Windows Hello for Business is a modern two-factor authentication that replaces password authentication on devices. This authentication consists of a new type of user credential that is tied to a device and uses a biometric or PIN. This guide will discuss All you need to know before deploying Windows Hello for Business Key and Certificate Trust. Windows Hello for Business lets the user authenticate to an Active Directory or Azure Active Directory account. Here is a guide on how to synchronize your on-premises AD with Azure Active Directory using the Azure AD Connect tool, and how to use the built-in AAD Connect troubleshooting tool.
Update: There is a new cloud Deployment Model: WHFB Hybrid Cloud Kerberos Trust Model is now Generally Available.
Windows Hello addresses resolve these issues with passwords: Also, see how to backup existing and new BitLocker recovery keys to Active Directory.
- Since very strong passwords are difficult to remember, and the possibility of reusing the same password on multiple sites often presents itself.
- Server breaches can expose symmetric network credentials (passwords)
- Passwords are subject to replay attacks and
- Users can inadvertently expose their passwords due to phishing attacks or have to write them down due to their complexity.
Windows Hello for Business can be deployed in the following areas: Cloud, Hybrid, and On-Premises environments. This is a very secure solution as it has a device-based MFA enabled by default and it is asymmetric in nature when implemented. This moves Organizations beyond the security pitfalls of passwords.
Cloud Deployment
Windows Hello for Business supports with AAD joined, Hybrid Azure Active Directory joined, or Azure Active Directory registered devices and also works for domain-joined devices.
Windows Hello for Business relies on these factors
Remote Authenticator (Phone, PIN, Unique Identifier, Biometric [Face recognition or fingerprint). Windows Hello for Business supports by default MFA.
Also, see BitLocker Drive Encryption architecture and implementation types on Windows, how to fix missing BitLocker Recovery Tab in Active Directory Users and Computers, and how to enable or disable BitLocker Drive Encryption on Windows 10 and Virtual Machines.
Other Benefits of Windows Hello for Business
Provides seamless SSO to Apps and Services. When in an unknown location (Network), there is an additional configuration that can be applied which will require Windows will prompt you to authenticate with a different means instead of face recognition.
Prerequisites for Deploying Hello for Business
This depends on your need and I will be discussing all applications (Cloud, Hybrid, and On-Premises environment) need. A key prerequisite of all cloud and hybrid Windows Hello for Business deployments is device registration.
A user cannot provision Windows Hello for Business unless the device from which they are trying to provision has registered with Azure Active Directory.
Hybrid Deployment
For this deployment, here are the needed prerequisites.
- Windows 10, version 1511 or above - Server 2016 schema - Windows Server 2016 or above Domain Controller (DC) - Azure Account - Azure Active Directory - Azure MFA or AD FS with Azure MFA - Subscription: Azure AD Premium
On-Premise Deployment
For this deployment, here are the needed prerequisites.
- Windows 10, version 1511 or above - Server 2016 schema - Windows Server 2016 or above Domain Controller (DC) - ADFS with 3rd party MFA - ADFS with Azure MFA Then an Azure Account will be needed for Azure MFA billing.
Cloud Deployment
For this deployment, here are the needed prerequisites.
- Windows 10 - Microsoft Azure Account - Azure Active Directory - Azure MFA - (Modern Management System -Intune or a 3rd party MDM).This is optional - Azure AD Premium subscription (needed for automatic MDM enrollment when the device joins Azure Active Directory). This is optional as well.
Windows Hello for Business Mode of deployment
Windows Hello for Business must have a public key infrastructure regardless of the deployment method used. All trust models depend on the domain controllers having a certificate.
The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller. There are currently two modes of deployment. They are as follows below:
- Certificate-based (certificate trust)
- Key-based (Key-trust).
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end-user certificates can continue to use PKI in combination with Windows Hello for Business.
Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust.
Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Azure AD as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.Additionally, I will show you in the next guides how this can be achieved regarding key trust. This is because the Domain Controller (DC) must use the “Kerberos Authentication” certificate or an equivalent certificate with the KDC Authentication EKU and the domain’s FQDN as a SAN.
Similarly, Windows Hello for Business requires all users to perform multi-factor authentication before creating and registering a Windows Hello for the Business credential. Nevertheless, On-premises deployments can also use certificates, third-party authentication providers for AD FS, or a custom authentication provider for AD FS as an on-premises MFA option.
Therefore, For information on available third-party authentication methods, see Configure Additional Authentication Methods for AD FS. For creating a custom authentication method, see Build a Custom Authentication Method for AD FS in Windows Server.
Note: The caveat with the keypair is that it doesn’t support supplied credentials for RDP. RDP doesn’t support authentication with a key or a self-signed certificate. RDP with Windows Hello for Business is supported with certificate-based deployments as a supplied credential. Active Directory Certificate Services (AD CS) should help here!
Windows Hello for Business supports these additional features
Conditional Access
AAD provides options for protecting access to corporate resources. Conditional access provides more fine-grained control over who can access certain resources and under what conditions. This requires AAD.
Dynamic Lock
Dynamic lock uses a paired Bluetooth device to determine user presence and locks the device if a user is absent.
PIN Reset
Nonetheless, This functionality enables users to recover their forgotten PIN. Using Group Policy, Microsoft Intune, or a compatible MDM.
Consequently, you can configure Windows 10 devices to securely use the Microsoft PIN reset service that enables users to reset their forgotten PIN through settings or above the lock screen without requiring re-enrollment.
Remote Desktop with Biometrics
Moreover, Users with Windows Hello for Business certificate trust can use their credentials to authenticate to remote desktop sessions over RDP. In addition, biometric gestures can be used if they are enrolled when authenticating to the session.
This functionality is not supported for key trust deployments. Microsoft continues to investigate supporting this feature for key trust deployments in a future release.
I hope you found this blog post on All you need to know before deploying Windows Hello for Business Key and Certificate Trust helpful. However, please let me know in the comment session if you have any questions.
