Configuring Windows Hello for Business cloud Kerberos trust

by

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.

Figure 1: Overview of the required object in Active Directory

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
  1. 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
  1. 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
Figure 2: Overview of the configuration setting for cloud Kerberos trust
  1. On the Scope tags page, configure the required scope tags and click Next
  2. On the Assignments page, configure the assignment and click Next
  3. 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.

Figure 3: Overview of the configuration experience

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.

26 thoughts on “Configuring Windows Hello for Business cloud Kerberos trust”

  2. Thanks for this great article.
    Does it work for both Hybrid-joined and as well EntraID-joined devices?
    Or is this not a requirement for cloud Kerberos trust

    Reply

  3. Cloud Kerberos trust is great, until you try RDP to on-prem servers… event with a certificate I have to disblae NLA on the servers…

    Reply

  4. hello,
    great article!!! i do have a question…. is the sestting you are setting in the settings catalog the same as one i have already set using the Custom OMA-URI Settings that i set following another article awhile ago? in that the following setting are set:

    OMA-URI – ./Device/Vendor/MSFT/PassportForWork/73200aa1-a81f-4a64-bf8b-8c0d8dff0734/Policies/UseCloudTrustForOnPremAuth

    Data type – Boolean

    Value – True

    if they are the same can i use yours in place of that one or would i need both?

    Reply
  5. Pingback: Intune Newsletter - 17th November 2023 - Andrew Taylor

  7. Hello,
    Just wanted to ask if connecting to OnPrem RDS Farm from hybrid joined device possible ?
    and if there is a chance that entra id joined devices can connect to rds with cloud kerberos trust in the near future ?

    best regards, Chris

    Reply

  8. Hi Peter,
    Thank you for this great article, as always a pleasure to read.
    Maybe you can help me, i configured this in my LAB, but i think i habe made a mistake. When i logon to a Client suing Hello, and then try to connect a network share i get a permission error. If i check with “klist”, i can see the tickets, but it doesn’t work.
    When i then lock the screen, and logon again using my password, everything works. What have i done wrong?
    Does my previous Key Trust deployment create any issues ?

    Reply

  9. I found the Problem, for some reason i had enabled this settings “Enable to certificate for on-premise resources”. after setting it back to Not configured, everything works.

    Reply

    • Many thanks for the hint! I was also struggling and had no clue what’s the issue!
      Disabling the setting and deleting the Windows Hello Container (if already in use) will help immediately.
      Command: certutil.exe -deletehellocontainer from the user context

      Reply

  10. Peter,

    We currently have WHFB set up through Intune at our company for our Hybrid Azure AD Joined devices, and I’m interested in migrating to Cloud Kerberos. Is it necessary to reenroll the WHFB for all our client computers after making the configuration changes? Additionally, is there an easy way to see if our current setup uses Key or Certificate trust?

    Reply

  11. I’ve run into a glitch. The WHFB enrollment experience at login is working perfectly, with one exception. The sequence is as follows and I will call out the flaw:

    1. User enters username and password
    2. Blue screen “WHFB enrollment shell” starts
    3. WHFB prompts user to configure biometrics (if available) – In the test, user selects ‘skip for now’
    4. WHFB prompts, “Your organization requires you to set up your work or school account with…” – User clicks OK
    5. Cloud experience host checks for MFA factors other than password and determines another is needed.
    6. WHFB prompts, “More information is needed” – User clicks ‘Next’
    7. WHFB prompts, “On your phone, install the Microsoft Authenticator app.” with a “Download now” hyperlink to
    https://www.microsoft.com/en-us/security/mobile-authenticator-app

    What’s supposed to happen in step 7 is the user clicks on the ‘Download Now’ link, Edge opens and displays one QR code for Android, and one for iPhone, and the user can scan the correct QR code to install Microsoft Authenticator app. The problem is that the “Download now” link APPEARS to do nothing. What it’s doing though, is launching edge to the hyperlink in the user’s desktop experience (NOT in the WHFB enrollment shell). This can be seen when the user exits out of WHFB enrollment and is admitted to the desktop, where Edge is waiting with the Microsoft Authenticator App installation link. I would think Edge should be able to open in the WHFB enrollment shell. Otherwise, why include the download link at all? I’m wondering if there are group policy settings that might interfere with Windows ability to display Edge in the shell. Anyone have any ideas?

    Reply

  12. Hi Peter,
    We are trying to set this up in a case where there is no on-premises Active Directory Domain Services, but instead we use Entra Domain Services.
    The requirement for cloud Kerberos trust is to create the computer account using the PowerShell module. However this is no possible when using EDS since we do not have access to create this object as these are managed by Microsoft.
    Do you have any knowledge on how to do this or if this is even supported?
    Hope you can help.
    Thanks Sjoerd!

    Reply

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.