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.
- Open the Microsoft Intune admin center portal and navigate to Devices > Windows > Configuration profiles
- On the Windows | Configuration profiles blade, click Create profile
- 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
- 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
- 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

- On the Scope tags page, configure the required scope tags and click Next
- On the Assignments page, configure the assignment and click Next
- 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
Discover more from All about Microsoft Intune
Subscribe to get the latest posts sent to your email.
Great article! We opted for WHFB certificate trust so we could leverage WHFB authentication for RDP sessions. Is that now possible with cloud kerberos trust?
Not at this moment. Have a look at the not supported scenarios: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust?WT.mc_id=EM-MVP-5001447#unsupported-scenarios
Regards, Peter
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
Hi Gyz,
This is also applicable to Entra hybrid joined devices.
Regards, Peter
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…
That is correct, Matthieu. RDP is still one of the unsupported scenarios.
Regards, Peter
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?
Yes, Michael! That’s the same setting.
Regards, Peter
Hello,
On Entra ID joined devices, does the VPN (Line of sight to DC) is a must or can this work without the VPN?
Hi Kiran,
Only for Microsoft Entra hybrid joined devices, users must perform the first sign in with new credentials while having line of sight to a DC.
Regards, Peter
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
Hi Chris,
I don’t know about the future. Only about the currently unsupported scenarios: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?WT.mc_id=EM-MVP-5001447#unsupported-scenarios
Regards, Peter
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 ?
Hi Kudi,
I wouldn’t expect a lot of issues, but make sure that you’ve went through the documented steps: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll?tabs=intune#migrate-from-key-trust-deployment-model-to-cloud-kerberos-trust
Regards, Peter
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.
Ah, that’s great to hear! Thanks for sharing!
Regards, Peter
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
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?
Hi Jamie,
You don’t have to re-enroll your client devices. Depending on the current Windows Hello for Business configuration, you can find the required steps here: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust?tabs=intune#migrate-from-key-trust-deployment-model-to-cloud-kerberos-trust
Regards, Peter
Is there any way to prove a computer is using Cloud Kerberos Trust to know users have migrated? I ask because we are looking to decommission a certificate authority, and Windows Hello is using that right now for our key trust. I need to know when all my users have migrated to Cloud Kerberos Trust before decommissioning it.
Hi Jamie,
Successfully applying the configuration should basically immediately enable the use of cloud trust. Sign-out and sign-in should be sufficient in that case. Not sure if you can check that somewhere easily on a central location.
Regards, Peter
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?
So, for my understanding, this is mainly referring to getting the download link for mobile devices, right?
Regards, Peter
Yes, that is correct. Obviously, we could do some sort of workaround, but seems like this link should either work as intended or not be included in this context. Thanks.
Ah, yeah, thank you for that. To get it addressed, and maybe even fixed, you might also want to report this with Microsoft.
Regards, Peter
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!
Hi Sjoerd,
To my knowledge, WHfB always relies on an on-premises AD.
Regards, Peter
You want a cloud-only deployment, I think.
https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/deploy/cloud-only?tabs=intune
I am facing the exact same problem. Have you found a solution?
In fact, the Entra Domain Services are quite useless without the Kerberos Trust. In fact it is not possible to provide a SSO with Entra ID Joined Devices to Services joined the Entra Domain Services. I would have expected that this is even preconfigured on the Entra Domain Services.
Hey all,
We are using cloud kerberos trust with our clients … how do you handle rolling the keys ?
Logging into the clients tenant every 30 days with global admin is not the best way, also its very time consuming …. will there be an option with entra id connect or something else that will “auto” roll the keys ?
Hi Christian,
There are script examples available that can help you automate that process, or parts of that process.
Regards, Peter
Hello Peter, Do you know where i would find those scripts ?
thanks & best regards
Hi Christian,
Please use your favorite search engine and search for automating the rotation of krbtgt. I haven’t tested those scripted results, so I don’t like to refer to something that I haven’t tested.
Regards, Peter