AD FS federation to Entra ID authentication
Cohash moves sign-in from AD FS to Microsoft Entra ID. We document federation settings and claim rules, replace AD FS access policies with Conditional Access, test password hash sync with staged rollout groups, convert domains one at a time, then move each relying party to Entra ID as a gallery or custom app. The farm is retired only when Connect Health shows no traffic.
- 01Inventory relying parties
- 02Record and back up federation settings
- 03Replace access policies
- 04Staged rollout and domain conversion
- 05Move the remaining apps
- 06Decommission
The story
Told without the client's name or anything that could identify them.
A healthcare group's identity team ran an AD FS farm and Web Application Proxy servers on Windows Server 2016, and every token-signing certificate renewal turned into a scramble. Users saw a branded AD FS page for some apps and the Microsoft sign-in page for others, and MFA was enforced in two places. We used the AD FS application activity report and Connect Health to find which relying party trusts still got traffic, backed up the federation settings, and rebuilt access policies as Conditional Access in report-only mode. After staged rollout pilots on password hash sync, domains converted one at a time and the remaining apps moved in waves. The farm was shut down once Connect Health showed no new requests.
why it was urgentWindows Server 2016 leaves extended support in January 2027, and many AD FS farms and Web Application Proxy servers still run on it. Rebuilding the farm on a newer Windows release is real work, so teams ask whether to rebuild or move sign-in to Entra ID, where Microsoft recommends password hash sync for cloud authentication.
- openAD FS and WAP servers run Windows Server 2016 and the token-signing certificate renewal is always a scramble.
- recurringDozens of relying party trusts exist and nobody knows which ones still get sign-ins.
- blockedSign in to one app and you get a branded AD FS page. Sign in to the next and it's the Microsoft page.
- openMFA is enforced in AD FS for some apps and in Conditional Access for others.
The estate, before and after
Before: AD FS federated sign-in for every domain
Sign-in for Microsoft 365 and line-of-business apps went through Web Application Proxy to the AD FS farm. MFA was split between AD FS access policies and Conditional Access, and nobody knew which relying parties still had traffic.
Read the diagram as text
- Workforce users → Web Application Proxy: sign-in
- Legacy clients → Web Application Proxy: WS-Trust
- Web Application Proxy → AD FS farm: proxy
- AD FS farm → Active Directory: LDAP lookup
- AD FS farm → Microsoft 365: SAML token
- AD FS farm → SaaS apps: SAML token
- AD FS farm → Line-of-business apps: claims
After: Entra ID handles sign-in for every app
Entra ID gets the synced password hashes, authenticates users and applies Conditional Access. Apps that relied on AD FS trusts have moved to gallery or custom SAML apps and app registrations, and the older protocol apps sit behind Application Proxy.
Read the diagram as text
- Active Directory → Entra Connect: hashes
- Entra Connect → Microsoft Entra ID: sync
- Microsoft Entra ID → Conditional Access: policy check
- Microsoft Entra ID → ID Protection: sign-in risk
- Microsoft Entra ID → Microsoft 365: token
- Microsoft Entra ID → SaaS apps: SAML assertion
- Microsoft Entra ID → Line-of-business apps: OIDC token
- Microsoft Entra ID → Application Proxy: pre-auth
How we run it, phase by phase.
6 phases take you from AD FS farm and WAP servers to Microsoft Entra ID cloud authentication. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Inventory relying parties
We use the AD FS application activity report and Connect Health usage data to see which relying party trusts still get traffic. Each one gets an owner, protocol, claim rules and a target: gallery app, custom SAML app, app registration or retire.
- phase 02
Record and back up federation settings
Get-MgDomainFederationConfiguration records PreferredAuthenticationProtocol, federatedIdpMfaBehavior and PromptLoginBehavior for each domain. We back up the farm with the AD FS Rapid Restore Tool and export the Microsoft 365 relying party trust, so there's a way back.
- phase 03
Replace access policies
We turn AD FS access control policies into Conditional Access policies and test them in report-only mode. Legacy authentication gets blocked. And we set federated MFA behavior up front, because MFA mustn't be bypassable mid-change.
- phase 04
Staged rollout and domain conversion
Staged rollout won't take nested or dynamic groups, so our pilot groups are cloud-only ones on password hash sync. Once the pilots look right, domains convert with Update-MgDomain, smallest first, inside a window that allows for the switch taking up to 60 minutes.
- phase 05
Move the remaining apps
Line-of-business and SaaS relying parties are reconfigured against Entra ID in waves, with claims compared token by token. Older protocol apps go behind Application Proxy.
- phase 06
Decommission
Once Connect Health shows no new requests, we remove the relying party trusts and shut the farm down, following Microsoft's AD FS decommission guide.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
Sign-in runs on Entra ID cloud authentication
We converted federated domains to managed authentication with password hash sync. That also turned on leaked-credential detection, something AD FS never had.
- result 02
One set of MFA and access rules
AD FS access control policies were rebuilt as Conditional Access policies, legacy authentication is blocked, and federatedIdpMfaBehavior was set explicitly so MFA wasn't skipped during the switch.
- result 03
Every relying party has an owner and a target
We moved each trust to a gallery app, a custom SAML app or an app registration. Some we simply retired. Nothing went live in a wave until its claims matched the old tokens one for one.
- result 04
A rollback path that was written down
We exported each domain's federation settings and the Microsoft 365 relying party trust, and wrote down the commands to convert a domain back if a cut-over went wrong.
- result 05
The AD FS and WAP servers are gone
We removed the relying party trusts and decommissioned the farm following Microsoft's guide. No more certificate renewals on Windows Server 2016 hosts.
Risks we plan for
-
Claim rules with no direct mapping
Custom claim transforms, attribute stores and issuance rules don't always map to Entra claims mapping. Each one is rebuilt and compared against a real token before cut-over.
-
Lost sign-in customization
Microsoft notes onload.js customizations can't be duplicated in Entra ID. Sign-in also needs a UPN or email, so users who sign in with a short name need a heads-up and help desk notes.
-
MFA bypass or double prompts
Leave federatedIdpMfaBehavior at its default during the switch and MFA can get skipped, or asked for twice. We set it explicitly for each domain before conversion.
-
Hidden legacy clients
Old Office clients, scripts and devices using WS-Trust or basic auth fail once the domain converts. Sign-in logs are checked for them weeks in advance.
Where AI helps, and where it needs guardrails
Once sign-in goes through Entra ID, Entra ID Protection can apply leaked-credential and sign-in risk detection that AD FS never had. AI assistants are useful for reading exported claim rule XML and drafting equivalent claims mappings, but every draft is tested against a captured token. No agent gets write access to domain federation settings; those changes run as reviewed scripts in a change window.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- inventory01
Relying party inventory with usage, owner, claims and target per trust
yours to keep - document02
Federation settings backup and documented rollback commands
yours to keep - guide03
Conditional Access policy set replacing AD FS access policies
yours to keep - runbook04
Domain conversion runbook and communication plan for users
yours to keep - document05
AD FS and WAP decommission checklist
yours to keep
Platforms and services on this move
Services involved
Learn the background
Terms from this page in plain English. If you want the why, the field note behind it is right there.
- 01Conditional access
- Rules evaluated at each sign-in that look at conditions such as user, device or location, and then allow, block or demand more proof.in context →
- 02Report-only mode
- A setting where the policy runs against real sign-ins and logs what it would have done. Nobody actually gets blocked.in context →
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Password hash sync or pass-through authentication?
Password hash sync is Microsoft's recommendation for cloud authentication, and it gives you leaked-credential detection too. If you can't allow password hashes in the cloud, pass-through authentication fits, at the cost of running agents on-premises. Either way we document the choice and why.
02Can we roll back if the domain conversion goes wrong?
Yes. As long as the federation settings are recorded and the farm is still running, New-MgDomainFederationConfiguration converts the domain back to federated. We schedule conversions outside business hours so a rollback doesn't land on users.
03Do all apps have to move at once?
No. Domains convert one at a time and relying parties move in waves. AD FS can keep serving some apps after Microsoft 365 sign-in has moved, until the last trust is migrated.
04Are we moving to Okta or Ping instead?
That works too. We do the same inventory, claim mapping and wave plan, and only the target changes. If Okta or Ping is already your primary identity provider, we plan the move there.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAuth0 Rules and Hooks to Actions before end of life
Rewriting Auth0 Rules and Hooks as Actions before their 18 November 2026 end of life, with token claims compared before and after each change.
read the case studyNasdaq Calypso upgrade to V19
Upgrading Nasdaq Calypso to V19, with server consolidation, properties moved to the database, the WebUI and deployment changes tested on your own trades.
read the case study7b3f4dff - 01Microsoft Learn: Migrate from federation to cloud authentication in Microsoft Entra IDlearn.microsoft.com ↗
- 02Microsoft Learn: Stages of migrating application authentication from AD FS to Entra IDlearn.microsoft.com ↗
- 03Microsoft Lifecycle: Windows Server 2016learn.microsoft.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it