Set up Windows Hello for Business Hybrid Azure AD joined Devices
In one of my last posts you will see how to disable the mandatory Windows Hello for Business Prompt (provisioning) on Azure AD joined devices and also get detailed information about what’s the difference between Windows Hello (convenient sign-in) and Windows Hello for Business.
- Introduction
- Prerequisites
- Set up
- Determine if Windows Hello for Business is used for your Windows Sign In
- Removing your Windows Hello for Business PIN Registration
- Identify if you register your Account for Windows Hello (convenient sign-in) or Windows Hello for Business
- Moving from Windows Hello (convenient sign-in) to Windows Hello for Business
- Troubleshooting
- Windows Hello for Business Logon Process Flow
- Security aspects
- Links
Introduction
In this post we will see, how to set up Windows Hello for Business for Hybrid Azure AD joined devices by using the key trust model (deployment).
Windows Hello for Business was introduced in Windows 10 1703
There are also further deployments available for Windows Hello for Business as follows:
- Hybrid Azure AD Joined Certificate Trust Deployment
- On-premises Key Trust Deployment
- On-premises Certificate Trust Deployment
Whereas Windows Hello for Business for Azure AD joined devices will be provisioned and works out of the box, for Hybrid Azure AD joined devices we will first need to invest some effort to get it up and running.
To set up Windows Hello for Business for Hybrid Azure AD joined devices you can choose between two following trust models:
- Hybrid Azure AD Joined Certificate Trust Deployment
- Hybrid Azure AD Joined Key Trust New Installation
Which is better or more secure, key trust or certificate trust?
Both key trust and certificate trust use the same hardware-backed, two-factor credential. The difference between the two trust types are:
- Required domain controllers
- Issuing end entity certificates
The key trust model authenticates to Active Directory by using a raw key. Windows Server 2016 domain controllers enable this authentication. Key trust authenticate does not require an enterprise issued certificate, therefore you don’t need to issue certificates to users (domain controller certificates are still needed).
The certificate trust model authenticates to Active Directory by using a certificate. Because this authentication uses a certificate, domain controllers running previous versions of Windows Server can authenticate the user. Therefore, you need to issue certificates to users, but you don’t need Windows Server 2016 domain controllers. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise’s issuing certificate authority.
How are keys protected?
Wherever possible, Windows Hello for Business takes advantage of Trusted Platform Module (TPM) 2.0 hardware to generate and protect keys. However, Windows Hello and Windows Hello for Business do not require a TPM. Administrators can choose to allow key operations in software.
Whenever possible, Microsoft strongly recommends the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will need to reset the PIN (which means they’ll need to use MFA to re-authenticate to the IDP before the IDP allows them to re-register).
Source: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq#how-are-keys-protected
The Certificate Trust deployment only works in federated environments by using the Active Directory Federation Services (AD FS).
In contrast Windows Hello for Business key trust can be deployed in non-federated and federated environments.
Federation with Azure
You can deploy Windows Hello for Business key trust in non-federated and federated environments. For non-federated environments, key trust deployments work in environments that have deployed Password Synchronization with Azure AD Connect or Azure Active Directory Pass-through-Authentication. For federated environments, you can deploy Windows Hello for Business key trust using Active Directory Federation Services (AD FS) 2012 R2 or later.
Source: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs#federation-with-azure
Prerequisites
In this post I want to go through each step to set up the key trust model.
In the following article from Microsoft you will find all prerequisites for the key trust model.
Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs#federation-with-azure
In a nutshell these are:
- at least one 2016 Domain Controller
only 2016 DCs enable key trust authentication - Azure AD Connect
The two directories used in hybrid deployments must be synchronized. You need Azure Active Directory Connect to synchronize user accounts in the on-premises Active Directory with Azure Active Directory. - Enterprise PKI – Active Directory Certificate Services (AD CS)
Domain controllers for hybrid deployments need a certificate in order for Windows 10 devices to trust the domain controller. - Device Registration
Organizations wanting to deploy hybrid key trust need their domain joined devices to register to Azure Active Directory. Just as a computer has an identity in Active Directory, that same computer has an identity in the cloud. This ensures that only approved computers are used with that Azure Active Directory. Each computer registers its identity in Azure Active Directory.
Set up
I assume you will have already installed and configured Azure AD Connect. If not you can use my following post about install and configure Azure AD Connect to synchronize your on-premises network with Azure AD.
Also you will find here detailed information about how to configure Azure AD Connect in order to set up Windows Hello for Business key trust model.
Configure Directory Synchronization for Hybrid Azure AD joined key trust Windows Hello for Business
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-dirsync
In my lab environment I have a running Azure AD Connect setup and therefore I will first check if device registration is already configured as it is a prerequisite to set up Windows Hello for Business.
You will also find in my following post about how to configure Hybrid Azure AD join, the steps which will also enables the device registration.
In order to check if device registration is configured in Azure AD Connect, I will first edit the synchronization options.
Here you need to check to select all OUs where you store your computer objects which should be used for Hybrid Azure AD join and therefore must be synced to Azure AD.
Further we need to check the Configure device options
Here we need to select Configure Hybrid Azure AD join
I will only have Windows 10 clients in my environment and also Windows Hello requires you to have Windows 10 clients.
Finally configure the SCP configuration which you will find in my post mentioned above.
The next step is to configure the public key infrastructure.
Windows Hello for Business must have a public key infrastructure regardless of the deployment or trust model. All trust models depend on the domain controllers having a certificate. The certificate serves as a root of trust for clients to ensure they are not communicating with a rogue domain controller.
Source: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install#public-key-infrastructure
If you do not have an existing public key infrastructure, please review Certification Authority Guidance from Microsoft TechNet to properly design your infrastructure.
Configure a Production Public Key Infrastructure
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install#configure-a-production-public-key-infrastructure
Because my lab environment already have a running public key infrastructure I can skip that step.
Finally we need to enable Windows Hello for Business by using a group policy for the user’s or computers you want to enroll it.
Enable Windows Hello for Business
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-settings-policy#enable-windows-hello-for-business
You can configure the Enable Windows Hello for Business Group Policy setting for computer or users.
In my lab environment, I will apply the GPO to computers, therefore I need to configure the following policy.
Computer Configuration -> Administrative Templates -> Windows Components -> Windows Hello for Business
The GPO is linked to the OU with the computers who should provision Windows Hello for Business.
From now on all Windows 10 computers (version 1703 or later) residing in that OU, should provision Windows Hello for Business, after the user signs-in the next time as follows.
Hybrid Azure AD joined Windows Hello for Business Key Trust Provisioning
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-whfb-provision
If you want to change your PIN later, you can go to settings -> Accounts -> Sign-in options -> Windows Hello PIN and click on Change.
The next time the user want’s to logon to the device, the PIN can be used instead the password.
By clicking on Sign-in options you can still use your password to logon to the device.
You will find your Hybrid Azure AD joined devices in the Azure Portal https://portal.azure.com under
Azure Active Directory -> Devices -> All devices
Here you will see the device win10, which is used from John Doe for the logon and provisioning above.
To only disable the Windows Hello for Business provisioning process after sign-in on the device, which prompts the following dialog, …
… you can also enable Windows Hello for Business with that GPO but also check the option Do not start Windows Hello provisioning after sign-in as shown below.
That option is available in both sections of the GPO, the Computer configuration and User configuration.
Determine if Windows Hello for Business is used for your Windows Sign In
To finally check if Windows Hello for Business is used for the Windows Sign In on a Azure AD joined device, you can check the Sign-in logs from Azure AD as follows.
Azure Active Directory -> Sign-in logs
You can also add a filter to limit the logs only on Windows Sign In events as follows.
Click on Add filters
Select Application and click on Apply.
Add the name of the application in our case Windows Sign In and click on Apply.
Removing your Windows Hello for Business PIN Registration
As far as I know, at the moment you have only two options to remove your Windows Hello for Business PIN registration, which both of them a little bit odd in my opinion.
The Windows Hello (convenient sign-in) registration in contrast can be removed as expected by using the Remove button as follows. The button here is not greyed out and you can click on it to remove the registration.
For Windows Hello for Business PIN this button is greyed out by default as you can see in the screenshots below. The GPO itself does also not provide a setting to enable the user to remove the registration, only to not start Windows Hello provisioning after sign-in.
In order to remove Windows Hello for Business PIN, you can either use the certutil command or the I forgot my PIN link and cancel the process afterwards, as shown below. Both options will remove the registration, but keep in mind, that if the Windows Hello for Business GPO above doesn’t have checked the option Do not start Windows Hello provisioning after sign-in, after removing you will be prompted after the next logon to your device again to set up Windows Hello for Business.
certutil.exe -DeleteHelloContainer
logoff.exe
Remove button is greyed out for Windows Hello for Business as mentioned.
The registration is removed
Removing your Windows Hello for Business registration by using the I forgot my PIN link
Click on the link
Click on Continue
Click on Cancel
Click on the link I’ll set up a PIN later
The registration is removed.
Identify if you register your Account for Windows Hello (convenient sign-in) or Windows Hello for Business
If you want to know if you register your account for Windows Hello (convenient sign-in) or Windows Hello for Business, you can distinguish them easily by the dialog itself for the password verification as follows.
Windows Hello (convenient sign-in) dialog
You only get prompted from your local device itself to verify your local cached domain or standalone password and storing them within a sort of wrapper on that device. The PIN only releases that wrapper on the local device to use the credentials within for authentication as usual.
The Windows Hello (convenient sign-in) registration you can also remove by using the Remove button.
Windows Hello for Business dialogs
Here you can see from the dialogs that you need to verify the password directly with Azure AD.
Behind the scenes an asymmetric key pair is created and the public key is associated with your Azure AD account and then synced to your on-premises Active Directory user object and msDS-KeyCredentialLink attribute as described under troubleshooting at the end of this post.
And in contrast to the Windows Hello (convenient sign-in) registration, the Remove button is greyed out after registration for Windows Hello for Business.
In case of a hybrid Azure AD joined certificate trust, on-premise key trust or on-premise certificate trust deployment, you will be prompted with a dialog from the internal Active Directory Federation Services (AD FS) server like this for password verification.
Moving from Windows Hello (convenient sign-in) to Windows Hello for Business
If you still use Windows Hello (convenient sign-in) in your network and want to move to use Windows Hello for Business, you first have to change your policy settings for Turn on convenience PIN sign-in into Not Configured as follows.
Computer Configuration -> Policies -> Administrative Templates -> System -> Logon -> Turn on convenience PIN sign-in
Now you can enable the Windows Hello for Business policy as follows if you already had configured your environment for Windows Hello for Business as described in this post.
You can choose here between computer or user policy.
Computer Configuration -> Administrative Templates -> Windows Components -> Windows Hello for Business
User Configuration -> Administrative Templates -> Windows Components -> Windows Hello for Business
In case you check the option Do not start Windows Hello provisioning after sign-in for that policy, the user’s will still use Windows Hello (convenient sign-in) and first have to remove that registration in order to add afterwards a new Windows Hello for Business registration as follows.
Now the user can add a new Windows Hello for Business registration.
If that option, Do not start Windows Hello provisioning after sign-in, is not checked, the next time the user logs on to its device, can indeed still use its existing convenient PIN to sign-in, but then will be prompted to set up Windows Hello for Business as usual. The user also can cancel that process, but then will be prompted for each logon again.
Troubleshooting
That option is temporarily unavailable. For now, please use a different method to sign in.
If you run into the following error directly after provisioning Windows Hello for Business key trust model, the reason for is supposedly that the key is not already synced from Azure AD to your on-premises Active Directory. The user’s public key will be written to the msDS-KeyCredentialLink attribute of the user object in your on-premises Active Directory as shown below.
In hybrid deployments, users register the public portion of their Windows Hello for Business credential with Azure. Azure AD Connect synchronizes the Windows Hello for Business public key to your on-premises Active Directory.
Directory Synchronization
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-whfb-settings-dir-sync#directory-synchronization
https://github.com/MicrosoftDocs/windows-itpro-docs/blob/public/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md#identifying-user-public-key-deletion-issue
You will find in the following link also how this authentication flow works in detail.
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication#hybrid-azure-ad-join-authentication-using-a-key
Here you can see the from Azure AD to the on-premises Active Directory synced msDS-KeyCredentialLink attribute as mentioned above.
Here you can see that the msDS-KeyCredentialLink attribute is exported by the Windows Azure Active Directory connector to on-premises.
More about the Azure AD Connect architecture and how it works you will find in my following post.
Your credentials could not be verified
Something went wrong and your PIN isn’t available (status: 0x000005e, substatus:0x0). Click to set up your PIN again.
This error appears on Hybrid Azure AD joined devices (both, key and certificate trust) for the first logon after provisioning Windows Hello for Business and if the device doesn’t have a connection to the internal domain controllers from your on-premises network.
For example you provision Windows Hello for Business on your notebook from external.
For Hybrid Azure AD joined devices a newly provisioned user will not be able to sign in using Windows Hello for Business until:
(a) Azure AD Connect successfully synchronizes the public key to the on-premises Active Directory and
(b) device has line of sight to the domain controller for the first time.
You will find in the following link also how this authentication flow works in detail.
Source: https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication#hybrid-azure-ad-join-authentication-using-a-key
You can use here a simple workaround to solve this issue:
- logon to your device by using your password
- establish a vpn connection to your network
(if you already establish the vpn connection at the logon screen by using the -AllUserConnection flag for the native windows vpn, and therefore logon directly against your internal domain controllers, or after the logon, doesn’t matter in this case) - lock your screen
- unlock your screen by using the (PIN or biometrics)
- done!
After that the next second logon from external should also work by using the (PIN or biometrics).
Deleting the Ngc Folder
Sometimes you encounter problems where nothing else works, in this case you could try to solve them by deleting the Ngc folder. By deleting this folder, all Windows Hello registrations on the device will be removed.
Windows 10 stores all information about the Windows Hello PIN registration among the Trusted Platform Module (TPM) and the local Ngc folder:
C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc
If you can’t delete this folder because of missing permissions, you can execute one or all of the following commands in order to be able to.
takeown /F C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc /R /D Y # This tool allows an administrator to recover access to a file that was denied by re-assigning file # ownership. # /F filename # /R recursive # /D prompt Default answer used when the current userdoes not have the "list folder" permission on a # directory. This occurs while operating recursively (/R) on sub-directories. Valid values "Y" to # take ownership or "N" to skip. # If necessary also execute the following command, your account should be a member of the local # administrators group. icacls C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc /T /C /GRANT administrators:f # Displays or modifies discretionary access control lists (DACLs) on specified files, and applies # stored DACLs to files in specified directories. # /T Performs the operation on all specified files in the current directory and its subdirectories. # /C Continues the operation despite any file errors. Error messages will still be displayed. # /GRANT Grants specified user access rights. Permissions replace previously granted explicit # permissions.
Now you should be able to delete this folder. After that try the provisioning again, the Ngc folder will be created automatically during this process.
Windows Hello for Business Logon Process Flow
You will find detailed information about how the logon process in Windows Hello for Business will work by the following Microsoft article.
Windows Hello for Business and Authentication
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication
Security aspects
Both trust models intensely reduce the risk of keyloggers, password phishing or password interception in general.
Windows Hello for Business fits in seamlessly with modern authentication (using tokens instead username and password like in basic authentication in a nutshell) and extends it with new tokens and encryption keys for authentication like the Primary Refresh Token (PRT).
By using both technologies side by side, the Primary Refresh Token (requesting access and refresh tokens for registered apps in Azure AD) and Windows Hello for Business for Azure AD joined or Hybrid Azure AD joined devices, the username and password will never be transmitted to the identity provider (IdP), instead tokens will be sent and used.
This is also true for the Windows Hello for Business provisioning process, instead username and password, the PRT will be used for authentication from Azure AD joined or Hybrid Azure AD joined devices
A PRT is issued with all Windows 10 supported credentials, for example, password and Windows Hello for Business.
Source: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#how-is-a-prt-issued
During Windows sign in, the Azure AD CloudAP plugin requests a PRT from Azure AD using the credentials (in case of Windows Hello for Business the cryptographic keys) provided by the user. It also caches the PRT to enable cached sign in when the user does not have access to an internet connection.
Source: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#how-is-a-prt-used
Sign in with Windows Hello for Business: Windows Hello for Business replaces passwords and uses cryptographic keys to provide strong two-factor authentication. Windows Hello for Business is specific to a user on a device, and itself requires MFA to provision. When a user logs in with Windows Hello for Business, the user’s PRT gets an MFA claim. This scenario also applies to users logging in with smartcards if smartcard authentication produces an MFA claim from ADFS.
As Windows Hello for Business is considered multi-factor authentication, the MFA claim is updated when the PRT itself is refreshed, so the MFA duration will continually extend when users sign in with WIndows Hello for Business.
Source: https://docs.microsoft.com/en-us/azure/active-directory/devices/concept-primary-refresh-token#when-does-a-prt-get-an-mfa-claim
You can check if a PRT is issued to your user and device by using the command dsregcmd /status
Under SSO State you will find AzureAdPrt yes or no.
The device is Hybrid Azure AD joined
NgcSet: Set to “YES” if a Windows Hello key is set for the current logged on user.
WamDefaultAuthority: Set to “organizations” for Azure AD.
WamDefaultId: Always “https://login.microsoft.com” for Azure AD.
AzureAdPrt: Set to “YES” if a PRT is present on the device for the logged-on user.
AzureAdPrtUpdateTime: Set to the time in UTC when the PRT was last updated.
AzureAdPrtExpiryTime: Set to the time in UTC when the PRT is going to expire if it is not renewed.
AzureAdPrtAuthority: Azure AD authority URL
EnterprisePrt: Set to “YES” if the device has PRT from on-premises ADFS. For hybrid Azure AD joined devices the device could have PRT from both Azure AD and on-premises AD simultaneously. On-premises joined devices will only have an Enterprise PRT.
EnterprisePrtAuthority: ADFS authority URL
If the Windows Hello key is not set for the device, you will see the following output.
Further you will see an additional section at the end with Ngc Prerequisites Check as follows.
Ngc for Next Generation Cryptographic aka Cryptography API: Next Generation (CNG)
Cryptography API: Next Generation
https://docs.microsoft.com/en-us/windows/win32/seccng/cng-portal
Cryptography API: Next Generation (CNG)
https://de.wikipedia.org/wiki/Cryptography_API:_Next_Generation
Windows 10 stores all information about the Windows Hello PIN registration among the Trusted Platform Module (TPM) and the local Ngc folder:
C:WindowsServiceProfilesLocalServiceAppDataLocalMicrosoftNgc
This section performs the prerequisite checks for the provisioning of Windows Hello for Business (WHFB).
PolicyEnabled: Set to “YES” if the WHFB policy is enabled on the device.
PostLogonEnabled: Set to “YES” if WHFB enrollment is triggered natively by the platform. If it’s set to “NO”, it indicates that Windows Hello for Business enrollment is triggered by a custom mechanism
DeviceEligible: Set to “YES” if the device meets the hardware requirement for enrolling with WHFB.
SessionIsNotRemote: Set to “YES” if the current user is logged in directly to the device and not remotely.
CertEnrollment: Specific to WHFB Certificate Trust deployment, indicating the certificate enrollment authority for WHFB. Set to “enrollment authority” if source of WHFB policy is Group Policy, “mobile device management” if source is MDM. “none” otherwise
PreReqResult: Provides result of all WHFB prerequisite evaluation. Set to “Will Provision” if WHFB enrollment would be launched as a post-logon task when user signs in next time.
See also for more information about using the dsregcmd command the following article.
Troubleshooting devices using the dsregcmd command
https://docs.microsoft.com/en-us/azure/active-directory/devices/troubleshoot-device-dsregcmd
That doesn’t mean you will be safe from attacks at all by using token based authentication, there are also potential weaknesses like in all systems. The following links will deal about that for Windows Hello for Business as well as the Primary Refresh Token (PRT).
Bypassing Windows Hello Without Masks or Plastic Surgery
https://www.cyberark.com/resources/threat-research-blog/bypassing-windows-hello-without-masks-or-plastic-surgery
Black Hat: Microsoft’s Patch for Windows Hello Bypass Bug is Faulty, Researchers Say
https://threatpost.com/microsofts-patch-windows-hello-faulty/168392/
Pass-the-PRT
https://twitter.com/gentilkiwi/status/1291537989395505158?lang=de
Abusing Azure AD SSO with the Primary Refresh Token
https://dirkjanm.io/abusing-azure-ad-sso-with-the-primary-refresh-token/
Digging further into the Primary Refresh Token
https://dirkjanm.io/digging-further-into-the-primary-refresh-token/
CQ Hacks 39: A Look Inside a Pass-the-PRT Attack
https://www.youtube.com/watch?v=9WDe7IiSrWE
More technical details about how Windows Hello for Business works you will find in the following Microsoft articles.
Windows Hello for Business Overview
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-overview#how-windows-hello-for-business-works-key-points
Why a PIN is better than a password
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password
How Windows Hello for Business works
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works
Manage Windows Hello for Business in your organization
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-manage-in-organization
It’s also worth to watch Microsoft’s password-less strategy.
What is the password-less strategy?
Watch Principal Program Manager Karanbir Singh’s Microsoft’s guide for going password-less Ignite 2017 presentation.
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-videos#microsofts-passwordless-strategy
Links
Windows Hello for Business Hybrid Azure AD joined Key Trust New Installation
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-new-install
Hybrid Azure AD joined Key trust Windows Hello for Business Prerequisites
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust-prereqs#federation-with-azure
Hybrid Azure AD joined Certificate Trust Deployment
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust
Windows Hello for Business Frequently Asked Questions (FAQ)
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-faq
Windows Hello for Business Videos
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-videos#microsofts-passwordless-strategy
Microsoft’s passwordless strategy
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-videos#microsofts-passwordless-strategy
Windows Hello for Business settings in Configuration Manager
https://docs.microsoft.com/en-us/mem/configmgr/protect/deploy-use/windows-hello-for-business-settings
Starting in Configuration Manager version 2103, this company resource access feature is deprecated. Use Microsoft Intune to deploy resource access profiles.
How it works: Device registration
https://docs.microsoft.com/en-us/azure/active-directory/devices/device-registration-how-it-works
Windows Hello for Business and Authentication
https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication
