Deploying Windows Hello for Business with cloud Kerberos trust using Intune

Windows Hello for Business replaces the password with a device-bound key unlocked by a PIN or biometrics, but in a hybrid environment the hard part has always been getting that key accepted by Active Directory. Cloud Kerberos trust removes the PKI from the equation. In this post I'll cover the prerequisites, the one-time Microsoft Entra Kerberos setup, the Intune settings, and how to prove it's working on a device.

How it works#

The trust type decides how a Windows Hello for Business credential authenticates to Active Directory (authentication to Microsoft Entra ID always uses the key). There are three options:

Microsoft recommends cloud Kerberos trust over key trust, and it's the preferred model unless you specifically need certificate scenarios: no key synchronization delay before the first on-premises sign-in, no certificates to issue, and the same Microsoft Entra Kerberos object also enables FIDO2 security key sign-in to on-premises resources.

Prerequisites#

• Identity: users synchronized by Microsoft Entra Connect with cloud authentication (password hash sync or pass-through authentication) or federation. The default attribute set already includes the required onPremisesSamAccountName, onPremisesDomainName and onPremisesSecurityIdentifier.
• Devices: Microsoft Entra joined or Microsoft Entra hybrid joined, enrolled in Intune. Windows 10 21H2 with KB5010415 or later, or Windows 11 21H2 with KB5010414 or later.
• Domain controllers: Windows Server 2016 with KB3534307 or later, Windows Server 2019 with KB4534321 or later, Windows Server 2022 or Windows Server 2025, with enough writable DCs in every site where users sign in. If you restrict Kerberos encryption types on DCs, AES256_HMAC_SHA1 must stay enabled.
• Permissions: an Active Directory account in Domain Admins (and Enterprise Admins for the forest) and a Microsoft Entra account holding Hybrid Identity Administrator.
• MFA: users must complete Microsoft Entra multifactor authentication during provisioning, so make sure they have a registered method or a Temporary Access Pass.
• Licensing: Windows Hello for Business itself needs no Entra ID P1 or P2 licence in a hybrid cloud Kerberos trust deployment; Intune management does.

Step 1: Deploy Microsoft Entra Kerberos#

If you already enabled passwordless security key sign-in to on-premises resources, this is done. Otherwise, run the following on the Entra Connect server (or another server with the Microsoft.Online.PasswordSynchronization.Rpc.dll dependency) for every domain that contains Entra users. The -UserPrincipalName form opens an interactive sign-in, which you need when the cloud admin is protected by MFA.

Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber

$domain     = $env:USERDNSDOMAIN
$cloudUpn   = "hybrid.admin@contoso.onmicrosoft.com"
$domainCred = Get-Credential   # Domain Admin + Enterprise Admin, enter the user name in UPN format

Set-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred
Get-AzureADKerberosServer -Domain $domain -UserPrincipalName $cloudUpn -DomainCredential $domainCred

The output should show matching values for KeyVersion and CloudKeyVersion. In Active Directory you'll now see a computer object CN=AzureADKerberos under the Domain Controllers OU and a disabled user krbtgt_AzureAD. Rotate the key on the same schedule as your other krbtgt accounts with Set-AzureADKerberosServer ... -RotateServerKey, and only with this module, so the key changes in both directories.

Step 2: Configure the Intune policy#

Two settings are required: enabling Windows Hello for Business and enabling cloud trust. A third, requiring a TPM, is recommended.

1. In the Microsoft Intune admin center, go to Devices › Manage devices › Configuration, select Create › New policy, choose Windows 10 and later and the Settings catalog profile type.
2. Add the Windows Hello for Business category and set Use Windows Hello For Business to true, Use Cloud Trust For On Prem Auth to Enabled, and Require Security Device to true.
3. Add your PIN and biometric settings in the same profile: minimum PIN length (the default is 6, the minimum allowed is 4), whether uppercase, lowercase and special characters are allowed or required, PIN history, biometrics, and enhanced anti-spoofing for facial recognition.
4. Assign the profile to a pilot device group.

Alternatives with the same settings are an Endpoint security › Account protection profile, or the tenant-wide enrollment policy under Devices › Enrollment › Windows › Windows Hello for Business. If the tenant-wide policy is already enabled and tuned, your device profile only needs the Use Cloud Trust For On Prem Auth setting. Leave Use certificate for on-premises authentication unconfigured everywhere: when it's enabled, certificate trust takes precedence over cloud Kerberos trust. And if the same devices also receive Windows Hello settings from Group Policy, Group Policy wins and the Intune settings are ignored.

Step 3: Let users enroll#

Provisioning starts right after sign-in once the prerequisite checks pass; on a hybrid joined device, one of those checks confirms the user received a partial TGT, which proves Entra Kerberos is set up for their domain. The user optionally sets up a biometric gesture, completes MFA and creates a PIN, and the key pair is generated in the TPM and registered with Entra ID. The PIN works immediately, with one condition: on a hybrid joined device the first sign-in or unlock with the new credential needs line of sight to a domain controller. After that, cached sign-in works offline.

Verify#

1. As the user, run dsregcmd /status. Under User State, NgcSet : YES confirms the Hello key exists. Under SSO State, expect AzureAdPrt : YES, OnPremTgt : YES and CloudTgt : YES.
2. Before enrollment, the Ngc Prerequisite Check section shows PreReqResult : WillProvision when everything is in place, and the OnPremTGT line (named CloudTGT before Windows 11 23H2) shows whether the partial ticket arrived. The same checks are logged in Applications and Services Logs › Microsoft › Windows › User Device Registration › Admin.
3. Run klist after a PIN sign-in. You should see a krbtgt ticket for your Active Directory realm, which means the partial TGT was exchanged for a full one.
4. Open a file share or an intranet site that uses Windows integrated authentication. No credential prompt means on-premises SSO is working.

Tips & gotchas#

• Line of sight is needed more than once. Besides the first sign-in, users need a DC when they access on-premises resources and after changing their password locally with Ctrl+Alt+Del; they must then unlock with the PIN while connected at least once.
• Expired passwords block sign-in. A synchronized user whose Active Directory password has expired can't sign in with cloud Kerberos trust until the password is reset.
• Remote Desktop needs extra work. Cloud Kerberos trust can't be used as a supplied credential for RDP or VDI. Use Remote Credential Guard, or enroll a certificate into the Hello container. Run as with the Hello credential isn't supported either.
• Migrating from key trust only requires enabling the cloud trust policy (hybrid joined users sign in once with DC connectivity). Migrating from certificate trust means disabling the certificate policy, enabling cloud trust, deleting the container with certutil.exe -deletehellocontainer, signing out and re-provisioning. On current Windows 11 builds that command also removes passkeys stored on the device, so warn users first.
• Multifactor unlock (now documented as trusted signal unlock) is a separate policy that adds a second unlock factor such as a trusted Bluetooth device or network. Get basic Windows Hello working first; a missing trusted factor can lock users out of the device.

References#

• Windows Hello for Business cloud Kerberos trust deployment guide
• Enable passwordless security key sign-in to on-premises resources (Microsoft Entra Kerberos)
• Configure a tenant-wide Windows Hello for Business policy with Microsoft Intune