Cloud Kerberos trust takes the pain out of Windows Hello for Business

Whenever customers think about Windows Hello for Business (WHfB) in hybrid environments, I hit the same obstacles: a complex PKI, unreliable key sync, and the ongoing struggle of connecting on-premises and cloud authentication. Cloud Kerberos trust removes most of that. It's a passwordless option you can actually deploy, with no in-house certificate authority and none of the usual waiting for key sync. Biometric and PIN sign-in in hybrid setups is now realistic for pretty much any organization.

Cloud Kerberos trust relies on a single object in Active Directory

Cloud Kerberos trust is the newest and tidiest deployment model for Windows Hello for Business, whether your devices are hybrid or cloud-only. The basic principle is simple. Domain controllers don't have to issue or validate certificates anymore (as they do with certificate trust), and they don't have to wait for keys to sync from Entra ID (as with key trust). Users sign in with a Hello gesture and still get single sign-on to traditional on-premises resources like file shares, legacy apps and even print servers, without ever entering a password.

Everything hinges on the Azure AD Kerberos Server object, which you create in Active Directory with the AzureADHybridAuthenticationManagement PowerShell module. Run the following on PowerShell 7 with Global Admin and Domain Admin rights:

# Prerequisite: PowerShell 7, AzureADHybridAuthenticationManagement module, Global Admin and Domain Admin rights
Install-Module -Name AzureADHybridAuthenticationManagement
Import-Module AzureADHybridAuthenticationManagement
Set-AzureADKerberosServer -DomainController <FQDN-of-DC>

The command creates the required computer object in AD and links it to your Microsoft Entra ID tenant. After that, cloud Kerberos trust does the hard work, with domain controllers and Entra ID handling authentication together in the background. The full procedure is described in Microsoft's deployment guide.

The requirements are modest and the rollout runs through Intune

People are often unsure what this model really requires. If your Windows clients and domain controllers are reasonably current, the list is short:

• Windows 10 21H2 (fully patched) or Windows 11
• Devices are Entra hybrid joined or Entra joined (plain Azure AD Join works too)
• Domain controllers are Windows Server 2016 or later, fully patched
• No ADFS or third-party authentication providers involved
• Entra ID P1 license (recommended, especially for Conditional Access)

To turn on cloud Kerberos trust, you deploy a policy through Intune. I'd use the Settings Catalog and set "Use Cloud Trust For On Prem Auth" to true. The dedicated Windows Hello for Business identity protection profile does the job as well. As soon as the policy reaches the devices and patching is complete, users can work with cloud Kerberos trust. If you're moving from an older Hello trust model, read Microsoft's migration guide first.

Users notice the difference at their first sign-in

The change users actually notice happens the first time they sign in on a new device. Setting up Windows Hello (PIN, fingerprint, face) goes quickly and without friction. The important part is that users no longer sit around waiting for key sync before they can reach on-prem resources, which was a well-known problem with key trust. If you've ever fielded calls from users who couldn't see their file shares right after setting up Hello, you'll appreciate this.

Access to on-prem file shares, printers and legacy applications still runs over Kerberos. The difference is that tickets come from the new mechanism on demand instead of depending on slow certificate or key sync. The one real limitation I've come across involves a few very old apps that use uncommon Kerberos extensions (S4U2Self, for example). They may not behave, so test those scenarios in a pilot first.

Real-world tip: To check that cloud Kerberos trust is working, sign in with Hello, open a command prompt and run klist. You should see a ticket issued to the AzureAD Kerberos Server object.

Cloud Kerberos trust removes the need for both PKI and key sync

Until now you had to pick certificate trust, which needs a PKI, or key trust, which needs key sync. Cloud Kerberos trust needs neither, only a cloud object in AD. A simple flowchart makes the differences clear:

flowchart TD
    UserLogin["Hello sign-in"]
    TrustType["Choose trust type"]
    CT["Certificate trust"]
    KT["Key trust"]
    CKT["Cloud Kerberos trust"]
    PKI["Internal PKI? Yes"]
    PKI_No["Internal PKI? No"]
    KeySync["Key sync required"]
    CloudObj["AzureAD Kerberos server object"]
    PKI --> CT
    PKI_No --> KT
    TrustType --> PKI
    TrustType --> PKI_No
    TrustType --> CKT
    CT --> UserLogin
    KT --> KeySync --> UserLogin
    CKT --> CloudObj --> UserLogin

Figure: The Windows Hello for Business trust models and where cloud Kerberos trust fits.

The diagram shows how much of the old complexity cloud Kerberos trust drops, while users still get passwordless authentication to both cloud and traditional resources.

I consider cloud Kerberos trust the way forward

There are still edge cases, such as very old infrastructures or applications with unusual Kerberos dependencies. Those may need extra attention or may have to stay on certificate trust for the time being. For most modern environments, though, cloud Kerberos trust is now the quickest and least error-prone way to deploy Windows Hello for Business in hybrid mode. If you're planning a wider move to modern authentication, have a look at my post on migrating to the Entra ID authentication methods policy.

In my view, cloud Kerberos trust is one of the most practical identity improvements Microsoft has shipped in recent years. If PKI or key sync problems have kept you from rolling out Hello for Business, there's little reason to wait any longer. Admins and users both benefit right away.