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-Authentifizierung ist ein weiteres Anmeldeverfahren neben der ADFS, Office 365 Password Sync oder Seamless Single Sign On. Diese Lösung ist insbesondere für kleinere und mittlere Firmen eine interessante Option.

Beachten Sie auch die Einschränkungen
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-current-limitations

Achtung: TLS 1.2 PTA-Agenten bis 30.3.2021 erforderlich!
MC246440 Upgrade AADConnect server before TLS 1.0/1.1 retirement for Azure AD
Mindestversion 1.4.38.0 vom 9.12.2019
TLS 1.2 Enforcement
TLS 1.2 enforcement for Azure AD Connect https://docs.microsoft.com/en-us/azure/active-directory/hybrid/reference-connect-tls-enforcement
Azure Active Directory TLS 1.0, TLS 1.1, and 3DES deprecation https://docs.microsoft.com/en-us/azure/active-directory/fundamentals/whats-new#november-2020

Multi Forest Szenario
Mit ADFS können Sie pro UPN-Domain einen anderen ADFS-Service angeben. Das geht mit PTA vermutlich nicht, so dass der Agent einen User in einem anderen Forest wenn überhaupt dann nur nur per Forest Trust authentifizieren kann. Prüfen Sie vorab, wie MultiForest abgedeckt wird.

Ignite 2018: BRK3145 Deploying Outlook mobile securely in the enterprise
https://youtu.be/dt5GomXuqhI?t=552 
Our preferred identity model is a synchronized identity model, where you are using password hash syncronization or passthrough authentication with an AADConnect. But we do support federated identity...

Migrate from federation to cloud authentication
https://docs.microsoft.com/en-us/azure/active-directory/hybrid/migrate-from-federation-to-cloud-authentication
Microsoft hat mittlerweile ein richtig gutes Video samt Beschreibung veröffentlicht

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 On-Prem-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 an Office 365 zurück.

Argumente für PTA

Mit dem Einsatz von PTA anstelle von PasswordHashSync etc. gibt es einige essentielle Unterschiede.

  • Kennwortänderungen sind sofort aktiv
    Anders als mit PasswordHashSync muss der Anwender nicht auf die Replikation durch AADConnect warten
  • Anmeldezeitbeschränkung wirkt.
    Wenn der Anwender sich nur zu bestimmten Zeiten anmelden darf, dann gilt dies nun auch für Office 365
  • Konto-Deaktivierung/Sperrung
    Wenn das Konto durch einen Administrator oder zu viele Fehlerversuche lokal geblockt ist, dann kann sich der Anwender auch nicht mehr an Office 365 anmelden
  • Entfall von KennwortHashSync ohne ADFS
    Bislang hatten Kunde nur die Wahl zwischen losgelösten Kennworten in der Cloud, per PasswordHashSync übertragene Hashwerte und ADFS. Mit PTA müssen sie keine Kennworte in die Cloud übertragen, wenn Sie dies nicht möchten oder nicht dürfen. Die Authentifizierung übernimmt das lokale AD über den PTA-Agent.

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 On-Prem-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.

Azure AD Application Proxy Connector

Ich habe natürlich auch lokal auf meinem ADSync-Service geschaut, was sich dort getan hat. Auf meinem System gibt es seit der Installation zwei neue Dienste:

Der zweite Dienst steuert die Updates des ersten Service. Der erste Service verbindet sich per HTTPS mit der Cloud um die "Authentifizierungswarteschlage" abzuarbeiten.

Hinweis: Ein solcher Dienst ist aus Verfügbarkeitsüberlegungen nicht genug. Sie können bis zu 12 Agenten installieren, wobei durchaus 300.000 Anmeldungen/Sek bedienen kann. Also sollten sie mit 2-3 Agenten locker hinkommen.
https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication-faq#how-many-pass-through-authentication-agents-should-i-install

Ob er das tut, können Sie z.B. über Performance Counter prüfen.

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 On-Prem-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 

Weitere Agenten installieren

In der Regel werden die Helpdesk-Tickets sehr schnell ansteigen, wenn sich die Anwender gar nicht mehr anmelden können. AADConnect installiert erst mal "nur einen Agenten". Aber sie können, und sollten, mehrere Agenten installieren. Ein Agent könnte wohl bis zu 300.000-400.000 Anmeldungen pro Sekunde bearbeiten. Wichtiger ist hier aber die Verfügbarkeit. Daher sollten Sie On-Premises nicht nur zwei oder mehr Domain Controller betreiben sondern entsprechend auch mehrere PTA Agenden installieren.

Den Agenten können Sie im Azure Portal oder über folgenden direkten Link herunter laden:

Authentication Agent software
https://aka.ms/getauthagent

Dazu gibt es natürlich noch eine Lizenzvereinbarung

Mindestvoraussetzung war im Jan 2019 noch Windows 2012 R2 der höher als Server.

Hochverfügbarkeit und Monitoring

Aber auch mehrere Agenten sind kein Garant, dass die Anmeldung immer funktioniert. Sie müssen einen ausgefallenen Agenten natürlich auch erkennen. Der erste Blick gilt hier dem AzureAD Status.

Hier sehen Sie das Bild, als ich noch einen PTA-Agenten installiert hatte. Er war aktiv aber aus Sicht von Microsoft zumindest "gelb".

In production environments, we recommend that you have a minimum of 3 Authentication Agents running on your tenant. There is a system limit of 40 Authentication Agents per tenant. And as best practice, treat all servers running Authentication Agents as Tier 0 s
Quelle: Azure Active Directory Pass-through Authentication: Quick start  https://docs.microsoft.com/en-us/azure/active-directory/hybrid/how-to-connect-pta-quick-start

Mit einem Klick auf den Link "Pass-through authentication" sehen Sie dann eine Übersicht der Agenten mitsamt ihrer IP-Adresse, wie Sie bei Office 365 erkannt wird:

Leider habe ich bislang noch nicht herausgefunden, mit welchem PowerShell-Befehl oder per Graph ich diesen Status auch mit eigenen Lösungen abfragen kann.

Natürlich sind auch das Windows Eventlog und die Performance Counter auf den PTA-Servern eine wichtige Quelle zur Funktionsüberwachung. Zudem gibt es noch zwei Logdateien

  • Protokolle der Installation: %ProgramData%\AADConnect\trace-*.log
  • Detaillierte Logs zur Authentifizierung %ProgramData%\Microsoft\Azure AD Connect Authentication Agent\Trace\.

Wechsel von ADFS

Siehe dazu die Seite ADFS zu PHS/SSO

PTA Rückbau

So einfach wie PTA eingerichtet wird, können Sie PTA auch wieder zurückbauen. Zuerst nutzen Sie einfach das ADSync-Setup, um das Anmeldeverfahren für ihren Tenant auf PHS oder Federation umzustellen und durchlaufen alle Schritte. Danach sollten Sie im AzureAD sehen, dass PTA deaktiviert wurde:

Eventuell tauchen bei ihnen hier aber noch die bisher genutzten Agenten auf. Diese werden auf dem ADSync-Server, auf dem Sie die Konfigurationsänderung durchgeführt haben, dabei deinstalliert. Aber sie können ja auch ohne ADSync auf weiteren Servern weitere PTA-Agenten installiert haben. Diese Agenten werden weitere Stunden versuchen, die Verbindung zu EntraID aufrecht zu erhalten aber irgendwann erkennen, dass PTA deaktiviert wurde und auch nicht mehr reaktiviert wird und sich dann selbständig deinstallieren.

Sie können den PTA-Agent natürlich auch über die Systemsteuerung deinstallieren. Das sollten sie aber nur tun, wenn Sie PTA auch im Tenant deaktiviert haben oder ein anderer PTA-Agent die Anmeldedienste bereitstellt. Zudem sollten Sie dann nicht nur den Agent, sondern auch den Agent Updater Service entfernen. Der Eintrag im AzureAD selbst sollten nach ca. 10 Tagen verschwinden

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 die Anmeldung in der Cloud in eine Warteschlange zu legen und ein lokaler Agent übernimmt die Verifikation, umgehen Sie die Ablage eines Kennworts in der Cloud.

Das ist pfiffig und einfach und man kann auf den ADFS-Server verzichten. Allerdings ist es kein "SingleSignOn", da man seine Kennwortdaten weiterhin eingeben muss. Dies lässt sich aber in Kombination mit der Seamless Single Sign On-Lösung zumindest für interne Clients erreichen.

Weitere Links