A Guide to Troubleshooting WHFB Sign-In Issues in a Hybrid Environment
Overview
In this post, we’re assuming that the end customer has already completed the WHFB deployment and successfully provisioned the PIN sign-in method. However, they encountered a sign-in failure when using the WHFB sign-in options to login windows or SSO to the on-prem resources.
1. Identify the Trust Type
Firstly, it’s always important to check the type of trust used for WHFB sign-in. Following the zero-trust strategy, it’s recommended to verify this independently. There are several aspects that we can inspect.
| Cloud Kerberos Trust | Key Trust | Certificate Trust | |
| PKI (AD CS) | Not Required | Required | Required |
| AD FS | Not Required | Not Required | Required |
| Policies (GPO, Local Policies, Intune) | Use Windows Hello for Business Use cloud Kerberos trust for on-premises authentication | Use Windows Hello for Business | Use Windows Hello for Business Use certificate for on-premises authentication |
| KDC Certificate | Not Required | Required | Required |
| Sign-in Key/Certificate | Issued to userSID | Issued to userSID | Issued to userSID Issued to username |
| DC Object | AzureADKeberos | Required | Required |
1.1 KDC Certificate (Used in Key Trust and Cert Trust)
The KDC certificate is stored in the Domain Controllers in an Active Directory environment. It is instrumental in ensuring secure and trustworthy communication in the Kerberos authentication process.
Windows Hello for Business hybrid key trust deployment guide – Windows Security | Microsoft Learn
How Windows Hello for Business authentication works – Windows Security | Microsoft Learn
- The Kerberos provider sends signed preauthentication data and the user’s public key (in a self-signed certificate) to the KDC service on the domain controller.
- The domain controller verifies the self-signed certificate, retrieves the public key from the certificate, and searches for the public key in Active Directory. It validates that the User Principal Name (UPN) for the authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory.
- Upon successful validation, the KDC returns a Ticket Granting Ticket (TGT) to the client with its KDC certificate in the KERB_AS_REP.
- The Kerberos provider then verifies the trustworthiness of the response from the domain controller. It checks that the KDC certificate chains to a trusted root certificate, is within its validity period, hasn’t been revoked, has the enhanced key usage KDC Authentication present, and that the subject alternate name in the KDC’s certificate matches the domain name to which the user is authenticating.
Verifying at least three aspects will help us narrow down the actual trust type. If identification is not possible, no worries, because for WHFB sign-in issues, our troubleshooting is inseparable from the authlog (provided on aka.ms/authscript). The following section will guide how to determine what trust type is used through the logs in the authlog.
2. Narrow down the Issue
After the trust type has been identified, we will have a clearer picture to help narrow down the issues that the customer is encountering. For example, if a customer has just set up key trust and finds they can’t log in, we can quickly consider whether the customer needs to wait for the 30-minute key write-back time to be able to log in normally.
I will also outline some common issues. If the customer’s issue aligns with these patterns, it might be possible to resolve the problem directly.
2.1 Key Trust – “That option is temporarily unavailable.”
After the user provisions a Windows Hello for Business credential in a hybrid key trust environment, the key must sync from Microsoft Entra ID to Active Directory during a Microsoft Entra Connect Sync cycle. The user’s public key is written to the msDS-KeyCredentialLink attribute of the user object.
There could be several reasons for the issue. The user might just need to wait for a sync cycle to allow the public key to sync back to the user attribute. Additionally, the problem could also be caused by an inheritance issue with the MSOL service account, which may not have the rights to write the attribute in the user account. Moreover, it could be related to the deletion issue mentioned in this document: Windows Hello for Business known deployment issues – Windows Security | Microsoft Learn
If the issue is particularly challenging, we will need to capture the authlog. You can refer to this post to understand the process of capturing the authlog. By examining the log, we can ultimately pinpoint the specific problem.