I had the honor to deploy Windows Hello for Business several times for customers transitioning to a modern workplace using Azure AD and Microsoft Intune to manage their Windows 10 devices - combined with hybrid user identities. Now I want to share the most common hurdles and my experiences with you.
Just to make sure that you have the modern mindset - here’s a little quote to reconsider your hybrid strategy (if not already done):
You don’t need a Hybrid Azure AD join for your Windows 10 devices. Be brave and don’t be afraid and switch to an Azure AD join. It will simplify your device management and significantly reduce the complexity.
Why additional configuration is required
To access on premise resources who rely on Active Directory (file shares, applications) kerberos is used as authentication protocol. If you have Azure AD connect in place and a user sign’s in with his hybrid Identity using a password to a Windows 10 device which is Azure AD joined he automatically receives the required kerberos tickets if he wants to access resources.
But if the sign-in happens with Windows Hello for Business credentials (pin, biometrics) the authentication flow get’s interrupted because whether the domain controller (if it’s not a Windows Server 2016 DC) or the client can verify the integrity of each other.
Possible configurations
For Azure AD joined devices the following Windows Hello for Business deployment options exist:
You have to chose your deployment strategy wisely - the key based authentication may look tempting but possibly you need to distribute other user-certificates as well like for WiFi authentication or an Always On VPN.
- You can find more details and the Hybrid Azure AD Join Deployment options in the slides from a community event I attended as a speaker
Big picture
For better understanding here’s a scheme of the involved components when using Windows Hello for Business SSO with on premise resources. As mentioned before NDES is not necessary - depending on your deployment option.
The number one issue from my experience is always the availability of the certificate revocation list (CRL). During the authentication flow a verification get’s performed:
- After a verification of the users pre-authentication data the KDC (Kerberos key distribution center) which is running on a Domain Controller returns a Ticket Granting Ticket (TGT). Thereupon the client determines if he can trust the response from the KDC. _ This includes a check if the certificate neither has expired nor been revoked, the certificate chain is valid and the CRL is valid and accessible. _
- When using certificate trust with WHFB the client sends as mentioned above in case #1 an authentication request but it includes also the user’s certificate and a verification if neither the certificate has expired nor been revoked, the certificate chain is valid and the CRL is valid and accessible. On success the KDC returns a TGT and the client will verify the response.
Requirements
The certificate revocation list must be accessible from every client involved in the authentication flow. Assuming that you have published your CRL with a web server make sure that the CRL is available trough HTTP and not HTTPS. Please also note that Hybrid Azure AD joined devices cannot access the LDAP CRL.
Windows provides a very helpful an powerful tool called certutil to verify the CRL accessibility (and basically support for all operations for certificate deployments). Run it on your DC’s and your Windows 10 clients to verify the accessibility. If you are running a web proxy with user authentication also check the accessibility under the SYSTEM account using PsExec.
You can check the CRL availability with:certutil -url "%CRL URL%"certutil -url "%Exported certificate file path%"
And here some examples:certutil -url "http://crl.nicolonsky.ch/nt-issuing-ca"certutil -url "c:\temp\nicolonsky-nicola.cer"
At this point I also recommend to remove unused or unavailable CRL paths.
More log resources
The validation of the certificate chain and CRL can also be traced in the Windows eventlog. Simply enable the “Microsoft-Windows-CAPI2/Operational” log and you’ll find all certificate validation based entries there.
Issue #2: Domain Controller Certificates
The domain controller certificates must be installed on all domain controllers which handle authentication requests. Make sure that the certificate is valid for the KDC Authentication usage and the primary DNS domain name (e.g. intra.contoso.com) is included in the SAN. To avoid any missing certificate properties copy the “Kerberos Authentication” certificate template.
For an easier management of the Domain Controller certificates I strongly recommend to enable auto enrollment.
Issue #3: Enterprise CA
For all cloud Windows Hello for Business deployment scenarios (Hybrid Azure AD Joined & Azure AD Joined) enterprise CA infrastructure is required. Whereas for key trust deployments certificates are only required on domain controllers; for a certificate trust certificates must be distributed to end users.
Final thoughts
I hope this post helps you to spin up your Windows Hello for Business deployment. Have you experienced other issues during the deployment? Please leave a comment and I’ll update the post accordingly.