Moving from AD FS to cloud authentication: inventory, staged rollout and domain cutover

In many tenants AD FS now exists mainly to sign users in to Microsoft 365, at the cost of extra servers, certificates and an internet-facing attack surface. Microsoft recommends password hash synchronization (PHS) for cloud authentication, and staged rollout lets you prove it with pilot groups before you touch the domain. In this post I'll walk through the whole path: inventory, PHS, staged rollout, domain conversion with Microsoft Graph PowerShell and decommissioning.

Prerequisites#

• A current Microsoft Entra Connect Sync server and the Microsoft Graph PowerShell SDK.
• The Hybrid Identity Administrator role for staged rollout, plus domain admin rights in each forest if you enable Seamless SSO.
• Conditional Access policies and company branding ready for users who will now see the Microsoft Entra sign-in page.
• Users registered for Microsoft Entra MFA if MFA happens in AD FS or a third-party provider today.

Still choosing between PHS and pass-through authentication? Read my comparison of hybrid sign-in methods first. I'll use PHS here.

Step 1: Inventory what AD FS does for you#

The Microsoft 365 trust is rarely the whole story. On an AD FS server, list every relying party trust and save the rules on the Microsoft 365 one:

Get-AdfsRelyingPartyTrust | Sort-Object Name | Select-Object Name, Enabled, Identifier
$rp = Get-AdfsRelyingPartyTrust | Where-Object Name -like "Microsoft Office 365 Identity Platform*"
$rp.IssuanceTransformRules | Out-File .\m365-claim-rules.txt
$rp.IssuanceAuthorizationRules, $rp.AccessControlPolicyName

• Other relying parties are apps to move to Microsoft Entra ID as SAML or WS-Federation enterprise apps, or reasons to keep AD FS a while longer. The AD FS application activity report in the Microsoft Entra admin center, fed by the Connect Health agent for AD FS, shows which are actually used.
• Claim rules and access policies on the Microsoft 365 trust, such as blocking external access or issuing the insidecorporatenetwork claim, need Conditional Access equivalents.
• Custom sign-in pages built with AD FS JavaScript (onload.js) can't be reproduced; use company branding.
• Blockers: Microsoft's guidance says non-persistent VDI on Windows 10, version 1903 or later, must remain federated, and Windows Hello for Business hybrid certificate trust that uses AD FS as its registration authority isn't supported in staged rollout. Plan a move to cloud Kerberos trust first.
• Hybrid joined devices stop registering through AD FS once the domain is managed, so their computer objects must be in Entra Connect's sync scope; see configuring hybrid join.

Finally, record each federated domain's settings with Graph PowerShell. They are your rollback plan:

Connect-MgGraph -Scopes "Domain.ReadWrite.All", "OnPremDirectorySynchronization.Read.All"
Get-MgDomain | Where-Object AuthenticationType -eq "Federated" | Select-Object Id
Get-MgDomainFederationConfiguration -DomainId "contoso.com" | Format-List * | Out-File .\contoso-federation.txt

Step 2: Enable password hash sync#

1. In the Entra Connect wizard, choose Customize synchronization options and tick Password hash synchronization on Optional features. Federated domains keep federating, so nobody notices.
2. Let a full password hash sync finish, then check it on the Connect server with Invoke-ADSyncDiagnostics -PasswordSync (module ADSyncDiagnostics).
3. Confirm UPN changes will keep flowing for managed users: (Get-MgDirectoryOnPremiseSynchronization).Features.SynchronizeUpnForManagedUsersEnabled must return True.
4. If some PCs are domain-joined but not hybrid joined, enable Seamless SSO now with Enable-AzureADSSOForest. It applies only to staged rollout users until the domain converts; my Seamless SSO guide covers the intranet zone and Kerberos side.

Step 3: Pilot with staged rollout#

1. Create a cloud security group for the pilot; cloud groups avoid sync latency. Nested groups, dynamic groups and groups containing contacts aren't supported, and a group should hold no more than 200 members when you first add it. You can add members afterwards.
2. In the Microsoft Entra admin center, open Entra ID › Entra Connect › Connect sync and select Enable staged rollout for managed user sign-in.
3. Turn on Password Hash Sync (and Seamless single sign-on if you enabled it) and add the pilot group to each. The limit is 10 groups per feature.
4. A newly added group is picked up immediately, but later membership edits can take up to 24 hours. Even then, each new user completes one more sign-in at AD FS before managed authentication sticks, unless you issue a Temporary Access Pass for that first sign-in.
5. Widen the pilot in waves while watching sign-in logs, the Hybrid Auth workbooks and help desk tickets.

Step 4: Convert the domain#

Book an off-hours window: the conversion can take up to 60 minutes to settle, while modern clients carry on with their refresh tokens. Microsoft documents two paths:

• AD FS configured by Entra Connect: run Change user sign-in, choose Password Hash Synchronization (with Enable single sign-on if needed) and the wizard converts all federated domains at once.
• AD FS configured outside Entra Connect: keep PHS enabled in Connect and convert each domain with Graph PowerShell. Subdomains follow their root domain by default.

# Same Graph session (Domain.ReadWrite.All) as step 1
Update-MgDomain -DomainId "contoso.com" -AuthenticationType "Managed"
Get-MgDomain -DomainId "contoso.com" | Select-Object Id, AuthenticationType

Step 5: Decommission AD FS#

1. Remove the pilot groups and switch staged rollout off; it has no purpose once the domain is managed.
2. Watch the AD FS servers (Connect Health usage, AD FS audit events) until no Microsoft 365 or other relying party traffic remains.
3. Back up the AD FS configuration, then remove the Microsoft 365 trust with Remove-AdfsRelyingPartyTrust -TargetName "<trust name>".
4. Uninstall WAP and AD FS, then clean up public DNS records for the federation service, load balancer and firewall rules, certificates, the service account, Connect Health agents and any Group Policy entries for the federation URL.

Verify#

• Get-MgDomain shows Managed for every converted domain.
• From outside the network, a private browser session to https://myapps.microsoft.com shows the Microsoft Entra password page, not AD FS, and the sign-in log records the success.
• On hybrid joined PCs, dsregcmd /status still shows AzureAdPrt : YES after the user signs in again.
• A password changed in AD works in the cloud within minutes, and AD FS logs no new Microsoft 365 requests.

Tips and gotchas#

• Fix non-routable on-premises UPNs (such as .local) first. During staged rollout, PRT acquisition for those users falls back to AD FS; once federation is gone, it stops working.
• The legacy MFA option to skip MFA for federated users on your intranet relied on the insidecorporatenetwork claim. Replace it with Conditional Access named locations.
• Synced users' cloud passwords don't expire by default, so an expired AD password keeps working in the cloud until it's changed. Review the CloudPasswordPolicyForPasswordSyncedUsersEnabled feature if that matters.
• AD FS extranet lockout goes away with the farm; tune Microsoft Entra smart lockout instead.

References#

• Migrate from federation to cloud authentication
• Migrate to cloud authentication using Staged Rollout
• Update-MgDomain (Microsoft Graph PowerShell)