Cloud Kerberos Trust, Explained: What Microsoft Entra Kerberos Covers, and What It Leaves Out

Lukas Schönbächler · July 2026 · 7 min read

Your company rolls out FIDO2 keys or Windows Hello for Business. Sign-in works, Microsoft 365 works, everyone is happy. Then someone opens the intranet portal, and instead of the page they get an authentication error.

That’s the problem cloud Kerberos trust exists to solve, and it lives squarely in the hybrid environment: Microsoft 365 and Entra ID in the cloud, Active Directory still running the intranet sites on IIS, the applications behind AD FS, and the file shares on-prem. Classic Kerberos derives the user’s key from a password. Remove the password and the domain controller has nothing to build a ticket from, so everything that authenticates with Kerberos stops working for that user. This one gap has stalled more passwordless projects than any licensing question ever did.

What Microsoft Entra Kerberos actually is

Microsoft Entra Kerberos turns your Entra ID tenant into a second Kerberos realm, KERBEROS.MICROSOFTONLINE.COM, that lives alongside your on-premises Active Directory realm. Entra ID can then issue Kerberos tickets itself. Microsoft introduced it in 2021, and “cloud Kerberos trust” is the deployment model that uses it for Windows Hello for Business and FIDO2 sign-in.

When a user signs in to an Entra-joined or hybrid-joined Windows machine, the device gets a Primary Refresh Token (PRT) from Entra ID. Along with the PRT, Entra ID hands out two Kerberos tickets:

• A cloud TGT for the KERBEROS.MICROSOFTONLINE.COM realm. This one is used for cloud resources that speak Kerberos, mainly Azure Files and Azure SQL Managed Instance.
• A partial TGT for your on-premises AD domain. It contains the user’s SID and nothing else. No group memberships, no PAC.

The partial TGT is the interesting part. On its own it grants access to nothing. The Windows client takes it to an on-premises domain controller and exchanges it for a full TGT, complete with group memberships. From there, everything works as it always has: the client requests service tickets, the intranet loads, and the file share opens.

Figure 1: The cloud issues only a partial ticket. Your own domain controllers still turn it into real access, which is why DC line of sight remains a requirement.

To make the exchange possible, you create a Microsoft Entra Kerberos server object in your AD. Technically it’s a read-only domain controller (RODC) object, and Entra ID uses its key to sign the partial TGTs your real DCs will later accept. The RODC object’s allow and deny lists control which users may use the mechanism at all, and Microsoft recommends default deny with explicit allow groups.

What you need for it

The prerequisites are short but strict, and they describe exactly the hybrid setup most established companies already run:

• Hybrid identities. Users must exist in on-premises AD and sync to Entra ID through Entra Connect.
• The Entra Kerberos server object in AD, created with the AzureADHybridAuthenticationManagement PowerShell module.
• Windows 10 2004 or later, Entra-joined or hybrid-joined.
• Domain controllers patched for cloud trust, and reachable from the client. The partial-to-full TGT exchange happens against a real DC, so line of sight to a domain controller is still required for on-premises resources. Cloud Kerberos trust removes the password, not the network dependency.

That last point surprises people. The cloud issues the partial ticket, but your DCs still do the heavy lifting for anything on-premises.

What it’s good for

Three scenarios carry most of the real-world usage.

True passwordless sign-in in a hybrid environment is the headline. A user signs in with a FIDO2 key or Windows Hello, and still reaches everything Kerberos protects: the intranet sites running on IIS with Windows authentication, the applications behind AD FS, and the SMB file shares. No password at sign-in, no password stored or typed behind the scenes, and the legacy estate keeps working. This is what actually lets a hybrid organization remove the password rather than just hide it. You also skip the certificate-to-every-client rollout the older certificate trust model demanded.

Azure Files is the second. Entra ID issues service tickets for cifs/<account>.file.core.windows.net directly, so Entra-joined VMs and clients can mount Azure file shares without talking to a DC. FSLogix profile containers for Azure Virtual Desktop are the common case here. One caveat worth knowing before you design around it: conditional access policies that require MFA must exclude the storage account, because the Kerberos flow can’t satisfy an MFA claim.

Windows authentication to Azure SQL Managed Instance is the third, useful when you’re lifting old database workloads into Azure and the connection strings assume integrated auth.

Where it stops

Here’s the part the deployment guides don’t dwell on. The whole mechanism rides on components that only exist on certain platforms. The tickets are fetched by the Windows credential stack (CloudAP, the same plumbing that manages the PRT) or, since Platform SSO, by macOS. There is no public protocol for anything else to request them. A standard Kerberos client can’t send an AS-REQ to Entra ID and get a TGT back; ticket issuance is welded to the PRT.

Platform	Entra Kerberos / cloud Kerberos trust	Classic Kerberos client
Windows 10 (2004+) / 11, Entra- or hybrid-joined	Yes	Built in
macOS with Platform SSO	Yes	Built in
iOS / iPadOS	No	Apple’s Kerberos SSO extension, via MDM
Linux	No	krb5 / SSSD
Android	No	Nothing built in: Hypergate Authenticator

Not every “No” in that column weighs the same. iOS ships Apple’s Kerberos Single Sign-on extension, which your MDM can configure to fetch tickets from your on-premises domain controllers the classic way, with a password or a certificate. Linux has carried krb5 and SSSD for decades. Neither can talk to Entra ID’s cloud KDC, but against a reachable DC they do the job.

Android is the odd one out: no OS Kerberos client at all. Nothing to configure, nothing to fall back on. So the moment a phone or a rugged Android scanner in a warehouse needs to reach your Kerberos-protected resources, neither cloud Kerberos trust nor the platform has anything to offer. Microsoft says this themselves, in an unexpected place: the install guide for the Global Secure Access client on Android notes that “to enable a Kerberos single sign-on (SSO) experience, install and configure a non-Microsoft SSO client.” The tunnel to your network is Microsoft’s; the Kerberos part on Android is explicitly someone else’s job.

Filling the Android gap

Full disclosure: that job is our product. Hypergate Authenticator is a Kerberos client for Android and iOS. It obtains tickets from your existing domain controllers, using certificates (PKINIT) or passwords, and hands SPNEGO tokens to managed browsers and apps the same way Windows does natively: the intranet on IIS, the apps behind AD FS, everything that expects a ticket. With certificates, mobile becomes truly passwordless too: the same end state your Windows fleet just reached through cloud Kerberos trust, and your EMM already knows how to distribute them. On Android it fills a hole the platform leaves open; on iOS it gives you one configuration and one behavior across both halves of the mobile fleet instead of maintaining Apple’s extension separately.

And when the resource your mobile users actually need is the file share itself, Hypergate Files builds on the same Kerberos SSO: a managed mobile file browser for your SMB shares, so the warehouse scanner and the field tablet open the same shares your desktops mount, without a password prompt.

Figure 2: Both paths end at the domain controllers you already run. Cloud Kerberos trust covers the desktop estate; Hypergate covers mobile, against the same infrastructure.

The two approaches complement each other rather than compete. Cloud Kerberos trust covers your Windows and Mac estate. A mobile Kerberos client covers everything else, against the same infrastructure you already run. If you’re deploying Entra Private Access as the network path, the combination is straightforward: publish your DCs through the tunnel, and the mobile client authenticates through it.

The short version

Cloud Kerberos trust is worth deploying if you run a hybrid environment and want truly passwordless Windows sign-in without breaking two decades of Kerberos-protected infrastructure. It’s a well-designed bridge, and considerably less painful than the certificate trust model it largely replaces. Just go in knowing its shape: hybrid identities only, DC reachability still required for on-premises access, MFA exclusions for Azure Files, and no Entra Kerberos on anything that isn’t Windows or macOS. iOS and Linux can fall back on their classic Kerberos clients. Android can’t, and for it you’ll be shopping for a Kerberos client. Microsoft’s docs say as much.

---