I was troubleshooting an issue with Windows Hello for Business recently. I’ve tried setting it up in my home lab so I understand how it works for hybrid-joined computers. This post is about what I learned about the authentication flows for key trust and certificate trust, and why understanding them is essential for troubleshooting.

I could sign in with Windows Hello on the corporate network but ran into issues when on a remote network (secured with specific firewall restrictions). It would initially work but then after some time, I couldn’t sign-in using the Windows Hello pin or biometric until I connected back to the corporate network. My setup is hybrid-joined.

In my case, I am using the key trust model. Windows Hello generates a public/private key pair. The private key stays in the TPM, while the public key is registered in Microsoft Entra ID and then synchronized back into Active Directory via Entra Connect. This allows both AD (for Kerberos) and Entra ID (for cloud) to validate the same credential.

Rather than describe every step, I am hoping that the diagram below can explain it better:

whfb-key

When the computer is offline, Windows Hello uses cached credentials to login to the computer. If the computer has internet access, then it can refresh the PRT against Entra ID. Accessing cloud apps using Entra ID login continues to work.

To refresh the Kerberos tickets, it needs line of sight access to the AD Domain Controller. The Kerberos ticket is required to access my on-prem resources that rely on AD authentication. You can check the Kerberos tickets by running klist from the command prompt. What I noticed is that although the computer can access certain corporate AD-integrated resources like a file server when I connect it to the remote (firewall/restricted) network, the authentication fails because the cached Kerberos tickets expired and is unable to get a new one from my AD Domain Controller. Connecting it back to the corporate network works because the computer is then able to fully communicate with the AD Domain Controller and acquire a new Kerberos tickets.

The certificate trust model, works the same way as the key trust model so I won’t go into detail. The only difference is that:

  • Key Trust Model = Windows Hello generates a public/private key pair. The public key is stored in the user object in Active Directory (via synchronization from Entra ID). Authentication relies directly on this key.

  • Certificate Trust Model = This works similarly but adds an extra layer. An internal Certificate Authority issues a certificate that contains the Windows Hello public key. That certificate is then mapped to the user object in AD. Certificate trust wraps the public key in a CA-issued certificate, whereas key trust stores the public key directly.

I suspect my current issue stems from my computer having restricted communication with the Domain Controller, possibly because certain ports or channels are blocked when I’m on the remote (firewall/restricted) network. When I connect directly on the corporate network, the computer can fully communicate with the Domain Controller, and everything functions as expected. In contrast, when that communication is limited, authentication problems arise after a while because the device cannot properly exchange the required Kerberos traffic with the Domain Controller.

Observations during logon:

  • When the computer is fully offline or on a network that has no connection to your Domain Controller, Windows Hello works because it falls back to using the cached credentials and the PIN/Biometric works as it does not need to validate.
  • When I am quick enough to login using Windows Hello before the network is established/connected, it uses the cached credentials so it works.
  • When the computer is connected to the remote (firewall/restricted) network that has a “semi-working” connection to the Domain Controller, Windows Hello does not work as it will try to validate its private key with the public key on the Domain Controller and something is blocking it. The username/password works because it just falls back to the local cached credentials. Sometimes running a klist purge fixes it temporarily and intermittently stops working again.
  • When the computer is on the corporate network, Windows Hello works as it is able to fully validate its private key with the public key on the Domain Contoller.

There is also the issue of negative caching where the device caches the failed connection with the KDC/Domain Controller. The default cache is 10 minutes and can be set to 0 using the following registry key:

HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters
Name: FarKdcTimeout
Type: REG_DWORD
Value: 0 (minutes)

In my case, opening the correct/missing ports/path to the Domain Controller fixed my issue, but this experience has helped me understand the authentication process of Windows Hello for Business. Next steps for me is to understand how Cloud Kerberos Trust works. I’ll try to document my learnings on a future post.