AutoErmittlungsablauf in einer Office 365-Umgebung | Teil 1#3 | Teil 29#36

Der Autodiscover-Ablauf in einer Office 365-basierten Umgebung kann als faszinierender Prozess angesehen werden, da der Autodiscover-Client seinen Autodiscover-Endpunkt findet, was viele Wendungen beinhaltet.

AutoErmittlungsablauf in einer Office 365-Umgebung | Die Artikelserie

Der aktuelle Artikel ist der erste Artikel in einer Reihe von drei Artikeln, die sich der detaillierten Beschreibung des Autodiscover-Ablaufs in einer Umgebung widmen, die wir als „nur Cloud“ bezeichnen können.

Die weiteren Artikel der Reihe sind:

• AutoErmittlungsablauf in einer Office 365-Umgebung | Teil 2#3 | Teil 30#36
• AutoErmittlungsablauf in einer Office 365-Umgebung | Teil 3#3 | Teil 31#36

Der erste Artikel widmet sich der Darstellung der Logik und der beteiligten Komponenten im Autodiscover-Ablauf, der in einer Office 365-basierten Umgebung implementiert wird.

In den nächsten beiden Artikeln werden wir den Autodiscover-Ablauf überprüfen, der in einer Office 365-basierten Umgebung mithilfe des webbasierten Microsoft-Tools Microsoft Remote Connectivity Analyzer (ExRCA) implementiert wird.

Weitere Informationen zur Verwendung des Microsoft Remote Connectivity Analyzer (ExRCA)-Tools finden Sie im Artikel - Microsoft Remote Connectivity Analyzer (ExRCA) | AutoErmittlungstools zur Fehlerbehebung | Teil 2#4 | Teil 22#36

Die Sonderzeichen der AutoErmittlung fließen in einer Office 365-basierten Umgebung ein

Der AutoErmittlungsablauf, der in einer Office 365-basierten Umgebung implementiert ist, unterscheidet sich stark vom „Standard“-AutoErmittlungsablauf, der in einer lokalen Exchange-Umgebung implementiert ist.

Die Hauptfunktionen des Autodiscover-Ablaufs in einer Office 365-basierten Umgebung sind:

• Der AutoErmittlungsablauf, einschließlich strukturierter Fehlerereignisse. Mit einfachen Worten: Der Autodiscover-Client adressiert einen Autodiscover-Endpunkt, der nicht vorhanden ist oder die erforderlichen Autodiscover-Informationen nicht bereitstellen kann.
• Der Autodiscover-Ablauf basiert auf einigen Knoten und „Sprüngen“, bis der Autodiscover-Client sein endgültiges Ziel erreicht, d. h. den Autodiscover-Endpunkt, der die erforderlichen Autodiscover-Informationen bereitstellen kann.
• Einige der Knoten, die den Autodiscover-Ablauf umfassen, stellen nicht die „Standard-Autodiscover-Informationen“ bereit, sondern stellen stattdessen eine Autodiscover-Umleitungsnachricht bereit, die den Autodiscover-Client an zusätzliche Autodiscover-Endpunkte „weiterleitet“.

Klingt diese Information groß und nicht so klar?

Wenn die Antwort „Ja“ ist, dann willkommen im Club!

Exchange Online und „Nur-Cloud-Umgebung“

In der Exchange Online-Umgebung wird der AutoErmittlungsprozess auf andere Weise implementiert als der „Standard“-AutoErmittlungsprozess als bei der Implementierung in einer lokalen Exchange-Umgebung.

In der lokalen Exchange-Umgebung sucht der AutoErmittlungs-Client nach einem AutoErmittlungs-Endpunkt, der eine bestimmte Domäne darstellt.

Beispielsweise in einem Szenario, in dem ein Benutzer mit der E-Mail-Adresse - Bob@o365info.com versucht, ein neues Outlook-Mail-Profil zu erstellen; Der Autodiscover-Prozess wird auf folgende Weise implementiert:

Autodiscover Endpoint fragt DNS ab und sucht nach einem Host mit dem Namen - o365info.com. Falls es dem Autodiscover-Client nicht gelingt, den angegebenen Hostnamen zu verbinden, fährt der Autodiscover-Endpunkt mit Schritt 2 fort, in dem der Autodiscover-Client versucht, einen potenziellen Autodiscover-Endpunkt mithilfe des Hostnamens zu finden -
autodiscover.o365info.com

Die zugrunde liegende Annahme ist, dass die Organisation in einer lokalen Exchange-Umgebung einen öffentlich zugänglichen Exchange CAS-Server zuweist, der als Repräsentant für den Domänennamen dient - o365info.com und der FQDN -autodiscover.o365info.com , der diesem öffentlich zugänglichen Exchange-Server zugeordnet ist.

Wenn es dem Autodiscover-Client gelingt, den Autodiscover-Endpunkt zu finden, fordert der Autodiscover-Client den Autodiscover-Endpunkt auf, „seine Identität zu beweisen“, indem er ein öffentliches Serverzertifikat bereitstellt.

Der Autodiscover-Endpunkt stellt das erforderliche Zertifikat bereit und der Autodiscover-Client überprüft, ob das Serverzertifikat den Domänennamen enthält - o365info.com (in einem Szenario eines Wildcard-Zertifikats) oder den Hostname - autodiscover.o365info.com.

Im Exchange Online-Umfeld lässt sich das beschriebene Szenario aus einem ganz einfachen Grund nicht umsetzen:

In Wirklichkeit ist die „Cloud-Infrastruktur“ (Office 365 und Exchange Online) nicht in der Lage, jedem Office 365-Mandanten und jedem öffentlichen Bereich, der bei Office 365 registriert ist, ein dediziertes öffentliches Zertifikat zuzuweisen.

In Exchange Online kann ein bestimmter Exchange-Server (oder eine Reihe von Exchange Online-Servern) hundert oder tausend verschiedene Domänen gleichzeitig darstellen.

Das Konzept, bei dem der Autodiscover-Endpunkt (der Exchange-Server) ein öffentliches Zertifikat bereitstellt, das einen Verweis auf die jeweilige Client-Domäne enthält, ist nicht umsetzbar!

Die große Frage ist also: Wie lösen wir das Problem, das Autodiscover-Clients den Zugriff auf ihr Exchange Online-Postfach ermöglicht?

Und die Antwort lautet: „Umleitung“.

DNS-Umleitungsmethode mithilfe eines CNAME-Eintrags

Die Office 365- und Exchange Online-Umgebung hat einen anderen Charakter als die lokale Exchange-Umgebung.
Aus diesem Grund ist es wichtig, dass wir mit der Kernlogik der Office 365-Infrastruktur vertraut sind.

Office 365 (das Exchange Online als E-Mail-Infrastruktur nutzt) ist ein SaaS (Software as a Service).
Jeder der Office 365-Abonnenten wird als „Mandant“ bezeichnet; das einen privaten Raum im Office 365 „Big Building“ mietet.

In einer lokalen Exchange-Umgebung verwendet die Organisation einen dedizierten öffentlichen Exchange-Server, der als „Repräsentant“ für den öffentlichen Domänennamen der Organisation dient.

Die „Cloud-Umgebung“ (Office 365) kann diese Art von „dediziertem Exchange-Server“, der den bestimmten Domänennamen des Office 365-Mandanten darstellt, nicht bereitstellen.

Für den Fall, dass wir beispielsweise ein neues Outlook-Mail-Profil für einen Empfänger mit der E-Mail-Adresse - Bob@o365info.com, dem Autodiscover-Client (Outlook) erstellen müssen, startet den Autodiscover-Prozess immer, indem er nach einem Host mit dem Namen o365info.com
sucht. Wenn er diesen Host nicht finden oder mit ihm kommunizieren kann, versucht er, nach dem Autodiscover-Endpunkt zu suchen benannt - autodiscover.o365info.com

Die eigentliche Antwort lautet, dass es in der Office 365-Umgebung keinen „echten Server“ mit dem Namen autodiscover.o365info.com gibt, der über ein öffentliches Zertifikat verfügt, das einen Verweis auf den Domänennamen enthält - < span class="highlight4i">o365info.com

Theoretisch sollte der Autodiscover-Prozess fehlschlagen.

Die Antwort auf dieses Problem lautet: Identitätswechsel.

Die Lösung besteht darin, den Autodiscover-Client „denken“ zu lassen, dass er mit einem bestimmten Host kommuniziert, während er in der Praxis mit einem anderen Element kommuniziert, das sich selbst als das Element „präsentiert“, für das der Autodiscover-Client ihn hält.

Klingt nach einer Verschwörung?
Ja, ein bisschen

In einer „Nur-Cloud-Umgebung“ (E-Mail-Infrastruktur, die vollständig in der Cloud gehostet wird) müssen Office 365-Abonnenten ihr öffentliches DNS aktualisieren, indem sie einen neuen CNAME-Eintrag hinzufügen.

Bei den DNS-Einträgen, die die „Magie“ ausmachen, handelt es sich um einen einfachen CNAME-Eintrag, der für die erneute Erkennung von Autodiscover-Client-Anfragen an ein Office 365-„Element“ erstellt wurde, das sich gegenüber dem „echten Host“, nach dem gesucht wird, ausgibt.

Autodiscover und der DNS-CNAME-Eintrag (DNS-Umleitung)

Der „Trick“ des CNAME-Records wird wie folgt umgesetzt:

Auf dem öffentlichen DNS-Server, der den öffentlichen Domänennamen der Organisation hostet, erstellen wir einen neuen CNAME-Eintrag, der Anfragen für den Hostnamen - Autodiscover - an einen anderen oder einen anderen Hostnamen umleitet.

Der Hostname, an den Autodiscover-Anfragen umgeleitet werden, lautet: autodiscover.o365info.com

Beispielsweise fügen wir auf dem öffentlichen DNS-Server, der den Domänennamen hostet - o365info.com - einen neuen CNAME-Eintrag hinzu, der den DNS-Server dazu veranlasst, die IP-Adresse bereitzustellen hosten Sie autodiscover.outlook.com für jeden DNS-Client, der nach der IP-Adresse von autodiscover.outlook.com fragt

Wenn beispielsweise ein Autodiscover-Client versucht, mit einem Host namens autodiscover.o365info.com zu kommunizieren, lautet die IP-Adresse, die vom DNS an den Autodiscover-Client zurückgegeben wird, „lead „Der Autodiscover-Client für die Office 365-Hosts mit dem Namen - autodiscover.outlook.com.

Wer ist autodiscover.outlook.com?

Das autodiscover.outlook.com ist ein „Office 365-Element“, das als „logischer Router“ zwischen den Autodiscover-Clients und der Exchange Online-Infrastruktur dient.

Der AutoErmittlungsfluss von Office 365-Benutzern (Benutzer, deren Postfach bei Exchange Online gehostet wird) beginnt mit der Kommunikation mit den Office 365-Hosts mit dem Namen -
autodiscover.outlook.com

Die „autodiscover.outlook.com-Komponente“ akzeptiert die Anfragen des Autodiscover-Clients, aber anstatt die erforderlichen Autodiscover-Informationen nachzuweisen, muss der Host autodiscover .outlook.com, senden Sie als Antwort eine „Umleitungsnachricht“, um den Autodiscover-Client zu anderen Offices 365 Autodiscover-Endpunkten zu „leiten“.

autodiscover.o365info.com ein einzelner Host oder logische Komponenten. Theoretisch handelt es sich bei den Office 365-Objekten, die den Autodiscover-Endpunkt auf den erforderlichen Exchange Online-Server umleiten, um einen einzelnen Host mit dem Namen autodiscover.o365info.com.

In Wirklichkeit ist autodiscover.outlook.com nur ein logisches Objekt, das von Dutzenden oder sogar Hunderten Servern repräsentiert wird, die über die ganze Welt verstreut sind.

Wenn ein Autodiscover-Client versucht, die IP-Adresse des Hostnamens abzurufen - autodiscover.outlook.com, hängt die Antwort (die IP-Adresse + Hostname), die der Autodiscover-Client erhält, davon ab sein geografischer Standort.

Beispielsweise erhält ein Autodiscover-Client, der sich physisch in Europa befindet, genaue Informationen, die sich von dem Autodiscover-Client unterscheiden, der physisch in den USA ansässig ist.

Wir können eine Demonstration dieses Vorgangs mithilfe eines einfachen Ping-Befehls sehen.
Im folgenden Screenshot sehen wir das Ergebnis eines Ping-Befehls an den Host mit dem Namen - autodiscover.o365info. com

Die „Antwort“, die wir vom DNS-Server erhalten, verweist uns auf einen anderen Host mit dem Namen-
autodiscover-emeaeast.outlook.com

Falls Sie sich fragen, warum wir den Hostnamen
autodiscover-emeaeast.outlook.com anstelle des Hostnamens sehen, über den wir sprechen - autodiscover.outlook.com, die Antwort liegt wahrscheinlich daran, dass die DNS-Infrastruktur von Office 365 auf einem „GeoDNS“ basiert.

Bei Verwendung der GeoDNS-Option erkennt der DNS-Server die IP-Adresse des DNS-Clients und schließt daraus den geografischen Standort des DNS-Clients.

Basierend auf diesen Informationen stellen die DNS-Server eine Antwort (IP-Adresse und Hostname) bereit, die für den geografischen Standort des DNS-Clients geeignet ist.
In unserem Beispiel wird mein physischer Standort als „EMEA“ (Europa, Naher Osten usw.) betrachtet Afrika) und aus diesem Grund wird als Office 365 Autodiscover-Komponente ein Host verwendet, der sich physisch in EMEA befindet.

HTTP- und HTTPS-Umleitungsmethode

Eine zusätzliche Umleitungsmethode, die in der Office 365-Umgebung für AutoErmittlungsdienste implementiert ist, sind die Methoden - HTTP-Umleitung und HTTPS-Umleitung.

Im vorherigen Abschnitt haben wir erwähnt, dass der Autodiscover-Client, der den DNS-Server nach dem potenziellen Autodiscover-Endpunkt abfragt, zu einem anderen Hostnamen
(autodiscover.outlook.com).

Der Autodiscover-Client „glaubt“, dass dies das „Element“ sei, das ihm die erforderlichen Informationen liefern könnte, aber diese „Annahme“ ist falsch.

Wenn der Autodiscover-Client versucht, eine Verbindung zum Autodiscover-Endpunkt mit dem Namen autodiscover.outlook.com herzustellen, ist das Endergebnis eine zusätzliche Umleitung, die durch das HTTP-Protokoll zu < implementiert wird u>zusätzlicher Autodiscover-Endpunkt.

Wenn Sie glauben, dass dies das „Ende der Geschichte“ ist, werden Sie enttäuscht sein!
(Oder genauer gesagt, der Autodiscover-Client wird enttäuscht sein).

Nach der Phase der HTTP-Umleitung, wenn der Autodiscover-Client versucht, den „neuen Host“ (den potenziellen Autodiscover-Endpunkt) anzusprechen, ist das Ergebnis eine zusätzliche Umleitung, dieses Mal jedoch die Umleitung Die Methode basiert auf dem HTTPS-Protokoll.

Die Autodiscover-„Reise“ des Autodiscover-Clients in einer Office 365-Umgebung

Ich habe den Autodiscover-Workflow des Autodiscover-Clients in Office 365 als „Reise“ beschrieben, denn wie im Märchen, wo der Prinz viele Strapazen durchmacht, um die Prinzessin zu erreichen, muss auch der Autodiscover-Client viele Hürden überwinden.

Hinweis - Wir werden nicht näher auf die einzelnen „Schritte“ eingehen, die der Autodiscover-Client durchlaufen muss, da im nächsten Artikel der Autodiscover-Ablauf in einer Office 365-Umgebung | Teil 2#3 | In Teil 30#36 gehen wir jeden dieser Schritte gründlich durch.

Im folgenden Diagramm sehen wir eine „allgemeine Ansicht“ der „Elemente“, denen der Autodiscover-Client auf seinem Weg begegnen wird.

Ich muss den DNS-Server oben im Diagramm positionieren, da der Autodiscover-Client jedes Mal, wenn er zum „nächsten Hop“ umleitet, eine DNS-Abfrage erstellen muss, in der er nach der IP-Adresse des Hostnamens fragt, der angezeigt wird die Weiterleitungsnachricht.

Zusätzliche Überprüfung des Autodiscover-Prozesses in der Office 365-Umgebung

Der Prozess, bei dem der Autodiscover-Endpunkt „aufwächst“, um dem Autodiscover-Client die erforderlichen Informationen (die Autodiscover-Antwort) bereitzustellen, kann nur durchgeführt werden, wenn zwei Regeln angewendet werden:

Regel 1 - Gegenseitige Authentifizierung
Der Server muss dem Autodiscover-Client seine Identität nachweisen, damit der Autodiscover-Client sicher sein kann, dass der Server (Autodiscover-Endpunkt) eine „zuverlässige Informationsquelle“ ist.

Der Autodiscover-Client muss dem Autodiscover-Endpunkt seine Identität nachweisen, indem er seine Benutzeranmeldeinformationen bereitstellt.

Regel 2 - Sicherer Kommunikationskanal

Die Daten, die auf dem Kommunikationskanal zwischen dem Autodiscover-Endpunkt und dem Autodiscover-Client übertragen werden, müssen verschlüsselt werden.

Wir müssen über diese „zwingenden Regeln“ Bescheid wissen, um den „seltsamen Autodiscover-Ablauf“ in der Office 365-Umgebung verstehen zu können.

Im folgenden Abschnitt beantworte ich die Frage: „Was ist nötig, um eine so komplizierte Autodiscover-Infrastruktur in der Office 365-Umgebung zu implementieren?“

Phase 1

Wie bereits erwähnt, sucht der Autodiscover-Client in unserem Szenario nach einem Host mit dem Namen - autodiscover.o365info.com

Die Antwort des DNS liefert dem Autodiscover-Client die IP-Adresse des Hosts autodiscover.outlook.com

Der Autodiscover-Client versucht, mit diesem Host zu kommunizieren (über HTTPS).

Der Host - autodiscover.outlook.com - kann nicht über HTTPS kommunizieren, da er nicht der „echte“ Autodiscover-Endpunkt ist und über kein Serverzertifikat verfügt, das den Hostnamen enthält - autodiscover.o365info.com

Da der HTTPS-Kommunikationstest fehlschlägt, erstellt der Autodiscover-Client eine neue HTTP-Anfrage mit der Bitte um eine „Umleitung“ zum erforderlichen Autodiscover-Endpunkt, der die erforderlichen Autodiscover-Dienste mithilfe des HTTPS-Protokolls bereitstellen kann.

Die „HTTP-Umleitungsantwort“ von autodiscover.outlook.com
enthält den Namen des Autodiscover-Endpunkts mit dem Namen autodiscover-s.outlook. com

Phase 2

Der Autodiscover-Client versucht, den „neuen Autodiscover-Endpunkt“ (autodiscover-s.outlook.com) über das HTTPS-Protokoll zu kommunizieren.

Die gute Nachricht ist, dass der Host autodiscover.outlook.com über HTTPS kommunizieren kann, aber die weniger gute Nachricht ist, dass der Host autodiscover.outlook. Das öffentliche Zertifikat von com enthält eine „Autorisierung“ nur für Hostnamen, die zur Domäne „outlook.com“ gehören.

Der Autodiscover-Client erwartet, im Serverzertifikat den Hostnamen zu finden - autodiscover.o365info.com und diese Erwartung kann nicht erfüllt werden, da es in der Office 365-Umgebung keinen Mechanismus gibt, der dies bereitstellt ein dediziertes öffentliches Zertifikat für jeden öffentlichen Domänennamen des Office 365-Mandanten.

Jetzt haben wir also ein „Problem“.

Der Autodiscover-Client kann den Prozess nicht abschließen, da er den Hostnamen autodiscover.o365info.com nicht im Serverzertifikat finden kann und der Autodiscover-Prozess technisch gesehen fehlschlagen sollte.

Und die gute Nachricht ist, dass die Autodiscover-Methode einen „Trick“ namens -HTTPS-Umleitung hat.

Der Autodiscover-Endpunkt - autodiscover.outlook.com kann die Bedingungen des Autodiscover-Clients nicht erfüllen, aber weil der
autodiscover.outlook.com< Wenn /span> seine Identität nachweisen kann, indem er dem Client sein Zertifikat zur Verfügung stellt, kann der Autodiscover-Client dem Host
autodiscover.outlook.com „vertrauen“ und ihn als zuverlässig betrachten Informationsquelle.

Bei den Informationen, die autodiscover.outlook.com dem Autodiscover-Client bereitstellt, handelt es sich nicht um Autodiscover-Informationen (die Autodiscover-Konfigurationseinstellungen), sondern die Informationen umfassen stattdessen eine Umleitung zu einem zusätzlichen Autodiscover-Endpunkt.

Der „zusätzliche Autodiscover-Endpunkt“ ist der Exchange Online CAS-Server, der dem Autodiscover-Client die erforderlichen Autodiscover-Informationen bereitstellen kann.

In unserem speziellen Szenario enthalten die von autodiscover.outlook.com bereitgestellten Informationen (die XML-Umleitungsnachricht) den Namen des folgenden Hosts - pod5149.outlook.com

Hinweis: Der Name des Exchange Online CAS-Servers in unserem Szenario lautet - pod51049.outlook.com
Technisch gesehen kann und wird der Name basierend auf vielen Faktoren wie den Office 365-Rechenzentren geändert werden in dem der Office 365-Mandant gehostet wird, die verfügbaren Exchange Online CAS-Server usw.

Phase 3

Der Autodiscover-Client ist bereit, die Umleitungsinformationen zu akzeptieren und zu versuchen, mit dem Autodiscover-Endpunkt zu kommunizieren - pod51049.outlook.com

Die gute Nachricht ist, dass der Autodiscover-Prozess jetzt abgeschlossen werden kann.

Das öffentliche Zertifikat, das pod51049.outlook.com bereitstellt, ist ein Platzhalterzertifikat, das eine „Autorisierung“ für alle Hostnamen „unter“ der outlook.com Domainname.

Der Autodiscover-Client ruft das Zertifikat pod51049.outlook.com ab, überprüft, ob das Zertifikat von einer vertrauenswürdigen Zertifizierungsstelle bereitgestellt wurde, überprüft den Hostnamen oder den Domänennamen (in unserem Szenario outlook.com) erscheint im öffentlichen Zertifikat.

Dies ist ein „Zeichen“ für den Autodiscover-Client, dass er dem „Server“ nun sicher seine Identität übermitteln kann, indem er die Anmeldeinformationen des Office 365-Benutzers bereitstellt.

Nach Abschluss des gegenseitigen Authentifizierungsprozesses wird eine sichere Kommunikationsverbindung erstellt und der „Server“ (pod5149.outlook.com) stellt dem Autodiscover-Client die gewünschte autodiscover.xml bereit Datei.

Der nächste Artikel der aktuellen Artikelserie

AutoErmittlungsablauf in einer Office 365-Umgebung | Teil 2#3 | Teil 30#36