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.

Ich vertrete die Meinung, dass die Mehrzahl der Firmen mit Office 365 besser auf lokale ADFS-Server verzichten und PHS nutzen. Für "Conditional Access" aus der Cloud brauchen Sie eine AzureAD-P1-Lizenz aber die Mehrkosten lassen sich aus meiner Sicht rechtfertigen.

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.

ADFSHelp - Resolve authentication issues faster
https://adfshelp.microsoft.com/
https://adfshelp.microsoft.com/JwtDecoder/GetToken 
Sehr nützliche Seite von Microsoft, um Probleme mit ADFS und Tokens zu analysieren

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 Through“-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 sogar sinnvoll sein, PHS einzurichten, obwohl die Domain "Federated" ist.

ADFS die schlechtere Wahl?

Ich würde heute aber einfach die Frage stellen, ob ich heute noch einmal ADFS einrichten würde?. Kurze Antwort NEIN aber vergleichen Sie selbst

  • ADFS stellt Tickets für den Zugriff auf die Cloud aus.
    Das ist wie ein Domain Controller, der Kerberos Tickets im Intranet ausstellt. Die Tickets kommen aber per HTTPS und nicht über das KDC.
  • Verfügbarkeit: Würden Sie ein Active Directory mit einem DC betreiben?
    Sicher nicht, d.h. sie brauchen mindestens zwei ADFS-Server und wenn Sie nicht mit Network Load Balancing (NLB) arbeiten auch einen Hardware Load-Balancer davor.
  • Zugriff aus dem Internet
    Ein interner ADFS-Server reicht leider nicht, denn Clients gibt es auch im Internet und die Cloud selbst spricht auch mit dem ADFS-Server (Federation Metadata, SigningZertifikatUpdate etc.) Also muss der Server "im Internet" veröffentlicht werden
  • ADFS Proxy
    Keiner stellt einen internen ADFS-Server mit einem Bein ins Internet. Also brauchen wir einen Reverse Proxy oder besser auch zwei mit einer Lastverteilung, Zertifikaten, DNS-Einträgen und statischer öffentlicher IP-Adresse
  • DoS-Schutz
    Ein ADFS-Server ist sehr einfach zu finden. Versuchen Sie eine Anmeldung an Office 365 und der Redirect legt die URL offen. Also müssen wir unseren Service gegen DoS-Attacken, Kennwort-Attacken etc. absichern.

Wenn Sie dann noch geografisch verteilt sind oder ein zweite RZ haben, kommen weitere Anforderungen dazu. Die Planung, Installation und Betrieb einer ADFS-Umgebung kann ganz schön teuer sein. Früher war das zu argumentieren, wenn es der einzige Weg für "SingleSignOn" war und man lokal eh schon MFA-Lösungen (RSA-Tokens etc.) hatte und man sich die AzureAD P1-Lizenz sparen wollte.

Heute reicht Office 365 E3 nicht mehr aus, weil andere Anforderungen (Intune, Conditional Access, AIP, Windows Enterprise u.a.) den Einsatz von Microsoft 365 F1/F3/E3 oder E5 erfordern und in allen Paketen ist Conditional Access und Seamless Single Sign On mit ADSync enthalten.

Sie brauchen einen ADFS-Server nicht mehr für Office 365 sondern eigentlich nur noch für andere Fremddienste. Und da sollten Sie prüfen, ob diese nicht sowieso schon als "Enterprise App" im AzureAD-Portal verfügbar sind.

Unsicher über die Wahl des Authentifizierungsdienstes? Dann sprechen Sie meine Kollegen oder mich einfach an. -> Net at Work und MSXFAQ

Was sagt Microsoft

Schon das Exchange Team hat in einer Präsentation nur noch über Pass Through Authentifizierung (PTA) und Password Hash Sync (PHS) gesprochen und bei der Frage nach ADFS recht flapsig mit einem "Das gibt es auch noch aber sei zweite Wahl" geantwortet. In einem Vortrag auf der Ignite 2022 wurde aber noch einmal gegenüber gestellt, was alles im einem On-Premises ADFS nicht so einfach geht:


Quelle https://ignite.microsoft.com/en-US/sessions/56b18247-a311-4b8f-8397-486b9ab30e68

Im gleichen Vortrag wurde auch eine Grafik gezeigt, wie die Nutzung von ADFS im Laufe der Zeit abgenommen hat.


Quelle https://ignite.microsoft.com/en-US/sessions/56b18247-a311-4b8f-8397-486b9ab30e68  02:30

Leider wird nicht zwischen PHS und PTA unterschieden. Der weitere Vortrags beschreibt auch noch die Migration von ADFS zu AzureAD Authentication. So kann der "Connect Health ADFS Agent" auf den lokalen Servern installiert werden um die aktuelle Nutzung der On-Premises ADFS-Farm zu analysieren.

Staged Rollout

Seit Apr 2021 ist diese Funktion nicht mehr Preview.

Der Umstieg von ADFS zu PTA/PHS ist einfach, denn die Umschaltung ist pro Domäne und seit 2019 sogar über Windows Gruppen möglich. Sie konfigurieren erst einmal PTA/PHS wie gewünscht aber lassen die "Federation" noch aktiv. Dann nutzen Sie die Funktion einer "Staged Rollout", wenn sie nicht eine Test-Domain haben, bei der sie Federation komplett abschalten wollen.

Im nächsten Dialog können Sie dann für PHS und PTA getrennt hinterlegen, welche Gruppen trotz aktivierter ADFS-Federation nicht mehr zum ADFS-Service gesendet werden sollen.

Es sollte sie nicht stören, wenn die Funktion seit 2019 in "Preview". Bislang hat sie immer funktioniert, um erst einmal ein paar Pilotpersonen in einer Gruppe auf PTA/PHS umzustellen, ehe Sie dann die Federation für die komplette UPN-Domain abschalten.

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.

Dieses Commandlet aktualisiert aber nur die Einstellungen in Office 365. Die Federation-Trust-Einstellungen auf dem lokalen ADFS-Server bleiben erhalten. Wenn der Server aber eh nicht mehr da ist und ein Neuaufbau ansteht, dann ist das das kleinste Problem.

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