My Notes on Setting up A POC Windows Hello For Business Lab using Hybrid Key Trust

My goal with this lab is to get Windows Hello Business to work on Windows 10 to show the user experience and provide some lessons learned.  I have provided as many of the steps and PowerShell cmdlets I used to set up this lab so that it can be easier to duplicate.  I would like to give credit to a few of my peers @ Microsoft – Mike S, Greg C, Jacob M and Scott D thanks for helping me work through some scenarios and providing useful information.


Update 3/22/2018

This guide is in no way to be a replacement for the documents Microsoft put together.  Please make sure to review those documents as well.

This particular lab is based on this set up documents. Hybrid Azure AD joined Key Trust Deployment

To learn about deployment options and Windows Hello for Business Benefits go to the official documents.

Windows Hello for Business

This particular lab is great for a POC because it doesn’t require ADFS w/MFA Adapter.

LAB Setup

AD Domain Name:

Azure AD Domain Name:

Virtual Machines

  • Hello-DC01 - Domain Controller / Certificate Authority - Windows Server 2016
  • Hello-APP1 - Azure AD Connect Server - Windows Server 2016
  • Hello-Client - Windows 10 1709

On Hello-DC01

Ran the following PowerShell Commands to set up Domain Controller, Forest and Certificate Services

 Set-TimeZone -Id "Mountain Standard Time"
 Rename-computer -newname HELLO-DC01
 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
 Install-ADDSForest -DomainName
 #No ADFS KDSRootKey Not Needed  no  MSA Used
 #Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
 New-ADGroup -GroupScope Global -Name "KeyCredential Admins"
 New-ADGroup -GroupScope Global -Name "Windows Hello for Business Users"
 #good to have turn on in the environment
 Enable-ADOptionalFeature 'recycle bin feature' -Scope ForestOrConfigurationSet -target ""
 #Configure ADCS
 Install-WindowsFeature ADCS-Cert-Authority -IncludeManagementTools
 Install-AdcsCertificationAuthority -CAType EnterpriseRootCA -KeyLength 4096 -HashAlgorithmName SHA256 -ValidityPeriod Years -ValidityPeriodUnits 20 -CACommonName  "HELLO-DC01" -CryptoProviderName "RSA#Microsoft Software Key Storage Provider" -DatabaseDirectory c:\windows\system32\Certlog -LogDirectory  c:\windows\system32\Certlog -OverwriteExistingDatabase -OverwriteExistingCAinDS -OverwriteExistingKey

Configure the Certificates following these directions – Read Here

  • Configure Domain Controller Certificates
  • Publish Certificate Templates to the Certificate Authority
  • Configure Domain Controllers for Automatic Certificate Enrollment
  • Deploy the Domain Controller Auto Certificate Enrollment Group Policy Object

Give KeyCredential Admins, Read and Write to the msDS-KeyCredentialLink attribute On Descendant User Objects on the root of the domain.  (Can also use the Key Admin Group)


On Hello-APP1

 Add-WindowsFeature RSAT-AD-Tools
 Set-TimeZone -Id "Mountain Standard Time"
 Rename-computer -newname HELLO-APP01

Download and Install Azure AD Connect, screens shots on how this was configured below. Since ADFS is not deployed for this lab password sync is being used.





Need to add the Azure AD Account to the KeyCredential Admins (or Key Admin) group, this will allow the Azure AD connect account to set the attribute in Active Directory

 get-aduser -filter {samaccountname -like "msol*"}
 get-aduser -filter {samaccountname -like "msol*"} | Add-ADPrincipalGroupMembership -memberof "KeyCredential Admins"
 Get-ADGroupMember "KeyCredential Admins"



On Hello-APP1 Enable Device Registration

 Import-Module 'C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1'
 Initialize-ADSyncDomainJoinedComputerSync -AdConnectorAccount: "MSOL_6d8f8960fc61"


Verify the service connection point was created in Active Directory

 (get-adobject -filter * -SearchBase `
     "CN=62a0ff2e-97b9-4513-943f-0d221bd30080,CN=Device Registration Configuration,CN=Services,$((get-adrootdse).configurationNamingContext)" `
     -Properties keywords).keywords


Before jumping into Enabling Windows Hello for business lets make sure Device Registration or Azure AD Join is working.

Create a GPO and link to the OU that contains the computers.

Open the gpo and navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, Device registration and enabled Register domain joined computers as devices.


On Hello-Client

Join Hello-client to the domain and make sure the computer is in the OU where the gpo is linked.

Run gpupdate /force on Hello-Client to make sure the GPO was applied.

Logon to the Azure Portal and check to see if the device shows up in Azure AD under devices. 


if it doesn’t show up validate the device settings allow users to join devices.


On Hello-Client run dsregcmd /status to confirm


Once confirmed that device registration is working enable Windows Hello for Business.

Enable Windows Hello for Business

Create and Link a GPO to the OU where the clients reside.  Edit the GPO and Navigate to Computer Configuration, Policies, Administrative Templates, Windows Components, Windows Hello for Business and enabled Use Windows Hello for Business. 



On Hello-Client run gpupdate /force, restart the computer and logon.  After logging on with a synced user the following should show up. One of the things that surprised me was I didn’t need to set up Azure AD MFA for the Synced User.  As it turns out if the user is not federated and the account is in Azure AD, AAD will send a SMS-Based proof MFA when a user registers a new device.  Read: Register a new user or device




After this is set up, the user wont be able to log in with the pin until an Azure AD Connect sync occurs (30 Minute sync cycle). To validate check the user to see if the msDS-KeyCredentialLink attribute is populated.

 #Verify the user now has msDS-KeyCredentialLink populated.
 get-aduser tom -properties "msDS-KeyCredentialLink"


Once populated login to Hello-Client, with the PIN.  You will probably need to change the sign in option


Here are some of the things I learned during this process. 

1) Personal and Computer installed certs during the process.  These are mostly from being device registered.

 Get-ChildItem –Path Cert:\currentuser\My | fl
 Get-ChildItem –Path Cert:\LocalMachine\My | fl


2a) This is what a Successful Authentication Network Trace looks like using Windows Hello For Business. Note it is using a PA-PK-AS-REQ just like a smart card.


2b) This is what a trace looks like, that is missing the required Domain Controller cert. KDC_ERR_PADATA_TYPE_NOSUPP(16)


On the domain controller, an Event ID 4771 in the security log should show.


KDC has no support for PADATA type (pre-authentication data)
Smart card logon is being attempted and the proper certificate cannot be located. This can happen because the wrong certification authority (CA) is being queried or the proper CA cannot be contacted in order to get Domain Controller or Domain Controller Authentication certificates for the domain controller.
It can also happen when a domain controller doesn’t have a certificate installed for smart cards (Domain Controller or Domain Controller Authentication templates).

PreAuthType 14-17 from RFC 4120 is PKINIT, but none of our charts call out 16 directly, PreAuthtype of 15 is PA-PK-AS-REP_OLD which is a smart card auth.

This is what an actual smart card capture looks like


My next challenge will be Upgrading a Windows 2012r2 lab with ADFS 3.0 to Windows Server 2016 to support Windows Hello for Business using On Pre Certificate Trust.


Update 5/2/2018 – this is a great description on what is happening in the background  - Windows Hello for Business: Registration and Authentication with #AzureAD

Useful Resources:

Windows Hello for Business /en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification

Hybrid Azure AD joined Key Trust Deployment /en-us/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust

Setting up Windows Hello for Business with Intune

Azure AD Connect at this time was 1.1.654.0

Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol