Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 3

Cloud Kerberos Trust for Windows Hello for Business is the apex of single sign-on solutions for your Windows devices. in this Trilogy you can expect to learn the what, the how and the wow!

Looking for other parts?
Part 1 – Part 2

The story so far

We continue our mini series on Windows Hello for Business Cloud Kerberos Trust. In part 2 we walked through the configuration of Cloud Kerberos Trust for both on-premise infrastructure and clients.

If you missed part 1 of our series, your journey into “Cloud Kerberos Trust” should start here: Simplify Windows Hello for Business SSO with Cloud Kerberos Trust – Part 1

We love the elegance and simplicity of Cloud Kerberos Trust but in this final post of the mini series we will dive a little deeper and look at some of the mechanics and moving parts to help you understand and troubleshoot your way out of a hole- if you need to.

Hold tight and get your engineer brain engaged as we equip you with the tools you need to succeed!

Pick-up your engineering toolkit and come down the rabbit hole

Migrating from other Trust Models

This question often comes up, naturally. What if you are using hybrid key trust and you want to begin kicking the tires on cloud kerberos trust? The answer is simpler than you might think.

Migrating from a hybrid key trust model is very simple. For Azure AD and Hybrid Azure AD joined devices, simply deploy the Intune configuration to enable cloud kerberos trust and the user will switch to cloud kerberos trust. The extra requirement for Hybrid Azure AD joined devices is the device requires line-of-sight to a DC at first logon or it will fall back to using key trust.

Migrating from certificate trust has more moving parts. You must disable the existing certificate trust policy, deploy the Intune configuration to enable cloud kerberos trust, delete the existing hello credential and sign back in to the device.

Use the following command to delete the existing hello credential

certutil.exe -DeleteHelloContainer

The “Key” thing to understand, (see what I did there?) is that a policy that defines neither: “Use certificate for on-premises authentication (*1)” or “Use cloud trust for on-premises authentication (*2)” is considered as using the “Key Trust” model for authentication.

Privileged Accounts

Highly privileged accounts are not granted, by default, to use FIDO2 security keys and/or cloud kerberos trust to login to a device. The local security policy forbids it.

The msDS-NeverRevealGroup property is used to define which AD objects forbidden to have their passwords cached on the Kerberos RODC.

To unblock the accounts, use Active Directory Users and Computers to modify the msDS-NeverRevealGroup property of the Azure AD Kerberos Computer object (CN=AzureADKerberos,OU=Domain Controllers,<domain-DN>).

Caution should be used when relaxing any local security policy. Understand the impact, if any, of what you are about to do

Next Generation Credential (NGC)

The Next Generation Credential (NGC) is important. Verify the NGC has been set on client devices correctly by using dsregcmd (in the user context) command. NgcSet: YES means that a hello key has been set for the current user

dsregcmd /status

Verify the NGC has been saved to the user object in AzureAD using Graph Explorer. Examine the deviceKeys attribute for the NGC assigned to the device the user logged on to using WHfB.

The NGC is present as a result of the normal WHfB authentication process – it is not specific to us enabling AzureAD Kerberos but it will be important when we look at other moving parts later in this blog.

The NGC contains the base64-encoded public portion of the asymmetric key pair used for WHfB authentication.

You can also see in the Windows event log that the NGC was created and written to the user object in Azure AD

In Graph Explorer, we can also see some other cool metadata that will be useful when we deep dive later!

Cloud Kerberos Trust under the Microscope

Before we dial in our microscopes it is best we define what the high level components are in a Windows Hello for Business Cloud Kerberos Trust relationship as this will help us sort through the finer details.

• AzureADKerberos
• Windows 10/11
• Windows Server 2016 or newer DC
• User account synced from On-Premise

Yes, it is basically just those few things, no PKI is explicitly required! And now we have that sorted, on to nitty gritty.

AzureADKerberos

In Part 2, we provisioned the Azure AD Kerberos Read-Only Domain Controller (RODC) object into the “Domain Controllers” OU of our local Active Directory domain.

So what happens when the object is created? It creates a server object that can issue Ticket Granting Tickets (TGTs) for Kerberos in your domain. The encryption key is then securely published to Azure AD, which allows it to issue a partial TGT as part of the magic behind Cloud Kerberos Trust. This partial TGT is received by the user via the Primary Refresh Token when they authenticate with Azure AD. The TGT includes only the user’s SID, and no authorization data.

This is a one-time operation, and for each on-premises domain, an object will represent it in Azure AD. No background processes are enabled to keep things in sync. It’s all very secure!

If you have more than one on-premises domain, each one will have a key in Azure AD that corresponds to the on-premises domain. Thus, if you have multiple domains, this is not an issue. However, if you have a single domain and multiple tenants, the issue becomes more complicated, as there is no option to just publish the encryption key of the current Azure AD Kerberos RODC object into another tenant.

It’s important to know that, since the encryption key (kbrtgt) is not synced after the initial publishing into Azure AD, it’s imperative to only use the Azure AD Kerberos PowerShell module to rotate the kbrtgt of the Azure AD Kerberos RODC object.

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $userprincipalname -RotateServerKey

There is more of on the official Microsoft Learn site: Passwordless security key sign-in to on-premises resources – Azure Active Directory – Microsoft Entra | Microsoft Learn

Windows 10/11

ICYMI: Windows is required for Windows Hello for Business to function. But not just any version of Windows. Windows 10 21H2 and later are recommended because the Cloud Kerberos Trust feature was introduced with this build.

So what happens during sign-in, since it is important to have an updated version of Windows? Well it depends on what join-type your device is using – Hybrid Join or Azure AD Join. Let’s start with the most common “Hybrid Join”.

Hybrid Joined

There are many roads to Rome, and this one takes the longest of them all!

Azure AD Joined

Be prepared to be amazed at the simplicity of being in an Azure AD Joined state and doing SSO to your on-prem resources:

If you wanna get deeper into it and follow these awesome diagram flows from Microsoft, there is the official documentation at Microsoft Learn: How Windows Hello for Business works – Authentication | Microsoft Learn

Windows Server 2016 or newer DC

Now what’s wrong with the classic Server OS of yesteryear? It’s kerberos trust! Surely it matters not what version ones domain controller is at?

Well that part right and some parts wrong. See, there must be one or more Windows server 2016 DC’s to support both the Key Trust and the Cloud Kerberos Trust models, as they need to be able to interpret the Cloud TGT.
The amount of DC’s is determined by the amount of overhead the additional Kerberos requests cause in your domain. So even if you choose to upgrade all your current DC’s that might not be enough if you decide everyone has to use WHfB. As Windows Hello for Business generates a sign-in process overhead, and you might need to plop in a few more “Mega Godzilla Beast servers” (as Mark Russinovich likes to call his pet servers) to take the load.

So, we are talking about Windows Server 2016+ Domain Controllers, which just upgrades the Schema when introduced. But what about the forrest and domain functional level you ask?
Well… Windows Server 2008 R2 Domain/Forest functional level is the accepted minimum. If you like leftovers and dumpster diving, you can go right ahead and keep it like that.

User account synced from On-Premise

We have already eluded to the fact that an on-premise user account is indeed needed – so there is no crying to mommy when your pure cloud user won’t magically SSO into the ocean of legacy file shares you might have on-premise.

The simple fact is that the TGT that you get from Cloud Kerberos, is in fact just an identifier, proving that you are in fact a synced user from the on-prem domain. and the full TGT which you get from the DC, contains information that comes from the on-prem. Azure AD has no clue about what resources are in your on-prem, and even if it did, the on-prem is likely not trusting Azures own Kerberos tokens (yes, there is another thing called Azure AD Kerberos, which can issue full TGT’s for resources like file shares in an Azure Storage account, but I digress).

To get deeper into how all this works, we need to spinup a new headline called (drum-roll please)…

Kerberos is King!

Meet Michael, Ben and Fluffy the dog. Cerberos is the mythical creature that guards hades, the gates of hell. Fluffy is the watchdog of the underworld etc. In previous roles he was guarding Windows Vista and was born in the 80’s when no one cared what shampoo you used.

Kerberos has 3 parts/heads (Michael = User, Fluffy = KDC, Ben = Service)

So what is Kerberos and how does it help us when we are looking to SSO to our domain resources? Here are some Kerberos basics

• “Kerberos” is just a cryptographic ticketing system
• In order to request tickets to domain resources, the Kerberos protocol needs to know where the “Ticket Master” is
• The “Ticket Master” is called the Key Distribution Centre (KDC)
• The KDC in a Windows Domain is a Domain Controller

Basically I need to get a ticket from the domain controller, or KDC, to prove who I am to the service e.g. file server

Finding a KDC

Azure AD joined devices are not aware of your domain, so how do they find the KDC to get tickets? Thats easy and takes us back to the 80’s again. DCLOCATOR is a process used by Windows systems to locate the closest available Domain Controller

First my client needs to find the KDC, how does it do this when the client knows nothing about the domain? Ah-ha, remember we have some synced attributes that come down with our Primary Refresh Token at logon. DCLocator needs a domain hint, which it gets from the <onpremisedomainname> attribute that came down with this PRT. A Domain Controller (KDC) is returned to the client as a result of, effectively, a DNS query.

We can simulate what DCLocator does by running the nltest on a device and passing the domain name

nltest /dsgetdc:byteben.com

If on-premises DNS is broken or the client is not configured correctly for DNS. This query might/will fail. Its always DNS right?

Tickets Please

Now we know where the KDC is, lets go into a bit more detail on how Kerberos ticket issuance works and helps us to access domain resources.

1. The partial TGT we obtained from AzureAD is sent to the KDC.
2. The KDC validates the partial TGT.
3. The KDC then issues a “Golden” ticket to the user. The golden tickets, or Full TGT is proof the user authenticated. Authentication has a lot of overhead so we don’t want to keep doing it.
4. The user then sends that TGT (proof that they can come into the nightclub) along with another request to access a service, like CIFS (fileshare)
5. The KDC sees the user has a valid TGT (BTW, only the KDC can decrypt the TGT) and issues a “Service Ticket”. The service ticket contains things like group membership and service requested.

We can see the AS-REQ for a ticket come into the KDC (You can filter Wireshark using the KRB5 protocol to see this cool stuff)

When we try to access a file share, we see the client send a request to the KDC.

When we try to access a file share, we see the client send a request to the KDC. The request contains our TGT which validates who we are

The KDC then issues us a service ticket for the resource we just tried to access. In this example we accessed a file share on bb-app1.byteben.com

Klist

Klist displays all the service tickets we have been granted. Here is the service ticket we requested to access the file share on bb-app1.byteben.com

Klist also has another cool command when working with Cloud Kerberos Trust

klist /cloud_debug

MFA

YES!

In case it was not obvious, the requirement to enroll into Windows Hello for Business is that the user can complete and MFA request from Azure AD. and there is absolutely no way around that. But there are tricks like using Temporary Access Pass in Azure AD, in case you want to pre-provision WHfB for end users, or you don’t want or need them to have MFA capabilities outside of their device.

Summary

Hopefully this 3 part mini series has been useful. Its always difficult to know how deep to go and keep the content engaging. If you would like any more info, please reach out!

Bookmark this page, because there is no way you will remember all of this stuff, and don’t forget that Ben and Michael work for likes and follows on Twitter and LinkedIn. Fluffy takes bones, peanut butter and cinema ticket stubs as donations.