ADFS zu PHS/SSO

Es war im Jahr 2008: Office 365 hieß noch BPOS, Exchange Online basierte auf Exchange 2007 und Net at Work war eine er der frühen Nutzer von Cloud-Diensten. AADConnect hieß noch DirSync und synchronisierte unsere Benutzerkonten in die Cloud

Warum damals ADFS?

Für SingleSignOn und zur Steuerung der Zugänge haben wir einen ADFS-Server installiert. Das war damals der Weg, wenn Firmen die Cloud Dienste per SingleSignOn nutzen und über Claim Rules weitere Bedingungen umsetzen wollen. Der Betrieb von ADFS ist natürlich mit Kosten verbunden. Es erfordert neben einer öffentlichen IP, einem DNS-Namen und einem kostenpflichtigen Zertifikat mindestens einen ADFS-Server im LAN und einen ADFS-Proxy in der DMZ. Um gegen Ausfall der eigenen Internet-Verbindung und Unterbrechungen beim regelmäßigen Update gewappnet zu sein, sollten die Server redundant ausgelegt werden, wozu dann auch Loadbalancer gehören. Alles in allem ein umfangreiches Setup. PasswordHashSync war damals zwar auch schon möglich, aber ein SameSignOn ist eben kein SingleSignOn.

Erst mit dem Updaten im Juni 2017 können Anwender mit Verbindung zum KDC ihres Domain Controllers auch Cloud Dienste ohne neue Eingabe von Kennworten verwenden. Zeitgleich wurde auch „Pass Though“-Authentication als Preview bereitgestellt, bei der Agenten im LAN die Authentifizierung die Cloud-Anmeldungen übernehmen. Sie können damit auf den Export der Hashwerte in die Cloud verzichten aber bekommen eine Abhängigkeit zu lokalen Diensten. Wenn meine Daten schon in der Cloud sind, dann sollte ich auch kein Problem mit doppelt verhashten Kennworten haben.

Weckruf

Als dann durch den Abriss eines Nachbargebäude unser Office komplett stromlos war und auch die Internetbindung unterbrochen wurde, konnten für einige Stunden die Anwender nicht mal mehr im Homeoffice oder einem Hotel arbeiten, da die ADFS-Server zur Authentifizierung ebenfalls nicht mehr erreichbar waren.

Sicher könnte man auch einen Domain Controller in Azure aufbauen und dort auch ADFS-Services, Loadbalancer und Firewall virtuell betreiben. Aber diese Unterbrechung war ein Auslöser, dass wir die Anmeldung auf eine solide und vernünftige Plattform aufsetzen sollten. Viel zu lange lief der ADFS-Service, weil er ja eh da war. Mit EMS E3 bzw. Azure P1 haben sich auch die meisten Claim Rules über Conditional Access und MFA ablösen lassen.

Aber es gibt noch mindestens einen weiteren Vorteil, wenn Sie Hashwerte in die Cloud synchronisieren. Es gibt immer wieder Leaks, bei denen Kennworte oder Hashwerte bei Firmen abgegriffen und verteilt werden. Auch Microsoft nutzt diese Listen, um die Hashwerte gegen die mit PHS synchronisierten Werte zu prüfen und bei Übereinstimmung den Anwender zu informieren.

Identity Architecture: Password Hash Synchronization | Azure Active Directory
https://www.youtube.com/watch?v=s2-RmScMfm4
Gut gut gemaches Erklär-Video

Es kann also sinnvoll sein, PHS zu nutzen, obwohl die Domain "Federated" ist.

Vorarbeiten

Schon kurz nach dem Ausfall haben wir ADSync mit PasswordHashSync konfiguriert. Zu dem Zeitpunkt war AADConnect Version 1.3.21 aktuell und installiert. Die Mindestvoraussetzung ( neuer als 1.1.614) war somit schon länger erfüllt. Die Umstellung von ADFS zu Password Hash Sync hat Microsoft sehr gut dokumentiert.

Selbst wenn die Domain weiterhin per ADFS Federation betrieben wird, könnte wir im Falle eines Falles die Federation eben abschalten und nach kurzer Zeit (Microsoft verspricht maximal 4h) weiter arbeiten. Die Verbindung zum ADFS wird pro Domain konfiguriert und da wir mehrere UPN-Domains betreiben, konnten wir mit einer andere Domäne schon mal die Funktion mit PHS und vor allem "SeamlessSignOn.

Dazu müssen natürlich vorab alle Client per Gruppenrichtlinie oder Präferenz mitgeteilt bekommen, dass die Domain „microsoftazuread-sso.com“ auch vertrauenswürdig ist, da ansonsten der Browser kein Kerberos-Ticket für diese Domäne anfordert. Auch das ist gut bei Microsoft beschrieben.

  • Neue Gruppenrichtline angelegt
    Name: „User – Office365 SSO“
    Bindung auf “OU=Abteilung”
    Einstellung: Gruppenrichtlinienpräferenz – Registry:
    Schlüsselpfad: Software\Microsoft\Windows\CurrentVersion\Internet Settings\ZoneMap\Domains\microsoftazuread-sso.com\autologon
    Wertname: https.
    Werttyp: REG_DWORD.
    Wertdaten: 00000001

Nun fehlt natürlich noch das Platzhalterkonto im lokalen AD. AADConnect legt dieses automatisch an, wenn wir "Seamless Single Sign On" aktivieren. Erst dann wissen die lokalen Kerberos Server, welches Ticket sie für die hinterlegten SPNs der Cloud-Dienste ausstellen sollen.

Allerdings steuert natürlich weiterhin die Cloud anhand der Einstellungen pro Domäne, ob die Anmeldung des Clients über den Microsoft EVOSTS läuft oder eine Umleitung zum On Premises ADFS-Service erfolgt. Der hat ja einen anderen FQDN und damit kommt das AzureADSSOACC-Konto nicht zum tragen.

Für die Test-Domains war schnell klar, dass wir keine Applikation gefunden haben, die inkompatibel war. Sogar der Wechsel einer Domain von "federated" auf "Managed" wurde von den Client korrekt umgesetzt, ohne dass Anwender erneut sich anmelden mussten. Nur in einigen seltenen Fällen musste der Anwender einmalig seinen UPN eingeben, damit der Browser zukünftig die Information gleich mitschicken kann.

Allerdings knirscht es schon etwas während der Umstellungszeit, wenn Clients von der Cloud noch zu ADFS umgeleitet werden und mit dem Ticket zurückkehren und dann an einen Server kommen, der schon die neue Konfiguration hat.

Switch

Ende August haben wir dann die Umstellung der produktiven Domäne gewagt. Aufgrund der Verzögerungen in Office 365 haben wir die Domäne spät abends (genau 23:50) umgestellt und gewartet.

Da wird durch die frühe Nutzung damals die ADFS-Konfiguration unabhängig von AADConnect durchgeführt haben, konnten wir die ADFS-Federation auch einfach wieder manuell zurück bauen. Das sind wenige Befehle mit der Office 365 PowerShell:

# Check des IST-Status
Get-MsolDomain -domain netatwork.de
Name         Status   Authentication
----         ------   --------------
netatwork.de Verified Federated
 
# Umstellen auf Managed
Set-MsolDomainAuthentication `
   -Authentication Managed `
   -DomainName netatwork.de
 
# Kontrolle
Get-MsolDomain -domain netatwork.de
 
Name         Status   Authentication
----         ------   --------------
netatwork.de Verified Managed
 

Die ersten Minuten wurde jeder Anmeldeversuch weiterhin auf dem ADFS-Service umgeleitet aber so nach und nach haben immer mehr Dienste darauf verzichtet und ein Kennwort angefordert.

Fallstricke

Durch die Umstellung der Domäne von "Federated" auf "Managed" in der Nacht konnte die Cloud bis zum nächsten Morgen diese Änderungen problemlos durch synchronisieren. Insofern gab es auch kein böses Erwachen, wenn sich am nächsten Tag die Mitarbeiter an ihrem PC neu angemeldet haben und wie gewohnt die Cloud-Dienste nutzen wollten.

Je nach Vorbereitung kann natürlich immer was schief geben. Hier eine kleine Liste:

  • Modern Authentication und Clients
    Alle Clients, die bislang schon mit ADFS arbeiten konnten, sollten auch mit Password Hash Sync (PHS) und Seamless Single Sign On umgehen können. Knifflig wird es eher für Eigenentwicklungen, die z.B. den ADFS-Server direkt ansprechen.
  • Einmalige Eingabe des Benutzernames
    Ihr Browser speichert ihren Anmeldenamen in einem Cookie. Anscheinend ändert sich hier der Name, so dass einige Anwender neu nur nach dem Anmeldenamen gefragt wurde. Eine Kennwortabfrage erfolgte aber im LAN nicht, da dann ja Seamless Single Sign On zuschlägt
  • Die Clients bekommen die GPO verspätet
    Womit wir beim zweiten Stolperstein wären. Die Anmeldung per Seamless Single Sign On funktioniert natürlich nur, wenn per GPO die Office 365-Hostnamen als !"Trusted" definiert wurden. Ansonsten fragt der Browser nicht nach einem Kerberos-Ticket. Der Anwender wird dann nach seinem Kennwort gefragt. Sie sollten die Gruppenrichtlinie also einige Tage vorab schon verteilen, damit auch Clients diese anwenden, die nicht regelmäßig Kontakt zur Basis haben.
  • "Falscher" Browser
    Voraussetzung für SSO im Browser muss natürlich sein, dass der Browser dies kann und es aktiviert ist. Das sollte aber schon früher der Fall gewesen sein, wenn Sie ADFS schon mit Kerberos von intern genutzt haben.
  • Andere Anmeldebildschirm
    Ihren ADFS-Service können Sie einem eigenen Layout versehen und per Firewall noch viele andere Dinge erweitern. Wenn ab der Umstellung ein Client nicht mehr per Kerberos gleich "drin" ist, dann landet er nun auf dem Anmeldeschirm des EVOSTS von Microsoft. Der sieht vielleicht anders aus und auch die URL im Browser ist anders.
  • Timing 4h
    Microsoft verspricht, dass eine Änderungen am Federation-Status einer Domain nach spätestens 4h aktiv ist. Bislang hat das bei meinen Projekten immer funktioniert aber das muss nicht immer sein. Vor allem gibt es keinen "Zeitpunkt" sondern je nach Service ist es eine Zeitdauer, in der die Reaktion der Clients unterschiedlich sein kann.

Die Probleme sind möglich aber lösbar und in großen Teilen auch vermeidbar.

Nacharbeiten

Nachdem die Anmeldung nun auf Seamless Single Sign On bzw. Password Hash Sync (PHS) umgestellt ist, sollten Sie natürlich noch sicherstellen, dass bestimmte Dinge auch erfolgreich durchlaufen werden. Die Anmeldung ist nämlich ansonsten alles andere als ein Selbstläufer:

  • PHS-Funktion
    Wenn ein Anwender ein lokales Kennwort ändert, muss ADSync dieses in die Cloud übertragen. Überwachen Sie solche Events auf Erfolg und ob die passieren. Wenn ihr Anwender ab und an ihr Kennwort ändern, sollten sie immer mal wieder solche Meldungen sehen.
  • Key Rollover AZURESSOACC-Konto
    Aus Sicherheitsgründen sollte das Schlüsselmaterial dieses Kontos regelmäßig aktualisiert werden. Microsoft empfiehlt dies alle 30 Tage. Sie müssen das nicht machen aber um so länger hätte ein Angreifer, der auf den Key Zugriff erlangt hat, Zugriff auf die Benutzerdaten in der Cloud. Wobei auch bis zu 30 Tage sehr lange sein kann. Eine Anmeldeüberwachung ist also schon ratsam.

Diese Nacharbeiten und Betriebsaufwände sind aber nur ein Bruchteil, die bei einem ADFS-Serverbetrieb so anfallen. Die Unabhängigkeit von einer lokalen Komponente war auch der Grund auf den Wechsel zu Pass-Through Authentifizierung (PTA) abzusehen. Mit Pass-Through Authentifizierung (PTA) ist es natürlich im Vergleich zu ADFS um einige einfacher eine Anmeldung gegen die lokalen Domain Controller zu ermöglichen. Allerdings sehe ich kaum einen Sicherheitsgewinn, denn die Kennworte liegen nur nach zweimaligem Hashing in der Cloud und ein staatlicher "Angreifer" oder Microsoft müsse ja gar nicht meine Zugangsdaten erhalten. Die könnten auch direkt an die Daten. Mein Office 365/Firmen-Kennwort unterscheidet sich natürlich von den Kennworten in anderen Diensten.

Weitere Links