Why leave AD FS federation?
If your AD FS (Active Directory Federation Services) farm goes down, all your users are immediately blocked: no access to Teams, Outlook, SharePoint or any other cloud service. The dependency on critical on-premises infrastructure, available 24/7, is precisely the Achilles heel of classic federation.
The shift to cloud authentication (managed directly by Entra ID) is the sustainable solution. However, the official method for converting a federated domain to a managed domain applies instantly to all users in the domain, with no possibility of progressive rollback. If a misconfiguration goes unnoticed, you discover it in production, for everyone, simultaneously. This is precisely why many IT teams indefinitely delay this migration.
Good to know
Staged Rollout is Microsoft's answer to this problem: it allows you to test cloud authentication on a subset of users, while the rest of the organization continues to authenticate via AD FS, with no visible change for them.
How AD FS federation works
Before discussing Staged Rollout, it's useful to review the federated authentication flow:
- The user opens Outlook and enters their email address.
- Entra ID identifies the domain as federated and redirects the user to the federation server (AD FS or a third party).
- AD FS verifies the password against Active Directory, issues a SAML or WS-Federation token.
- The user is returned to Entra ID with the token, which finalizes the session.
This flow requires maintaining an AD FS server farm, certificates, proxies (WAP), and permanent high availability — solely to allow users to authenticate.
Staged Rollout: the progressive migration mechanism
Staged Rollout (phased deployment) is a mechanism provided by Microsoft to test the migration to managed authentication without changing the domain's federated status. It works as follows:
- You designate a pilot group of users in Entra ID.
- A background process stamps a hidden attribute on each account member of the group.
- At login, Entra ID reads this attribute and, if present, processes authentication in cloud mode, without delegating to AD FS.
- Users not in the pilot group continue to authenticate normally via federation.
Attention
Staged Rollout is a testing tool, not a permanent configuration. Microsoft is explicit on this point: the final objective is to convert the domain to managed mode. Maintaining indefinitely a hybrid state (some users federated, others managed) is not a supported architecture long-term.
The three available cloud authentication methods
| Method | How it works | Complexity | Recommended |
|---|---|---|---|
| Password Hash Sync (PHS) | Password hashes are synchronized to Entra ID every 2 minutes | Low | âś… Yes |
| Pass-Through Authentication (PTA) | Entra ID delegates verification to lightweight agents installed on-premises | Medium | ⚠️ Depending on context |
| Certificate-Based Authentication (CBA) | Certificate-based authentication, resistant to phishing | High | ⚠️ Expensive |
For most organizations, Password Hash Sync is the recommended choice. It removes any dependency on on-premises infrastructure for cloud authentication and provides maximum resilience: if your Active Directory is unavailable, users continue to connect to cloud services.
Password Hash Sync: what is really synchronized
A common confusion concerns the nature of the data synchronized. Here is the exact process:
- Entra Connect retrieves the NTLM password hash from Active Directory.
- This hash is itself hashed a second time with a salt specific to Microsoft before being transmitted.
- The final hash is stored in Entra ID and cannot be used to authenticate against your Active Directory domain.
- Synchronization occurs approximately every 2 minutes.
Tip
Enable Password Hash Sync even if you use Pass-Through Authentication or AD FS. It serves as an automatic failover mechanism in case of failure of your PTA agents or your AD FS farm.
The hidden attribute: the secret of Staged Rollout
This is the technical point that most documentation does not explain clearly. Contrary to what one might think, Entra ID never directly consults the pilot group at the time of authentication.
Here is the actual mechanism:
- A background job monitors membership in the Staged Rollout group.
- When a user is added to the group, the job writes a hidden attribute on the user object in Entra ID, indicating that this account should use managed authentication.
- At each login, Entra ID reads this attribute on the account, not the group.
This architecture explains several important behaviors:
- Changes in group membership can take up to 24 hours to take effect.
- Nested groups and dynamic groups are not supported.
- The first addition is limited to 200 users maximum.
Important
Do not plan an emergency failover by massively adding users to the Staged Rollout group and expecting immediate effect. The attribute propagation delay can reach 24 hours. Anticipate this delay in your migration planning.
Implementing Staged Rollout: step-by-step procedure
Prerequisites: enable Password Hash Sync in Entra Connect
First, ensure that Password Hash Sync is enabled in your Entra Connect configuration (formerly Azure AD Connect) and that a full synchronization cycle has been executed. Check in the Entra ID > Connect Health portal that synchronization is active and error-free.
Enable Staged Rollout from the Entra ID portal
Navigate to Entra ID > Hybrid identity management > Entra Connect > Connect Sync, then select Enable phased rollout for managed user sign-in.
Enable the Password Hash Sync toggle, then click Manage groups to add your pilot group. Start with a group of fewer than 200 members for the first deployment.
Validate the pilot group authentication
Log in with an account that is a member of the pilot group. If Staged Rollout is working correctly, you will be redirected to the Entra ID sign-in page with your organization's branding, not to your AD FS page. The absence of the AD FS page confirms that cloud authentication is active for this account.
Also monitor the sign-in logs in Entra ID > Monitoring > Sign-in logs to confirm that the authentication method is indeed Password Hash Sync.
Monitor and expand progressively
During the pilot phase, monitor:
- The Entra ID sign-in logs filtered on the pilot group.
- The hybrid authentication workbooks available in the Microsoft 365 admin center.
- The AD FS logs to identify users still going through federation (legacy protocols in particular).
Expand the pilot group progressively by validating each iteration.
Final conversion of the domain to managed
Once validation is complete, the final migration is performed with a single PowerShell command via the Microsoft Graph module. Connect with Domain.ReadWrite.All permissions:
1# Connect to Microsoft Graph with necessary permissions2Connect-MgGraph -Scopes "Domain.ReadWrite.All"3 4# Convert the federated domain to managed domain5Update-MgDomain -DomainId "yourdomain.com" -AuthenticationType "Managed"6 7# Verify status after conversion8Get-MgDomain -DomainId "yourdomain.com" | Select-Object Id, AuthenticationTypeThis command is irreversible in the short term and can take up to one hour to propagate. Schedule execution during a maintenance window, outside peak hours.
Post-migration: disable Staged Rollout
After domain conversion, return to the Staged Rollout configuration and disable it. Keeping Staged Rollout active after conversion is unnecessary and may generate unexpected behaviors. Your AD FS farm can then be decommissioned according to your schedule.
Limitations and use cases to exclude from the pilot
Staged Rollout does not cover all authentication scenarios. Take these limitations into account when forming your pilot group:
- Legacy authentication protocols (IMAP, POP3, SMTP AUTH, EWS Basic): they ignore the Staged Rollout attribute and continue to go through federation.
- Applications sending a domain hint: if an application forces redirection to AD FS via a
domain_hintparameter, Staged Rollout is bypassed. - Password writeback: behavior is not guaranteed for users in Staged Rollout with Password Hash Sync. Explicitly test self-service password reset.
- Password expiration: by default, expiration is not enforced for users in Staged Rollout mode.
- Non-persistent VDI: must remain in federated mode.
- Windows Hello for Business (certificates) and smart cards: not supported in Staged Rollout.
Tip
Constitute your pilot group intentionally: choose users who do not use legacy protocols, no VDI, and who have cloud MFA methods configured. Avoid service accounts and administrative accounts in the initial phase.
Summary of AD FS to Password Hash Sync migration
Migration from AD FS to Entra ID managed authentication is a project structured in three main phases:
Phase 1 — Preparation
- Enable and verify Password Hash Sync in Entra Connect
- Audit applications and authentication protocols in use
- Form a representative but limited pilot group
Phase 2 — Testing with Staged Rollout
- Enable Staged Rollout for the pilot group
- Validate sign-ins, conditional access policies, and MFA flows
- Gradually expand scope while monitoring metrics
Phase 3 — Conversion and decommissioning
- Execute the
Update-MgDomaincommand during a maintenance window - Verify propagation with
Get-MgDomain - Disable Staged Rollout
- Plan the decommissioning of the AD FS farm
Staged Rollout is the tool that transforms a risky migration into a controlled and validatable process. It does not replace the rigor of preparation, but it provides the safety net that IT teams need to move forward with confidence.
