Multifactor device unlock is a neat feature that works alongside Windows Hello For Business. We know that a Pin/biometric gesture is more secure that a traditional password because it is unique to the device it was setup on. Someone would have to steal your physical device to make use of a compromised Pin/biometric gesture unlike a password. However there are certain scenarios where this system may not be as secure as it seems such as in a coffee shop where someone has watched you enter your pin then waited until you left the device unattended before making their move. The solution to this type of scenario is Multifactor device unlock.

Multifactor unlock as you can probably guess uses a first and second unlock credential provider, this blog will detail how to configure a common setup in Intune where the first factor is your Windows Hello credential (Pin/Fingerprint/Face etc) and second factor is Trusted location or Bluetooth phone. For the purpose of this blog the configuration was tested in a pure Azure AD Join scenario on windows 10 1809. Note that trusted location in this scenario means the client must connected to a network with DNS server (10.0.0.1).

With this configuration we will look to achieve the following login experience:
1. User enters their PIN or uses Biometric gesture.
2. Windows Hello Verifies the Pin/Biometric gesture is valid. First Factor Pass.
3. Windows Hello checks the device is on a network with DNS server 10.0.0.1. Second Factor Pass, user is logged in.
4. Device is not on a trusted network, Windows Hello checks the users Bluetooth phone signal is nearby. Second Factor Pass, user is logged in.
5. Windows Hello does not detect Bluetooth signal, user is prevented from signing in.

The trusted signal may be your corporate office network where due to physical and network security your confident the user authenticating is who they say they are only resorting to Bluetooth phone signal when the user leaves the office. You may want to do this to provide a better user experience as trusted signal is likely to be more reliable than Bluetooth.

Configuration:
Pre-Requirements:
1. Working Windows Hello for Business
2. Intune
3. At least Windows 10 1709

First from the Azure Portal > Intune Snap in > Device configuration create a new custom profile.

Add a new OMA-URI Setting:
Name: Windows Hello Multifactor Unlock – First Unlock Factor
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupA
Data Type: String
Value: {D6886603-9D2F-4EB2-B667-1971041FA96B},{8AF662BF-65A0-4D0A-A540-A338A999D36F},{BEC09223-B018-416D-A0AC-523971B639F5}

Add a second OMA-URI Setting:
Name: Windows Hello Multifactor Unlock – Second Unlock Factor
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/GroupB
Data Type: String
Value: {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD},{D6886603-9D2F-4EB2-B667-1971041FA96B}

Add a third OMA-URI Setting:
Name: Windows Hello Multifactor Unlock – Unlock Signals Rules
OMA-URI: ./Device/Vendor/MSFT/PassportForWork/DeviceUnlock/Plugins
Data Type: String
Value:
<rule schemaVersion="1.0"> <signal type="ipConfig"> <ipv4DnsServer>10.0.100.32</ipv4DnsServer> </signal> </rule>, <rule schemaVersion="1.0"> <signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/> </rule>

At this stage you can save the profile and start assigning to your users/devices.

Further Information:

  • First unlock factor credential provider (primary authentication)
  • Second unlock factor credential provider (second factor authentication)
  • Signal rules for device unlock (defines second unlock credential provider)
  • Each GUID relates to a credential provider:

  • PIN: {D6886603-9D2F-4EB2-B667-1971041FA96B}
  • Fingerprint: {BEC09223-B018-416D-A0AC-523971B639F5}
  • Facial Recognition: {8AF662BF-65A0-4D0A-A540-A338A999D36F}
  • Trusted Signal: {27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}
  • The signal rule uses the ipv4DnsServer parameter to specify the DNS server, update the value to your choice.

    The Bluetooth Section is slightly different:

    <rule schemaVersion="1.0"> <signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/> </rule>

    The class of device “512” refers to a phone, other devices are possible:

  • Miscellaneous: 0
  • Computer: 256
  • Phone: 512
  • LAN/Network Access Point: 768
  • Audio/Video: 1024
  • Peripheral: 1280
  • Imaging: 1536
  • Wearable: 1792
  • Toy: 2048
  • Health: 2304
  • Uncategorized: 7936
  • Microsoft Recommend leaving the rssiMin setting to the default -10 setting, as explained here.

    The rssiMin attribute value signal indicates the strength needed for the device to be considered “in-range”. The default value of -10 enables a user to move about an average size office or cubicle without triggering Windows to lock the device. The rssiMaxDelta has a default value of -10, which instruct Windows 10 to lock the device once the signal strength weakens by more than measurement of 10.
    RSSI measurements are relative and lower as the bluetooth signals between the two paired devices reduces. Therefore a measurement of 0 is stronger than -10, which is stronger than -60, which is an indicator the devices are moving further apart from each other.

    For troubleshooting refer to the Windows Logs>Applications and Service Logs>Microsoft>Windows>HelloForBusiness>Operational