Deploying Windows Hello for Business

• Author
• Recent Posts

Paul Schnackenburg

Paul Schnackenburg works part time as an IT teacher as well as running his own business in Australia. He has MCSE, MCT, MCTS and MCITP certifications. Follow his blog TellITasITis.

Latest posts by Paul Schnackenburg (see all)

• Azure Sentinel—A real-world example - Tue, Oct 12 2021
• Deploying Windows Hello for Business - Wed, Aug 4 2021
• Azure Purview: Data governance for on-premises, multicloud, and SaaS data - Wed, Feb 17 2021

This won't offer complete coverage of all Windows Hello for Business options, as there are quite a few paths you can take, depending on your starting environment. Instead, I'll share my learnings from this particular deployment.

A few words about the client—they're an independent school with approximately 90 students in grades 1–12 and about 20 staff. They use Microsoft 365 A3 (equivalent to commercial E3), Microsoft Endpoint Manager, and Windows 10 across all devices.

The device fleet comprises 13 Surface Book devices for teachers, 16 Surface Pros for senior students, and just over 50 Dell laptops (not Windows Hello for Business-capable) for the rest of the students, plus a smattering of Dell desktop PCs for admin staff. Server infrastructure is a R440 Dell Server, running Windows Server 2019 Hyper-V and seven VMs: two domain controllers, a file/print server, a LOB application, a WSUS server, Microsoft's Advanced Threat Analytics (ATA), and a Linux Syslog server.

There's also an older Dell server that's the Hyper-V replica target for all VMs, located in a different building on campus. Each of the six buildings has a managed switch, which is connected with fiber optic cabling to the others. Each of these has a NetGear Wi-Fi access point in an ensemble, providing roaming indoor network access. Active Directory synchs user and computer accounts to Azure AD using AAD Connect.

Windows Hello vs. Windows Hello for Business

I've used Windows Hello for Business on every device since my first Surface Book, and it's incredibly convenient. Most times I'm signed in before I've even sat down in the chair to start working. Setup is also quite quick: a few scans of your face (with and without glasses) and you're good to go.

While Windows Hello for Business uses the same underlying technology, it’s quite a different beast. When the school decided to purchase Surface Books and later Surface Pros, I mentioned how great I found Windows Hello and said, "You can do this too." IT consultant mistake number one: don't promise until you've checked the prerequisites 😊.

Deployment prerequisites

Taking Windows Hello to Active Directory and using it on domain-joined PCs is a lot more complex than on consumer devices. When this first was discussed with the client, they were still running Windows Server 2008 R2 DCs, so that was the first hurdle—now their DCs are Windows Server 2019. Other requirements are Windows 10 1709 or later, either AD and AAD joined (hybrid) or AAD joined, Windows Server 2016 or later DCs (you can use 2008 R2/2012 but only with certificate trust—see below), with a Windows Server 2016 schema.

Windows Hello for Business isn't just biometrics but an umbrella term for various stronger authentication methods, and you always have the option of falling back to a PIN that's unique to that device, unlike a username/password pair.

As mentioned, there are a few paths to take in the quest toward Windows Hello for Business nirvana. Your first decision is between key-based and certificate-based authentication. The former is easier to deploy but doesn't support Remote Desktop connections; the latter requires a public key infrastructure (PKI) for certificate deployment, which might fit right in if your business already has that deployed but raises the bar if you don't. Note that even if you opt for key-based, you'll still need a minimal PKI/AD Certificate Services (AD CS) service to deploy updated certificates to your DCs.

A second decision is whether you're going to do a cloud-only deployment (Windows 10, AAD, Azure AD MFA only) or a hybrid deployment. For hybrid, you can do certificate trust and mixed managed, key trust and modern managed, or certificate trust modern managed, where "modern" means MDM (Intune/Endpoint Manager) enrolled. There is also an on-premises-only deployment path.

Microsoft provides a map for your quest in the form of a planning worksheet. Go through each question regarding your current environment in conjunction with the planning guide to gain insight into which options you have for your Windows Hello for Business deployment.

Here's my resulting worksheet. We went with a hybrid deployment with key trust and Endpoint Manager. I automatically joined the client PCs to Azure AD using a GPO.

Windows Hello for Business Planning Worksheet

Another wrinkle is whether you're still running AD Federation Services (AD FS; this client is not), which needs to be considered in your planning. As an aside, given that the SolarWinds attacks used AD FS, and Microsoft has been recommending migrating from AD FS to AAD for your federation needs, start your migration journey now if you have AD FS.

Once all devices were joined to AAD, I was ready to proceed. The documentation has clearly laid out steps, which in my case involved:

1. Checking prerequisites—AD, AAD directories, and PKI will need to be deployed for DC certificates (see below)
2. Deploying AD CS and configuring it
3. Configuring directory synchronization
4. Configuring Azure device registration
5. Configuring Windows Hello for Business settings
6. Signing in and provisioning

Certificate services

If you're deploying AD CS in a large business with strict security requirements, be aware that there are many steps involved in planning such a deployment. One path is creating a root certificate server on a workgroup server (so that it doesn't lose trust with the domain when it's offline for extended periods of time), which deploys leaf certificate servers and is then shut down and locked away in a vault. This is beyond what this client needs, and I simply deployed CS on one of the DCs.

Setting up AD CS

By default, the AD CA publishes a Kerberos Authentication certificate template, but it uses older and less performant crypto APIs; hence, the documentation guided me through creating a new template with updated settings such as the RSA algorithm with 20148 minimum key size. This template is then configured to supersede the older ones and published, while the older certificate templates are deleted.

Configuring the certificate template

AAD device registration

Since AAD Connect is already running at this client, it was simply a matter of configuring it. There's a Service Connection Point (SCP) required but since we're running an up-to-date version of AAD Connect, it was already in place.

I checked a random sample of devices in Devices for their join status in the AAD portal as well as on the devices themselves. You can use either dsregcmd /status in a command window or Get-MSolDevice in PowerShell.

Configuring Windows Hello for Business settings

After what felt like an eternity of planning, checking prerequisites, and configuring the infrastructure itself, I could now configure the single GPO setting "Enable Windows Hello for Business," along with a second GPO for the domain controllers to automatically enroll the certificate described above.

Group policy configuration

There are a few optional additional settings in the GPO that you can use, such as Use a hardware security device, which mandates storing credentials in a TPM chip. You can optionally also require only TPM 2.0 and not 1.2. You can also use biometrics; perhaps you want to disable the use of biometrics until you're ready to switch it on, which will leave PIN as the only option. You can require PIN Complexity (I went with a minimum of six digits) and created a Windows Hello for Business Users group to control who gets the option for Windows Hello for Business in the staged rollout.

End user experience

I learned rather late in the deployment that Windows Hello for Business requires Azure MFA (or the now-retired Azure MFA server on-premises), so apart from the steps above, users also need to use the free Microsoft Authenticator app on their phones (or SMS text messages or phone calls—I disabled those options as they're more insecure) and need to register at aka.ms/mfasetup.

I initially deployed this to six teachers during an afternoon training session, and the experience was flawless: set up MFA, sign off, sign back on, Windows Hello for Business asks the user to set up a PIN, scans their face, and then signs them in. One of the Surface Books had trouble with the biometrics and refused to do face registration, probably due to its age (troubleshooting to follow).

Lessons learned

This was a long process, spread out over years from the initial idea to last week's training when teachers enrolled, with more students and teachers to follow. I really like the idea of an unphishable credential that also provides a convenient user experience. Given the hardware requirements for Windows 11, I've advised the client that new device purchases toward the end of this year need to come with TPM 2.0 chips and Windows Hello for Business-capable biometrics. We'll see what price premium that brings.

I'm also trialing a FIDO 2 YubiKey with one student to assess whether having a separate device (again unphishable) for authentication is preferable, rather than having it built into each PC.

I hope this real-world deployment experience retelling was useful. Good luck in your journey to being passwordless.