Note: The second 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.
Windows Hello for Business Deployment
We can deploy Windows Hello for Business in various ways (models). It mostly depends on what environment we operate. Whether it's cloud-only, On-Premises only or hybrid. That is, whether our computers are AD Domain Joined, Azure AD Joined or Hybrid Azure AD Joined. Other circumstances can also influence the decision, such as whether we use AD FS or another Identity Federation Service, whether we require the use of cert-based authentication, etc.
Within the Microsoft 365 admin center, there is a guide Plan your passwordless deployment (Setup - Advanced deployment guides & assistance), where we answer several questions about our environment and receive recommendations on which deployment model to use.
There are three possible deployment models and various trust models that determine how users authenticate against AD:
- Cloud-only deployment
- On Premises deployment
- Key Trust
- Certificate Trust
- Hybrid deployment
- Key Trust
- Certificate Trust
- Cloud Kerberos Trust
Windows Hello for Business certificate (Smart Card Logon)
When we install a certificate into the Windows Certificate Store, the public key is stored in the registry and the private key is stored using the selected CSP.
Microsoft supports a number of Cryptographic Service Providers (CSP), newer versions are called Key Storage Providers (KSP). These are modules that work with private keys, handle their storage and generation, and perform cryptographic functions. Applications do not work directly with the private key, but use the CSP.
Note: I haven't found much information on this area in the Microsoft Windows Hello documentation, so I'm deriving and estimating conclusions.
Windows Hello for Business uses a special Microsoft Passport Key Storage Provider and emulates a smart card to ensure application compatibility. When an application uses a certificate, the certificate API locates the keys using the stored KSP.
When a user registers Windows Hello, a Self-signed Smart Card Logon certificate is issued to the user's store (valid for 30 years). If we connect to the computer via RDP, we won't see it. If we delete the certificate, it will be restored upon the next login.
The generated Windows Hello for Business public key is used in the certificate. The certificate has a private key managed by the Microsoft Passport KSP and stored in the TPM (we're not considering the SW option). Access is therefore protected by the Windows Hello for Business gesture.
The certificate has a subject in the format
User-SID/GUID/login.windows.net/Tenant-ID/User-Principal-Name
We can see the certificate using certmgr.msc
. Using the certutil
command, we can list all keys of the given CSP (the -v
switch displays more details).
certutil -csp "Microsoft Passport Key Storage Provider" -key -v
Below is a sample output (some values are deleted). We can learn several important pieces of information here. For example, if the key is stored in TPM, then in the NgcKeyImplType
section, the flag NCRYPT_IMPL_HARDWARE_FLAG
is active (not in parentheses).
Microsoft Passport Key Storage Provider: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz RSA Key Id Hash(rfc-sha1): Key Id Hash(sha1): Key Id Hash(bcrypt-sha1): Key Id Hash(bcrypt-sha256): Container Public Key: ... Cached Key Identifier: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/./bouska@firma.cz: No container name match Cached Key Identifier: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/./bouska@firma.cz: No KeyId match NCRYPT_ALLOW_DECRYPT_FLAG -- 1 NCRYPT_ALLOW_SIGNING_FLAG -- 2 (NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4) (NCRYPT_ALLOW_KEY_IMPORT_FLAG -- 8) (NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215)) UI Policy = 0 (NCRYPT_UI_PROTECT_KEY_FLAG -- 1) (NCRYPT_UI_FORCE_HIGH_PROTECTION_FLAG -- 2) Version: 0 Export Policy = 0 (NCRYPT_ALLOW_EXPORT_FLAG -- 1) (NCRYPT_ALLOW_PLAINTEXT_EXPORT_FLAG -- 2) (NCRYPT_ALLOW_ARCHIVING_FLAG -- 4) (NCRYPT_ALLOW_PLAINTEXT_ARCHIVING_FLAG -- 8) Name: S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz Algorithm Group: RSA Algorithm Name: RSA Length: 2048 (0x800) Lengths: dwMinLength = 2048 (0x800) dwMaxLength = 2048 (0x800) dwIncrement = 0 (0x0) dwDefaultLength = 2048 (0x800) UI Policy: dwVersion = 1 (0x1) dwFlags = 0 (0x0) pszCreationTitle = (null) pszFriendlyName = (null) pszDescription = (null) Export Policy: 0 (0x0) (NCRYPT_ALLOW_EXPORT_FLAG -- 1) (NCRYPT_ALLOW_PLAINTEXT_EXPORT_FLAG -- 2) (NCRYPT_ALLOW_ARCHIVING_FLAG -- 4) (NCRYPT_ALLOW_PLAINTEXT_ARCHIVING_FLAG -- 8) NgcKeyImplType: 1 (0x1) NCRYPT_IMPL_HARDWARE_FLAG -- 1 (NCRYPT_IMPL_SOFTWARE_FLAG -- 2) (NCRYPT_IMPL_REMOVABLE_FLAG -- 8) (NCRYPT_IMPL_HARDWARE_RNG_FLAG -- 10 (16)) Key Usage: 3 (0x3) NCRYPT_ALLOW_DECRYPT_FLAG -- 1 NCRYPT_ALLOW_SIGNING_FLAG -- 2 (NCRYPT_ALLOW_KEY_AGREEMENT_FLAG -- 4) (NCRYPT_ALLOW_KEY_IMPORT_FLAG -- 8) (NCRYPT_ALLOW_ALL_USAGES -- ffffff (16777215)) Serial Number: Issuer: CN=S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz NotBefore: 02.06.2023 13:15 NotAfter: 02.06.2053 13:25 Subject: CN=S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz Signature matches Public Key Root Certificate: Subject matches Issuer Cert Hash(sha1): Private key is NOT exportable
Cancelling (deleting) Windows Hello registration
Many articles on the internet state that we can use the command line tool certutil if we want to delete Windows Hello for Business registrations on a device.
certutil.exe -DeleteHelloContainer
This deletes the Windows Hello container and removes associated locally stored information (credentials), such as PIN or fingerprints (it should also include WebAuthn and FIDO credentials). The certificate mentioned above (and possibly others stored in the container) will also be deleted. When we look at the settings after executing the command, we'll see that no method is set. Data stored in Azure AD will remain (we can delete them from the user's account in Azure AD).
C:\>certutil -DeleteHelloContainer Deleted certificate CN=S-1-5-21-2200562112-.../bd6913e1-6375-.../login.windows.net/bb9528c8-3d14-.../bouska@firma.cz
Sign out now to complete this task.
CertUtil: -DeleteHelloContainer command completed successfully.
Checking registration in Azure AD
When a user correctly registers Windows Hello for Business, a new authentication method is added to their account in Azure AD. In the user details in Azure Active Directory admin center - Users under Authentication methods, we'll see the Windows Hello for Business authentication method.
Note: We can delete the Windows Hello for Business method here and thus disable it for login.
We can view a summary of registered authentication methods for users, where we can filter for Windows Hello for Business. We can access the same information through two paths:
- Azure Active Directory admin center - Security - Authentication methods - User registration details
- Azure Active Directory admin center - Usage & insights - Authentication methods activity - User registration details
Data in the client's registry
Windows Hello for Business uses the first three Credential Providers, which are identified by the following GUIDs:
- PIN -
{D6886603-9D2F-4EB2-B667-1971041FA96B}
- Fingerprint -
{BEC09223-B018-416D-A0AC-523971B639F5}
- Facial Recognition -
{8AF662BF-65A0-4D0A-A540-A338A999D36F}
- Password -
{60B78E88-EAD8-445C-9CFD-0B87F74EA6CD}
- FIDO -
{F8A1793B-7873-4046-B2A7-1F318747F427}
- Smartcard -
{8FD7E19C-3BF7-489B-A72C-846AB3678C96}
We can check if a user has registered Windows Hello for Business on the computer in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\Credential Providers\{D6886603-9D2F-4EB2-B667-1971041FA96B}
. Under the PIN provider, there are SIDs of individual users. The value LogonCredsAvailable
must be 1.
We can find out how the user is currently logged in (more precisely, what was the last interactive login) in the registry HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Authentication\LogonUI\LastLoggedOnProvider
. The value indicates the GUID of the provider.
Cloud Kerberos Trust
For hybrid environments, the newest option Cloud Kerberos Trust is recommended. The deployment is very simple. Older models Key Trust and Certificate Trust have many complex requirements and the entire deployment is much more complicated.
To use Cloud Kerberos Trust, we must meet several prerequisites (Requirements):
- The OS on workstations must be at least Windows 10 21h2 with KB5010415 installed (we shouldn't have an older version these days, and even this one is nearing end of support) or Windows 11 21h2 with KB5010414 installed
- Domain controllers must be at least Windows Server 2016 with KB3534307 installed, Windows Server 2019 with KB4534321
- Multi-factor Authentication is required for user account verification when registering Windows Hello for Business (all methods)
- Accounts synchronized using Azure AD Connect
By default, we can't use Windows Hello for Business to log in with a privileged account. These are accounts that are in groups like Domain Admins, Account Operators, Server Operators, Print Operators, etc.
Deploying Windows Hello for Business with Cloud Kerberos Trust is very simple. As an administrator, we need to perform two steps. The user then performs the registration.
- Create/deploy Azure AD Kerberos
- Enable/configure Windows Hello for Business on selected devices
- The user performs Windows Hello for Business registration (Provisioning) (we'll address this in the next part)
Azure AD Kerberos
Windows Hello for Business cloud Kerberos trust uses Azure AD Kerberos, which simplifies deployment compared to the Key Trust model. It doesn't need PKI nor does it perform public key synchronization from Azure AD to AD (there's no delay after Windows Hello registration). It doesn't increase the load on domain controllers during KDC authentication. Azure AD Kerberos is also used for security key authentication (FIDO2).
When Azure AD Kerberos is enabled in an AD domain, a computer object AzureADKerberos is created as a Read Only Domain Controller (not associated with any server). It's used by Azure AD to generate TGT (Ticket-Granting-Ticket) for the AD domain.
When a user authenticates using Windows Hello for Business, they can request a TGT from Azure AD (they receive it along with the Primary Refresh Token - PRT). They get a partial TGT, which they use to log in or access resources in AD. The KDC (domain controller) exchanges it for a (full) TGT. Domain controllers are still responsible for standard issuance of service tickets and authorization.
Deploying Azure AD Kerberos
We install the Azure AD Kerberos PowerShell Module
Install-Module -Name AzureADHybridAuthenticationManagement -AllowClobber
We create Azure AD Kerberos Server objects in AD and publish them to Azure AD. There are various authentication options for AD and Azure AD. Here's a variant where we run PowerShell under an account with domain administrator rights. Global administrator authentication is done using modern authentication (we enter their UPN).
Set-AzureADKerberosServer -Domain firma.local -UserPrincipalName bouska@firma.cz
We can display information about the created Azure AD Kerberos Server. We see that not only a computer account was created, but also a user account krbtgt_AzureAD
. This holds the TGT encryption key, similar to the krbtgt
account. A Service Connection Point (SCP) CN=900274c4-b7d2-43c8-90ee-00a9f650e335,CN=AzureAD,CN=System,<domain-DN>
was also created. In Azure AD, a KerberosDomain object is created.
PS C:\> Get-AzureADKerberosServer -Domain firma.local -UserPrincipalName bouska@firma.cz Id : 25205 UserAccount : CN=krbtgt_AzureAD,CN=Users,DC=firma,DC=local ComputerAccount : CN=AzureADKerberos,OU=Domain Controllers,DC=firma,DC=local DisplayName : krbtgt_25205 DomainDnsName : firma.local KeyVersion : 41992547 KeyUpdatedOn : 11.05.2023 12:42:56 KeyUpdatedFrom : dc1.firma.local CloudDisplayName : krbtgt_25205 CloudDomainDnsName : firma.local CloudId : 25205 CloudKeyVersion : 41992547 CloudKeyUpdatedOn : 11.05.2023 12:42:56 CloudTrustDisplay :
From a security perspective, it is recommended to regularly change (rotate) the KRBTGT encryption keys for the Azure AD Kerberos Server. We can do this using the cmdlet.
Set-AzureADKerberosServer -Domain firma.local -UserPrincipalName bouska@firma.cz -RotateServerKey
Configuring device settings using Group Policy
To allow users to register and use Windows Hello for Business, we can use Group Policy. Based on the Windows settings, it determines whether the user should attempt to register credentials. We can set the enablement of Windows Hello for Business for computers or users. However, Cloud Kerberos Trust requires settings that are only available as computer configuration.
To set the corresponding policies, we must have sufficiently new ADMX templates for Windows 10/11 (currently the latest for Windows 10 is version 22H2). Links to download different versions can be found in How to create and manage the Central Store for Group Policy Administrative Templates in Windows. Optimally, we upload them to the Central Store.
Enabling Windows Hello for Business
Windows Hello for Business configuration in Group Policy is located in the path
Computer Configuration/Policies/Administrative Templates/Windows Components/Windows Hello for Business
There are several settings here, three are important for our situation:
- Use Windows Hello for Business - we enable the use of Windows Hello
- Use cloud trust for on-premises authentication - we enable the use of Azure AD Kerberos
- Use a hardware security device - requires the use of TPM 1.2 or 2.0 (we can set only TPM 2.0)
- Use certificate for on-premises authentication - must not be set, using certificates would take precedence
Non-enforced enabling of Windows Hello for Business
In the Use Windows Hello for Business settings, we can check Do not start Windows Hello provisioning after sign-in
. With this setting, users are not prompted to configure Windows Hello after signing in (registration is not enforced). They can perform the registration themselves later in Settings - Accounts - Sign-in options. Until they perform the configuration, Windows Hello will not be available.
PIN Complexity
If we want to set PIN requirements, the configuration is located in Group Policy in the path
Computer Configuration/Policies/Administrative Templates/System/PIN Complexity
Note: Once, there was also a setting Use Phone Sign-in in Group Policy, which was supposed to allow using Authenticator. But Microsoft apparently cancelled it and the current documentation notes it as Not currently supported.
Blocking password login
We can also block password login when we require the use of Windows Hello for Business or a certificate from a smart card (or FIDO2). This is a Group Policy setting Interactive logon: Require Windows Hello for Business or smart card
in the path
Computer Configuration/Policies/Windows Settings/Security Settings/Local Policies/Security Options
Configuring device settings using Intune
- Configure Windows Hello for Business policy - Intune
- Manage Windows Hello for Business on devices at the time devices enroll with Intune
- Use identity protection profiles to manage Windows Hello for Business in Microsoft Intune
We can enable and configure Windows Hello for Business using Intune in two ways:
- Tenant-wide policy - we can create settings for the entire Tenant, which are applied only when a device registers with Intune (policy changes do not affect already registered devices)
- Configuration profile - we create a configuration profile that we assign to a group of devices, changes take effect on assigned devices
Tenant-wide configuration is done in Microsoft Endpoint Manager admin center - Devices - Enroll devices - Windows enrollment - Windows Hello for Business.
Setting up using a configuration profile
Usually, we need to create a configuration profile (the documentation also mentions other options, besides those listed below, such as Endpoint security Account protection policy).
- Microsoft Endpoint Manager admin center - Devices - Configuration profiles
We can use the Identity protection template, where we enable Windows Hello for Business and set various parameters (including PIN requirements). But we can't set Cloud Kerberos Trust here.
Therefore, we must create another profile from the Custom template. Where we manually set the OMA-URI ./Device/Vendor/MSFT/PassportForWork/<tenant ID>/Policies/UseCloudTrustForOnPremAuth
, type Boolean
with value True
.
Or there's a second option to create a Settings catalog profile, where we find the Windows Hello For Business category. The configuration is less clear than using a template, but there are more settings (including PIN requirements). Some configurations are separate for devices and for users. We have the main options here:
- Use Passport for Work - enabling Windows Hello for Business (the item uses the old Passport name)
- Use Cloud Trust For On Prem Auth - enabling Azure AD Kerberos
- Require Security Device - requiring TPM
I couldn't find the option in Intune that exists in Group Policy, Do not start Windows Hello provisioning after sign-in. Probably the only solution is to create a configuration using registry keys HKLM\SOFTWARE\Policies\Microsoft\PassportForWork\DisablePostLogonProvisioning
.
We assign the profile to a device group. This is necessary for using Cloud Kerberos Trust. Also, when assigned to users, only one user can register on the device with Windows Hello.
Extended Windows Hello features
Dynamic Lock
Dynamic Lock allows pairing a mobile phone (or other device) with a computer using Bluetooth. When the phone's signal is too weak and the computer is not in use, it automatically locks.
- the setting is located in Windows under Settings - Accounts - Sign-in options
- using Group Policy under Windows Hello for Business - Configure dynamic lock factors
Multi-Factor Unlock
Multi-Factor Unlock allows setting up a requirement for two methods to unlock Windows. We can set a combination of fingerprint, face scan, PIN, and Trusted Signal (only as a second factor, phone proximity or trusted network location).
- Group Policy setting under Windows Hello for Business - Configure dynamic unlock factors
Dual Enrollment
Allows using two accounts on a computer, one privileged and the other standard, under which we usually work. Within the non-privileged account, we can use Remote Desktop Connection or run an application as Run as different userand use Windows Hello for Business login with the privileged account.
Smart Card Logon certificates are used for this, which we must have properly deployed. We must also allow access to certificates of all users within the computer (Group Policy under Windows Hello for Business - Allow enumeration of emulated smart cards for all users).
PIN Reset
In Windows settings, we can change our Windows Hello PIN. If we forget it, we can perform a reset, where we log in and verify using MFA and set a new PIN.
There are two ways to reset the PIN:
- destructive PIN reset - deletes the original PIN, keys, certificates, etc. in the Windows Hello container and creates new ones, works automatically without configuration, Hybrid Azure AD Joined devices must have an available domain controller
- non-destructive PIN reset - requires Microsoft PIN reset service (an Enterprise application that is activated in Azure AD), a PIN reset protector (256-bit AES key) is added to the Windows Hello container on the device, during reset it's used to change the PIN, so the keys remain preserved, we must enable it using Group Policy
Use PIN recovery
or IntuneEnablePinRecovery
Remote Desktop - connecting to a remote desktop
We use Windows Hello for Business for interactive (local) login to the computer. When we log in to the computer remotely (Remote Desktop), we must use a different authentication method (password).
If we are logged in to the computer using Windows Hello for Business, we can connect remotely to another computer using Remote Desktop Connection from this computer. The RDP protocol doesn't support Windows Hello for Business, but it's possible to use a certificate that is protected by Windows Hello for Business (stored in the Windows Hello Container). The RDP feature of smart card redirection is used. Or deploy Windows Defender Remote Credential Guard.
Windows Hello for Business certificate
After registering Windows Hello for Business, the user has a Smart Card Logon certificate with Windows Hello keys on the computer. During remote connection, authentication with this certificate with a set gesture is automatically offered. Login with this Self-signed certificate doesn't work, it doesn't contain the correct UPN and isn't trusted.
Windows Hello for Business emulates a smart card. Older versions of Windows 10 redirect access to the private key (emulated smart card) using Microsoft Smart Card KSP, so it's possible to use a PIN. From Windows 10 version 1809, redirection doesn't occur, but Microsoft Passport KSP is used, which supports the use of biometrics. For compatibility, we can enable the original functionality using Group Policy Use Windows Hello for Business certificates as smart card certificates
.
Issuing Smartcard Logon certificate
If we want to use Windows Hello for Business for RDP (for example with Cloud Kerberos Trust) and we have an internal CA (PKI set up), we can create a special Smartcard Logon certification template and issue certificates to users. The description is in the article Deploy certificates for remote desktop (RDP) sign-in. The main thing is to change the CSP to Microsoft Passport KSP, which must be done by exporting the template and text editing.
Login with the issued Smart Card Logon certificate works, but only PIN use is offered to me (I couldn't get biometrics to work).
There are no comments yet.