Requiring the use of Windows Hello for Business for interactive logons

This week is all about Windows Hello for Business. Windows Hello for Business provides a really convenient and user-friendly method to authenticate in Windows, as it enables users to verify their identity by using a gesture (face, fingerprint or PIN). More importantly, however, Windows Hello for Business is also an important step in the transition to a passwordless environment, as it replaces the need for the traditional username-password authentication with a strong two-factor authentication on Windows devices. By default, Windows Hello for Business will be an additional method to get authenticated in Windows.

When working towards a passwordless environment, it’s important to also take further actions for Windows devices, by preventing the use of the traditional username-password and by requiring the use of Windows Hello for Business or smart cards. That would force users in to using Windows Hello for Business. Forcing users in to using Windows Hello for Business does require an organization and their users to be ready. To be ready to provision new users on devices, to facilitate PIN reset functionalities on devices, to accept the limitations for new accounts and local accounts on devices, and to be able to address the different scenarios for password usage by the applications on devices. This post will focus on the technical implementation of requiring the use of Windows Hello for Business. The steps for the implementation, some technical challenges and the user experience.

Important: The intention of this post is not to discuss Windows Hello for Business as a true multi-factor authentication solution, only to provide guidance with the technical implementation of requiring Windows Hello for Business. It is good, however, to keep in mind that the definition of NIST considers the construction of Windows Hello for Business as multi-factor authentication. Windows Hello for Business combines something that you have (e.g. a device with a hardware TPM that contains the private key) with something that you know (e.g. a PIN to unlock the private key) or something that you are (e.g. a fingerprint match to unlock the private key). That is similar to smart cards. Big difference, however, is the portability. And even though portability is not part of that definition of multi-factor authentication, organizations might consider it as an important part of the solution. When Windows Hello for Business alone is considered as not sufficient, have a look at adding multi-factor unlock, FIDO2 security keys or smart cards.

Configuring the required use of Windows Hello for Business for interactive logons

When looking at requiring the use of Windows Hello for Business, there is the option to require the use of Windows Hello for Business for interactive logons and the option to completely exclude the password credential provider. The former is the more elegant initial option, as it leaves the password credential provider available for use and provides the user with a clear message that Windows Hello for Business should be used. The latter is the more disrupting option, as it completely hides the password credential provider from Windows and other applications that are relying on that credential provider. This post will focus on the former option and more about the latter option is for another post.

For the configuration to require the use of Windows Hello for Business, there is a Group Policy setting available that can be used. That policy setting exists as Interactive logon: Require Windows Hello for Business or smart card for Windows 10, version 1703 and later. The challenge, however, is that this policy settings isn’t easily configurable via Microsoft Intune at this moment. Not available via the Administrative Templates, nor via the Settings Catalog. The good thing is that this setting configures a registry value (scforceoption) and that can be relatively easily scripted by using PowerShell. As PowerShell scripts are the road forward, the best controlled method to distribute the required configuration is by using proactive remediations.

Constructing the PowerShell script to detect the Windows Hello for Business configuration

When using proactive remediations, there should be a detection script. That detection script should detect the Windows Hello for Business configuration. Below is a snippet of a PowerShell script that performs the required detection. That snippet verifies the existence of the registry key, the registry value and the registry data, that are required for the Windows Hello for Business configuration. That verification is achieved by checking the existence of the registry key (line 5), by checking the availability of the registry value (line 6) and by verifying the registry data (line 7).

$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$registryValueName = "scforceoption"
$registryValueData = "1"

if((Test-Path $registryPath)) {
    if(Get-ItemProperty -Path $registryPath -Name $registryValueName -ErrorAction Ignore) {
        if((Get-ItemPropertyValue -Path $registryPath -Name $registryValueName -ErrorAction Ignore)-eq $registryValueData) {
            Write-Host "Windows Hello for Business is required"
            exit 0
        }
        else {
            Write-Host "Windows Hello for Business is currently not required"
            exit 1 
        }
    }
    else {
        Write-Host "Windows Hello for Business is currently not required"
        exit 1 
    }
}
else {
    Write-Host "Windows Hello for Business is currently not required"
    exit 1
}  

Constructing the PowerShell script to remediate the Windows Hello for Business configuration

When using proactive remediations, there should also be a remediation script. That remediation script should remediate the Windows Hello for Business configuration. Below is a snippet of a PowerShell script that performs the required remediation. That snippet creates the registry configuration that is required for the Windows Hello for Business configuration. That creation is achieved by checking the existence of the registry key. When the registry key doesn’t exist (line 6), the registry key (line 7), the registry value and the registry data are created (line 8). When the registry key does exist (line 11), only the registry value and registry data are set (line 12).

$registryPath = "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System"
$registryValueName = "scforceoption"
$registryValueData = "1"

try {
    if(!(Test-Path $registryPath)) {
        New-Item -Path $registryPath -Force
        New-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -PropertyType DWORD -Force
        Write-Host "Successfully configured Windows Hello for Business as required" 
    }
    else {
        New-ItemProperty -Path $registryPath -Name $registryValueName -Value $registryValueData -PropertyType DWORD -Force
        Write-Host "Successfully configured Windows Hello for Business as required" 
    }
}
catch {
    $errorMessage = $_.Exception.Message
    Write-Error $errorMessage
    exit 1 
}

Using proactive remediation to detect and remediate the Windows Hello for Business configuration

After constructing the different PowerShell scripts to detect and remediate the Windows Hello for Business configuration, it’s time to look at the best method for applying those scripts. That best method is proactive remediations. Proactive remediations are script packages that can detect and remediate any scriptable challenge, as long as those challenges can be addressed by using PowerShell. The nice thing about script packages is the ability to schedule the execution and to configure recurring behavior. That provides a lot of control and flexibility. For deploying those script packages, Microsoft Intune relies on the Intune Management Extension (IME). The following six steps walk through the creation of a script package to detect and remediate the Windows Hello for Business configuration.

1. Open the Microsoft Endpoint Manager admin center portal navigate to Reports > Endpoint analytics > Proactive remediations
2. On the Endpoint analytics (Preview) | Proactive remediations blade, click Create script package to open the Create custom script wizard
3. On the Basics page, provide the following information and click Next

• Name: Provide a valid name for the custom script package to distinguish it from other similar script packages
• Description: (Optional) Provide a valid description for the custom script package to further differentiate script packages
• Publisher: (Optional) Provide a valid publisher for the custom script package, by default the creator of the script package
• Version: [Greyed out]

1. On the Settings page, provide the following information and click Next

• Detection script file: Select the created detection script to detect the status of the Windows Hello for Business configuration
• Detection script: [Greyed out]
• Remediation script file: Select the created remediation script to remediate the Windows Hello for Business configuration
• Remediation script: [Greyed out]
• Run this script using the logged-on credentials: Select No as value to make sure that the script runs in SYSTEM context
• Enforce script signature check: Select No as value to make sure that the signature of the script is not checked
• Run script in 64-bit PowerShell: Select Yes as value to make sure that the script runs in 64-bit, if possible

• Figure 1: Example configuration of the custom script package settings

1. On the Scope tags page, configure the required scope tags click Next
2. On the Assignments page, provide the following information and click Next

• Assign to: Select the assigned group and configure the schedule by clicking on the three dots
• Schedule: Select the recurrence frequency by choosing between Once, Daily, or Hourly
  • When choosing Once, a specific date and time should be configured
  • When choosing Daily, a frequency and daily time should be configured
  • When choosing Hourly, a frequency should be configured

Important: The assignment of the script package is an important part of creating a working solution. When the script package is applied during the out-of-the-box experience, that will already disrupt the configuration of the device and that will prevent the user from configuring Windows Hello for Business on the device.

1. On the Review + create page, verify the information and click Create

Experiencing the required use of Windows Hello for Business for interactive logons

Experiencing the behavior with the required use of Windows Hello for Business is pretty straight forward. Simply start a configured Windows 10 device, select Password (the key icon) as the Sign-in option, provide username-password and click Submit (the arrow icon). That will trigger the configuration and will tell the user to use Windows Hello or a smart card to sign in (as shown below in Figure 2). This behavior is also successfully tested on the current preview version of Windows 11.

Important: Keep in mind that this configuration also allows the use of FIDO2 security keys.

• Figure 2: User experience when requiring Windows Hello for Business

As mentioned earlier, this does require Windows Hello for Business to be configured for the user before the configuration is applied. That makes it important to make the user configure Windows Hello for Business immediately during the out-of-the-box experience. After applying the configuration, to require Windows Hello for Business, it’s no longer possible for a user to set up Windows Hello for Business. At that point the configuration becomes a loop. Windows Hello for Business is required, but can’t be configured. That might bring challenges for local accounts or new user accounts. In those cases, or when using shared devices, think about using FIDO2 security keys, or smart cards. Those are already configured and connected to the identity of the user. And can also be used in combination with the configuration to require Windows Hello for Business.

More information

For more information about the passwordless strategy of Microsoft and and the different configuration options, refer to the following docs.