Autodiscover - Grundlagen

Microsoft Consultant Exchange & Skype for Business (m/w)
Kommen Sie zu Net at Work. Wir haben spannende Projekte bei innovativen Kunden. Unser Team arbeitet kollegial und kooperativ – ständiger Austausch und Weiterbildung sind bei uns Standard.
https://www.netatwork.de/unternehmen/karriere/

Autodiscover ist einer der Schlüsselkomponenten, wie Outlook,, Smartphone, Lync und Skype for Business Clients aber auch viele andere Dienste den Weg zum Exchange finden. Dazu versucht die Client entweder automatisch die Mail-Adresse das aktuell angemeldeten AD-Benutzers aus dessen AD-Feld "mail" auszulesen oder der Client "fragt" den Anwender um die Mailadresse um dann seine Reise durch die verschiedenen Schritte anzutreten.

Der erste Client, der Autodiscover nutzte, war Outlook 2007. Autodiscover ist aber auch der Weg für jeden anderen Exchange Client. Dazu zählen auch ActiveSync-Client, EWS-Clients und selbst Exchange Server nutzten Autodiscover, um die Position von Postfächern für die Abfrage von Frei/Belegt-Zeiten.

Autodiscover ist nicht auf Exchange als Backend beschränkt. Auch Internetprovider, die POP3/IMAP4-Postfächer anbieten, können ihren Kunden eine "automatische Konfiguration" ihres Outlook Clients über diesen Weg anbieten.

Achtung Outlook 2016
Mit Outlook 2016 können Sie keine manuelle Konfiguration für Exchange Postfächer mehr abgeben. Hier muss Autodiscover funktionieren.

Ablaufdiagramm

Bis ein Client die richtige Konfiguration per Autodiscover gefunden hat, durchläuft er mehrere Schritte. Im Laufe der Evolution von Outlook und Exchange hat sich das Verfahren um weitere Schritte erweitert aber im wesentlichen ist es immer doch das folgende Flussdiagramm, nach dem Outlook, Exchange, EWS, Skype for Business und andere Clients einen Server finden.

Outlook ist insofern ein Sonderfall, dass es als wohl einziges Produkt auch eine Mitgliedschaft im Active Directory auswertet und neben dem Feld "mail" auch einen "Service Connection Point" sucht. Damit können Firmen mit Exchange sofort starten, ohne explizit einen DNS-Eintrag in der Form "autodiscover.<maildomain>" samt Zertifikat anzulegen. Erforderlich ist dies aber schon, das viele andere Clients eben nicht per LDAP im AD diese Informationen abfragen. Verlassen Sie sich also nicht darauf.

Achtung: Outlook 2016 arbeitet etwas anders: Siehe "Outlook 2016 Implementation of Autodiscover "
https://support.microsoft.com/en-us/help/3211279/outlook-2016-implementation-of-autodiscover
Es nutzt vor allem den Inhalt des UserPrincipalName (UPN) und nicht mehr das Feld "mail". Autodiscover eigentlich fehlt schlagen würde, dann versucht Outlook noch eine Auflösung mit Office 365.

Ds Bild hier ist diesbezüglich noch nicht aktualisiert.

Autodiscover Flussdiagramm 

Für den Betrieb mit Exchange ist der linke Ablauf maßgeblich. Die beiden anderen Wege haben nicht direkt etwas mit Autodiscover zu tun, sondern zeigen eher, welche andere Namen und Dienste Outlook versucht aber, wenn das klassische Autodiscover nicht zum Erfolg führt, noch mit verschiedenen Hostnamen einen IMAP4 oder POP3-Zugriff. Damit sollen primär Privatanwender mit klassischen Providern eventuell automatisch eingerichtet werden. Hinzu kommt, dass Outlook für verschiedene größere Provider sogar lokale "Autodiscover"-Dateien vorhält, so dass Yahoo, MSN etc. auch automatisch konfiguriert werden können.

Entgegen der Dokumentation von Microsoft habe ich sehr wohl beobachtet, dass die POP3/IMAP4/SMTP-Optionen geprüft werden, selbst wenn man im Active Directory ist. Die Dokumentation von Microsoft besagt hingegen, dass erst die Active Directory Daten ausgelesen und versucht werden und erst nach dem Misserfolg die anderen Wege "probiert" werden.

Autodiscover und Redirect
Autodiscover erlaubt eine Konfiguration, bei der autodiscover.domain.tld auf einen Webserver verweist, der KEIN SSL anbietet, sondern nur auf HTTP reagiert und den Client umlenkt. Das funktioniert mit Outlook 2007 SP1 recht gut aber ein iPhone (ActiveSync) mag das nicht und auch die Exchange Web Services benötigen Zusatzcode, um diese Exception abzufangen.

CAS-Failover/HA mit DNS
Da Outlook zuerst "autodiscover" anfragt, kann man diesen Eintrag auf die primäre Site lenken. Wenn dort kein Webservice antwortet, dann wird Outlook 2007SP1 und neuer später den SRV-Record versuchen. Dieser kann auf die BackupSite verweisen, da er dann eine Verfügbarkeit bereit stellen kann.

Es kann daher interessant sein, einen "Autodiscover"-Eintrag im offiziellen Namensraum z.B.: auf die Firmenwebseite (ohne SSL) zu verweisen und dort einfach den Pfad "Autodiscover" auf eine andere Webseite (z.B. owa.firma.tld) mit dem passenden Zertifikat umzuleiten. So erspart man sich den Namen "Autodiscover" im SAN-Zertifikate.

Empfehlung

Auch wenn Microsoft in Autodiscover viele Optionen vorgesehen hat, über die ein Client den Weg zum Exchange Postfach ermitteln kann, so gibt es eigentlich nur einen relevanten Weg. Denn neben Outlook gibt es ja viele andere Clients, die auch im Prinzip eine "Autodiscover"-Auflösung machen aber gar nicht alle Optionen unterstützen. So ignoriert selbst der Skype for Business Client die SRV-Records.

  • Intern
    Die Exchange Server pflegen automatisch entsprechende Service Connections Points, damit kompatible Clients wie Outlook den Weg alleine finden. Daher funktionieren viele Exchange Server und interne Outlooks "einfach so", auch wenn der Administrator überhaupt nichts davon weiß und die Zertifikate auf dem Exchange Server "SelfSigned" sind. Wenn Outlook per LDAP mit Authentifizierung die Daten lesen kann, dann ist er intern und glücklich.
    Eine Fehlkonfiguration fällt immer nur dann auf, wenn auch andere Clients ohne LDAP-Tauglichkeit eine Autodiscover-Auflösung versuchen.
  • https://autodiscover.<maildomain>
    Alle Autodiscover-Clients nutzen den Zugang über diese URL und diese sollte mit einem gültigen Zertifikate (Name, Aussteller, Datum) durch die Clients erreichbar sein

Die zweite Option ist eigentlich die Schlüsselkomponente und sollte bei allen Firmen für alle Domains so umgestellt werden. Sie ist zudem auch die "kompatibelste" Option.

Und was passiert wenn nicht ?

Probleme gibt es immer dann, wenn Störfaktoren die Auflösung verhindern, z.B.: „Wildcard-DNS-Einträge, die alles auf die Firmenwebseite auflösen und deren Zertifikat dann nicht passt:

  • https://<maildomain> mit Zertifikatfehler
    Autodiscover-Clients fragen auch nach diesem Namen und es gibt hier folgende Szenarien
    • o Zertifikat gültig und landet auf Exchange
      dann ist alles ok
    • o Zertifikat gültig aber Backend ist z.B. Firmenwebseite
      Keine Warnung, keine Antwort, Client geht zum nächsten Schritt
    • o Zertifikat ungültig
      Client. Zeigt eine Warnung. Diese Konfiguration ist nicht ratsam aber kann passieren, wenn die öffentliche Webseite https://www.<maildomain> per SSL gesichert wird und https://<maildomain> ebenfalls auf diese Adresse geht
    • o Kein Zertifikat: 443 geschlossen
      Keine Warnung, keine Antwort, Client geht zum nächsten Schritt
  • https://autodiscover.<maildomain>
    • Kein Zertifikat, keine Verbindung auf 443
      Client geht weiter zu http mit Redirect
    • Ungültiges Zertifikat
      Client zeigt Warnung an. Das Problem muss gelöst werden
    • Gültiges Zertifikat mit Exchange im Backend
      Autodiscover funktioniert
    • Gültiges Zertifikat ohne Exchange im Backend
      Autodiscover versucht den nächsten Weg

Autodiscover unsicher?

Siehe dazu die eigene Seite Autodiscover Sicherheit

Weitere Links