1. The Big Decision: Why Leave ADFS?

After ten parts of deep ADFS mastery, it may seem odd to talk about leaving it behind. But the industry is shifting: Microsoft Entra ID (formerly Azure AD) now provides native authentication with pass‑through authentication (PTA), password hash sync (PHS), and seamless SSO. These offer higher availability, less on‑prem hardware, and tighter integration with modern security like Conditional Access and Identity Protection.

Many organisations start with ADFS federation for Microsoft 365 and later move to cloud‑only auth once they trust the cloud’s resilience and security. This final post will guide you through that migration – preserving the user experience while simplifying your infrastructure.

2. Pre‑Lab Checklist

• ✅ Existing hybrid setup from Part 6 (Entra Connect syncing users, domain federated)
• ✅ Microsoft 365 tenant with Global Admin access
• ✅ An on‑premises test user that can be used for staged rollout
• ✅ Decision on target authentication method: Password Hash Sync + Seamless SSO is the simplest; PTA if you need on‑prem password validation

We’ll use PHS + Seamless SSO in this walkthrough because it requires no additional servers and provides immediate cloud fallback if on‑prem connectivity is lost.

3. Step 1 – Switch Entra Connect to Password Hash Sync

If your current Entra Connect configuration uses federation, the sign‑in method is likely set to “Federation with AD FS”. We need to change that to Password Hash Synchronization.

1. On your Entra Connect server (AZCONNECT01), open Azure AD Connect and select Configure.
2. Choose Change user sign‑in.
3. Enter your Microsoft 365 Global Admin credentials.
4. Select Password Hash Synchronization as the sign‑in method. Do not enable “Do not convert user accounts” yet – we’ll handle that with staged rollout.
5. Complete the wizard. This will enable PHS and keep the existing federation configuration. The domain remains federated for now.

Allow a full sync cycle. User password hashes will now be synced to Entra ID in addition to the existing federation.

4. Step 2 – Enable Seamless Single Sign‑On

Seamless SSO is the magic that lets domain‑joined devices inside the corporate network automatically sign users into Microsoft 365, without any ADFS redirect. It uses Kerberos to obtain a token from Entra ID.

1. On the Entra Connect server, run:

Enable-AzureADSSO -Enable $true

2. This creates a computer account in Active Directory named AZUREADSSOACC (if it doesn’t already exist). Ensure you do not move it from the default OU – Seamless SSO will break.
3. Update the group policy on your client machines to add https://autologon.microsoftazuread-sso.com to the Intranet Zone in Internet Explorer/Edge. This allows the Seamless SSO script to run.

Test Seamless SSO from a domain‑joined client: browse to https://myapps.microsoft.com. You should be silently signed in with your AD credentials – no prompt at all.

5. Step 3 – Staged Rollout: Test Cloud Authentication

Microsoft’s Staged Rollout feature lets you move a subset of users to cloud authentication while the rest of the organisation remains federated. This is the safest way to migrate.

1. In the Microsoft Entra admin center, go to Protection → Authentication methods → Staged rollout.
2. Select Password hash sync + Seamless SSO as the authentication method.
3. Add a test group containing one or two pilot users. Click Enable.

Now, those pilot users will have their authentication handled by the cloud (PHS + Seamless SSO), even though the domain is still federated for everyone else. Have them test Office 365, Teams, etc. – they should not see any ADFS redirects.

6. Step 4 – Convert the Domain from Federated to Managed

Once testing is complete and all users are ready to move, we’ll convert the entire domain. This is the point of no return – ADFS will no longer be used for Microsoft 365 authentication.

# Connect to Microsoft Graph
Connect-MgGraph -Scopes "Domain.ReadWrite.All"

# Update the domain to Managed (cloud‑only authentication)
Update-MgDomain -DomainId "corp.lab" -AuthenticationType "Managed"

Within a few minutes, all users in the domain will use PHS + Seamless SSO. The ADFS farm can remain running for non‑Microsoft 365 relying parties (like on‑prem Exchange OWA, if still used), but you can begin decommissioning WAP servers and reducing ADFS capacity.

7. Step 5 – Decommission ADFS (For Microsoft 365 Only)

If ADFS is no longer needed at all, you can completely remove it. But many orgs keep it for legacy apps. For those retiring it entirely:

1. Update all other relying parties to use Entra ID directly (SaaS apps, B2B trusts, etc.).
2. Unpublish applications from WAP.
3. Remove WAP servers.
4. Uninstall ADFS role from all farm members.
5. Remove the gMSA and any dedicated certificates.

If keeping ADFS for on‑premises only, leave the farm running but remove the Microsoft 365 relying party trust to avoid confusion.

8. How Cloud Authentication Works Without ADFS

When a user signs into Office 365 now, Entra ID validates the password hash (PHS) or forwards the password to an on‑prem agent (PTA). Because the device is domain‑joined and we configured Seamless SSO, the browser automatically obtains a Kerberos ticket for the Entra ID SSO endpoint. No redirect, no ADFS, no extra prompt.

The entire flow happens in the cloud. If your on‑premises AD is unavailable, PHS still works (users can sign in with their last synced password). PTA requires an on‑prem agent, but the fallback to PHS can be configured for resilience.

9. Troubleshooting Common Pitfalls

• Pilot user still redirected to ADFS? – Staged rollout may not have propagated. Wait up to an hour. Verify the user is in the correct group and that the group is listed in the Staged rollout policy.
• Seamless SSO not working? – Check that the AZUREADSSOACC computer account exists and is not deleted/moved. Ensure the client has the Intranet Zone GPO applied and can reach the SSO URL. Use the Microsoft SSO Troubleshooter script.
• Password hash not syncing? – Re‑run the Entra Connect wizard and ensure Password Hash Sync is selected. Force a full sync with Start-ADSyncSyncCycle -PolicyType Initial.
• Some apps still require ADFS? – Keep ADFS for those apps until you can migrate them to Entra ID Enterprise Applications (SAML/OIDC). You can run both in parallel indefinitely.

10. The End of Our Journey 🏁

Congratulations! Over ten parts you’ve gone from zero knowledge to designing, deploying, securing, and finally migrating away from ADFS. You’ve built a lab, federated Exchange OWA, published it securely with MFA, connected to Microsoft 365, federated with partners, upgraded without downtime, and hardened your infrastructure. You’re now equipped to make any identity decision with confidence.

Whether you keep ADFS for years or move entirely to the cloud, the principles of claims, trust, and secure token exchange will serve you well. Identity is the foundation of modern security – and you’re now an expert.

Thank you for following this series. If you built the lab, faced challenges, or have a success story, I’d love to hear about it in the comments. Happy federating – and happy cloud‑journeying!