Configuring Windows Hello for Business cloud Kerberos trust

This week is all about Windows Hello for Business. More specifically, about Windows Hello for Business cloud Kerberos trust. Not something really new, but definitely something that should be part of the default toolset. Hopefully familiar nowadays, Windows Hello for Business can be used to replace password sign-in with strong authentication on Windows. On top of that, Windows Hello for Business cloud Kerberos trust brings a simplified deployment experience for hybrid authentication with Windows Hello for Business. To provide that functionality, it relies on Microsoft Entra Kerberos for requesting Kerberos ticket-granting-tickets (TGTs). And those TGTs can then be used for on-premises authentication. A bing difference with other deployment models is the simplicity. No dependency on a public key infrastructure (PKI) and no need to synchronize public keys. This post will focus on the configurations that are specific to Windows Hello for Business cloud Kerberos trust. So, it starts with the deployment of Microsoft Entra Kerberos, followed with the deployment of the policy that is used to tell Windows to actually use cloud Kerberos trust. This post will end with experiencing the configuration on a Windows device.

Note: Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to key trust. Besides that, it is also the preferred deployment model when there is no need to support certificate authentication.

Deploying Microsoft Entra Kerberos

When looking at using Windows Hello for Business cloud Kerberos trust, it all starts with Microsoft Entra Kerberos. Entra Kerberos makes sure that Entra ID can issue (partial) TGTs for an Active Directory (AD) domain. Windows can request such an TGT from Entra ID, when using Windows Hello for Business. That TGT can then be used for accessing on-premises resources. Within that chain AD is still responsible for verifying the partial TGT and providing the full TGT.

Note: For a lot more details around the authentication flows and the TGTs, have a look at the docs here and here.

To deploy Microsoft Entra Kerberos it’s required to create a Kerberos server object in the AD. That can be achieved by using PowerShell. More specifically, by using the AzureADHybridAuthenticationManagement module. That module contains the Set-AzureADKerberosServer cmdlet that can be used to create the required Kerberos server object and the Get-AzureADKerberosServer cmdlet that can be used to view an existing Kerberos server object. Once the object has been created, it can be easily verified in the AD. A new Read Only Domain Controller (RODC) object with the name AzureADKerberos should be available. Below in Figure 1 is an example of that object.

Note: Keep in mind that the server encryption krbtgt keys should be rotated regularly. That can also be achieved by using the Set-AzureADKerberosServer cmdlet.

Configuring cloud Kerberos trust

After creating the Kerberos server object, the next step is to create a policy to tell Windows to use cloud Kerberos trust. Luckily, there is a policy setting available within the PassportForWork CSP that can be used for exactly that purpose. That CSP contains the UseCloudTrustForOnPremAuth policy setting that can be used to tell Windows to use cloud Kerberos trust for authentication to on-premises resources. Of course that first requires the regular configuration of Windows Hello for Business. Either via the tenant-wide settings, or a via an Account Protection policy. On top of that the Settings Catalog can be used to enable the specific cloud Kerberos trust configuration. The following eight steps walk through the creation of a Settings Catalog profile that can be used to tell Windows to use cloud Kerberos trust for authentication to on-premises resources.

1. Open the Microsoft Intune admin center portal and navigate to Devices > Windows > Configuration profiles
2. On the Windows | Configuration profiles blade, click Create profile
3. On the Create a profile blade, provide the following information and click Create

• Platform: Select Windows 10 and later to create a profile for Windows 10 and Windows 11 devices
• Profile: Select Settings Catalog to select the required setting from the catalog

4. On the Basics page, provide the following information and click Next

• Name: Provide a name for the profile to distinguish it from other similar profiles
• Description: (Optional) Provide a description for the profile to further differentiate profiles
• Platform: (Greyed out) Windows 10 and later

5. On the Configuration settings page, as shown below in Figure 2, perform the following actions

• Click Add settings and perform the following in Settings picker
  • Select Windows Hello for Business as category
  • Select Use Cloud Trust For On Prem Auth as settings
• Switch the slider to Enabled with Use Cloud Trust For On Prem Auth and click Next

6. On the Scope tags page, configure the required scope tags and click Next
7. On the Assignments page, configure the assignment and click Next
8. On the Review + create page, verify the configuration and click Create

Note: The Settings Catalog profile will take care of adding the Tenant ID to the URI of the actual setting in the CSP.

Experiencing Windows Hello for Business cloud Kerberos trust

After applying the required configurations for telling Windows to use cloud Kerberos trust for authentication to on-premises, it’s time to experience the configuration. That’s actually quite challenging in a single screenshot. So, let’s try with Figure 3 below. That’s a Windows device, with an active VPN connection to an on-premises environment. On that device, it starts with the user that signs in by using Windows Hello for Business. In this case, a PIN (see number 1). Besides that, it’s important to know that the configuration is applied. That can be seen in the Event Viewer in the User Device Registration log. Event ID 358 provides an overview of the applied configuration, including the configuration of using cloud trust (see number 2). So, when the configuration is applied, it’s important to know that it’s actually working. That can be seen by using the commmand klist cloud_debug. That command shows the available TGT that can be used (see number 3). When that’s all verified, simply access an on-premises resource, like a file share (see number 4). The user has access without additional authentication prompts.

Note: Another interesting command to use is dsregcmd /status. The SSO State section should show that the OnPremTgt and the CloudTgt are available.

More information

For more information about Windows Hello for Business cloud Kerberos trust, refer to the following docs.

• Windows Hello for Business cloud Kerberos trust deployment – Windows Security | Microsoft Learn
• Windows Hello for Business cloud Kerberos trust clients configuration and enrollment – Windows Security | Microsoft Learn
• Passwordless security key sign-in to on-premises resources | Microsoft Learn
• How Windows Hello for Business authentication works – Windows Security | Microsoft Learn
• PassportForWork CSP – Windows Client Management | Microsoft Learn