Windows Hello for Business: PKI Requirements, Deployment Models, and Common Failures
Windows Hello for Business (WHfB) provides phishing-resistant, certificate-based or key-based authentication for Windows devices. The PKI requirements vary significantly between the three deployment models: Key Trust, Certificate Trust, and Cloud Kerberos Trust. This article covers the ADCS configuration requirements for each model and the most common deployment failures.
WHfB Deployment Models
Windows Hello for Business has three deployment models, each with different PKI requirements:
- Key Trust — Uses asymmetric key pairs stored in the device TPM. Requires Azure AD or hybrid Azure AD join. No ADCS certificate issuance required for the WHfB credential itself, but ADCS may still be needed for other authentication scenarios.
- Certificate Trust — Issues a WHfB certificate from ADCS to the device. Requires ADCS with a certificate template configured for WHfB enrollment. Supports on-premises-only environments.
- Cloud Kerberos Trust — Microsoft's recommended model for hybrid environments. Uses Azure AD Kerberos to issue Kerberos tickets. Requires Azure AD Connect and Azure AD Kerberos configuration, but minimal ADCS involvement.
ADCS Requirements for Certificate Trust
Certificate Trust deployment requires a certificate template configured specifically for WHfB. The template must meet these requirements:
- Subject Name: Supply in the request (the device provides the subject name during enrollment).
- EKU: Smart Card Logon (1.3.6.1.4.1.311.20.2.2) and Client Authentication (1.3.6.1.5.5.7.3.2).
- Key Usage: Digital Signature.
- Enrollment: Domain Computers or the device group must have Enroll permission.
- Validity: 1 year recommended; shorter validity requires more frequent renewal.
Common Deployment Failures
The most common WHfB deployment failures related to PKI:
- Missing Smart Card Logon EKU — the WHfB certificate template does not include the required EKU, causing PKINIT failures.
- CRL unreachable from domain controllers — DCs perform revocation checking on WHfB certificates; inaccessible CDPs cause authentication failures.
- NTAuthCertificates not populated — the issuing CA certificate is not in the NTAuthCertificates AD object, preventing Kerberos PKINIT trust.
- Template not published to the CA — the WHfB template exists in AD but has not been added to the issuing CA's template list.
- Hybrid Azure AD join not completed — devices must be hybrid Azure AD joined for Certificate Trust to work in hybrid environments.
Windows Hello for Business is one of the most effective phishing-resistant authentication methods available for Windows environments. Getting the PKI configuration right is the most common barrier to successful deployment. A misconfigured WHfB deployment results in authentication failures that are difficult to diagnose without understanding the underlying PKI requirements.
- 1Choose the right deployment model: Cloud Kerberos Trust for hybrid environments, Certificate Trust for on-premises-only.
- 2For Certificate Trust: create a dedicated WHfB certificate template with the correct EKUs and subject name settings.
- 3Verify the issuing CA certificate is in NTAuthCertificates: "certutil -viewstore -enterprise NTAuth".
- 4Test WHfB enrollment with a pilot group before broad deployment.
- 5Monitor for Event ID 4768 with certificate authentication to verify WHfB is working correctly.
Cloud Kerberos Trust is the right choice for most hybrid environments — it minimizes ADCS complexity while providing the same phishing-resistant authentication. If you are deploying Certificate Trust, treat the PKI configuration as carefully as you would any other ADCS deployment. The failure modes are the same.
InsecurePlanet provides original technical analysis based on the sources listed below. This article does not claim facts beyond the cited source material.