Windows Hello for Business on Azure AD-joined devices is capable of providing single sign-on access to Active Directory domain-joined services and servers in Hybrid Identity setups.
Microsoft provides guides to configure this access in several ways: Certificate Trust, Key Trust and Hybrid Cloud Trust. Each of the three Windows Hello for Business Hybrid Access trust models have their own pros and cons and their own manual and their own artifacts. They also have things in common. Knowing these aspects of the Hybrid Access trust models helps you troubleshoot each of them.
In this blogpost, I'll share my sequence for troubleshooting Windows Hello for Business Hybrid Access:
- Check if the user object in Azure AD is assigned an Azure AD Premium license
- Check if the user object in Azure AD has permissions to configure Windows Hello for Business methods
- Check if the right multi-factor authentication method is configured for the user object in Azure AD
- Check if the device is correctly configured for Windows Hello for Business
- Check if the user profile is correctly configured for Windows Hello for Business
- Check the Event log
- Check the Cloud Trust's Read-only Domain Controller
- Check if the Domain Controllers are configured with the right certificate
- Check if the device is configured with the root CA's certificate
- Check if the user object is enrolled for the right certificate
Check if the user object in Azure AD is assigned an Azure AD Premium license
One of the big requirements for Windows Hello for Business Hybrid Access is Azure AD Premium licensing. While multi-factor authentication is available as part of Azure AD Free through the Security Defaults functionality, Windows Hello for Business requires Azure AD Premium licensing. Every person in the organization that you want to have access to Windows Hello for Business from Azure AD-joined devices to on-premises resources should have the Azure AD Premium P1 license assigned. As the P1 license is included in the Azure AD Premium P2, the Microsoft EMS E3/E5 and the Microsoft 365 E3/E5 licensing, assigning Azure AD Premium P1 as part of these licensing suites also works.
To check if the user object in Azure AD is assigned an Azure AD Premium license, perform the following steps:
- Navigate a browser to the Entra portal.
- Sign in with an account that has either the Global Administrator, License Administrator, Directory Writers, Groups Administrator or User Administrator, or Partner Tier1 Support role assigned or is eligible to activate the role.
Perform multi-factor authentication when prompted. - If the organization uses Azure AD Privileged Identity Management (PIM), activate the role from the list of roles in step 2 with the least administrative privilege.
- In the Entra portal, in the left-hand navigation menu, click Show more….
- In the menu, expand Billing.
- Underneath the Billing node, click Licenses.
The Licenses | Overview pane opens. - In the licenses sub menu, click All products.
The Licenses | All products pane opens. - From the list of license products, click the Azure AD Premium P1 license plan, or click the license suite that includes this license.
The Licensed users pane for the license opens. - At the top of the list, use the Search box to search for the user object(s) you are troubleshooting Windows Hello for Business Hybrid Access for.
- Make sure the user object for the person is activated for the feature. For license suites, click through on the Enabled Services to make sure the Azure Active Directory Premium P1 license is assigned. If not, assign it either through a (dynamic) group or assign it to the user object(s) individually.
If you change a user object(s) license(s) or license feature(s), allow for some time to have Azure AD replicate the change throughout the Azure AD infrastructure.
Check if the user object in Azure AD has permissions to configure a Windows Hello for Business method
Even if the user object in Azure AD has the right license and the right authentication method, you may have settings that contradict the use of that method as a passwordless method. This applies specifically for the Microsoft Authenticator app and FIDO2 security keys. To check if the Authenticator app can be used for Passwordless sign-ins, perform the following steps:
- Navigate a browser to the Entra portal.
- Sign in with an account that has either the Global Administrator, Authentication Administrator or Privileged Authentication Administrator (when troubleshooting user objects with roles assigned) role assigned or is eligible to activate the role.
Perform multi-factor authentication when prompted. - If the organization uses Azure AD Privileged Identity Management (PIM), activate the role from the list of roles in step 2 with the least administrative privilege.
- In the Entra portal, in the eft-hand navigation menu, click Show more….
- In the menu, expand Protect & secure.
- Underneath the Protect & secure node, select Authentication Methods.
The Authentication methods | Policies pane opens. - From the list of methods, click Microsoft Authenticator.
The Microsoft Authenticator settings pane opens on the Enable and Target tab. - For the All users group (if included) or any group that is included as a target (and includes the user account for the person you are troubleshooting Windows Hello for Business for) for the Microsoft Authenticator method, make sure that the Authentication mode column displays Any or Passwordless, specifically. If there is no group included that contains the user object, add a group, or include the All users group alternatively.
- At the bottom of the Microsoft Authenticator settings page, click Save.
- From the navigation breadcrumbs, click Authentication methods | Policies.
- From the list of methods, click FIDO2 security key.
The FIDO2 security key settings pane opens on the Enable and Target tab. - Make sure that the Enable option is enabled.
- Make sure that a group that includes the user account for the person you are troubleshooting Windows Hello for Business for, or the All users group is selected to enable FIDO2 security keys as Windows Hello for Business (WHfB) method.
- At the bottom of the Microsoft Authenticator settings page, click Save.
Check if the user object in Azure AD has a multi-factor authentication method configured
Windows Hello for Business authentication are considered multi-factor authentication (MFA) methods in Conditional Access. In the Authentication Strengths context it's considered a phishing-resistant MFA method. To securely onboard to Windows Hello for Business, the person using the user object should be required to perform multi-factor authentication at least once during the deployment process. A good way to do this is to require multi-factor authentication for the Register or join devices action in Conditional Access.
For this, the user object needs to be configured with at least one multi-factor authentication method. To check if the user object in Azure AD has a multi-factor authentication method configured, perform the following steps:
- Navigate a browser to the Entra portal.
- Sign in with an account that has either the Global Administrator, Authentication Administrator or Privileged Authentication Administrator (when troubleshooting user objects with roles assigned) role assigned or is eligible to activate the role.
Perform multi-factor authentication when prompted. - If the organization uses Azure AD Privileged Identity Management (PIM), activate the role from the list of roles in step 2 with the least administrative privilege.
- In the Entra portal, in the eft-hand navigation menu, expand Users.
- Underneath the Users node, click All users.
The Users pane opens. - At the top of the list, use the Search box to search for the user object(s) you are troubleshooting Windows Hello for Business Hybrid Access for.
- Click the user object.
The users Overview pane opens. - In the menu, click Authentication methods.
Note:
If you haven't activated the new user authentication methods experience, yet, activate it now by clicking on the purple banner offering to switch to the new user authentication methods experience.
- Make sure the user object for the person has at least one authentication method in the list of Usable authentication methods.
If the person does not have a usable authentication method or has lost the means to perform the authentication method, add an authentication method as an admin, require the person to reregister a multi-factor authentication method, or have the user register a multi-factor authentication method.
Check if the device is correctly configured for Windows Hello for Business
Azure AD-joined device can be manually configured with the required settings to configure Windows Hello for Business (WHfB) or through a Mobile Device Management (MDM) solution like Microsoft Intune. It all boils down to registry settings on the device itself, so we can check any result there as the most reliable end-to-end deployment verification means.
To manually check if a device is configured for Windows Hello for Business, look at the following registry keys and values:
Use Windows Hello for Business
The setting Use Windows Hello for Business enables the device to provision Windows Hello for Business using keys or certificates for all users. If you disable this policy setting, the device does not provision Windows Hello for Business for any user.
In the registry, this setting is represented by the Enabled and DisablePostLogonProvisioning values underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork. Enabled should be configured with 1 as its data. DisablePostLogonProvisioning should be configured with 0 as its data or not be present.
Use biometrics
Windows Hello for Business enables users to use biometric gestures, such as face and fingerprints, as an alternative to the PIN gesture. However users must still configure a PIN to use in case of failures. If you enable or do not configure the Use biometrics setting, Windows Hello for Business allows the use biometric gestures.
In the registry, this setting is represented by the Domain Accounts value underneath HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WinBio\Credential Provider. This value needs to be configured with 1 as its data.
Use certificate for on-premises authentication
For Hybrid Certificate Trust, specifically, the UseCertificateForOnPremAuth value underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork needs to present and configured with 1 as its data.
Use cloud trust for on-premises authentication
For Hybrid Cloud Trust, specifically, the UseCloudTrustForOnPremAuth value underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork needs to present and configured with 1 as its data.
Check if the user profile is correctly configured for Windows Hello for Business
To manually check if the user profile is configured for Windows Hello for Business, look at the following registry keys and values:
Use Windows Hello for Business
Even when on the device level, the Use Windows Hello for Business setting is enabled, provisioning Windows Hello for Business may be blocked on the user profile.
In the registry, this setting is represented by the Enabled value underneath HKCU\SOFTWARE\Policies\Microsoft\PassportForWork. The Enabled value should either be absent, or when it is present, it needs to be configured with 1 as its data.
Use certificate for on-premises authentication
Even when on the device level, the Use certificate for on-premises authentication setting is enabled, Hybrid Certificate Trust may still not work when it is blocked on the user profile.
The UseCertificateForOnPremAuth value underneath HKCU\SOFTWARE\Policies\Microsoft\PassportForWork needs to either be absent, or when it is present, it needs to be configured with 1 as its data.
Check if the device has the correct hardware for the Windows Hello for Business settings
With default settings, a Windows device needs a configured Trusted Platform Module (TPM) chip. The use of a TPM chip to store keys for Windows Hello for Business provides additional security. Keys stored in the TPM may only be used on that system while keys stored using software are more susceptible to compromise and could be used on other systems.
While definitely not recommended, this requirement can be disabled through the Use a hardware security device Group Policy settings. If the device does not have a suitable TPM 1.2 or TPM 2.0 chip, this setting needs to be disabled to offer Windows Hello for Business provisioning. In the registry, this setting is represented as the RequireSecurityDevice registry key underneath HKLM\SOFTWARE\Policies\Microsoft\PassportForWork.
Configure this registry setting with the value 0 for testing on devices without suitable TPM chips.
Check the Event log
When the correct settings are present, Windows' Event log is capable of providing insights in why Windows Hello for Business provisioning is not happening.
Over the years, events related to Windows Hello for Business provisioning have been written to logs with various names, but on Windows 11 22H2, the Microsoft\Windows\HelloforBusiness\Operational and Microsoft\Windows\User Device Registration\Admin logs provide detailed information.
When troubleshooting hybrid access, specifically, the Microsoft\Windows\Security-Kerberos\Operational log provides detailed information.
When using FIDO2 security keys, additional information can be found in the Microsoft\Windows\WebAuthN\Operational log.
Tip!
These logs can be accessed in Event Viewer (eventvwr.exe) by selecting the Applications and Services Logs node in the left navigation pane and then drilling down to the log file you're interested in.
Check the Cloud Trust's Read-only Domain Controller
Applies to: Hybrid Cloud Trust scenario, only
When you've chosen the Hybrid Cloud Trust scenario for Windows Hello for Business Hybrid Access, a read-only Domain Controller object is created in the on-premises Active Directory environment. Its read-only domain controller account is named AzureADKerberos and is placed in the Domain Controllers Organizational Unit (OU). Kerberos tickets are issued by Azure AD, based on the password of its specific krbtgt account. This account is named krbtgt_AzureAD and is placed in the Users container.
By using the Active Directory users and computers MMC snap-in (dsa.msc) or the Active Directory Administrative Center (dsac.exe), the presence of these two objects can be checked.
Furthermore, the status of the read-only domain controller can be checked using PowerShell. Use the following commands to get the status on a Windows Server installation in your infrastructure that runs Azure AD Connect:
Import-module "C:\Program Files\Microsoft Azure Active Directory Connect\AzureADKerberos\AzureAdKerberos.psd1"
$domain = "domain.tld"
Get-AzureADKerberosServer
Check if the Domain Controllers are configured with the right certificate
Applies to: Certificate Trust scenario, Key Trust scenario
When you've chosen the Certificate Trust scenario or the Key Trust scenario for Windows Hello for Business Hybrid Access, Domain Controllers need to be configured with the right certificates. You'll need to Upgrade the Certificates for your Windows Server 2016-based Domain Controllers (and up) to enable Windows Hello for Business Hybrid Scenarios.
To check if the Domain Controllers are equipped with the right type of certificates, perform the following steps:
- Sign in interactively to a Domain Controller.
- Right-click the Start button and select Run from the context menu.
The Run window appears. - Type certlm.msc and press OK to close the Run window and start the Certificates MMC snap-in for the Local Computer.
The certlm – [Certificates – Local Computer] window appears. - In the left navigation pane, expand Personal. Then expand the Certificates node underneath it.
- In the main pane, sort on the Certificate Template column.
- Look at the presence of certificates, based on the certificate template that you specified.
In the Microsoft Docs, the template name Domain Controller Authentication (Kerberos) is used. - When done, close the certlm – [Certificates – Local Computer] window.
Tip!
If you've configured automatic certificate enrollment, and the Domain Controller hasn't picked up the settings, yet, you can run the following command to trigger certificate enrollment: certutil.exe –pulse
Check if the device is configured with the root CA's certificate
Applies to: Certificate Trust scenario, Key Trust scenario
When you've chosen the Certificate Trust scenario or the Key Trust scenario for Windows Hello for Business Hybrid Access, devices need to be configured with the certificate of the Root Certification Authority (CA). To check the presence of the Root CA certificate, perform the following steps:
- Sign in interactively to the device.
- Right-click the Start button and select Run from the context menu.
The Run window appears. - Type certlm.msc and press OK to close the Run window and start the Certificates MMC snap-in for the Local Computer.
The certlm – [Certificates – Local Computer] window appears. - In the left navigation pane, expand Trusted Root Certification Authorities. Then expand the Certificates node underneath it.
- In the main pane, sort on the Certificate Template column.
- Search for the certificate of your Root CA.
- When done, close the certlm – [Certificates – Local Computer] window.
Check if the user object is enrolled for the right certificate
Applies to: Certificate Trust scenario, only
When you've chosen the Certificate Trust scenario for Windows Hello for Business Hybrid Access, authentication is based on user certificates. To check the presence of the user certificate, perform the following steps:
- Sign in interactively to the device.
- Right-click the Start button and select Run from the context menu.
The Run window appears. - Type certmgr.msc and press OK to close the Run window and start the Certificates MMC snap-in for the Current User.
The certmgr – [Certificates – Current User] window appears. - In the left navigation pane, expand Personal. Then expand the Certificates node underneath it.
- In the main pane, sort on the Certificate Template column.
- Look at the presence of certificates, based on the certificate template that you specified.
In the Microsoft Docs, the template name WHfB Certificate Authentication is used. - When done, close the certmgr – [Certificates – Current User] window.
Login