Migrate from federation to cloud authentication

In this article, you learn how to deploy cloud user authentication with either Azure Active Directory Password hash synchronization (PHS) or Pass-through authentication (PTA). While we present the use case for moving from Active Directory Federation Services (AD FS) to cloud authentication methods, the guidance substantially applies to other on premises systems as well.

Before you continue, we suggest that you review our guide on choosing the right authentication method and compare methods most suitable for your organization.

We recommend using PHS for cloud authentication.

Staged rollout

Staged rollout is a great way to selectively test groups of users with cloud authentication capabilities like Azure AD Multi-Factor Authentication (MFA), Conditional Access, Identity Protection for leaked credentials, Identity Governance, and others, before cutting over your domains.

Refer to the staged rollout implementation plan to understand the supported and unsupported scenarios. We recommend using staged rollout to test before cutting over domains.

To learn how to configure staged rollout, see the staged rollout interactive guide migration to cloud authentication using staged rollout in Azure AD).

Migration process flow

Process flow for migrating to cloud auth


Before you begin your migration, ensure that you meet these prerequisites.

Required roles

For staged rollout, you need to be a Hybrid Identity Administrator on your tenant.

To enable seamless SSO on a specific Windows Active Directory Forest, you need to be a domain administrator.

Step up Azure AD Connect server

Install Azure Active Directory Connect (Azure AD Connect) or upgrade to the latest version. When you step up Azure AD Connect server, it reduces the time to migrate from AD FS to the cloud authentication methods from potentially hours to minutes.

Document current federation settings

To find your current federation settings, run Get-MgDomainFederationConfiguration.

Get-MgDomainFederationConfiguration –DomainID yourdomain.com

Verify any settings that might have been customized for your federation design and deployment documentation. Specifically, look for customizations in PreferredAuthenticationProtocol, federatedIdpMfaBehavior, SupportsMfa (if federatedIdpMfaBehavior is not set), and PromptLoginBehavior.

Back up federation settings

Although this deployment changes no other relying parties in your AD FS farm, you can back up your settings:

  • Use Microsoft AD FS Rapid Restore Tool to restore an existing farm or create a new farm.

  • Export the Microsoft 365 Identity Platform relying party trust and any associated custom claim rules you added using the following PowerShell example:

    (Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform") | Export-CliXML "C:\temp\O365-RelyingPartyTrust.xml"

Plan the project

When technology projects fail, it's typically because of mismatched expectations on impact, outcomes, and responsibilities. To avoid these pitfalls, ensure that you're engaging the right stakeholders and that stakeholder roles in the project are well understood.

Plan communications

After migrating to cloud authentication, the user sign-in experience for accessing Microsoft 365 and other resources that are authenticated through Azure AD changes. Users who are outside the network see only the Azure AD sign-in page.

Proactively communicate with your users how their experience will change, when it will change, and how to gain support if they experience issues.

Plan the maintenance window

After the domain conversion, Azure AD might continue to send some legacy authentication requests from Exchange Online to your AD FS servers for up to four hours. The delay is because the Exchange Online cache for legacy applications authentication can take up to 4 hours to be aware of the cutover from federation to cloud authentication.

During this four-hour window, you may prompt users for credentials repeatedly when reauthenticating to applications that use legacy authentication. Although the user can still successfully authenticate against AD FS, Azure AD no longer accepts the user's issued token because that federation trust is now removed.

Existing Legacy clients (Exchange ActiveSync, Outlook 2010/2013) aren't affected because Exchange Online keeps a cache of their credentials for a set period of time. The cache is used to silently reauthenticate the user. The user doesn't have to return to AD FS. Credentials stored on the device for these clients are used to silently reauthenticate themselves after the cached is cleared. Users aren't expected to receive any password prompts as a result of the domain conversion process.

Modern authentication clients (Office 2016 and Office 2013, iOS, and Android apps) use a valid refresh token to obtain new access tokens for continued access to resources instead of returning to AD FS. These clients are immune to any password prompts resulting from the domain conversion process. The clients will continue to function without extra configuration.


When you migrate from federated to cloud authentication, the process to convert the domain from federated to managed may take up to 60 minutes. During this process, users might not be prompted for credentials for any new logins to Azure portal or other browser based applications protected with Azure AD. We recommend that you include this delay in your maintenance window.

Plan for rollback


Consider planning cutover of domains during off-business hours in case of rollback requirements.

To plan for rollback, use the documented current federation settings and check the federation design and deployment documentation.

The rollback process should include converting managed domains to federated domains by using the Convert-MSOLDomainToFederated cmdlet. If necessary, configuring extra claims rules.

Migration considerations

Here are key migration considerations.

Plan for customizations settings

The onload.js file cannot be duplicated in Azure AD. If your AD FS instance is heavily customized and relies on specific customization settings in the onload.js file, verify if Azure AD can meet your current customization requirements and plan accordingly. Communicate these upcoming changes to your users.

experience

You cannot customize Azure AD sign-in experience. No matter how your users signed-in earlier, you need a fully qualified domain name such as User Principal Name (UPN) or email to sign into Azure AD.

Organization branding

You can customize the Azure AD sign-in page. Some visual changes from AD FS on sign-in pages should be expected after the conversion.


Organization branding is not available in free Azure AD licenses unless you have a Microsoft 365 license.

Plan for conditional access policies

Evaluate if you're currently using conditional access for authentication, or if you use access control policies in AD FS.

Consider replacing AD FS access control policies with the equivalent Azure AD Conditional Access policies and Exchange Online Client Access Rules. You can use either Azure AD or on-premises groups for conditional access.

Disable Legacy Authentication - Due to the increased risk associated with legacy authentication protocols create Conditional Access policy to block legacy authentication.

Plan support for MFA

For federated domains, MFA may be enforced by Azure AD Conditional Access or by the on-premises federation provider. You can enable protection to prevent bypassing of Azure MFA by configuring the security setting federatedIdpMfaBehavior. Enabling the protection for a federated domain in your Azure AD tenant makes sure that Azure MFA is always performed when a federated user accesses an application that is governed by a Conditional Access policy requiring MFA. This includes performing Azure MFA even when federated identity provider has issued federated token claims that on-prem MFA has been performed. Enforcing Azure MFA every time assures that a bad actor cannot bypass Azure MFA by imitating that MFA has already been performed by the identity provider, and is highly recommended unless you perform MFA for your federated users using a third party MFA provider.

The following table explains the behavior for each option. For more information, see federatedIdpMfaBehavior.

Value Description
acceptIfMfaDoneByFederatedIdp Azure AD accepts MFA that's performed by the federated identity provider. If the federated identity provider didn't perform MFA, Azure AD performs the MFA.
enforceMfaByFederatedIdp Azure AD accepts MFA that's performed by federated identity provider. If the federated identity provider didn't perform MFA, it redirects the request to federated identity provider to perform MFA.
rejectMfaByFederatedIdp Azure AD always performs MFA and rejects MFA that's performed by the federated identity provider.


The federatedIdpMfaBehavior setting is an evolved version of the SupportsMfa property of the Set-MsolDomainFederationSettings MSOnline v1 PowerShell cmdlet.

For domains that have already set the SupportsMfa property, these rules determine how federatedIdpMfaBehavior and SupportsMfa work together:

  • Switching between federatedIdpMfaBehavior and SupportsMfa is not supported.
  • Once federatedIdpMfaBehavior property is set, Azure AD ignores the SupportsMfa setting.
  • If the federatedIdpMfaBehavior property is never set, Azure AD will continue to honor the SupportsMfa setting.
  • If neither federatedIdpMfaBehavior nor SupportsMfa is set, Azure AD will default to acceptIfMfaDoneByFederatedIdp behavior.

You can check the status of protection by running Get-MgDomainFederationConfiguration:

Get-MgDomainFederationConfiguration -DomainId yourdomain.com

You can also check the status of your SupportsMfa flag with Get-MsolDomainFederationSettings:

Get-MsolDomainFederationSettings –DomainName yourdomain.com


Microsoft MFA Server is nearing the end of support life, and if you're using it you must move to Azure AD MFA. For more information, see Migrate from Microsoft MFA Server to Azure Multi-factor Authentication documentation. If you plan to use Azure AD MFA, we recommend that you use combined registration for self-service password reset (SSPR) and Multi-Factor Authentication to have your users register their authentication methods once.

Plan for implementation

This section includes pre-work before you switch your sign-in method and convert the domains.

Create necessary groups for staged rollout

If you're not using staged rollout, skip this step.

Create groups for staged rollout. You will also need to create groups for conditional access policies if you decide to add them.

We recommend you use a group mastered in Azure AD, also known as a cloud-only group. You can use Azure AD security groups or Microsoft 365 Groups for both moving users to MFA and for conditional access policies. For more information, see creating an Azure AD security group, and this overview of Microsoft 365 Groups for administrators.

The members in a group are automatically enabled for staged rollout. Nested and dynamic groups are not supported for staged rollout.

Pre-work for SSO

The version of SSO that you use is dependent on your device OS and join state.

Pre-work for PHS and PTA

Depending on the choice of sign-in method, complete the pre-work for PHS or for PTA.

Implement your solution

Finally, you switch the sign-in method to PHS or PTA, as planned and convert the domains from federation to cloud authentication.

Using staged rollout

If you're using staged rollout, follow the steps in the links below:

  1. Enable staged rollout of a specific feature on your tenant.

  2. Once testing is complete, convert domains from federated to managed.

Without using staged rollout

You have two options for enabling this change:

  • Option A: Switch using Azure AD Connect.

    Available if you initially configured your AD FS/ ping-federated environment by using Azure AD Connect.

  • Option B: Switch using Azure AD Connect and PowerShell

    Available if you didn't initially configure your federated domains by using Azure AD Connect or if you're using third-party federation services.

To choose one of these options, you must know what your current settings are.

Verify current Azure AD Connect settings

Sign in to the Azure AD portal, select Azure AD Connect and verify the USER SIGN_IN settings as shown in this diagram:

Verify current Azure AD Connect settings

To verify how federation was configured:

  1. On your Azure AD Connect server, open Azure AD Connect and select Configure.

  2. Under Additional Tasks > Manage Federation, select View federation configuration.

    View manage federation

    If the AD FS configuration appears in this section, you can safely assume that AD FS was originally configured by using Azure AD Connect. See the image below as an example-

    View AD FS configuration

    If AD FS isn't listed in the current settings, you must manually convert your domains from federated identity to managed identity by using PowerShell.

Option A

Switch from federation to the new sign-in method by using Azure AD Connect

  1. On your Azure AD Connect server, open Azure AD Connect and select Configure.

  2. Under Additional tasks page, select Change user sign-in, and then select Next.

    View Additional tasks

  3. On the Connect to Azure AD page, enter your Global Administrator account credentials.

  4. On the User sign-in page:

    • If you select Pass-through authentication option button, check Enable single sign-on, and then select Next.

    • If you select the Password hash synchronization option button, make sure to select the Do not convert user accounts check box. The option is deprecated. Check Enable single sign-on, and then select Next.

    Check enable single sign-on on User sign-in page

  5. On the Enable single sign-on page, enter the credentials of a Domain Administrator account, and then select Next.

    Enable single sign-on page

    Domain Administrator account credentials are required to enable seamless SSO. The process completes the following actions, which require these elevated permissions:

    • A computer account named AZUREADSSO (which represents Azure AD) is created in your on-premises Active Directory instance.
    • The computer account's Kerberos decryption key is securely shared with Azure AD.
    • Two Kerberos service principal names (SPNs) are created to represent two URLs that are used during Azure AD sign-in.

    The domain administrator credentials are not stored in Azure AD Connect or Azure AD and get discarded when the process successfully finishes. They are used to turn ON this feature.

  6. On the Ready to configure page, make sure that the Start the synchronization process when configuration completes check box is selected. Then, select Configure.

    Ready to configure page


At this point, all your federated domains will change to managed authentication. Your selected User sign-in method is the new method of authentication.

  1. In the Azure AD portal, select Azure Active Directory, and then select Azure AD Connect.

  2. Verify these settings:

    • Federation is set to Disabled.
    • Seamless single sign-on is set to Enabled.
    • Password Hash Sync is set to Enabled.

 Reverify current user settings

  1. In case you're switching to PTA, follow the next steps.
Deploy more authentication agents for PTA


PTA requires deploying lightweight agents on the Azure AD Connect server and on your on-premises computer that's running Windows server. To reduce latency, install the agents as close as possible to your Active Directory domain controllers.

For most customers, two or three authentication agents are sufficient to provide high availability and the required capacity. A tenant can have a maximum of 12 agents registered. The first agent is always installed on the Azure AD Connect server itself. To learn about agent limitations and agent deployment options, see Azure AD pass-through authentication: Current limitations.

  1. Select Pass-through authentication.

  2. On the Pass-through authentication page, select the Download button.

  3. On the Download agent page, select Accept terms and download.

    More authentication agents start to download. Install the secondary authentication agent on a domain-joined server.

  4. Run the authentication agent installation. During installation, you must enter the credentials of a Global Administrator account.

     Microsoft Azure AD Connect Authentication Agent

  5. When the authentication agent is installed, you can return to the PTA health page to check the status of the more agents.

Option B

Switch from federation to the new sign-in method by using Azure AD Connect and PowerShell

Available if you didn't initially configure your federated domains by using Azure AD Connect or if you're using third-party federation services.

On your Azure AD Connect server, follow the steps 1- 5 in Option A. You will notice that on the User sign-in page, the Do not configure option is pre-selected.

 See Do not Configure option on the user sign-in page

  1. In the Azure AD portal, select Azure Active Directory, and then select Azure AD Connect.

  2. Verify these settings:

  • Federation is set to Enabled.

  • Seamless single sign-on is set to Disabled.

  • Password Hash Sync is set to Enabled.

     Verify current user settings on the Azure portal

In case of PTA only, follow these steps to install more PTA agent servers.

  1. In the Azure AD portal, select Azure Active Directory, and then select Azure AD Connect.

  2. Select Pass-through authentication. Verify that the status is Active.

     Pass-through authentication settings

    If the authentication agent isn't active, complete these troubleshooting steps before you continue with the domain conversion process in the next step. You risk causing an authentication outage if you convert your domains before you validate that your PTA agents are successfully installed and that their status is Active in the Azure portal.

  3. Deploy more authentication agents.

Convert domains from federated to managed

At this point, federated authentication is still active and operational for your domains. To continue with the deployment, you must convert each domain from federated identity to managed identity.


You don't have to convert all domains at the same time. You might choose to start with a test domain on your production tenant or start with your domain that has the lowest number of users.

Complete the conversion by using the Microsoft Graph PowerShell SDK:

  1. In PowerShell, sign in to Azure AD by using a Global Administrator account.

     Connect-MGGraph -Scopes "Domain.ReadWrite.All", "Directory.AccessAsUser.All"
  2. To convert the first domain, run the following command:

     Update-MgDomain -DomainId <domain name> -AuthenticationType "Managed"

    See [Update-MgDomain](/powershell/module/microsoft.graph.identity.directorymanagement/update-mgdomain?view=graph-powershell-1.0 &preserve-view=true)

  3. In the Azure AD portal, select Azure Active Directory > Azure AD Connect.

  4. Verify that the domain has been converted to managed by running the following command:

    Get-MgDomainFederationConfiguration -DomainId yourdomain.com

Complete your migration

Complete the following tasks to verify the sign-up method and to finish the conversion process.

Test the new sign-in method

When your tenant used federated identity, users were redirected from the Azure AD sign-in page to your AD FS environment. Now that the tenant is configured to use the new sign-in method instead of federated authentication, users aren't redirected to AD FS.

Instead, users sign in directly on the Azure AD sign-in page.

Follow the steps in this link - Validate sign-in with PHS/ PTA and seamless SSO (where required)

Remove a user from staged rollout

If you used staged rollout, you should remember to turn off the staged rollout features once you have finished cutting over.

To disable the staged rollout feature, slide the control back to Off.

Sync UserPrincipalName updates

Historically, updates to the UserPrincipalName attribute, which uses the sync service from the on-premises environment, are blocked unless both of these conditions are true:

  • The user is in a managed (non-federated) identity domain.
  • The user hasn't been assigned a license.

To learn how to verify or turn on this feature, see Sync userPrincipalName updates.

Manage your implementation

Roll over the seamless SSO Kerberos decryption key

We recommend that you roll over the Kerberos decryption key at least every 30 days to align with the way that Active Directory domain members submit password changes. There is no associated device attached to the AZUREADSSO computer account object, so you must perform the rollover manually.

See FAQ How do I roll over the Kerberos decryption key of the AZUREADSSO computer account?.

Monitoring and logging

Monitor the servers that run the authentication agents to maintain the solution availability. In addition to general server performance counters, the authentication agents expose performance objects that can help you understand authentication statistics and errors.

Authentication agents log operations to the Windows event logs that are located under Application and Service logs. You can also turn on logging for troubleshooting.

To confirm the various actions performed on staged rollout, you can Audit events for PHS, PTA, or seamless SSO.


Your support team should understand how to troubleshoot any authentication issues that arise either during, or after the change from federation to managed. Use the following troubleshooting documentation to help your support team familiarize themselves with the common troubleshooting steps and appropriate actions that can help to isolate and resolve the issue.

Decommission AD FS infrastructure

Migrate app authentication from AD FS to Azure AD

Migration requires assessing how the application is configured on-premises, and then mapping that configuration to Azure AD.

If you plan to keep using AD FS with on-premises & SaaS Applications using SAML / WS-FED or Oauth protocol, you'll use both AD FS and Azure AD after you convert the domains for user authentication. In this case, you can protect your on-premises applications and resources with Secure Hybrid Access (SHA) through Azure AD Application Proxy or one of Azure AD partner integrations. Using Application Proxy or one of our partners can provide secure remote access to your on-premises applications. Users benefit by easily connecting to their applications from any device after a single sign-on.

You can move SaaS applications that are currently federated with ADFS to Azure AD. Reconfigure to authenticate with Azure AD either via a built-in connector from the Azure App gallery, or by registering the application in Azure AD.

For more information, see –

Remove relying party trust

If you have Azure AD Connect Health, you can monitor usage from the Azure portal. In case the usage shows no new auth req and you validate that all users and clients are successfully authenticating via Azure AD, it's safe to remove the Microsoft 365 relying party trust.

If you don't use AD FS for other purposes (that is, for other relying party trusts), you can decommission AD FS at this point.

Remove AD FS

For a full list of steps to take to completely remove AD FS from the environment follow the Active Directory Federation Services (AD FS) decommision guide.

Next steps