During my stint at Microsoft, I spent a good deal of time with Windows Hello for Business (WHfB), and subsequently would be involved in prerequisite work to set the stage. For the enablement of WHfB, one of these items is device join, and it usually would be Hybrid Azure AD Join (HAADJ) for existing devices already within Active Directory. Device join can be a bit of a rabbit hole if the organization has federated authentication with AD FS in place, as there are different ways you can configure the device join process.
One customer I was working with decided that they wanted to use their WHfB prerequisite work as the same point to switch from federated to cloud authentication with PHS; they were already sending their passwords to Azure AD for use with Azure AD Identity Protection. I discussed high-level what was required to switch but figured the conversation would continue after lunch. Instead, the customer decided to implement the switch during lunch, and their thousand or so users were moved to cloud authentication, with relatively little planning.
Luckily their environment was relatively straightforward from an identity architecture perspective; I wouldn’t recommend going into the switch without more thorough planning. But the point being made here is that the actual period of cutover has a much lower actual risk than perceived risk.
Managed authentication and managed domain can be used interchangeably with cloud authentication. In most documentation Microsoft has started to prefer using cloud authentication for the umbrella term for Password Hash Sync (PHS) and Pass-through Authentication (PTA)
Note that this article should be considered a companion to some excellent documentation Microsoft already has published, which you can find here:
Azure AD Connect: Cloud authentication via Staged Rollout – Microsoft Entra | Microsoft Learn
Ensuring Risk is Mitigated
Migration risk falls into three buckets: pre-migration, during migration, and post migration. As we dig into them, you’ll note that during and post migration risks are mitigated by taking proper pre-migration actions.
Pre-migration Risk Mitigation
Staged rollout
While it was in public preview for over two years, staged rollout has been a pivotal piece in allowing organizations to mitigate migration risk in a few ways.
From the perspective of pre-migration, risk becomes mitigated by allowing organizations to do what everyone loves the most – test in production. Staged rollout can start with as few users as desired, to dip your toes into the waters of what cloud authentication will look like.
When a user is authenticating to Azure AD, upon the initial sign-in screen where you enter your UPN, Home Realm Discovery (HRD) is performed to determine where and how to authenticate you. Essentially Azure AD analyzes the UPN entered and routes you accordingly. This is how staged rollout can make decisions on who to continue to federate for authentication, and who should be authenticated in the cloud.
The other key component is that staged rollout allows for the migration to happen in waves/phases/rings – however you want to put it. It’s usually a business decision as to who gets to go when and how, and requires some planning, but with staged rollout, your users are essentially already migrated. I’ve had some organizations move their entire user base to staged rollout so that it was a non-event when the actual switch from federated auth to cloud auth happened on the tenant level.
Password Expiration Policies (if using PHS)
I’ll stand on the side of the argument that for *most* personas, there is an overall usability benefit that also fosters better user behavior relative to risk of password phishing by not requiring password expiration in Azure AD.
When relying on federated authentication, whatever password policies exist in Active Directory will impact user authentication in the cloud.
Now, if you are choosing to go with PTA, Active Directory is still the final say on authentication, and so password policies in Azure AD for these hybrid users is not relevant. But if you are moving to PHS, you should weigh what your current password policy looks like and whether you want to continue to with password expiration with cloud authentication. If you do, you’ll want to look here for details on how to ensure that users in the cloud continue to have their password expire, Implement password hash synchronization with Azure AD Connect sync – Microsoft Entra | Microsoft Learn.
Virtual Desktop Infrastructure (VDI)
If your organization is running a VDI infrastructure, and you’re leveraging non-persistent virtual machines, it’s important to note that there are limitations for support with cloud authentication. More details can be found here, Device identity and desktop virtualization – Azure Active Directory – Microsoft Entra | Microsoft Learn.
AD FS Access Control Policies
While not as common due to the broad uptake of Conditional Access policies, it’s important to make sure that if you have any access control policies in AD FS 2016 or later, or any authorization rules in AD FS 2012 R2 (or earlier), that you translate those rules into CA policies.
AD FS Certificate Based Authentication
While too deep to cover within here, previously the lack of CBA was one of the reasons for organizations to continue to persist with AD FS. If you have CBA in place, you’ll want to make sure you have your use cases documented and well tested in Azure AD; this is another great place for staged rollout.
Azure AD Hybrid Join Service Connection Point
Organizations that have been using HAADJ for a while and have had AD FS in play, may have configured their environment to use AD FS as the authentication service in the Service Connection Point (SCP) for hybrid join.
Note that the SCP is only used for provisioning of hybrid join. Once devices have their trust relationship with Azure AD, there is nothing facilitated by the SCP. Because of this, there is not an ongoing dependency on the SCP for devices already hybrid joined.
Downlevel devices (Windows 7/8/8.1) have dependencies for hybrid join in federated authentication on AD FS, but again this is for joining those devices, which hopefully the occurrences are low in spinning up new Windows 7 instances.
As far as timing goes, the SCP should be re-configured before the final migration from federated to managed authentication.
Windows Hello for Business
Organizations that may have been earlier adopters of WHfB and rolled out Hybrid Certificate Trust, are going to find that they need to convert to a Hybrid Key Trust, or Cloud Kerberos Trust (the new name for Hybrid Cloud Trust).
If you currently are using Hybrid Key Trust, you don’t have change anything to prepare for the migration.
If you are using Hybrid Certificate Trust, you’ll need to take a look at the work required for preparing users to re-enroll in Windows Hello for Business, which you can find here, Hybrid cloud Kerberos trust deployment (Windows Hello for Business) | Microsoft Learn. Note that Microsoft never officially supported migration from Hybrid Certificate Trust to Hybrid Key Trust, but if you wanted to move to HKT, the same steps essentially can be taken, with the different of targeting Hybrid Key Trust.
Sign-in Frequency Conditional Access Policies
If you have heavily restrictive sign-in frequency policies in place and are not using staged rollout on the targeted users, it is an area where the risk will be slightly higher during migration. You may want to evaluate to whom and how you have these policies applied, and potentially temporarily disable your CA policies ahead of the migration window.
Continuous Access Evaluation
Yet another feature that can be used to minimize any risk during migration, continuous access evaluation greatly extends access token lifetimes. Having long token lifetimes will reduce the likelihood of users needing to re-authenticate during the migration window itself. Note that CAE requires the application to support this, so the focus here primarily is on Exchange Online, SharePoint Online and Teams.
Federated Applications
It might be a surprise, but some organizations investigate migration to cloud authentication even when they still have applications federated to AD FS.
While the thought may be that all applications must be migrated prior to cutover, that isn’t necessarily the case, as long as the organization understands the user authentication experience and flows. As the applications have no tie to Azure AD already, they will continue to operate without issue within AD FS. And beyond the fact that the organization will have to continue to maintain AD FS, the organization needs to understand that the user experience for authentication may give a fragmented perception. Users will now have three providers for authentication – Active Directory, Azure AD, and AD FS. In reality the user experience overall should be improved because authentication will be seamless to anything using Azure AD, but then when hitting an application tied to AD FS, the user may be prompted for forms authentication if they don’t have line-of-sight of Active Directory – which is likely the behavior they were already used to. I bring it up because it can become a place of optics and a lot of user subjectivity, and can make troubleshooting scenarios a bit more complex.
Domain Hint with Staged Rollout
Some applications may pass a domain_hint to Azure AD, which is used to bypass the Azure AD sign-on screen. This can be popular in environments with AD FS in play so that users do not need to enter their username upon the initial sign-in screen with Azure AD.
Where this comes into play with staged rollout, is users could be directed to AD FS still for authentication. If your organization is already hybrid joined, and subsequently your users will have a PRT, the domain_hint piece is not even in play for authentication. If you have scenarios of users accessing Azure AD from things like personal devices with no trust relationship with Azure AD, it’s where you may want to see what the behavior for authentication looks like. You can read about domain hints here, Home Realm Discovery policy – Microsoft Entra | Microsoft Learn.
Document your Federation Settings
It may go without saying, but make sure you documented your federation settings, and understand the process to reverse things in the case that an issue arises post migration. This generally would look like using Azure AD Connect to re-configure the tenant for federated authentication unless you only need to selectively roll some of the domains back to federated authentication.
Azure AD Connect Health and Planning the Migration
Along with all the technical checks, there is the question of when to perform the migration. Whether staged rollout is in place or not, the when is a key piece of information the business is going to want to understand (well, as noted in my intro, usually).
For global organizations, the question can become an issue of “there is always someone working somewhere”. The two paths forward:
- A slightly less refined approach operates under the principal that the organization already has an outage window defined for IT operations. 60 minutes fits into almost any defined outage window an organization would have, and so subsequently the work is just scheduled during that time.
- A more refined and risk-adverse approach leverages Azure AD Connect Health. Azure AD Connect Health can help organizations understand when authentication is happening within AD FS, and subsequently you can use the data from this to determine when AD FS is least utilized. Of course, if you have not already deployed Azure AD Connect Health, you’ll likely want to let it run for a bit to allow it to gather a proper amount of data to make an educated decision. Rolling out Azure AD Connect Health is a relatively straightforward process, which you can read about its use here, Using Azure AD Connect Health with AD FS – Microsoft Entra | Microsoft Learn.
Mitigating Risk During Migration
The level of risk used to be higher when ActiveSync was still heavily with legacy authentication, up until even a year or so ago. The reason for this is due to Exchange Online (EXO) having up to a four-hour period in which it may still attempt to authenticate to the federated identity source. Considering that Azure AD no longer has a trust relationship with AD FS, that is where things break down. Recall that with legacy authentication, the service such as EXO captures the user credentials and authentications on behalf of the user.
With modern authentication you don’t have the same drawn-out risk. As long as your user has a valid refresh token (RT) for Azure AD, they will not hit AD FS upon renewal of their access token (AT). To put that another way, the user only talks to AD FS for initial authentication, and subsequent renewals of the AT only require silent interaction with Azure AD. As mentioned, if you have very restrictive sign-in frequency CA policies in place, that can impact this behavior.
There still is a small window, Microsoft defines as up to 60 minutes, where the tenant is converting itself behind the scenes. But as long as you’ve checked all the pre-migration areas, the migration should generate next to no noise.
If you’re curious to understand how to test the migration from the outside-in, Sander Berkouwer (@SanderBerkouwer) has a nice way of leveraging domain_hint for that, which you can find here, How to check if Azure AD has processed the hybrid authentication method change – The things that are better left unspoken (dirteam.com).
Mitigating Risk Post Migration
As noted in the pre-migration tasks, documenting how federation is currently configured is what you’ll need to help rollback any changes. I have not encountered an organization that planned properly needing to rollback to federated authentication.
You may want to continue to keep your AD FS farm around for a bit of time. For those that managed AD FS, it will be a joyous occasion to decommission.
About this posts featured image
The chosen photo is the work of Jorge Tung, used under the Unsplash license.
