Migrating from AD FS to Microsoft Entra ID

Migrating from AD FS to Microsoft Entra ID has two separate workstreams: move each application's federation from AD FS to Entra, then convert user authentication for your domains from federated to managed (cloud) authentication. Do them in that order, test both with pilot groups, and decommission AD FS only when sign-in data shows it is idle. This guide is for identity engineers running a hybrid Microsoft estate; every product behavior below is from Microsoft Learn.

Why migrate off AD FS

Running AD FS means patching federation and Web Application Proxy servers, rotating token-signing certificates, and keeping an on-premises dependency in the critical sign-in path. It is also a high-value target: the token-signing key is what makes every SAML assertion trusted, and whoever holds it can forge sign-ins, the core of federation trust abuse and SAML forgery. Microsoft's AD FS security best practices recommend protecting those keys in an HSM and never storing certificates on a network share; its emergency rotation guide covers what a compromise forces you to do. Token forgery with a stolen signing key is not theoretical, as Storm-0558 showed against Microsoft's own consumer key. Moving to Entra removes that key from your estate and enables Conditional Access, ID Protection, and phishing-resistant MFA.

Decide your target sign-in method

Microsoft's federation-to-cloud migration guide recommends password hash sync (PHS).

Before you start: checklist

• Microsoft Entra Connect installed or upgraded to the latest version (Microsoft says this cuts migration time "from potentially hours to minutes").
• Current federation settings documented with Get-MgDomainFederationConfiguration, especially PreferredAuthenticationProtocol, federatedIdpMfaBehavior, SupportsMfa, and PromptLoginBehavior.
• AD FS backed up (the AD FS Rapid Restore Tool) and the Microsoft 365 relying party trust exported, including custom claim rules.
• Inventory of every relying party and its protocol: SAML, WS-Fed, or OIDC/OAuth.
• AD FS access control policies mapped to Entra Conditional Access, authored in report-only mode.
• A Conditional Access policy to block legacy authentication, which Microsoft recommends because of the risk legacy protocols carry. The Midnight Blizzard password spray started at a legacy test account without MFA.
• Hybrid Identity Administrator role available for staged rollout.
• Two cloud-only emergency access accounts that do not depend on AD FS.

Phase 1: Migrate applications

Use the AD FS application migration dashboard under Usage & insights. It needs Entra ID P1 or P2, Entra Connect, and the Connect Health AD FS agents. It lists relying parties with sign-ins in the last 30 days (filterable to 1, 7, or 30 days) and excludes Microsoft relying parties such as Office 365. Each app gets a status:

The wizard creates the app registration and service principal, sets the SAML identifier and reply URL, assigns users and synced groups from the AD FS access control policy, and configures compatible claims. It does not migrate the signing certificate, does not create Conditional Access policies, and does not handle OIDC, OAuth, or WS-Fed apps. The new app stays inactive until you redirect sign-in traffic, so rollback is deleting it.

Microsoft's migration stages suggest moving apps on modern protocols first, testing a test instance against a test tenant (optional), then a test instance against production, then the production app. Line-of-business apps on OAuth 2.0, OIDC, or WS-Federation become app registrations; custom SAML or WS-Fed apps become non-gallery enterprise apps. Legacy-protocol apps go behind Application Proxy or a Secure Hybrid Access partner.

Claim rules: the long tail

The wizard's claim rule tests flag what will not translate. The common blockers: regular expressions in conditions or transformations (replace with functions such as IfEmpty(), StartWith(), Contains(), Extract(), ToLower()), ADD issuance rules (rebuild as multiple transformations), and attribute stores other than Active Directory, which Entra cannot source claims from. Budget time for that tail, plus apps with AD FS endpoints or certificates hardcoded in config.

Phase 2: Pilot cloud authentication with staged rollout

Staged rollout moves selected users to PHS or PTA (plus Kerberos-based desktop SSO via the AZUREADSSO computer account) while the domain stays federated. Limits that trip teams up:

• Maximum 10 groups per feature; nested and dynamic groups are not supported; use cloud security groups to avoid sync latency.
• A newly added group is limited to 200 users to avoid a UI time-out; add more afterward. Membership edits can take up to 24 hours.
• Only synced users, browser and modern-auth clients; legacy-auth apps fall back to federation, and apps that send domain_hint keep using federation.
• Newly added users need one more federated sign-in before managed auth applies; Microsoft's workaround is a Temporary Access Pass for the first sign-in.

Phase 3: Convert domains and harden MFA

Convert one domain at a time, starting with a test domain or the one with fewest users, using Entra Connect (if it configured AD FS originally) or Update-MgDomain -DomainId <domain> -AuthenticationType "Managed". Allow up to 60 minutes for the change. Rollback is New-MgDomainFederationConfiguration with your documented settings.

While any domain stays federated, set federatedIdpMfaBehavior to rejectMfaByFederatedIdp unless you rely on a third-party MFA provider at the federation server. If neither it nor SupportsMfa is set, Entra defaults to accepting MFA claims from the federated IdP, which lets anyone who can impersonate that IdP claim MFA was done. After cutover, roll over the Kerberos decryption key of the AZUREADSSO computer account at least every 30 days; it is manual.

Phase 4: Decommission

Use Connect Health usage data to confirm no new authentication requests reach AD FS and all users sign in through Entra, then remove the Microsoft 365 relying party trust. If no other relying parties remain, follow Microsoft's AD FS decommission guide.

Common failure modes

Related

Guides: IAM cloud migration, conditional access policies, SAML vs OIDC. Techniques: federation trust abuse and SAML forgery, password spraying. Standards: SAML 2.0, OpenID Connect. Glossary: federation, conditional access.