This document describes the installation and configuration steps for enabling certificate issuance through the DigiCert Autoenrollment server for Windows Hello® for Business.
Windows Hello® for Business, a feature by Microsoft® starting from Windows 10, introduced password replacement with strong two-factor authentication, consisting of a new type of user credential bound to a device and accessed using a biometric or PIN. DigiCert now has an offering to issue certificates from the DigiCert PKI Platform hosted Certificate Authorities for this new user credential.
For a detailed overview of Windows Hello for Business, please refer to the official Microsoft documentation: Windows Hello for Business Overview.
Windows Hello for Business depends on multiple technology stacks, but Public Key Infrastructure (PKI) is one of its many foundations. DigiCert PKI Platform can provide all certificates which are required to enable Windows Hello for Business through our Certificate Authority, and automatically provision them via our Autoenrollment Server.
Following table shows the type of certificates required by Windows Hello for Business.
|Certificate Type||Required By||Description|
Domain Controllers (DC)
|Certificate to install in DC to assure that the server is trusted.|
|Windows Hello for Business Authentication||End Users||Certificate used by end users to authenticate to Active Directory or Azure. This is used in the background after successful PIN or biometrics authentication.|
|Enrollment Agent||Active Directory Federation Services (AD FS)||Certificate used by AD FS to sign Windows Hello for Business Authentication certificate request sent from end users.|
|SSL/TLS Server||Active Directory Federation Services||Certificate to install in AD FS to assure that the service is trusted.
Installation for this type of certificate is not covered in this document, but you can issue private server certificate using Generic Server template. Refer to “DigiCert® Autoenrollment Server Deployment Guide” for details. For public server certificate, please contact our sales representative.
Below sections describe how they are used and issued in more details.
Windows Hello for Business enables users to use PIN or biometrics to authenticate. But PIN or biometrics are only used to access the private key stored in the device. They act as a key to open a box which stores the master key. The authentication with Active Directory and Azure solely relies on authentication request signed by this private key.
The above diagram shows the authentication process using Windows Hello for Business. After user has retrieved the Ticket Granting Ticket (TGT) and Primary Refresh Token (PRT), he/she can access any on-premise service with Kerberos Authentication using TGT and any Azure service using PRT. For more information about PRT and TGT, check the following links.
Additionally, when user authenticates with the Domain Controller, it is required that the server has the correct DC certificate. This is because the user also check if the Domain Controller can be trusted.
For more details about the authentication sequence, check the following link.
Following diagram shows how the Windows Hello for Business Authentication certificate is issued to the end user using DigiCert Certificate Authority using Autoenrollment Server.
You can see from the diagram that user requests certificate through AD FS. AD FS authenticates the user and also signs the CSR (Certificate Signing Request) sent by user. This is called “Enroll on Behalf of”, since AD FS enrolls for the certificate on behalf of the user. This process requires that AD FS has its own Enrollment Agent certificate, which is automatically issued to AD FS during this process if AD FS does not have an Enrollment Agent certificate.
The request is sent to Autoenrollment Server using CMC (Certificate Management over CMS), where Autoenrollment Server checks the signature of the request. If the signature is valid, Autoenrollment Server will call the DigiCert API to issue certificate. The issued certificate will be returned to AD FS, and AD FS will return it to the user.
The issuance process explained in this section is also part of a process called “Provisioning“ in Windows Hello for Business terms, where initial certificate issuance occurs after user has successfully authenticated to both Active Directory and Azure AD using credentials or MFA (Multi-Factor Authentication).
For more details about the certificate issuance sequence, check the following link.
When enabling Windows Hello for Business for your organization, you will need to decide which deployment model and trust type suit your organization. There are five different deployment model and trust type combinations:
Cloud Only Deployment
Hybrid Azure AD joined Certificate Trust Deployment
Hybrid Azure AD joined Key Trust Deployment
On-premises Certificate Trust Deployment
On-premises Key Trust Deployment
Check the official Microsoft documents, Planning a Windows Hello for Business Deployment and Windows Hello for Business Deployment Prerequisite Overview for full details about which model you should and can use.
You do not need to consider about Windows Server Certificate Authority stated in the Microsoft Prerequisite document, since it will be covered by DigiCert.
Currently, DigiCert supports the Hybrid Azure AD joined Certificate Trust Deployment model but planning to support additional certificate-based trust models. DigiCert will not support any of the two Key Trust Deployment models.
Following shows the steps required to set up a Windows Hello for Business solution for Hybrid Azure AD joined Certificate Trust Deployment. They are steps outlined in the official Microsoft deployment guides. The links for each step will take you to the official Microsoft documents.
You will need to complete all steps to 5-a. “Active Directory”, but in 3. “New Installation Baseline“, skip “Public Key Infrastructure” section. Also you can skip 5-b. “Public Key Infrastructure” and 5-c. “Active Directory Federation Services“, and finish 5-d. “Group Policy” first. This document replaces those sections, substituting Windows Server Certificate Authority with a DigiCert Certificate Authority.
When all the steps covered in this document are completed, you can move on to 6. “Sign-in and Provision”. If all the configurations are properly in place, provisioning should happen when user logs on to their Windows machine.
To enable Windows Hello for Business certificates to be issued from a DigiCert Certificate Authority, the DigiCert Autoenrollment Server is required to be installed and configured in your enterprise Windows domain. Follow the directions in “DigiCert® Autoenrollment Server Deployment Guide” which can be downloaded from DigiCert PKI Platform & Autoenrollment Server Deployment Guides to install and configure.
All steps from the document need to be completed, and it is recommended to first check if certificates can be issued using a Non-Windows Hello for Business Certificate Profile. The issuance process for Windows Hello for Business is complicated, and it will be easier to troubleshoot by ensuring that your Autoenrollment Server can issue certificates properly before configuring for the Windows Hello for Business solution.
The Windows Hello for Business solution can be provisioned where:
You will need to create three different certificate profiles from each certificate templates described below to enable Windows Hello for Business for your organization.
|Certificate Template Name||Description||
|Domain Controller for Windows Hello for Business||This profile issues certificates to Domain Controllers in your Active Directory domain. This certificate is used when users using Windows Hello for Business credentials try to authenticate to your Active Directory domain.||CSR
|Microsoft® Enrollment Agent||Enables organization to issue Microsoft® Enrollment Agent certificates which allows certificate enrollment on behalf of another entity in your Active Directory domains.||Microsoft® Autoenrollment|
|Windows Hello for Business Authentication||Enables organization to issue Windows Hello for Business certificates to users in your Active Directory domains.||Microsoft® Autoenrollment|
Screenshot shows the profile for “Domain Controller for Windows Hello for Business”
The “DigiCert® Autoenrollment Server Deployment Guide” (downloadable from DigiCert PKI Platform & Autoenrollment Server Deployment Guides) section “Creating Autoenrollment Certificate Profile” will guide you through on how to create certificate profiles for Autoenrollment Server. When selecting certificate template, make sure to select from one of the three templates described above.
After you create the profiles, make sure to note the Certificate Profile OID for two profiles created from following templates.
This information will be required later in section “Setting Up Active Directory Federation Services”.
This is required since Active Directory Federation Service will try to issue certificate from this profile every 12 hours for status check. If duplicate certificate is not allowed, status check will fail.
After you have successfully created the required three certificate profiles, you will need to download and import the Autoenrollment configuration file.
To do so, refer to the “DigiCert® Autoenrollment Server Deployment Guide” (downloadable from DigiCert PKI Platform & Autoenrollment Server Deployment Guides) section “Importing the Autoenrollment Configuration File”.
After you have imported the Autoenrollment configuration file into the Autoenrollment Server, you will need to assign access permissions to the imported templates. The required permission for each template is described below. Refer to the “DigiCert® Autoenrollment Server Deployment Guide” (downloadable from DigiCert PKI Platform & Autoenrollment Server Deployment Guides) section “About the Preparation of Certificate Templates” and “About the Assignment of Group/User Access to Templates“ for more details on how to configure them.
Certificate Template Name
Target Group or User
Required Access Permission
Domain Controller for Windows Hello for Business
Group which has all the Domain Controllers in your domain.
By default, Domain Controllers group should include all the domain controllers.
Check Read, Enroll, and Autoenroll.
Microsoft® Enrollment Agent
Group which includes the account user for AD FS, or specify the account directly.
If the account is a Service Account, following operation is required to show the Service Account objects:
Check Read, and Enroll. Autoenroll is not required. Certificate from this template will be issued to AD FS account user automatically as part of Windows Hello for Business flow.
Windows Hello for Business Authentication
This should be Windows Hello for Business Users group that was created during 5-a. “Active Directory” from the official Microsoft documentation. The name does not have to exactly match, but needs to be group of users that you are trying to assign Windows Hello authentication to.
Check Read, Enroll, and Autoenroll.
Issuing Domain Controller Certificates
There are different ways to issue Domain Controller certificates depending on the Enrollment Method chosen during the profile creation. Proceed to the appropriate section depending on the Enrollment method you have selected.
Issuing Domain Controller Certificates with CSR:
If you selected CSR as Enrollment Method, follow the steps in this section. These steps are completed on the Domain Computer where you are planning to issue the certificate to. The user who performs these steps must have administrator rights for the computer.
1. Create a text file named dccert.inf with following contents:
RequestType = PKCS10
ProviderName = "Microsoft Software Key Storage Provider"
Subject = "CN=<machine name>"
MachineKeySet = True
HashAlgorithm = SHA256
KeyAlgorithm = RSA
KeyLength = 2048
Exportable = <True|False>
SMIME = False
UseExistingKeySet = False
KeyUsage = 0xA0
Make sure to edit Subject and Exportable property appropriately. Save it to a temporary location.
2. From a command prompt, run the following command to generate the CSR in .pem format. The command outputs the CSR to the file dccert.req. You can run this utility from any location. However, unless you run it from the location where you saved the dccert.inf file, you must specify the path to this file.
certreq -new dccert.inf dccert.req
This command writes the dccert.req file to the directory where you ran the command. Specify the full path to a different location.
3. Copy the dccert.req file to the computer that has access to the DigiCert PKI Platform 8 Certificate Service. How to issue the certificate varies depending on which Authentication Method you chose for Domain Controller for Windows Hello for Business profile. Here, we will go through the steps using commonly used Manual approval method.
4. In PKI Manager, go to Manage users, and approve the request.
5. The certificate will be sent to the requestor. Copy the certificate from -----BEGIN CERTIFICATE----- to -----END CERTIFICATE----- and paste it into a file named dccert.pem in the Domain Controller.
6. Install the new certificate on the Domain Controller machine:
certreq -accept -machine dccert.pem
When successful, it should show the installed certificate as an output. Following shows an example:
> certreq -accept -machine dccert.pem
Serial Number: 6081c45c965e3877715d420a91d5af
Subject: OU=MULTI-ALLOWED, OU=DOMAIN-CONTROLLER, CN=w19-whfb-220 (DNS Name=w19-whfb-220.whfb.pkidev.bbtest.net)
NotBefore: 1/13/2023 4:00 PM
NotAfter: 1/14/2024 3:59 PM
Issuing Domain Controller Certificates with Microsoft® Autoenrollment
If you selected Microsoft® Autoenrollmentas Enrollment Method, follow the steps in this section.
After you have assigned access permissions to the Domain Controller template for the Domain Controllers, Domain Controller certificate will be issued automatically to the Domain Controllers. The timing depends on how the operating system handles them. To make sure that the certificate has been issued properly to the Domain Controllers, follow the direction below.
After certificate templates are imported and access permission is set, you will need to configure the Registration Authority templates to use for Windows Hello for Business with AD FS. This section covers the first part of “Active Directory Federation Services“ from the Microsoft official documentation, but provides little more information about what to specify for Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication template names when using DigiCert Autoenrollment Server.
To configure the Registration Authority:
After above configuration is completed, continue from “Group Memberships for the AD FS Service Account” in “Active Directory Federation Services“ from the Microsoft official documentation. Additionally, make sure that ‘ugs' scope is configured correctly as mentioned in the Note section of the document. This is extremely important since provisioning will not start without this ‘ugs’ scope properly configured.
This section will guide you on how to add User Principal Name (UPN) to Service Account. You will need to follow the direction here if your AD FS is configured to run using a Service Account. You can check whether AD FS is using Service Account by using the Services Tool (open Start Menu and type services). If Log On As for Active Directory Federation Services ends with '$' (dollar sign), this indicates that your AD FS is running using a Service Account.
UPN is required to identify the end entity of the issued certificate, but since Service Account does not have UPN by default, it is required that this information is filled out before issuing Enrollment Agent certificate to the Service Account.
To add UPN to Service Account:
After all configurations have been set and user logs on to their device, user should be prompted to provision Windows Hello for Business. Refer to “Sign-in and Provision” from the Microsoft official documentation for details.
Renewal of the certificate will occur in the background automatically when the certificate nears the expiration period. But for the certificate to renew, it requires that user to be logged in to the machine. If the user misses the renewal period for some reason, certificate will reach expiration.
During Windows Hello for Business Authentication certificate renewal, only the certificate information is updated (such as validity notBefore and notAfter) and asymmetric keys are not regenerated.
When the automatic renewal does not occur during the renewal period for some reason, certificate will expire. But users should be able to log on to their machine using the Windows Hello credential for the first time after certificate reaches the expiration. After successful login, the operating system will try to re-issue the certificate in the background. If the user logs out of the machine before this takes place, user will not be able to login using their Windows Hello credential, with screen like below.
User will need to login using Active Directory credential if this happens, but Windows Hello credential should be re-issued after sometime automatically after successful login.
During re-issuance, only the certificate information is updated (such as validity notBefore and notAfter) and asymmetric keys are not regenerated.
When Windows Hello for Business Authentication certificate is revoked, user will not be able to login using their Windows Hello credential, with screen like below.
The timing that OS identifies that the certificate is revoked depends on the update time of CRL or OCSP, so it may not be reflected immediately after the certificate is revoked.
User will need to reset Windows Hello credential by such method as using “I forgot my PIN” in the login screen. See below “Reset” for more details.
When user resets their Windows Hello credential such as using “I forgot my PIN” in the login screen, user will be re-provisioned and certificate will be issued again. Asymmetric keys will be regenerated and new certificate will be issued.
Refer to the following documents for troubleshooting.