ADFS nach PHS/SSO umstellen

Irgendwann kann diese Entscheidung fallen, hier der Weg zum Ziel

Azure AD Connect Updaten!

Mit Version 2.0.8.0 wurde die Sicherheitslücke in Azure AD Connect Microsoft Azure Active Directory Connect Authentication Bypass Vulnerability -CVE-2021-3699, welche hier etwas besser beschrieben ist, gefixt worden – also updaten!
Aktuelle Version 08/2021 -> Azure AD Connect 2.0.10.0

Von „ADFS“ nach „Password Hash Sync“, mit Aktivierung „Seamless Single Sign On“

    Voraussetzungen

  1. ADFS funktioniert fehlerfrei
  2. Zugriff auf AzureAD via PowerShell funktioniert und ist getestet
  3. ADConnect ist bereits konfiguriert und auf dem aktuellsten Stand (siehe oben!)
  4. Vorbereitungen

  5. Seit April 2021 kann die Umstellung pro Domain im Staged Rollout Verfahren erfolgen, also in der Domain auf Gruppenzugehörigkeit gefiltert werden.
  6. Umstellung ADConnect auf Password Hash Sync, um die Hashes der Passwörter bereits nach Azure AD zu übertragen (ADConnect muss min. in Version 1.1.614 installiert sein!)
  7. Erstellen einer neuen Gruppenrichtlinie, die auf die entsprechende(n) User OU(s) verlinkt wird.
    Name bspw. „User – Office365 SSO“
    Einstellungen (deutschsprachiger DC):

    Benutzerkonfiguration > Richtlinien > Verwaltungsvorlagen > Windows-Komponenten > Internet Explorer > Internetkonfigurationsbildschirm > Die Sicherheitsseite > Intranetzone 
    "Aktualisierungen für die Statusleiste per Skript zulassen" auf "Enabled".
    Benutzerkonfiguration > Richtlinien > Verwaltungsvorlagen > Windows-Komponenten > Internet Explorer > Internet-Konfigurationsbildschirm > Seite Sicherheit . Wählen Sie dann die Liste Standort bis Zonenzuordnung und bearbeiten...
    https://autologon.microsoftazuread-sso.com
    Wert (Daten): 1
  8. Aktivierung Seamless Single Sign On via AD Connect Konfiguration GUI. In diesem Zuge wird auch das lokale Platzhalterkonto im AD (MSOL_xyz….), für die Anforderung Kerberos Tickets an die lokalen DC’s erstellt!)
  9. Sicherung der aktuellen Einstellungen!
    (Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"
  10. Wartungsfenster planen und Information der Benutzer!

  11. ACHTUNG: Den nächsten Schritt wenn möglich abends durchführen und gut planen, da die Änderung der Domaineinstellung im Tenant NICHT sofort übernommen wird! Microsoft definiert die „Umschaltzeit“ pro Domain auf etwa 4h… Siehe auch den Original Beitrag von Microsoft:
    „…After the domain conversion, Azure AD might continue to send some legacy authentication requests from Exchange Online to your AD FS servers for up to four hours. The delay is because the Exchange Online cache for legacy applications authentication can take up to 4 hours to be aware of the cutover from federation to cloud authentication.

    During this four-hour window, you may prompt users for credentials repeatedly when reauthenticating to applications that use legacy authentication. Although the user can still successfully authenticate against AD FS, Azure AD no longer accepts the user’s issued token because that federation trust is now removed.

    Existing Legacy clients (Exchange ActiveSync, Outlook 2010/2013) aren’t affected because Exchange Online keeps a cache of their credentials for a set period of time. The cache is used to silently reauthenticate the user. The user doesn’t have to return to AD FS. Credentials stored on the device for these clients are used to silently reauthenticate themselves after the cached is cleared. Users aren’t expected to receive any password prompts as a result of the domain conversion process.

    Modern authentication clients (Office 2016 and Office 2013, iOS, and Android apps) use a valid refresh token to obtain new access tokens for continued access to resources instead of returning to AD FS. These clients are immune to any password prompts resulting from the domain conversion process. The clients will continue to function without extra configuration…“

    Erfahrungsgemäß kann es schon etwas während der Umstellungszeit „klappern“, wenn Clients noch zu ADFS umgeleitet werden, mit dem Ticket zurückkehren und dann an einen Server kommen, der schon die neue Konfiguration hat.

    Cut Over

  12. Switch ADFS auf PHS und Seamless Single Sign On auf der Azure Domain dann im „Wartungsfenster“:
    Auf dem AD Connect Server, die PowerShell als Administrator starten…
    (Ist das AzureAD Modul noch nicht installiert, nachziehen mit:

    Install-Module AzureAD -AllowClobber

    dann:

    Connect-MsolService

    und Check des IST-Status der Federated Domain:

    Get-MsolDomain -domain contoso.com

    Ergebnis:
    Name Status Authentication
    —- —— ————–
    contoso.com Verified Federated

    Umstellen auf Managed:

    Set-MsolDomainAuthentication -Authentication Managed -DomainName contoso.com
    

    Kontrolle mit:

    Get-MsolDomain -domain contoso.com

    Ergebnis:
    Name Status Authentication
    —- —— ————–
    contoso.com Verified Managed

  13. Nachbereitung

  14. Jetzt heißt es warten! In der ersten Zeit wird jeder Anmeldeversuch weiterhin auf den ADFS-Service umgeleitet, aber so nach und nach sollten immer mehr Dienste darauf verzichten und ein Kennwort anfordern. Es kann durchaus erforderlich sein, dass Benutzer erneut, im Regelfall aber nur noch einmalig ihren UPN und ihr Passwort eingeben müssen, bis alle Dienste umgestellt sind.

That’s it!