Windows Hello for Business - introduction

Note: The first part of a mini-series focusing on Windows Hello for Business with Cloud Kerberos Trust deployment in a hybrid environment with Hybrid Azure AD Joined devices.

Updated on March 24, 2024 - When I was researching this area, I didn't come across an important piece of information (which is still hard to find at Microsoft). Windows Hello has been a certified FIDO2 authenticator (platform / internal) since Windows 10 1903, Microsoft Achieves FIDO2 Certification for Windows Hello. So it works, and we can use it, just like a FIDO Security Key. I've written more information about FIDO authentication in a new article FIDO passkeys part 1 - passkeys for authentication.

What is Windows Hello for Business

• Windows Hello for Business
• Learn about Windows Hello and set it up

Windows Hello for Business is one of Microsoft's supported user authentication methods. It falls under Passwordless authentication options for Azure Active Directory. A general description of authentication options is provided in the article What authentication and verification methods are available in Azure Active Directory?.

Microsoft describes Windows Hello for Business (WHfB) as a password replacement with strong two-factor authentication on devices. Authentication consists of user credentials (asymmetric key pair) that are bound to the device and protected (optionally) by biometric data and a PIN, collectively referred to as a gesture. It can be used when logging in interactively (locally) directly to a computer (not remotely). If we use biometrics (fingerprint, facial recognition), the login is more convenient and secure than using a password.

By default, authentication using Windows Hello for Business is added as an additional login option to the device. Similar to how we can use certificate login (Smart Card Logon). We can use policies to disable some forms of login and enforce the use of Windows Hello.

It is used for centrally managed user accounts. The term Identity Provider (IdP) is often used in this context. This is an identity provider, i.e., a server/service where we create and manage accounts and where the user is authenticated. The main examples are Active Directory or Azure Active Directory, or Microsoft Account and others.

Windows Hello vs. Windows Hello for Business

Windows Hello is designed for home users. PIN or biometrics are used for convenient login, and we use them to obtain a password stored in the local vault. So the login is standard with a username and password, but the user doesn't enter the password. Microsoft states that Windows Hello is disabled by default for computers joined to a domain or Azure AD (unless we use the Group Policy Turn on convenience PIN sign-in).

In contrast, Windows Hello for Business is designed for businesses and works much more securely. It uses asymmetric cryptography (and certificates), where the private key is secured (by default) using a Trusted Platform Module (TPM). When logging in over the network, the password (or its hash) is not sent, but keys are used instead. It works with accounts that are not local but are managed on a server (Identity Provider), typically AD or Azure AD.

Note: In this series of articles, we focus only on Windows Hello for Business. If the name Windows Hello is used, it usually refers to Windows Hello for Business.

Basic conditions of use

Windows Hello for Business is supported by Windows 10/11 Pro and Enterprise editions. Within Azure AD, a Windows Enterprise E3/E5 license is required.

Windows Hello for Business creates login credentials uniquely linked to a specific device. We can use it to log in to

• Microsoft account
• Active Directory account
• Azure Active Directory account
• Identity Provider Services (IDP) that support FIDO2 (Fast ID Online 2.0) authentication

Principles of Windows Hello for Business

• added as an additional login option to the device
• also works for cached sign-in when a domain controller is not available
• (depending on deployment) logs in to both Azure AD and local AD
• Windows Hello credentials are based on an asymmetric key pair used to log in to Azure AD, for AD a key, certificate or Kerberos ticket is used
• credentials are bound to the device, as is the token obtained with them
• keys are generated in HW (TPM 2.0 or 1.2) or SW (not recommended, we won't consider further)
• during registration, the user's identity is verified using MFA, the public key is mapped to the user account
• the private key is held by the TPM and never leaves the device, the authentication server only has the public key
• the user sets a PIN and optionally also biometrics (face recognition or fingerprint comparison, or iris recognition), which protect access to the keys
• we must set the PIN mandatorily (even if we want to use biometric login), it is used for login if problems occur (reader not working, we are injured)
• during authentication using Windows Hello, two-factor verification is performed using a key bound to the device and a PIN or biometrics
• biometric data and PIN are not sent over the network and are not shared, they are used (stored) only locally on the device
• using the PIN or biometric gesture, we gain access to use the private key, which signs data sent to the authentication server (Identity Provider), which verifies and logs in the user
• for Windows Hello Fingerprint we need a fingerprint reader
• for Windows Hello Face a special (compatible) infrared (IR) camera

A detailed authentication process is described in Hybrid Azure AD join authentication using Azure AD Kerberos (cloud Kerberos trust).

Windows Hello for Business and Azure AD MFA

When we log in to Windows using Windows Hello for Business, and we have an available internet connection (communication to Azure AD), verification in Azure AD takes place (the user obtains PRT). This verification is considered MFA (Multi-Factor Authentication). If we subsequently log in to an application where Azure AD MFA is required, we are normally logged in automatically because Single Sign-On (SSO) occurs.

In the Azure Active Directory admin center, we can look at the user's sign-in logs. Here we find Windows Sign In and the Authentication method is Windows Hello for Business.

More detailed functioning of Windows Hello for Business

Use of keys or certificates - Key Trust and Certificate Trust

Windows Hello for Business replaces user login credentials (username and password) with other Credentials (asymmetric key pair). We can use Key-based authentication, i.e., keys stored in hardware or software. Or Certificate-based authentication, i.e., certificates stored in hardware or software.

Authentication against Azure AD always takes place using keys and the user obtains PRT (with MFA claim). Depending on the environment, we have different deployment models and associated trust types that determine how users authenticate against local AD. The basic ones are Key Trust and Certificate Trust. Authentication against AD works the same as Smart Card authentication. Kerberos and certificates are used.

In both cases, a pair of public and private keys is created. In the case of Key Trust, the user receives a Self-signed certificate with their public key. During Kerberos authentication at the domain controller (DC), the client sends the certificate, but the DC verifies the public key with the record in the user account. In the case of Certificate Trust, the Self-signed certificate is replaced by a certificate from the company PKI. And standard certificate authentication takes place

Using certificates requires Public Key Infrastructure (PKI) for issuing and managing certificates, as well as AD FS. Using keys is simpler. But a certification authority (with available CRL) and a certificate on the domain controller, which is the Root of Trust, are still needed. After registering (provisioning) Windows Hello on the client, public key synchronization from Azure AD to AD needs to occur. Only then will login to resources in the AD domain (SSO for On-Premises) start working, in practice this means a delay of up to 30 minutes.

More information about Windows Hello certificates and stored keys is in the next part.

Cloud Kerberos Trust

Since the beginning of 2022 (at least Windows 10 21h2), for hybrid deployment it is possible and recommended to use Cloud Kerberos Trust, where Azure AD is the root of trust. This method doesn't require any certificates or additional synchronization. It also works with an asymmetric key pair. For On-Premises authentication, a Kerberos ticket (partial TGT) issued by Azure AD is used.

Remote Desktop Protocol (RDP)

RDP doesn't support authentication with Windows Hello for Business deployed with Key Trust or Cloud Kerberos Trust, only with Certificate Trust deployment. Because it supports Certificate Authentication, where we need a trusted certificate.

This means that when connecting to RDP from a computer where we're logged in using Windows Hello for Business, we must log in with a username and password (we can't use Windows Hello login). Or we can use Windows Hello for Business along with Windows Defender Remote Credential Guard.

But Windows Hello for Business also supports adding additional Credentials, which can be a Smart Card Logon certificate from the company CA (from a special template). The certificate's private key is then protected by Windows Hello, which we use when logging in via RDP.

Windows Hello for Business Provisioning

• Windows Hello for Business Provisioning

Registering (new setup) Windows Hello for Business consists of three basic steps:

• authentication and MFA - we must securely authenticate the user
• key generation on the client - if a biometric sensor is available, biometrics can be registered, then creating a PIN is mandatory, TPM generates a key pair
• key registration in Azure AD and/or AD - the public key is registered in Azure AD, where it's written to the user object along with information about the device where it was issued

For Key Trust or Certificate Trust, an additional special step is always added. But for Cloud Kerberos Trust, this is all.

Windows Hello for Business Container

• What's a container?

A Windows Hello Container is a logical grouping of keys or data. Microsoft states that it doesn't physically exist (on disk, in registries, or similar). Windows Hello for Business uses one container that stores user keys for personal accounts, including keys associated with the user's Microsoft account or Azure AD account (workplace or school account). Keys are separated by IDP domain. So it stores enterprise credentials for devices connected to on-premises AD or Azure AD.

Each user account on the computer has its own Windows Hello Container. It combines all set login credentials, keys, and certificates. Deleting it cancels the Windows Hello for Business setup.

The container contains sets of keys. When a gesture (PIN or biometrics) is registered for Windows Hello, a pair of public and private keys is generated. TPM generates and protects the private key. It's referred to as the Protector key, each registered gesture has a unique protector key. The container has one Authentication key, which is encrypted using the Protector key. If we have multiple gestures registered, multiple copies of the authentication key are created encrypted with different protector keys.

The Authentication key encrypts individual keys (Identity Provider Key) stored in the container. The device generates a public and private key during registration. It registers the public key in Azure AD and securely stores the private key. We can store a Smart Card Logon certificate in the container. Windows Hello for Business uses smart card emulation and caches the PIN similar to chip cards.

Password versus PIN from a security perspective

This chapter primarily contains arguments given by Microsoft on why a PIN is more secure than a password. But other manufacturers and experts agree on the same principles.

Generally, there's a trend today to get rid of passwords and move to passwordless authentication. Remembering complex passwords is challenging for users, and using passwords has a number of security risks. It's being replaced by using some HW device (phone with MS Authenticator app, FIDO2 security key) and biometrics (fingerprint). Authentication mechanisms use keys and tokens (not passwords).

Dangerous passwords

Traditional passwords have several disadvantages. A secure password must be long and complex, making it difficult to remember and use. We can use our online account to log in to many different services over the internet. Passwords are transmitted over the network during authentication (usually their hash) and are stored on the server (again, usually the hash). An attacker can intercept communication or attack the server. Under certain conditions, an attacker can use a brute force attack.

Safer PIN

One might imagine a PIN as a short numeric code. But nowadays, a PIN can look the same as a password, containing digits, letters, and special characters. Often, a PIN is used shorter than a password because limitations on its use ensure sufficient security. In Windows Hello for Business, we can set requirements for the PIN in terms of length and complexity.

Importantly, the Windows Hello PIN is tied to the device. If an attacker were to obtain it, they would also need to obtain the specific computer. They can't use the PIN to log in to online services under the user's account. The PIN is local to that computer, isn't transmitted over the network, and isn't used for server authentication. The PIN is protected by the TPM, which is designed for secure cryptographic operations. A brute force attack on the PIN will result in the device being locked. Therefore, this PIN is also more secure than a local password.

Microsoft refers to Windows Hello for Business as passwordless authentication. However, we must set a PIN, which is the same as a password. As I mentioned earlier, this doesn't seem like moving away from passwords to me. But if we set up, for example, a fingerprint, we can function without passwords (the PIN is only for potential problems). It's similar to Microsoft Authenticator and Phone Sign-in, which we have on our phone protected by a PIN and usually a fingerprint.

We must, of course, protect the PIN. Primarily, we use biometrics, which no one can spy on. When we need to use the PIN, we don't enter it in front of another person, under camera surveillance, etc. If we have multiple devices, each should have a different PIN (which is, of course, challenging for users). A quite fundamental requirement is that we must not set the PIN the same as the password.