SSO zwischen Active Directory und der Microsoft-Cloud mit Pass-through-Authentifizierung (PTA) einrichten

Realisiert wird das oftmals durch eine relativ wartungsintensive AD FS-Infrastruktur. PTA bietet hier eine einfache Alternative, die sich on-prem mit einer schmalen Agenten-Installation begnügt.

Vorteile durch den Einsatz von PTA

Welche Vorteile bietet uns PTA somit im Vergleich zu anderen Technologien wie den Active Directory Federation Services (AD FS) oder der Password-Hash-Synchronisation? Einige Beispiele helfen bei der Einordnung:

• Die Pass-through Authentifizierung lässt sich einfach über Azure AD Connect konfigurieren (Sign-in Method).
• Die PTA-Agenten sind kompakt und können auf mehreren Windows-Servern zusammen hochverfügbar installiert werden (nicht mehrere Agenten auf einem Server).
• Die Agenten kommunizieren nur ausgehend über den TCP Port 443 (HTTPS requests für Feature operations) und Port 80 (HTTP requests für den Download von CRLs) mit dem Azure Active Directory. Weitere Firewall-Anpassungen entfallen, da Port 80 und 443 ausgehend meistens bereits allowed sind.
• Eine Platzierung in einer DMZ ist nicht erforderlich.
• PTA erfordert keinen Passwort-Hash-Transfer in die Public-Cloud, weil die Authenti­fizierung on-prem gegen das Active Directory erfolgt.
• Compliance des Unternehmens kann erfüllt werden.
• Ist das Anmeldekonto im AD gesperrt, dann kann sich der User auch nicht mehr bei M365 anmelden.
• Passwort­­änderungen greifen sofort, es muss kein Replikations-Fenster (2 Minuten) abgewartet werden.
• Die Pass-through Authentifizierung arbeitet zusammen mit Azure AD Multi-Factor Authentication und Conditional Access Policies.
• Self-Service Password Reset (SSPR) in der Cloud ist möglich (Password writeback).

Funktionsweise von PTA

1. In meinem Beispiel öffnet ein neuer User seine Cloud-Applikation
2. Die Anfrage wird an Azure AD geroutet (Azure AD Security Token Service antwortet) und der User gibt seine Credentials für den Log-in ein.
3. Das Passwort wird mit dem Public Key des PTA-Agenten verschlüsselt (dieser wird in Azure SQL für jeden registrierten Agenten gesichert). Das verschlüsselte Passwort bleibt in der Service-Bus-Queue, bis der PTA Agent (dauerhaft mit der Queue verbunden) dieses erhält. Im Gegensatz zu AD FS ermittelt die Cloud ihre Anmeldedaten und verarbeitet diese in einer Warteschlange.
4. Der PTA-Agent erhält den Benutzernamen und das verschlüsselte Passwort durch eine ausgehende Verbindung.
5. Der Agent auf dem on-prem-System arbeitet diese Anmelde­warte­schlange ab und entschlüsselt das Passwort mit seinem Private Key.
6. Danach werden die Credentials mithilfe der Win32 LogonUser API gegen die on-prem AD DS validiert.
7. Active Directory überprüft die Anfrage und quittiert sie mit erfolgreich, fehlerhaft, Passwort abgelaufen, Konto gesperrt oder Credentials falsch.
8. Der PTA-Agent leitet diese Antwort wieder zum Azure AD weiter.
9. Hier findet eine Bewertung statt, ob dieses Ergebnis mit der Log-in-Anforderung in Zusammenhang steht
10. Fällt diese positiv aus, kann der User auf die Applikation zugreifen.

Hinweis: Agenten kommunizieren nicht untereinander, sondern nur mit der Public-Cloud. Es findet keine Abstimmung und auch kein Load-Balancing beim Einsatz mehrerer Agenten statt. Die Windows Server für PTA-Agenten sollten gehärtet sein.

Konfiguration der Pass-through Authentication

Wie bereits erwähnt, lässt sich eine PTA über ein bereits installiertes Azure Active Directory Connect (AAD Connect) zügig konfigurieren. Über den Punkt Change user sign-in führt der Wizard durch die notwendigen Schritte.

Zu Beginn muss ich mich wie gewohnt über meinen globalen Administrator (Cloud only Account) mit Azure AD verbinden.

Danach kann man schon die Anmeldeoption Pass-through authentication über den entsprechenden Radio-Button auswählen. Zusätzlich ist die Checkbox für das Single sign-on bereits aktiviert.

Entscheidet man sich für das Single-Sign-on, dann müssen die Anmeldedaten des lokalen Domain Admin einmal verifiziert werden.

Die Konfiguration für PTA ist damit bereits erledigt. In meinem Fall ist die Password-Hash-Synchronisation noch zusätzlich aktiv (Backup) und kann später bei Bedarf ausgeschaltet werden.

Ist die Konfiguration bestätigt, wird automatisch der AAD Connect PTA-Agent installiert. Dieser lässt sich zusätzlich aus dem Azure Portal laden und manuell einrichten. Weitere Windows Server, Core werden nicht unterstützt, können dann mit einem heruntergeladenen Agenten versorgt werden.

Jetzt sind zwei zusätzliche on-prem-Services vorhanden, einmal der Azure AD Connect Authentication Agent sowie der Microsoft Azure AD Connect Agent Updater.

In Azure Active Directory lässt sich verifizieren, ob der Authentication Agent ordnungsgemäß kommuniziert.

Da ich zusätzliche Daten rundum um den Authentifizierungsprozess abfragen möchte, starte ich dazu on-prem einen Perfmon und überwache diesen über die Counter PTA authentications (failed and successful).

Weiterführende Links zu PTA

• Azure Active Directory Pass-through Authentication: Current limitations
• Migrate from federation to cloud authentication
• User Voice AAD PTA