Configuring Windows Hello for Business multi-factor unlock

This week continues the journey through Windows Hello for Business. The last weeks were all about requiring the use of Windows Hello for Business, while this week is all about requiring the use of something extra with Windows Hello for Business. That something extra is a second unlock factor. By default, Windows requires the use of a single authentication factor to verify the identity of a user and to unlock the device. And even though the construction of Windows Hello for Business can be considered multi-factor authentication, as it combines something that you have (e.g. a device with a hardware TPM) with something that you know (e.g. a PIN) or with something that you are (e.g. a fingerprint), the unlock factor of the device with hardware TPM can be just a PIN. That PIN is device specific, but it can be a potential threat (e.g. via shoulder surfing) that can be relatively easily mitigated. Even with standard Windows functionality. That standard functionality is extending Windows Hello for Business with multi-factor unlock. Multi-factor unlock enables organizations to require a combination of credential providers and trusted signals. This post will provide an introduction to Windows Hello for Business multi-factor unlock, the configuration options and the steps for using Microsoft Intune to apply the configuration.

Introducing Windows Hello for Business multi-factor unlock

Windows Hello for Business multi-factor unlock provides organizations with the ability to require a combination of credential providers to verify the identity of the user and to unlock the device. That combination of credential providers, however, is limited to a specific list of supported credential providers. That list of supported credential providers is summarized in the table below, including the default usage and the configuration options within the first and second unlock factors. Third-party credential providers are not supported as unlock factor. Almost all of the different credential providers can be configured as the first and the second unlock factor. It is, however, important to keep in mind that any credential provider can only be used to satisfy one unlock factor. Using, for example, PIN to satisfy the first and second unlock factor is not possible.

Credential ProviderCLSIDDefaultConfiguration optionPIN{D6886603-9D2F-4EB2-B667-1971041FA96B}First and second unlock factor First and second unlock factor Fingerprint{BEC09223-B018-416D-A0AC-523971B639F5}First unlock factor First and second unlock factor Facial recognition{8AF662BF-65A0-4D0A-A540-A338A999D36F}First unlock factor First and second unlock factor Trusted signal{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}Second unlock factorSecond unlock factor

Another interesting part of Windows Hello for Business multi-factor unlock, is the trusted signal credential provider. The trusted signal credential provider can only be used to satisfy the second unlock factor and can use any of the following signals.

• Bluetooth – Use a connected bluetooth device to satisfy the trusted signal (available with Windows 10 version 1709 and later). That signal enables the IT administrator to configure a bluetooth class of devices that can be used as the second unlock factor. That configuration requires users to have that specified bluetooth device configured and connected to their device, to satisfy the second unlock factor. Common used example is phone (512).
• IP configuration – Use the IP configuration to satisfy the trusted signal (available with Windows 10 version 1709 and later). That signal enables the IT administrator to specify IP configurations that can be used as the second unlock factor. That configuration requires users to have a specific IP configuration on their device, that can often be related to a specific location, to satisfy the second unlock factor. Common used examples are the network prefix, the gateway, the DHCP server, the DNS server and the DNS suffix.
• Wi-Fi – Use the wireless connection to satisfy the trusted signal (available with Windows 10 version 1803 and later). That signal enables the IT administrator to specify wireless network configurations that can be used as the second unlock factor. That configuration requires users to be connected to a specific wireless network, that can often be related to a specific location, to satisfy the second unlock factor. Common used examples are the ssid, the bssid, the network security and the trusted root CA.

The trusted signals can be configured by configuring signal rules in XML. That XML should be properly formatted in a single line. Each signal rule contains at least a rule element like this <rule schemaVersion="1.0"> </rule> and each rule element contains one or more signal elements. Those signal elements describe the actual signal configuration. When the IT administrator wants to allow multiple signal elements, a rule element can contain multiple signal elements. The actual configuration depends on if multiple signals should be required or if only one of the signals should be required. When multiple signals should be required, the signal elements are within an and element like this <rule schemaVersion="1.0"> <and> </and> </rule>, and when only one signal should be required, the rule elements are separated with a comma like this <rule schemaVersion="1.0"> </rule>,<rule schemaVersion="1.0"> </rule>. The different configuration options of the signal elements are described in the table below.

SignalElementDescriptionExamplebluetooth–The bluetooth signal element describes the bluetooth signal and attributes, in which the classOfDevice attribute describes the device in the bluetooth protocol (possible values: 0, 256, 512, 768, 1024, 1280, 1536, 1792, 2048, 2304, 7936).<signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>ipConfig–The ipConfig signal element describes the IP configuration and contains one ore more IP configuration elements.<signal type="ipConfig"> </signal>ipConfigipv4PrefixThe optional ipv4Prefix element describes the network prefix and can only exist once in the signal element (also available as ipv6Prefix).<ipv4Prefix>192.168.20.0/24</ipv4Prefix>ipConfig ipv4Gateway The optional ipv4Gateway element describes the gateway and can only exist once in the signal element (also available as ipv6Gateway).<ipv4Gateway>192.168.20.1</ipv4Gateway>ipConfig ipv4DhcpServer The optional ipv4DhcpServer element describes the DHCP server and can only exist once in the signal element (also available as ipv6DhcpServer).<ipv4DhcpServer>192.168.20.1</ipv4DhcpServer>ipConfig ipv4DnsServer The optional ipv4DnsServer element describes the DNS server and can exist multiple times in the signal element (also available as ipv6DnsServer).<ipv4DnsServer>192.168.20.1</ipv4DnsServer>ipConfigdnsSuffixThe optional dnsSuffix element describes the DNS suffix and can exist multiple times in the signal element.<dnsSuffix>corp.petervanderwoude.nl</dnsSuffix>wifi–The wifi signal element describes the Wi-Fi configuration and contains one ore more Wi-Fi elements. <signal type="wifi"> </signal>wifissidThe required ssid element describes the name of the wireless network and can only exist once in the signal element.<ssid>corpwifi</ssid>wifibssidThe optional bssid element describes the mac address of the wireless access point and can only exist once in the signal element.<bssid>34-cd-56-ff-f6-57</bssid>wifisecurityThe required security element describes the security of the wireless network (supported values: Open, WEP, WPA-Personal, WPA-Enterprise, WPA2-Personal, WPA2-Enterprise) and can only exist once in the signal element. <security>WPA2-Enterprise</security>wifitrustedRootCAThe optional trustedRootCA element describes the thumbprint of the trusted root certificate of the wireless network and can only exist once in the signal element.<trustedRootCA>b3 02 45 bb 33 4b b3 4b 5b 89 b3 bb 86 b3 45 3b 4c 33 5b cc</trustedRootCA>wifisig_qualityThe optional sig_quality element describes the signal strength of the wireless network and can only exist once in the signal element.<sig_quality>75</sig_quality>

Configuring Windows Hello for Business multi-factor unlock

When looking at the configuration of Windows Hello for Business multi-factor unlock, the PassportForWork CSP can help. That CSP contains the DeviceUnlock node in the device configuration and is available with Windows 10 version 1803 and later. That node contains the following settings nodes that should be configured for Windows Hello for Business multi-factor unlock.

• GroupA – This node contains a list with CLSIDs, comma separated, that are allowed as the first unlock factor
• GroupB – This node contains a list with CLSIDs, comma separated, that are allowed as the second unlock factor
• Plugins – This node contains the signal rules, in XML, that configure the trusted signals

Important: The XML should not be nicely formatted with new lines and tabs, but formatted in a single line.

Those settings of the PassportForWork CSP are currently not available via the Settings Catalog and still require the use of a custom profile with OMA-URI settings. The following 10 steps walk through the configuration of a custom profile with the required OMA-URI settings. Those steps configure PIN, fingerprint and facial recognition as the first unlock factor options, PIN and trusted signal as the second unlock factor options, and bluetooth connected phone or network prefix as trusted signal rules.

1. Open the Microsoft Endpoint Manager admin center portal navigate to Devices > Windows > Configuration profiles
2. On the Windows | Configuration profiles blade, click Create profile
3. On the Create a profile blade, provide the following information and click Create

• Platform: Windows 10 and later
• Profile type: Templates
• Template name: Custom

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

• Name: Provide a name for the custom profile to distinguish it from other similar profiles
• Description: (Optional) Provide a description for the custom profile to further differentiate profiles
• Platform: (Greyed out) Windows 10 and later
• Profile type: (Greyed out) Custom

1. On the Configuration settings page, see also Figure 1, click Add to add a row for the following custom settings and click Next

• OMA-URI setting 1 – This setting is used to define the first unlock factor credential providers
  • Name: Provide a name for the OMA-URI setting to distinguish it from other similar settings
  • Description: (Optional) Provide a description for the OMA-URI setting to further distinguish it from other similar settings
  • OMA-URI: Specify ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupA as value to define the first unlock factor credential providers
  • Data type: Select String
  • Value: Specify {D6886603-9D2F-4EB2-B667-1971041FA96B},{BEC09223-B018-416D-A0AC-523971B639F5},{8AF662BF-65A0-4D0A-A540-A338A999D36F} as value to configure PIN, fingerprint and facial recognition as the allowed first unlock factor credential providers
• OMA-URI setting 2 – This setting is used to define the second unlock factor credential providers
  • Name: Provide a name for the OMA-URI setting to distinguish it from other similar settings
  • Description: (Optional) Provide a description for the OMA-URI setting to further distinguish it from other similar settings
  • OMA-URI: Specify ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupB as value to define the second unlock factor credential providers
  • Data type: Select String
  • Value: Specify {D6886603-9D2F-4EB2-B667-1971041FA96B},{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD} as value to configure PIN and trusted signal as the allowed second unlock factor credential providers
• OMA-URI setting 3 – This setting is used to define the signal rules for device unlock
  • Name: Provide a name for the OMA-URI setting to distinguish it from other similar settings
  • Description: (Optional) Provide a description for the OMA-URI setting to further distinguish it from other similar settings
  • OMA-URI: Specify ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/Plugins as value to define the signal rules
  • Data type: Select String
  • Value: Specify <rule schemaVersion=”1.0″> <signal type=”bluetooth” scenario=”Authentication” classOfDevice=”512″ rssiMin=”-10″ rssiMaxDelta=”-10″/> </rule>,<rule schemaVersion=”1.0″> <signal type=”ipConfig”> <ipv4Prefix>192.168.20.0/24</ipv4Prefix> </signal> </rule> as value to require a connected bluetooth phone or a specific network prefix as trusted signal

• Figure 1: Configuring the first and second unlock factor credential providers

1. On the Scope tags page, configure the required scope tags click Next
2. On the Assignments page, configure the required assignment and click Next
3. On the Applicability rules page, configure the required applicability rules and click Next
4. On the Review + create page, verify the configuration and click Create

Experiencing Windows Hello for Business multi-factor unlock

Experiencing the behavior with Windows Hello for Business multi-factor unlock is pretty straight forward. Simply start a configured Windows 10 device, or Windows 11 device, and sign-in with one of the available allowed first unlock factor credential providers. When a bluetooth phone is connected to the device, or the device is connected to the expected network, the second unlock factor will automatically be verified. Figure 3 shows an example of a Windows 10 device and Figure 4 shows an example of a Windows 11 device.

Important: Keep in mind that multi-factor unlock is an extension on Windows Hello for Business. That means that the request for the second unlock factor will only come when using one of the specified first unlock factors. When for example using username-password, or FIDO2 security keys, there will be no request for a second unlock factor. Make sure to align the available credential provider with the required behavior.

More information

For more information about Windows Hello for Business multi-factor unlock and and the different configuration options, refer to the following docs.