A Guide to Troubleshooting WHFB Sign-In Issues in a Hybrid Environment


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 TrustKey TrustCertificate Trust
PKI (AD CS)Not RequiredRequiredRequired
AD FSNot RequiredNot RequiredRequired
Policies (GPO, Local Policies, Intune)Use Windows Hello for Business
Use cloud Kerberos trust for on-premises authentication
Use Windows Hello for BusinessUse Windows Hello for Business
Use certificate for on-premises authentication
KDC CertificateNot RequiredRequiredRequired
Key/CertificateIssued to userSIDIssued to userSIDIssued to userSID
Issued to username
DC ObjectAzureADKeberosRequiredRequired

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

  1. 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.
  2. 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.
  3. Upon successful validation, the KDC returns a Ticket Granting Ticket (TGT) to the client with its KDC certificate in the KERB_AS_REP.
  4. 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.