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

  • Article

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: hello.contoso.com

Azure AD Domain Name: hellodemo2.chadcolabs.us

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
 Restart-computer
  
 Install-WindowsFeature AD-Domain-Services -IncludeManagementTools
 Install-ADDSForest -DomainName hello.contoso.com
  
 #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 "hello.contoso.com"
  
 #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)

image

On Hello-APP1

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

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.

 

image 

image 

 

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"

image

image

On Hello-APP1 Enable Device Registration

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

image

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

image

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.

imageimage

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. 

image

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

image

On Hello-Client run dsregcmd /status to confirm

image

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. 

image

image

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

imageimage

imageimage

imageimage

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"

image

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

imageimage

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

imageimage

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.

image

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

image

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

image

0x10
KDC_ERR_PADATA_TYPE_NOSUPP
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

image

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.

-Chad

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

https://blogs.technet.microsoft.com/microscott/setting-up-windows-hello-for-business-with-intune/

Azure AD Connect at this time was 1.1.654.0

https://www.microsoft.com/en-us/download/details.aspx?id=47594

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

https://winprotocoldoc.blob.core.windows.net/productionwindowsarchives/MS-PKCA/%5bMS-PKCA%5d.pdf