Creating a Friendlier Windows Hello Setup

By now, we should have all received the news: Passwords are no longer enough. With faster and more powerful devices in the hands of determined cybercriminals, and the relative ease in which even “secure” password policies can be compromised by phishing attacks, the costs now outweigh the benefits of using predictable and vulnerable passwords. The solutions you’ve likely heard at this point are Multi-Factor Authentication (MFA) and Passwordless solutions such as Fast Identity Online (or FIDO) and Security Keys like those from Yubico and AuthenTrend. In each case, the solution is to pair something you know (your username and password, or PIN) with something you have or are (such as biometrics and/or a phone with an authenticator app). Without these two factors, you are not able to sign into an account. This means that, even if your account credentials are stolen, your account is likely still protected as long as you retain the physical factors. Windows Hello for Business replaces your password with strong, two-factor authentication, when configured on PCs that provide biometric authentication methods such as fingerprint or face sign-in.

So what’s so unfriendly about Windows Hello?

By default, Windows Hello can take a few different forms, and each of them have a number of prerequisites for IT administrators, as well as a number of actions that must be taken by users when configuring the technology. Probably the most jarring of the user-driven processes is the setup itself: Unlike other settings in Windows that are user-driven or silently managed by IT policies, Windows Hello for Business requires user-interaction… and this is achieved by a modal dialog that forces the user to complete the Windows Hello sign-up. While it is possible to minimise the disruption by having users complete a joint MFA and Self Service Password Reset (SSPR) process to ensure that the alternate authentication methods are set up, the Windows Hello for Business setup wizard will still pop up after every single sign-on the user makes, across any device they are enabled for, and it will force them to set a PIN and complete the registration. That’s not ideal and can lead to your new – and very important – security solution being resented by users.

But there is a solution: Create a Custom Configuration Policy to allow the setup to be triggered on demand AFTER the login has completed. The trick here is to simply not use the default Windows Hello Policy at all, or at least not for the users where forcing the setup may be inappropriate. To check the current state of the default policy:

1. Sign into the Microsoft Endpoint Manager admin center with an appropriate administrator credentials: https://endpoint.microsoft.com/
   
2. Open the side menu with the hamburger icon is collapsed, then click on Devices from the side menu.
   
3. Click Windows Hello for Business from the available options.
   
4. Check the status of the Configure Windows Hello for Business option. If set to Not configured, then you’ll be able to configure the solution using a custom policy. If set to Enabled, this will target All users, and will enforce the setup wizard after sign-in. Furthermore, setting this to Disabled may prevent your users from using the custom policy.

Creating a Custom Policy

As part of the mobile device management (MDM) solution Intune provides, a large effort is made to ensure that common and critical templates and policy options are provided as simple click-and-configure settings. However, there often comes a time when you need to define a custom policy to include the exact settings you need, and this comes in the form of Open Mobile Alliance Uniform Resource Identifier (OMA-URI) settings.

1. If you aren’t signed into the Microsoft Endpoint Manager admin center, go there now (see above) and then select Devices from the main menu again.
   
2. This time, click on Configuration profiles, then finally click on + Create profile from the top menu.
   
3. Under Platform, select Windows 10 and later. For the Profile type, select Templates. Within the Templates list, select Custom and then click the Create button at the bottom.
   
4. Provide your new Configuration profile a Name (and optionally Description), then click Next.
   
5. Now, for each setting we require, click the Add button, then fill out the required Name, OMA-URI, Data type, and Value. As these will vary based on your needs, I’ll add an example configuration in the code block below. Add each of these one at a time, then click Save.

While not all of the following settings are required to create a valid Windows Hello for Business configuration profile, and while your environment might choose to configure certain settings differently, the settings below should provide a place to start.

1. Name: UsePassportForWork
   Description: Enables Windows Hello on the client device
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/UsePassportForWork
   Data Type: Boolean
   Value: True
   
2. Name: UseBiometrics
   Description: Enable the use of biometric login
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/Biometrics/UseBiometrics
   Data Type: Boolean
   Value: True
   
3. Name: RequireSecurityDevice
   Description: Attempt to use a TPM is available
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork<Tenant_ID>/Policies/RequireSecurityDevice
   Data Type: Boolean
   Value: True
   
4. Name: UseEnhancedProtection
   Description: Enable Enhanced Protection for Face Login (Recommended)
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/Biometrics/FacialFeaturesUseEnhancedAntiSpoofing
   Data Type: Boolean
   Value: True
   
5. Name: UseCertificateForOnPremAuth
   Description: This may change depending on whether you’re using Hybrid Key Trust or not
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/UseCertificateForOnPremAuth
   Data Type: Boolean
   Value: True
   
6. Name: EnablePinRecovery
   Description: Enables… PIN rewcovery
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork<Tenant_ID>/Policies/EnablePinRecovery
   Data Type: Boolean
   Value: True
   
7. Name: MinimumPINLength
   Description: PIN Minimum
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/MinimumPINLength
   Data Type: Integer
   Value: 6
   
8. Name: MaximumPINLength
   Description: PIN Maximum
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/MaximumPINLength
   Data Type: Integer
   Value: 25
   
9. Name: UppercaseLetters
   Description: Require uppercase characters (no)
   OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/UppercaseLetters
   Data Type: Integer
   Value: 0
   
10. Name: LowercaseLetters
    Description: Require lowercase characters (no)
    OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/LowercaseLetters
    Data Type: Integer
    Value: 0
    
11. Name: SpecialCharacters
    Description: Require special characters (no)
    OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/SpecialCharacters
    Data Type: Integer
    Value: 0
    
12. Name: Digits
    Description: Require digits/numbers (yes)
    OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/Digits
    Data Type: Integer
    Value: 1
    
13. Name: Expiration
    Description: Configure PIN expiry (no)
    OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/Expiration
    Data Type: Integer
    Value: 0
    
14. Name: History
    Description: Configure PIN history for blocking PIN changes (no)
    OMA-URI: ./Device/Vendor/MSFT/PassportForWork/<Tenant_ID>/Policies/PINComplexity/History
    Data Type: Integer
    Value: 0

Obviously the <Tenant_ID> above is a placeholder and needs to be replaced with your actual Azure AD Tenant ID. If you are unsure what this is, navigate to the Azure AD Portal and sign in, then click on Azure Active Directory from the menu, then click on Properties.

NOTE: All the above settings were obtained by browsing the Microsoft Configuration service provider reference and comparing the values against those I discovered by performing registry checks against devices after using Group Policy Objects to configure the needed settings (for the on-premises and Domain-Joined devices).

Wait, we’re not done yet!

But Murray, you say, this Custom Configuration Profile is no different to the built-in one. To that, you’re almost correct. The issue with the built-in Windows Hello configuration profile is that it affects all users and devices, and that scope cannot be changed, nor can any users or groups be excluded. Thats’ the “not very nice” part of the setup. The benefit of this Custom Configuration profile is that it allows you to add, remove, and change all the available CSP values for Windows Hello, biometrics and PIN in one place, but also gives you full control over who is scoped for the policy.

The part you are correct about, is that this still enforces the Windows Hello setup wizard after logon. Annoyingly, while Microsoft did manage to add almost every equivilent Group Policy and Registry item for Windows Hello… except the one setting we actually need: DisablePostLogonProvisioning. This setting is described as “Select ‘Do not start provisioning after sign-in’ when you want to use a third-party solution to provision Windows Hello for Business… Windows Hello for Business does not automatically start provisioning after the user has signed in”. When used, you don’t actually need a third-party solution, and simply using the Set up button in Settings is the trigger for the setup wizard.

To add this setting, what we need to do is create the required registry key. You can do this using the registry key below either manually or in a script, however we’ll use a Microsoft Endpoint Manager script Configuration profile to make this happen at the same time as the above Windows Hello Configuration Profile. For those wanting to test the direct method, here’s the key you need:

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork]
“DisablePostLogonProvisioning”=DWORD:00000001

But here’s how we’ll do it via Intune:

1. Head back to the Microsoft Endpoint Manager admin center if you’re not there, sign in, then click Devices.
   
2. This time, select Scripts from the side menu followed by + Add and Windows 10.
   
3. Give your script a Name (and optional Description) and click Next.
   
4. Select a script to deploy. This must be a working script, already saved. We’ll leave all the other options as default for now. See the below code block – below this list – for the script I used.
   
5. Click Next, then set your Group assignments. These should be the same as the ones targeted for the Windows Hello Configuration profile above, however it may be useful to exclude users that you want to enforce the setup wizard on by creating a new group: Unfortunately, Microsoft also neglected to add group exclusions to these script options.
   
6. Click Next, then click Add to complete the the setup. This configuration will now deploy and execute on the scoped devices and configure the setting you need.

clear-host
#Defining the variables we need
[string]$ConfigKey = “HKLM:\SOFTWARE\Policies\Microsoft\PassportForWork”
[string]$ConfigItemName = “DisablePostLogonProvisioning”
[string]$ConfigItemType = “DWORD”
[int]$ConfigItemValue = 1
#Ensure the key exists to avoid an error
If(!(Test-Path $ConfigKey)) {
# Create the key if it doesn’t exist already
New-Item -Path $ConfigKey -Force | Out-Null
}
#Create the item we need
New-ItemProperty -Path $ConfigKey -Name $ConfigItemName -Value $ConfigItemValue -PropertyType $ConfigItemType -Force | Out-Null

At this point, you may be wondering about the order these two Configuration profiles apply in, and to that I say “it should mostly work”. By default Windows hello for Business setup will only be triggered after a user has signed into the device. If the Windows Hello profile applies without the script also applying, then users may continue to experience the forced setup wizard. That being said, this should only occur if you’re unlucky and deploying the configuration to existing devices where a user login may occur at any time AND without the Enrollment Status Page (ESP) being executed for setup: You’d have to be very unlucky. When deploying new devices, the Device configuration state in the ESP is always run before the user configuration, so with both profiles targeting the device, both should have completed before the user signs in.

I hope that helps. If you find this useful, or have further questions, feel free to drop me a message on Twitter.