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.
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.
This particular lab is great for a POC because it doesn’t require ADFS w/MFA Adapter.
AD Domain Name: hello.contoso.com
Azure AD Domain Name: hellodemo2.chadcolabs.us
- Hello-DC01 - Domain Controller / Certificate Authority - Windows Server 2016
- Hello-APP1 - Azure AD Connect Server - Windows Server 2016
- Hello-Client - Windows 10 1709
Ran the following PowerShell Commands to set up Domain Controller, Forest and Certificate Services
- 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)
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
On Hello-APP1 Enable Device Registration
Verify the service connection point was created in Active Directory
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.
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.
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.
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
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
Azure AD Connect at this time was 1.1.654.0
Public Key Cryptography for Initial Authentication (PKINIT) in Kerberos Protocol