Azure AD Pass-through Authentication

Azure AD Pass-through Authentication erklärt

Azure AD Pass-through Authentication nachfolgend «PTA» genannt, war bereits im November/Dezember 2016 als Preview verfügbar und ist inzwischen fester Bestandteil der Azure AD Authentifizierungs-Mechanismen.

PTA ist eine echte Alternative zur Passwort-Hash-Synchronisation oder zum Active Directory Federation Service (ADFS). Es gibt einige triftige Gründe, um PTA einzusetzen:

• Mit PTA werden keine Passwort-Informationen auf dem Azure AD-Benutzer hinterlegt
• Der Einsatz von PTA ist kostenlos, es werden keine zusätzlichen Office 365- oder Azure-Lizenzen benötigt
• PTA kommt mit wenig Infrastruktur, respektive bescheidenen On-Premises Server-Ressourcen aus
• PTA kommuniziert vom internen LAN ins Azure AD, es muss kein Dienst ins Internet publiziert werden

PTA ist eine Software-Komponente, welche via Azure Active Directory Connect installiert oder via Azure AD-Portal als einzelnes Software-Paket heruntergeladen werden kann. Die Komponente kann auf einem beliebigen Windows Server (Windows Server 2012 R2 oder neuer) installiert werden.

Damit der Dienst ausfallsicher betrieben werden kann, sollten 2 – 3 Instanzen installiert werden (oder gar mehr Instanzen, sofern mehrere 10’000 authentifizierende Benutzer bedient werden müssen). PTA wählt automatisch eine verfügbare Instanz (oder Agent) aus, ein eigentliches LoadBalancing, über die installierten Instanzen, findet nicht statt. Die Konfiguration erfolgt über den Azure Active Directory Connect Konfigurations-Wizard, unter der Option «Sign-In-Options» kann PTA aktiviert werden.

Auf Stufe Office 365 muss sichergestellt werden, dass die Logon-Domains auf «managed» konfiguriert sind, was z.B. bei der Nutzung der Passwort Hash-Synchronisation standard ist.

Im Azure AD-Portal unter «Azure AD-Connect» kann der Status der installierten Azure AD Pass-through Authentication – Instanzen unter «User Sign In» geprüft werden.

Bei der Nutzung von PTA, erfolgt der Authentifizierungs-Prozess wie folgt:

1. Die Benutzer-Informationen werden in Azure verschlüsselt in eine Queue gestellt
2. Ein verfügbarer On-Premises-Agent holt die Benutzer-Informationen von derselben Queue ab
3. Die Benutzer-Informationen werden gegen das lokale Active Directory geprüft
4. Der PTA-Agent gibt die gewonnen Informationen aus dem lokalen Active Directory zurück ins Azure AD
5. Sofern implementiert, werden weitere Mechanismen wie MFA oder conditional Access aktiv

Hinweis: De Fakto verlässt das Passwort «ihr Netzwerk»  in denjenigen Fällen, in welchen Sie sich an Office 365 interaktiv authentifizieren (was auch mit PTA  inkl. Seamless SSO in seltenen Fällen vorkommen kann). Bei der Passwort-Eingabe wird das Passwort mit AES256 verschlüsselt und Online zwischengespeichert, so dass der Passwort Server dieses aus dem Netz herunterladen kann und gegen das lokale Active Directory verifizieren kann.

MS-Referenz: Migrating from Federated Authentication to Pass-through Authentication, Seite 8

Welche Rolle spielt Azure Active Directory Seamless Single Sign-On?

PTA selbst stellt für den Benutzer kein durchgängiges «Single-Sign-On-Experience» zur Verfügung. Dazu muss zusätzlich Azure Active Directory Seamless Single Sign-On – kurz «Seamless SSO» – implementiert werden. Dies erfolgt ebenfalls über den Konfigurations-Wizard von Azure Active Directory Connect.

• Seamless SSO funktioniert grundsätzlich nur auf Active Directory Domain-Joined Geräten
• Seamless SSO ermöglicht den Workplace-Join von Legacy Windows Clients (Non-Windows 10 oder Non-Windows Server 2016 Geräte) ohne ADFS einzusetzen

Damit Seamless SSO stets funktioniert, bzw. den Sicherheitsstandards entspricht, müssen zwei Dinge beachtet werden:

1. Damit die Kerberos-Tickets korrekt verarbeitet werden, müssen zwei Azure Authentifizierungs- Seiten zur lokalen IE Zone hinzugefügt werden – dies kann mittels folgender GPO erfasst werden:
   User ConfigurationPoliciesAdministrative TemplatesWindows ComponentsInternet ExplorerInternet Control PanelSecurity Page / Site to Zone Assignment List / Enabled:
   Value Name: https://autologon.microsoftazuread-sso.com Value: 1
   Value Name: https://aadg.windows.net.nsatc.net Value: 1
2. Der Kerberos Decryption Key auf dem durch das von Seamless SSO erstellten Computer-Objekt «AZUREADSSOACC» sollte aus sicherheitstechnischen Gründen alle 30 Tag aktualisiert werden ->  «Kerberos decryption key rollover».  Leider muss diese Aktualisierung bis dato von Hand gemacht werden. Jedoch stellt ein kürzlicher Post vom Azure AD Team die automatisierte Variante des «Kerberos decryption key rollover» für den Sommer 2019 in Aussicht. Wird der Key nicht aktualisiert, funktioniert Seamless SSO zwar nach wie vor, aber Im Azure AD-Portal unter «Azure AD-Connect» unter «User Sign-In» wird auf dem Feature «Seamless Signle Sign-On» eben nach diesen 30 Tagen eine entsprechende Warnung angezeigt.

ADFS vs. PTA

• Genutzte Applikationen unterstützen «Modern Authentication» nicht:
  • Legacy Applikationen werden genutzt, z.B. der «alte» Lync-Client
  • Eine Legacy Protokoll Applikation wie z.B. PowerShell Version 1.0 wird genutzt
• Es kommt eine 3rd Party On-Premises Multifactor Authentication Lösung zum Einsatz
• Es werden Smart-Cards zur Authentifizierung genutzt
• Single Sign-On soll so weit gehen, dass keine Anmelde-Dialoge erscheinen und die Anmelde-Informationen zwischen allen Applikationen automatisch übergeben werden, also auch zwischen Office 365-Applikationen und anderen integrierten 3rd Party-Applikationen wie z.B. Salesforce, Box, Dropbox, u.v.a.
• Password Ablauf-Meldung müssen unter Windows 10 im Office 365 Portal angezeigt werden

Fazit

Aufgrund der gemachten Erfahrungen bei Kunden, kommen wir mehr und mehr von den teils aufwendigen und mühseligen ADFS-Implementationen weg und empfehlen PTA mit Seamless SSO. Die vorangehenden aufgelisteten Umstände, welche für ADFS sprechen, entfallen in einer Umgebung, welche auf die Nutzung der modernen und aktuellen Microsoft Dienste und Applikationen setzt.

Letzten Endes soll das bewährte ADFS nicht etwa als «überflüssig» dargestellt werden, sondern es soll bei der Evaluation der «Sign-In-Methode» schlicht sorgfältig analysiert werden, welche Variante die aktuellen Anforderungen am besten abdeckt und verhältnismässig in Sachen Kosten und Komplexität daherkommt. Oder anders formuliert: wer sich den Rolls Royce mit allem Komfort leisten kann, ist mit ADFS nach wie vor am besten bedient.