Windows Hello for Business (WHfB) is an awesome Microsoft technology that replaces traditional passwords with PIN and/or Biometrics and linked with a cryptographic certificate key pair. This is set up by default as part of the Out of Box Experience with Windows 10. These certificates grant single sign-on access to legacy Active Directory resources. There are a number of other benefits of why a PIN is more secure than passwords as well and I would encourage you to read more about it on Microsoft’s documentation.

WHfB not only provides a more secure way to sign in to Windows, but it enables cloud-joined Azure Active Directory (AAD) devices to access resources on the domain. For many organizations adopting modern deployment technologies like Autopilot, AAD-joined PCs (also called cloud-joined) aren’t joined to the on-premise domain. Accessing a file share, for example, would not be possible without constantly prompting the user for username and password. With WHfB, however, Windows 10 clients are now able to generate a Kerberos ticket and they now act almost like they are joined to the domain. Users will be able to access file shares, printer shares, and other resources that leverage Kerberos authentication without any prompts at all. Nice!

WHfB is relatively simple to set up but it does have quite a few pre-requisites that must be met in order for it to function properly. In this blog, I’ll be going over which type of WHfB deployment is best, all the prereqs associated, and then walking step-by-step on setting this up in your lab or production environment. Let’s begin!

What is the difference between Windows Hello and Windows Hello for Business?

You are probably familiar with Windows Hello by setting it up on your home PC. It allows you to log in to your PC with an easier PIN and/or Biometric login. For most people, this is just a convenience; it doesn’t do anything beyond that. Windows Hello for Business, on the other hand, takes that same convenience but adds an additional layer of security on top. It not only makes it simpler for end-users to log into their corporate PC, but it also provides a secure way to access corporate resources on the domain.

Additionally, we can also control WHfB with GPO or MDM policies and tools like Microsoft Endpoint Manager or VMware Workspace ONE.

Two Methods

Microsoft has implemented two different methods for Hello For Business: Cert-Trust and Key-Trust. Key-Trust is the default and is the easiest to set up. It leverages the built-in Azure AD certificate that gets deployed each time a device joins Azure AD through the Out of Box Experience (OOBE). The private key of this certificate gets saved in the Microsoft Passport for Work store and the public key gets synced to Azure AD. AAD then syncs it back to on-premises Active Directory and saves it to a user attribute called msDS-KeyCredentialLink.

Cert-Trust on the other hand, adds an additional device registration step to the process. When the device goes through OOBE, it must talk to Active Directory Federation Services (ADFS) which then registers the device to on-premise AD. This device object is then written up to Azure AD (called “Device Writeback” in Azure AD Connect). After this happens, the user certificate, which is deployed from your own Active Directory Certificate Server instead of Azure AD, is then paired up with the device. This method uses both Device + User trust whereas the Key-Trust is only at the user level (no device registration required).

Which method should I pick?

Key-Trust is the default method and is the method I recommend. It is much simpler to implement and doesn’t require any additional infrastructure or services. Cert-Trust requires ADFS and thus adds a significant layer of complexity. Consult your Microsoft resource if you are unsure of which method to choose.

I’ll be demonstrating the Key-Trust method. Even though these steps will all be done in a lab environment, you should be able to easily replicate these to a UAT or Production environment at your organization.

PreReqs and Assumptions

Here are the following prereqs and assumptions we’ll need before we get started. You’ll need to complete these or be ready for them before continuing.

1. Active Directory Domain Services installed on a Domain Controller running Windows Server 2016 or newer.
   1. Ensure Active Directory Schema is 2016 or higher.
2. Active Directory Certificate Services (ADCS) 2012 or newer. You can also use third-party certificate services, but I won’t be showing that here.
   • A certificate revocation list (CRL) that is accessible via HTTP. Ideally this should also be accessible on the internet.
   • Resolvable DNS for the CRL on the client.
   • A new Kerberos Authentication Template will be generated and must be installed on Domain Controllers (overwriting the previous one).
3. Azure AD Connect Setup, configured, and syncing users from on-premise AD into AAD.
4. Azure AD Premium P1 or P2 licensing or equivalent.
5. Domain Controller Root Certificate deployed to clients.

One final note: Microsoft refers to this implementation as “Hybrid Key-Trust”. This just refers to the back-end architecture of having both on-premise Active Directory syncing into Azure AD via AAD connect. It does not mean the Windows 10 client is actually hybrid-joined to on-premise AD plus AAD. You can view the full list MS list of prereqs here.

Quick Checklist

Before we get in too deep, here is a quick reference on the steps we’ll be going through to set up Windows Hello for Business using the Key Trust method.

Verify the AAD Connect Service Account Permissions

First, you will need to ensure the service account used by AAD Connect has the correct permissions to update the msDS-KeyCredentialLink attribute on the user object. If you aren’t sure what service account is being used, here is how you check:

1. Log in to the Azure AD Connect service and double-click on the Azure AD Connect icon on the desktop.
2. Once the Azure AD connect wizard application launches, click on “View or Export Current Configuration” and click Next.

3. Under Synchronized Directories, you will see the account used.

In my case, my account name is MSOL_1e05d7a78947.

Now, add this account into the KeyAdmins security group in Active Directory. This group provides the correct level of permissions needed to read and write the public key to Active Directory.

Close the Azure AD Connect wizard and perform delta sync on AAD connect after you make this change. You can do this by running the following PowerShell command from the Azure AD Connect server:

Start-ADSyncSyncCycle -PolicyType Delta

For more information on this topic, see the Microsoft documentation. Now that we have that taken care of, let’s move onto certs.

Setup CRL Distribution Point (CDP) accessible from the web

Clients will need the ability to query the certificate revocation list (CRL) in order for the authentication to happen. This may seem odd since we are not using the cert trust method, but remember that certificates are still used in the key-trust method. The domain controller is still doing authentication based on the trust between the key pair. It also needs to check to see if any domain-level certificates are revoked, including the root CA.

This CRL needs to be accessible via HTTP (not HTTPS) and ideally internet facing. Since this is primarily used to access on-premises resources you technically don’t have to make this internet-facing. Clients will need to be on the VPN in order to access internal file shares and thus will have access to an internally based CRL. However, it is best practice to put these on the internet. This may already be set up in your organization, but in case it’s not or you want to follow along in a lab here are the high-level steps:

1. Setup an web server using IIS that has a fileshare configured. You will add this as a virtual directory in IIS. The Certificate Authority will publish the CRL there and that is also where clients will check. This will be your CPD or “Certificate Distribution Point.
2. Create a CNAME record in DNS for that server which will house the CRL (i.e. pki.brookspeppin.local)
3. Update the CA template to use this HTTP location for CRL
4. Deploy (or re-deploy) your domain controller certificate as well as export the root certificate for installation on client machines.

MS has good documentation on how to properly set up a full web-based CRL and we’ll generally be following these steps.

Setup CRL Share

I’m putting the Certificate Distribution Point (CPD) on the same server as my CA, but it’s not required. Any web server will do as long as the CA has write access to it in order to create the CRL files.

1. Create a folder on the C drive where the CRL will reside. I’m calling mine C:\CRL
2. Right click the folder, then Properties, then Sharing tab, then Advanced Sharing. 
3. Click Share this folder and name it. Add $ to the end if you want to make it hidden from normal file browsing.
4. Then click Permissions.  Ensure Everyone has “Read” permissions 

5. Then click on Add and we will need to add the CA computer object to this.
6. Click on Object Types and ensure ​”Computers” box is checked.
   

7. Search for the computer name and it should resolve. Click OK and ensure the it has Full Control. In my lab, my CA is on my Domain Controller, DC01.
   

8. Click Apply and OK on Advanced Sharing.
9. On the security tab for your share (C:\CRL), repeat the same process giving the computer object modify permissions

10. Finally, click Add and type ANONYMOUS LOGON; Everyone

11. Click ok. This allows anonymous access so that any clients can check the CRL.
12. Do a quick test by browsing to that share. It should resolve and be empty.
    

Configure IIS for HTTP CRL Location

Now that we have finished setting up our CDP, we need to configure IIS by adding it as a virtual directory.

1. Load the IIS console
2. In navigation tree, expand it and browse to your Default Web Site. Right click it and click Add Virtual Directory.​
   

3. Under Alias, type what you want your web URL to contain. I’ve just named it “CRL”. Also, browse for the CRL folder and select it. Click OK ​to close.

4. On the left hand navigation tree, select the new folder (named “CRL”). Double-click on the Directory Browsing icon.

5. Click Enable on the right hand side.

6. Go back one screen and then double-click on the Configuration Editor icon.

6. In the drop down list, type or search for system.webServer/security/requestFiltering
7. Change allowDoubleEscaping to be ​True. Then click Apply.  This is required in order for the client to download a CRL delta file which has a ‘+’ symbol in it.

8. Click on Default Web Site and then under Manage Website on the right click Restart.

9. Load up a web browser and ensure you can get to your new website: http://dc01/crl

Now this resolves because I’m doing it on the same box, but it won’t be accessible by clients until we set up DNS. We’ll do that next.

Setup DNS for the CRL

DNS may already be set up in your environment for the IIS server we just created, but if you still need to do it, follow these steps. I’ll be using Active Directory integrated DNS and setting up an alias for this called “PKI”.

1. Launch the DNS Manager mmc.
2. Expand the tree under Server > Forward Lookup Zones. Right-click the forward lookup zone where you want to add the Alias resource record, and then click New Alias (CNAME).

2. In Alias name, type the alias name you would like. I’ll be using “pki”.
3. In Fully qualified domain name (FQDN) for target host, type the FQDN of the IIS web server. Since I put it on my DC in my lab, the FQDN is “dc01.brookspeppin.local”.

3. Click OK to save.
4. Type in the new alias URL to ensure it resolves (Make sure it’s http:// not https://)

You can reference the Microsoft Docs for more info. Now that we have this complete, we will move onto configuring a few things on the certificate authority.

Configure CDP and AIA on the Microsoft Certificate Authority

We need to add the CDP URL to the CA itself.

1. Log in to the CA if you are not already there.
2. Search for and launch certsrv.mmc. Right click the CA name and click Properties.

1. Click the Extensions tab. In the dropdown for “Select extension”, ensure you have CRL Distribution Point (CDP) selected. Before you make changes here, take a screenshot of this in case you need to revert. In the Specify locations from which users can obtain a certificate revocation list (CRL) section, remove the following enteries:
   • Entry starting with “file://\\<ServerDNSName>…”
   • Entry starting with “http://<ServerDNSName>…”
   • Entry starting with “ldap:///CN=<CATruncatedName>…”
     You should only have one left starting with “C:\Windows\System32\CertServer…”
2. Now we need to add our new CDP URL that we configured earlier.
3. Click Add.
4. In Add Location, in Location, type http://[yourDNSname]/[folder]/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl
   So in my case I put “http://pki.brookspeppin.local/crl/<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl”. Update yours accordinly. The items in between the <> are variables and when the CRLs are generated they will be populated with real data. Click OK to save.

5. At the bottom, ensure the following boxes are selected:
   • Include in CRLs. Clients use this to find the Delta CRL locations
   • Include in the CDP extension of issued certificates

6. Click Add again.
7. in Location, type 
   file://\\[dnsname]\[folder]\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl, (be sure to replace the value in teh brackets with your own server info). I.e. “file://\\pki.brookspeppin.local\crl$\<CaName><CRLNameSuffix><DeltaCRLAllowed>.crl” (note that I have a $ at the end since I set this up as a hiddens share)
8. Click OK. This returns you to the CA properties dialog box.
9. At the bottom, select the following check boxes:
   • Publish CRLs to this location
   • Publish Delta CRLs to this location

6. Change the dropdown from “Select extension” to Authority Information Access (AIA)
7. Repeate what you did earlier by removing the three entries:
   • Entry starting with “file://\\<ServerDNSName>…”
   • Entry starting with “http://<ServerDNSName>…”
   • Entry starting with “ldap:///CN=<CATruncatedName>…”
8. Click Add.
9. In the Location box type: http://[dnsname]/[folder]/<ServerDNSName>_<CaName><CertificateName>.crt, and then click OK. So for me this would be: “http://pki.brookspeppin.local/crl/<ServerDNSName>_<CaName><CertificateName>.crt”. Click OK to save.

6. At the bottom, check the box Include in the AIA of issued certificates.

6. Click OK to save all of these changes. You will be prompted to restart Active Directory Certificate Services. You can click No as we will be restarting the service later.

You can reference the Microsoft Docs for more info. Next, let’s move on to publishing the cert revocation list.

Publish the cert revocation list

1. Restart your CA service from certsrv.mmc by right-clicking your CA server name, All Tasks > Stop Service. Then Start the service again.

2. Right click Revoked Certificates > All Tasks > Publish
   

3. Select New CRL and click OK.

NOTE: If you are doing all of this on the same server such as in a lab environment (DC, CA, DNS, etc) you may run into this error:

This either means the configuration on the Extensions tab is incorrect or because of a loopback problem. In my case, I had to disable loopback check on the DC. You can disable loopback by running the following PowerShell command:

New-ItemProperty HKLM:\System\CurrentControlSet\Control\Lsa -Name "DisableLoopbackCheck" -value "1" -PropertyType "DWORD"

4. Re-publish the CRL and the error should be gone.
5. Browse to your CDP and ensure the two CRL files are there:
   1. One ending in .crl (primary CRL)
   2. One ending in +.crl (delta CRL)
6. Additionally, we will need to copy the CA certificate to this location as well. You can run this command (update it with your target URL)

copy C:\Windows\system32\certsrv\certenroll\*.crt \\pki.brookspeppin.local\crl$

A cert ending in .crt will be copied to your CDP. Once complete it should look like this:

7. Finally, load pkiview.msc to verify everything is good

OK you’ve made it this far. Great job! We’re in the home stretch — only a few more things to configure.

Create a New Domain Controller Authentication (Kerberos) Certificate Template

Active Directory Schema 2016 adds some additional attributes in order to support the key-trust authentication used with Hello for Business. We will need to create an updated template and then issue them to the domain controllers. This new template will replace and supersede the old ones. Nothing is getting removed, we are just added additional authentication purposes to it (namely KDC and Smart Card Logon).

1. On the CA server, open the Certificate Authority management console (certsrv.mmc)
2. Right-click Certificate Templates and click Manage.
   

3. In the Certificate Template Console, right-click the Kerberos Authentication template in the details pane and click Duplicate Template.
   

4. On the Compatibility tab, clear the “Show resulting changes” check box. Select Windows Server 2008 R2 from the Certification Authority list. Select Windows 7 / Server 2008 R2 from the Certification Recipient list.
   

5. On the General tab, type Domain Controller Authentication (Kerberos) in Template display name. Adjust the validity and renewal period as needed.
   

6. On the Subject Name tab, select the Build from this Active Directory information button if it is not already selected. Select None from the Subject name format list. Select DNS name from the Include this information in alternate subject list.

7. On the Cryptography tab, configure the following:
   • Provider Category: Key Storage Provider
   • Algorithm name: RSA
   • Minimum key size: 2048
   • Request Hash: SHA256
   • Click Apply.

Supercede Old templates

Now we need to supersede the older templates so that this new one gets automatically applied.

1. In the Domain Contoller Authentication (Kerberos) template, click the Superseded Templates tab.
2. Click Add.
3. Select Domain Controller and Domain Controller Authentication (hold shift to multi-select) certificate templates and click OK.
   

4. There should be three listed in the superseded list:
   • Domain Controller
   • Domain Controller Authentication
   • Kerberos Authentication
5. Click Apply and OK.
6. Close the Certificate Templates Console

You can read the Microsft Docs for additional information. Next, we need to publish this template so that it can be issued to Domain Controllers.

Publish the Template

1. In the Certificate Authority management console (certsrv.mmc), right-click the Certificate Templates node. Click New, and click Certificate Template to issue.
   

2. In the Enable Certificates Templates window, select the Domain Controller Authentication (Kerberos) template you created in the previous steps. Click OK to publish the selected certificate templates to the certificate authority.
   

3. It’s a good idea to unpublish the old, superceded templates. Select both the Domain Contoller and Domain Controller Authentication templates, right click and delete. Only the new “Domain Controller Authentication (Kerberos)” template should remain. The other templates in the list unrelated to this can also remain.

Now let’s deploy these to our domain controllers. You’ll want to do this on every domain controller.

Deploy new certificate to Domain Controller

You have two options here: manually deploy to each DC or configure group policy for automatic certificate enrollment. I’ll show you how to do it manually but in production, you’ll probably want to set up the GPO since you’ll have way more than one or two. To set up the GPO, follow the Microsoft docs here

Manual Steps

1. Login to the DC and open the Local Computer cert store on the DC
2. Expand Personal > Certificates. Right click the Certificates folder then All Tasks > Request new Certificate
   

3. Click Next in the window
4. Select Active Directory Enrollment Policy and Click Next.

5. Select Domain Controller Authenticate (Kerberos). You may need to select “show all templates” for it to appear. Then click Enroll.
   

6. You should see the new cert deployed and it should have “KDC Authentication” and “Smart Card Logon” added to it under the intended purposes column

6. Select the older cert (the one that says just “Client Authentication, Server Authentication”) and delete it.
7. Double click the newly issued cert to open it
8. Click on Details tab
9. Scroll down to CRL Distribution Points and ensure that it has the correct CRL information (it should show your http location)
   

The last step in the process is to ensure the Root CA is installed on the Windows 10 client machines. This will enable them to trust the DCs when making authentication requests.

Install ROOT CA on clients

Successful Connection

The easiest way to do this is to export the root certificate from the DC itself.

Export Root CA From DC

1. In the certificates store, expand the “Trusted Root Certificate Authorities” node on the left and click on Certificates.
2. Select the root certificate for you domain.

3. Right click it > All Tasks > Export

4. On the Export File Format, select DER encoded binary x.509 (.CER).

4. Click next, name the file and finish the wizard to save the file.

Install Root CA on Client

For now, we will just install this manually on the client. Once you have validated the full Windows Hello for Business process, you will want to deploy this certificate automatically with a management tool such as MEM or Workspace ONE. For Workspace ONE, you can check out this video on how to deploy certs. You will want to ensure this certificate comes down automatically during the Out of Box Experience

1. On the Windows 10 client, ensure you have fully completed the Out of Box Experience and enrolled into Windows Hello for Business.
2. Copy the Root Certificate to the client, such as the desktop.
3. Right-click the cert and click Install Certificate.
4. In the Certificate Import Wizard screen, select Local Machine as the Store Location.

5. Click Next and the Yes if prompted by UAC.
6. Select Place all certificates in the following store. Click Browse and select Trusted Root Certification Authorities. Click Next and Finish to complete the wizard.

7. Load up the certificate store on the client and ensure it got successfully installed

How to Check for Successful Hello

First, ensure that you have successfully registered for Hello for Business by setting up your PIN and completing Azure MFA.

After you complete these screens, Windows Hello for Business is successfully initialized. Let’s check to see if the key is successfully registered to Azure AD.

Check for Successful Key Registration

1. Open Event Viewer
2. Expand Applications and Services Logs > Microsoft > Windows. Navigate to User Device Registration. Click on Admin to view the log.
3. Look for a record with Event ID 300. You should see a “The Microsft Passport key was successfully registered with Azure AD”. This indicates that the public key was sent to Azure and AAD connect will then attempt to sync it back to on-premises Active Directory.

NOTE: The AAD Connect process, by default, is a sync every 30 min. Your organization may have changed this sync policy and so it may take longer. If you attempt to authenticate to on-premises resources such as a file share before the sync happens, you will probably see this popup:

Don’t type your username and password as that will NOT use Windows Hello for Business. Wait until the key has synchronized to AD. You can speed up the process by running a delta sync on AAD connect (see earlier in this article for the command)

Check for msDS-KeyCredentialLink

You will want to validate that the user object in Active Directory has the msDS-KeyCredentialLink attribute available and that it is populated with the key. There are a couple of ways to do this.

Check via ADUC

1. Open Active Directory Users and Computers
2. Click View > Advanced Features
3. Find the user object
4. Click on Member Of tab. Double-click one of the groups to bring up the group membership page (doesn’t matter which group).
5. While this is open, close the user properties page.
6. Go back to the group properties page and click on the Members tab.
7. Find the user and double click it.
8. The attribute editor tab should be visible now. Click Attribute Editor Tab
9. Scroll down and find the msDS-KeyCredentialLink value. It should be populated with the public key of the hello for business certificate. The private key is saved on the device in the Windows Passport store.

Check via PowerShell

An easier and quicker method is to use PowerShell. You must have the Active Directory PowerShell Module installed for this to work.

get-aduser bpeppin -Properties msDS-KeyCredentialLink

If this is empty, you will need to wait until the synchronization has been completed on AAD Connect.

Additionally, the user can have more than one entry here as well. Each time they go through the Out of Box experience and set up WHfB, a new key pair will be generated and synced back to AD.

A Successful Attempt

Once both of these things are completed, an authentication request to an on-premises file share should go through automatically without any prompting! Pretty slick. Also, if you run klist from the command prompt you will also see that a Kerberos ticket has been granted by the domain controller.

Check it out below!

Troubleshooting

If you followed this guide extremely close and were able to get this working on the first try, congratulations! You are awesome. However, due to the number of little things that need to be in place for this to work, there’s a good chance you have probably overlooked something. Since this blog is already so long, you’ll need to check out my troubleshooting Hello for Business blog for more details.

Conclusion

Wow, you made it! Well done on getting to the end. Now you know how to set up Windows Hello for Business and you should be proud. If you have been successful, let me know if the comments below! In my opinion, this is one of the coolest technologies that Microsoft has developed and is a must-have when doing Out of Box Experience. Enjoy using your PIN to access file shares.