Introduction
About 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® Trust Lifecycle Manager 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.
How DigiCert Contributes in Windows Hello for Business
Windows Hello for Business depends on multiple technology stacks, but Public Key Infrastructure (PKI) is one of its many foundations. DigiCert® Trust Lifecycle Manager 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.
The following table shows the type of certificates required by Windows Hello for Business.
Certificate Type | Required By | Description |
|---|---|---|
Domain Controller | Domain | 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® Trust Lifecycle Manager | Autoenrollment Server deployment guide for details. For public server certificate, please contact our sales representative. |
The above table only covers certificates required by Hybrid Azure AD joined Certificate Trust Deployment model which DigiCert supports currently. See below, “Supported Deployment Model and Trust Type” for more details.
The below sections describe how they are used and issued in more detail.
Windows Hello for Business Authentication Process
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 requests signed by this private key.
 |
The above diagram shows the authentication process using Windows Hello for Business. After the 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.
Primary Refresh Token (PRT) and Azure AD
Additionally, when the user authenticates with the Domain Controller, it is required that the server has the correct DC certificate. This is because the user also checks if the Domain Controller can be trusted.
For more details about the authentication sequence, check the following link.
Windows Hello for Business Certificate Issuance Process
The 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 the user requests the certificate through AD FS. AD FS authenticates the user and also signs the CSR (Certificate Signing Request) sent by the 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 the 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 the 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.