Case scenario: You are activating Azure AD Domain Join or Azure AD Hybrid join for your clients. The setup requires your computer to be registered for Windows Hello for Business. You then log on to the device using PIN, and try to access a local resource, for instance by mapping a drive.
This fails every time with the following message:
The reason for this is that Windows Hello for Business has no trust between Active Directory and Azure AD. You need to establish trust by establishing a Hybrid Azure AD Joined trust.
This can be done in two ways, either Hybrid Azure AD Joined Key Trust Deployment or by Hybrid Azure AD Joined Certificate Trust Deployment. This guide will show you how to do it with the Key Trust method.
Why didn't we choose Certificate Trust? Because, while being able to deploy it on older DCs (Key Trust requires at least parity on Windows server 2016 DCs and older servers), we need some more infrastructure, such as NDES and ADFS servers. ADFS alone requires four servers in your environment.
Hybrid Azure AD Joined Key Trust Deployment
- Adequate number of Windows server 2016 DCs. This means you need at the very least 1 Windows 2016 DC
- Windows server 2012 Certificate Authority - CRL needs to be accessible by Azure AD (See info in setup)
- Azure AD Connect - Password Hash Synchronization or Passthrough-Authentication is required, or ADFS 2012++.
- Multifactor Auth - Azure MFA is enough here, 2016 ADFS if federated
- Device Registration with Azure Device Registration.
If you've come here looking for a solution it means you have most of what is required.
Step by step setup with pictures
Active Directory changes
- In Active Directory, go to the Users container - Create a group named "Windows Hello for Business users", add your WHfB users to this group. Or you could use a security group you already have with the users you want to enable WHfB on.
- Go back to the Users container, right-click on KeyAdmins and click on Properties
Click the Members-tab and click on Add, enter the name of your Azure AD connect service account, and click OK.
Certificate Authority changes
As mentioned in Pre-requisites, your certificate revocation list must be accessible from Azure AD. We will follow this guide from Scott Duffy and do it with Azure Application Proxy
By default ADCA provides and publishes a Kerberos Authentication certificate template. This default Kerberos Authentication template is based on older cryptography APIs. Specifically KDC authentication which has been added to the Kerberos RFC. We therefore need to create a new Kerberos Auth template.
- Open Certificate Authority management console
- Right-click on Certificate Templates and click on Manage
- Right-click on Kerberos Authentication template and click Duplicate Template
- On Compatibility, remove Show resulting changes. Select Windows Server 2012 (or R2) from the Certification Authority list. Do the same for the Certification Recipient list.
- On General, type Domain Controller Authentication (Kerberos) in the template display name. You can set your own validity and renewal period to your enterprise needs.
- On Subject, select Build from this Active Directory Information, select None from the Subject name format. Select DNS name from the Include this information in alternate subject list. Clear everything else.
- On Cryptography, select Key Storage Provider. Selct RSA, type 2048 on key size, and select SHA256 in hashes.
- Click OK
Now we need to supersede the new template on the CA.
- Go back to the Certificate Template Console, right click the Domain Controller Authentication (Kerberos) template we just created, and click on Properties.
- Click on Superseded Templates, and click on Add
- Add the Domain Controller certificate template
- Add the Domain Controller Authentication certificate template
- Add the Kerberos Authentication certification template
- Add any other enterprise certificate templates that were previously configured for the DC's
- Click OK
- Publish the certificate templates, if you have more than one CA publish to all.
AD is unaware that we have updated the templates on the CA, we need to create a group policy for automatic certificate enrollment, and enable "Windows Hello for Business" policy for your users.
- Open Group Policy Management Console
- Expand the domain and select Group Policy Object, right click and select New
- Write "Domain Controller Auto Certificate Enrollment" and click OK
- Edit the new object above, expand Policies under Computer Configuration
- Expand Windows settings > Security Settings and click on Public Key Policies
- In details, right-click on Certificates Services Client - Auto Enrollment and select Properties
- Select Enabled from the Configuration Model list.
- Select Renew expired certificates, update pending certificates, and remove revoked certificate
- Select the Update certificates that use certificate templates check-box and click OK
Deploy the GPO on the Domain Controllers OU and click Link an existing GPO, select the newly created GPO (Domain Controller Auto Certificate Enrollment) and click OK
- We need to create a new GPO, download .AMDX and .ADML or use a Windows 10 1703 edition
- Create a new GPO - Enable Windows Hello for Business
- Expand Policies under User Configuration, go to Administrative Templates > Windows Component and select Windows Hello for Business - Click OK
Deploy the GPO
- Deploy the WHfB GPO to the respective security group by double clicking on the GPO.
- In Security Filtering click Add and type the security group (We created the Windows Hello for Business Users previously). Click Delegation > Authenticated Users > Advanced.
- In the Group or User names list, select Authenticated Users. In the Permissions for Authenticated Users, clear the Allow check-box for the Apply Group Policy Permission. Click OK.
Deploy the GPO on the Domain Controllers OU and click Link an existing GPO, select the newly created GPO (Windows Hello for Business) and click OK
That's it! You're done. Please be aware that the minimum time needed to synchronize the user's public ky from Azure AD to OnPrem is 30 minutes.