Implementing strong user authentication with Windows Hello for Business

[Editor’s note: This content was written to highlight a particular event or moment in time. Although that moment has passed, we’re republishing it here so you can see what our thinking and experience was like at the time.]

Deploying Windows Hello for Business internally here at Microsoft has significantly increased our security when our employees and vendors access our corporate resources. This feature offers a streamlined user sign-in experience—it replaces passwords with strong two-factor authentication by combining an enrolled device with a PIN or biometric user input for sign in. Windows Hello was easy to implement within our existing identity infrastructure and is compatible for use within our remote access solution.

The Windows Hello for Business feature can replace passwords with strong two-factor authentication that combines an enrolled device with a PIN or biometric (fingerprint or facial recognition) user input to sign in. We—the Microsoft Digital Employee Experience team—streamlined the deployment of this feature as an enterprise credential to improve our user sign-in experience and to increase the security of accessing corporate resources.

Using this feature, users can authenticate to a Microsoft account, an Active Directory account, or a Microsoft Azure Active Directory (Azure AD) account.

The Windows Hello for Business feature is a public key or certificate-based authentication approach that goes beyond passwords. This form of authentication relies on key pairs that can replace passwords and are resistant to breaches, thefts, and phishing.

Other benefits of this feature include:

It supports our Zero Trust security model. Emphasizes an identity-driven security solution by centering on securing user identity with strong authentication as well as eliminating passwords.
It uses existing infrastructure. We configured Windows Hello to support smart card–like scenarios by using a certificate-based deployment. Our security policies already enforced secure access to corporate resources with two-factor authentication, including smart cards and Microsoft Azure Multi-Factor Authentication. Windows Hello is currently enabled, and we anticipate an increase in usage as more biometric-capable devices become available in the market.
It uses a PIN. Replace passwords with a stronger authentication. Users can now sign in to a device using a PIN that could be backed by a trusted platform module (TPM) chip.
It provides easy certificate renewal. Certificate renewals automatically occur when a user signs in with their PIN before the lifetime threshold is reached.
It permits single sign on. After a user signs in with their PIN, the user has access to email, SharePoint sites, when using the latest Office 365 versions, and business applications without being asked for credentials again.
It is compatible with remote access. When using a certificate-based PIN, users can connect remotely using a Microsoft Digital Employee Experience VPN without the need for multi-factor authentication with phone verification.
It supports Windows Hello. If users have compatible biometric hardware, they can set up biometrics sign-in to swipe their finger or a take a quick look at the device camera.

Our deployment environment for the Windows Hello for Business feature include:

Server: Microsoft Azure AD subscription and Microsoft Azure AD Connect to extend on-premises directory to Azure AD:
- For certificate-based: Active Directory Certificate Services (AD CS), Active Directory Federation Services (AD FS) Network Device Enrollment Service (NDES), and Microsoft Intune
Client: A device, preferably with an initialized and owned TPM.

For more information about integrating on-premises identities with Microsoft Azure AD, see Integrating your on-premises identities with Microsoft Azure Active Directory.

For a transcript, please view the video on YouTube: https://www.youtube.com/watch?v=3k4Mduc9eUQ, select the “More actions” button (three dots icon) below the video, and then select “Show transcript.”

Dimitris Papitsis, Service Engineer for Inside Track, and Mike Stephens, Senior Program Manager, OS Security, share lessons learned when Inside Track deployed Windows Hello for Business on 100,000 Windows 10 devices over existing infrastructure, including Intune, System Center Configuration Manager, Public Key Infrastructure, and Azure Active Directory.

Enrollment and setup

Windows Hello for Business user enrollment steps vary, based on our deployed scenarios. For all scenarios, users will need to use their smart card or multi-factor authentication with a verification option—such as a phone call or verification on a mobile app, such as Microsoft Authenticator, in addition to their user name and password—to complete the enrollment.

The Windows Hello for Business feature supports the following enrollment scenarios:

On-premises Active Directory domain–joined devices. Users sign in with their domain account, the Group Policy is applied, the device is registered with Microsoft Azure Active Directory, and then the user creates a PIN.
Microsoft Azure AD–joined devices managed by Microsoft Intune. Users must enroll in device management (or add a work account) through Microsoft Intune. After their device is enrolled and the policies are applied, the PIN credential provisioning process begins and users receive the prompt to create their PIN.

Requirements

Two-factor authentication is required for PIN creation using one of the existing methods (virtual smart card, physical smart card, or multi-factor authentication with phone verification).
A PIN that is at least six characters long.
A connection to the internet or Microsoft corporate network.

Physical architecture

Our Windows domain-joined devices were already synchronized with Microsoft Azure AD through Microsoft Azure AD Connect, and we already had a public key infrastructure (PKI) in place. Already having PKI reduced the amount of change required in our environment to enable the Windows Hello for Business feature.

To deploy user certificates based on Windows Hello keys, we used AD FS, AD CS, and Group Policy.

Server roles and services

In our implementation, the following servers and roles work together to enable Windows Hello as a corporate credential:

Microsoft Azure AD subscription with Microsoft Azure Active Directory Device Registration Service to register devices with Azure Active Directory.
Microsoft Intune is used to enroll devices joined to Microsoft Azure Active Directory.
AD FS is used for federated identities and Microsoft Azure AD Application Proxy for secure remote access of web applications hosted on-premises. AD FS Registration Authority is used to handle certificate issuances and renewals for devices that are joined to the domain.
PKI includes NDES servers (with policy module) and certificate authorities (with smart card EKU—enhanced key usage—template), used for the issuance, renewal, and revocation of Windows Hello for Business certificates.

Domain-joined service workflow

The following workflow applies to any Windows 10 computers joined to our AD DS domain.

Our domain-joined devices pull a Group Policy object that configures certificate enrollment, PIN-enablement, and notification tasks.
After users sign out and sign in again, or if they select the pop-up notification when it displays, a PIN creation workflow runs, and they must configure their new PIN.
During the next sign-in, the user is prompted to configure Windows Hello for Business, confirm their identity using multifactor authentication, and create a PIN. A private key is created and registered in Microsoft Azure AD. The user can also initiate the Windows Hello setup process from the Settings app at any time.
- If the client and infrastructure support Instant-On, a key-receipt verification package is downloaded and a certificate request is sent to the AD FS registration authority. AD FS confirms valid key ownership and submits the request on behalf of the user to an AD CS certification authority.
The certificate is delivered to the computer.

Microsoft Azure Active Directory–joined service workflow

Windows Intune pushes a device policy to Microsoft Azure Active Directory devices that contains the URL of the NDES server and the challenge generated by Intune. A policy has already been pushed to the device by the Intune service. This policy contains the URL of the NDES server and the challenge generated by Intune.
During the next sign-in, the user is prompted to configure Windows Hello for Business, confirm their identity using multifactor authentication, and create a PIN. A private key is created and registered in Microsoft Azure AD. The user can also initiate the Windows Hello setup process from the Settings app at any time.
The device contacts the internet-facing NDES server using the URL from the NDES server and provides the challenge response. The NDES server validates the challenge with the CRP and receives a “true” or “false” to challenge verification.
- If the challenge response is “true,” the NDES server communicates with the certificate authority (CA) to get a certificate for the device. Appropriate ports need to be open between the NDES server and the CA for this to happen.
The NDES server delivers the certificate to the computer.

Setting policies

Our Microsoft Digital Employee Experience team used domain-based Group Policies to push out policy-based settings to configure our Windows 10 domain-joined devices to provision Windows Hello user credentials when users sign in to Windows. Non-domain joined devices receive their policies from Intune. We also used these settings to define the complexity and length of the PIN that our users generate at registration and to control whether Windows Hello was enabled.

We had the option to configure whether we would accept certificate-based Windows Hello for Business with PIN as a software-backed credential. We chose to enable Windows Hello for Business with a hardware-required option, which means that keys are generated on the TPM.

Policies for Microsoft Active Directory domain–joined clients

You must create and deploy a Group Policy object using the settings found under User Configuration > Administrative Templates > Windows Components Windows Hello for Business.

The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed. Both the Enable Windows Hello for Business setting and the Use certificate for on-premises authentication setting must be enabled.

Windows 10 also provides PIN complexity settings for control over PIN creation and management. Beginning with Windows 10 version 1703, the policy settings are found under Computer Configuration > Administrative Templates System > PIN Complexity.

Policies for Microsoft Azure Active Directory–joined clients

To use the Windows Hello/Windows Hello for Business certificate-based sign-in, configure the certificate profile (Assets & Compliance > Compliance Settings > Company Resource Access > Certificate Profiles). Select a template that has smart card sign-in extended key usage. Note that to set the minimum key size set, this certificate template should be configured in the Simple Certificate Enrollment Protocol (SCEP) Enrollment page—then you can use the Windows Hello for Business and Certificate Properties page to set the minimum key size set to 2048.

To set up the desired policy, we also need to create a new Windows Hello for Business profile (Assets & Compliance > Compliance Settings > Company Resource Access > Windows Hello for Business profiles) and specify the following required options:

Use Windows Hello for Business
Use a hardware security device
Use biometrics
PIN Complexity

User enrollment experience

When a domain-joined computer running Windows 10 Anniversary Update or later pulls Group Policy settings from a domain controller, certificate enrollment policies and the Windows Hello for Business policies are applied to the Windows 10 computer, provided all the criteria for policy application are met.

Client signs out and signs in (and unlocks) the device

The user unlocks their device, and the certificate enrollment process is triggered.

Certificate enrollment process

After a PIN is successfully created, the scheduled task runs (triggered by Event ID 300, which is “Key registration was successful.”). It checks for an existing certificate. If the user doesn’t have one, the task sends the requests for a new challenge.

At this point, Windows 10 calls on the specified Certificate Services server through AD FS and requests a challenge with an expiration time. If the PIN is cached, the certificate enrollment is triggered.

Certificate renewal behavior

We have configured PIN credential certificates to have a lifetime of 90 days from when they are issued. Renewals will happen approximately 30 days before they expire. When a user next enters their Windows Hello for Business PIN within the 30 days prior to its expiration, a new certificate will be automatically provisioned on their device.

Certificate renewal is governed by Group Policy settings for auto-enrollment. The system checks for certificate lifetime percentage and compares it against the renewal threshold. If it’s beyond the set threshold, a certificate renewal starts.

Microsoft Intune specifics

The Open Mobile Alliance Device Management client talks to the Microsoft Intune mobile device management server using SyncML. Policies are routed, and then the user receives the Simple Certificate Enrollment Protocol profile, as configured in our hybrid environment, deployed through Microsoft Intune. Within 10 minutes, the user should receive a certificate. If that fails, the user needs to manually sync.

Service management

We manage identity as a service at Microsoft and are responsible for deciding when to bring in new types of credentials and when to phase out others. When we were considering adding the Windows Hello for Business feature, we had to figure out how to introduce the new credential to our users, and to explain to them why they should use it.

Measuring service health

We’re in the process of creating end-to-end telemetry to measure the service health of Windows Hello for Business. For now, we’re monitoring the performance and status of all our servers. We’re also expanding the service, so adoption and usage numbers are very important metrics that demonstrate the success of our service. We also track the number and types of help desk issues that we see.

We use custom reports created from certificate servers and custom telemetry service metrics to collect prerequisites, and key and certificate issuance times for troubleshooting. Detailed reports about other aspects of the service can also be generated from Microsoft Intune.

We configure a user’s certificate to expire, and certificate renewals are issued with the same key. When necessary, the certificates can be revoked directly though Microsoft Intune, which provides easier administration.

TPM issues

OEM BIOS initialization instructions and TPM lockout policies are OEM-specific. We performed steps to identify and document the potential issues for each hardware provider. We also communicated to our users that clearing a TPM will cause their private key to not work in Windows Hello for Business.

Preventing PIN enrollment problems

Some of the common issues we saw with users creating their PINs could have been avoided with better communication. These issues include users not understanding the prerequisites, or the expected delays in onboarding scenarios. To help avoid this issue, we created a productivity guide to walk users through the steps.

Monitoring end-to-end service health

Windows Hello for Business relies on several underlying services: Microsoft Azure AD, AD FS, Microsoft Intune, NDES, and CA. All of these services need to be healthy and available. Certificate issuance delays can be hard to troubleshoot, but monitoring the health and performance of the supporting services can help.