Windows Hello for Business and changing security policies (lessons learned)

Posted On February 13, 2024

Last weeks I had some challenges with a customer requiring more strictive PIN permissions for Windows Hello For Business. My initial thought was, I’ll just change the Intune Policy, and people will receive the new policy settings and job done. During the test phase with my own tenant, and with a few test users all seemed to be working fine. But when we started to deploy the policy to the entire company, a lot of users didn’t get the prompt to change their PIN.

To understand why a lot of users didn’t get the prompt to change their PIN, we need to take a deeper look into the setup of Windows Hello for Business.

First we will dive into the protection of the keys and biometric data. Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There’s a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it’s recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IdP before the IdP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed.

Basically what it means, when you setup Windows Hello for Business, Windows will create a Hello Container. This container will contain all information about Windows Hello for Business, and cannot be changed unless you delete this container, which can be done by resetting your PIN, or using the certutil utility.

Okay so far so good. Let’s move on the the next part. When you change the Policy in Intune, and you see almost all your devices and users reporting green, making you happy and thinking, policy applied successfully, job done!

But then you hear that the policy isn’t working, you will need to investigate why. When you create or change the Intune policies or use Account Protection like me, all the settings for Windows Hello for Business are written in to the device registry. (HKLM\Software\Microsoft\Policies\PassportForWindows, there are sub keys for device and user under the tenant ID.) When you check the devices, you can see all the settings being applied to device and user, but not be applied to Windows Hello.

Now here comes the tricky part, and I couldn’t find anything about this part in the Microsoft documentation. When you setup Windows Hello for Business, Windows will create your Hello container, and copies all the registry information from above, and “tattoos/print” the policies in the container. Every time you login, Windows Hello for Business will verify that your PIN still meets the complexity requirements that are printed into the container, and not verifying the information that is stored in your registry. This also applies when the user changes his PIN!

All makes sense, because you want to make it tamper proof. However frustrating to deal with when you need to increase PIN complexity because of various reasons. The only way to let the users comply again with the policy, is to forcefully delete the user container after the new Intune settings have been applied to the users.

You can do this with 1 simple command in the user context:

certutil.exe -deletehellocontainer

After the deletion, the next time the user logs on, the user is required to setup a new PIN, meeting the new complexity requirements. When a user starts the reset procedure from the login screen and clicks I forgot my PIN, the container also gets deleted.

Retrieve Windows Hello for Business registration information from Entra ID

What I found out that it is possible to retrieve information from Entra ID, giving you insights on when the containers has been created. When a Hello container gets created some information will be stored in Entra ID containing Username, Device, ID, CreationTime and status (Orphaned or not)

STEP1: Install Windows Hello for Business PowerShell module

Install-Module WHfBTools

STEP 2: View information

Get-AzureADWHfBKeys -Tenant 2azure.nl -All

After you’ve entered the command, an authentication window will appear for the corresponding tenant.

After logging in, the keys will be downloaded. Depending on the size of your tenant, the results might take a while to retrieve

The results will look like this:

TIP:

If you want to export the WHfB results to a CSV file, use the following commandline:

Get-AzureADWHfBKeys -Tenant 2azure.nl -All | Export-Csv c:\2azure\whfbkeys.csv

With the required information you can at least tell when the users did create the container, and verify if the new policy is applied because of the creation date is later than the policy has been applied.

I hope this information will help you to avoid the mistakes I made.