deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-06-18 11:53:37 +00:00
Code Issues Actions 3 Packages Projects Releases Wiki Activity

updates

Browse Source
This commit is contained in:
Paolo Matarazzo
2023-03-09 10:43:12 -05:00
parent f1b1278f0b
commit d83b57abda
9 changed files with 148 additions and 143 deletions
Download Patch File Download Diff File Expand all files Collapse all files

264
windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md
View File

@ -1,99 +1,103 @@
---
title: Multi-factor Unlock
description: Learn how Windows 10 and Windows 11 offer multi-factor device unlock by extending Windows Hello with trusted signals.
ms.date: 03/20/2018
title: Multi-factor unlock
description: Learn how Windows offers multi-factor device unlock by extending Windows Hello with trusted signals.
ms.date: 03/09/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
ms.topic: article
ms.topic: how-to
---
# Multi-factor Unlock
# Multi-factor unlock
Windows Hello for Business supports the use of a single credential (PIN and biometrics) for unlocking a device. Therefore, if any of those credentials are compromised (shoulder surfed), an attacker could gain access to the system.
Windows Hello for Business can be configured with multi-factor device unlock, by extending Windows Hello with trusted signals. Administrators can configure devices to request a combination of factors and trusted signals to unlock them.
Windows Hello for Business can be configured with *multi-factor unlock*, by extending Windows Hello with trusted signals. Administrators can configure devices to request a combination of factors and trusted signals to unlock them.
Which organizations can take advantage of Multi-factor unlock? Those who:
Multi-factor unlock is ideal for organizations that:
- Have expressed that PINs alone do not meet their security needs
- Have expressed that PINs alone don't meet their security needs
- Want to prevent Information Workers from sharing credentials
- Want their organizations to comply with regulatory two-factor authentication policy
- Want to retain the familiar Windows sign-in user experience and not settle for a custom solution
You enable multi-factor unlock using Group Policy. The **Configure device unlock factors** policy setting is located under **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**.
## The Basics: How it works
## How it works
First unlock factor credential provider and Second unlock credential provider are responsible for the bulk of the configuration. Each of these components contains a globally unique identifier (GUID) that represents a different Windows credential provider. With the policy setting enabled, users unlock the device using at least one credential provider from each category before Windows allows the user to proceed to their desktop.
**First unlock factor credential provider** and **Second unlock credential provider** are responsible for the bulk of the configuration. Each of these components contains a globally unique identifier (GUID) that represents a different Windows credential provider. With the policy setting enabled, users unlock the device using at least one credential provider from each category before Windows allows the user to proceed to their desktop.
The policy setting has three components:
* First unlock factor credential provider
* Second unlock factor credential provider
* Signal rules for device unlock
## Configuring Unlock Factors
- First unlock factor credential provider
- Second unlock factor credential provider
- Signal rules for device unlock
The **First unlock factor credential providers** and **Second unlock factor credential providers** portion of the policy setting each contain a comma separated list of credential providers.
## Configure unlock factors
Supported credential providers include:
The **First unlock factor credential providers** and **Second unlock factor credential providers** portion of the policy setting each contain a comma separated list of credential providers.
Supported credential providers include:
|Credential Provider| GUID|
|:------------------|:----|
|PIN | \{D6886603-9D2F-4EB2-B667-1971041FA96B}|
|Fingerprint | \{BEC09223-B018-416D-A0AC-523971B639F5}|
|Facial Recognition | \{8AF662BF-65A0-4D0A-A540-A338A999D36F}|
|Trusted Signal<br>(Phone proximity, Network location) | \{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}|
|PIN| `{D6886603-9D2F-4EB2-B667-1971041FA96B}`|
|Fingerprint| `{BEC09223-B018-416D-A0AC-523971B639F5}`|
|Facial Recognition| `{8AF662BF-65A0-4D0A-A540-A338A999D36F}`|
|Trusted Signal<br>(Phone proximity, Network location) | `{27FBDB57-B613-4AF2-9D7E-4FA7A66C21AD}`|
>[!NOTE]
>Multifactor unlock does not support third-party credential providers or credential providers not listed in the above table.
The default credential providers for the **First unlock factor credential provider** include:
* PIN
* Fingerprint
* Facial Recognition
- PIN
- Fingerprint
- Facial Recognition
The default credential providers for the **Second unlock factor credential provider** include:
* Trusted Signal
* PIN
Configure a comma separated list of credential provider GUIDs you want to use as first and second unlock factors. While a credential provider can appear in both lists, remember that a credential supported by that provider can only satisfy one of the unlock factors. Listed credential providers do not need to be in any specific order.
- Trusted Signal
- PIN
For example, if you include the PIN and fingerprint credential providers in both first and second factor lists, a user can use their fingerprint or PIN as the first unlock factor. However, whichever factor they used to satisfy the first unlock factor cannot be used to satisfy the second unlock factor. Each factor can therefore be used exactly once. The Trusted Signal provider can *only* be specified as part of the Second unlock factor credential provider list.
Configure a comma separated list of credential provider GUIDs you want to use as first and second unlock factors. While a credential provider can appear in both lists, a credential supported by that provider can only satisfy one of the unlock factors. Listed credential providers don't need to be in any specific order.
For example, if you include the PIN and fingerprint credential providers in both first and second factor lists, a user can use their fingerprint or PIN as the first unlock factor. Whichever factor you use to satisfy the first unlock factor can't be used to satisfy the second unlock factor. Each factor can therefore be used exactly once. The Trusted Signal provider can *only* be specified as part of the Second unlock factor credential provider list.
## Configure Signal Rules for the Trusted Signal Credential Provider
The **Signal rules for device unlock** setting contains the rules the Trusted Signal credential provider uses to satisfy unlocking the device.
### Rule element
You represent signal rules in XML. Each signal rule has a starting and ending **rule** element that contains the **schemaVersion** attribute and value. The current supported schema version is 1.0.
**Example**
You represent signal rules in XML. Each signal rule has a starting and ending `rule` element that contains the `schemaVersion` attribute and value. The current supported schema version is `1.0`.
#### Example
```xml
<rule schemaVersion="1.0">
</rule>
```
### Signal element
Each rule element has a **signal** element. All signal elements have a **type** element and value. Windows 10, version 1709 or later supports the **ipConfig** and **bluetooth** type values.
Each rule element has a `signal` element. All signal elements have a `type` element and `value`. The values currently supported listed in the following table:
|Attribute|Value|
|---------|-----|
| type| "bluetooth" or "ipConfig" (Windows 10, version 1709) or later|
| type| "wifi" (Windows 10, version 1803 or later)
|type| `bluetooth` or `ipConfig`|
|type| `wifi`|
#### Bluetooth
You define the bluetooth signal with additional attributes in the signal element. The bluetooth configuration does not use any other elements. You can end the signal element with short ending tag "\/>".
You define the bluetooth signal with more attributes in the signal element. The bluetooth configuration doesn't use any other elements. You can end the signal element with short ending tag "\/>".
|Attribute|Value|Required|
|---------|-----|--------|
|type|"bluetooth"|yes|
|scenario|"Authentication"|yes|
|type|`bluetooth`|yes|
|scenario|`Authentication`|yes|
|classOfDevice|"*number*"|no|
|rssiMin|"*number*"|no|
|rssiMaxDelta|"*number*"|no|
**Example**
#### Example
```xml
<rule schemaVersion="1.0">
<signal type="bluetooth" scenario="Authentication" classOfDevice="512" rssiMin="-10" rssiMaxDelta="-10"/>
@ -115,20 +119,23 @@ The **classofDevice** attribute defaults to Phone and uses the values from the f
|Health|2304|
|Uncategorized|7936|
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 to lock the device once the signal strength weakens by more than measurement of 10.
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 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.
RSSI measurements are relative, and lower as the bluetooth signals between the two paired devices reduces. A measurement of 0 is stronger than -10. A measurement of -10 is stronger than -60, and indicates that the devices are moving further apart from each other.
>[!IMPORTANT]
>Microsoft recommends using the default values for this policy setting. Measurements are relative, based on the varying conditions of each environment. Therefore, the same values may produce different results. Test policy settings in each environment prior to broadly deploying the setting. Use the rssiMIN and rssiMaxDelta values from the XML file created by the Group Policy Management Editor or remove both attributes to use the default values.
>Microsoft recommends using the default values for this policy setting. Measurements are relative, based on the varying conditions of each environment. Therefore, the same values may produce different results. Test policy settings in each environment prior to broadly deploying the setting. Use the rssiMIN and rssiMaxDelta values from the XML file created by the Group Policy Management Editor or remove both attributes to use the default values.
#### IP Configuration
You define IP configuration signals using one or more ipConfiguration elements. Each element has a string value. IpConfiguration elements do not have attributes or nested elements.
You define IP configuration signals using one or more ipConfiguration elements. Each element has a string value. IpConfiguration elements don't have attributes or nested elements.
##### IPv4Prefix
The IPv4 network prefix represented in Internet standard dotted-decimal notation. A network prefix that uses the Classless Inter-Domain Routing (CIDR) notation is required as part of the network string. A network port must not be present in the network string. A **signal** element may only contain one **ipv4Prefix** element.
**Example**
The IPv4 network prefix represented in Internet standard dotted-decimal notation. A network prefix that uses the Classless Inter-Domain Routing (CIDR) notation is required as part of the network string. A network port must not be present in the network string. A **signal** element may only contain one **ipv4Prefix** element.
#### Example
```xml
<ipv4Prefix>192.168.100.0/24</ipv4Prefix>
```
@ -136,22 +143,27 @@ The IPv4 network prefix represented in Internet standard dotted-decimal notation
The assigned IPv4 addresses in the range of 192.168.100.1 to 192.168.100.254 match this signal configuration.
##### IPv4Gateway
The IPv4 network gateway represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv4Gateway** element.
**Example**
The IPv4 network gateway represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv4Gateway** element.
#### Example
```xml
<ipv4Gateway>192.168.100.10</ipv4Gateway>
```
##### IPv4DhcpServer
The IPv4 DHCP server represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv4DhcpServer** element.
**Example**
The IPv4 DHCP server represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv4DhcpServer** element.
#### Example
```xml
<ipv4DhcpServer>192.168.100.10</ipv4DhcpServer>
```
##### IPv4DnsServer
The IPv4 DNS server represented in Internet standard dotted-decimal notation. A network port or prefix must not be present in the network string.The **signal** element may contain one or more **ipv4DnsServer** elements.
**Example:**
@ -160,87 +172,102 @@ The IPv4 DNS server represented in Internet standard dotted-decimal notation. A
```
##### IPv6Prefix
The IPv6 network prefix represented in IPv6 network using Internet standard hexadecimal encoding. A network prefix in CIDR notation is required as part of the network string. A network port or scope ID must not be present in the network string. A **signal** element may only contain one **ipv6Prefix** element.
**Example**
The IPv6 network prefix represented in IPv6 network using Internet standard hexadecimal encoding. A network prefix in CIDR notation is required as part of the network string. A network port or scope ID must not be present in the network string. A **signal** element may only contain one **ipv6Prefix** element.
#### Example
```xml
<ipv6Prefix>21DA:D3::/48</ipv6Prefix>
```
##### IPv6Gateway
The IPv6 network gateway represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv6Gateway** element.
**Example**
The IPv6 network gateway represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv6Gateway** element.
#### Example
```xml
<ipv6Gateway>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6Gateway>
```
##### IPv6DhcpServer
The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv6DhcpServer** element.
**Example**
The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. A **signal** element may only contain one **ipv6DhcpServer** element.
#### Example
```xml
<ipv6DhcpServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DhcpServer
```
##### IPv6DnsServer
The IPv6 DNS server represented in Internet standard hexadecimal encoding. An IPv6 scope ID may be present in the network string. A network port or prefix must not be present in the network string. The **signal** element may contain one or more **ipv6DnsServer** elements.
**Example**
#### Example
```xml
<ipv6DnsServer>21DA:00D3:0000:2F3B:02AA:00FF:FE28:9C5A%2</ipv6DnsServer>
```
##### dnsSuffix
The fully qualified domain name of your organization's internal DNS suffix where any part of the fully qualified domain name in this setting exists in the computer's primary DNS suffix. The **signal** element may contain one or more **dnsSuffix** elements.
**Example**
The fully qualified domain name of your organization's internal DNS suffix where any part of the fully qualified domain name in this setting exists in the computer's primary DNS suffix. The **signal** element may contain one or more **dnsSuffix** elements.
#### Example
```xml
<dnsSuffix>corp.contoso.com</dnsSuffix>
```
#### Wi-Fi
**Applies to:**
- Windows 10, version 1803 or later
You define Wi-Fi signals using one or more wifi elements. Each element has a string value. Wifi elements do not have attributes or nested elements.
You define Wi-Fi signals using one or more wifi elements. Each element has a string value. Wifi elements don't have attributes or nested elements.
#### SSID
Contains the service set identifier (SSID) of a wireless network. The SSID is the name of the wireless network. The SSID element is required.
Contains the service set identifier (SSID) of a wireless network. The SSID is the name of the wireless network. The SSID element is required.
```xml
<ssid>corpnetwifi</ssid>
```
#### BSSID
Contains the basic service set identifier (BSSID) of a wireless access point. the BSSID is the mac address of the wireless access point. The BSSID element is optional.
**Example**
Contains the basic service set identifier (BSSID) of a wireless access point. the BSSID is the mac address of the wireless access point. The BSSID element is optional.
#### Example
```xml
<bssid>12-ab-34-ff-e5-46</bssid>
```
#### Security
Contains the type of security the client uses when connecting to the wireless network. The security element is required and must contain one of the following values:<br>
Contains the type of security the client uses when connecting to the wireless network. The security element is required and must contain one of the following values:<br>
|Value | Description|
|:----:|:-----------|
|Open| The wireless network is an open network that does not require any authentication or encryption.|
|Open| The wireless network is an open network that doesn't require any authentication or encryption.|
|WEP| The wireless network is protected using Wired Equivalent Privacy.|
|WPA-Personal| The wireless network is protected using Wi-Fi Protected Access.|
|WPA-Enterprise| The wireless network is protected using Wi-Fi Protected Access-Enterprise.|
|WPA2-Personal| The wireless network is protected using Wi-Fi Protected Access 2, which typically uses a pre-shared key.|
|WPA2-Enterprise| The wireless network is protected using Wi-Fi Protected Access 2-Enterprise.|
**Example**
#### Example
```xml
<security>WPA2-Enterprise</security>
```
#### TrustedRootCA
Contains the thumbprint of the trusted root certificate of the wireless network. This may be any valid trusted root certificate. The value is represented as hexadecimal string where each byte in the string is separated by a single space. This element is optional.
**Example**
#### TrustedRootCA
Contains the thumbprint of the trusted root certificate of the wireless network. You can use any valid trusted root certificate. The value is represented as hexadecimal string, where each byte in the string is separated by a single space. The element is optional.
#### Example
```xml
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
```
@ -248,17 +275,20 @@ Contains the thumbprint of the trusted root certificate of the wireless network.
#### Sig_quality
Contains numeric value ranging from 0 to 100 to represent the wireless network's signal strength needed to be considered a trusted signal.
**Example**
#### Example
```xml
<sig_quality>80</sig_quality>
```
### Sample Trusted Signal Configurations
These examples are wrapped for readability. Once properly formatted, the entire XML contents must be a single line.
>[!IMPORTANT]
> These examples are wrapped for readability. Once properly formatted, the entire XML contents must be a single line.
#### Example 1
This example configures an IPConfig signal type using Ipv4Prefix, Ipv4DnsServer, and DnsSuffix elements.
The following example configures an **IPConfig** signal type using **Ipv4Prefix**, **Ipv4DnsServer**, and **DnsSuffix** elements.
```xml
<rule schemaVersion="1.0">
@ -271,9 +301,9 @@ This example configures an IPConfig signal type using Ipv4Prefix, Ipv4DnsServer,
</rule>
```
#### Example 2
This example configures an IpConfig signal type using a dnsSuffix element and a bluetooth signal for phones. This configuration is wrapped for reading. Once properly formatted, the entire XML contents must be a single line. This example implies that either the ipconfig **or** the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.
The following example configures an **IpConfig** signal type using a **dnsSuffix** element and a **bluetooth** signal for phones. The example implies that either the IpConfig **or** the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.
>[!NOTE]
>Separate each rule element using a comma.
@ -290,7 +320,8 @@ This example configures an IpConfig signal type using a dnsSuffix element and a
```
#### Example 3
This example configures the same as example 2 using compounding And elements. This example implies that the ipconfig **and** the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.
The following example configures the same as example 2 using compounding `and` elements. The example implies that the IpConfig **and** the Bluetooth rule must evaluate to true, for the resulting signal evaluation to be true.
```xml
<rule schemaVersion="1.0">
@ -303,69 +334,54 @@ This example configures the same as example 2 using compounding And elements. T
</rule>
```
#### Example 4
This example configures Wi-Fi as a trusted signal (Windows 10, version 1803 or later)
#### Example 4
The following example configures **Wi-Fi** as a trusted signal.
```xml
<rule schemaVersion="1.0">
<signal type="wifi">
<ssid>contoso</ssid>
<bssid>12-ab-34-ff-e5-46</bssid>
<security>WPA2-Enterprise</security>
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
<sig_quality>80</sig_quality>
</signal>
</rule>
<rule schemaVersion="1.0">
<signal type="wifi">
<ssid>contoso</ssid>
<bssid>12-ab-34-ff-e5-46</bssid>
<security>WPA2-Enterprise</security>
<trustedRootCA>a2 91 34 aa 22 3a a2 3a 4a 78 a2 aa 75 a2 34 2a 3a 11 4a aa</trustedRootCA>
<sig_quality>80</sig_quality>
</signal>
</rule>
```
## Deploying Multifactor Unlock
## Deploy Multifactor Unlock
>[!IMPORTANT]
>You need to remove all third party credential providers to ensure users cannot unlock their devices if they do not have the required factors. The fall back options are to use passwords or smart cards (both of which could be disabled as needed).
### How to configure Multifactor Unlock policy settings
You need at least a Windows 10, version 1709 or later workstation to run the Group Policy Management Console, which provides the latest Windows Hello for Business Group Policy settings, which includes multi-factor unlock. To run the Group Policy Management Console, you need to install the Remote Server Administration Tools for Windows. You can download these tools from the [Microsoft Download Center](https://www.microsoft.com/download/details.aspx?id=45520). Install the Remote Server Administration Tools for Windows on a computer running Windows 10, version 1709 or later.
Alternatively, you can create copy the .ADMX and .ADML files from a Windows 10, version 1703 to their respective language folder on a Windows Server or you can create a Group Policy Central Store and copy them their respective language folder. See [How to create and manage the Central Store for Group Policy Administrative Templates in Windows](/troubleshoot/windows-client/group-policy/create-and-manage-central-store) for more information.
### Create the Multifactor Unlock Group Policy object
The Group Policy object contains the policy settings needed to trigger Windows Hello for Business provisioning and to ensure Windows Hello for Business authentication certificates are automatically renewed.
>[!IMPORTANT]
> * PIN **must** be in at least one of the groups
> * Trusted signals **must** be combined with another credential provider
> * You cannot use the same unlock factor to satisfy both categories. Therefore, if you include any credential provider in both categories, it means it can satisfy either category, but not both.
> * The multifactor unlock feature is also supported via the Passport for Work CSP. See [Passport For Work CSP](/windows/client-management/mdm/passportforwork-csp) for more information.
>
> - PIN **must** be in at least one of the groups
> - Trusted signals **must** be combined with another credential provider
> - You cannot use the same unlock factor to satisfy both categories. Therefore, if you include any credential provider in both categories, it means it can satisfy either category, but not both
> - The multifactor unlock feature is also supported via the Passport for Work CSP. For more information, see [Passport For Work CSP](/windows/client-management/mdm/passportforwork-csp).
1. Start the **Group Policy Management Console** (gpmc.msc).
1. Start the **Group Policy Management Console** (`gpmc.msc`).
1. Expand the domain and select the **Group Policy Object** node in the navigation pane.
1. Right-click **Group Policy object** and select **New**.
1. Type *Multifactor Unlock* in the name box and select **OK**.
1. In the content pane, right-click the **Multifactor Unlock** Group Policy object and select **Edit**.
1. In the navigation pane, expand **Policies** under **Computer Configuration**.
1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
![Group Policy Editor.](images/multifactorUnlock/gpme.png)
1. In the content pane, open **Configure device unlock factors**. Select **Enable**. The **Options** section populates the policy setting with default values.
![Multifactor Policy Setting.](images/multifactorUnlock/gp-setting.png)
1. Configure first and second unlock factors using the information in [Configure Unlock Factors](#configure-unlock-factors).
1. If using trusted signals, configure the trusted signals used by the unlock factor using the information in [Configure Signal Rules for the Trusted Signal Credential Provider](#configure-signal-rules-for-the-trusted-signal-credential-provider).
1. Select **OK** to close the **Group Policy Management Editor**. Use the **Group Policy Management Console** to deploy the newly created Group Policy object to your organization's computers.
2. Expand the domain and select the **Group Policy Object** node in the navigation pane.
## Troubleshoot
3. Right-click **Group Policy object** and select **New**.
4. Type *Multifactor Unlock* in the name box and click **OK**.
5. In the content pane, right-click the **Multifactor Unlock** Group Policy object and click **Edit**.
6. In the navigation pane, expand **Policies** under **Computer Configuration**.
7. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business**.
![Group Policy Editor.](images/multifactorUnlock/gpme.png)
8. In the content pane, double-click **Configure device unlock factors**. Click **Enable**. The **Options** section populates the policy setting with default values.
![Multifactor Policy Setting.](images/multifactorUnlock/gp-setting.png)
9. Configure first and second unlock factors using the information in [Configure Unlock Factors](#configuring-unlock-factors).
10. If using trusted signals, configure the trusted signals used by the unlock factor using the information in [Configure Signal Rules for the Trusted Signal Credential Provider](#configure-signal-rules-for-the-trusted-signal-credential-provider).
11. Click **OK** to close the **Group Policy Management Editor**. Use the **Group Policy Management Console** to deploy the newly created Group Policy object to your organization's computers.
## Troubleshooting
Multi-factor unlock writes events to event log under **Application and Services Logs\Microsoft\Windows\HelloForBusiness** with the category name **Device Unlock**.
### Events

2
windows/security/identity-protection/hello-for-business/hello-faq.yml
View File

@ -8,7 +8,7 @@ metadata:
- highpri
- tier1
ms.topic: faq
ms.date: 01/06/2023
ms.date: 03/09/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>

2
windows/security/identity-protection/hello-for-business/hello-videos.md
View File

@ -1,7 +1,7 @@
---
title: Windows Hello for Business Videos
description: View several informative videos describing features and experiences in Windows Hello for Business in Windows 10 and Windows 11.
ms.date: 07/26/2022
ms.date: 03/09/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
ms.topic: article

3
windows/security/identity-protection/hello-for-business/index.yml
View File

@ -12,8 +12,7 @@ metadata:
author: paolomatarazzo
ms.author: paoloma
manager: aaroncz
ms.reviewer: prsriva
ms.date: 01/22/2021
ms.date: 03/09/2023
ms.collection:
- highpri
- tier1

2
windows/security/identity-protection/hello-for-business/webauthn-apis.md
View File

@ -1,7 +1,7 @@
---
title: WebAuthn APIs
description: Learn how to use WebAuthn APIs to enable passwordless authentication for your sites and apps.
ms.date: 09/15/2022
ms.date: 03/09/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10 and later</a>
ms.topic: article