Leaving AD FS: moving to cloud authentication without disrupting users
Many organisations keep AD FS out of habit, long after the reason for deploying it has gone. This internet-facing infrastructure, whose compromise opens the door to token forgery, deserves an exit project. Well prepared, the migration is largely invisible to users.
Why leave AD FS
An AD FS farm means servers to maintain, Web Application Proxies published to the internet, certificates to renew, and a strong dependency on the datacentre for every Microsoft 365 sign-in. Above all, it is a Tier 0 component: anyone who obtains the token-signing certificate can forge tokens for any user. Cloud authentication, through password hash synchronization or pass-through authentication, removes that dependency and lets you rely fully on Conditional Access and Entra ID Protection.
Inventory before touching anything
The difficulty of an AD FS migration rarely lies with Microsoft 365 itself, but with everything that has been attached to the farm over the years:
- Relying party trusts: every federated application must be identified, along with its owner and actual usage. The AD FS application activity report in Entra ID, fed by Entra Connect Health, helps assess how easily each one can be migrated.
- Claims rules: some complex, sometimes undocumented, transformations are essential for an application to work.
- MFA: a third-party MFA adapter or custom authorisation rules need an equivalent in Conditional Access.
- Hybrid join: make sure device registration does not depend on AD FS.
Testing with staged rollout
Staged rollout lets you move groups of users to cloud authentication while the domain remains federated. You first enable PHS (or PTA) for everyone, then add pilot groups. Users in those groups authenticate directly against Entra ID; everyone else still goes through AD FS. Some scenarios are not supported in this mode: check the current Microsoft documentation before building the test plan.
Migrating applications
SAML and WS-Federation applications published by AD FS can, in most cases, become Entra ID enterprise applications. You need to reproduce the expected claims with Entra ID claims mapping and transformation features, replace authorisation rules with user assignment and Conditional Access policies, then test with the vendor or application team. Migrating one application at a time, with a rollback option, keeps risk low.
Switching domains, then decommissioning
- Convert each domain from federated to managed during a planned window, with a documented rollback plan.
- Monitor sign-in logs and helpdesk activity for a few days.
- Remove the Microsoft 365 relying party trust from AD FS.
- Decommission the AD FS servers and proxies, then clean up DNS records, firewall rules and service accounts.
- Destroy the token-signing and token-decryption certificates, and clean up the AD FS key container in Active Directory.
Golden SAML and persistence. After the switch, check that no domain in the tenant is still federated and that no unknown federation configuration has been added. Adding a federated domain that points to an attacker-controlled identity provider is a documented persistence technique.
What an audit checks
- The list of domains still federated and the justification for each one.
- The inventory of relying party trusts and their actual usage.
- Protection of the token-signing certificate for as long as AD FS remains in service.
- Undocumented federation configurations in the tenant.
- Actual decommissioning of servers, certificates and service accounts after the migration.