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.
Microsoft is committed to its vision of a world without passwords and they have acknowledged the satisfaction “the convenience PIN” has provided. That being said, 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. Here is a list of FAQs.
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 model, 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 hybrid cloud Kerberos trust?
WHFB Hybrid Cloud Kerberos Trust Model as it is much easier to deploy than the existing key trust and certificate trust deployment models by removing the need for maintaining complicated public key infrastructure (PKI) and Azure Active Directory (Azure AD) Connect synchronization wait times.
Windows Hello for Business is available by default on Windows 11 devices and hybrid cloud Kerberos trust deployment is the simplest deployment model, as it offers:
- 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 deployment configurations are supported by different Azure subscriptions.
How does Hybrid Cloud Kerberos Trust Model work?
The 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 that is tied to a device and uses a biometric or PIN. 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 and 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 partial TGT is returned to the client along with Azure AD Primary Refresh Token (PRT).
- The client contacts the on-premises AD domain controller and exchanges the partial TGT for a full TGT. This is the same protocol flow used today 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.