Site icon Windows Active Directory

Migrating from AD FS to Azure AD SSO

Arun Kumar

Many organizations built their hybrid identity strategy around Active Directory Federation Services (AD FS) for single sign-on (SSO). Today, Microsoft Entra ID (formerly Azure AD) can deliver the same sign-in experience for most apps—often with less infrastructure, lower operational overhead, and better native controls like Conditional Access.

This guide walks you through a practical, low-risk migration from AD FS to Entra ID SSO, including assessment, pilot, cutover, and decommissioning.

What “migrating off AD FS” actually means

In most environments, “AD FS to Entra SSO” means moving from federated authentication (AD FS issuing tokens) to one of these Entra-backed models:

  • Password Hash Synchronization (PHS) + Seamless SSO: Entra validates a synced password hash. Simple, resilient, lowest operational complexity.
  • Pass-through Authentication (PTA) + Seamless SSO: Entra forwards auth to on-prem agents that validate against AD DS. Useful when you can’t/won’t sync password hashes.
  • Federation kept only for edge cases: Some legacy requirements may keep AD FS temporarily while most apps move to Entra.

If you want a quick refresher on how Entra SSO works conceptually before you design the migration, read: Microsoft Entra Single Sign-On: Explained.

Why organizations move away from AD FS

  • Lower infrastructure and patching burden (no federation farm/WAP dependency for most scenarios)
  • Better cloud-native access control (Conditional Access, identity protection, session controls)
  • More consistent user experience across Microsoft 365 and SaaS apps
  • Improved resiliency (especially with PHS) if on-prem connectivity is disrupted

Prerequisites and readiness checklist

  • Verified custom domains in Entra ID (do not cut over sign-in domains until verified)
  • Azure AD Connect / Entra Connect in place (or a plan to install) to support PHS/PTA and Seamless SSO
  • Inventory of relying party trusts / apps currently federated through AD FS
  • MFA approach decided (Entra MFA / Conditional Access vs. AD FS MFA adapters)
  • Certificate and claims mapping review for apps that depend on custom claims or signing certs
  • Communications plan for users, helpdesk, and app owners

If you need to align your hybrid identity foundation first, this deep dive helps you choose and operate the right sync + auth model: Azure AD Connect: What it is, how it works; best practices.

Phase 1: Discover and classify AD FS dependencies

1) Build the application inventory

Document every application currently relying on AD FS. For each app, capture:

  • Protocol: SAML, WS-Fed, OAuth/OIDC
  • Sign-in URL, entity ID (SAML), reply URLs, identifiers
  • Claims required (UPN/email/ImmutableID/group claims/custom)
  • Who owns it (app team/vendor), user population, criticality, support contacts
  • Current MFA behavior and exceptions

2) Categorize apps by migration path

  • Easy: SaaS apps with Entra gallery support (SAML/OIDC supported natively)
  • Moderate: Custom line-of-business apps that can be updated to OIDC/SAML with Entra
  • Hard: Legacy WS-Fed or apps tightly coupled to AD FS claims rules/certs

Phase 2: Choose your target sign-in model (PHS vs PTA)

Recommendation for most orgs: PHS + Seamless SSO

  • Resilient: users can authenticate even if on-prem is down
  • Simpler operations: fewer moving parts than PTA
  • Works well with Conditional Access and modern auth patterns

When PTA is still a fit

  • Strict policy prevents password hash sync (even though hashes are not reversible)
  • Requirement to validate passwords only against on-prem AD at sign-in time

Phase 3: Prepare Entra ID for production SSO

1) Establish your access control baseline

  • Define Conditional Access policies (MFA, device compliance, locations, risk-based controls)
  • Plan break-glass accounts (cloud-only, excluded from CA, strong protection)
  • Decide how you will handle legacy authentication (block where possible)

2) Ensure your federation and app protocol posture is clean

During migration you’ll likely touch SAML and/or OpenID Connect configuration in Entra. Use these references when you’re mapping apps off AD FS:

Phase 4: Pilot (do not “big bang”)

1) Start with a controlled pilot group

  • Select 1–3 low-risk apps and a small user cohort (IT + a friendly business team)
  • Move those apps to Entra SSO while keeping the rest on AD FS
  • Run a parallel validation window (sign-in tests, MFA prompts, device flows)

2) Validate the “gotchas” that usually break pilots

  • Identifier mismatch: app expects UPN vs email vs immutable ID
  • Group claims: token size issues or different group formats
  • MFA behavior: Conditional Access prompts differ from AD FS rules
  • Legacy clients: older apps may not support modern auth well

Phase 5: Migrate applications in waves

Move applications in “waves” based on the inventory you built:

  • Wave 1 (easy): Entra gallery SaaS apps (SAML/OIDC), minimal claims customization
  • Wave 2 (moderate): custom apps with manageable claims and tested token flows
  • Wave 3 (hard): legacy apps—upgrade, re-platform, or isolate with temporary federation

For each app cutover:

  1. Configure the app in Entra (SAML/OIDC settings, certificates, reply URLs, claims)
  2. Assign pilot users and test end-to-end
  3. Expand assignment to the full population
  4. Switch the app’s trust from AD FS to Entra (vendor/admin setting) and monitor

Phase 6: Cut over the tenant from “federated” to “managed” (if applicable)

If your primary sign-in domain in Entra is currently set to federated with AD FS, the final step is switching it to managed (PHS/PTA). This is a high-impact change—do it only after you’ve proven that apps and authentication flows are ready.

Cutover principles

  • Do it during a planned change window with helpdesk coverage
  • Have a rollback plan (and test the rollback steps in advance)
  • Communicate clearly what users may see (re-login prompts, MFA prompts, new consent screens)

Phase 7: Monitor and stabilize

  • Track sign-in success/failure rates and Conditional Access impact
  • Look for spikes in password resets, lockouts, and MFA challenges
  • Confirm Seamless SSO behavior on domain-joined devices
  • Validate critical apps again after the domain auth cutover (if performed)

If you want a health-first approach to diagnosing hybrid authentication issues during the migration, use this troubleshooting reference: Azure AD Connect Health – Troubleshooting Hybrid identity scenarios.

Phase 8: Decommission AD FS safely

Only decommission AD FS when:

  • All relying party trusts have been migrated or retired
  • No sign-in traffic depends on AD FS (confirm via logs over a meaningful period)
  • All external dependencies are accounted for (partners, extranet, legacy endpoints)

Decommission checklist

  • Freeze AD FS configuration changes
  • Export and archive AD FS configuration and certificates (for audit/forensics)
  • Remove DNS dependencies and load balancer configs gradually
  • Decommission WAP first (if used), then federation servers
  • Update documentation, runbooks, and incident procedures

Common pitfalls (and how to avoid them)

  • Underestimating custom claims rules: Map every claim used by apps and replicate in Entra (or change the app to accept standard claims).
  • MFA surprises: Conditional Access is policy-driven and can behave differently than AD FS MFA adapters. Pilot MFA-heavy apps early.
  • Token bloat: Group claims and nested groups can create large tokens. Prefer app roles or scoped group assignment where possible.
  • Legacy authentication: Some older clients will fail when you tighten controls. Identify and modernize them before wave cutovers.
  • Rushing domain cutover: Migrating apps first usually reduces blast radius. Flip the domain from federated to managed only after proven readiness.

Quick “ideal” migration plan (copy/paste for your change proposal)

  1. Week 1–2: Inventory AD FS apps, classify by protocol and complexity
  2. Week 2–3: Configure Entra baseline (CA, MFA approach, break-glass, logging)
  3. Week 3–4: Pilot 2–3 apps + pilot user group; validate Seamless SSO
  4. Month 2: Migrate Wave 1 SaaS apps; stabilize
  5. Month 3: Migrate Wave 2 custom apps; stabilize
  6. Month 4+: Handle Wave 3 legacy apps; retire/upgrade as needed
  7. Final: Convert federated domain to managed (if needed), then decommission AD FS

FAQ

Will users notice the change?

If you plan well, most users only see a one-time sign-in prompt or updated MFA prompt behavior. The biggest “felt” changes usually come from Conditional Access rollout and legacy client remediation.

Do we still need AD FS for Microsoft 365?

In most cases, no. Entra ID can handle Microsoft 365 authentication directly using PHS or PTA. AD FS is typically retained only for specific legacy app requirements.

Can we migrate gradually?

Yes—and you usually should. Migrate applications in waves first, then perform any tenant/domain authentication cutover only after stability.

Exit mobile version