WINDOWS hELLO FOR BUSINESS
WHFB
Windows Hello for Business provides an authentication mechanism using biometrics and/or alphanumeric PIN. It is also possible to use "trusted signal" as a factor for unlocking a device (more on that later).
We support government customers where smart card login is the primary method via which users are authenticated to Active Directory. This is to comply with HSPD 12.
In these organizations, users are sometimes temporarily (or permanently) excluded from smart card enforcement. A user may lose their PIV/CAC, not yet received one, or be a temporary or detailed employee. In the case of a user detailed to multiple agencies, some organizations may prohibit the issuance of two smart card credentials (certificates). It is necessary to still meet MFA requirements in this scenario if a password is issued.
Windows Hello and "smart card required for interactive logon"
There are two ways smart card login can be enforced: on the user object itself and via Windows Group Policy.
User level enforcement is configured on the account tab of the user object. Group Policy is applied to the computer object. When applied to a computer any user who logs into that machine will be required to use a smart card and PIN. Astute observers will notice that the setting for this configuration was changed at some point from "Interactive Logon: Require Smart Card" to "Require Windows Hello for Business or Smart Card". Even though the functionality did not change, this change was made to clarify the settings for admins, as it was not obvious that Windows Hello could be used to meet the requirement. Because WHfB satisfies smart card logon, it is not necessary to change Group Policy or user account configuration if a user needs to fall back to Windows Hello for authentication.
Models for deployment
- Cloud-only - for pure Entra ID environments with no Active Directory (AD)
- Key trust - a private key is used to sign authentication requests to AD and is initiated via Kerberos PKINIT
- Kerberos cloud trust - a Ticket Granting Ticket is generated via cloud services and is used to issue tickets for on-prem AD
- Certificate trust - certificates are used to authenticate to AD. This method requires Active Directory Federation Services (AD FS)
More information is publicly available about WHfB here: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/
Real world deployment
Moving on from general information about WHfB we now turn to real-world deployment and limitations of the various models and challenges admins will face.
The deployment model that requires the least effort is Cloud Kerberos trust. However, this model blurs the security boundary between the cloud (Entra ID) and on-prem. It can be exploited to move laterally from the cloud to on-prem using compromised Entra ID Global Admin accounts. More information on specifics and mitigation can be found in a talk published on YouTube: I Trusted You A Demonstrated Abuse of Cloud Kerberos Trust
For customers who using Active Directory and are not willing to accept the risk of the Cloud Kerberos model must choose between Key Trust and Certificate Trust models.
For organizations that do not already have AD FS deployed, or are looking to deprecate it, the Certificate Trust model poses too much of an operational burden.
The Key Trust model is a viable alternative. However, this method will make the use of self-signed certificates which is prohibited at many organizations.