Windows Hello for Business: Hybrid Cloud Trust

When we talk about Windows Hello for Business (WHfB) rollout scenarios, the one that has consistently been the preferred path is Hybrid Key Trust. It is the lowest weight scenario for deployment requirements, and if you already had Active Directory Certificate Services (AD CS), it was only a matter of a few hours to configure your directory to be ready to start a rollout.

While there are some smaller niche limitations, the most common limitation that every organization will encounter with Hybrid Key Trust, is that initial Windows of needing to wait for Azure AD Connect to synchronize the msDS-KeyCredentialLink attribute from Azure AD to the user object in Active Directory.

This process is what informs Active Directory of the public side of the users WHfB key pair, and is what enables the user for certificate-based authentication, through WHfB, to AD. Historically this leaves many organizations needing to communicate to users that it will “take some time” between when they enroll and when they can first start using WHfB – not the greatest way to introduce users into a passwordless experience.

Note on Hybrid Cloud Trust Migration

June 16th, 2022

I’ve received feedback from readers who have gone through this post, and following up with me that for their users who were already enrolled in Windows Hello for Business with Hybrid Key Trust are having issues with authentication when switching to Hybrid Cloud Trust.

From my own conversations with folks at Microsoft, the path explained in this document is how an organization would go about switching existing Hybrid Key Trust users to Hybrid Cloud Trust. That being said, if you are hitting these issues and would like to collectively collaborate on researching the, please reach out to me, either on LinkedIn, Twitter DM, or email me at eric at ericonidentity dot com.

Enter Hybrid Cloud Trust

The technology behind WHfB Hybrid Cloud Trust has existed for a while; it’s the same mechanism that has been used to support hybrid FIDO2 Security Key authentication.

Microsoft already has some very good documentation, Passwordless security key sign-in to on-premises resources – Azure Active Directory | Microsoft Docs, that explains how the whole process works, so I won’t dive deep into paraphrasing things. But essentially we now are able to obtain a partial TGT from Azure AD, and subsequently exchange that for a full TGT in AD. Because of this key piece, we no longer need to wait for Azure AD Connect to inform AD of our users public key.

Why Should I Convert?

If you’re asking yourself why you would want to convert from a Hybrid Key Trust to a Hybrid Cloud Trust, there are several benefits:

Goodbye PKI

In reality, if you have a PKI in your environment, you likely are using it for several things. However, you will no longer need to maintain certificates on your Domain Controllers to be used for certificate-based authentication. That partial TGT is all you’ll need to obtain a full Kerberos TGT from Active Directory.

No More Enrollment Delays

Not having to wait for the sync back to AD of msDS-KeyCredentialLink, users will be able to use their WHfB credentials immediately after enrollment.

Sets the Stage for FIDO2 Security Keys

The mechanisms to configure Hybrid Cloud Trust is the same leveraged for FIDO2 Security Key authentication in a hybrid scenario. This puts your environment in a great position to start exploring FIDO2 if you have not already.

Converting to Hybrid Cloud Trust

Prerequisites

You’ll need to first configure your tenant to support the ability for Azure AD to issue a Kerberos TGT for your Active Directory domain. I won’t run through the process here, but it’s straightforward and the instructions can be found here, Passwordless security key sign-in to on-premises resources – Azure Active Directory | Microsoft Docs.

Method for Conversion

Microsoft has documented both the mechanisms for enabling Hybrid Cloud Trust through both Intune and Group Policy; here we will be examining the GPO route. The Microsoft documentation regarding the enablement of Hybrid Cloud Trust can be found here, Hybrid Cloud Trust Deployment (Windows Hello for Business) – Windows security | Microsoft Docs.

Let’s take a look at our existing GPO settings, which can be found under Computer Configuration, Windows Components, Windows Hello for Business:

While we can enable WHfB either as a Computer or User Configuration, the ability to modify the trust model only exists under the Computer Group Policy.

The setting we want to toggle is Use cloud trust for on-premises authentication:

We just need to select OK to save our policy change, and let (or force) our clients pick up the changed GPO.

If you do not find the option for Use cloud trust for on-premises authentication within your GPO, you likely need to update your ADMX templates to a newer version.

And that’s it. The devices scoped to this group policy will be configured for Hybrid Cloud Trust.

Verification, Transition, and Cleanup

Verification

Please note that the process explained below for verification is not a required process. This verification piece is provided to explain the steps that would invalidate any local certificates in Active Directory, to ultimately prove that Hybrid Cloud Trust is working. For migration purposes, you only need to perform the group policy change indicated above.

So we have our GPO updated and refreshed on our client. How can we tell that the device is in fact using Hybrid Cloud Trust and not Hybrid Key Trust?

After the configuration change, we can look at some Event Viewer logs. If we expand Applications and Services Logs, Microsoft, Windows, Hello for Business, Operational, we can see the following Event that shows the device configured and having obtained a Cloud TGT:

We can further test things by deleting the msDS-KeyCredentialLink contents on the user object within Active Directory.

If we look at Lee Gu, we can see there is a public key on his account in AD:

We can easily clear this, and then verify the attribute is empty:

After another sign-on with WHfB, we can go look at our Security logs in Active Directory, and find a successful 4624:

Transition

Even though the transition has no visible impact on our end users, many organizations may still want to take a staged approach to transition to a Hybrid Cloud Trust. To that point, because we are altering the mechanism for authentication on a per-device level, there is nothing stopping an organization from moving to a Hybrid Cloud Trust in a staged approach.

Long-term, from a troubleshooting perspective, it would behoove most organizations to not draw out the transition. Conversely, if an organization has edge use cases that are only supported by a Hybrid Key Trust, those users and their devices should still be able to continue to use Hybrid Key Trust while the rest of the organization operates with Hybrid Cloud Trust.

Cleanup

While in the demonstration above, we see that authentication happens without the need for the msDS-KeyCredentialLink to be populated in Active Directory, the behavior of Azure AD Connect is to still synchronize that value back ton AD, even for a Hybrid Cloud Trust. Remember – we are still performing asymmetric key-based authentication to Azure AD, so there is still a keypair that exists. The behavior change is on the client; the public key in the way it is written to Azure AD appears to have no mechanism to differentiate the type of authentication the client intends with it. Due to this, downstream, Azure AD Connect is still going to synchronize back to Active Directory the public key. I would be curious if Microsoft has intentions to modify this behavior down the road, but for the meantime, we can just ignore those attributes in AD.

At this point, we can also evaluate whether or not to roll back the certificate policies issuing certs to our DC’s for certificate-based authentication. If configured properly, this process should be no-maintenance, so it’s not a critical item, but likely should be removed to clear up any confusion down the road. Would also caution though to ensure that you do not negatively impact anything else that might be leveraging AD for certificate-based auth before backing that out of Active Directory.

FAQ

Do I still need line-of-sight of Active Directory for enrollment?

Yes. For the underlying mechanisms that configure Windows for a cached sign-on experience, line-of-sight is required for Active Directory during the first use of the WHfB credentials that were configured.

What Identity Provider is Authoritative for the client?

One of the topics that almost always comes up when talking about a Hybrid device, is what Identity Provider (IdP) is authoritative for user authentication – Azure AD or Active Directory. This question arises because there is this duality of identity on the device; our user object is tied to two different identity providers. However, one of the identity providers is still considered the authoritative identity provider. The authoritative identity provider is the one that would handle things like providing account lockout for a disabled user account.

For Hybrid Key Trust, Active Directory was authoritative, and Azure AD was secondary – you would receive/refresh your PRT after successful authentication to AD.

With Hybrid Cloud Trust, the model is now flipped, and Azure AD is authoritative, with AD as secondary.

We can observe this behavior in the security events on the device. When you first sign into the device, you will receive a 4624 user logon event with a logon type of 11, which is cached interactive. This is observed even with line-of-sight of Active Directory. Very soon after, if you have line-of-sight of Active Directory, you will see another 4624 user logon event with a type of 7, which normally indicates workstation unlock.

Now, during testing, you will notice that even if the user account is disabled in Azure AD and Active Directory, even with line-of-sight of both AAD and AD, local logon will still occur. However, when the user attempts to access cloud-based resources, they will receive an error in thick-client applications like Teams indicating they need to sign-in (which will fail), and through the web, they will be informed their account is locked out. For AD resources, access will also be denied, and in the security event log, we will find a failed sign-on event, with a failure indicating the account is currently disabled.

Final Notes

If you’ve happened to read this whole post and your organization is not using WHfB yet, now is a great time to strengthen the security posture of your organization, and to start examining what it takes to go passwordless.

If you’ve rolled out Windows Hello for Business, and want to take a look at what the next steps are to eliminating the use of passwords for those passwordless people, take a look at my post on SCRIL, Living in a Passwordless World: Password Management – Eric on Identity.