Migrate to cloud authentication using staged rollout
Staged rollout allows you 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. This article discusses how to make the switch. Before you begin the staged rollout, however, you should consider the implications if one or more of the following conditions is true:
- You're currently using an on-premises Multi-Factor Authentication server.
- You're using smart cards for authentication.
- Your current server offers certain federation-only features.
Before you try this feature, we suggest that you review our guide on choosing the right authentication method. For more information, see the "Comparing methods" table in Choose the right authentication method for your Azure Active Directory hybrid identity solution.
For an overview of the feature, view this "Azure Active Directory: What is staged rollout?" video:
You have an Azure Active Directory (Azure AD) tenant with federated domains.
You have decided to move to either of two options:
- Option A - password hash synchronization (sync). For more information, see What is password hash sync
- Option B - pass-through authentication. For more information, see What is pass-through authentication
For both options, we recommend enabling single sign-on (SSO) to achieve a silent sign-in experience. For Windows 7 or 8.1 domain-joined devices, we recommend using seamless SSO. For more information, see What is seamless SSO. For Windows 10, Windows Server 2016 and later versions, it’s recommended to use SSO via Primary Refresh Token (PRT) with Azure AD joined devices, hybrid Azure AD joined devices or personal registered devices via Add Work or School Account.
You have configured all the appropriate tenant-branding and conditional access policies you need for users who are being migrated to cloud authentication.
If you plan to use Azure AD Multi-Factor Authentication, 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. Note- when using SSPR to reset password or change password using MyProfile page while in Staged rollout, Azure AD Connect needs to sync the new password hash which can take up to 2 minutes after reset.
To use the staged rollout feature, you need to be a global administrator on your tenant.
To enable seamless SSO on a specific Active Directory forest, you need to be a domain administrator.
If you are deploying Hybrid Azure AD or Azure AD join, you must upgrade to Windows 10 1903 update.
The following scenarios are supported for staged rollout. The feature works only for:
Users who are provisioned to Azure AD by using Azure AD Connect. It does not apply to cloud-only users.
User sign-in traffic on browsers and modern authentication clients. Applications or cloud services that use legacy authentication will fall back to federated authentication flows. An example might be Exchange online with modern authentication turned off, or Outlook 2010, which does not support modern authentication.
Group size is currently limited to 50,000 users. If you have groups that are larger then 50,000 users, it is recommended to split this group over multiple groups for staged rollout.
Windows 10 Hybrid Join or Azure AD Join primary refresh token acquisition without line-of-sight to the federation server for Windows 10 version 1903 and newer, when user’s UPN is routable and domain suffix is verified in Azure AD.
Autopilot enrollment is supported in Staged rollout with Windows 10 version 1909 or later.
The following scenarios are not supported for staged rollout:
Legacy authentication such as POP3 and SMTP are not supported.
Certain applications send the "domain_hint" query parameter to Azure AD during authentication. These flows will continue, and users who are enabled for staged rollout will continue to use federation for authentication.
Admins can roll out cloud authentication by using security groups. To avoid sync latency when you're using on-premises Active Directory security groups, we recommend that you use cloud security groups. The following conditions apply:
- You can use a maximum of 10 groups per feature. That is, you can use 10 groups each for password hash sync, pass-through authentication, and seamless SSO.
- Nested groups are not supported.
- Dynamic groups are not supported for staged rollout.
- Contact objects inside the group will block the group from being added.
When you first add a security group for staged rollout, you're limited to 200 users to avoid a UX time-out. After you've added the group, you can add more users directly to it, as required.
While users are in Staged Rollout, password expiration policy is set to 90 days with no option to customize it.
Windows 10 Hybrid Join or Azure AD Join primary refresh token acquisition for Windows 10 version older than 1903. This scenario will fall back to the WS-Trust endpoint of the federation server, even if the user signing in is in scope of staged rollout.
Windows 10 Hybrid Join or Azure AD Join primary refresh token acquisition for all versions, when user’s on-premises UPN is not routable. This scenario will fall back to the WS-Trust endpoint while in staged rollout mode, but will stop working when staged migration is complete and user sign-on is no longer relying on federation server.
If you have a non-persistent VDI setup with Windows 10, version 1903 or later, you must remain on a federated domain. Moving to a managed domain isn't supported on non-persistent VDI. For more information, see Device identity and desktop virtualization.
If you have a Windows Hello for Business hybrid certificate trust with certs that are issued via your federation server acting as Registration Authority or smartcard users, the scenario isn't supported on a staged rollout.
You still need to make the final cutover from federated to cloud authentication by using Azure AD Connect or PowerShell. Staged rollout doesn't switch domains from federated to managed. For more information about domain cutover, see Migrate from federation to password hash synchronization and Migrate from federation to pass-through authentication.
Get started with staged rollout
To test the password hash sync sign-in by using staged rollout, follow the pre-work instructions in the next section.
For information about which PowerShell cmdlets to use, see Azure AD 2.0 preview.
Pre-work for password hash sync
Enable password hash sync from the Optional features page in Azure AD Connect.
Ensure that a full password hash sync cycle has run so that all the users' password hashes have been synchronized to Azure AD. To check the status of password hash sync, you can use the PowerShell diagnostics in Troubleshoot password hash sync with Azure AD Connect sync.
If you want to test pass-through authentication sign-in by using staged rollout, enable it by following the pre-work instructions in the next section.
Pre-work for pass-through authentication
Identify a server that's running Windows Server 2012 R2 or later where you want the pass-through authentication agent to run.
Do not choose the Azure AD Connect server. Ensure that the server is domain-joined, can authenticate selected users with Active Directory, and can communicate with Azure AD on outbound ports and URLs. For more information, see the "Step 1: Check the prerequisites" section of Quickstart: Azure AD seamless single sign-on.
Download the Azure AD Connect authentication agent, and install it on the server.
To enable high availability, install additional authentication agents on other servers.
Make sure that you've configured your Smart Lockout settings appropriately. Doing so helps ensure that your users' on-premises Active Directory accounts don't get locked out by bad actors.
We recommend enabling seamless SSO irrespective of the sign-in method (password hash sync or pass-through authentication) you select for staged rollout. To enable seamless SSO, follow the pre-work instructions in the next section.
Pre-work for seamless SSO
Enable seamless SSO on the Active Directory forests by using PowerShell. If you have more than one Active Directory forest, enable it for each forest individually. Seamless SSO is triggered only for users who are selected for staged rollout. It doesn't affect your existing federation setup.
Enable seamless SSO by doing the following:
Sign in to Azure AD Connect Server.
Go to the %programfiles%\Microsoft Azure Active Directory Connect folder.
Import the seamless SSO PowerShell module by running the following command:
Run PowerShell as an administrator. In PowerShell, call
New-AzureADSSOAuthenticationContext. This command opens a pane where you can enter your tenant's global administrator credentials.
Get-AzureADSSOStatus | ConvertFrom-Json. This command displays a list of Active Directory forests (see the "Domains" list) on which this feature has been enabled. By default, it is set to false at the tenant level.
$creds = Get-Credential. At the prompt, enter the domain administrator credentials for the intended Active Directory forest.
Enable-AzureADSSOForest -OnPremCredentials $creds. This command creates the AZUREADSSOACC computer account from the on-premises domain controller for the Active Directory forest that's required for seamless SSO.
Seamless SSO requires URLs to be in the intranet zone. To deploy those URLs by using group policies, see Quickstart: Azure AD seamless single sign-on.
For a complete walkthrough, you can also download our deployment plans for seamless SSO.
Enable staged rollout
To roll out a specific feature (pass-through authentication, password hash sync, or seamless SSO) to a select set of users in a group, follow the instructions in the next sections.
Enable a staged rollout of a specific feature on your tenant
You can roll out one of these options:
- Option A - password hash sync + seamless SSO
- Option B - pass-through authentication + seamless SSO
- Not supported - password hash sync + pass-through authentication + seamless SSO
Do the following:
To access the UX, sign in to the Azure AD portal.
Select the Enable staged rollout for managed user sign-in link.
For example, if you want to enable Option A, slide the Password Hash Sync and Seamless single sign-on controls to On, as shown in the following images.
Add the groups to the feature to enable pass-through authentication and seamless SSO. To avoid a UX time-out, ensure that the security groups contain no more than 200 members initially.
The members in a group are automatically enabled for staged rollout. Nested and dynamic groups are not supported for staged rollout. When adding a new group, users in the group (up to 200 users for a new group) will be updated to use managed auth immediately. Editing a group (adding or removing users), it can take up to 24 hours for changes to take effect. Seamless SSO will apply only if users are in the Seamless SSO group and also in either a PTA or PHS group.
We've enabled audit events for the various actions we perform for staged rollout:
Audit event when you enable a staged rollout for password hash sync, pass-through authentication, or seamless SSO.
An audit event is logged when seamless SSO is turned on by using staged rollout.
Audit event when a group is added to password hash sync, pass-through authentication, or seamless SSO.
An audit event is logged when a group is added to password hash sync for staged rollout.
Audit event when a user who was added to the group is enabled for staged rollout.
To test the sign-in with password hash sync or pass-through authentication (username and password sign-in), do the following:
On the extranet, go to the Apps page in a private browser session, and then enter the UserPrincipalName (UPN) of the user account that's selected for staged rollout.
Users who've been targeted for staged rollout are not redirected to your federated login page. Instead, they're asked to sign in on the Azure AD tenant-branded sign-in page.
Ensure that the sign-in successfully appears in the Azure AD sign-in activity report by filtering with the UserPrincipalName.
To test sign-in with seamless SSO:
On the intranet, go to the Apps page in a private browser session, and then enter the UserPrincipalName (UPN) of the user account that's selected for staged rollout.
Users who've been targeted for staged rollout of seamless SSO are presented with a "Trying to sign you in ..." message before they're silently signed in.
Ensure that the sign-in successfully appears in the Azure AD sign-in activity report by filtering with the UserPrincipalName.
To track user sign-ins that still occur on Active Directory Federation Services (AD FS) for selected staged rollout users, follow the instructions at AD FS troubleshooting: Events and logging. Check vendor documentation about how to check this on third-party federation providers.
You can monitor the users and groups added or removed from staged rollout and users sign-ins while in staged rollout, using the new Hybrid Auth workbooks in the Azure portal.
Remove a user from staged rollout
Removing a user from the group disables staged rollout for that user. To disable the staged rollout feature, slide the control back to Off.
Frequently asked questions
Q: Can I use this capability in production?
A: Yes, you can use this feature in your production tenant, but we recommend that you first try it out in your test tenant.
Q: Can this feature be used to maintain a permanent "co-existence," where some users use federated authentication and others use cloud authentication?
A: No, this feature is designed for testing cloud authentication. After successful testing a few groups of users you should cut over to cloud authentication. We do not recommend using a permanent mixed state, because this approach could lead to unexpected authentication flows.
Q: Can I use PowerShell to perform staged rollout?
A: Yes. To learn how to use PowerShell to perform staged rollout, see Azure AD Preview.