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. Seit Anfang 2017 gibt es mit der Pat    h-Through Authentifizierung aber einen weiteren Weg zur Anmeldung an der Cloud. Diese Lösung ist insbesondere für kleinere und mittlere Firmen eine interessante Option.

Was ist PTA?

Wer heute Office 365 nutzt und lokal ein Active Directory hat, ist fast immer gut damit beraten, den AADConnect-Prozess zu installieren und laufen zu lassen. AADConnect kann problemlos auch auf einem Domain Controller mit installiert werden, liest die lokalen Identitäten aus und führt die entsprechenden Identitäten in der Cloud nach. Nur für die Anmeldung war AADConnect bislang nicht nutzbar. AADConnect kann aber schon länger Hashwerte von Kennworten in die Cloud replizieren, so dass Anwender in Office 365 die gleichen Zugangsdaten verwenden konnten. Damit erreichen Sie aber nur einen "Same SignOn" aber kein "SingleSignOn (SSO)", da der Anwender immer wieder ein Kennwort eingeben muss. Die fortgeschrittene Variante ist die Bereitstellung von ADFS zur Anmeldung per SAML-Token. Nur jeder kann und will aber einen ADFS-Server samt ADFS-Proxy, statischer IP-Adresse, öffentlichem Zertifikat und Veröffentlichung im Internet installieren.

PTA verbessert dieses Verhalten nun zumindest für "Domain Joined" Clients, die Zugriff auf den das Kerberos Distribution Center (KDC) haben. Das gilt also für alle internen PCs, wobei VPN User und DirectAccess-Clients auch dazu gehören. Die Cloud bietet ihnen nämlich als Authentifizierungsverfahren nun auch "Negotiate" an und wenn ihr internes Setup korrekt ist, dann bekommt der Anwender automatisch ein Ticket und meldet sich an der Cloud an.

Die Funktion ist seit AADConnect Dezember 2016 (Version 1.1.371.0) vorhanden und muss auf Windows 2012R23 oder höher installiert sein.

Wie funktioniert PTA

Eigentlich ganz einfach und ich frage mich, warum Microsoft das nicht schon früher so umgesetzt hat. Wenn ein interner Client auf einem internen WebServer zugreift und der WebServer einen "401 Auth required" liefert, dann liefert der Webserver auch die Authentifizierungsverfahren mit, die der WebServer unterstützt. Intern ist man gut beraten, wenn Sie NTLM und Kerberos unterstützen, damit die Anwender nicht immer wieder nach ihren Anmeldedaten gefragt werden.

Im "Internet" funktioniert diese Art der Anmeldung in der Regel aber nicht, denn WebServer eines Anbieters werden kaum ein KerberosTicket ihres internen KDC decodieren können. Sie sind ja nicht in ihrer Domäne und haben auch kein Computerkonto. Zudem sind die DNS-Namen des Ziels in einer ganz anderen DNS-Domäne und jeder Browser betrachtet diese Hosts als "Internet". In der Zone ist "integrierte Authentifizierung" natürlich abgeschaltet. Das wäre ja noch zu schön, wenn eine böse WebSeite ihnen einen NTLM-Hash V1 entlocken könnte und damit per Brute-Force ein Kennwort ermitteln kann, welches zu dem Hash führt und damit auch für andere Dienste gültig wäre.

Aber genau dieses "geht nicht" wird von Microsoft mit Office 365 doch möglich gemacht. Dazu passiert im wesentlichen folgendes:

  • Client im AD mit Zugriff zum DC
    Der Anwender muss natürlich auf einem PC arbeiten, der in der Domäne Mitglied ist und beim Einsatz auch mit dem KDC sprechen kann. Ein PC in einem anderen "unvertrauten" Forest oder Domain oder ihre HomeOffice Client kann kein PTA nutzen
  • Passender Browser
    Im wesentlichen geht es erst mal um Browser und auch hier hängt es schon etwas vom Windows Betriebssystem und dem verwendeten Browser ab. Windows 7-10 mit IE, Chrome, Firefox sollten funktionieren. MacOS-User müssen noch etwas nachkonfigurieren und der Edge Browser ist auch außen vor.
  • Computerkonto im AD
    Das Setup legt einen Computer mit dem Namen "AZUREADSSOACCT" an, und verpasst ihm einige SPNs. Damit können die Clients beim Zugriff auf die Office 365 URLs um ein Kerberos Ticket gebeten werden und finden dieses Computerkonto, dessen private Schlüssel durch AADConnect in die Cloud synchronisiert wird. So kann der Client mit dem enthaltenen Ticket den Clouddienst ansprechen der die Gültigkeit des Tickets auch prüfen kann.
  • Service Endpunkte sind in der Browser "Intranet"-Zone
    Das ist natürlich knifflig, wenn Sie auf einem PC mehrere Office 365 Tenants ansprechen. Jedes Mal wird dann der Client "versuchen" ein Kerberos-Ticket zu bekommen bzw. sich mit ihrem aktuellen Benutzernamen anmelden wollen. Tipp: "Private Mode" der Browser nutzen, welche zugleich auch die automatische Anmeldung unterdrücken.

Von den anderen Single Sign On (SSO) können sie neben PTA aber nur noch den PasswordSync gleichzeitig nutzen. Ein Parallelbetrieb mit ADFS ist nicht möglich.

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 Auth" 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 KennwortSync 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