Pass-Through Authentifizierung (PTA)

Benutzer müssen für den Zugriff auf Dienste in Office 365 authentifiziert werden. AADConnect kann die Identitäten in der Cloud anhand eines lokalen AD verwalten und wenn sie keine Kennworte in die Cloud synchronisieren wollen oder ein Single-SignOn gefordert ist, dann war ADFS der Weg zum Ziel.

Die PassThrough-Autentifizierung ist ein weiteres Anmeldeverfahren neben der ADFS, KennwortSync oder Seamless SSO. Diese Lösung ist insbesondere für kleinere und mittlere Firmen eine interessante Option.

Was ist PTA?

Die Anmeldung mittels PTA erfolgt ganz anders als sie es von ADFS oder Seamless SSO gewohnt sind. Mit ADFS leitet Sie die Cloud zu einem ADFS-Server weiter, der sie dann anmelden und ein Ticket ausstellt um verschiedenste Dienste zu nutzen.

Bei Seamless SSO sendet ihr interne Client ein kerberos-Ticket zu Office 365 und authentifiziert sich damit. Bei PTA erfragt die Cloud ihre Anmeldedaten und stellt diese in eine "Warteschlange".

Auf ihrem OnPremise-System werden vorab aber Agenten installiert, die sie aus ihrem Netzwerk mit Office 365 verbinden und dort diese "Anmeldewarteschlange" abarbeiten. Die Agenten finden dort die offenen Anmeldungen mit dem Kennwort als Hashwert. Der Agent prüft die Daten gegen das lokale Active Directory und meldet dann den Erfolg oder Misserfolg and Office 365 zurück.

Wie funktioniert PTA

Microsoft hat aus meiner Sicht das Verfahren schon sehr ausführlich auf folgender Webseite beschrieben, so dass ich bis auf weiteres nicht weiter auf die Details hier eingehen werden:

Allerdings müssen Sie ihre Kennwort an die Cloud senden, welche dann die Validierung über ihre OnPremise-Umgebung ausführen lässt. Im Gegensatz zu ADFS oder Seamless SSO muss der Anwender sein Kennwort eingeben (Same Login aber kein Single Login)

Einrichtung

Die Nutzung von Pass-Through Authentifizierung wird schon beim Setup von AADConnect konfiguriert. Microsoft hat das sehr umfangreich mit Bildern auf folgender Seite beschrieben.

Wenn Sie AADConnect aber schon installiert haben, dann müssen sie die Option "Change User Sign-in" aufrufen:

Im folgenden Fenster können Sie dann eine der von AADConnect angebotenen Anmeldeoptionen auswählen

Die Warnung sollten Sie ernst nehmen, dass das Admin-Konto besser ein "Cloud Only"-Konto ist und nicht im Rahmen des DirSync provisioniert wird.

Ich habe hier bei meinem Test-Tenant von dem vormals konfigurierten "Password Synchronization" nun auf Pass-through authentication umgestellt. Zudem kann man mitterlweile auch ein "Enable Single-Sign-on" aktivieren. Dazu muss man aber einmal die Anmeldedaten eines Administrators zur Konfiguration eingeben.

Eine Zusammenfassung zeigt an, was als nächstes getan wird.

Kontrolle

Bei der Beschreibung, wie PTA funktioniert, haben sie von einem neuen Computerkonto gelesen. Wenn ihr interner Client auf eine gewisse URL zugreift, dann muss die andere Seite auch "Kerberos" als Authentifizierungsverfahren anbieten, damit ihre Client überhaupt den lokalen KDC nach einem Ticket fragt. Der lokale KDC muss dann im Active Directory ein passendes Objekt suchen, dessen ServicePrincipalName auf die geforderte Ressource passt, damit er ein Ticket hierfür ausstellen kann.

Entsprechend muss es in ihrem lokalen Active Directory auch ein Objekt mit dem passenden SPN geben, welches Sie einfach per Active Directory Benutzer und Computern suchen können. Tipp: Der Name ist immer AZUREADSSOACC. Die Kurzform von Azure AD SingleSignOnAccount.

In den Eigenschaften ist insbesondere das Feld "ServicePrincipalName" interessant.

Hier tauchen also gar nicht alle Office 365 URLs auf, sondern "nur" die Services, die die Authentifizierung des Anwenders übernehmen und dann ein Office 365 Ticket für die weiteren Dienste ausstellen. Damit das funktioniert, müssen Sie im Browser natürlich diese Adressen als "Intranet" addieren oder in einer Zone betreiben, in der eine Anmeldung per Kerberos möglich ist.

Die Zonen stellen sie natürlich am besten per Gruppenrichtlinien ein.

Umgekehrt ist nun aber auch klar, dass Clients ohne entsprechende Unterstützung diese Art der Anmeldung gar nicht anbieten können. Dazu zählt als auch ein mobiler Client, private Computer, die nicht in der Domäne sind, Domänenmitglieder, die aber von unterwegs keine Verbindung zu einem KDC haben. Insofern sind VPN, AutoVPN oder auch Direct Access hier zu beachten. Da ein interner KDC in der Regel keine gesonderte Authentifizierung erfordert, weil der Anwender ja schon am Client selbst angemeldet ist, gibt es auch keine direkte Unterstützung für einen zweiten Faktor, d.h. eine starke Authentifizierung ist Aufgabe des Client Betriebssystems.

Anmeldung testen

Um die Funktion zu testen muss ist also einen Client nutzen, der in der Domäne ist und an dem der Benutzer angemeldet ist, der auch auf Office 365 zugreifen will. Mit den richtigen Zoneneinstellungen sollte der Client dann die Office 365 Web-Dienste ansprechen und passenden zu den Hosts auch ein Kerberos-Ticket von internen KDC anfordern, weiterreichen und authentifiziert sein. Aktuell funktioniert das wohl mit allen Clients, die "Modern Authentication" unterstützen. Ausgerechnet der Edge ist hier noch nicht dabei:

Ich habe also den Internet Explorer auf einem Windows 10 System gestartet, der Mitglied der Domäne ist. Beim Zugriff auf portal.office365.com wurde ich natürlich nach dem Usernamen gefragt. Diese erste Eingabe muss ich im Browser wohl noch machen. Ich habe aber das Kennwort "leer" gelassen und einfach Anmelden geklickt.

Im Fiddler-Trace ist dann das Paket 46 interessant. Hier lehnt Office 365 die Anmeldung mit einem 401 ab aber liefert mir "Negotiate" als mögliches Anmeldeverfahren:

Das ist für den Client natürlich das Startsignal, sich von dem lokalen KDC ein Ticket zu besorgen, wenn die URL in der richtigen Intranet-Zone aufgenommen wurde. Die Abfrage des Kerberos-Tickets könnten Sie mit WireShark mitschneiden aber mir reicht auch das folgende Pakete 47, welches die gleiche URL anspricht und diesmal ein Kerberos-Ticket mitliefert:

Nach der erfolgreichen Anmeldung wird von dem Authentifizierungsserver natürlich ein Token erstellt, welches dann vom Browser zukünftig weiter verwendet wird. Das sind dann die Pakete 48 und folgende, bis bei 61 der eigentliche Zugriff auf OWA erfolgt.

Wenn der Client aber kein Kerberos-Ticket bekommt, z.B. weil Sie das Konto gar nicht korrekt angelegt oder wieder gelöscht haben oder der Client außerhalb ihres Netzwerks sich befindet und den KDC daher nicht erreichen kann oder der Client unterstützt Kerberos nicht, dann bleibt weiterhin die Anmeldung mit Benutzername und Kennwort. Das ganze funktioniert sogar mit Multi Faktor Authentifizierung. Ich erspare dem Anwender also einfach die Eingabe des Kennwort, wenn er auf einem internem PC arbeitet und kein ADFS hat.

Gegenrichtung: Azure AD Application Proxy Connector

Ich habe natürlich auch lokal auf meinem AADSync-Service geschaut, was sich dort getan hat. Denn ursprünglich bin ich davon ausgegangen, dass ein interner Dienst eine Verbindung zu Office 365 aufrecht erhält und ähnlich wie "ActiveSync Push" die Cloud damit einen lokalen Dienst anweist, doch bitte die Authentifizierung zu übernehmen. Dem ist auch so, denn auf meinem System gibt es seit der Installation zwei neue Dienste:

Allerdings funktioniert zumindest bei mir die Anmeldung auch, wenn die beiden Dienste gestoppt sind. Anscheinend sind die Dienste nicht für alle Fälle erforderlich. Da die Anmeldung per Kerbreros möglich ist, gäbe es auch keinen Grund für einen Rückkanal. Allerdings gibt es schon eine "Management-Komponente", d.h. das lokale Computerkonto AzureadSSOACC muss ja mit der Cloud abgeglichen werden, damit der PublicKey dsa lokalen Objekts mit dem Private-Key der Cloud übereinstimmt.

So finden Sie einige Performance Counter:

Interessanterweise ist bei mir doch ein Counter hochgezählt worden, als ich mich an Office 365 angemeldet habe.

Es scheint also doch nicht "nur" ein bisschen Kerberos zu sein, sondern ein OnPremise-Dienst hält Kontakt mit der Cloud um Authentifizierungsanfragen durchzuführen. Auch im Eventlog ist die Aktion sichtbar:

Hier muss ich bei Gelegenheit noch einmal genauer nachschauen, was diese Dienste nun wirklich in der finalen Version tun.

Azure AD Application Proxy Connector Download
https://download.msappproxy.net/subscription/d3c8b69d-6bf7-42be-a529-3fe9c2e70c90/connector/download 

Einschätzung

Mit der "Pass Through Authentifizierung", die im Jun 2017 noch als "Preview" läuft, wird es wohl auch für all die mittleren und kleinen Firmen eine Option zum "SignleSignOn" geben, die den Aufwand für einen ADFs-Server scheuen oder nicht rechtfertigen können aber ein kompletter Kennwort-Sync mit ADFS in Office 365 (AzureADPremim) ebenfalls nicht mögen. Durch den Trick einer Anmeldung per "Negotiate" mit Kerberos zu wenigen ausgewählten Systemen wird auch kein Kennwort mehr übertragen oder in der Cloud benötigt.

Ich gehe davon aus, dass diese elegante und bequemen Anmeldung für all diese Firmen zukünftig zum Standard wird. Die Einrichtung ist auch sehr schnell erfolgt, da neben einer Checkbox bei der Installation von AADConnect nur noch die Zoneneinstellungen des Internet Explorer anzupassen sind.

Weitere Links