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 - Greg C, Jacob M and Scott D thanks for helping me work through some scenarios and providing useful information.
To learn about deployment options and Windows Hello for Business Benefits go to the official documents.
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:windowssystem32Certlog -LogDirectory c:windowssystem32Certlog -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.
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.
Need to add the Azure AD Account to the KeyCredential Admins 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 FilesMicrosoft Azure Active Directory ConnectAdPrepAdSyncPrep.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 MFA for the Synced User. The set up gives an option to set up MFA which is used when the user sets up Hello for Business on other computers.
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:currentuserMy | fl
Get-ChildItem –Path Cert:LocalMachineMy | 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.
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 the smart card capture looks like
Well this is all I have for now. 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 Hybrid Certificate Trust.
-Chad
Useful Resources:
Windows Hello for Business https://docs.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/hello-identity-verification
Hybrid Azure AD joined Key Trust Deployment https://docs.microsoft.com/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