The purpose of this post is to help IT pro's and architects understand Windows Hello for Business as it relates to Windows 10 modern management (with Intune). The deployment guide for Windows hello for business is very comprehensive so I'm not reproducing that – but instead want to strip out much of the complexity and choices, and focus on the pieces that matter to organisations aiming for Windows 10 Modern Management using Microsoft Enterprise Mobility + Security (EMS) suite. This means I'm not even going to touch on the pure "On-Premises" deployment choices.
Choosing the right Windows Hello for Business deployment:
![]()
Summarizing a massive table of considerations and requirements (and hopefully not over-simplifying it) I'm going to boil it down to a few key points common to the majority of Intune customers I work with:
- They use Intune to manage mobile devices (iOS and Android) and they enforce conditional access to Exchange online and SharePoint online. For that reason, they are already using Azure AD user identities AND device registration for domain-joined devices (aka hybrid Azure AD Join) as this is a requirement for conditional access -> Hybrid Azure AD
- They are looking at or actively moving to Modern Windows 10 management, shifting away from heavy-handed IT SOE design and management, but still have traditional desktop managed Windows 10 machines (managed by GPO or SCCM Client) and want those devices to leverage Windows Hello for Business too -> Hybrid Azure AD
- They are actively trying to reduce On-Prem server infrastructure, move away from an Active Directory Federation Services (ADFS) and Web Application Proxy (WAP) architecture and simplify deployment -> Key Trust
For those reasons I'll cover the Hybrid Key Trust deployment method. (There are reasons to choose Hybrid Certificate Trust too – I'll cover that setup in a future post)
Overview of Configuration Steps:
Step 1: Configure Azure AD Connect - Password Hash Sync and Device Registration (AD Service connection point) + build a Server 2016 Domain Controller
Step 2: Configure a new KDC Certificate Template on your CA and issue a cert to your DC's (Optional)
Step 3:
Configure Windows Hello client settings (Though Intune for Modern managed devices and through GPO for the domain joined PC's)
![]()
Step 1: Configure Azure AD Connect - Password Hash Sync and Device Registration (AD Service connection point) + build a Server 2016 Domain Controller
The deployment guide calls out loads of requirements but in truth, there is not a lot to it, and most of these things will already be done if you've been using other Microsoft 365 scenarios like Conditional Access.
Start the Azure AD Connect setup wizard and configure these key requirements:
User Sign-in
Password Synchronisation OR Pass-Through Authentication must be enabled (as opposed to using ADFS).
SSO – Not strictly needed for Hello for Business but it enhances user experience when in the corporate network so I'm enabling it.
![]()
Turn on Device Registration
This is one of the most important steps because it creates a Service Connection Point in the Active Directory forest that directs your Windows 10 devices to the right endpoint in AAD to perform device registration (aka Hybrid Azure Ad join). If you ran the express installation of Azure AD Connect, this would have already been done and would not be required as an extra step.
Add-WindowsFeature RSAT-AD-Tools
Import-Module 'C:Program FilesMicrosoft Azure Active Directory ConnectAdPrepAdSyncPrep.psm1'
Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount:[connector account]
![]()
Set extra permissions for Azure AD Connect Service Account
As an extra step specifically for Windows Hello for Business - AAD Connect Service account needs to be part of the "KEY ADMINS" AD Security Group. This gives the sync service account access to read and write the msDS-KeyCredentialLink attribute on each user object).
Ie: Allows the windows hello public key to be synchronised from Azure AD to AD,
![]()
Verify that its configured correctly:
Use ADSI Edit on a domain controller to ensure a service connection point has been created.
![]()
Other Infrastructure Changes
Server 2016 - You need to build at least one Server 2016 Domain Controller to authenticate Windows Hello Logons
Step 2: Configure a new KDC Certificate Template on your CA and issue a cert to your DC's (Optional)
Certificate Authority Requirements
The CA is not for handing out certificates to devices as we are doing "Key Trust" here. Its only purpose in this scenario is to configure a newer, better performant Kerbersos KDC template that your 2016 domain controllers can use to prove their identity to clients. In a lab environment you could skip this step if you didn't want to deploy Public Key Infrastructure.
Configure a new Certificate template and get your 2016 DC's to use it (Copy the "Domain Controller Authentication" template and change these things)
Template Name: Domain Controller Authentication (Kerberos)
Compatibility: Windows Server 2016 (or 2012 or 2012 R2)
Subject Name: DNS
Cryptography: Key Storage Provider, Request hash SHA256
Superseded Templates: Domain Controller, Domain Controller Authentication
![]()
Now enable the auto-enrolment GPO setting and target at your domain controllers
Computer Configuration > Policies > Windows Settings > Security Settings > Certificate Services Client - Auto-Enrollment
After a GPUpdate, your Domain controllers will have a Certificate in the Computer store based on the new template which supersedes the old ones.
![]()
Step 3: Configure Windows Hello client settings (Though Intune for Modern managed devices and through GPO for the domain joined PC's)
Modern Managed Devices
If you are managing devices that are Azure AD Joined + Intune enrolled, the configuration for Windows Hello for business is on by default (Windows 10 1709) so you don't need to do anything.
If you want to configure or change the defaults, head to the Intune console and tweak the Hello for Business client configuration:
![]()
Domain Joined devices
If you want your domain joined devices to be able to do windows hello you need to configure at least one group policy to get things started.
Computer Configuration > Administrative Templates > Windows Components > MDM > Auto MDM Enrolment with AAD Token
This GPO can be targeted at all Windows 10 1709 Devices and it will essentially perform two things: Trigger Azure AD Device Registration AND enrol the device into Intune so that Intune can deliver the Windows Hello for Business settings (from the screenshot above).
![]()
Option 2 - If you are not quite ready to have your devices managed by GPO and INTUNE at the same time, you can instead just enable the Device Registration and Windows Hello for Business as separate Group Policy delivered settings.
Turn on Device Registration (aka Hybrid Azure AD Join)
Computer Configuration > Policies > Administrative Templates > Windows Components > Device Registration > Register domain joined computers as devices
![]()
Turn on Windows Hello for Business
Computer Configuration > Policies > Administrative Templates > Windows Components> Windows Hello for Business > Use Windows Hello for Business
Note: This setting is also available as a user targeted setting
![]()
The third option for registering devices into Azure AD and delivering the Hello for Business Settings would be through the Configuration Manager client – Using "Co-Management", you could orchestrate the Device registration and deliver the Hello for Business settings – which you could then gradually move across to being delivered from Intune rather than SCCM. I'm not going to cover co-management in this post (It's a very big topic) but I wanted to call it out as a viable option here as you slowly move devices from traditional to modern management.
Testing it out and Troubleshooting
Domain Joined PC
After you configure all the pre-reqs, there is a lot of work that gets orchestrated under the covers. Here is a quick flow diagram to show where and how you can troubleshoot or validate progress along the way.
![]()
![]()
Domain Joined PC's grab Computer policies during the boot process so during the first boot after targeting the GPO for Automatic MDM enrolment, the machine should receive the group policy setting telling it to perform the Automatic Intune enrolment. A good test that this is working is once logged on, launch a command prompt as an administrator and run GPRESULT /User: domainnameusername /Z and look for AutoEnrollMDM setting
![]()
![]()
At the first login, a scheduled task will be triggered that starts the Device Registration Process off. Check that the scheduled task has been initiated by launching Task Scheduler as an administrator and looing for ensuring the Automatic-Device-Join task is enabled and look at the History to see if it has initiated successfully
![]()
If Device registration worked, you should also see a Device Registration certificate installed in the Local Machine Personal store. Launch certlm.msc and look in Personal to check for certificates issued by MS-Organization-Access
![]()
Also, if you go to the Azure Active Directory portal and look at All Azure AD Devices you will see a device object created.
![]()
If the device registration doesn't work, you can open a command prompt or Powershell window (with standard user credentials) and run Dsregcmd /status or dsregcmd /status /debug to investigate.
(This screenshot is a successful Device registration)
![]()
Device registration status information is also provided in the Microsoft – Windows - User Device Registration event log.
![]()
![]()
A scheduled task exists to Automatically enrol the device into Intune, it will run every 15 minutes. Check it out to ensure it ran successfully
![]()
Upon successful Intune enrolment, you will also see a new certificate deployed to the local machine personal store
![]()
… and an object in the Intune portal
![]()
![]()
Upon enrolment, the device will start pulling down settings and configuration from Intune – in this case, the Windows Hello for Business configuration settings. You will be able to see the settings arrived by looking at the MDM Diagnostics report from Settings. (Note: The settings in this report still appear under the old name "PassportForWork"
Another indicator that this is good to go is by running dsregcmd /status again.
In this example PolicyEnabled means that Intune delivered the settings, but DeviceEligible = No because my machine didn't have a TPM and I configured this as a requirement in the Windows Hello for Business policy. To fix, I had to enable virtual TPM on my Hyper-V VM.
![]()
![]()
After the MDM Settings are delivered via Intune, the user will be prompted to configure Hello at the next user logon. A visual check during the logon will tell you that Windows Hello for Business is working at this point.
![]()
![]()
After a strong (Private-Public) key-pair has been generated on the Device, the private key will be secured on the device (backed by TPM) and the Public key will be written into Azure AD.
![]()
In order for users to authenticate against a domain controller when they are inside their corporate network, Sync must occur. The Public Key from Azure AD will be written into the Users object in AD using the msDS-KeyCredentialLink attribute. The default sync interval for AAD Connect is 30 minutes.
You can visually check that this has occurred using a tool like LDP. In this screenshot the user "Scott" has multiple Windows 10 devices enrolled with Windows Hello for business and therefore multiple entries.
![]()
![]()
The next time the user wants to logon, they can use their Windows Hello for Business pin or biometrics to sign-in and authenticate against a Windows Server 2016 domain controller.
If sync back to on-prem has not occurred yet, the user may get an error "That option is temporarily unavailable. For now, please use a different method to sign in" if they are inside the corporate network.
![]()
Modern Managed Windows 10 Device
The flow is much simpler for Azure AD joined devices. The Device registration is not required and there is not Group Policy involved:
![]()
![]()
Device is Azure AD Joined (Either user driven or Auto-pilot driven during OOBE)
![]()
At the end of the AADJ, User will be prompted to Setup Windows Hello for Business Pin. This is the default configuration for a non-domain joined Windows 10 device. After a strong (Private-Public) key-pair has been generated on the Device, the private key will be secured on the device (backed by TPM) and the Public key will be written into Azure AD.
![]()
On the next logon, the user will be able to logon with their "Hello" credentials. This unlocks access to the private key.
![]()
Device authenticates against AzureAD. (Note – Private key is never sent on the wire. The client instead sends a "Nonce" to Azure AD, which replies with a message encrypted with the Public key. After authentication, the device obtains an Azure AD PRT.
Summary:
This post was way longer that what I expected it to be! I tried my hardest to take the complexity out of the setup and configuration, yet also add enough detail for you to setup and test the feature while also understanding the nuts and bolts that make it work across both AD and Azure AD, GPO and MDM.
Let me know how you go – Next up I want to cover Windows Hello for Business - Hybrid Certificate Trust deployment.
Oh, and If you want to go deeper on this stuff, I'd recommend reading some of Jairo Cadena's posts:
https://jairocadena.com/2016/01/18/how-domain-join-is-different-in-windows-10-with-azure-ad/
https://jairocadena.com/2016/03/09/azure-ad-and-microsoft-passport-for-work-in-windows-10/
https://jairocadena.com/2016/11/08/how-sso-works-in-windows-10-devices/
Domain Joined PC's grab Computer policies during the boot process so during the first boot after targeting the GPO for Automatic MDM enrolment, the machine should receive the group policy setting telling it to perform the Automatic Intune enrolment. A good test that this is working is once logged on, launch a command prompt as an administrator and run GPRESULT /User: domainnameusername /Z and look for AutoEnrollMDM setting
At the first login, a scheduled task will be triggered that starts the Device Registration Process off. Check that the scheduled task has been initiated by launching Task Scheduler as an administrator and looing for ensuring the Automatic-Device-Join task is enabled and look at the History to see if it has initiated successfully
A scheduled task exists to Automatically enrol the device into Intune, it will run every 15 minutes. Check it out to ensure it ran successfully
Upon enrolment, the device will start pulling down settings and configuration from Intune – in this case, the Windows Hello for Business configuration settings. You will be able to see the settings arrived by looking at the MDM Diagnostics report from Settings. (Note: The settings in this report still appear under the old name "PassportForWork"
After the MDM Settings are delivered via Intune, the user will be prompted to configure Hello at the next user logon. A visual check during the logon will tell you that Windows Hello for Business is working at this point.
After a strong (Private-Public) key-pair has been generated on the Device, the private key will be secured on the device (backed by TPM) and the Public key will be written into Azure AD.
In order for users to authenticate against a domain controller when they are inside their corporate network, Sync must occur. The Public Key from Azure AD will be written into the Users object in AD using the msDS-KeyCredentialLink attribute. The default sync interval for AAD Connect is 30 minutes.
The next time the user wants to logon, they can use their Windows Hello for Business pin or biometrics to sign-in and authenticate against a Windows Server 2016 domain controller.
Device is Azure AD Joined (Either user driven or Auto-pilot driven during OOBE)
At the end of the AADJ, User will be prompted to Setup Windows Hello for Business Pin. This is the default configuration for a non-domain joined Windows 10 device. After a strong (Private-Public) key-pair has been generated on the Device, the private key will be secured on the device (backed by TPM) and the Public key will be written into Azure AD.
On the next logon, the user will be able to logon with their "Hello" credentials. This unlocks access to the private key.
Device authenticates against AzureAD. (Note – Private key is never sent on the wire. The client instead sends a "Nonce" to Azure AD, which replies with a message encrypted with the Public key. After authentication, the device obtains an Azure AD PRT.