Windows Hello enables users to log in to their Windows devices with biometrics or a pin. These methods are accepted for Microsoft logins as well. Logging in with face recognition, fingerprint, or pin allows for a more seamless authentication experience.
In environments that restrict local admin access, Windows Hello can be used on User Account Control (UAC) prompts when users are temporarily granted admin rights. This reduces the burden of keying in passwords multiple times when launching programs as an administrator.
Optionally, the password method of logging in can be hidden to promote a ‘Passwordless Experience’ with password authentication only appearing when setting up Windows Hello. Overall, this leads to a more streamlined authentication experience, enabling access with the touch of a finger; however, it is important to select the correct Windows Hello deployment model to ensure that it works correctly on and off the corporate network.
If Windows Hello is not integrated with Active Directory correctly, users on the corporate network will experience issues when using pin, fingerprint, or face recognition.
The next section covers guidance for deploying Windows Hello to different environments.
Azure AD Only Environments
If your Domain is hosted in Azure AD only (no On-Premises/on-premActive Directory), then Windows Hello will work right out of the box with no need to link with an on-premises environment. Microsoft Intune can be used to manage Hello Policy, such as pin complexity, allowed authentication options, etc.
Azure AD Hybrid Environments
If you have an on-prem AD that synchronizes to Azure AD, you will want to configure Windows Hello to utilize one of the following trust types:
- Key Trust
- Certificate Trust
- Cloud Kerberos Trust
Certificate & Key Trust
Both Certificate and Key Trust require an on-prem PKI to function. If your domain does not have this, you can defer to the ‘Cloud Kerberos Trust’ Section. If your domain is federated, you will utilize the Certificate Trust model. If it is not federated, then use the Key Trust deployment plan.
See the resources below for each deployment type:
Cloud Kerberos Trust
If you do not have or do not wish to utilize an on-prem PKI, you can instead opt to use Azure AD Kerberos and create an Active Directory server object that handles Azure Kerberos Ticket-Granting-Ticket requests.
All four deployment models are specific implementations of Windows Hello. Which trust type you choose comes down to compatibility and preference. For example, we do have a PKI in our environment, and we could utilize the certificate-based trust types — yet we opt to use the Cloud Kerberos Trust Deployment for simplicity, as integrating it with Kerberos proved simpler. Choose the correct deployment plan for your environment and follow the documentation carefully to ensure the best user experience.
Solving Deployment Issues
Sometimes the deployment is bumpy, it is important to recognize known deployment issues quickly, and establish where the issue is from: client configuration, domain configuration, or issues with Kerberos or PKI.
Sometimes the cause of errors is not so obvious, so do not forget to check event viewer when troubleshooting as well: ‘Application logs and Services > Microsoft > Windows> Hello For Business’
If your organization uses Azure AD exclusively, implementing Windows Hello is a no brainer, and it works right out of the box. Most organizations, however, utilize a hybrid domain. Using Windows Hello without tailoring it to your environment can rob users of a consistent passwordless experience. Windows Hello requires a bit more planning and effort to deploy in hybrid environments, but, with a little bit of planning, users can enjoy a consistent passwordless experience.
DMC is a Microsoft Solution Partner. Learn more about DMC’s Enterprise Mobility + Security (EMS) expertise and contact us today for your next project.