Windows Hello for Business Cloud Kerberos Trust: The Complete Deployment Guide

You have three ways to make Windows Hello for Business (WHfB) work with your on-premises Active Directory (AD). Two of them cost you a public key infrastructure (PKI), a federation server, or both. The third one — cloud Kerberos trust — needs neither, deploys in an afternoon, and is the model Microsoft now recommends for almost everyone. If you are still running key trust or certificate trust "because that is how we set it up in 2019," this guide is your migration brief.

This is a hands-on deployment walkthrough for endpoint engineers running hybrid or cloud-only Microsoft Entra environments. We will explain what cloud Kerberos trust actually does under the hood — the partial ticket-granting ticket (TGT) exchange that makes it work — then deploy it end to end with Intune, a Configuration Service Provider (CSP) custom policy, and Group Policy, and verify every step with commands you can run right now.

The problem: three ways to trust, two of them hurt

Here is the thing WHfB has to solve. When a user signs in with a PIN or their face, Windows authenticates them to Microsoft Entra ID with an asymmetric key pair — no password crosses the wire. That is great for cloud resources. But your file servers, print servers, and line-of-business apps still speak Kerberos, and Kerberos wants a ticket from an on-premises domain controller (DC). So the question every WHfB deployment must answer is: how does a passwordless sign-in turn into a Kerberos ticket the DC will accept?

The "trust type" is the answer to that question. There are three:

• Certificate trust — Windows enrols a certificate into the WHfB container and uses it for on-prem auth. This needs Active Directory Federation Services (AD FS) and a Network Device Enrollment Service (NDES)/SCEP pipeline to issue those certs. It is the oldest model and by far the most infrastructure to run and break.
• Key trust — the user's WHfB public key is written to their AD account (the msDS-KeyCredentialLink attribute) and the DCs use it directly. No AD FS, but your DCs still need certificates from an enterprise PKI so they can do Public Key Cryptography for Initial Authentication (PKINIT). You still run a PKI.
• Cloud Kerberos trust — Microsoft Entra ID itself issues the Kerberos TGT. No PKI, no AD FS, no per-user certificates. You publish one object into AD and flip two policy settings. This is the same technology that powers passwordless FIDO2 security-key sign-in to on-prem resources.

Why it happens: how cloud Kerberos trust actually works (the partial TGT)

Let us trace what happens the moment a user unlocks with their PIN. This is the mechanism the whole model hangs on, and if you understand these five steps you will diagnose 90% of cloud-trust problems on sight.

When you enable Microsoft Entra Kerberos in a domain, a special computer object called AzureADKerberos is created under OU=Domain Controllers. It looks like a read-only domain controller (RODC) in Active Directory Users and Computers, but it is not tied to any physical server. Its only job is to hold the encryption key that lets Microsoft Entra ID mint Kerberos tickets your real DCs will honour. A disabled user account, CN=krbtgt_AzureAD,CN=Users,<domain-DN>, holds that TGT encryption key.

With that in place, sign-in looks like this:

1. The user signs in to Windows with their Windows Hello gesture and authenticates to Microsoft Entra ID.
2. Entra ID checks its directory for a Kerberos Server key matching the user's on-premises AD domain, then generates a partial TGT for that domain. The partial TGT contains the user's security identifier (SID) only — no group memberships, no authorization data.
3. The partial TGT is returned to the client alongside the user's Primary Refresh Token (PRT).
4. The client contacts a real on-premises DC and trades the partial TGT for a fully formed TGT — the DC fills in all the group SIDs and authorization data.
5. The client now holds a PRT (for cloud) and a full AD TGT (for on-prem). Single sign-on works everywhere.

The elegant part: authorization never leaves your DCs. Entra ID vouches for who the user is; your Active Directory still decides what they can touch. That is why service tickets and group-based access control keep working exactly as before.

How to verify: the prerequisites, before you touch policy

Do not enable the policy and hope. Confirm each prerequisite first; every one of them maps to a real failure mode.

Here is what a healthy DC key-list check looks like. You are confirming at least one DC advertises the Entra Kerberos capability:

The fix: deploy cloud Kerberos trust step by step

Step 1 — Deploy Microsoft Entra Kerberos

You run this once per AD domain that contains Entra users, from the Entra Connect server (or any server that can reach a writable DC and has the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency). First install the module:

Now create the Entra Kerberos server object. You need an AD account that is Domain Admin for the domain and Enterprise Admin for the forest, plus an Entra account with the Hybrid Identity Administrator role. This example prompts for both:

Verify it landed. The one field that matters most: KeyVersion on the on-prem object must equal CloudKeyVersion on the Entra object. If they diverge, the ticket exchange will fail with encryption errors.

Step 2 — Configure the Windows Hello for Business policy

Cloud Kerberos trust needs two settings on: Use Windows Hello for Business and Use cloud trust for on-premises authentication. A third — Use a hardware security device — is optional but strongly recommended so the key lives in the TPM.

Option A — Intune Settings Catalog (recommended)

Create a Settings Catalog policy and add the Windows Hello for Business category settings. In the Intune admin center:

If your tenant-wide WHfB enrolment policy (under Devices › Enrollment › Windows Hello for Business) is already enabled to your liking, you only strictly need the Use Cloud Trust For On Prem Auth toggle here — otherwise configure all three.

Option B — Custom CSP policy (PassportForWork)

If you would rather push raw CSP, create a custom policy with these three OMA-URIs. Replace {TenantId} with your directory (tenant) GUID:

Option C — Group Policy

For AD-managed devices, first copy the current Passport.admx and Passport.adml from a modern Windows client into your Central Store — older definitions do not contain the cloud-trust setting. Then set:

Step 3 — Enrol

Provisioning starts automatically at the next sign-in once prerequisite checks pass. On a hybrid-joined device, cloud Kerberos trust adds one extra check: does the user have a partial TGT? This proves Entra Kerberos is set up for their domain. The user is walked through biometrics (optional), a multifactor prompt, and PIN creation, then Windows registers the WHfB public key — from the TPM if present. On Entra hybrid joined devices, Entra Connect then syncs that key back into AD.

Proof it worked

Two commands settle it. First, dsregcmd /status — look in the SSO State block for the partial-TGT check and confirm the join state:

Then klist — you should see a Kerberos TGT for your realm, proving the partial-to-full exchange completed against a real DC:

Now open a share on a file server (\\fileserver\finance). No credential prompt = single sign-on is working end to end. That is cloud Kerberos trust doing its job with zero PKI behind it.

Migrating from an older trust model

Already on key trust? It is easy: set up Entra Kerberos, enable cloud trust, then sign out and back in (hybrid users must do that first sign-in with line of sight to a DC). Both models can even coexist during rollout — if the partial-TGT check fails, the device quietly falls back to the key-trust path.

Certificate trust is harder — there is no direct migration path. You must delete the Windows Hello container first: disable the certificate-trust policy, enable cloud trust, run certutil.exe -deletehellocontainer in the user context, then sign out and back in to re-provision. We cover the NDES decommission in detail in the certificate-trust migration guide.

References

• Windows Hello for Business cloud Kerberos trust deployment guide
• Enable passwordless security key sign-in to on-premises resources (Entra Kerberos)
• PassportForWork CSP reference
• Windows Hello for Business policy settings
• Troubleshoot devices by using the dsregcmd command