Autodiscover Check

Autodiscover ist der Weg, über den Outlook für eine E-Mail-Adresse den zuständigen Exchange-Server samt aller Endpunkte findet, ohne dass der Nutzer Servernamen eintippt. Schlägt Autodiscover fehl, lässt sich ein Exchange-Postfach in Outlook nicht oder nur mit Zertifikatswarnungen einrichten. Dieser Check prüft die drei Bausteine, auf die Outlook nacheinander zugreift: DNS, TLS-Zertifikat und die Autodiscover-Antwort selbst.

Was dieses Werkzeug prüft

DNS: die Einträge autodiscover.<domain> (A/CNAME) und _autodiscover._tcp.<domain> (SRV), dazu der MX-Hinweis. Endpunkt: daraus wird genau ein HTTPS-Ziel auf Port 443 gewählt (der autodiscover-Host, sonst das SRV-Ziel, sonst die Domain selbst) und getestet. Am Endpunkt wird das TLS-Zertifikat geprüft (Kette, Laufzeit und ob es den Autodiscover-Hostnamen als SAN führt, was Outlook zwingend verlangt) und ein AutodiscoverV1-Aufruf mit NTLM Type 1 gemacht. Ein gesunder Exchange antwortet mit 401 und den angebotenen Authentifizierungsverfahren im WWW-Authenticate-Header. Microsoft 365 wird erkannt (CNAME auf autodiscover.outlook.com oder MX auf mail.protection.outlook.com) und ohne Verbindungstest nur als Hinweis gemeldet.

Das Ergebnis lesen

Grün heißt: ein Autodiscover-Ziel im DNS auffindbar, ein Zertifikat, das den Namen abdeckt, und eine 401-Antwort mit sinnvollen Auth-Verfahren. Eine 401 ist hier das erwünschte Ergebnis: der Endpunkt soll eine Anmeldung verlangen. Als Härtungsbefund ausgewiesen werden angebotenes NTLM/Negotiate (interne Namen im Type-2-Token), eine alte Windows-Build-Nummer und ein veralteter Exchange-Build aus dem X-OWA-Version-Header. Ein nicht abgedeckter Hostname oder ein abgelaufenes Zertifikat ist ein Fehler, ebenso ein dedizierter Endpunkt, der sich gar nicht wie Exchange verhält.

Grundlagen

Autodiscover ist ein Microsoft-Protokoll ([MS-OXDSCLI]), kein RFC-Standard. Der SRV-Eintrag _autodiscover._tcp folgt dem allgemeinen SRV-Format aus RFC 2782. Die Regel, dass ein Zertifikat den angesprochenen Hostnamen als Subject Alternative Name führen muss, kommt aus RFC 6125. Dieser Test sendet ausschließlich den ersten Aushandlungsschritt und nie Zugangsdaten; AutodiscoverV2 und beliebige weitere Endpunkte werden bewusst nicht geprüft.

Typische Fehlerbilder und wie man sie behebt

• Kein Autodiscover-Eintrag im DNS. Einen autodiscover.<domain>-Record (A oder CNAME auf den Exchange-Namen) anlegen, alternativ einen SRV-Record _autodiscover._tcp mit Ziel und Port 443. Ohne das rät Outlook nur und landet oft auf der falschen Adresse.
• Outlook zeigt eine Zertifikatswarnung. Fast immer deckt das Zertifikat autodiscover.<domain> nicht ab. Ein Zertifikat verwenden, das alle Namen als SAN führt (autodiscover., mail., owa.), oder die Autodiscover-Antwort so setzen, dass sie auf einen abgedeckten Namen zeigt.
• Endpunkt liefert 200 ohne Anmeldung. Der AutodiscoverV1-Pfad ist dann anonym erreichbar und gibt eventuell interne Einstellungen preis. Vor-Authentifizierung am Reverse-Proxy oder die Windows-Authentifizierung in IIS aktivieren.
• Veralteter Exchange-Build. Der aus X-OWA-Version abgeleitete Build liegt hinter dem aktuellen Cumulative Update. Das jeweils aktuelle CU plus das letzte Sicherheitsupdate einspielen; ältere Builds enthalten in der Regel bekannte Lücken.
• SRV-Record vorhanden, wird aber ignoriert. Outlook nutzt SRV nur, wenn autodiscover.<domain> nicht direkt auflöst. Das Ziel des SRV-Records muss zudem per HTTPS mit gültigem Zertifikat erreichbar sein.

Ausführlicher Hintergrund im Blogartikel Exchange 2016: Umfangreiches Whitepaper zu Autodiscover auf frankysweb.de.