Autodiscover und Webseite

Der "Autodiscover"-Prozess nutzt verschiedene Wege, um die passende Exchange Postfachkonfiguration zu ermitteln. Die Wege sind gut dokumentiert aber auf einen Sonderfall will ich auf dieser Seite gesondert eingehen.

Autodiscover-Abfolge

Wenn sie sich das Ablaufbild auf Autodiscover - Grundlagen genauer anschauen, dann sollte ihnen die rot umrandete URL auffallen:

An diese Stelle kommt Outlook immer dann, wenn keine Verbindung zum Domain Controller möglich ist und Outlook daher nicht über den Autodiscover SCP eine interne URL erhält. Wer nun etwas aufgepasst hat, kann hier mehrere Probleme für die Client auf Anhieb erkennen, die im Internet unterwegs sind.

msxfaq.de nicht im DNS

Im einfachsten Fall ist der Name gar nicht auflösbar. Outlook erkennt dies und gibt diesen Request sofort auf und geht zum nächsten Verfahren über.

msxfaq.de im DNS

Auch wenn Sie den Namen offizielle nie eingetragen haben, so haben die meisten Firmen und Provider diese Adresse durchaus gepflegt. Wer eine eigene Domain nutzt, kennt natürlich die "WWW"-Adresse. Dies ist aber auch nur ein Hostname in der eigenen Domain und die meisten Provider addieren parallel auch noch einen Eintrag für "ohne WWW" und lassen diesen auf die Webseite verweisen. Das können Sie ganz einfach prüfen.

PS C:> Resolve-DnsName www.msxfaq.de

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
www.msxfaq.de                                  AAAA   558   Answer     2a01:488:42:1000:b24d:7562:25:6783
www.msxfaq.de                                  A      99    Answer     178.77.117.98

PS C:\> Resolve-DnsName msxfaq.de

Name                                           Type   TTL   Section    IPAddress
----                                           ----   ---   -------    ---------
msxfaq.de                                      AAAA   557   Answer     2a01:488:42:1000:b24d:7562:25:6783
msxfaq.de                                      A      557   Answer     178.77.117.98

Meist sind es A-Records und keine CNAMEs. Das führt aber dazu, dass Outlook nun bei einem Zugriff per HTTPS auf diese Webseite eine Antwort bekommt. Auch das ist per PowerShell mal schnell geprüft

PS C:\> Invoke-WebRequest "https://msxfaq.de/autodiscover/autodiscover.xml" -SkipHttpErrorCheck

StatusCode        : 404
StatusDescription : NotFound
Content           : <!DOCTYPE html>
                    <html lang="de">

                    <head>
                    <meta http-equiv="Content-Language" content="de">
                    <meta http-equiv="refresh" content="0; URL=https://www.msxfaq.de/404.htm">
                    </head>
                    <body>
                    <h1>MSXFAQ.…
RawContent        : HTTP/1.1 404 NotFound
                    Date: Tue, 30 Mar 2021 10:05:30 GMT
                    Connection: keep-alive
                    Server: Apache
                    X-Frame-Options: SAMEORIGIN
                    ETag: "192-5939d24141e00"
                    Accept-Ranges: bytes
                    Content-Security-Polic…
Headers           : {[Date, System.String[]], [Connection, System.String[]], [Server, System.String[]],
                    [X-Frame-Options, System.String[]]…}
Images            : {}
InputFields       : {}
Links             : {}
RawContentLength  : 402
RelationLink      : {}

In meinem Fall gibt es einen "404 not Found". Für Outlook ist das genug Information, um es nicht weiter zu versuchen

Webseite und SSL

Mittlerweile sollte dieser Fehler "gelöst" sein aber gerade in der Anfangszeit von HTTPS wurden Zertifikate nur für die Webseite mit einem "www"-Prefix ausgestellt. Der Zugriff auf https://msxfaq.de lieferte dann eine Zertifikatswarnung. Dies ist heute aber nicht mehr der Fall, da quasi alle Webserver-Zertifikate heute beide Namen enthalten.

Früher gab es "Single Name Zertifikate" während Zertifikate mit mehreren Namen, auch gerne als "UC-Zertifikat" mit bis zu 5 Namen, teurer verkauft wurden. Heute enthält quasi jedes Webserver-Zertifikat zwei Namen. Damit liefert Outlook zumindest auch keine SSL-Warnung mehr, wenn es auf https://<domain</.. zugreift.

302 statt 404

Es gehört zu guten Ton, eine öffentliche und anonym erreichbare Webseite mit SSL abzusichern. Spätestens seit Suchmaschinen darauf Wert legen und unverschlüsselte Seiten abgestraft werden, haben alle Webseiten ein Zertifikat. Der zweite Schritt ist der SSL-Zwang oder zumindest die Umleitung von Anwendern auf die HTTPS-Seite, um Veränderungen beim Transport oder über Proxy-Server zu erschweren oder dem Anwender zumindest sichtbar zu machen. Auch meine MSXFAQ leitet die Anwender auf HTTPS um.

PS C:\> Invoke-WebRequest "https://msxfaq.de/autodiscover/autodiscover.xml" -SkipHttpErrorCheck -MaximumRedirection 0

StatusCode        : 301
StatusDescription : Moved
Content           : <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
                    <html><head>
                    <title>301 Moved Permanently</title>
                    </head><body>
                    <h1>Moved Permanently</h1>
                    <p>The document has moved <a href="https://www.msxfaq.de/a…
...

Da Invoke-WebRequest automatisch den Weiterleitungen folgt, müssen Sie mit "-MaximumRedirection 0" arbeiten, um den Redirect selbst zu sehen.

Outlook folgt solche einer Umleitung

Fehler 401/200 statt 404

Ein "404 not found" ist die richtige Antwort, wenn sie unter "https://<domain>/autodiscover/autodiscover.xml" keinen Autodiscover-Dienst liefern. Manchmal nutzen Webseitenbetreiber aber ein Content Management Systeme wie Wordpress, Drupal oder eine vorgeschaltete "Webfirewall", die den Zugriff auf diese URL nicht von vorneherein mit einem "404" ablehnt, sondern eine Authentifizierung für das CMS anfordert.

Da Outlook noch nicht erkennen kann, ob er nun schon mit einem Exchange Server spricht, versucht sich Outlook natürlich anzumelden. Die meisten öffentlichen Webseiten bieten natürlich weder Kerberos noch NTLM an, sondern fragen "Basic AUTH" nach oder eigen ein Formular an:

  • Formular mit 200 OK
    Bei einem Formular liefert der Webserver eine HTML-Seite mit einem 200 OK aus. Outlook kann aber nicht erkennen, dass es sich um ein Form handelt und interpretiert den Inhalt. Da er für Outlook keinen Sinn ergibt, verwirft Outlook die Rückgabe und geht zum nächsten Test über
  • Basic mit 401
    Outlook erkennt die "Authentication required"-Meldung und sendet ggfls. vorliegende Anmeldedaten, mit der die öffentliche Webseite aber nichts anfangen kann. Das ist einer der Fälle, in denen Outlook eine Kennwortbox anzeigt.

Hier kommen Outlook und der Anwender dann nicht weiter. Wenn der Anwender nicht bemerkt, dass Outlook sich an der falschen Gegenstelle anmelden möchte, dann wird der Anwender nach mehreren Eingaben des Kennworts aufgeben

Risiko Webseite gekapert

Solange die öffentliche Webseite unter ihrer Kontrolle ist, können Sie das Verhalten von Outlook entsprechend über die Reaktion der Webseite steuern. Sie können z.B. den 401-Fehler, der in Outlook eine Authentifizierung triggert, unterbinden.

Anders sieht es aber aus, wenn ihre Webseite "gekapert" wird. Das ist gar nicht mal so unwahrscheinlich, denn verschiedene Content-Management-Systeme, z.B. Wordpress, sind immer wieder Einfallstore. Genaugenommen sind es noch viel mehr die Erweiterungen von Drittanbietern, die als PHP-Code in ein Content Management System eingebunden werden. Selbst ohne CMS müssen Sie beim Einsatz von Code (PHP, ASPX; etc.) auf ihrem Webserver genau hinschauen. Auch die MSXFAQ ist schon kompromittiert gewesen (Siehe MSXFAQ.Org Hack).

In dem Fall könnte ein Angreifer einen "passenden" Autodiscover-Code auf ihrem Webserver hinterlegen, der auf die Anfragen von Outlook mit einem 401 antwortet und dann die eingegebenen Zugangsdaten dankbar annimmt.

Lösung

Microsoft hat scheinbar nicht vor, das Verhalten von Outlook bezüglich Autodisover zu ändern um den Abruf der Root-Domain ihrer Domain per HTTPS zu unterbinden. Es wird also immer wieder passieren, dass Outlook auf https://<domain>/autodiscover/autodiscover.xml zugreift. Sie können als Administrator aber diese Verhalten über Einstellungen in der Registrierung bzw. über Gruppenrichtlinien beeinflussen. Die Einstellungen sind je Outlook Version im passenden Pfad anzulegen. Für die Root-Domain ist der Eintrag "ExcludeHttpsRootDomain" maßgeblich.

[HKEY_CURRENT_User\Software\Microsoft\Office\12.0\Outlook\AutoDiscover]
"ExcludeHttpsRootDomain"=dword:00000001

Auch die anderen Optionen können Sie abschalten, wenn Sie diese nicht nutzen wollen.

[HKEY_CURRENT_User\Software\Microsoft\Office\12.0\Outlook\AutoDiscover]
"ExcludeHttpsAutodiscoverDomain"=dword:00000001
"ExcludeScpLookup"=dword:00000001
"ExcludeSrvRecord"=dword:00000001

Gehen Sie aber sehr umsichtig damit vor und merken Sie sich diese Abweichung vom Standard. Bei der Fehlersuche sollten Sie wissen, dass Sie hier Abweichungen eingestellt haben.

Diese Einstellung ist für Domain-Mitglieder einfach zu setzen aber hilft nicht bei "freien" Outlook-Installationen. Die internen Outlook sollten aber über Autodiscover und SCP nie nach extern fragen.

Die Problemstellung darf sie aber nicht davon entbinden, ihre Anwender für "Kennwortabfragen" zu sensibilisieren und insbesondere, wo Sie diese eingeben. Ihr Ziel sollte immer ein "SingleSignOn" mit möglichst wenig Kennworteingaben sein.

Weitere Links