I'm managing an environment with devices enrolled through Intune and connected via Entra. A subset of users is experiencing intermittent problems with Kerberos tickets when they log in using Windows Hello for Business, be it via PIN or biometrics, especially after a fresh boot at the beginning of the workday. There are times when devices don't generate the Kerberos tickets right away, preventing proxy authentication and leading to several issues. It usually resolves itself after a few minutes, although if someone is impatient, locking and unlocking the device with a password seems to help too. Interestingly, using password authentication doesn't seem to trigger any problems.
The logs show an indication of issues with Event ID 9 from the Security-Kerberos source, suggesting a failure to validate the domain controller certificate with an error stating the revocation function could not check because the revocation server was offline. We've engaged multiple teams (workplace, Active Directory, and networking) but still haven't found a solid fix. While the entire chain of CRL and URLs has been checked and deemed functional, this issue is unpredictable—out of 1500+ users, most report no problems. Any suggestions would be greatly appreciated! I've also been advocating for implementing Cloud Kerberos trust, but the response has mostly been skepticism about its risks and impacts, even though Key Trust isn't meeting our needs effectively.
4 Answers
I’d also recommend checking if you're mixing Cloud Trust and Certificate Trust in your Intune settings; that can cause strange issues. If you switch to Cloud Trust, make sure to push that policy out properly. Switching back can also have complications, especially when it comes to certificate redeployment. Each user needs to manually handle their Hello container deletions, which can complicate things.
I've noticed that Key Trust for Windows Hello for Business has been shaky lately, primarily due to Kerberos issues with certificates. In smaller setups like ours, we rely heavily on Cert Trust for WHFB and have only a couple of domain controllers. One thing that really helped was ensuring that all domain controllers are running the same version. Differences in DC versions led to Kerberos failures after device password resets. Matching everything across the board helped resolve those issues.
Another thing to consider is the number of certificates in your domain controllers. I've had problems where if you have multiple certificates, the selection process fails because Schannel breaks down. The logs won't say much, but it's crucial to have just the Kerberos auth EKU certificate in the store to avoid selecting the wrong one. Removing extraneous certificates has cleared up many of these issues for us.
It sounds like you might need to take a closer look at your CRL implementation. Exposing the CRL via HTTP along with Entra App Proxy really helped us before we transitioned to Cloud Trust. It made a big difference in ticket generation timing when users log in.
Yeah, we've got devices either on the internal network or connected through an always-on VPN, so I'm surprised this is still an issue.
Ugh, that sounds frustrating! It feels like every patch Tuesday, something new goes wrong with these settings. Thanks for the tips!