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 option
PIN{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.

SignalElementDescriptionExample
bluetoothThe 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"/>
ipConfigThe 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>
wifiThe 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
  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.

9 thoughts on “Configuring Windows Hello for Business multi-factor unlock”

  1. We are experiencing users forgetting more and more their passwords because of the use of Windows Hello for Business. Is there an easy way of introducing their account passwords as an additional needed factor once a week or similar so that they keep using them?

    Reply
    • Hi David,
      There not something like that in combination with Windows Hello. Also, isn’t that what you want to achieve? The user not knowing their password, means that they don’t use it anymore.
      Regards, Peter

      Reply
      • Aren’t there still instances though where Windows Hello for Business won’t pass through the token and an application will still require a password? Sorry, I’m not sure about the terminology.

        Reply
  2. Hello Peter,

    The second factor in combination with pin does not work.
    the login screen with pin saying second factor required for this but it is not accepted while my mobile phone is connected and dynamic lock also is working when i disable bluetooth on my phone.

    Also you say this:
    “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”

    Why do we need to specify the pin again as second factor? cause you say that any credential provider can only be used to satisfy one unlock factor and whe are using it already as the first unlock factor am i right?

    Reply
    • Hi H. Huibers,
      Yes, in this example I’ve configured PIN as both factors. Main reason is to provide combination options to the user. And yes, the user can only use the PIN as a single factor.
      Regards, Peter

      Reply
  3. Hello Peter,

    I configured a policy in Intune with trusted signal as 2nd factor but it is nog working with bluetooth phone and also not with wifi ssid. Kan aanvullende factor niet verifieren. Do you know what can be wrong? I use my phone also for dynamic lock and that is working fine.
    Thanks in advance!

    Reply

Leave a Reply to Pete Mitchell Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.