The user signs in with their PIN, the desktop loads, cloud apps work perfectly - and then they open a file share and get a credential prompt, or a mapped drive shows a red X. "Windows Hello is broken," the ticket says. It usually is not. What is broken is the hand-off between the passwordless sign-in and the on-premises Kerberos ticket, and there are only a handful of places that hand-off can fail. This post walks the on-premises single sign-on (SSO) chain for Windows Hello for Business (WHfB) and shows you how to find the exact broken link.
The problem: cloud works, on-prem does not
This is the signature of an on-premises SSO failure, and it is worth stating precisely because it rules out half the possibilities immediately: the user can sign in with Hello and reach Microsoft 365, but cannot silently reach an Active Directory (AD) resource - a file share, a print server, an internal site using Integrated Windows Authentication. Sign-in itself works, so the WHfB credential is fine. The problem is downstream, in getting a Kerberos ticket the domain controller (DC) will honour.
Why it happens: the passwordless-to-Kerberos hand-off
Cloud resources use a Primary Refresh Token (PRT). On-premises resources use a Kerberos ticket-granting ticket (TGT). On a cloud Kerberos trust device, the chain is: sign in with Hello → get a partial TGT from Microsoft Entra ID → exchange it at a real DC for a full TGT → use that to get service tickets for file shares. On-prem SSO breaks when any link in that chain is missing:
- No PRT - so there is nothing to carry the partial TGT.
- Entra Kerberos not set up for the user's domain - so no partial TGT is issued.
- No line of sight to a writable DC - so the partial TGT cannot be exchanged for a full one.
- DCs not patched for the exchange - so they reject the partial TGT.
How to verify: walk the chain one command at a time
1. Is there a PRT and an on-prem TGT?
dsregcmd /status is your first stop. In the SSO State block you want AzureAdPrt : YES (the cloud token exists) and OnPremTgt : YES (a full AD TGT was obtained). If the PRT is missing, fix that first - nothing downstream works without it.
2. Is a Kerberos ticket actually cached?
klist shows the tickets in the current session. A healthy on-prem SSO device has a krbtgt/YOURREALM ticket. No krbtgt ticket confirms the partial-to-full exchange never completed:
3. Can a DC even service the exchange?
Cloud Kerberos trust needs DCs that advertise the Entra Kerberos capability. Confirm at least one writable DC per site responds to the key-list query (the /keylist switch is Windows 10 2004+):
The fix: match the failure to the link
| Symptom | Broken link | Fix |
|---|---|---|
AzureAdPrt : NO | No PRT | Repair the PRT (network/DC connectivity, re-register the device); nothing on-prem works without it |
PRT YES, OnPremTgt : NO, no DC reachable | No line of sight to a DC | Get the device on a network that can reach a writable DC (VPN before logon for remote users), then sign in again |
PRT YES, DC reachable, still OnPremTgt : NO | Entra Kerberos not set up, or DCs unpatched | Confirm the AzureADKerberos object exists for the domain and DCs have the required patches |
| Everything YES but one app prompts | Service principal name (SPN) / delegation on that app | Standard Kerberos SPN troubleshooting - not a WHfB problem |
Proof it worked
Here is a real run of Test-OnPremSsoHealth.ps1 from this series, against a device where the whole chain is healthy end to end:
Every link in the chain from the "How to verify" section above reads YES/True in one script run instead of three separate commands - this is the fast path once you have used the manual steps once to understand what each field means. A healthy device shows AzureAdPrt : YES and OnPremTgt : YES in dsregcmd /status, a krbtgt/YOURREALM entry in klist, and opens \\fileserver\share with no credential prompt. Run those three checks in order and the broken link identifies itself.
dsregcmd /status and klist output from a known-good device on your network and keep it. When a ticket comes in, a thirty-second diff against that baseline tells you which line changed - PRT, OnPremTgt, or the ticket cache - and that single difference is your root cause. Troubleshooting on-prem SSO blind is slow; troubleshooting it against a baseline is not.References
- Troubleshoot devices by using the dsregcmd command
- Enable passwordless SSO to on-premises resources (Entra Kerberos, nltest /keylist)
- Windows Hello for Business authentication technical deep dive
- What is a Primary Refresh Token
Script for this post is in Daily-Tasks.