HomeNewsletterCommunityMVP FeedToolsArchiveBlogToday's NewsAboutServicesQuick Links Subscribe free
← Back to Blog
Windows Hello for Business WHfBOn-Prem SSOKerberosCloud Kerberos TrustdsregcmdTroubleshooting

Windows Hello Signs In Fine but File Shares Prompt: Fixing On-Premises SSO

IA
Imran Awan
31 July 2026

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:

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.

Command Prompt
C:\> dsregcmd /status | findstr /i "AzureAdPrt OnPremTgt CloudTgt" AzureAdPrt : YES # cloud token OK OnPremTgt : NO # the problem - no full AD TGT CloudTgt : YES

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:

Command Prompt
C:\> klist Cached Tickets: (0) # empty = no TGT was obtained; on-prem SSO will prompt

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+):

Command Prompt
C:\> nltest /dsgetdc:contoso /keylist /kdc DC: \\DC01.contoso.com The command completed successfully # a capable DC answered

The fix: match the failure to the link

SymptomBroken linkFix
AzureAdPrt : NONo PRTRepair the PRT (network/DC connectivity, re-register the device); nothing on-prem works without it
PRT YES, OnPremTgt : NO, no DC reachableNo line of sight to a DCGet 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 : NOEntra Kerberos not set up, or DCs unpatchedConfirm the AzureADKerberos object exists for the domain and DCs have the required patches
Everything YES but one app promptsService principal name (SPN) / delegation on that appStandard Kerberos SPN troubleshooting - not a WHfB problem
Gotcha: On a Microsoft Entra hybrid joined device the first Hello sign-in must have line of sight to a DC to build the on-prem TGT. A user who provisioned Hello at home over the internet, then walks into the office, is the classic "worked yesterday, broken today" case - except it never worked on-prem, they just had not tried a share yet. The first successful on-prem sign-in has to happen with DC connectivity.
Watch out: High-privilege accounts are deliberately blocked from getting a partial TGT via cloud Kerberos trust - the Password Replication Policy on the AzureADKerberos object excludes members of privileged groups. If your test account is a Domain Admin, on-prem SSO "failing" is the control working as designed, not a bug. Test with a normal user.
Note: Password expiry causes a subtle variant of this. WHfB sign-in itself is unaffected by an expired password (it uses a key), so the user gets in - but they are never prompted to change the expired password, and AD-protected resources then reject them. If SSO breaks the day a password expires, the fix is a password change (Ctrl+Alt+Del › Change a password), not WHfB troubleshooting. Consider PIN expiration policies instead of password expiration for Hello users.

Proof it worked

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.

Tip: Bank the healthy baseline. Capture 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

PowerShell Scripts — On-Prem SSO Health

Script for this post is in Daily-Tasks.

Test-OnPremSsoHealth.ps1 — read-only: walks the PRT → partial TGT → full TGT chain (dsregcmd + klist) and names the first broken link
View all scripts on GitHub
Share this post
LinkedIn X / Twitter Reddit Bluesky

More from EndpointWeekly

Windows Hello for Business
Key Trust vs Certificate Trust vs Cloud Kerberos Trust: Which…
Three trust models, and most admins cannot say for certain which one a given device is…
Windows Hello for Business
dsregcmd /status Decoded: The Complete Field Reference for WHfB…
One command answers more WHfB questions than any portal - and its forty-plus fields come…
Windows Hello for Business
The Complete Windows Hello for Business Event ID Catalog (Across…
WHfB logs to three different places with cryptic IDs and no index. This catalog maps…