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!

_Co-authored by Ben Whitmore and Michael Mardahl_

Looking for other parts?

Part 1 (/posts/identity/cloud-kerberos-trust-part-1) -- Part 3 (/posts/identity/cloud-kerberos-trust-part-3)

We continue our mini series on Windows Hello for Business Cloud Kerberos Trust. In Part 1 (/posts/identity/cloud-kerberos-trust-part-1) we introduced the concept of Cloud Kerberos Trust and spoke to some of the challenges it can help organisations overcome. One of the things that we love is the SIMPLICITY of configuration -- both for green field tenants and for organisations already using a different trust method with Windows Hello for Business (WHfB).

Drawing by Nanna Mardahl

In this post, we will show you how to configure Cloud Kerberos Trust for your on-premises infrastructure and how to create a configuration policy for your client devices.

This is so easy. Honestly, put one hand behind you back, juggle some wet frogs and sing "I will always love you", all at the same time, and you will still be able to configure Azure AD Kerberos too.

Enabling Azure AD Kerberos creates an "Azure AD Kerberos" server object in the domain.

We will configure AZURE AD KERBEROS in our lab. Full prerequisites can be found here (https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust?tabs=intune#prerequisites) and the code samples are taken from the Microsoft docs here (https://learn.microsoft.com/en-us/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module).

From the PowerShell Gallery (https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement). This can be done directly on the Domain Controller or from a computer that can access the Domain Controller.

TLS 1.2 is required to access the PowerShell Gallery. Run the following command if it is not enabled:

We can either use a GPO or push a configuration from Intune. If you are interested in using a GPO, read more here (https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust?tabs=gpo#tabpanel_1_gpo). In this post we will push the configuration from Intune (this is the way).

Ensure the client devices are a minimum of Windows 10 21H2 / Windows 11 Pro or Enterprise SKU. Perhaps consider using an Intune Filter (https://learn.microsoft.com/en-us/mem/intune/fundamentals/filters) for targeting.

Assuming you don't already have an existing policy for Windows Hello for Business, we will add it in its simplest form using the Settings Catalog.

Go to the Windows configuration profiles area and click "Create profile".

Select the "Windows 10 and later" platform along with the profile type "Settings catalog" and click CREATE.

Give it an appropriate name and description and click NEXT.

Now, start adding settings by clicking on the "Add settings" button.

The list of settings is LOOOONG, so, you want to do a search for "Windows Hello for Business" and click on the appearing category name "Windows Hello for Business" when it returns the result. Now we start by selecting the following settings (this is a minimum):

A few things to note here...

One is, that Passport for Work is the name in the CSP for "Windows Hello for Business", it is a leftover from Microsoft rebranding. So, don't get stuck on that. Speaking of rebranding, "Cloud Trust" and "Cloud Kerberos Trust" are the exact same thing, just another rebranding.

Second thing is that we selected a policy setting with the text "(User)" in it. This indicates that the user is the target. Even if you assign to a device, this policy will be a user scoped policy on that device. This takes precedence over any other policies that might be targeted to the device. For Windows Hello for Business in Intune, the rules of precedence is "Tenant wide settings" over "User" and lastly "Device".

Lastly we enable the settings and move on to the next part.

Assign the profile to your desired group. You can target either users or devices according to your own preference or policy in-house.

Now we are assuming that the policy has applied from Intune...

At this stage, after a synced user logs in using WHfB, verify that a partial TGT has been issued using the command:

You can also verify in the event log if the policy has been set successfully on the client.

If you don't see the Cloud Primary TGT, then you might not have gotten a new token from Entra ID, and you can force that process by running the command line (as the user):

Then wait a bit and issue the command:

You should be able to see the "SSO" part has the following values set:

In part 2 of this mini series we looked at how to configure Cloud Kerberos Trust. In Part 3 (/posts/identity/cloud-kerberos-trust-part-3) we will dive a little deeper into some of the moving parts and help with some troubleshooting tips. Stay tuned for more fun!