Office 365 - ADFS Anmeldung

Wer sich per ADFS an einem Dienst anmeldet, wird im Browser einige URL-Sprünge sehen. In Outlook, Lync und der PowerShell erfolgt das unter der Haube. Trotzdem müssen sie wissen, was da passiert, wenn Fehler analysiert werden sollen. Hier also der Ablauf einiger Anmeldevorgänge.

Genereller Ablauf

Eine ADFS-Umgebung mit Office 365 besteht aus einem internen Active Directory mit ADFS-Service, einem ADFS-Proxy für die sichere Veröffentlichung und natürlich dem Service in der Cloud und internen und externen Clients.

Die nun folgenden Funktionsabläufe sind vereinfacht dargestellt. So holt sich ein Client beim ersten Zugriff auf ADFS von Extern natürlich die Anmeldeseite und auch jede Menge weitere Dateien (Bilder, JavaScript, CSS). Diese GET-Anfragen und die 200OK-Antworten sind nicht gesondert abgebildet.

Funktionsablauf Outlook WebApp

Am Beispiel einer Office 365 Anmeldung mit ADFS und DirSync lässt sich gut erkennen, wann ADFS ins Spiel kommt: Ein Outlook Client macht erst einmal eine ganz normale "Autodiscover"-Anfragen, über die er beim Office 365 CAS-Server landet. Dieser lehnt die Anmeldung natürlich erst mal ab und verweist den Client zum ADFS-Server.

Der Client geht dann zum ADFS-Server, meldet sich an und bekommt ein Ticket. Das sind natürlich mehr als nur eine Anfrage. HTTP-typisch versucht der Client es auch erst einmal "anonym" am ADFS-Server, bekommt einen 401 mit den dort möglichen Anmeldeinformationen und speziell bei NTLM schlägt auch noch der zweite Versuch fehlt.

Mit dem ADFS-Ticket geht der Client dann wieder zurück zum Office 365 Server, der dann den Zugriff gewährt, weil beim der Einrichtung des ADFS-Servers der ADFS-Schlüssel in die Office 365-Cloud hochgeladen wurde.

Funktionsablauf Outlook (MAPI/HTTP)

Die Anmeldung für Outlook erfolgt allerdings etwas anders. Ursache ist hier die aktuell fehlende Möglichkeit den Client auf ein ADFS-Ticket zu trimmen. Statt dessen macht die Office 365 "on behalf".

Das Bild ist noch nicht abschließend verifiziert. Zudem habe ich den internen Zwischenschritt noch nicht addiert, bei dem Exchange Online intern nach der ADFS-URL fragt.

Debugging mit "Remote Connectivity Analyzer "

Wenn Millionen Anwender und Administratoren auf Office 365 arbeiten sollen, dann ist ein Anbieter gut beraten, möglichst viel als "Self-Service" anzubieten, denn Telefonsupport erfordert Personen und kostet Geld. Entsprechend gibt es von Microsoft auch eine eigene Webseite

https://www.testconnectivity.microsoft.com/?testid=SingleSignOn

Damit lassen Sie schon sehr schön die häufigsten Fehler analyiseren.

Microsoft Office 365: Identity and Access Solutions
http://channel9.msdn.com/Events/TechEd/NorthAmerica/2011/OSP215

Debugging mit Fiddler

Diese verschiedenen Zugriffe können Sie auf dem Client mit dem Programm Fiddler untersuchen. Auf dem ADFS-Server können Sie auch FREB (Siehe IISDebugging) arbeiten. Nur die Zugriffe und Anfragen auf die Office 365 Server können Sie in der Regel nur auf dem Client analysieren, da diese SSL-verschlüsselt sind und sie keinen Zugriff auf den Server haben.

Hier ein Fiddler-Trace des Clients zum internen ADFS-Server. Paket 2-19 zeigt die Anmeldung und 21-.40 die Abmeldung. Zwischendrin sehen Sie am Hostnamen, dass der Clients sich per ADFS am Office 365 Portal angemeldet hat.

Hier sehen Sie den "GET" auf den ADFS-Server mit einem Authentication-Header mit der Antwort.

Sie sehen, dass hier eine ganze Menge Cookies gesetzt werden, die der Client bei der nächsten Anfrage zu Office 365 mit sendet und sich damit ausweist.

Weitere Links