An Entra-joined device signs in without ever speaking to a domain controller. The moment it opens a file share, the domain is back in the conversation. Cloud Kerberos trust is how a cloud-native credential earns Kerberos tickets from an Active Directory it never joined, and it is the piece that decides whether your Windows Hello deployment coexists with the infrastructure you have not retired yet.
A ticket in two halves
The mechanism is elegant enough to explain in one breath. When you enable Microsoft Entra Kerberos against a domain, an object named AzureADKerberos appears in it. It looks like a read-only domain controller and is backed by no server at all; it exists so that Entra ID can hold keys that Active Directory recognizes. From then on, when a user signs into an Entra-joined device with a Windows Hello gesture, Entra ID issues them a partial Kerberos ticket-granting ticket for the on-premises domain alongside the usual cloud tokens. Partial is the operative word: it carries the user’s security identifier and no authorization data, no groups, no privilege attribute certificate. On its own it opens nothing.
The device completes the transaction. When the user first touches an on-premises resource, Windows presents that partial ticket to a writable domain controller and exchanges it for a full TGT, groups and all, exactly as if the user had authenticated on-premises. From there Kerberos proceeds as it has since the nineties: service tickets from the domain controller, silent access to whatever the user’s groups entitle them to. Entra mints the introduction; Active Directory still decides what it is worth. That division of authority is the whole design, and it is why nothing about your on-premises permission model changes.
Entra mints the introduction; Active Directory still decides what it is worth.
What it takes
The bill of materials is short, which is precisely its advantage over the older trust models. Domain controllers on Windows Server 2016 or later, patched to speak Entra Kerberos, with enough writable ones in every site where users will authenticate; the read-only-shaped object cannot serve the exchange itself. The Kerberos server object is created once per domain with a small PowerShell module, and the operation is a few minutes of work:
Install-Module AzureADHybridAuthenticationManagement -AllowClobber
Set-AzureADKerberosServer -Domain $domain `
-CloudCredential $cloudCred -DomainCredential $domainCred
Get-AzureADKerberosServer -Domain $domainTwo prerequisites hide in plain sight. The first is identity plumbing: the users must be synchronized identities. Even though the devices are purely Entra-joined, the accounts need their on-premises attributes, the SAM account name, domain name, and security identifier, flowing through Entra Connect or Cloud Sync, because the partial ticket is built from them. Cloud Kerberos trust is for organizations with one foot on each side; a tenant with no Active Directory needs none of this, and I made that distinction deliberately in the anchor article of this family. The second is the client-side switch. One device-scoped policy setting, Use Cloud Trust For On Prem Auth, tells Windows to request and use the partial ticket. It rides the same settings catalog profile as the rest of your Hello configuration.
Neither side is on by default, and that produces the most common false alarm in the whole deployment: Hello provisions beautifully, the PIN works, and the first attempt at a file share throws a credential prompt. Nothing is broken. The credential simply has no path to a Kerberos ticket because nobody built one. If you carry any on-premises dependency at all, treat the Kerberos server object and the client setting as part of Hello enablement itself, deployed in the same ring, never as a follow-up task.
Line of sight, honestly
Every conversation about cloud Kerberos trust eventually arrives at the same question: does the device need to reach a domain controller? The answer is yes and no, and the distinction is the most useful thing in this article. Signing into Windows needs no domain controller. The Entra-joined device authenticates to Entra ID, cached sign-in covers the airplane and the coffee shop, and a user can work disconnected from your network indefinitely. Reaching an on-premises resource always needs one, because the partial ticket must be exchanged at a writable domain controller, and that exchange happens on demand, at access time, not at sign-in.
So the real question is routability. On the corporate LAN, the exchange just works. Over a VPN, it works the moment the tunnel gives the device DNS resolution for the domain and a route to a writable domain controller; users notice only that shares fail before the tunnel is up and succeed after. The same logic extends to a domain controller that lives in Azure or on any hosted infrastructure: Kerberos does not care where the writable DC is, only that the device can resolve and reach it. And the modern answer for a remote workforce that you would rather not give a full tunnel is Entra Private Access, which can publish the domain controllers themselves and broker exactly the traffic this exchange needs. That combination, Entra-joined laptop anywhere in the world, Hello sign-in, Private Access to the DCs, file share opens, is the cleanest expression of this architecture I have deployed.
With no path to a domain controller, on-premises access simply does not happen. The partial ticket sits unexchanged, the share prompts and fails, and everything cloud-side continues untouched. Design your remote access around that truth rather than against it.
What it does not solve
Cloud Kerberos trust covers integrated Windows authentication, which is to say the overwhelming majority of what legacy infrastructure actually asks of a workstation: SMB shares, printers, intranet sites doing Kerberos or NTLM, line-of-business applications riding integrated auth. It does not cover the scenarios that require presenting a certificate. RDP with supplied credentials is the one that surprises people; the workaround is Remote Credential Guard, or a certificate deployed into the Hello container, which is the certificate-trust conversation again. Run-as with the Hello credential, S/MIME signing, and server sign-in sit on the same list. Accounts in the domain’s privileged groups are excluded by the same safeguards that protect any read-only domain controller, which I consider a feature: your tier-zero admins should not be authenticating to domain controllers from a convenience credential anyway. And if the certificate trust policy is enabled anywhere it wins over cloud trust on that device, so run one model per device, chosen on purpose.
Three things called cloud trust
A naming collision costs real deployments real hours here, so let me separate three siblings that share infrastructure and nothing else. What this article describes is Windows Hello for Business cloud Kerberos trust: a device credential earning tickets to on-premises resources, partial ticket exchanged at your DC. Entra Kerberos for Azure Files is a different path: the device gets a cloud ticket for the KERBEROS.MICROSOFTONLINE.COM realm and talks to Azure Files directly, no domain controller in the transaction at all, which is exactly why FSLogix profiles on Azure Files work from devices that have never seen your network. And Azure Files also offers a feature literally named cloud trust between AD DS and Entra ID, which serves on-premises domain-joined clients and has nothing to do with Entra-joined devices whatsoever. If you wire up the wrong one, everything looks configured and nothing works. Check which realm the failing ticket belongs to before touching anything.
Proving it
The deployment verifies in two commands, run as the user on an enrolled device:
dsregcmd /status
CloudTgt : YES
OnPremTgt : YES
klist cloud_debugCloudTgt confirms Entra issued the partial ticket; OnPremTgt confirms a domain controller honored the exchange. A yes on the first and a no on the second is the signature of a routing or line-of-sight problem, not a Hello problem, and knowing that distinction before the first pilot user calls is worth the whole read. Once both say yes, you have the thing this family of articles has been building toward: a phishing-resistant credential, provisioned in rings on your terms, that opens both the cloud and the basement.
Intune Deployment Guide · Phase 2: Identity and Tenant Foundation
‹ Previous: [2.5.1] Rolling Out Windows Hello for Business: Rings, Not Switches
Next: [2.6] Delegating Intune: Roles, Scope Tags, and Scoped Permissions ›
