Von ADFS zu Passwort-Hash-Sync mit Azure AD Connect
Viele Unternehmen verwenden noch einen ADFS Server, um die Authentifizierung über die zentrale Aktive Directory des Unternehmens durchzuführen. Wenn man diese ADFS Lösung als hochverfügbare Variante (HVV) konfiguriert hat, ist dies auch eine solide Lösung. Sollte die HVV jedoch nicht umgesetzt sein, gibt es eine gute Alternative.
Verwendung von Passwort-Hash-Sync mit AAD Connect
Passwort-Hash-Sync setzt voraus, dass man seine lokalen AD Passwörter gehashed in die Cloud synchronisiert. Seit einiger Zeit ist dies einer der empfohlenen Wege von Microsoft . Einhergehend mit dieser Variante kann man einige Features, wie Password-Self-Services der Azure AD nutzen.
Viele Unternehmen verwenden den AAD Connect bereits, um die Identitäten in die Azure AD zu synchronisieren.
Möchte man nun auch die Passwort-Hashes in die Cloud schieben, kann man unter „User Sign-In“
Den Punkt „Password Hash Synchronization“ anwählen.
Mit dieser Auswahl hat man es lediglich geschafft die Hashes in der Cloud verfügbar zu machen.
Oft sind weitere Schritte gewünscht, um die ganzen Vorteile des AAD Connects auszuschöpfen.
Unteranderem sind die Funktionen „Password-Writeback“ für die Azure AD Self-Services nützlich und der „Seamless-Single-Sign-On“ um den Identitätsanbieter über die Azure AD abzubilden.
Password-Writeback mit Azure AD Connect
Mit dem Password-Writeback ermöglicht man den Usern das eigene Passwort für Azure und Office 365 Services zurückzusetzen.
Aktivieren tut man es unter Sync -> Optional Features
Zudem muss man den Passwort Reset in der Azure AD unter „Manage“ aktivieren.
Seamless Single Sign On (SSSO) mit Azure AD Connect
Um die User-Experience zu steigern und Zeit zu sparen ist SSSO ein wunderbares Feature, was dem User erlaubt sich an seiner Workstation anzumelden und gleichzeitig den Zugriff auf O365 oder Azure Services zu haben. Dabei muss sich der User nicht erneut anmelden sondern der AAD Connect reicht die Anmeldung an die Azure AD weiter . Weitere lokale Komponenten sind nicht erforderlich.
Für das Aktivieren dieses Features müssen einige Änderungen lokal auf den Geräten, der Infrastruktur und dem AAD Connect durchgeführt werden.
Grundsätzlich empfehle ich vor der Änderung einige Backups zu erstellen.
- Step1:
- Backup existing Data / Check solution
- Backup ADFS Party Trust
- Domain Federation MFA Check
- Insight Corporate Network Claim
- Step2: Prerequisites
- Trusted Azure Intranet zone (On-Premises AD-Admin):
- GPO, User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page. Then select Site to Zone Assignment List. à Value(Data): 1, Value name: https://autologon.microsoftazuread-sso.com
- GPO, User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Zone. Then select Allow updates to status bar via script. à enabled
- Proxy/FW Whitelisting (Netzwerk Team): Proxy Exception: <tenantid>.registration.msappproxy.net (die ID findest du hier)
- Trusted Azure Intranet zone (On-Premises AD-Admin):
- Step3: Implementation
- Downtime: Nach der Umstellung kann es noch bis zu 4h ADFS Requests geben. Es könnte also vorkommen, dass User sich in Einzelfällen doppelt anmelden müssen.
- Change1: Enable PHS ✅
- Change2: MSAAD Connect, Change User Sign-in. Die Konfiguration ist wie in dem folgenden Bild gezeigt.
- Change3: Convert to Managed Domain, Azure Powershell: Set-MsolDomainAuthentication -Authentication Managed -DomainName <domain name>
- Step4: Testing
- office.com (Einloggen mit erlaubtem User)
- SSO Test: https://myapps.microsoft.com/ (SSO ohne Anmeldung)
Fragen?
Dann meldet euch gerne über mein Kontaktformular, per Whatsapp oder einfach als Kommentar.
Mehr Infos gibt es direkt bei Microsoft.