How to Use Staged Rollout to Migrate to Azure Active Directory Single Sign-On

Are you ready to make the move to Azure Active Directory (AD) single sign-on (SSO)? Do you want to avoid the complications of federated authentication for Microsoft 365? Are you unsure about switching your entire organization over at once? Azure AD’s cloud authentication staged rollout might be the answer.

Background to Azure AD SSO

Azure AD provides a sophisticated SSO platform that can be integrated with almost all Security Assertion Markup Language (SAML) and OpenID Connect (OIDC) relying parties. Any tier (including the free tier, with some limitations) can take advantage of Azure AD SSO, including Azure multi-factor authentication (MFA). Additionally, anyone already using Microsoft 365 can have Azure AD act as an identity provider (IdP) for relying parties even if they are using another IdP (e.g., federated authentication) for sign-in to Microsoft 365. This makes Azure AD SSO an extremely competitive offering in the SSO space compared to the costs of other commercial SSO providers or the resources required to run an open-source SSO platform.

Moving to another SSO platform is not an easy undertaking. Most applications do not support multiple identity providers. In addition, there may also be a move to a new MFA provider that is supported natively by your IdP (e.g., Azure MFA with Azure AD SSO). Chances are, almost everyone in your organization uses an organization-wide app such as Office 365. Changing your users’ login experience all at once will have an enormous impact on them.

The huge amount of pre-work and the required lift and shift might be enough to deter you from even considering moving to another SSO provider, despite the cost and time benefits of Azure AD SSO in the long run. But fortunately, Azure AD has a feature to help make this move quite a bit easier: staged rollout.

Azure AD Staged Rollout

Staged rollout allows you to disable federated authentication and use either password hash sync or pass-through authentication for a subset of your Azure AD tenant. This lets you pilot using Azure AD SSO with Office 365 (and any applications you register with Azure AD) with a much smaller group. All features such as Azure MFA, Conditional Access, and Identity Governance work in staged rollout mode, allowing you to comprehensively test using Azure AD fully for SSO before switching over more users.

We can take this pilot one step further and use staged rollout to switch over select groups of individuals. Perhaps your organization has some applications that only small subsets of users use. You can register those apps in Azure AD and then add the apps’ populations to staged rollout to slowly grow the population that is exclusively using Azure AD SSO. Note that staged rollout is on a per-user rather than per-app basis. Enrolling a user in staged rollout will affect their login experience to all applications the user is assigned to within Azure AD.

If you are also working on having your organization enroll in Azure MFA, using staged rollout with smaller application populations allows you to target enrollment to specific users (smaller populations) at first. This approach makes the required change management a much easier effort.

Deploying Staged Rollout

The first thing you need to do is configure Azure AD Connect for password hash sync or deploy the Azure AD Connect Authentication Agent for pass-through authentication. This task is no different than if you were planning to switch your entire tenant over at once. However, do not change any of the user sign-in options in Azure AD Connect at this time.

Next, you need to determine which population(s) you want to switch to native cloud authentication first. You can configure up to 10 security groups to use staged rollout. Each group can contain up to 50,000 members, although you must add a group to staged rollout before populating it with more than 200 members. Unfortunately, nested and dynamic groups are currently unsupported (as of June 2022). However, it is easy enough to use the bulk import feature to import a list of users to a group in Azure AD.

If you have multiple Azure AD domains, you might want to break out the groups by domain, with each domain containing a subset of the population to test out native Azure AD SSO. Note that you can switch over individual domains to managed/cloud authentication while still using staged rollout for the remaining domains.

In the Azure AD Admin Center, click Azure AD Connect, then click the “Enable staged rollout for managed user sign-in” link. Set the toggle to “On” for either Password Hash Sync or Pass-through Authentication. Note that you can only select one or the other—you cannot pilot both modes at the same time.

Click “Manage groups” and “Add groups” to add the groups you created. You should see the groups successfully added with a notification in the top right corner. If you were planning for more than 200 members in the rollout group, go back to Azure AD Groups and add the remaining members.

Wait a few minutes. According to Microsoft documentation, this change can take up to 24 hours, although the change typically takes effect quickly when adding new members.

In a fresh browser session, try to log in to something such as myapps.microsoft.com with an account in the staged rollout group. You should see the normal Azure AD login screen instead of your previous IdP’s login screen.

The Sign-in logs section can be very helpful to understand what is happening during the login process for each user: For example, Did the authentication come from an external IdP, or was it using password hash sync or pass-through authentication? Adding the “Incoming Token Type” column will show you at a glance if a user is passing through the federated experience or native cloud authentication.

Note: You may discover that your IdP was previously enforcing things outside of Azure AD and Microsoft 365, such as its own MFA or restricting login locations. You will want to recreate any of these rules as Conditional Access policies in Azure AD.

Fully Disabling Federated Authentication

At some point you will have enough users migrated to Azure AD SSO and you will transition from using staged rollout and federated authentication to full password hash sync or pass-through authentication. When considering the cutover threshold, keep in mind that any remaining users may be prompted to enroll in Azure MFA (depending on your policies) and will need to re-sign in to their Office 365 apps. But at this point, staged rollout has helped get most of your users to the final state.

Fully transitioning to Azure AD SSO is just a matter of converting your domain(s) from federated authentication as you would in a migration without staged rollout:

Set-MsolDomainAuthentication -Authentication Managed -
DomainName ravenswoodtechnology.com

Note that this change can take up to 24 hours to fully take effect (although in practice we have seen it take only a few hours). Any users already in staged rollout will already be using managed authentication at this point and will experience no user-facing changes—which is another good reason to leverage staged rollout as much as possible. You can confirm that the change was successful by selecting Azure AD Connect in the Azure AD portal or by running the following PowerShell command:

Get-MsolDomain -DomainName ravenswoodtechnology.com

Note: You do not need to migrate all your domains at once. You can continue to use staged rollout after you have migrated one or more domains to cloud authentication.

Once all domains are migrated, simply go back to Azure AD Connect in the Azure AD portal and turn off staged rollout.

Make Azure AD Cloud Authentication A Reality

Staged rollout can help make your transition to Azure AD SSO quite a bit easier. It decreases your risk by allowing a slow, testable rollout instead of one big all-or-nothing switch. When you combine using staged rollout with a repeatable process for app migrations, what seemed like an impossibly daunting task with no starting place can be fully accomplished in smaller, easier-to-migrate sets of applications and users.

If this project still seems too large to take on yourself, or if you just need a second set of eyes in the planning stage, Ravenswood Technology Group is ready to help. Whether you are looking to migrate to Azure AD SSO from Active Directory Federation Services (ADFS), Okta, Shibboleth, OneLogin, PingFederate, Auth0, or another platform—or if you want to start completely fresh with your login experience—Ravenswood has the business and technical expertise you need. We will walk you through all the stages of planning and execution to make Azure AD cloud authentication a reality in your organization.

Contact our experts today!

WHAT WE DO

Manage Azure AD Groups with the Graph API

In my previous blog [Win32 App Deployment with Intune Supersedence Rules] I explained how to update Win32 applications deployed within Microsoft Intune by using the

Leave a Comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.