Windows Hello for Business: WHFB Hybrid Cloud Kerberos Trust Model

Windows Hello for Business (WHFB) is a modern two-factor authentication that replaces password authentication on devices. It uses key-based or certificate-based authentication and at least two unique factors “something the user knows (PIN) or something the user is (biometrics), combined with something they have (physical access to their device)”. WHFB offers secure, convenient single sign-on to the device and cloud services. With this being said, the WHFB key meets Azure AD multi-factor authentication (MFA) requirements and reduces the number of MFA prompts users will get when accessing resources.

Kindly refer to these related guides: The Local Administrators Account lockout is now available, Unable to install Azure AD Connect, TLS 1.2 is required: How to enable or disable TLS 1.2 on a Windows Server via the Registry and PowerShell, Repair or Uninstall Azure AD Connect: How to uninstall Azure AD Connect, and how to synchronize your on-premises AD with Azure Active Directory using the Azure AD Connect tool.

Authentication on Windows

Microsoft is committed to its vision of a world without passwords and they have acknowledged the satisfaction “the convenience PIN” has provided. Regardless, it still uses a password for authentication. Microsoft recommends that customers using Windows 10 and convenience PINs should move to Windows Hello for Business.

Microsoft will be deprecating convenience PINs in the future and will publish the date early to ensure customers have adequate lead time to deploy Windows Hello for Business.

In Windows and other operating systems, one method for authenticating a user’s identity is to use a secret passphrase or password. Microsoft recommends using secure multi-factor authentication such as Smart Card, FIDO, and Windows Hello for Business.

For the various deployment models, please see the following guide “WHFB Prerequisites: All you need to know before deploying Windows Hello for Business“, and how to enable Azure Single Sign-On: Sign-in issues, non-routable domain, invalid username, and password for SSO solved.

Why WHFB hybrid cloud Kerberos trust?

The WHFB Hybrid Cloud Kerberos Trust Model offers easier deployment compared to existing key and certificate trust models. It achieves this by eliminating the need to maintain complex public key infrastructure (PKI) and by reducing Azure Active Directory (Azure AD) Connect synchronization wait times.

Windows 11 devices comes with Windows Hello for Business. The easiest deployment is the WHFB hybrid cloud Kerberos trust model, which provides:

No PKI requirements
No Azure AD Connect synchronization dependency for writing back the public keys to Active Directory
No device write-back requirement (only applicable for certificate trust deployments)
No Active Directory Federation Services (AD FS) deployment requirement (only applicable for certificate trust deployments)

Hybrid Windows Hello for Business deployment needs an Azure Active Directory subscription. Different Azure subscriptions support different deployment configurations.

How does it work?

The WHFB Hybrid Cloud Kerberos trust uses Azure AD Kerberos to address the impediment of the key trust deployment model. Below is an architecture of this model.

Below are the steps describing how this Trust model works. This authentication consists of a new type of user credential. It is tied to a device and will utilize biometrics or PINs for authentication.

Windows Hello for Business lets the user authenticate to an Active Directory or Azure Active Directory account.

The users sign in to Windows with Windows Hello for Business by authenticating with Azure AD.
Azure AD checks for a Kerberos server key matching user’s on-premises AD domain. Then it generates a partial Kerberos ticket-granting ticket (TGT) for the on-premises domain. The partial TGT contains the user security identifier (SID) only and no authorization data, such as groups.
The client receives the partial TGT along with the Azure AD Primary Refresh Token (PRT).
The client contacts the on-premises AD domain controller and exchanges the partial TGT for a full TGT. We utilized this protocol flow earlier for Read Only Domain Controller scenarios.
The client has the Azure AD PRT and a full Active Directory TGT.

With the above-mentioned steps, you will be able to obtain a partial TGT from Azure AD, and subsequently, exchange that for a full TGT in Active Directory.

Because of this crucial piece, we no longer need to wait for Azure AD Connect to inform AD of the user’s public key. Users will authenticate directly with Azure AD with instant access to on-premises resources

I hope you found this blog post helpful. Please let me know in the comment session if you have any questions.