Autodiscover und DNS

Sie sollten vorab die Autodiscover Grundlagen gelesen und verstanden haben. Wenn ein Client per Autodiscover den Weg zum Postfach sucht, dann wird er in den meisten Fällen die SMTP-Domäne des Anwender als Startpunkt nutzen, um per DNS einen Exchange Server zu finden, der ihm dann mehr über den Zugang zum Postfach verrät. Outlook nutzt zwar auch einen Service Connection Point (Autodiscover LDAP), aber das funktioniert nur, wenn der Client in einem Forest ist, in dem auch Exchange installiert ist und ein Kontakt zum Domaincontroller möglich ist.

Suchen Sie gerade eine Lösung für ihre Autodiscover-Problem? Vielleicht finden Sie die hier. Aber nicht jede Firma hat Administratoren, die auf der MSXFAQ eine Lösung suchen und hoffentlich finden. Ein Anruf bei Net at Work kann ein schnellerer Weg sein. Aber dazu muss auf der anderen Seite ein engagierter, neugieriger und und wissbegieriger Kollege sitzen. Im richtigen Team können Sie durchstarten.
https://www.netatwork.de/unternehmen/karriere/#stellenangebote

 

Eine funktionierende Auflösung per DNS ist dennoch aus meiner Sicht erforderlich, da viele andere Clients ( ActiveSync, Skype for Business, WebServices, Mac etc.) nicht mit einem Service Connection Point im AD anfangen können.

Achtung
Nutzen ihre Anwender Outlook 2007 auf einem PC, der nicht Mitglied des Exchange Forest ist, dann versucht Outlook "autodiscover.maildomain.tld" als DNS-Host aufzulösen. Die dann genutzten Zertifikaten müssen für den Client vertrauenswürdig sein.

Der Lync-Client als auch die Lync Telefone nutzen "Autodiscover", um per EWS aus Exchange Informationen zu den nächsten Meetings etc. zu erhalten. Leider ignorieren Sie dabei sowohl die Service Connection Points als auch SRV-Records. Sie müssen also diese Funktion per "autodiscover.<maildomain> mit einem passenden Zertifikat auf dem CAS-Server bereit stellen.

Webseite zum externen Test der Exchange Anbindung und DNS Einträge
https://www.testexchangeconnectivity.com/

Beachten Sie auch die How-To Seite E2K7:Autodiscover

Autodiscover und Authentifizierung

Natürlich liefert der Exchange Server die Information nicht einfach so aus. Der Service benötigt zuerst einmal die Mailadresse aber dann natürlich auch gültige Anmeldedaten. Und wie bei jedem HTTP-Zugriff gibt es hier mehrere Dinge, die dies erschweren:

  • Zertifikat
    Der Name "autodiscover.<maildomain>" muss natürlich im Zertifikat auftauchen, die ausstellende PKI vertrauenswürdig sein, der Datumsbereich passen und die CRL funktionieren. Das ist nicht immer einfach, da es auch Geräte gibt, die nicht über ein AutoEnrollment mit neuen Stammzertifikaten ausgestattet werden und nur einer Teilmenge vertrauen
  • Internet Zonen
    Dann sendet ein Windows Clients seine Anmeldedaten ja nicht einfach an einen beliebigen Host. Der muss schon in der "Intranet-Zone" sein, wozu erst einmal nur Systeme mit dem gleichen DNS-Raum oder bei konfiguriertem Proxy direkt erreichbare Systeme gehören. Wenn der DNS-Namensraum ihres AD-Forest nicht mit der Maildomäne übereinstimmt, dann ist autodiscover.<maildomain> eben nicht mehr "Intranet. DAs Problem kennen Sie ja auch schon von MAPI over HTTP und Outlook Anywhere.
  • Proxy, Reverse Proxy, WAN-Optimierer
    Wenn ein Client durch Proxy-Ketten zugreift, dann kann sowohl ein ausgehender Proxy, z.B. im Hotel etc., als auch der Reverse Proxy auf der Exchange Seite beim Zugriff aus dem Internet als auch ein Optimierer im eigenen WAN die Zugriffe verändern, so dass z. B. NTLM nicht mehr geht.
  • WSSecurity
    Es sind nicht immer "Benutzer", die auf den Autodiscover-Service zugreifen. Auch Server sprechen z.B. im Rahmen von Kalenderfederation miteinander und hier kommt nicht das klassische Benutzername + Kennwort zum Einsatz.

Es gibt also auch hier noch Herausforderungen.

Hinweis:
Alle Betrachtungen bezüglich Autodiscover sind pro SMTP-Domain erforderlich.. Wer also mehrere SMTP-Domains auf der gleichen Umgebung betreibt, muss mehrere Autodiscover-Einträge anlegen, Namen im Zertifikat addieren etc.

Autodiscover per CNAME/A-Record

Wenn wir von Outlook im LAN einmal absehen, versuchen die meisten Clients sich aber direkt per Autodiscover unter Nutzung der Maildomäne zu verbinden. Dazu muss der Client natürlich zuerst einmal auch "autodiscover.<maildomain>" per DNS auflösen können. Schon das kann natürlich zumindest im internen LAN eine Herausforderung sein, da hier das Thema "Split-DNS" auf die Tagesordnung kommt.

Es ist sicher einfach im Internet einen solchen Eintrag zu setzen, der dann auf den per ISA/TMG o.ä. veröffentlichten Service verweist und dort auch ein öffentliches Zertifikat nutzt. Aber im Internen LAN gibt es nun drei Optionen

  1. Ihre interne AD-Zone entspricht der SMTP-Domain
    Hier ist es einfach ein "autodiscover"-Eintrag, der zu addieren ist und auf den Exchange Server verweist. Mit Authentifizierung sollten sie keine Probleme haben, da diese Domäne ja als AD-Domain als "Trusted/Intranet" angesehen wird.
  2. SMTP-Domain ist ungleich dem AD aber intern auflösbar (Split DNS)
    Viele Firmen fahren einen "Split-DNS"-Ansatz, dass Sie auch im internen DNS die externen Domänen samt Hosts pflegen. Das ist zwar ein Mehraufwand, wenn man die komplette externe Zone quasi "spiegeln" muss aber man kann bestimmte Hosts von Intern direkt auf private Adressen verweisen. Eine Abwandlung sind hier PinpointDNS-Zonen", bei denen nur ein Host nach intern umgeleitet wird
  3. SMTP-Domain ist intern nicht direkt auflösbar
    Im dem Fall wird der Client über den konfigurierten Proxy versuchen, den Host "im Internet" zu erreichen. Das kann durchaus sinnvoll sein, z.B.: wenn Sie Office 365 nutzen oder Sie in einer Niederlassung arbeiten, die für den Exchange Zugang das Internet nutzt um die kostbare MPLS-Leitung frei zu halten. Bedenken Sie dabei aber auch, dass sowohl der Proxy als auch der Client bei der Authentifizierung besondere Hürden zu nehmen haben.

Die Anlage des Autodiscover-Eintrags ist dann jedoch sehr einfach.

Ich kann es aber nur noch mal wiederholen, dass Sie auf dem Server am besten ein öffentliches SAN-Zertifikat einsetzen, indem es für jede verwendete SMTP-Domain auch einen entsprechenden Autodiscover-Eintrag gibt.

Der Client versucht dann die beiden URLs anzusprechen

  • https://autodiscover.<SMTPDomain>/autodiscover.xml
  • https://autodiscover.<SMTP-Domain>/autodiscover/autodiscover.xml

Autodiscover per Umleitung

Sicher fällt ihnen sofort auf, dass die Verwendung von SAN-Zertifikaten nicht immer sinnvoll möglich ist.

  • Viele Domains
    Zum einen ist das SAN-Feld im Zertifikat nicht endlos groß, so dass je nach Domänennamenlänge bei 40-80 Zertifikaten das Zertifikat nicht mehr ausgestellt werden kann (1024 Bytes). Auch tun sich Zertifizierungsstellen mit sehr umfangreichen SAN-Listen schwer. Zum einen wollen Sie mehr Geld dafür aber vor allem müssen Sie ja für jede der Domänen prüfen, ob der Request zulässig ist
  • Hohe Fluktuation
    Und dann gibt es noch Hoster, die für ihre Kunden z.B. Exchange Hosting anbieten und hier kommen quasi täglich neue Kunden hinzukommen oder wieder weg gehen. Hier wäre es einfach untauglich jedes Mal das komplette Zertifikat zu ändern.

Für diesen Fall hat Microsoft alternative Funktionen implementiert. Neben statischen Konfiguration mit lokalen XML-Dateien, die aber nur von Outlook unterstützt werden (siehe Autodiscover Outlook), gibt es noch die Funktion des HTTP Redirect, bei der folgende Dinge erfüllt sei müssen.

  • Kunde muss "autodiscover.<maildomain> als CNAME auf den Provider eintragen
    Das macht Office 365 übrigens genau so
  • Der Provider-Service darf "NICHT" per SSL erreichbar sein
    Wenn der Client über Port 443/https eine Verbindung erhält ,wird er ein Zertifikat bekommen und prüfen. Genau das wird aber nicht gültig sein. Der WebServer darf also nicht per 443 erreichbar sein.
  • HTTP-Redirect
    Die einzige Aufgabe dieses WebServers ist die Weiterleitung des Clients auf einen anderen Namen, der dann per HTTPS erreichbar sein muss und ein vertrauenswürdiges und auf diesen Namen ausgestelltes Zertifikat vorweist.
  • Generischer Autodiscover-Service
    Auf dem Zielserver der Umleitung läuft dann die normale Autodiscover-Funktion.

Per Default verweigert sich Outlook dieser Umleitung aber, denn aus Sicherheitsgründen erwartet Outlook, dass der Domainname des angesprochenen Server natürlich auch mit der SMTP-Adresse des Anwenders übereinstimmt. Schließlich sendet Outlook dort im nächsten Schritt seine Anmeldeinformationen hin.

Achtung:
Diese Umleitung funktioniert nicht mit Autodiscover V2 und damit z.B. dem Zugriff per Teams auf ihren OnPremise-Kalender

  • 2480582 How to suppress the AutoDiscover redirect warning in Outlook 2010
  • 956528 You cannot suppress the Autodiscover redirect warning in Outlook 2007

Autodiscover als SRV-Record

Achtung:
Diese Lösung funktioniert nur mit Clients, die SRV-Records auflösen können. Das ist z.B. mit Windows Phone/Windows Mobile angeblich nicht möglich, so dass diese Clients andere Wege nutzen müssen.

Wenn Sie "sicher" stellen können, dass alle Client auch Outlook 2007 SP1 oder neuer oder eben Outlook 2003 und älter einsetzen, dann können Sie mit dem DNS-SRV-Eintrag die ganzen Aufwände für ein SAN-Zertifikat oder eine Autodiscover Webseite ohne SSL mit Umleitung auf eine andere Seite sparen und einen SRV-Record im DNS eintragen:

Autodiscover im DNS

Den Erfolg des Eintrags können Sie per NSLOOKUP einfach prüfen

NSLookup auf SRV-Record

Der Eintrag verweist auf den Namen eines Webserver mit dem "passenden" Zertifikat. Outlook 2007 SP1 erkennt den Eintrag aber fragt einmal nach, ob diese Umleitung auch so in Ordnung ist.

Outlook und SRV-Record

Ein Test über die Outlook 2007 "Test Autodiscover"-Funktion zeigt auch hier dann die Umleitung im Protokoll an.

Outlook Test Autodiscover mit SRV-Record

Man sieht hier gut, dass Outlook erst einmal die alten Zugriffe auf den Domainnamen, auf Autodiscover per SSL und auf Autodiscover als "Redirect-Check" versucht um dann aber einen "SRV-Record Lookup" zu machen, der diesmal zum Erfolg führt und Outlook auf die primäre Seite umleitet. Da bekommt der dann auch per SSL verschlüsselt eine Antwort und kann weiter arbeiten.

Es gibt berichte, dass nicht alle DSL-Router, die auch als DNS-Proxy fungieren, mit den SRV-Records arbeiten. Wenn Sie also an einem privaten Netzwerk arbeiten und Autodiscover nicht funktioniert, dann geben Sie doch einfach mal das folgende ein:

NSLookup prüft SRVrecord 

Hier sehen Sie die Anfrage aus den SRV-Record von Net at Work. Wenn diese Anfrage oder die Anfrage auf ihre Domain nicht funktioniert, dann fragen Sie mit NSLOOKUP mal einen anderen Server anstelle ihres Routers (meist 192.168.0.1)

Die Nutzung von SRV-Records ist aber nur für bestimmte Clients tauglich. So nutzt ein Lync Communicator als auch Lync Telefone als auch die Office 365 Hybrid-Auflösung keine SRv-Records. Der Einsatzbereich ist also stark beschränkt.

Weitere Links

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.
hhttps://www.netatwork.de/unternehmen/karriere/