deepblue/windows-itpro-docs
1
0
Fork 0
mirror of https://github.com/MicrosoftDocs/windows-itpro-docs.git synced 2025-05-12 13:27:23 +00:00
Code Issues Actions 2 Packages Projects Releases Wiki Activity

refresh

Browse Source
This commit is contained in:
Paolo Matarazzo 2023-12-22 10:44:53 -05:00
parent 1247496161
commit 4aa19482d1
95 changed files with 1709 additions and 2126 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

145
windows/security/identity-protection/hello-for-business/configure.md Normal file
View File

@ -0,0 +1,145 @@
---
title: Configure Windows Hello for Business
description: Learn about the configuration options for Windows Hello for Business and how to implement them in your organization.
ms.topic: how-to
ms.date: 12/19/2023
---
# Configure Windows Hello for Business
Windows Hello for Business offers a variety of configuration options to accommodate the needs of your organization. This article describes the configuration options and how to implement them.
## Configuration options
You can configure Windows Hello for Business by using the following options:
- Configuration Service Provider (CSP): commonly used for devices managed by a Mobile Device Management (MDM) solution, like Microsoft Intune. To configure Windows Hello for Business, you use the [PassportForWork CSP][CSP-2]
- Group policy (GPO): used for devices that are Active Directory joined or Microsoft Entra hybrid joined, and aren't managed by a device management solution
- Provisioning packages: used to configure devices at deployment time or for devices that aren't managed by a device management solution
### Policy precedence
Some of the Windows Hello for Business policies are available for both computer and user configuration.
*user policies* take precedence over *computer policies*. If a user policy is set, the corresponded computer policy is ignored. If a user policy is not set, the computer policy is used.
Policies for Windows Hello for Business are enforced using the following hierarchy:
- User GPO > Computer GPO > User MDM > Device MDM > Device Lock policy
>[!IMPORTANT]
>All devices only have one PIN associated with Windows Hello for Business. This means that any PIN on a device will be subject to the policies specified in the PassportForWork CSP. The values specified take precedence over any complexity rules set via Exchange ActiveSync (EAS) or the DeviceLock CSP.
>[!NOTE]
> If a policy isn't explicitly configured to require letters or special characters, users can optionally set an alphanumeric PIN.
### Retrieve the Microsoft Entra tenant ID
The configuration via CSP or registry of different Windows Hello for Business policy settings require to specify the Microsoft Entra tenant ID where the device is registered.
To look up your Tenant ID, see [How to find your Microsoft Entra tenant ID][ENTRA-2] or try the following, ensuring to sign in with your organization's account:
```msgraph-interactive
GET https://graph.microsoft.com/v1.0/organization?$select=id
```
For example, the [PassportForWork CSP documentation][CSP-1] describes how to configure Windows Hello for Business options using the OMA-URI:
```Device
./Device/Vendor/MSFT/PassportForWork/{TenantId}
```
When configuring devices, replace `TenantID` with your Microsoft Entra tenant ID. For example, if your Microsoft Entra tenant ID is `dcd219dd-bc68-4b9b-bf0b-4a33a796be35`, the OMA-URI would be:
```Device
./Device/Vendor/MSFT/PassportForWork/{dcd219dd-bc68-4b9b-bf0b-4a33a796be35}
```
## Configure Windows Hello for Business using Microsoft Intune
For Microsoft Entra joined devices and Microsoft Entra hybrid joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business.
There are different ways to enable and configure Windows Hello for Business in Intune:
- Using a policy applied at the tenant level. The tenant policy:
- Is only applied at enrollment time, and any changes to its configuration won't apply to devices already enrolled in Intune
- It applies to *all devices* getting enrolled in Intune. For this reason, the policy is usually disabled and Windows Hello for Business is enabled using a policy targeted to a security group
- A device configuration policy that is applied *after* device enrollment. Any changes to the policy will be applied to the devices during regular policy refresh intervals. There are different policy types to choose from:
- [Settings catalog][MEM-1]
- [Security baselines][MEM-2]
- [Custom policy][MEM-3], via the [PassportForWork CSP][MEM-4]
- [Account protection policy][MEM-5]
- [Identity protection policy template][MEM-6]
### Verify the tenant-wide policy
To check the Windows Hello for Business policy applied at enrollment time:
1. Sign in to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431).
1. Select **Devices** > **Windows** > **Windows Enrollment**
1. Select **Windows Hello for Business**
1. Verify the status of **Configure Windows Hello for Business** and any settings that may be configured
:::image type="content" source="images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Intune admin center." lightbox="images/whfb-intune-disable.png":::
If the tenant-wide policy is enabled and configured to your needs, you can skip to [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business). Otherwise, follow the instructions below to create a policy using an *account protection* policy.
## Policy conflicts from multiple policy sources
Windows Hello for Business is designed to be managed by group policy or MDM, but not a combination of both. Avoid mixing group policy and MDM policy settings for Windows Hello for Business. If you mix group policy and MDM policy settings, the MDM settings are ignored until all group policy settings are cleared.
> [!IMPORTANT]
> The [*MDMWinsOverGP*](/windows/client-management/mdm/policy-csp-controlpolicyconflict#mdmwinsovergp) policy setting doesn't apply to Windows Hello for Business. MDMWinsOverGP only applies to policies in the *Policy CSP*, while the Windows Hello for Business policies are in the *PassportForWork CSP*.
## Manage Windows Hello for Business in your organization
You can create a Group Policy or mobile device management (MDM) policy to configure Windows Hello for Business on Windows devices.
## Disable Windows Hello for Business enrollment
Windows Hello for Business is enabled by default for devices that are Microsoft Entra joined. If you need to disable the automatic enablement, there are different options to configure them.
### Disable during OS deployment
If you don't use Intune in your organization, then you can disable Windows Hello for Business using the registry. You can use a third-party MDM, or some other method that you use to manage these devices. Because these systems are Microsoft Entra joined only, and not domain joined, these settings can also be made manually in the registry.
Intune uses the following registry keys: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\Device\Policies`**
These registry settings are pushed from Intune for user policies:
- Intune User Policy: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\UserSid\Policies`**
- DWORD: **UsePassportForWork**
- Value = **0** for Disable, or Value = **1** for Enable
These registry settings can be applied from Local or Group Policies:
- Local/GPO User Policy: **`HKEY_USERS\UserSID\SOFTWARE\Policies\Microsoft\PassportForWork`**
- Local/GPO Device Policy: **`HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork`**
- DWORD: **Enabled**
- Value = **0** for Disable or Value = **1** for Enable
If there's a conflicting Device policy and User policy, the User policy would take precedence. We don't recommend creating Local/GPO registry settings that could conflict with an Intune policy. This conflict could lead to unexpected results.
## Next steps
Learn more about Windows Hello for Business features and how to configure them:
- [PIN reset](pin-reset.md)
- [Dual enrollment](hello-feature-dual-enrollment.md)
- [Dynamic Lock](hello-feature-dynamic-lock.md)
- [Multi-factor Unlock](multifactor-unlock.md)
- [Remote desktop (RDP) sign-in](rdp-sign-in.md)
<!--links-->
[CSP-1]: /windows/client-management/mdm/passportforwork-csp#devicetenantid
[CSP-2]: /windows/client-management/mdm/passportforwork-csp
[ENTRA-1]: /entra/identity/conditional-access/overview
[ENTRA-2]: /entra/fundamentals/how-to-find-tenant
[MEM-1]: /mem/intune/configuration/settings-catalog
[MEM-2]: /mem/intune/protect/security-baselines
[MEM-3]: /mem/intune/configuration/custom-settings-configure
[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy
[MEM-6]: /mem/intune/protect/identity-protection-configure

27
windows/security/identity-protection/hello-for-business/deploy/cloud.md
View File

@ -21,7 +21,7 @@ You may wish to disable the automatic Windows Hello for Business enrollment prom
Cloud only deployments will use Microsoft Entra multifactor authentication (MFA) during Windows Hello for Business enrollment, and there's no additional MFA configuration needed. If you aren't already registered in MFA, you'll be guided through the MFA registration as part of the Windows Hello for Business enrollment process.
The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](requirements.md#azure-ad-cloud-only-deployment).
The necessary Windows Hello for Business prerequisites are located at [Cloud Only Deployment](requirements.md#microsoft-entra-cloud-only-deployment).
It's possible for federated domains to configure the *FederatedIdpMfaBehavior* flag. The flag instructs Microsoft Entra ID to accept, enforce, or reject the MFA challenge from the federated IdP. For more information, see [federatedIdpMfaBehavior values](/graph/api/resources/internaldomainfederation#federatedidpmfabehavior-values). To check this setting, use the following PowerShell command:
@ -56,29 +56,4 @@ The following method explains how to disable Windows Hello for Business enrollme
> [!NOTE]
> This policy is only applied during new device enrollments. For currently enrolled devices, you can [set the same settings in a device configuration policy](../hello-manage-in-organization.md).
## Disable Windows Hello for Business enrollment without Intune
If you don't use Intune in your organization, then you can disable Windows Hello for Business using the registry. You can use a third-party MDM, or some other method that you use to manage these devices. Because these systems are Microsoft Entra joined only, and not domain joined, these settings can also be made manually in the registry.
Intune uses the following registry keys: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\Device\Policies`**
To look up your Tenant ID, see [How to find your Microsoft Entra tenant ID](/azure/active-directory/fundamentals/how-to-find-tenant) or try the following, ensuring to sign in with your organization's account:
```msgraph-interactive
GET https://graph.microsoft.com/v1.0/organization?$select=id
```
These registry settings are pushed from Intune for user policies:
- Intune User Policy: **`HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\<Tenant-ID>\UserSid\Policies`**
- DWORD: **UsePassportForWork**
- Value = **0** for Disable, or Value = **1** for Enable
These registry settings can be applied from Local or Group Policies:
- Local/GPO User Policy: **`HKEY_USERS\UserSID\SOFTWARE\Policies\Microsoft\PassportForWork`**
- Local/GPO Device Policy: **`HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork`**
- DWORD: **Enabled**
- Value = **0** for Disable or Value = **1** for Enable
If there's a conflicting Device policy and User policy, the User policy would take precedence. We don't recommend creating Local/GPO registry settings that could conflict with an Intune policy. This conflict could lead to unexpected results.

8
windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-adfs.md
View File

@ -1,13 +1,7 @@
---
title: Configure Active Directory Federation Services in a hybrid certificate trust model
description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business hybrid certificate trust model.
description: Learn how to configure Active Directory Federation Services (AD FS) to support the Windows Hello for Business hybrid certificate trust model.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---

6
windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md
View File

@ -2,12 +2,6 @@
title: Configure and provision Windows Hello for Business in a hybrid certificate trust model
description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid certificate trust scenario.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---

14
windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki.md
View File

@ -1,13 +1,7 @@
---
title: Configure and validate the PKI in an hybrid certificate trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid certificate trust model.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.date: 12/18/2023
ms.topic: tutorial
---
# Configure and validate the PKI in a hybrid certificate trust model
@ -22,7 +16,7 @@ Hybrid certificate trust deployments issue users a sign-in certificate, enabling
## Configure the enterprise PKI
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
[!INCLUDE [dc-certificate-template](includes/certificate-template-dc.md)]
> [!NOTE]
> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for Microsoft Entra hybrid joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Microsoft Entra joined devices.
@ -35,9 +29,9 @@ Hybrid certificate trust deployments issue users a sign-in certificate, enabling
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)]
[!INCLUDE [enrollment-agent-certificate-template](includes/certificate-template-enrollment-agent.md)]
[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)]
[!INCLUDE [auth-certificate-template](includes/certificate-template-auth.md)]
[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]

18
windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust.md
View File

@ -1,29 +1,19 @@
---
title: Windows Hello for Business hybrid certificate trust deployment
description: Learn how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.date: 12/18/2023
ms.topic: tutorial
---
# Hybrid certificate trust deployment
# Hybrid certificate trust deployment guide
[!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Microsoft Entra protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid certificate trust scenario.
This deployment guide describes how to deploy Windows Hello for Business with a hybrid certificate trust model.
> [!IMPORTANT]
> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. It is also the recommended deployment model if you don't need to deploy certificates to the end users. For more information, see [cloud Kerberos trust deployment](hybrid-cloud-kerberos-trust.md).
It's recommended that you review the [Windows Hello for Business planning guide](../hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.
## Prerequisites
> [!div class="checklist"]
@ -44,7 +34,7 @@ Hybrid Windows Hello for Business needs two directories:
- A Microsoft Entra tenant with a Microsoft Entra ID P1 or P2 subscription
The two directories must be synchronized with [Microsoft Entra Connect Sync][AZ-1], which synchronizes user accounts from the on-premises Active Directory to Microsoft Entra ID.
The hybrid-certificate trust deployment needs a *Microsoft Entra ID P1 or P2* subscription because it uses the device write-back synchronization feature.
A *Microsoft Entra ID P1 or P2* subscription is required for the device write-back synchronization feature.
> [!NOTE]
> Windows Hello for Business hybrid certificate trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Microsoft Entra ID.

6
windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll.md
View File

@ -2,8 +2,6 @@
title: Windows Hello for Business cloud Kerberos trust clients configuration and enrollment
description: Learn how to configure devices and enroll them in Windows Hello for Business in a cloud Kerberos trust scenario.
ms.date: 02/24/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10, version 21H2 and later</a>
ms.topic: tutorial
---
# Configure and provision Windows Hello for Business - cloud Kerberos trust
@ -17,8 +15,6 @@ Deploying Windows Hello for Business cloud Kerberos trust consists of two steps:
1. Set up Microsoft Entra Kerberos.
1. Configure a Windows Hello for Business policy and deploy it to the devices.
<a name='deploy-azure-ad-kerberos'></a>
### Deploy Microsoft Entra Kerberos
If you've already deployed on-premises SSO for passwordless security key sign-in, then you've already deployed Microsoft Entra Kerberos in your hybrid environment. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business and you can skip this section.
@ -174,7 +170,7 @@ Once a user has set up a PIN with cloud Kerberos trust, it can be used **immedia
If you deployed Windows Hello for Business using the key trust model, and want to migrate to the cloud Kerberos trust model, follow these steps:
1. [Set up Microsoft Entra Kerberos in your hybrid environment](#deploy-azure-ad-kerberos).
1. [Set up Microsoft Entra Kerberos in your hybrid environment](#deploy-microsoft-entra-kerberos).
1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy).
1. For Microsoft Entra joined devices, sign out and sign in to the device using Windows Hello for Business.

18
windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust.md
View File

@ -2,15 +2,14 @@
title: Windows Hello for Business cloud Kerberos trust deployment
description: Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario.
ms.date: 02/24/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10, version 21H2 and later</a>
ms.topic: tutorial
---
# Cloud Kerberos trust deployment
[!INCLUDE [apply-to-hybrid-cloud-kerberos-trust](includes/apply-to-hybrid-cloud-kerberos-trust.md)]
Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in a *cloud Kerberos trust* scenario.
This deployment guide provides the information to deploy Windows Hello for Business in a *cloud Kerberos trust* scenario.
## Introduction to cloud Kerberos trust
@ -25,8 +24,6 @@ Windows Hello for Business cloud Kerberos trust uses *Microsoft Entra Kerberos*,
> [!NOTE]
> Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
<a name='azure-ad-kerberos-and-cloud-kerberos-trust-authentication'></a>
## Microsoft Entra Kerberos and cloud Kerberos trust authentication
*Key trust* and *certificate trust* use certificate authentication-based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust.
@ -45,7 +42,7 @@ When Microsoft Entra Kerberos is enabled in an Active Directory domain, an *Azur
:::image type="content" source="images/azuread-kerberos-object.png" alt-text="Active Directory Users and Computers console, showing the computer object representing the Microsoft Entra Kerberos server ":::
For more information about how Microsoft Entra Kerberos enables access to on-premises resources, see [enabling passwordless security key sign-in to on-premises resources][AZ-1].\
For more information about how Microsoft Entra Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](../hello-how-it-works-authentication.md#hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust).
For more information about how Microsoft Entra Kerberos works with Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business authentication technical deep dive](../hello-how-it-works-authentication.md#microsoft-entra-hybrid-join-authentication-using-cloud-kerberos-trust).
> [!IMPORTANT]
> When implementing the cloud Kerberos trust deployment model, you *must* ensure that you have an adequate number of *read-write domain controllers* in each Active Directory site where users will be authenticating with Windows Hello for Business. For more information, see [Capacity planning for Active Directory][SERV-1].
@ -66,7 +63,7 @@ The following scenarios aren't supported using Windows Hello for Business cloud
- On-premises only deployments
- RDP/VDI scenarios using supplied credentials (RDP/VDI can be used with Remote Credential Guard or if a certificate is enrolled into the Windows Hello for Business container)
- Using cloud Kerberos trust for "Run as"
- Using cloud Kerberos trust for *Run as*
- Signing in with cloud Kerberos trust on a Microsoft Entra hybrid joined device without previously signing in with DC connectivity
> [!NOTE]
@ -79,9 +76,10 @@ The following scenarios aren't supported using Windows Hello for Business cloud
Once the prerequisites are met, deploying Windows Hello for Business with a cloud Kerberos trust model consists of the following steps:
> [!div class="checklist"]
> * Deploy Microsoft Entra Kerberos
> * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients
>
> - Deploy Microsoft Entra Kerberos
> - Configure Windows Hello for Business settings
> - Provision Windows Hello for Business on Windows clients
> [!div class="nextstepaction"]
> [Next: configure and provision Windows Hello for Business >](hybrid-cloud-kerberos-trust-enroll.md)

6
windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md
View File

@ -54,7 +54,7 @@ To configure Windows Hello for Business using an *account protection* policy:
1. Specify a **Name** and, optionally, a **Description** > **Next**
1. Under *Block Windows Hello for Business*, select **Disabled** and multiple policies become available
- These policies are optional to configure, but it's recommended to configure *Enable to use a Trusted Platform Module (TPM)* to **Yes**
- For more information about these policies, see [MDM policy settings for Windows Hello for Business](../hello-manage-in-organization.md#mdm-policy-settings-for-windows-hello-for-business)
- For more information about these policies, see [Configure Windows Hello for Business](../configure.md)
1. Select **Next**
1. Optionally, add *scope tags* > **Next**
1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next**
@ -72,7 +72,7 @@ It's suggested to create a security group (for example, *Windows Hello for Busin
The Windows Hello for Business Group Policy object delivers the correct Group Policy settings to the user, which enables them to enroll and use Windows Hello for Business to authenticate to Azure and Active Directory
> [!NOTE]
> If you deployed Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources)
> If you deployed Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources)
### Enable Windows Hello for Business group policy setting
@ -101,7 +101,7 @@ Sign-in a domain controller or management workstations with *Domain Admin* equiv
> [!NOTE]
> Windows Hello for Business can be configured using different policies. These policies are optional to configure, but it's recommended to enable *Use a hardware security device*.
>
> For more information about these policies, see [Group Policy settings for Windows Hello for Business](../hello-manage-in-organization.md#group-policy-settings-for-windows-hello-for-business).
> For more information about these policies, see [Configure Windows Hello for Business](../configure.md).
### Configure security for GPO

15
windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-pki.md
View File

@ -1,15 +1,10 @@
---
title: Configure and validate the Public Key Infrastructure in a hybrid key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a hybrid key trust model.
ms.date: 01/03/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
title: Configure and validate the Public Key Infrastructure in an hybrid key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in an hybrid key trust model.
ms.date: 12/18/2023
ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - hybrid key trust
[!INCLUDE [apply-to-hybrid-key-trust](includes/apply-to-hybrid-key-trust.md)]
@ -46,7 +41,7 @@ Sign in using *Enterprise Administrator* equivalent credentials on a Windows Ser
## Configure the enterprise PKI
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
[!INCLUDE [dc-certificate-template](includes/certificate-template-dc.md)]
> [!NOTE]
> Inclusion of the *KDC Authentication* OID in domain controller certificate is not required for Microsoft Entra hybrid joined devices. The OID is required for enabling authentication with Windows Hello for Business to on-premises resources by Microsoft Entra joined devices.

52
windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust.md
View File

@ -1,39 +1,30 @@
---
title: Windows Hello for Business hybrid key trust deployment
description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario.
ms.date: 12/28/2022
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: how-to
ms.date: 12/18/2023
ms.topic: tutorial
---
# Hybrid key trust deployment
# Hybrid key trust deployment guide
[!INCLUDE [apply-to-hybrid-key-trust](includes/apply-to-hybrid-key-trust.md)]
Hybrid environments are distributed systems that enable organizations to use on-premises and Microsoft Entra protected resources. Windows Hello for Business uses the existing distributed system as a foundation on which organizations can provide two-factor authentication and single sign-on to modern resources.
This deployment guide describes how to deploy Windows Hello for Business in a hybrid key trust scenario.
This deployment guide describes how to deploy Windows Hello for Business with a hybrid key trust model.
> [!IMPORTANT]
> Windows Hello for Business *cloud Kerberos trust* is the recommended deployment model when compared to the *key trust model*. For more information, see [cloud Kerberos trust deployment](hybrid-cloud-kerberos-trust.md).
It is recommended that you review the [Windows Hello for Business planning guide](../hello-planning-guide.md) prior to using the deployment guide. The planning guide helps you make decisions by explaining the available options with each aspect of the deployment and explains the potential outcomes based on each of these decisions.
## Prerequisites
The following prerequisites must be met for a hybrid key trust deployment:
> [!div class="checklist"]
> * Directories and directory synchronization
> * Authentication to Microsoft Entra ID
> * Device registration
> * Public Key Infrastructure
> * Multifactor authentication
> * Device management
>The following prerequisites must be met for a hybrid key trust deployment:
>
> - Directories and directory synchronization
> - Authentication to Microsoft Entra ID
> - Device registration
> - Public Key Infrastructure
> - Multifactor authentication
> - Device management
### Directories and directory synchronization
@ -48,7 +39,8 @@ During the Window Hello for Business provisioning process, users register the pu
> [!NOTE]
> Windows Hello for Business hybrid key trust is not supported if the users' on-premises UPN suffix cannot be added as a verified domain in Microsoft Entra ID.
<a name='authentication-to-azure-ad'></a>
> [!IMPORTANT]
> Windows Hello for Business is tied between a user and a device. Both the user and device object must be synchronized between Microsoft Entra ID and Active Directory.
### Authentication to Microsoft Entra ID
@ -66,8 +58,6 @@ For *Microsoft Entra hybrid joined* devices, review the guidance on the [Plan yo
An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them.
<a name='multi-factor-authentication'></a>
### Multifactor authentication
The Windows Hello for Business provisioning process lets a user enroll in Windows Hello for Business using their user name and password as one factor, but requires a second factor of authentication.\
@ -85,13 +75,13 @@ To configure Windows Hello for Business, devices can be configured through a mob
## Next steps
Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
> [!div class="checklist"]
> * Configure and validate the PKI
> * Configure Windows Hello for Business settings
> * Provision Windows Hello for Business on Windows clients
> * Configure single sign-on (SSO) for Microsoft Entra joined devices
> Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps:
>
> - Configure and validate the PKI
> - Configure Windows Hello for Business settings
> - Provision Windows Hello for Business on Windows clients
> - Configure single sign-on (SSO) for Microsoft Entra joined devices
> [!div class="nextstepaction"]
> [Next: configure and validate the Public Key Infrastructure >](hybrid-key-trust-pki.md)

95
windows/security/identity-protection/hello-for-business/deploy/includes/adfs-additional-servers.md Normal file
View File

@ -0,0 +1,95 @@
---
ms.date: 12/15/2023
ms.topic: include
---
## Additional federation servers
Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
### Server authentication certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
### Install additional servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
## Load balance AD FS
Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
### Install Network Load Balancing Feature on AD FS Servers
Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
1. Start **Server Manager**. Select **Local Server** in the navigation pane
1. Select **Manage** and then select **Add Roles and Features**
1. Select **Next** On the **Before you begin** page
1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
1. On the **Select server roles** page, select **Next**
1. Select **Network Load Balancing** on the **Select features** page
1. Select **Install** to start the feature installation
### Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
Sign-in a node of the federation farm with *Administrator* equivalent credentials.
1. Open **Network Load Balancing Manager** from **Administrative Tools**
1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
1. In Port Rules, select Edit to modify the default port rules to use port 443
### Additional AD FS Servers
1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
## Configure DNS for Device Registration
Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
1. Open the **DNS Management** console
1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
1. Right-click the `<domain_name>` node and select **New Alias (CNAME)**
1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.<domain_name_fqdn`, and select OK
1. Close the DNS Management console
> [!NOTE]
> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.<upnsuffix_fqdn>` is present for each suffix.
## Configure the Intranet Zone to include the federation service
The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
### Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation with *Domain Admin* equivalent credentials:
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 **Intranet Zone Settings** in the name box and select **OK**
1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
1. In the navigation pane, expand **Policies** under **Computer Configuration**
1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
### Deploy the Intranet Zone Group Policy object
1. Start the **Group Policy Management Console** (gpmc.msc)
1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
1. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**

95
windows/security/identity-protection/hello-for-business/deploy/includes/adfs-deploy.md Normal file
View File

@ -0,0 +1,95 @@
---
ms.date: 12/15/2023
ms.topic: include
---
## Deploy the AD FS role
>[!IMPORTANT]
> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
1. Start **Server Manager**. Select **Local Server** in the navigation pane
1. Select **Manage > Add Roles and Features**
1. Select **Next** on the **Before you begin** page
1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
1. Select **Next** on the **Select features** page
1. Select **Next** on the **Active Directory Federation Service** page
1. Select **Install** to start the role installation
## Review to validate the AD FS deployment
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Confirm the AD FS farm uses the correct database configuration
> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
> * Confirm **all** AD FS servers in the farm have the latest updates installed
> * Confirm all AD FS servers have a valid server authentication certificate
## Device registration service account prerequisites
The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
### Create KDS Root Key
Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
Start an elevated PowerShell console and execute the following command:
```PowerShell
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```
## Configure the Active Directory Federation Service Role
Use the following procedures to configure AD FS.
Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
1. Start **Server Manager**
1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
1. On the **Welcome** page, select **Create the first federation server farm > Next**
1. On the **Connect to Active Directory Domain Services** page, select **Next**
1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
1. Select the federation service name from the **Federation Service Name** list
1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
1. On the **Review Options** page, select **Next**
1. On the **Pre-requisite Checks** page, select **Configure**
1. When the process completes, select **Close**
### Add the AD FS service account to the *Key Admins* group
During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
1. Open **Active Directory Users and Computers**
1. Select the **Users** container in the navigation pane
1. Right-click **Key Admins** in the details pane and select **Properties**
1. Select the **Members > Add…**
1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
1. Select **OK** to return to **Active Directory Users and Computers**
1. Change to server hosting the AD FS role and restart it
## Configure the device registration service
Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
1. Open the **AD FS management** console
1. In the navigation pane, expand **Service**. Select **Device Registration**
1. In the details pane, select **Configure device registration**
1. In the **Configure Device Registration** dialog, Select **OK**
:::image type="content" source="../images/adfs-device-registration.png" lightbox="../images/adfs-device-registration.png" alt-text="Screenshot that shows AD FS device registration: configuration of the service connection point.":::
Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
:::image type="content" source="../images/adfs-scp.png" lightbox="../images/adfs-scp.png" alt-text="Screenshot that shows AD FS device registration: service connection point object created by AD FS.":::

19
windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-mfa.md → windows/security/identity-protection/hello-for-business/deploy/includes/adfs-mfa.md
View File

@ -1,19 +1,9 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with key trust
description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises key trust model.
ms.date: 09/07/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
ms.date: 12/15/2023
ms.topic: include
---
# Validate and deploy multifactor authentication - on-premises key trust
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
## Validate and deploy multifactor authentication (MFA)
Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
@ -27,6 +17,3 @@ Windows Hello for Business requires users perform multifactor authentication (MF
For information on available third-party authentication methods see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). For creating a custom authentication method see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method)
Follow the integration and deployment guide for the authentication provider you select to integrate and deploy it to AD FS. Make sure that the authentication provider is selected as a multifactor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
> [!div class="nextstepaction"]
> [Next: configure Windows Hello for Business Policy settings](on-premises-key-trust-enroll.md)

47
windows/security/identity-protection/hello-for-business/deploy/includes/adfs-validate.md Normal file
View File

@ -0,0 +1,47 @@
---
ms.date: 12/15/2023
ms.topic: include
---
The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
Prepare the AD FS deployment by installing and **updating** two Windows Servers.
## Enroll for a TLS server authentication certificate
Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
- **Subject Name**: the internal FQDN of the federation server
- **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
### AD FS authentication certificate enrollment
Sign-in the federation server with *domain administrator* equivalent credentials.
1. Start the Local Computer **Certificate Manager** (certlm.msc)
1. Expand the **Personal** node in the navigation pane
1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
1. Select **Next** on the **Before You Begin** page
1. Select **Next** on the **Select Certificate Enrollment Policy** page
1. On the **Request Certificates** page, select the **Internal Web Server** check box
1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
:::image type="content" source="../images/hello-internal-web-server-cert.png" lightbox="../images/hello-internal-web-server-cert.png" alt-text="Example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
1. Select **Enroll**
A server authentication certificate should appear in the computer's personal certificate store.

0
windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust-entra.md → windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust.md
View File

83
windows/security/identity-protection/hello-for-business/deploy/includes/auth-certificate-template.md
View File

@ -1,83 +0,0 @@
---
ms.date: 12/28/2022
ms.topic: include
---
### Configure a Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template.
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. Right-click the **Smartcard Logon** template and choose **Duplicate Template**
1. On the **Compatibility** tab:
- Clear the **Show resulting changes** check box
- Select **Windows Server 2016** from the **Certification Authority** list
- Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
1. On the **General** tab:
- Type *WHFB Authentication* in **Template display name**
- Adjust the validity and renewal period to meet your enterprise's needs
> [!NOTE]
> If you use different template names, you'll need to remember and substitute these names in different portions of the deployment.
1. On the **Cryptography** tab
- Select **Key Storage Provider** from the **Provider Category** list
- Select **RSA** from the **Algorithm name** list
- Type *2048* in the **Minimum key size** text box
- Select **SHA256** from the **Request hash** list
1. On the **Extensions** tab, verify the **Application Policies** extension includes **Smart Card Logon**
1. On the **Issuance Requirements** tab,
- Select the **This number of authorized signatures** check box. Type *1* in the text box
- Select **Application policy** from the **Policy type required in signature**
- Select **Certificate Request Agent** from in the **Application policy** list
- Select the **Valid existing certificate** option
1. On the **Subject** tab,
- Select the **Build from this Active Directory information** button
- Select **Fully distinguished name** from the **Subject name format** list
- Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
1. On the **Request Handling** tab, select the **Renew with same key** check box
1. On the **Security** tab, select **Add**. Target an Active Directory security group that contains the users that you want to enroll in Windows Hello for Business. For example, if you have a group called *Window Hello for Business Users*, type it in the **Enter the object names to select** text box and select **OK**
1. Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section:
- Select the **Allow** check box for the **Enroll** permission
- Excluding the group above (for example, *Window Hello for Business Users*), clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes aren't already cleared
- Select **OK**
1. If you previously issued Windows Hello for Business sign-in certificates using Configuration Manger and are switching to an AD FS registration authority, then on the **Superseded Templates** tab, add the previously used **Windows Hello for Business Authentication** template(s), so they'll be superseded by this template for the users that have Enroll permission for this template
1. Select on the **Apply** to save changes and close the console
#### Mark the template as the Windows Hello Sign-in template
Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials
Open an elevated command prompt end execute the following command
```cmd
certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY
```
If the template was changed successfully, the output of the command will contain old and new values of the template parameters. The new value must contain the `CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY` parameter. Example:
```cmd
CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=[yourdomain]:WHFBAuthentication
Old Value:
msPKI-Private-Key-Flag REG_DWORD = 5050080 (84213888)
CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
New Value:
msPKI-Private-Key-Flag REG_DWORD = 5250080 (86311040)
CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY -- 200000 (2097152)
TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
CertUtil: -dsTemplate command completed successfully."
```
>[!NOTE]
>If you gave your Windows Hello for Business Authentication certificate template a different name, then replace `WHFBAuthentication` in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the `Get-CATemplate` ADCS Administration Windows PowerShell cmdlet on your certification authority.
</details>

64
windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-auth.md Normal file
View File

@ -0,0 +1,64 @@
---
ms.date: 12/15/2023
ms.topic: include
---
### Configure a Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows clients request an authentication certificate from AD FS, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template.
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. In the **Certificate Template Console**, right-click the **Smartcard Logon** template and select **Duplicate Template**
1. Use the following table to configure the template:
| Tab Name | Configurations |
| --- | --- |
| *Compatibility* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2016** from the *Certification Authority list*</li><li>Select **Windows 10 / Windows Server 2016** from the *Certification Recipient list*</li></ul>|
| *General* | <ul><li>Specify a **Template display name**, for example *WHFB Authentication*</li><li>Set the validity period to the desired value</li><li>Take note of the template name for later, which should be the same as the Template display name minus spaces</li></ul>|
| *Subject Name* | <ul><li>Select **Build from this Active Directory information**</li><li>Select **Fully distinguished name** from the **Subject name format** list</li><li>Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**</li></ul>|
|*Cryptography*|<ul><li>Set the *Provider Category* to **Key Storage Provider**</li><li>Set the *Algorithm name* to **RSA**</li><li>Set the *minimum key size* to **2048**</li><li>Set the *Request hash* to **SHA256**</li>|
|*Extensions*|Verify the **Application Policies** extension includes **Smart Card Logon**|
|*Issuance Requirements*|<ul><li>Select the **This number of authorized signatures** check box. Type *1* in the text box</li><li>Select **Application policy** from the *Policy type required in signature*</li><li>Select **Certificate Request Agent** from in the *Application policy* list</li><li>Select the **Valid existing certificate** option</li></ul>|
|*Request Handling*|Select the **Renew with same key** check box|
|*Security*| <ul><li>Select **Add**</li><li>Target an Active Directory security group that contains the users that you want to enroll in Windows Hello for Business. For example, if you have a group called *Window Hello for Business Users*, type it in the **Enter the object names to select** text box and select **OK**</li><li>Select the **Windows Hello for Business Users** from the **Group or users names** list. In the **Permissions for Windows Hello for Business Users** section:<ul><li>Select the **Allow** check box for the **Enroll** permission</li><li>Excluding the group above (for example, *Window Hello for Business Users*), clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other entries in the **Group or users names** section if the check boxes aren't already cleared</li></ul><li>Select **OK**</li></ul>|
1. Select **OK** to finalize your changes and create the new template
1. Close the console
#### Mark the template as the Windows Hello Sign-in template
Sign in to a CA or management workstations with *Enterprise Administrator* equivalent credentials
Open an elevated command prompt end execute the following command
```cmd
certutil.exe -dsTemplate WHFBAuthentication msPKI-Private-Key-Flag +CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY
```
If the template was changed successfully, the output of the command will contain old and new values of the template parameters. The new value must contain the `CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY` parameter. Example:
```cmd
CN=Certificate Templates,CN=Public Key Services,CN=Services,CN=Configuration,DC=[yourdomain]:WHFBAuthentication
Old Value:
msPKI-Private-Key-Flag REG_DWORD = 5050080 (84213888)
CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
New Value:
msPKI-Private-Key-Flag REG_DWORD = 5250080 (86311040)
CTPRIVATEKEY_FLAG_REQUIRE_SAME_KEY_RENEWAL -- 80 (128)
CTPRIVATEKEY_FLAG_ATTEST_NONE -- 0
TEMPLATE_SERVER_VER_WINBLUE<<CTPRIVATEKEY_FLAG_SERVERVERSION_SHIFT -- 50000 (327680)
CTPRIVATEKEY_FLAG_HELLO_LOGON_KEY -- 200000 (2097152)
TEMPLATE_CLIENT_VER_WINBLUE<<CTPRIVATEKEY_FLAG_CLIENTVERSION_SHIFT -- 5000000 (83886080)
CertUtil: -dsTemplate command completed successfully."
```
>[!NOTE]
>If you gave your Windows Hello for Business Authentication certificate template a different name, then replace `WHFBAuthentication` in the above command with the name of your certificate template. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template using the Certificate Template management console (certtmpl.msc). Or, you can view the template name using the `Get-CATemplate` ADCS Administration Windows PowerShell cmdlet on your certification authority.

0
windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-template.md → windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc.md
View File

53
windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-enrollment-agent.md Normal file
View File

@ -0,0 +1,53 @@
---
ms.date: 12/15/2023
ms.topic: include
---
### Configure an enrollment agent certificate template
A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. Windows Hello for Business certificate trust deployments use AD FS as the CRA.
The CRA enrolls for an *enrollment agent certificate*. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request.
> [!IMPORTANT]
> Follow the procedures below based on the AD FS service account used in your environment.
#### Create an enrollment agent certificate for Group Managed Service Accounts (GMSA)
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template**
1. Use the following table to configure the template:
| Tab Name | Configurations |
| --- | --- |
| *Compatibility* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2016** from the *Certification Authority list*</li><li>Select **Windows 10 / Windows Server 2016** from the *Certification Recipient list*</li></ul> |
| *General* | <ul><li>Specify a **Template display name**, for example *WHFB Enrollment Agent*</li><li>Set the validity period to the desired value</li></ul>|
| *Subject Name* | Select **Supply in the request**<br><br>**Note:** Group Managed Service Accounts (GMSA) don't support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.|
| *Cryptography* | <ul><li>Set the *Provider Category* to **Key Storage Provider**</li><li>Set the *Algorithm name* to **RSA**</li><li>Set the *minimum key size* to **2048**</li><li>Set the *Request hash* to **SHA256**</li> |
| *Security* | <ul><li>Select **Add**</li><li>Select **Object Types** and select the **Service Accounts** check box</li><li> Select **OK**</li><li>Type `adfssvc` in the **Enter the object names to select** text box and select **OK**</li><li>Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:<ul><li>In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission</li><li>Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list</li></ul></li><li>Select **OK**</li></ul> |
1. Select **OK** to finalize your changes and create the new template
1. Close the console
#### Create an enrollment agent certificate for a standard service account
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template**
1. Use the following table to configure the template:
| Tab Name | Configurations |
| --- | --- |
| *Compatibility* | <ul><li>Clear the **Show resulting changes** check box</li><li>Select **Windows Server 2016** from the **Certification Authority** list</li><li>Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list</li></ul>|
| *General* | <ul><li>Specify a **Template display name**, for example *WHFB Enrollment Agent*</li><li>Set the validity period to the desired value</li></ul>|
| *Subject Name* | <ul><li>Select **Build from this Active Directory information**</li><li>Select **Fully distinguished name** from the **Subject name format** list</li><li>Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**</li></ul>|
|*Cryptography*|<ul><li>Set the *Provider Category* to **Key Storage Provider**</li><li>Set the *Algorithm name* to **RSA**</li><li>Set the *minimum key size* to **2048**</li><li>Set the *Request hash* to **SHA256**</li></ul>|
| *Security* | <ul><li>Select **Add**</li><li>Select **Object Types** and select the **Service Accounts** check box</li><li> Select **OK**</li><li>Type `adfssvc` in the **Enter the object names to select** text box and select **OK**</li><li>Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:<ul><li>In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission</li><li>Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list</li></ul></li><li>Select **OK**</li></ul> |
1. Select **OK** to finalize your changes and create the new template
1. Close the console

0
windows/security/identity-protection/hello-for-business/deploy/includes/web-server-certificate-template.md → windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-web-server.md
View File

1
windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-deployment.md
View File

@ -29,4 +29,3 @@ Sign in to domain controller or management workstations with *Domain Administrat
1. In the navigation pane, expand the domain and expand the node with the Active Directory domain name. Right-click the **Domain Controllers** organizational unit and select **Link an existing GPO…**
1. In the **Select GPO** dialog box, select *Domain Controller Auto Certificate Enrollment* or the name of the domain controller certificate enrollment Group Policy object you previously created
1. Select **OK**

18
windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-validate.md
View File

@ -11,14 +11,14 @@ Confirm your domain controllers enroll the correct certificates and not any supe
Sign in to domain controller or management workstations with *Domain Administrator* equivalent credentials.
1. Using the Event Viewer, navigate to the **Application and Services > Microsoft > Windows > CertificateServices-Lifecycles-System** event log
1. Using the Event Viewer, navigate to the **Application and Services** > **Microsoft** > **Windows** > **CertificateServices-Lifecycles-System** event log
1. Look for an event indicating a new certificate enrollment (autoenrollment):
- The details of the event include the certificate template on which the certificate was issued
- The name of the certificate template used to issue the certificate should match the certificate template name included in the event
- The certificate thumbprint and EKUs for the certificate are also included in the event
- The EKU needed for proper Windows Hello for Business authentication is Kerberos Authentication, in addition to other EKUs provide by the certificate template
Certificates superseded by your new domain controller certificate generate an archive event in the event log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
Certificates superseded by your new domain controller certificate generate an *archive event* in the Event Log. The archive event contains the certificate template name and thumbprint of the certificate that was superseded by the new certificate.
### Certificate Manager
@ -26,9 +26,17 @@ You can use the Certificate Manager console to validate the domain controller ha
### Certutil.exe
You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run `certutil.exe -q -store my` to view locally enrolled certificates.
You can use `certutil.exe` command to view enrolled certificates in the local computer. Certutil shows enrolled and archived certificates for the local computer. From an elevated command prompt, run the following command:
To view detailed information about each certificate in the store, use `certutil.exe -q -v -store my` to validate automatic certificate enrollment enrolled the proper certificates.
```cmd
certutil.exe -q -store my
```
To view detailed information about each certificate in the store, and to validate automatic certificate enrollment enrolled the proper certificates, use the following command:
```cmd
certutil.exe -q -v -store my
```
### Troubleshooting
@ -36,4 +44,4 @@ Windows triggers automatic certificate enrollment for the computer during boot,
Alternatively, you can forcefully trigger automatic certificate enrollment using `certreq.exe -autoenroll -q` from an elevated command prompt.
Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the allow auto enrollment permissions.
Use the event logs to monitor certificate enrollment and archive. Review the configuration, such as publishing certificate templates to issuing certification authority and the *allow* auto enrollment permissions.

79
windows/security/identity-protection/hello-for-business/deploy/includes/enrollment-agent-certificate-template.md
View File

@ -1,79 +0,0 @@
---
ms.date: 12/15/2023
ms.topic: include
---
### Configure an enrollment agent certificate template
A certificate registration authority (CRA) is a trusted authority that validates certificate request. Once it validates the request, it presents the request to the certification authority (CA) for issuance. The CA issues the certificate, returns it to the CRA, which returns the certificate to the requesting user. Windows Hello for Business certificate trust deployments use AD FS as the CRA.
The CRA enrolls for an *enrollment agent certificate*. Once the CRA verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the CA. The Windows Hello for Business Authentication certificate template is configured to only issue certificates to certificate requests that have been signed with an enrollment agent certificate. The CA only issues a certificate for that template if the registration authority signs the certificate request.
> [!IMPORTANT]
> Follow the procedures below based on the AD FS service account used in your environment.
#### Create an enrollment agent certificate for Group Managed Service Accounts (GMSA)
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template**
1. On the **Compatibility** tab:
- Clear the **Show resulting changes** check box
- Select **Windows Server 2016** from the **Certification Authority** list.
- Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
1. On the **General** tab:
- Type *WHFB Enrollment Agent* in **Template display name**
- Adjust the validity and renewal period to meet your enterprise's needs
1. On the **Subject** tab, select the **Supply in the request** button if it isn't already selected
> [!NOTE]
> Group Managed Service Accounts (GMSA) do not support the *Build from this Active Directory information* option and will result in the AD FS server failing to enroll the enrollment agent certificate. You must configure the certificate template with *Supply in the request* to ensure that AD FS servers can perform the automatic enrollment and renewal of the enrollment agent certificate.
1. On the **Cryptography** tab:
- Select **Key Storage Provider** from the **Provider Category** list
- Select **RSA** from the **Algorithm name** list
- Type *2048* in the **Minimum key size** text box
- Select **SHA256** from the **Request hash** list
1. On the **Security** tab, select **Add**
1. Select **Object Types** and select the **Service Accounts** check box. Select **OK**
1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK**
1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:
- In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission
- Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list
- Select **OK**
1. Close the console
#### Create an enrollment agent certificate for a standard service account
Sign in to a CA or management workstations with *Domain Administrator* equivalent credentials.
1. Open the **Certification Authority** management console
1. Right-click **Certificate Templates** and select **Manage**
1. In the **Certificate Template Console**, right-click on the **Exchange Enrollment Agent (Offline request)** template details pane and select **Duplicate Template**
1. On the **Compatibility** tab:
- Clear the **Show resulting changes** check box
- Select **Windows Server 2016** from the **Certification Authority** list.
- Select **Windows 10 / Windows Server 2016** from the **Certificate Recipient** list
1. On the **General** tab:
- Type *WHFB Enrollment Agent* in **Template display name**
- Adjust the validity and renewal period to meet your enterprise's needs
1. On the **Subject** tab:
- Select the **Build from this Active Directory information** button
- Select **Fully distinguished name** from the **Subject name format**
- Select the **User Principal Name (UPN)** check box under **Include this information in alternative subject name**
1. On the **Cryptography** tab:
- Select **Key Storage Provider** from the **Provider Category** list
- Select **RSA** from the **Algorithm name** list
- Type *2048* in the **Minimum key size** text box
- Select **SHA256** from the **Request hash** list
1. On the **Security** tab, select **Add**
1. Select **Object Types** and select the **Service Accounts** check box. Select **OK**
1. Type *adfssvc* in the **Enter the object names to select** text box and select **OK**
1. Select the **adfssvc** from the **Group or users names** list. In the **Permissions for adfssvc** section:
- In the **Permissions for adfssvc** section, select the **Allow** check box for the **Enroll** permission
- Excluding the **adfssvc** user, clear the **Allow** check box for the **Enroll** and **Autoenroll** permissions for all other items in the **Group or users names** list
- Select **OK**
1. Close the console

2
windows/security/identity-protection/hello-for-business/deploy/includes/intro.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
This document describes Windows Hello for Business functionalities or scenarios that apply to:
**This article describes Windows Hello for Business functionalities or scenarios that apply to:**

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-cloud.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[cloud :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#cloud-deployment "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM")
[cloud :::image type="icon" source="../images/information.svg" border="false":::](../../how-it-works.md#cloud-deployment "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-hybrid.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[hybrid :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM")
[hybrid :::image type="icon" source="../images/information.svg" border="false":::](../../how-it-works.md#hybrid-deployment "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-onpremises.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[on-premises :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy")
[on-premises :::image type="icon" source="../images/information.svg" border="false":::](../../how-it-works.md#on-premises-deployment "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-domain.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[domain join :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md)
[domain join :::image type="icon" source="../images/information.svg" border="false":::](../../how-it-works.md)

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-entra.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[Microsoft Entra join :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#azure-active-directory-join "Devices that are Microsoft Entra joined do not have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices")
[Microsoft Entra join :::image type="icon" source="../images/information.svg" border="false":::](../../how-it-works.md#microsoft-entra-join "Devices that are Microsoft Entra joined do not have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-hybrid.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[Microsoft Entra hybrid join :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#hybrid-azure-ad-join "Devices that are Microsoft Entra hybrid joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Microsoft Entra ID will have single-sign on to both Active Directory and Microsoft Entra protected resources")
[Microsoft Entra hybrid join :::image type="icon" source="../images/information.svg" border="false":::](../../how-it-works.md#microsoft-entra-hybrid-join "Devices that are Microsoft Entra hybrid joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices. Active Directory users that are synchronized to Microsoft Entra ID will have single-sign on to both Active Directory and Microsoft Entra protected resources")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cert.md
View File

@ -3,4 +3,4 @@ ms.date: 12/15/2023
ms.topic: include
---
[certificate trust :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#certificate-trust "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")
[certificate trust :::image type="icon" source="../images/information.svg" border="false":::](../index.md#trust-types "This trust type uses a certificate to authenticate the users to Active Directory. It's required to issue certificates to the users and to the domain controllers")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cloud-kerberos.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[cloud Kerberos trust :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#cloud-kerberos-trust "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that don't need certificate authentication")
[cloud Kerberos trust :::image type="icon" source="../images/information.svg" border="false":::](../index.md#trust-types "This trust type uses security keys to authenticate the users to Active Directory. It's not required to issue any certificates, making it the recommended choice for environments that don't need certificate authentication")

2
windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-key.md
View File

@ -3,4 +3,4 @@ ms.date: 12/08/2022
ms.topic: include
---
[key trust :::image type="icon" source="../images/information.svg" border="false":::](../../hello-how-it-works-technology.md#key-trust "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")
[key trust :::image type="icon" source="../images/information.svg" border="false":::](../index.md#trust-types "This trust type uses a raw key to authenticate the users to Active Directory. It's not required to issue certificates to users, but it's required to deploy certificates to domain controllers")

222
windows/security/identity-protection/hello-for-business/deploy/index.md
View File

@ -1,65 +1,205 @@
---
title: Windows Hello for Business Deployment Overview
description: Use this deployment guide to successfully deploy Windows Hello for Business in an existing environment.
ms.date: 02/15/2022
title: Plan a Windows Hello for Business Deployment
description: Learn about the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of your infrastructure.
ms.date: 12/18/2023
ms.topic: overview
appliesto:
---
# Windows Hello for Business Deployment Overview
# Plan a Windows Hello for Business Deployment
Windows Hello for Business is the springboard to a world without passwords. It replaces username and password sign-in to Windows with strong user authentication based on an asymmetric key pair.
This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
This deployment overview is to guide you through deploying Windows Hello for Business. Your first step should be to use the Passwordless Wizard in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup) or the [Planning a Windows Hello for Business Deployment](../hello-planning-guide.md) guide to determine the right deployment model for your organization.
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure.
Once you've chosen a deployment model, the deployment guide for that model will provide you with the information needed to successfully deploy Windows Hello for Business in your environment. Read the [Windows Hello for Business Deployment Prerequisite Overview](requirements.md) for a summary of the prerequisites for each different Windows Hello for Business deployment model.
> [!TIP]
> If you have a Microsoft Entra ID tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup).
## Requirements
## Using this guide
This guide assumes that baseline infrastructure exists which meets the requirements for your deployment. For either hybrid or on-premises deployments, it is expected that you have:
There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex. However, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It's important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
- A well-connected, working network
- Internet access
- Multi-factor Authentication is required during Windows Hello for Business provisioning
- Proper name resolution, both internal and external names
- Active Directory and an adequate number of domain controllers per site to support authentication
- Active Directory Certificate Services 2012 or later (Note: certificate services aren't needed for cloud Kerberos trust deployments)
- One or more workstation computers running Windows 10, version 1703 or later
This guide removes the appearance of complexity by helping you make decisions on each aspect of your Windows Hello for Business deployment and the options you'll need to consider. Using this guide also identifies the information needed to help you make decisions about the deployment that best suits your environment.
If you're installing a server role for the first time, ensure the appropriate server operating system is installed, updated with the latest patches, and joined to the domain. This document provides guidance to install and configure the specific roles on that server.
### How to Proceed
Don't begin your deployment until the hosting servers and infrastructure (not roles) identified in your prerequisite worksheet are configured and properly working.
Read this document and record your decisions. When finished, you should have all the necessary information for your Windows Hello for Business deployment.
## Deployment and trust models
There are six major categories you need to consider for a Windows Hello for Business deployment:
Windows Hello for Business has three deployment models: Microsoft Entra cloud only, hybrid, and on-premises. Hybrid has three trust models: *Key Trust*, *Certificate Trust*, and *cloud Kerberos trust*. On-premises deployment models only support *Key Trust* and *Certificate Trust*.
- Deployment Options
- Client
- Management
- Active Directory
- Public Key Infrastructure
- Cloud
Hybrid deployments are for enterprises that use Microsoft Entra ID. On-premises deployments are for enterprises who exclusively use on-premises Active Directory. Remember that the environments that use Microsoft Entra ID must use the hybrid deployment model for all domains in that forest.
## Deployment Options
The trust model determines how you want users to authenticate to the on-premises Active Directory:
The goal of Windows Hello for Business is to enable deployments for all organizations of any size or scenario. To provide this type of granular deployment, Windows Hello for Business offers a diverse choice of deployment options.
- The key-trust model is for enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This still requires Active Directory Certificate Services for domain controller certificates.
- The cloud-trust model is also for hybrid enterprises who don't want to issue end-entity certificates to their users and have an adequate number of 2016 domain controllers in each site to support authentication. This trust model is simpler to deploy than key trust and doesn't require Active Directory Certificate Services. We recommend using **cloud Kerberos trust** instead of **Key Trust** if the clients in your enterprise support it.
- The certificate-trust model is for enterprises that *do* want to issue end-entity certificates to their users and have the benefits of certificate expiration and renewal, similar to how smart cards work today.
- The certificate trust model also supports enterprises, which aren't ready to deploy Windows Server 2016 Domain Controllers.
### Deployment models
> [!NOTE]
> RDP does not support authentication with Windows Hello for Business Key Trust or cloud Kerberos trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business Key Trust and cloud Kerberos trust can be used with [Remote Credential Guard](../../remote-credential-guard.md).
It's fundamentally important to understand which deployment model to use for a successful deployment. Some aspects of the deployment may have already been decided for you based on your current infrastructure.
Following are the various deployment guides and models included in this topic:
There are three deployment models from which you can choose:
- [Microsoft Entra hybrid joined cloud Kerberos trust Deployment](hybrid-cloud-kerberos-trust.md)
- [Microsoft Entra hybrid joined Key Trust Deployment](hybrid-key-trust.md)
- [Microsoft Entra hybrid joined Certificate Trust Deployment](hybrid-cert-trust.md)
- [Microsoft Entra join Single Sign-on Deployment Guides](../hello-hybrid-aadj-sso.md)
- [On Premises Key Trust Deployment](hybrid-cloud-kerberos-trust.md)
- [On Premises Certificate Trust Deployment](on-premises-cert-trust.md)
| :ballot_box_with_check: | Deployment model | Description |
|--|--|--|
| :black_square_button: | **Cloud-only** |For organizations that only have cloud identities and don't access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint Online, OneDrive, and others. Also, since the users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in cloud services|
| :black_square_button: | **Hybrid** |For organizations that have identities synchronized from Active Directory to Microsoft Entra ID. These organizations use applications registered in Microsoft Entra ID, and want a sinlge sign-on (SSO) experience for both on-premises and Microsoft Entra resources|
| :black_square_button: | **On-premises** |For organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID. These organizations use on-premises applications, integrated in Active Directory, and want a SSO user experiences when accessing them.|
For Windows Hello for Business hybrid [certificate trust prerequisites](/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust#directory-synchronization) and [key trust prerequisites](/windows/security/identity-protection/hello-for-business/hello-hybrid-key-trust#directory-synchronization) deployments, you'll need Microsoft Entra Connect to synchronize user accounts in the on-premises Active Directory with Microsoft Entra ID. For on-premises deployments, both key and certificate trust, use the Azure MFA server where the credentials aren't synchronized to Microsoft Entra ID. Learn how to [deploy Multifactor Authentication Services (MFA) for key trust](on-premises-key-trust-mfa.md) and [for certificate trust](on-premises-cert-trust-mfa.md) deployments.
>[!NOTE]
>
>- Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests"
>- Migration from on-premise to hybrid deployment requires redeployment
## Provisioning
### Trust types
Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user receives their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
A deployment's trust type defines how Windows Hello for Business clients **authenticate to Active Directory**. For this reason, the trust type isn't applicable to a cloud-only deployment model.
> [!NOTE]
> You must allow access to the URL `account.microsoft.com` to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL doesn't require any authentication and as such, doesn't collect any user data.
There are three trust types from which you can choose:
| :ballot_box_with_check: | Trust type | Description |
|--|--|--|
| :black_square_button: | **Cloud Kerberos trust**| Users authenticate to Active Directory by requesting a TGT from Microsoft Entra ID, using Microsoft Entra Kerberos. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization. Cloud Kerberos trust uses the same infrastructure required for FIDO2 security key sign-in, and it can be used for new or existing Windows Hello for Business deployments. |
| :black_square_button: | **Key trust**| Users authenticate to the on-premises Active Directory using a device-bound key (hardware or sofware) created during the Windows Hello provisioning experience. It requires to distribute certificates to domain controllers. |
| :black_square_button: | **Certificate trust**| The certificate trust type issues authentication certificates to users. Users authenticate using a certificate requested using a device-bound key (hardware or sofware) created during the Windows Hello provisioning experience. |
*Key trust* and *certificate trust* use certificate authentication-based Kerberos for requesting kerberos ticket-granting-tickets (TGTs) for on-premises authentication. This type of authentication requires a PKI for DC certificates, and requires end-user certificates for certificate trust.
The goal of Windows Hello for Business cloud Kerberos trust is to provide a simple deployment experience:
- No need to deploy a public key infrastructure (PKI) or to change an existing PKI
- No need to synchronize public keys between Microsoft Entra ID and Active Directory for users to access on-premises resources. There isn't any delay between the user's Windows Hello for Business provisioning, and being able to authenticate to Active Directory
- [FIDO2 security key sign-in][AZ-1] can be deployed with minimal extra setup
Windows Hello for Business cloud Kerberos trust is the recommended deployment model when compared to the *key trust model*. It is also the preferred deployment model if you don't need to support certificate authentication scenarios.
### Device registration
All devices included in the Windows Hello for Business deployment must go through a process called *device registration*. Device registration enables devices to authenticate to identity providers:
- For cloud-only and hybrid deployment, the identity provider is Microsoft Entra ID
- For on-premises deployments, the identity provider is the on-premises server running the Active Directory Federation Services (AD FS) role
### Key registration
The built-in Windows Hello for Business provisioning experience creates a device-bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules. The credential is a *user key*, not a *device key*. The provisioning experience registers the user's public key with the identity provider:
- For cloud-only and hybrid deployments, the identity provider is Microsoft Entra ID
- For on-premises deployments, the identity provider is the on-premises server running the AD FS role
### Directory synchronization
Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose:
- Hybrid deployments use Microsoft Entra Connect to synchronize Active Directory identities or credentials (in key trust model) between itself and Microsoft Entra ID. This synchronization enables SSO to Microsoft Entra ID and its federated components
- On-premises deployments use directory synchronization to import users from Active Directory to the MFA Server, which sends data to the MFA cloud service to perform the verification
### Multifactor authentication
The goal of Windows Hello for Business is to move organizations away from passwords by providing them with a *strong credential* that enables easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication. However, the user must provide a second factor of authentication before Windows provisions a strong credential:
- For cloud-only and hybrid deployments, ther are different choices for multifactor authentication, including [Microsoft Entra MFA][ENTRA-1]
- On-premises deployments must use a multifactor option that can integrate as an AD FS multifactor adapter. Organizations can choose from third-party options that offer an AD FS MFA adapter. For more infomration, see [Microsoft and third-party additional authentication methods][SERV-1]
> [!IMPORTANT]
> As of July 1, 2019, Microsoft doesn't offer MFA Server for new deployments. New deployments that require multifactor authentication should use cloud-based Microsoft Entra multifactor authentication. Existing deployment where the MFA Server was activated prior to July 1, 2019 can download the latest version, future updates, and generate activation credentials. See [Getting started with the Azure Multi-Factor Authentication Server][ENTRA-2] for more details.
### Device configuration
Windows Hello for Business provides organizations with a rich set of granular policy settings with which they can use to configure their devices. There are two main options to configure Windows Hello for Business: configuration service provider (CSP) and group policy (GPO):
- The CSP option is ideal for devices that are managed through a Mobile Device Management (MDM) solution, like Microsoft Intune
- GPO can be used to configure domain joined devices and where devices aren't managed via MDM
### Public Key Infrastructure (PKI)
While cloud Kerberos trust is the only deployment option that doesn't require the deployment of any certificates, the other models depend on an enterprise PKI as a trust anchor for authentication:
- Domain controllers for hybrid and on-premises deployments need a certificate for Windows devices to trust the domain controller as legitimate
- Deployments using the certificate trust type require an enterprise PKI and a certificate registration authority (CRA) to issue authentication certificates to users. AD FS is used as a CRA
- Hybrid deployments might need to issue VPN certificates to users to enable connectivity on-premises resources
### Cloud services
Some deployment combinations require an Azure account, and some require Microsoft Entra ID for user identities. These cloud requirements may only need an Azure account while other features need a Microsoft Entra ID P1 or P2 subscription.
### Licensing requirements for cloud services
Here are some considerations regarding licensing requirements for cloud services:
- Windows Hello for Business doesn't require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do
- Devices managed via MDM don't require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, users must manually enroll devices in the MDM solution, such as Microsoft Intune or a supported third-party MDM
- You can deploy Windows Hello for Business using the Microsoft Entra ID Free tier. All Microsoft Entra ID Free accounts can use Microsoft Entra multifactor authentication through the use of security defaults
- Some Microsoft Entra multifactor authentication features require a license. For more details, see [Features and licenses for Microsoft Entra multifactor authentication](/azure/active-directory/authentication/concept-mfa-licensing).
- Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature
## Planning a Deployment
Planning your Windows Hello for Business deployment begins with choosing a deployment type. Like all distributed systems, Windows Hello for Business depends on multiple components within your organization's infrastructure.
### Deployment Model
Choose the deployment model based on the resources your users access. Use the following guidance to make your decision.
- If your organization doesn't have on-premises resources, use **Cloud Only**
- If your organization syncronizes users to Microsoft Entra ID to access cloud services, select **Hybrid**
- If your organization doesn't have cloud resources, select **On-Premises**
### Trust type
Choose a trust type that is best suited for your organizations. The trust type determines whether you issue authentication certificates to your users. One trust model isn't more secure than the other.
The deployment of certificates to users and Domain Controllers requires more configuration and infrastructure, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
## Next steps
> [!div class="op_multi_selector" title1="Deployment type:" title2="Trust type:"]
> Select your deployment options to read about the deployment process:
>
> - [(cloud-only|Microsoft Entra ID)](cloud.md)
> - [(hybrid | cloud Kerberos trust)](hybrid-cloud-kerberos-trust.md)
> - [(hybrid | key trust)](hybrid-key-trust.md)
> - [(hybrid | certificate trust)](hybrid-cert-trust.md)
> - [(on-premises | key trust)](on-premises-key-trust.md)
> - [(on-premises | certificate trust)](on-premises-cert-trust.md)
## Prepare users to use Windows Hello
When you set a policy to require Windows Hello for Business in the workplace, you will want to prepare people in your organization by explaining how to use Hello.
After enrollment in Hello, users should use their gesture (such as a PIN or fingerprint) for access to corporate resources. Their gesture is only valid on the enrolled device.
Although the organization may require users to change their Active Directory or Microsoft Entra account password at regular intervals, changes to their passwords have no effect on Hello.
People who are currently using virtual or physical smart cards for authentication can use their virtual smart card to verify their identity when they set up Hello.
[!INCLUDE [virtual-smart-card-deprecation-notice](../../../includes/virtual-smart-card-deprecation-notice.md)]
## On devices owned by the organization
When someone sets up a new device, they are prompted to choose who owns the device. For corporate devices, they select **This device belongs to my organization**.
![who owns this pc.](images/corpown.png)
Next, they select a way to connect. Tell the people in your enterprise which option they should pick here.
![choose how you'll connect.](images/connect.png)
They sign in, and are then asked to verify their identity. People have options to choose from a text message, phone call, or the authentication application. After verification, they create their PIN. The **Create a PIN** screen displays any complexity requirements that you have set, such as minimum length.
After Hello is set up, people use their PIN to unlock the device, and that will automatically log them on.
## On personal devices
People who want to access work resources on their personal devices can add a work or school account in **Settings** > **Accounts** > **Work or school**, and then sign in with work credentials. The person selects the method for receiving the verification code, such as text message or email. The verification code is sent and the person then enters the verification code. After verification, the person enters and confirms new PIN. The person can access any token-based resource using this device without being asked for credentials.
People can go to **Settings** > **Accounts** > **Work or school**, select the work account, and then select **Unjoin** to remove the account from their device.
<!--links-->
[ENTRA-1]: /entra/identity/authentication/concept-mfa-howitworks
[SERV-1]: /windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods
[ENTRA-2]: /entra/identity/authentication/howto-mfaserver-deploy

310
windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs.md
View File

@ -1,180 +1,44 @@
---
title: Prepare and deploy Active Directory Federation Services in an on-premises certificate trust model
description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business on-premises certificate trust model.
title: Configure Active Directory Federation Services in an on-premises certificate trust model
description: Learn how to configure Active Directory Federation Services (AD FS) to support the Windows Hello for Business on-premises certificate trust model.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Prepare and deploy Active Directory Federation Services - on-premises certificate trust
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust.md)]
Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises certificate trust deployment model uses AD FS for *certificate enrollment* and *device registration*.
Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises certificate trust deployment model uses AD FS for *certificate enrollment* (CRA) and *device registration*.
The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
[!INCLUDE [adfs-validate](includes/adfs-validate.md)]
A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
Prepare the AD FS deployment by installing and **updating** two Windows Servers.
## Enroll for a TLS server authentication certificate
Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
- **Subject Name**: the internal FQDN of the federation server
- **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
### AD FS authentication certificate enrollment
Sign-in the federation server with *domain administrator* equivalent credentials.
1. Start the Local Computer **Certificate Manager** (certlm.msc)
1. Expand the **Personal** node in the navigation pane
1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
1. Select **Next** on the **Before You Begin** page
1. Select **Next** on the **Select Certificate Enrollment Policy** page
1. On the **Request Certificates** page, select the **Internal Web Server** check box
1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
:::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Screenshot that shows example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
1. Select **Enroll**
A server authentication certificate should appear in the computer's personal certificate store.
## Deploy the AD FS role
AD FS provides the following services to support Windows Hello for Business on-premises deployments in a certificate trust model:
- Device registration
- Key registration
- Certificate registration authority (CRA)
>[!IMPORTANT]
> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
1. Start **Server Manager**. Select **Local Server** in the navigation pane
1. Select **Manage > Add Roles and Features**
1. Select **Next** on the **Before you begin** page
1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
1. Select **Next** on the **Select features** page
1. Select **Next** on the **Active Directory Federation Service** page
1. Select **Install** to start the role installation
## Review to validate the AD FS deployment
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Confirm the AD FS farm uses the correct database configuration
> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
> * Confirm **all** AD FS servers in the farm have the latest updates installed
> * Confirm all AD FS servers have a valid server authentication certificate
## Device registration service account prerequisites
The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
### Create KDS Root Key
Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
Start an elevated PowerShell console and execute the following command:
```PowerShell
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```
## Configure the Active Directory Federation Service Role
Use the following procedures to configure AD FS.
Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
1. Start **Server Manager**
1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
1. On the **Welcome** page, select **Create the first federation server farm > Next**
1. On the **Connect to Active Directory Domain Services** page, select **Next**
1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
1. Select the federation service name from the **Federation Service Name** list
1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
1. On the **Review Options** page, select **Next**
1. On the **Pre-requisite Checks** page, select **Configure**
1. When the process completes, select **Close**
[!INCLUDE [adfs-deploy](includes/adfs-deploy.md)]
> [!NOTE]
> For AD FS 2019 and later in a certificate trust model, a known PRT issue exists. You may encounter this error in AD FS Admin event logs: Received invalid Oauth request. The client 'NAME' is forbidden to access the resource with scope 'ugs'. To remediate this error:
>
> 1. Launch AD FS management console. Browse to ***Services > Scope Descriptions**
> 2. Right-click **Scope Descriptions** and select **Add Scope Description**
> 3. Under name type *ugs* and select **Apply > OK**
> 4. Launch PowerShell as an administrator and execute the following commands:
> ```PowerShell
> $id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
> Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'
> ```
> 7. Restart the AD FS service
> 8. Restart the client. User should be prompted to provision Windows Hello for Business
### Add the AD FS service account to the *Key Admins* group
During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
1. Open **Active Directory Users and Computers**
1. Select the **Users** container in the navigation pane
1. Right-click **Key Admins** in the details pane and select **Properties**
1. Select the **Members > Add…**
1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
1. Select **OK** to return to **Active Directory Users and Computers**
1. Change to server hosting the AD FS role and restart it
Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
1. Open the **AD FS management** console
1. In the navigation pane, expand **Service**. Select **Device Registration**
1. In the details pane, select **Configure device registration**
1. In the **Configure Device Registration** dialog, Select **OK**
:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png" alt-text="Screenshot that shows AD FS device registration: configuration of the service connection point.":::
Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="Screenshot that shows AD FS device registration: service connection point object created by AD FS.":::
> 1. Right-click **Scope Descriptions** and select **Add Scope Description**
> 1. Under name type *ugs* and select **Apply > OK**
> 1. Launch PowerShell as an administrator and execute the following commands:
>
> ```PowerShell
> $id = (Get-AdfsApplicationPermission -ServerRoleIdentifiers 'http://schemas.microsoft.com/ws/2009/12/identityserver/selfscope' | ?{ $_.ClientRoleIdentifier -eq '38aa3b87-a06d-4817-b275-7a316988d93b' }).ObjectIdentifier
> Set-AdfsApplicationPermission -TargetIdentifier $id -AddScope 'ugs'
> ```
>
> 1. Restart the AD FS service
> 1. Restart the client. User should be prompted to provision Windows Hello for Business
## Review to validate the AD FS and Active Directory configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
> * Confirm you added the AD FS service account to the KeyAdmins group
> * Confirm you enabled the Device Registration service
> Before you continue with the deployment, validate your deployment progress by reviewing the following items:
>
> - Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
> - Confirm you added the AD FS service account to the KeyAdmins group
> - Confirm you enabled the Device Registration service
## Configure the certificate registration authority
@ -187,6 +51,7 @@ Open a **Windows PowerShell** prompt and type the following command:
```PowerShell
Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplate WHFBEnrollmentAgent -WindowsHelloCertificateTemplate WHFBAuthentication
```
>[!NOTE]
> If you gave your Windows Hello for Business Enrollment Agent and Windows Hello for Business Authentication certificate templates different names, then replace *WHFBEnrollmentAgent* and *WHFBAuthentication* in the above command with the name of your certificate templates. It's important that you use the template name rather than the template display name. You can view the template name on the **General** tab of the certificate template by using the **Certificate Template** management console (certtmpl.msc). Or, you can view the template name by using the `Get-CATemplate` PowerShell cmdlet on a CA.
@ -196,111 +61,7 @@ AD FS performs its own certificate lifecycle management. Once the registration a
Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it is successful. If the certificate fails to renew, and the certificate expires, the AD FS server will request a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate.
## Additional federation servers
Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
### Server authentication certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
### Install additional servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
## Load balance AD FS
Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
### Install Network Load Balancing Feature on AD FS Servers
Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
1. Start **Server Manager**. Select **Local Server** in the navigation pane
1. Select **Manage** and then select **Add Roles and Features**
1. Select **Next** On the **Before you begin** page
1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
1. On the **Select server roles** page, select **Next**
1. Select **Network Load Balancing** on the **Select features** page
1. Select **Install** to start the feature installation
### Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
Sign-in a node of the federation farm with *Administrator* equivalent credentials.
1. Open **Network Load Balancing Manager** from **Administrative Tools**
1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
1. In Port Rules, select Edit to modify the default port rules to use port 443
### Additional AD FS Servers
1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
## Configure DNS for Device Registration
Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
1. Open the **DNS Management** console
1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
1. Right-click the `<domain_name>` node and select **New Alias (CNAME)**
1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.<domain_name_fqdn`, and select OK
1. Close the DNS Management console
> [!NOTE]
> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.<upnsuffix_fqdn>` is present for each suffix.
## Configure the Intranet Zone to include the federation service
The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
### Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials
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 **Intranet Zone Settings** in the name box and select **OK**
1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
1. In the navigation pane, expand **Policies** under **Computer Configuration**
1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
### Deploy the Intranet Zone Group Policy object
1. Start the **Group Policy Management Console** (gpmc.msc)
1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
1. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template
> * Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance
> * Confirm you properly configured the Windows Hello for Business authentication certificate template
> * Confirm all certificate templates were properly published to the appropriate issuing certificate authorities
> * Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template
> * Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet
> Confirm you restarted the AD FS service
> * Confirm you properly configured load-balancing (hardware or software)
> * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
> * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server.
[!INCLUDE [adfs-additional-servers](includes/adfs-additional-servers.md)]
### Event Logs
@ -308,7 +69,7 @@ Use the event logs on the AD FS service to confirm the service account enrolled
- The account name under which the certificate was enrolled
- The action, which should read enroll
-_ The thumbprint of the certificate
- The thumbprint of the certificate
- The certificate template used to issue the certificate
You cannot use the Certificate Manager to view enrolled certificates for group managed service accounts. Use the event log information to confirm the AD FS service account enrolled a certificate. Use certutil.exe to view the details of the certificate shown in the event log.
@ -319,5 +80,24 @@ Each file in this folder represents a certificate in the service account's Perso
For detailed information about the certificate, use `Certutil -q -v <certificateThumbprintFileName>`.
[!INCLUDE [adfs-mfa](includes/adfs-mfa.md)]
## Review to validate the configuration
> [!div class="checklist"]
> Before you continue with the deployment, validate your deployment progress by reviewing the following items:
>
> - Confirm only the AD FS service account has the allow enroll permission for the enrollment agent certificate template
> - Consider using an HSM to protect the enrollment agent certificate; however, understand the frequency and quantity of signature operations the enrollment agent server makes and understand the impact it has on overall performance
> - Confirm you properly configured the Windows Hello for Business authentication certificate template
> - Confirm all certificate templates were properly published to the appropriate issuing certificate authorities
> - Confirm the AD FS service account has the allow enroll permission for the Windows Hello Business authentication certificate template
> - Confirm the AD FS certificate registration authority is properly configured using the `Get-AdfsCertificateAuthority` Windows PowerShell cmdlet
> Confirm you restarted the AD FS service
> - Confirm you properly configured load-balancing (hardware or software)
> - Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
> - Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server
> - Confirm you have deployed a MFA solution for AD FS
> [!div class="nextstepaction"]
> [Next: validate and deploy multi-factor authentication (MFA) >](on-premises-cert-trust-mfa.md)
> [Next: configure and enroll in Windows Hello for Business >](on-premises-cert-trust-enroll.md)

12
windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md
View File

@ -2,18 +2,12 @@
title: Configure Windows Hello for Business Policy settings in an on-premises certificate trust
description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises certificate trust scenario
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Configure Windows Hello for Business group policy settings - on-premises certificate Trust
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust.md)]
On-premises certificate-based deployments of Windows Hello for Business need three Group Policy settings:
@ -115,9 +109,9 @@ The settings can be found in *Administrative Templates\System\PIN Complexity*, u
## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
>Before you continue with the deployment, validate your deployment progress by reviewing the following items:
>
> - Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User)
> - Confirm you configure the Use Certificate enrollment for on-premises authentication policy setting
> - Confirm you configured the proper security settings for the Group Policy object

31
windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-mfa.md
View File

@ -1,31 +0,0 @@
---
title: Validate and Deploy MFA for Windows Hello for Business with certificate trust
description: Validate and deploy multifactor authentication (MFA) for Windows Hello for Business in an on-premises certificate trust model.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.topic: tutorial
---
# Validate and deploy multifactor authentication - on-premises certificate trust
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
Windows Hello for Business requires users perform multifactor authentication (MFA) prior to enroll in the service. On-premises deployments can use, as MFA option:
- third-party authentication providers for AD FS
- custom authentication provider for AD FS
> [!IMPORTANT]
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who would like to require multifactor authentication from their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1 will be able to download the latest version, future updates and generate activation credentials as usual.
For information about third-party authentication methods, see [Configure Additional Authentication Methods for AD FS](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs). To create a custom authentication method, see [Build a Custom Authentication Method for AD FS in Windows Server](/windows-server/identity/ad-fs/development/ad-fs-build-custom-auth-method).
Follow the integration and deployment guide for the authentication provider you plan to integrate to AD FS. Make sure that the authentication provider is selected as a multifactor authentication option in the AD FS authentication policy. For information on configuring AD FS authentication policies, see [Configure Authentication Policies](/windows-server/identity/ad-fs/operations/configure-authentication-policies).
> [!div class="nextstepaction"]
> [Next: configure Windows Hello for Business Policy settings >](on-premises-cert-trust-enroll.md)

18
windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-pki.md
View File

@ -1,19 +1,13 @@
---
title: Configure and validate the Public Key Infrastructure in an on-premises certificate trust model
description: Configure and validate the Public Key Infrastructure the Public Key Infrastructure when deploying Windows Hello for Business in a certificate trust model.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.date: 12/18/2023
ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - on-premises certificate trust
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust.md)]
Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* or *certificate trust* models. The domain controllers must have a certificate, which serves as a root of trust for clients. The certificate ensures that clients don't communicate with rogue domain controllers. The certificate trust model extends certificate issuance to client computers. During Windows Hello for Business provisioning, the user receives a sign-in certificate.
@ -21,15 +15,15 @@ Windows Hello for Business must have a Public Key Infrastructure (PKI) when usin
## Configure the enterprise PKI
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
[!INCLUDE [dc-certificate-template](includes/certificate-template-dc.md)]
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)]
[!INCLUDE [web-server-certificate-template](includes/certificate-template-web-server.md)]
[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)]
[!INCLUDE [enrollment-agent-certificate-template](includes/certificate-template-enrollment-agent.md)]
[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)]
[!INCLUDE [auth-certificate-template](includes/certificate-template-auth.md)]
[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]

23
windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust.md
View File

@ -1,32 +1,25 @@
---
title: Deployment guide for the on-premises certificate trust model
description: Learn how to deploy Windows Hello for Business in an on-premises, certificate trust model.
ms.date: 12/15/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.date: 12/18/2023
ms.topic: tutorial
---
# Deployment guide for the on-premises certificate trust model
# On-premises certificate trust deployment guide
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)]
[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust.md)]
Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment.
This deployment guide provides the information to deploy Windows Hello for Business with an on-premises certificate trust model.
There are four steps to deploying Windows Hello for Business in an on-premises certificate trust model:
There are three steps to complete this deployment:
1. [Validate and configure a PKI](on-premises-cert-trust-pki.md)
1. [Prepare and deploy AD FS](on-premises-cert-trust-adfs.md)
1. [Validate and deploy multi-factor authentication (MFA)](on-premises-cert-trust-mfa.md)
1. [Configure Windows Hello for Business Policy settings](on-premises-cert-trust-enroll.md)
1. [Prepare and deploy AD FS with MFA](on-premises-cert-trust-adfs.md)
1. [Configure and enroll in Windows Hello for Business](on-premises-cert-trust-enroll.md)
## Create the Windows Hello for Business Users security group
While this is not a required step, it is recommended to create a security group to simplify the deployment.
While this isn't a required step, it's recommended to create a security group to simplify the deployment.
The *Windows Hello for Business Users* group is used to make it easy to deploy Windows Hello for Business in phases. You assign certificate templates and group policy permissions to this group to simplify the deployment by adding the users to the group. This provides users with the proper permissions to provision Windows Hello for Business.

256
windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs.md
View File

@ -1,264 +1,44 @@
---
ms.date: 09/07/2023
title: Prepare and deploy Active Directory Federation Services in an on-premises key trust
description: Learn how to configure Active Directory Federation Services to support the Windows Hello for Business key trust model.
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
title: Configure Active Directory Federation Services in an on-premises key trust model
description: Learn how to configure Active Directory Federation Services (AD FS) to support the Windows Hello for Business key trust model.
ms.date: 12/15/2023
ms.topic: tutorial
---
# Prepare and deploy Active Directory Federation Services - on-premises key trust
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
Windows Hello for Business works exclusively with the Active Directory Federation Service (AD FS) role included with Windows Server. The on-premises key trust deployment model uses AD FS for *key registration* and *device registration*.
The following guidance describes the deployment of a new instance of AD FS using the Windows Information Database (WID) as the configuration database.\
WID is ideal for environments with no more than **30 federation servers** and no more than **100 relying party trusts**. If your environment exceeds either of these factors, or needs to provide *SAML artifact resolution*, *token replay detection*, or needs AD FS to operate as a federated provider role, then the deployment requires the use of SQL as a configuration database.\
To deploy AD FS using SQL as its configuration database, review the [Deploying a Federation Server Farm](/windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm) checklist.
[!INCLUDE [adfs-validate](includes/adfs-validate.md)]
A new AD FS farm should have a minimum of two federation servers for proper load balancing, which can be accomplished with external networking peripherals, or with using the Network Load Balancing Role included in Windows Server.
Prepare the AD FS deployment by installing and **updating** two Windows Servers.
## Enroll for a TLS server authentication certificate
Typically, a federation service is an edge facing role. However, the federation services and instance used with the on-premises deployment of Windows Hello for Business does not need Internet connectivity.
The AD FS role needs a *server authentication* certificate for the federation services, and you can use a certificate issued by your enterprise (internal) CA. The server authentication certificate should have the following names included in the certificate, if you are requesting an individual certificate for each node in the federation farm:
- **Subject Name**: the internal FQDN of the federation server
- **Subject Alternate Name**: the federation service name (e.g. *sts.corp.contoso.com*) or an appropriate wildcard entry (e.g. *\*.corp.contoso.com*)
The federation service name is set when the AD FS role is configured. You can choose any name, but that name must be different than the name of the server or host. For example, you can name the host server *adfs* and the federation service *sts*. In this example, the FQDN of the host is *adfs.corp.contoso.com* and the FQDN of the federation service is *sts.corp.contoso.com*.
You can also issue one certificate for all hosts in the farm. If you chose this option, leave the subject name *blank*, and include all the names in the subject alternate name when creating the certificate request. All names should include the FQDN of each host in the farm and the federation service name.
When creating a wildcard certificate, mark the private key as exportable, so that the same certificate can be deployed across each federation server and web application proxy within the AD FS farm. Note that the certificate must be trusted (chain to a trusted root CA). Once you have successfully requested and enrolled the server authentication certificate on one node, you can export the certificate and private key to a PFX file using the Certificate Manager console. You can then import the certificate on the remaining nodes in the AD FS farm.
Be sure to enroll or import the certificate into the AD FS server's computer certificate store. Also, ensure all nodes in the farm have the proper TLS server authentication certificate.
### AD FS authentication certificate enrollment
Sign-in the federation server with *domain administrator* equivalent credentials.
1. Start the Local Computer **Certificate Manager** (certlm.msc)
1. Expand the **Personal** node in the navigation pane
1. Right-click **Personal**. Select **All Tasks > Request New Certificate**
1. Select **Next** on the **Before You Begin** page
1. Select **Next** on the **Select Certificate Enrollment Policy** page
1. On the **Request Certificates** page, select the **Internal Web Server** check box
1. Select the **⚠️ More information is required to enroll for this certificate. Click here to configure settings** link
:::image type="content" source="images/hello-internal-web-server-cert.png" lightbox="images/hello-internal-web-server-cert.png" alt-text="Example of Certificate Properties Subject Tab - This is what shows when you select the above link.":::
1. Under **Subject name**, select **Common Name** from the **Type** list. Type the FQDN of the computer hosting the AD FS role and then select **Add**
1. Under **Alternative name**, select **DNS** from the **Type** list. Type the FQDN of the name that you will use for your federation services (*sts.corp.contoso.com*). The name you use here MUST match the name you use when configuring the AD FS server role. Select **Add** and **OK** when finished
1. Select **Enroll**
A server authentication certificate should appear in the computer's personal certificate store.
## Deploy the AD FS role
AD FS provides *device registration* and *key registration* services to support the Windows Hello for Business on-premises deployments.
>[!IMPORTANT]
> Finish the entire AD FS configuration on the first server in the farm before adding the second server to the AD FS farm. Once complete, the second server receives the configuration through the shared configuration database when it is added the AD FS farm.
Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
1. Start **Server Manager**. Select **Local Server** in the navigation pane
1. Select **Manage > Add Roles and Features**
1. Select **Next** on the **Before you begin** page
1. On the **Select installation type** page, select **Role-based or feature-based installation > Next**
1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list and **Next**
1. On the **Select server roles** page, select **Active Directory Federation Services** and **Next**
1. Select **Next** on the **Select features** page
1. Select **Next** on the **Active Directory Federation Service** page
1. Select **Install** to start the role installation
## Review to validate the AD FS deployment
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Confirm the AD FS farm uses the correct database configuration
> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
> * Confirm **all** AD FS servers in the farm have the latest updates installed
> * Confirm all AD FS servers have a valid server authentication certificate
## Device registration service account prerequisites
The use of Group Managed Service Accounts (GMSA) is the preferred way to deploy service accounts for services that support them. GMSAs have security advantages over normal user accounts because Windows handles password management. This means the password is long, complex, and changes periodically. AD FS supports GMSAs, and it should be configured using them for additional security.
GSMA uses the *Microsoft Key Distribution Service* that is located on the domain controllers. Before you can create a GSMA, you must first create a root key for the service. You can skip this if your environment already uses GSMA.
### Create KDS Root Key
Sign-in a domain controller with *Enterprise Administrator* equivalent credentials.
Start an elevated PowerShell console and execute the following command:
```PowerShell
Add-KdsRootKey -EffectiveTime (Get-Date).AddHours(-10)
```
## Configure the Active Directory Federation Service Role
Use the following procedures to configure AD FS.
Sign-in to the federation server with *Domain Administrator* equivalent credentials. These procedures assume you are configuring the first federation server in a federation server farm.
1. Start **Server Manager**
1. Select the notification flag in the upper right corner and select **Configure the federation services on this server**
1. On the **Welcome** page, select **Create the first federation server farm > Next**
1. On the **Connect to Active Directory Domain Services** page, select **Next**
1. On the **Specify Service Properties** page, select the recently enrolled or imported certificate from the **SSL Certificate** list. The certificate is likely named after your federation service, such as *sts.corp.contoso.com*
1. Select the federation service name from the **Federation Service Name** list
1. Type the *Federation Service Display Name* in the text box. This is the name users see when signing in. Select **Next**
1. On the **Specify Service Account** page, select **Create a Group Managed Service Account**. In the **Account Name** box, type *adfssvc*
1. On the **Specify Configuration Database** page, select **Create a database on this server using Windows Internal Database** and select **Next**
1. On the **Review Options** page, select **Next**
1. On the **Pre-requisite Checks** page, select **Configure**
1. When the process completes, select **Close**
### Add the AD FS service account to the *Key Admins* group
During Windows Hello for Business enrollment, the public key is registered in an attribute of the user object in Active Directory. To ensure that the AD FS service can add and remove keys are part of its normal workflow, it must be a member of the *Key Admins* global group.
Sign-in to a domain controller or management workstation with *Domain Administrator* equivalent credentials.
1. Open **Active Directory Users and Computers**
1. Select the **Users** container in the navigation pane
1. Right-click **Key Admins** in the details pane and select **Properties**
1. Select the **Members > Add…**
1. In the **Enter the object names to select** text box, type *adfssvc*. Select **OK**
1. Select **OK** to return to **Active Directory Users and Computers**
1. Change to server hosting the AD FS role and restart it
## Configure the device registration service
Sign-in to the federation server with *Enterprise Administrator* equivalent credentials. These instructions assume you are configuring the first federation server in a federation server farm.
1. Open the **AD FS management** console
1. In the navigation pane, expand **Service**. Select **Device Registration**
1. In the details pane, select **Configure device registration**
1. In the **Configure Device Registration** dialog, Select **OK**
:::image type="content" source="images/adfs-device-registration.png" lightbox="images/adfs-device-registration.png" alt-text="AD FS device registration: configuration of the service connection point.":::
Triggering device registration from AD FS, creates the service connection point (SCP) in the Active Directory configuration partition. The SCP is used to store the device registration information that Windows clients will automatically discover.
:::image type="content" source="images/adfs-scp.png" lightbox="images/adfs-scp.png" alt-text="AD FS device registration: service connection point object created by AD FS.":::
[!INCLUDE [adfs-deploy](includes/adfs-deploy.md)]
## Review to validate the AD FS and Active Directory configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
> * Confirm you added the AD FS service account to the KeyAdmins group
> * Confirm you enabled the Device Registration service
> - Record the information about the AD FS certificate, and set a renewal reminder at least six weeks before it expires. Relevant information includes: certificate serial number, thumbprint, common name, subject alternate name, name of the physical host server, the issued date, the expiration date, and issuing CA vendor (if a third-party certificate)
> - Confirm you added the AD FS service account to the KeyAdmins group
> - Confirm you enabled the Device Registration service
## Additional federation servers
[!INCLUDE [adfs-additional-servers](includes/adfs-additional-servers.md)]
Organizations should deploy more than one federation server in their federation farm for high-availability. You should have a minimum of two federation services in your AD FS farm, however most organizations are likely to have more. This largely depends on the number of devices and users using the services provided by the AD FS farm.
### Server authentication certificate
Each server you add to the AD FS farm must have a proper server authentication certificate. Refer to the [Enroll for a TLS Server Authentication Certificate](#enroll-for-a-tls-server-authentication-certificate) section of this document to determine the requirements for your server authentication certificate. As previously stated, AD FS servers used exclusively for on-premises deployments of Windows Hello for Business can use enterprise server authentication certificates rather than server authentication certificates issued by public certificate authorities.
### Install additional servers
Adding federation servers to the existing AD FS farm begins with ensuring the server are fully patched, to include Windows Server 2016 Update needed to support Windows Hello for Business deployments (https://aka.ms/whfbadfs1703). Next, install the Active Directory Federation Service role on the additional servers and then configure the server as an additional server in an existing farm.
## Load balance AD FS
Many environments load balance using hardware devices. Environments without hardware load-balancing capabilities can take advantage the network load-balancing feature included in Windows Server to load balance the AD FS servers in the federation farm. Install the Windows Network Load Balancing feature on all nodes participating in the AD FS farm that should be load balanced.
### Install Network Load Balancing Feature on AD FS Servers
Sign-in the federation server with *Enterprise Administrator* equivalent credentials.
1. Start **Server Manager**. Select **Local Server** in the navigation pane
1. Select **Manage** and then select **Add Roles and Features**
1. Select **Next** On the **Before you begin** page
1. On the **Select installation type** page, select **Role-based or feature-based installation** and select **Next**
1. On the **Select destination server** page, choose **Select a server from the server pool**. Select the federation server from the **Server Pool** list. Select **Next**
1. On the **Select server roles** page, select **Next**
1. Select **Network Load Balancing** on the **Select features** page
1. Select **Install** to start the feature installation
### Configure Network Load Balancing for AD FS
Before you can load balance all the nodes in the AD FS farm, you must first create a new load balance cluster. Once you have created the cluster, then you can add new nodes to that cluster.
Sign-in a node of the federation farm with *Administrator* equivalent credentials.
1. Open **Network Load Balancing Manager** from **Administrative Tools**
1. Right-click **Network Load Balancing Clusters**, and then select **New Cluster**
1. To connect to the host that is to be a part of the new cluster, in the **Host** text box, type the name of the host, and then select **Connect**
1. Select the interface that you want to use with the cluster, and then select **Next** (the interface hosts the virtual IP address and receives the client traffic to load balance)
1. In **Host Parameters**, select a value in **Priority (Unique host identifier)**. This parameter specifies a unique ID for each host. The host with the lowest numerical priority among the current members of the cluster handles all of the cluster's network traffic that is not covered by a port rule. Select **Next**
1. In **Cluster IP Addresses**, select **Add** and type the cluster IP address that is shared by every host in the cluster. NLB adds this IP address to the TCP/IP stack on the selected interface of all hosts that are chosen to be part of the cluster. Select **Next**
1. In **Cluster Parameters**, select values in **IP Address** and **Subnet mask** (for IPv6 addresses, a subnet mask value is not needed). Type the full Internet name that users will use to access this NLB cluster
1. In **Cluster operation mode**, select **Unicast** to specify that a unicast media access control (MAC) address should be used for cluster operations. In unicast mode, the MAC address of the cluster is assigned to the network adapter of the computer, and the built-in MAC address of the network adapter is not used. We recommend that you accept the unicast default settings. Select **Next**
1. In Port Rules, select Edit to modify the default port rules to use port 443
### Additional AD FS Servers
1. To add more hosts to the cluster, right-click the new cluster, and then select **Add Host to Cluster**
1. Configure the host parameters (including host priority, dedicated IP addresses, and load weight) for the additional hosts by following the same instructions that you used to configure the initial host. Because you are adding hosts to an already configured cluster, all the cluster-wide parameters remain the same
## Configure DNS for Device Registration
Sign-in the domain controller or administrative workstation with domain administrator equivalent credentials.\
You'll need the *federation service* name to complete this task. You can view the federation service name by selecting **Edit Federation Service Properties** from the **Action** pan of the **AD FS** management console, or by using `(Get-AdfsProperties).Hostname.` (PowerShell) on the AD FS server.
1. Open the **DNS Management** console
1. In the navigation pane, expand the domain controller name node and **Forward Lookup Zones**
1. In the navigation pane, select the node that has the name of your internal Active Directory domain name
1. In the navigation pane, right-click the domain name node and select **New Host (A or AAAA)**
1. In the **name** box, type the name of the federation service. In the **IP address** box, type the IP address of your federation server. Select **Add Host**
1. Right-click the `<domain_name>` node and select **New Alias (CNAME)**
1. In the **New Resource Record** dialog box, type `enterpriseregistration` in the **Alias** name box
1. In the **fully qualified domain name (FQDN)** of the target host box, type `federation_service_farm_name.<domain_name_fqdn`, and select OK
1. Close the DNS Management console
> [!NOTE]
> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.<upnsuffix_fqdn>` is present for each suffix.
## Configure the Intranet Zone to include the federation service
The Windows Hello provisioning presents web pages from the federation service. Configuring the intranet zone to include the federation service enables the user to authenticate to the federation service using integrated authentication. Without this setting, the connection to the federation service during Windows Hello provisioning prompts the user for authentication.
### Create an Intranet Zone Group Policy
Sign-in the domain controller or administrative workstation with _Domain Admin_ equivalent credentials
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 **Intranet Zone Settings** in the name box and select **OK**
1. In the content pane, right-click the **Intranet Zone Settings** Group Policy object and select **Edit**
1. In the navigation pane, expand **Policies** under **Computer Configuration**
1. Expand **Administrative Templates > Windows Component > Internet Explorer > Internet Control Panel >Security Page**. Open **Site to Zone Assignment List**
1. Select **Enable > Show**. In the **Value Name** column, type the url of the federation service beginning with https. In the **Value** column, type the number **1**. Select OK twice, then close the Group Policy Management Editor
### Deploy the Intranet Zone Group Policy object
1. Start the **Group Policy Management Console** (gpmc.msc)
1. In the navigation pane, expand the domain and right-click the node that has your Active Directory domain name and select **Link an existing GPO…**
1. In the **Select GPO** dialog box, select **Intranet Zone Settings** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK**
[!INCLUDE [adfs-mfa](includes/adfs-mfa.md)]
## Review to validate the configuration
Before you continue with the deployment, validate your deployment progress by reviewing the following items:
> [!div class="checklist"]
> * Confirm all AD FS servers have a valid server authentication certificate. The subject of the certificate is the common name (FQDN) of the host or a wildcard name. The alternate name of the certificate contains a wildcard or the FQDN of the federation service
> * Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
> * Confirm you restarted the AD FS service
> * Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
> * Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server
> - Confirm all AD FS servers have a valid server authentication certificate. The subject of the certificate is the common name (FQDN) of the host or a wildcard name. The alternate name of the certificate contains a wildcard or the FQDN of the federation service
> - Confirm the AD FS farm has an adequate number of nodes and is properly load balanced for the anticipated load
> - Confirm you restarted the AD FS service
> - Confirm you created a DNS A Record for the federation service and the IP address used is the load-balanced IP address
> - Confirm you created and deployed the Intranet Zone settings to prevent double authentication to the federation server
> - Confirm you have deployed a MFA solution for AD FS
> [!div class="nextstepaction"]
> [Next: validate and deploy multi-factor authentication (MFA)](on-premises-key-trust-mfa.md)
> [Next: configure and enroll in Windows Hello for Business >](on-premises-key-trust-enroll.md)

13
windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki.md
View File

@ -1,15 +1,10 @@
---
title: Configure and validate the Public Key Infrastructure in an on-premises key trust model
description: Configure and validate the Public Key Infrastructure when deploying Windows Hello for Business in a key trust model.
ms.date: 09/07/2023
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
ms.date: 12/18/2023
ms.topic: tutorial
---
# Configure and validate the Public Key Infrastructure - on-premises key trust
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
@ -20,11 +15,11 @@ Windows Hello for Business must have a Public Key Infrastructure (PKI) when usin
## Configure the enterprise PKI
[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)]
[!INCLUDE [dc-certificate-template](includes/certificate-template-dc.md)]
[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)]
[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)]
[!INCLUDE [web-server-certificate-template](includes/certificate-template-web-server.md)]
[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)]

13
windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust.md
View File

@ -1,20 +1,21 @@
---
title: Windows Hello for Business deployment guide for the on-premises key trust model
description: Learn how to deploy Windows Hello for Business in an on-premises, key trust model.
ms.date: 12/12/2022
ms.date: 12/18/2023
ms.topic: tutorial
---
# Deployment guide overview - on-premises key trust
# On-premises key trust deployment guide
[!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)]
Windows Hello for Business replaces username and password authentication to Windows with an asymmetric key pair. This deployment guide provides the information to deploy Windows Hello for Business in an on-premises environment:
This deployment guide provides the information to deploy Windows Hello for Business with an on-premises key trust model.
There are three steps to complete this deployment:
1. [Validate and configure a PKI](on-premises-key-trust-pki.md)
1. [Prepare and deploy AD FS](on-premises-key-trust-adfs.md)
1. [Validate and deploy multifactor authentication (MFA)](on-premises-key-trust-mfa.md)
1. [Configure Windows Hello for Business Policy settings](on-premises-key-trust-enroll.md)
1. [Prepare and deploy AD FS with MFA](on-premises-key-trust-adfs.md)
1. [Configure and enroll in Windows Hello for Business](on-premises-key-trust-enroll.md)
## Create the Windows Hello for Business Users security group

55
windows/security/identity-protection/hello-for-business/deploy/requirements.md
View File

@ -1,55 +0,0 @@
---
ms.date: 10/09/2023
title: Windows Hello for Business Deployment Prerequisite Overview
description: Overview of all the different infrastructure requirements for Windows Hello for Business deployment models
ms.topic: overview
appliesto:
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 11</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/supported-versions-windows-client target=_blank>Windows 10</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2022</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2019</a>
- ✅ <a href=https://learn.microsoft.com/windows/release-health/windows-server-release-info target=_blank>Windows Server 2016</a>
---
# Windows Hello for Business Deployment Prerequisite Overview
This article lists the infrastructure requirements for the different deployment models for Windows Hello for Business.
<a name='azure-ad-cloud-only-deployment'></a>
## Microsoft Entra Cloud Only Deployment
- Microsoft Entra ID
- Microsoft Entra multifactor authentication
- Device management solution (Intune or supported third-party MDM), *optional*
- Microsoft Entra ID P1 or P2 subscription - *optional*, needed for automatic MDM enrollment when the device joins Microsoft Entra ID
## Hybrid Deployments
The table shows the minimum requirements for each deployment. For key trust in a multi-domain/multi-forest deployment, the following requirements are applicable for each domain/forest that hosts Windows Hello for business components or is involved in the Kerberos referral process.
| Requirement | Cloud Kerberos trust<br/>Group Policy or Modern managed | Key trust<br/>Group Policy or Modern managed | Certificate Trust<br/>Mixed managed | Certificate Trust<br/>Modern managed |
| --- | --- | --- | --- | --- |
| **Windows Version** | Any supported Windows client versions| Any supported Windows client versions | Any supported Windows client versions |
| **Schema Version** | No specific Schema requirement | Windows Server 2016 or later schema | Windows Server 2016 or later schema | Windows Server 2016 or later schema |
| **Domain and Forest Functional Level** | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |Windows Server 2008 R2 Domain/Forest functional level |
| **Domain Controller Version** | Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
| **Certificate Authority**| Not required |Any supported Windows Server versions | Any supported Windows Server versions | Any supported Windows Server versions |
| **AD FS Version** | Not required | Not required | Any supported Windows Server versions | Any supported Windows Server versions |
| **MFA Requirement** | Azure MFA, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or<br/>AD FS w/Azure MFA adapter, or<br/>AD FS w/Azure MFA Server adapter, or<br/>AD FS w/3rd Party MFA Adapter |
| **Microsoft Entra Connect** | Not required. It's recommended to use [Microsoft Entra Connect cloud sync](/azure/active-directory/hybrid/cloud-sync/what-is-cloud-sync) | Required | Required | Required |
| **Microsoft Entra ID license** | Microsoft Entra ID P1 or P2, optional | Microsoft Entra ID P1 or P2, optional | Microsoft Entra ID P1 or P2, needed for device write-back | Microsoft Entra ID P1 or P2, optional. Intune license required |
## On-premises Deployments
The table shows the minimum requirements for each deployment.
| Requirement | Key trust <br/> Group Policy managed | Certificate trust <br/> Group Policy managed|
| --- | --- | ---|
| **Windows Version** | Any supported Windows client versions|Any supported Windows client versions|
| **Schema Version**| Windows Server 2016 Schema | Windows Server 2016 Schema|
| **Domain and Forest Functional Level**| Windows Server 2008 R2 Domain/Forest functional level | Windows Server 2008 R2 Domain/Forest functional level |
| **Domain Controller Version**| Any supported Windows Server versions | Any supported Windows Server versions |
| **Certificate Authority**| Any supported Windows Server versions | Any supported Windows Server versions |
| **AD FS Version**| Any supported Windows Server versions | Any supported Windows Server versions |
| **MFA Requirement**| AD FS with 3rd Party MFA Adapter | AD FS with 3rd Party MFA Adapter |

12
windows/security/identity-protection/hello-for-business/deploy/toc.yml
View File

@ -1,9 +1,5 @@
items:
- name: Windows Hello for Business deployment overview
href: index.md
- name: Deployment prerequisite overview
href: requirements.md
- name: Cloud-only deployment
- name: Cloud-only deployments
href: cloud.md
- name: Hybrid deployments
items:
@ -59,9 +55,7 @@ items:
href: on-premises-key-trust-pki.md
- name: Prepare and deploy Active Directory Federation Services (AD FS)
href: on-premises-key-trust-adfs.md
- name: Validate and deploy multi-factor authentication (MFA) services
href: on-premises-key-trust-mfa.md
- name: Configure Windows Hello for Business policy settings
- name: Configure and enroll in Windows Hello for Business
href: on-premises-key-trust-enroll.md
- name: Certificate trust deployment
items:
@ -71,7 +65,5 @@ items:
href: on-premises-cert-trust-pki.md
- name: Prepare and Deploy Active Directory Federation Services (AD FS)
href: on-premises-cert-trust-adfs.md
- name: Validate and deploy multi-factor authentication (MFA)
href: on-premises-cert-trust-mfa.md
- name: Configure and enroll in Windows Hello for Business
href: on-premises-cert-trust-enroll.md

243
windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md → windows/security/identity-protection/hello-for-business/glossary.md
View File

@ -1,11 +1,11 @@
---
title: How Windows Hello for Business works - technology and terms
description: Explore technology and terms associated with Windows Hello for Business. Learn how Windows Hello for Business works.
ms.date: 10/08/2018
title: Windows Hello for Business glossary
description: Explore technology and terms associated with Windows Hello for Business
ms.date: 12/18/2023
ms.topic: glossary
---
# Technology and terms
# Windows Hello for Business glossary
## Attestation identity keys
@ -21,98 +21,26 @@ Many existing devices that will upgrade to Windows 10 won't have a TPM, or the T
In the issued AIK certificate, a special OID is added to attest that endorsement certificate was used during the attestation process. This information can be used by a relying party to decide whether to reject devices that are attested using AIK certificates without an endorsement certificate or accept them. Another scenario can be to not allow access to high-value assets from devices that are attested by an AIK certificate that's not backed by an endorsement certificate.
### Related to attestation identity keys
- [Endorsement key](#endorsement-key)
- [Storage root key](#storage-root-key)
- [Trusted platform module](#trusted-platform-module)
### More information about attestation identity keys
- [Windows client certificate enrollment protocol: glossary](/openspecs/windows_protocols/ms-wcce/719b890d-62e6-4322-b9b1-1f34d11535b4#gt_70efa425-6b46-462f-911d-d399404529ab)
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
<a name='azure-active-directory-join'></a>
## Microsoft Entra join
Microsoft Entra join is intended for organizations that desire to be cloud-first or cloud-only. There's no restriction on the size or type of organizations that can deploy Microsoft Entra join. Microsoft Entra join also works in a hybrid environment and can enable access to on-premises applications and resources.
<a name='related-to-azure-ad-join'></a>
### Related to Microsoft Entra join
- [Join type](#join-type)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
<a name='more-information-about-azure-ad-join'></a>
### More information about Microsoft Entra join
[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview).
<a name='azure-ad-registration'></a>
## Microsoft Entra registration
The goal of Microsoft Entra registered devices is to provide you with support for the _bring your own device_ (BYOD) scenario. In this scenario, a user can access your organization's Microsoft Entra ID-controlled resources using a personal device.
<a name='related-to-azure-ad-registration'></a>
### Related to Microsoft Entra registration
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Join type](#join-type)
<a name='more-information-about-azure-ad-registration'></a>
### More information about Microsoft Entra registration
[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview).
## Certificate trust
The certificate trust model uses a securely issued certificate based on the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The certificate trust model is supported in hybrid and on-premises deployments and is compatible with Windows Server 2008 R2 and later domain controllers.
### Related to certificate trust
- [Deployment type](#deployment-type)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### More information about certificate trust
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Cloud deployment
The Windows Hello for Business cloud deployment is exclusively for organizations using cloud-based identities and resources. Device management is accomplished using Intune or a modern management alternative. Cloud deployments use Microsoft Entra joined or Microsoft Entra registered devices.
### Related to cloud deployment
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra registration](#azure-ad-registration)
- [Deployment type](#deployment-type)
- [Join type](#join-type)
## Cloud experience host
In Windows 10 and Windows 11, cloud experience host is an application used while joining the workplace environment or Microsoft Entra ID for rendering the experience when collecting your company-provided credentials. Once you enroll your device to your workplace environment or Microsoft Entra ID, your organization will be able to manage your PC and collect information about you (including your location). It might add or remove apps or content, change settings, disable features, prevent you from removing your company account, or reset your PC.
### Related to cloud experience host
- [Windows Hello for Business](deploy/requirements.md)
- [Managed Windows Hello in organization](hello-manage-in-organization.md)
### More information on cloud experience host
[Windows Hello for Business and device registration](/azure/active-directory/devices/device-registration-how-it-works)
## Cloud Kerberos trust
The cloud Kerberos trust model offers a simplified deployment experience, when compared to the other trust types.\
@ -120,19 +48,6 @@ With cloud Kerberos trust, there's no need to deploy certificates to the users o
Giving the simplicity offered by this model, cloud Kerberos trust is the recommended model when compared to the key trust model. It is also the preferred deployment model if you do not need to support certificate authentication scenarios.
### Related to cloud Kerberos trust
- [Deployment type](#deployment-type)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### More information about cloud Kerberos trust
[Cloud Kerberos trust deployment](deploy/hybrid-cloud-kerberos-trust.md)
## Deployment type
Windows Hello for Business has three deployment models to accommodate the needs of different organizations. The three deployment models include:
@ -141,16 +56,6 @@ Windows Hello for Business has three deployment models to accommodate the needs
- Hybrid
- On-premises
### Related to deployment type
- [Cloud deployment](#cloud-deployment)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
### More information about deployment type
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Endorsement key
The TPM has an embedded unique cryptographic key called the endorsement key. The TPM endorsement key is a pair of asymmetric keys (RSA size 2048 bits).
@ -167,34 +72,10 @@ The endorsement key is often accompanied by one or two digital certificates:
For certain devices that use firmware-based TPM produced by Intel or Qualcomm, the endorsement certificate is created when the TPM is initialized during the OOBE of Windows 10 and Windows 11.
### Related to endorsement key
- [Attestation identity keys](#attestation-identity-keys)
- [Storage root key](#storage-root-key)
- [Trusted platform module](#trusted-platform-module)
### More information about endorsement key
- [Understand the TPM endorsement key](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/cc770443(v=ws.11))
- [TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
## Federated environment
Primarily for large enterprise organizations with more complex authentication requirements, on-premises directory objects are synchronized with Microsoft Entra ID and users accounts are managed on-premises. With AD FS, users have the same password on-premises and in the cloud and they don't have to sign in again to use Microsoft cloud services. This federated authentication model can provide extra authentication requirements, such as smart card-based authentication or a third-party multi-factor authentication and is typically required when organizations have an authentication requirement not natively supported by Microsoft Entra ID.
### Related to federated environment
- [Hybrid deployment](#hybrid-deployment)
- [Managed environment](#managed-environment)
- [Pass-through authentication](#pass-through-authentication)
- [Password hash sync](#password-hash-sync)
### More information about federated environment
[Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
<a name='hybrid-azure-ad-join'></a>
## Microsoft Entra hybrid join
For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable:
@ -206,34 +87,10 @@ Typically, organizations with an on-premises footprint rely on imaging methods t
If your environment has an on-premises AD footprint and you also want benefit from the capabilities provided by Microsoft Entra ID, you can implement Microsoft Entra hybrid joined devices. These devices are joined to both your on-premises Active Directory and your Microsoft Entra ID.
<a name='related-to-hybrid-azure-ad-join'></a>
### Related to Microsoft Entra hybrid join
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra registration](#azure-ad-registration)
- [Hybrid deployment](#hybrid-deployment)
<a name='more-information-about-hybrid-azure-ad-join'></a>
### More information about Microsoft Entra hybrid join
[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview)
## Hybrid deployment
The Windows Hello for Business hybrid deployment is for organizations that have both on-premises and cloud resources that are accessed using a managed or federated identity that's synchronized with Microsoft Entra ID. Hybrid deployments support devices that are Microsoft Entra registered, Microsoft Entra joined, and Microsoft Entra hybrid joined. The Hybrid deployment model supports three trust types for on-premises authentication: cloud Kerberos trust, key trust and certificate trust.
### Related to hybrid deployment
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra registration](#azure-ad-registration)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about hybrid deployment
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Join type
Join type is how devices are associated with Microsoft Entra ID. For a device to authenticate to Microsoft Entra it must be registered or joined.
@ -244,86 +101,26 @@ When combined with a mobile device management (MDM) solution such as Microsoft I
Joining a device is an extension to registering a device. This method provides you with all the benefits of registering a device, and changes the local state of a device. Changing the local state enables your users to sign-in to a device using an organizational work or school account instead of a personal account.
### Related to join type
- [Microsoft Entra join](#azure-active-directory-join)
- [Microsoft Entra registration](#azure-ad-registration)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
### More information about join type
[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview)
## Key trust
The key trust model uses the user's Windows Hello for Business identity to authenticate to on-premises Active Directory. The key trust model is supported in hybrid and on-premises deployments and requires Windows Server 2016 domain controllers.
### Related to key trust
- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Certificate trust](#certificate-trust)
- [Deployment type](#deployment-type)
- [Microsoft Entra hybrid join](#hybrid-azure-ad-join)
- [Hybrid deployment](#hybrid-deployment)
- [On-premises deployment](#on-premises-deployment)
- [Trust type](#trust-type)
### More information about key trust
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Managed environment
Managed environments are for non-federated environments where Microsoft Entra ID manages the authentication using technologies such as Password Hash Synchronization and Pass-through Authentication rather than a federation service such as Active Directory Federation Services (ADFS).
### Related to managed environment
- [Federated environment](#federated-environment)
- [Pass-through authentication](#pass-through-authentication)
- [Password hash synchronization](#password-hash-sync)
## On-premises deployment
The Windows Hello for Business on-premises deployment is for organizations that exclusively have on-premises resources that are accessed using Active Directory identities. On-premises deployments support domain joined devices. The on-premises deployment model supports two authentication trust types, key trust and certificate trust.
### Related to on-premises deployment
- [Cloud deployment](#cloud-deployment)
- [Deployment type](#deployment-type)
- [Hybrid deployment](#hybrid-deployment)
### More information about on-premises deployment
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Pass-through authentication
Pass-through authentication provides a simple password validation for Microsoft Entra authentication services. It uses a software agent that runs on one or more on-premises servers to validate the users directly with your on-premises Active Directory. With pass-through authentication (PTA), you synchronize on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Allows your users to sign in to both on-premises and Microsoft cloud resources and applications using their on-premises account and password. This configuration validates users' passwords directly against your on-premises Active Directory without sending password hashes to Microsoft Entra ID. Companies with a security requirement to immediately enforce on-premises user account states, password policies, and sign-in hours would use this authentication method. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
### Related to pass-through authentication
- [Federated environment](#federated-environment)
- [Managed environment](#managed-environment)
- [Password hash synchronization](#password-hash-sync)
### More information about pass-through authentication
[Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Password hash sync
Password hash sync is the simplest way to enable authentication for on-premises directory objects in Microsoft Entra ID. With password hash sync (PHS), you synchronize your on-premises Active Directory user account objects with Microsoft Entra ID and manage your users on-premises. Hashes of user passwords are synchronized from your on-premises Active Directory to Microsoft Entra ID so that the users have the same password on-premises and in the cloud. When passwords are changed or reset on-premises, the new password hashes are synchronized to Microsoft Entra ID so that your users can always use the same password for cloud resources and on-premises resources. The passwords are never sent to Microsoft Entra ID or stored in Microsoft Entra ID in clear text. Some premium features of Microsoft Entra ID, such as Identity Protection, require PHS regardless of which authentication method is selected. With seamless single sign-on, users are automatically signed in to Microsoft Entra ID when they are on their corporate devices and connected to your corporate network.
### Related to password hash sync
- [Federated environment](#federated-environment)
- [Managed environment](#managed-environment)
- [Pass-through authentication](#pass-through-authentication)
### More information about password hash sync
[Choose the right authentication method for your Microsoft Entra hybrid identity solution](/azure/active-directory/hybrid/choose-ad-authn)
## Primary refresh token
Single sign on (SSO) relies on special tokens obtained for each of the types of applications above. These special tokens are then used to obtain access tokens to specific applications. In the traditional Windows Integrated authentication case using Kerberos, this token is a Kerberos TGT (ticket-granting ticket). For Microsoft Entra ID and AD FS applications, this token is a _primary refresh token_ (PRT). It's a [JSON Web Token](https://openid.net/specs/draft-jones-json-web-token-07.html) that contains claims about both the user and the device.
@ -336,32 +133,10 @@ The PRT is needed for SSO. Without it, the user will be prompted for credentials
The storage root key (SRK) is also an asymmetric key pair (RSA with a minimum of 2048-bits length). The SRK has a major role and is used to protect TPM keys, so that these keys can't be used without the TPM. The SRK key is created when the ownership of the TPM is taken.
### Related to storage root key
- [Attestation identity keys](#attestation-identity-keys)
- [Endorsement key](#endorsement-key)
- [Trusted platform module](#trusted-platform-module)
### More information about storage root key
[TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)
## Trust type
The trust type determines how a user authenticates to the Active Directory to access on-premises resources. There are two trust types, key trust and certificate trust. The hybrid and on-premises deployment models support both trust types. The trust type doesn't affect authentication to Microsoft Entra ID. Windows Hello for Business authentication to Microsoft Entra ID always uses the key, not a certificate (excluding smart card authentication in a federated environment).
### Related to trust type
- [Cloud Kerberos trust](#cloud-kerberos-trust)
- [Certificate trust](#certificate-trust)
- [Hybrid deployment](#hybrid-deployment)
- [Key trust](#key-trust)
- [On-premises deployment](#on-premises-deployment)
### More information about trust type
[Windows Hello for Business planning guide](hello-planning-guide.md)
## Trusted platform module
A trusted platform module (TPM) is a hardware component that provides unique security features.
@ -400,13 +175,3 @@ In a simplified manner, the TPM is a passive component with limited resources. I
- Nonvolatile memory for storing EK, SRK, and AIK keys
- A cryptographic engine to encrypt, decrypt, and sign
- Volatile memory for storing the PCRs and RSA keys
### Related to trusted platform module
- [Attestation identity keys](#attestation-identity-keys)
- [Endorsement key](#endorsement-key)
- [Storage root key](#storage-root-key)
### More information about trusted platform module
[TPM library specification](https://trustedcomputinggroup.org/resource/tpm-library-specification/)

33
windows/security/identity-protection/hello-for-business/hello-and-password-changes.md
View File

@ -1,33 +0,0 @@
---
title: Windows Hello and password changes
description: Learn the impact of changing a password when using Windows Hello.
ms.date: 03/15/2023
ms.topic: concept-article
---
# Windows Hello and password changes
When you set up Windows Hello, the PIN or biometric gesture that you use is specific to that device. You can set up Hello for the same account on multiple devices. If Windows Hello for Business isn't deployed and the password for that account changes, you must provide the new password on each device to continue to use Hello.
> [!Note]
> This article doesn't apply to Windows Hello for Business. Change the account password will not affect sign-in or unlock, since Windows Hello for Business uses a key or certificate.
**Example 1**
Let's suppose that you have set up a PIN for your Microsoft account on **Device A**. You use your PIN to sign in on **Device A** and then change the password for your Microsoft account.
Since you were using **Device A** when you changed your password, the PIN on **Device A** will continue to work with no other action on your part.
**Example 2**
Suppose that you sign in on **Device B** and change your password for your Microsoft account. The next time that you try to sign in on **Device A** using your PIN, sign-in will fail because the account credentials that Hello on **Device A** knows will be outdated.
>[!NOTE]
>This example also applies to an Active Directory account when [Windows Hello for Business is not implemented](hello-manage-in-organization.md).
## How to update Hello after you change your password on another device
1. When you try to sign in using your PIN or biometric, you'll see the following message: **Your password was changed on a different device. You must sign in to this device once with your new password, and then you can sign in with your PIN.**
1. Select **OK**
1. Select **Sign-in options**
1. Select **Password**
1. Sign in with new password
1. The next time that you sign in, you can select **Sign-in options > PIN** to resume using your PIN.

88
windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md
View File

@ -1,88 +0,0 @@
---
title: Windows Hello biometrics in the enterprise
description: Windows Hello uses biometrics to authenticate users and guard against potential spoofing, through fingerprint matching and facial recognition.
ms.date: 01/12/2021
ms.topic: concept-article
---
# Windows Hello biometrics in the enterprise
Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition.
>[!NOTE]
>When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these technologies into a single solution under the Windows Hello name. Customers who have already deployed these technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find it easier to deploy due to simplified policies, documentation, and semantics.
Because we realize your employees are going to want to use this new technology in your enterprise, we've been actively working with the device manufacturers to create strict design and performance recommendations that help to ensure that you can more confidently introduce Windows Hello biometrics into your organization.
## How does Windows Hello work?
Windows Hello lets your employees use fingerprint, facial recognition, or iris recognition as an alternative method to unlocking a device. With Windows Hello, authentication happens when the employee provides his or her unique biometric identifier while accessing the device-specific Windows Hello credentials.
The Windows Hello authenticator works to authenticate and allow employees onto your enterprise network. Authentication doesn't roam among devices, isn't shared with a server, and can't easily be extracted from a device. If multiple employees share a device, each employee will use his or her own biometric data on the device.
## Why should I let my employees use Windows Hello?
Windows Hello provides many benefits, including:
- It helps to strengthen your protections against credential theft. Because an attacker must have both the device and the biometric info or PIN, it's much more difficult to gain access without the employee's knowledge.
- Employees get a simple authentication method (backed up with a PIN) that's always with them, so there's nothing to lose. No more forgetting passwords!
- Support for Windows Hello is built into the operating system so you can add additional biometric devices and policies as part of a coordinated rollout or to individual employees or groups using Group Policy or Mobile Device Management (MDM) configurations service provider (CSP) policies.<br>For more info about the available Group Policies and MDM CSPs, see the [Implement Windows Hello for Business in your organization](hello-manage-in-organization.md) topic.
## Where is Windows Hello data stored?
The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was actually able to get the biometric data from a device, it cannot be converted back into a raw biometric sample that could be recognized by the biometric sensor.
> [!NOTE]
>Each sensor on a device will have its own biometric database file where template data is stored. Each database has a unique, randomly generated key that is encrypted to the system. The template data for the sensor will be encrypted with this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors will store biometric data on the fingerprint module instead of in the database file.
## Has Microsoft set any device requirements for Windows Hello?
We've been working with the device manufacturers to help ensure a high-level of performance and protection is met by each sensor and device, based on these requirements:
- **False Accept Rate (FAR).** Represents the instance a biometric identification solution verifies an unauthorized person. This is normally represented as a ratio of number of instances in a given population size, for example 1 in 100 000. This can also be represented as a percentage of occurrence, for example, 0.001%. This measurement is heavily considered the most important with regard to the security of the biometric algorithm.
- **False Reject Rate (FRR).** Represents the instances a biometric identification solution fails to verify an authorized person correctly. Usually represented as a percentage, the sum of the True Accept Rate and False Reject Rate is 1. Can be with or without anti-spoofing or liveness detection.
### Fingerprint sensor requirements
To allow fingerprint matching, you must have devices with fingerprint sensors and software. Fingerprint sensors, or sensors that use an employee's unique fingerprint as an alternative logon option, can be touch sensors (large area or small area) or swipe sensors. Each type of sensor has its own set of detailed requirements that must be implemented by the manufacturer, but all of the sensors must include anti-spoofing measures (required).
**Acceptable performance range for small to large size touch sensors**
- False Accept Rate (FAR): &lt;0.001 – 0.002%
- Effective, real world FRR with Anti-spoofing or liveness detection: &lt;10%
**Acceptable performance range for swipe sensors**
- False Accept Rate (FAR): &lt;0.002%
- Effective, real world FRR with Anti-spoofing or liveness detection: &lt;10%
### Facial recognition sensors
To allow facial recognition, you must have devices with integrated special infrared (IR) sensors and software. Facial recognition sensors use special cameras that see in IR light, letting them tell the difference between a photo and a living person while scanning an employee's facial features. These sensors, like the fingerprint sensors, must also include anti-spoofing measures (required) and a way to configure them (optional).
- False Accept Rate (FAR): &lt;0.001%
- False Reject Rate (FRR) without Anti-spoofing or liveness detection: &lt;5%
- Effective, real world FRR with Anti-spoofing or liveness detection: &lt;10%
> [!NOTE]
>Windows Hello face authentication does not currently support wearing a mask during enrollment or authentication. Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this topic further. Please remove a mask if you are wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, please consider unenrolling from face authentication and only using PIN or fingerprint.
### Iris recognition sensor requirements
To use Iris authentication, you'll need a [HoloLens 2 device](/hololens/). All HoloLens 2 editions are equipped with the same sensors. Iris is implemented the same way as other Windows Hello technologies and achieves biometrics security FAR of 1/100K.
## Related topics
- [Windows Hello for Business](deploy/requirements.md)
- [How Windows Hello for Business works](hello-how-it-works.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
- [Windows Hello and password changes](hello-and-password-changes.md)
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
- [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)

4
windows/security/identity-protection/hello-for-business/hello-deployment-issues.md
View File

@ -8,8 +8,6 @@ ms.topic: troubleshooting
The content of this article is to help troubleshoot known deployment issues for Windows Hello for Business.
<a name='pin-reset-on-azure-ad-join-devices-fails-with-we-cant-open-that-page-right-now-error'></a>
## PIN reset on Microsoft Entra join devices fails with *We can't open that page right now* error
PIN reset on Microsoft Entra joined devices uses a flow called *web sign-in* to authenticate the user above lock. Web sign in only allows navigation to specific domains. If web sign-in attempts to navigate to a domain that isn't allowed, it displays a page with the error message *We can't open that page right now*.
@ -50,8 +48,6 @@ After the initial sign-in attempt, the user's Windows Hello for Business public
To resolve the issue, update Windows Server 2016 and 2019 domain controllers with the latest patches. For Windows Server 2016, the behavior is fixed in build *14393.4104* ([KB4593226](https://support.microsoft.com/help/4593226)) and later. For Windows Server 2019, the behavior is fixed in build *17763.1637* ([KB4592440](https://support.microsoft.com/help/4592440)).
<a name='azure-ad-joined-device-access-to-on-premises-resources-using-key-trust-and-third-party-certificate-authority-ca'></a>
## Microsoft Entra joined device access to on-premises resources using key trust and third-party Certificate Authority (CA)
Applies to:

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

@ -20,7 +20,7 @@ sections:
- question: How can a PIN be more secure than a password?
answer: |
When using Windows Hello for Business, the PIN isn't a symmetric key, whereas the password is a symmetric key. With passwords, there's a server that has some representation of the password. With Windows Hello for Business, the PIN is user-provided entropy used to load the private key in the Trusted Platform Module (TPM). The server doesn't have a copy of the PIN. For that matter, the Windows client doesn't have a copy of the current PIN either. The user must provide the entropy, the TPM-protected key, and the TPM that generated that key in order to successfully access the private key.
The statement "PIN is stronger than Password" is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](feature-multifactor-unlock.md) feature.
The statement *PIN is stronger than Password* is not directed at the strength of the entropy used by the PIN. It's about the difference between providing entropy versus continuing the use of a symmetric key (the password). The TPM has anti-hammering features that thwart brute-force PIN attacks (an attacker's continuous attempt to try all combination of PINs). Some organizations may worry about shoulder surfing. For those organizations, rather than increase the complexity of the PIN, implement the [Multifactor Unlock](multifactor-unlock.md) feature.
- question: How does Windows Hello for Business authentication work?
answer: |
When a user wants to access protected key material, the authentication process begins with the user entering a PIN or biometric gesture to unlock the device, a process sometimes called releasing the key. Think of it like using a physical key to unlock a door: before you can unlock the door, you need to remove the key from your pocket or purse. The user's PIN unlocks the protector key for the container on the device. When that container is unlocked, applications (and thus the user) can use whatever IDP keys reside inside the container.
@ -222,7 +222,7 @@ sections:
Windows Hello for Business credentials need access to device state, which is not available in private browser mode or incognito mode. Hence it can't be used in private browser or Incognito mode.
- question: Can I use both a PIN and biometrics to unlock my device?
answer: |
You can use *multifactor unlock* to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see [Multifactor Unlock](feature-multifactor-unlock.md).
You can use *multifactor unlock* to require users to provide an extra factor to unlock their device. Authentication remains two-factor, but another factor is required before Windows allows the user to reach the desktop. To learn more, see [Multifactor Unlock](multifactor-unlock.md).
- name: Cloud Kerberos trust
questions:

54
windows/security/identity-protection/hello-for-business/hello-how-it-works.md
View File

@ -1,54 +0,0 @@
---
title: How Windows Hello for Business works
description: Learn how Windows Hello for Business works, and how it can help your users authenticate to services.
ms.date: 05/05/2018
ms.topic: overview
---
# How Windows Hello for Business works in Windows Devices
Windows Hello for Business is a two-factor credential that is a more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered devices. Windows Hello for Business also works for domain joined devices.
Watch this quick video where Pieter Wigleven gives a simple explanation of how Windows Hello for Business works and some of its supporting features.
> [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8]
## Technical Deep Dive
Windows Hello for Business is a distributed system that uses several components to accomplish device registration, provisioning, and authentication. Use this section to gain a better understanding of each of the categories and how they support Windows Hello for Business.
### Device Registration
Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration is where the device **registers** its identity with the identity provider. For cloud and hybrid deployments, the identity provider is Microsoft Entra ID and the device registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS).
For more information, read [how device registration works](/azure/active-directory/devices/device-registration-how-it-works).
### Provisioning
Provisioning is when the user uses one form of authentication to request a new Windows Hello for Business credential. Typically the user signs in to Windows using user name and password. The provisioning flow requires a second factor of authentication before it will create a strong, two-factor Windows Hello for Business credential.
Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business provisioning works.
> [!VIDEO https://www.youtube.com/embed/RImGsIjSJ1s]
For more information, read [how provisioning works](hello-how-it-works-provisioning.md).
### Authentication
With the device registered and provisioning complete, users can sign-in to Windows using biometrics or a PIN. PIN is the most common gesture and is available on all computers unless restricted by policy requiring a TPM. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. Neither the PIN nor the private portion of the credential are ever sent to the identity provider, and the PIN is not stored on the device. It is user provided entropy when performing operations that use the private portion of the credential.
Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business authentication works.
> [!VIDEO https://www.youtube.com/embed/WPmzoP_vMek]
For more information read [how authentication works](hello-how-it-works-authentication.md).
## Related topics
- [Technology and Terminology](hello-how-it-works-technology.md)
- [Windows Hello for Business](deploy/requirements.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
- [Windows Hello and password changes](hello-and-password-changes.md)
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
- [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)

8
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md
View File

@ -16,7 +16,7 @@ If you plan to use certificates for on-premises single-sign on, then follow thes
Steps you'll perform include:
- [Prepare Microsoft Entra Connect](#prepare-azure-ad-connect)
- [Prepare Microsoft Entra Connect](#prepare-microsoft-entra-connect)
- [Prepare the Network Device Enrollment Services Service Account](#prepare-the-network-device-enrollment-services-ndes-service-account)
- [Prepare Active Directory Certificate Services](#prepare-active-directory-certificate-authority)
- [Install the Network Device Enrollment Services Role](#install-and-configure-the-ndes-role)
@ -49,8 +49,6 @@ If you need to deploy more than three types of certificates to the Microsoft Ent
All communication occurs securely over port 443.
<a name='prepare-azure-ad-connect'></a>
## Prepare Microsoft Entra Connect
Successful authentication to on-premises resources using a certificate requires the certificate to provide a hint about the on-premises domain. The hint can be the user's Active Directory distinguished name as the subject of the certificate, or the hint can be the user's user principal name where the suffix matches the Active Directory domain name.
@ -59,8 +57,6 @@ Most environments change the user principal name suffix to match the organizatio
To include the on-premises distinguished name in the certificate's subject, Microsoft Entra Connect must replicate the Active Directory **distinguishedName** attribute to the Microsoft Entra ID **onPremisesDistinguishedName** attribute. Microsoft Entra Connect version 1.1.819 includes the proper synchronization rules needed for these attributes.
<a name='verify-azure-active-directory-connect-version'></a>
### Verify Microsoft Entra Connect version
Sign-in to computer running Microsoft Entra Connect with access equivalent to _local administrator_.
@ -287,8 +283,6 @@ Sign-in to the issuing certificate authority or management workstations with _Do
11. Select on the **Apply** to save changes and close the console.
<a name='create-an-azure-ad-joined-windows-hello-for-business-authentication-certificate-template'></a>
### Create a Microsoft Entra joined Windows Hello for Business authentication certificate template
During Windows Hello for Business provisioning, Windows requests an authentication certificate from Microsoft Intune, which requests the authentication certificate on behalf of the user. This task configures the Windows Hello for Business authentication certificate template. You use the name of the certificate template when configuring the NDES Server.

2
windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md
View File

@ -217,8 +217,6 @@ With the CA properly configured with a valid HTTP-based CRL distribution point,
1. Review the information below the list of fields to confirm the new URL for the CRL distribution point is present in the certificate. Select **OK**
![New Certificate with updated CDP.](images/aadj/dc-cert-with-new-cdp.png)
<a name='deploy-the-root-ca-certificate-to-azure-ad-joined-devices'></a>
## Deploy the root CA certificate to Microsoft Entra joined devices
The domain controllers have a certificate that includes the new CRL distribution point. Next, you need the enterprise root certificate so you can deploy it to Microsoft Entra joined devices. When you deploy the enterprise root certificates to a device, it ensures the device trusts any certificates issued by the certificate authority. Without the certificate, Microsoft Entra joined devices don't trust domain controller certificates and authentication fails.

103
windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md
View File

@ -1,103 +0,0 @@
---
title: Manage Windows Hello in your organization
description: Learn how to create a Group Policy or mobile device management (MDM) policy to configure and deploy Windows Hello for Business.
ms.date: 9/25/2023
ms.topic: reference
---
# Manage Windows Hello for Business in your organization
You can create a Group Policy or mobile device management (MDM) policy to configure Windows Hello for Business on Windows devices.
>[!IMPORTANT]
>Windows Hello as a convenience PIN is disabled by default on all domain joined and Microsoft Entra joined devices. To enable a convenience PIN, enable the Group Policy setting **Turn on convenience PIN sign-in**.
>
>Use **PIN Complexity** policy settings to manage PINs for Windows Hello for Business.
## Group Policy settings for Windows Hello for Business
The following table lists the Group Policy settings that you can configure for Windows Hello use in your organization. These policy settings are available in **User configuration** and **Computer Configuration** under **Policies** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**.
> [!NOTE]
> The location of the PIN complexity section of the Group Policy is: **Computer Configuration > Administrative Templates > System > PIN Complexity**.
|Policy|Scope|Options|
|--- |--- |--- |
|Use Windows Hello for Business|Computer or user|- **Not configured**: Device doesn't provision Windows Hello for Business for any user.<br>- **Enabled**: Device provisions Windows Hello for Business using keys or certificates for all users.<br>- **Disabled**: Device doesn't provision Windows Hello for Business for any user.|
|Use a hardware security device|Computer|- **Not configured**: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.<br>- **Enabled**: Windows Hello for Business will only be provisioned using TPM. This feature will provision Windows Hello for Business using TPM 1.2 unless the option to exclude them is explicitly set.<br>- **Disabled**: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.|
|Use certificate for on-premises authentication|Computer or user|- **Not configured**: Windows Hello for Business enrolls a key that is used for on-premises authentication.<br>- **Enabled**: Windows Hello for Business enrolls a sign-in certificate using ADFS that is used for on-premises authentication.<br>- **Disabled**: Windows Hello for Business enrolls a key that is used for on-premises authentication.|
|Use PIN recovery|Computer|- Added in Windows 10, version 1703<br>- **Not configured**: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service<br>- **Enabled**: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset<br>- **Disabled**: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service.<br>- For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
|Use biometrics|Computer|- **Not configured**: Biometrics can be used as a gesture in place of a PIN<br>- **Enabled**: Biometrics can be used as a gesture in place of a PIN.<br>- **Disabled**: Only a PIN can be used as a gesture.|
### PIN Complexity
|Policy|Scope|Options|
|--- |--- |--- |
|Require digits|Computer|- **Not configured**: Users must include a digit in their PIN.<br>- **Enabled**: Users must include a digit in their PIN.<br>- **Disabled**: Users can't use digits in their PIN.|
|Require lowercase letters|Computer|- **Not configured**: Users can't use lowercase letters in their PIN<br>- **Enabled**: Users must include at least one lowercase letter in their PIN.<br>- **Disabled**: Users can't use lowercase letters in their PIN.|
|Maximum PIN length|Computer|- **Not configured**: PIN length must be less than or equal to 127.<br>- **Enabled**: PIN length must be less than or equal to the number you specify.<br>- **Disabled**: PIN length must be less than or equal to 127.|
|Minimum PIN length|Computer|- **Not configured**: PIN length must be greater than or equal to 4.<br>- **Enabled**: PIN length must be greater than or equal to the number you specify.<br>- **Disabled**: PIN length must be greater than or equal to 4.|
|Expiration|Computer|- **Not configured**: PIN doesn't expire.<br>- **Enabled**: PIN can be set to expire after any number of days between 1 and 730, or PIN can be set to never expire by setting policy to 0.<br>- **Disabled**: PIN doesn't expire.|
|History|Computer|- **Not configured**: Previous PINs aren't stored.<br>- **Enabled**: Specify the number of previous PINs that can be associated to a user account that can&#39;t be reused.<br>- **Disabled**: Previous PINs aren't stored.<br>**Note** Current PIN is included in PIN history.
|Require special characters|Computer|- **Not configured**: Windows allows, but doesn't require, special characters in the PIN.<br>- **Enabled**: Windows requires the user to include at least one special character in their PIN.<br>- **Disabled**: Windows doesn't allow the user to include special characters in their PIN.|
|Require uppercase letters|Computer|- **Not configured**: Users can't include an uppercase letter in their PIN.<br>- **Enabled**: Users must include at least one uppercase letter in their PIN.<br>- **Disabled**: Users can't include an uppercase letter in their PIN.|
### Phone Sign-in
|Policy|Scope|Options|
|--- |--- |--- |
|Use Phone Sign-in|Computer|Not currently supported.|
## MDM policy settings for Windows Hello for Business
The following table lists the MDM policy settings that you can configure for Windows Hello for Business use in your workplace. These MDM policy settings use the [PassportForWork configuration service provider (CSP)](/windows/client-management/mdm/passportforwork-csp).
>[!IMPORTANT]
>All devices only have one PIN associated with Windows Hello for Business. This means that any PIN on a device will be subject to the policies specified in the PassportForWork CSP. The values specified take precedence over any complexity rules set via Exchange ActiveSync (EAS) or the DeviceLock CSP.
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
|UsePassportForWork|Device or user|True|- True: Windows Hello for Business will be provisioned for all users on the device.<br>- False: Users won't be able to provision Windows Hello for Business. <br>**Note:** If Windows Hello for Business is enabled, and then the policy is changed to False, users who previously set up Windows Hello for Business can continue to use it, but won't be able to set up Windows Hello for Business on other devices|
|RequireSecurityDevice|Device or user|False|- True: Windows Hello for Business will only be provisioned using TPM.<br>- False: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.|
|ExcludeSecurityDevice<br>- TPM12|Device|False|Added in Windows 10, version 1703<br>- True: TPM revision 1.2 modules will be disallowed from being used with Windows Hello for Business.<br>- False: TPM revision 1.2 modules will be allowed to be used with Windows Hello for Business.|
|EnablePinRecovery|Device or use|False|- Added in Windows 10, version 1703<br>- True: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset.<br>- False: Windows Hello for Business doesn't create or store a PIN recovery secret. PIN reset doesn't use the Azure-based PIN recovery service. For more information about using the PIN recovery service for PIN reset see [Windows Hello for Business PIN Reset](hello-feature-pin-reset.md).|
### Biometrics
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
|UseBiometrics|Device |False|- True: Biometrics can be used as a gesture in place of a PIN for domain sign-in.<br>- False: Only a PIN can be used as a gesture for domain sign-in.|
|- FacialFeaturesUser<br>-&nbsp;EnhancedAntiSpoofing|Device|Not configured|- Not configured: users can choose whether to turn on enhanced anti-spoofing.<br>- True: Enhanced anti-spoofing is required on devices which support it.<br>- False: Users can't turn on enhanced anti-spoofing.|
### PINComplexity
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
|Digits |Device or user|1 |- 0: Digits are allowed. <br>- 1: At least one digit is required.<br>- 2: Digits aren't allowed.|
|Lowercase letters |Device or user|2|- 0: Lowercase letters are allowed. <br>- 1: At least one lowercase letter is required.<br>- 2: Lowercase letters aren't allowed.|
|Special characters|Device or user|2|- 0: Special characters are allowed. <br>- 1: At least one special character is required. <br>- 2: Special characters aren't allowed.|
|Uppercase letters|Device or user|2|- 0: Uppercase letters are allowed. <br>- 1: At least one uppercase letter is required.<br>- 2: Uppercase letters aren't allowed.|
|Maximum PIN length |Device or user|127 |- Maximum length that can be set is 127. Maximum length can't be less than minimum setting.|
|Minimum PIN length|Device or user|6|- Minimum length that can be set is 6. Minimum length can't be greater than maximum setting.|
|Expiration |Device or user|0|- Integer value specifies the period of time (in days) that a PIN can be used before the system requires the user to change it. The largest number you can configure for this policy setting is 730. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then the user's PIN will never expire.|
|History|Device or user|0|- Integer value that specifies the number of past PINs that can be associated to a user account that can't be reused. The largest number you can configure for this policy setting is 50. The lowest number you can configure for this policy setting is 0. If this policy is set to 0, then storage of previous PINs isn't required.|
### Remote
|Policy|Scope|Default|Options|
|--- |--- |--- |--- |
|UseRemotePassport|Device or user|False|Not currently supported.|
>[!NOTE]
> If a policy isn't explicitly configured to require letters or special characters, users can optionally set an alphanumeric PIN.
## Policy conflicts from multiple policy sources
Windows Hello for Business is designed to be managed by group policy or MDM, but not a combination of both. Avoid mixing group policy and MDM policy settings for Windows Hello for Business. If you mix group policy and MDM policy settings, the MDM settings are ignored until all group policy settings are cleared.
> [!IMPORTANT]
> The [*MDMWinsOverGP*](/windows/client-management/mdm/policy-csp-controlpolicyconflict#mdmwinsovergp) policy setting doesn't apply to Windows Hello for Business. MDMWinsOverGP only applies to policies in the *Policy CSP*, while the Windows Hello for Business policies are in the *PassportForWork CSP*.
## Policy precedence
Windows Hello for Business *user policies* take precedence over *computer policies*. If a user policy is set, the corresponded computer policy is ignored. If a user policy is not set, the computer policy is used.

342
windows/security/identity-protection/hello-for-business/hello-planning-guide.md
View File

@ -1,342 +0,0 @@
---
title: Plan a Windows Hello for Business Deployment
description: Learn about the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of your infrastructure.
ms.date: 09/16/2020
ms.topic: overview
---
# Plan a Windows Hello for Business Deployment
Congratulations! You're taking the first step forward in helping move your organizations away from password to a two-factor, convenience authentication for Windows — Windows Hello for Business. This planning guide helps you understand the different topologies, architectures, and components that encompass a Windows Hello for Business infrastructure.
This guide explains the role of each component within Windows Hello for Business and how certain deployment decisions affect other aspects of the infrastructure. Armed with your planning worksheet, you'll use that information to select the correct deployment guide for your needs.
> [!Note]
> If you have a Microsoft Entra ID tenant, you can use our online, interactive Passwordless Wizard which walks through the same choices instead of using our manual guide below. The Passwordless Wizard is available in the [Microsoft 365 admin center](https://admin.microsoft.com/AdminPortal/Home#/modernonboarding/passwordlesssetup).
## Using this guide
There are many options from which you can choose when deploying Windows Hello for Business. Providing multiple options ensures nearly every organization can deploy Windows Hello for Business. Providing many options makes the deployment appear complex, however, most organization will realize they've already implemented most of the infrastructure on which the Windows Hello for Business deployment depends. It's important to understand that Windows Hello for Business is a distributed system and does take proper planning across multiple teams within an organization.
This guide removes the appearance of complexity by helping you make decisions on each aspect of your Windows Hello for Business deployment and the options you'll need to consider. Using this guide also identifies the information needed to help you make decisions about the deployment that best suits your environment. Download the [Windows Hello for Business planning worksheet](https://go.microsoft.com/fwlink/?linkid=852514) from the Microsoft Download Center to help track your progress and make your planning easier.
### How to Proceed
Read this document and record your decisions on the worksheet. When finished, your worksheet has all the necessary information for your Windows Hello for Business deployment.
There are six major categories you need to consider for a Windows Hello for Business deployment. Those categories are:
- Deployment Options
- Client
- Management
- Active Directory
- Public Key Infrastructure
- Cloud
### Baseline Prerequisites
Windows Hello for Business has a few baseline prerequisites with which you can begin. These baseline prerequisites are provided in the worksheet.
### Deployment Options
The goal of Windows Hello for Business is to enable deployments for all organizations of any size or scenario. To provide this type of granular deployment, Windows Hello for Business offers a diverse choice of deployment options.
#### Deployment models
There are three deployment models from which you can choose: cloud only, hybrid, and on-premises.
##### Cloud only
The cloud only deployment model is for organizations who only have cloud identities and don't access on-premises resources. These organizations typically join their devices to the cloud and exclusively use resources in the cloud such as SharePoint, OneDrive, and others. Also, because these users don't use on-premises resources, they don't need certificates for things like VPN because everything they need is hosted in Azure.
##### Hybrid
The hybrid deployment model is for organizations that:
- Are federated with Microsoft Entra ID
- Have identities synchronized to Microsoft Entra ID using Microsoft Entra Connect
- Use applications hosted in Microsoft Entra ID, and want a single sign-in user experience for both on-premises and Microsoft Entra resources
> [!Important]
> Hybrid deployments support non-destructive PIN reset that works with both the certificate trust and key trust models.
>
> **Requirements:**
> - Microsoft PIN Reset Service - Windows 10, versions 1709 to 1809, Enterprise Edition. There is no licensing requirement for this service since version 1903
> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
##### On-premises
The on-premises deployment model is for organizations that don't have cloud identities or use applications hosted in Microsoft Entra ID.
> [!Important]
> On-premises deployments support destructive PIN reset that works with both the certificate trust and the key trust models.
>
> **Requirements:**
> - Reset from settings - Windows 10, version 1703, Professional
> - Reset above lock screen - Windows 10, version 1709, Professional
> - Reset above lock screen (_I forgot my PIN_ link) - Windows 10, version 1903
It's fundamentally important to understand which deployment model to use for a successful deployment. Some aspects of the deployment may have already been decided for you based on your current infrastructure.
#### Trust types
A deployment's trust type defines how each Windows Hello for Business client authenticates to the on-premises Active Directory. There are two trust types: key trust and certificate trust.
> [!NOTE]
> Windows Hello for Business introduced a new trust model called cloud Kerberos trust, in early 2022. This model enables deployment of Windows Hello for Business using the infrastructure introduced for supporting [security key sign-in on Microsoft Entra hybrid joined devices and on-premises resource access on Microsoft Entra joined devices](/azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises). For more information, see [Hybrid Cloud Kerberos Trust Deployment](deploy/hybrid-cloud-kerberos-trust.md).
The key trust type doesn't require issuing authentication certificates to end users. Users authenticate using a hardware-bound key created during the built-in provisioning experience. This requires an adequate distribution of Windows Server 2016 or later domain controllers relative to your existing authentication and the number of users included in your Windows Hello for Business deployment. Read the [Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments](hello-adequate-domain-controllers.md) to learn more.
The certificate trust type issues authentication certificates to end users. Users authenticate using a certificate requested using a hardware-bound key created during the built-in provisioning experience. Unlike key trust, certificate trust doesn't require Windows Server 2016 domain controllers (but still requires [Windows Server 2016 or later Active Directory schema](/windows/security/identity-protection/hello-for-business/hello-hybrid-cert-trust#directories)). Users can use their certificate to authenticate to any Windows Server 2008 R2, or later, domain controller.
> [!NOTE]
> RDP does not support authentication with Windows Hello for Business key trust deployments as a supplied credential. RDP is only supported with certificate trust deployments as a supplied credential at this time. Windows Hello for Business key trust can be used with [Remote Credential Guard](../remote-credential-guard.md).
#### Device registration
All devices included in the Windows Hello for Business deployment must go through device registration. Device registration enables devices to authenticate to identity providers. For cloud only and hybrid deployment, the identity provider is Microsoft Entra ID. For on-premises deployments, the identity provider is the on-premises server running the Windows Server 2016 Active Directory Federation Services (AD FS) role.
#### Key registration
The built-in Windows Hello for Business provisioning experience creates a hardware bound asymmetric key pair as their user's credentials. The private key is protected by the device's security modules; however, the credential is a user key (not a device key). The provisioning experience registers the user's public key with the identity provider. For cloud only and hybrid deployments, the identity provider is Microsoft Entra ID. For on-premises deployments, the identity provider is the on-premises server running Windows Server 2016 Active Directory Federation Services (AD FS) role.
#### Multifactor authentication
> [!IMPORTANT]
> As of July 1, 2019, Microsoft will no longer offer MFA Server for new deployments. New customers who require multifactor authentication for their users should use cloud-based Microsoft Entra multifactor authentication. Existing customers who have activated MFA Server prior to July 1, 2019 will be able to download the latest version, future updates and generate activation credentials as usual. See [Getting started with the Azure Multi-Factor Authentication Server](/azure/active-directory/authentication/howto-mfaserver-deploy) for more details.
The goal of Windows Hello for Business is to move organizations away from passwords by providing them with a strong credential that enables easy two-factor authentication. The built-in provisioning experience accepts the user's weak credentials (username and password) as the first factor authentication; however, the user must provide a second factor of authentication before Windows provisions a strong credential.
Cloud only and hybrid deployments provide many choices for multifactor authentication. On-premises deployments must use a multifactor authentication that provides an AD FS multifactor adapter to be used in conjunction with the on-premises Windows Server 2016 AD FS server role. Organizations can use the on-premises Azure Multi-Factor Authentication Server, or choose from several third parties (Read [Microsoft and third-party additional authentication methods](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods) for more information).
> [!NOTE]
> Microsoft Entra multifactor authentication is available through:
> * Microsoft Enterprise Agreement
> * Open Volume License Program
> * Cloud Solution Providers program
> * Bundled with
> * Microsoft Entra ID P1 or P2
> * Enterprise Mobility Suite
> * Enterprise Cloud Suite
#### Directory synchronization
Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose. Hybrid deployments use Microsoft Entra Connect to synchronize Active Directory identities or credentials between itself and Microsoft Entra ID. This helps enable single sign-on to Microsoft Entra ID and its federated components. On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA Server, which sends data to the Azure MFA cloud service to perform the verification.
### Management
Windows Hello for Business provides organizations with a rich set of granular policy settings with which they can use to manage their devices and users. There are three ways in which you can manage Windows Hello for Business: Group Policy, Modern Management, and Mixed.
#### Group Policy
Group Policy is the easiest and most popular way to manage Windows Hello for Business on domain joined devices. Simply create a Group Policy object with the settings you desire. Link the Group Policy object high in your Active Directory and use security group filtering to target specific sets of computers or users. Or, link the GPO directly to the organizational units.
#### Modern management
Modern management is an emerging device management paradigm that leverages the cloud for managing domain joined and nondomain joined devices. Organizations can unify their device management into one platform and apply policy settings using a single platform
### Client
Windows Hello for Business is an exclusive Windows 10 and Windows 11 feature. As part of the Windows as a Service strategy, Microsoft has improved the deployment, management, and user experience with each new release of Windows and introduced support for new scenarios.
Most deployment scenarios require a minimum of Windows 10, version 1511, also known as the November Update. The client requirement might change based on different components in your existing infrastructure, or other infrastructure choices made later in planning your deployment. Those components and choices might require a minimum client running Windows 10, version 1703, also known as the Creators Update.
### Active Directory
Hybrid and on-premises deployments include Active Directory as part of their infrastructure. Most of the Active Directory requirements, such as schema, and domain and forest functional levels are predetermined. However, your trust type choice for authentication determines the version of domain controller needed for the deployment.
### Public Key Infrastructure
The Windows Hello for Business deployment depends on an enterprise public key infrastructure as a trust anchor for authentication. Domain controllers for hybrid and on-premises deployments need a certificate in order for Windows devices to trust the domain controller as legitimate. Deployments using the certificate trust type need an enterprise public key infrastructure and a certificate registration authority to issue authentication certificates to users. Hybrid deployments might need to issue VPN certificates to users to enable connectivity on-premises resources.
### Cloud
Some deployment combinations require an Azure account, and some require Microsoft Entra ID for user identities. These cloud requirements may only need an Azure account while other features need a Microsoft Entra ID P1 or P2 subscription. The planning process identifies and differentiates the components that are needed from those that are optional.
## Planning a Deployment
Planning your Windows Hello for Business deployment begins with choosing a deployment type. Like all distributed systems, Windows Hello for Business depends on multiple components within your organization's infrastructure.
Use the remainder of this guide to help with planning your deployment. As you make decisions, write the results of those decisions in your planning worksheet. When finished, you'll have all the information needed to complete the planning process and the appropriate deployment guide that best helps you with your deployment.
### Deployment Model
Choose the deployment model based on the resources your users access. Use the following guidance to make your decision.
If your organization doesn't have on-premises resources, write **Cloud Only** in box **1a** on your planning worksheet.
If your organization is federated with Azure or uses any service, such as AD Connect, Office365 or OneDrive, or your users access cloud and on-premises resources, write **Hybrid** in box **1a** on your planning worksheet.
If your organization doesn't have cloud resources, write **On-Premises** in box **1a** on your planning worksheet.
>[!NOTE]
>
>- Main use case of On-Premises deployment is for "Enhanced Security Administrative Environments" also known as "Red Forests"
>- Migration from on-premise to hybrid deployment will require redeployment
### Trust type
Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
Choose a trust type that is best suited for your organizations. Remember, the trust type determines two things. Whether you issue authentication certificates to your users and if your deployment needs Windows Server 2016 domain controllers.
One trust model isn't more secure than the other. The major difference is based on the organization comfort with deploying Windows Server 2016 domain controllers and not enrolling users with end entity certificates (key-trust) against using existing domain controllers and needing to enroll certificates for all their users (certificate trust).
Because the certificate trust types issues certificates, there's more configuration and infrastructure needed to accommodate user certificate enrollment, which could also be a factor to consider in your decision. Additional infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you need to activate the Device Writeback option in Microsoft Entra Connect.
If your organization wants to use the key trust type, write **key trust** in box **1b** on your planning worksheet. Write **Windows Server 2016** in box **4d**. Write **N/A** in box **5b**.
If your organization wants to use the certificate trust type, write **certificate trust** in box **1b** on your planning worksheet. Write **Windows Server 2008 R2 or later** in box **4d**. In box **5c**, write **smart card logon** under the **Template Name** column and write **users** under the **Issued To** column on your planning worksheet.
### Device Registration
A successful Windows Hello for Business requires all devices to register with the identity provider. The identity provider depends on the deployment model.
If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, write **Azure** in box **1c** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, write **AD FS** in box **1c** on your planning worksheet.
### Key Registration
All users provisioning Windows Hello for Business have their public key registered with the identity provider. The identity provider depends on the deployment model.
If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, write **Azure** in box **1d** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, write **AD FS** in box **1d** on your planning worksheet.
### Directory Synchronization
Windows Hello for Business is strong user authentication, which usually means there's an identity (a user or username) and a credential (typically a key pair). Some operations require writing or reading user data to or from the directory. For example, reading the user's phone number to perform multifactor authentication during provisioning or writing the user's public key.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **1e**. User information is written directly to Microsoft Entra ID and there isn't another directory with which the information must be synchronized.
If box **1a** on your planning worksheet reads **hybrid**, then write **Microsoft Entra Connect** in box **1e** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, then write **Azure MFA Server**. This deployment exclusively uses Active Directory for user information with the exception of the multifactor authentication. The on-premises Azure MFA server synchronizes a subset of the user information, such as phone number, to provide multifactor authentication while the user's credentials remain on the on-premises network.
### Multifactor authentication
The goal of Windows Hello for Business is to move user authentication away from passwords to a strong, key-based user authentication. Passwords are weak credentials and can't be trusted by themselves as an attacker with a stolen password could be attempting to enroll in Windows Hello for Business. To keep the transition from a weak to a strong credential secure, Windows Hello for Business relies on multifactor authentication during provisioning to have some assurances that the user identity provisioning a Windows Hello for Business credential is the proper identity.
If box **1a** on your planning worksheet reads **cloud only**, then your only option is to use the Azure MFA cloud service. Write **Azure MFA** in box **1f** on your planning worksheet.
If box **1a** on your planning worksheet reads **hybrid**, then you have a few options, some of which depend on your directory synchronization configuration. The options from which you may choose include:
* Directly use Azure MFA cloud service
* Use AD FS w/Azure MFA cloud service adapter
* Use AD FS w/Azure MFA Server adapter
* Use AD FS w/3rd Party MFA Adapter
You can directly use the Azure MFA cloud service for the second factor of authentication. Users contacting the service must authenticate to Azure prior to using the service.
If your Microsoft Entra Connect is configured to synchronize identities (usernames only), then your users are redirected to your local on-premises federation server for authentication and then redirected back to the Azure MFA cloud service. Otherwise, your Microsoft Entra Connect is configured to synchronize credentials (username and passwords), which enables your users to authenticate to Microsoft Entra ID and use the Azure MFA cloud service. If you choose to use the Azure MFA cloud service directly, write **Azure MFA** in box **1f** on your planning worksheet.
You can configure your on-premises Windows Server 2016 AD FS role to use the Azure MFA service adapter. In this configuration, users are redirected to the on premises AD FS server (synchronizing identities only). The AD FS server uses the MFA adapter to communicate to the Azure MFA service to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA cloud service adapter, write **AD FS with Azure MFA cloud adapter** in box **1f** on your planning worksheet.
Alternatively, you can use AD FS with an on-premises Azure MFA server adapter. Rather than AD FS communicating directly with the Azure MFA cloud service, it communicates with an on-premises Azure MFA server that synchronizes user information with the on-premises Active Directory. The Azure MFA server communicates with Azure MFA cloud services to perform the second factor of authentication. If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with Azure MFA server adapter** in box **1f** on your planning worksheet.
The last option is for you to use AD FS with a third-party adapter as the second factor of authentication. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, then you have two-second factor authentication options. You must use Windows Server 2016 AD FS with your choice of the on-premises Azure MFA server or with a third-party MFA adapter.
If you choose to use AD FS with the Azure MFA server adapter, write **AD FS with Azure MFA server adapter** in box **1f** on your planning worksheet. If you choose to use AD FS with a third-party MFA adapter, write **AD FS with third party** in box **1f** on your planning worksheet.
### Management
Windows Hello for Business provides organizations with many policy settings and granular control on how these settings may be applied to both computers and users. The type of policy management you can use depends on your selected deployment and trust models.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **2a** on your planning worksheet. You have the option to manage nondomain joined devices. If you choose to manage Microsoft Entra joined devices, write **modern management** in box **2b** on your planning worksheet. Otherwise, write** N/A** in box **2b**.
> [!NOTE]
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
If box **1a** on your planning worksheet reads **on-prem**, write **GP** in box **2a** on your planning worksheet. Write **N/A** in box **2b** on your worksheet.
Managing hybrid deployments includes two categories of devices to consider for your Windows Hello for Business deployment—domain joined and nondomain joined. All devices are registered, however, not all devices are domain joined. You have the option of using Group Policy for domain joined devices and modern management for nondomain joined devices. Or, you can use modern management for both domain and nondomain joined devices.
If you use Group Policy to manage your domain joined devices, write **GP** in box **2a** on your planning worksheet. Write **modern management** in box **2b** if you decide to manage nondomain joined devices; otherwise, write **N/A**.
If you use modern management for both domain and nondomain joined devices, write **modern management** in box **2a** and **2b** on your planning worksheet.
### Client
Windows Hello for Business is a feature exclusive to Windows 10 and Windows 11. Some deployments and features are available using earlier versions of Windows 10. Others need the latest versions.
If box **1a** on your planning worksheet reads **cloud only**, write **N/A** in box **3a** on your planning worksheet. Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
> [!NOTE]
> Microsoft Entra joined devices without modern management automatically enroll in Windows Hello for Business using the default policy settings. Use modern management to adjust policy settings to match the business needs of your organization.
Write **1511 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **2a** on your planning worksheet read **modern management**.
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
* Box **1a** on your planning worksheet reads **hybrid**, box **1b** reads **key trust**, and box **2a** reads **GP**.
<em>Optionally, you may write **1511 or later</em>* in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
Write **1703 or later** in box **3a** on your planning worksheet if any of the following are true.
* Box **1a** on your planning worksheet reads **on-premises**.
Write **N/A** in box **3b** on your planning worksheet.
* Box **1a** on your planning worksheet reads **hybrid**, box **1b** reads **certificate trust**, and box **2a** reads **GP**.
* Optionally, you may write **1511 or later** in box **3b** on your planning worksheet if you plan to manage nondomain joined devices.
### Active Directory
The Active Directory portion of the planning guide should be complete. Most of the conditions are baseline prerequisites except for your domain controllers. The domain controllers used in your deployment are decided by the chosen trust type.
Review the trust type portion of this section if box **4d** on your planning worksheet remains empty.
### Public Key Infrastructure
Public key infrastructure prerequisites already exist in your planning worksheet. These conditions are the minimum requirements for any hybrid or on-premises deployment. Additional conditions may be needed based on your trust type.
If box **1a** on your planning worksheet reads **cloud only**, ignore the public key infrastructure section of your planning worksheet. Cloud only deployments don't use a public key infrastructure.
If box **1b** on your planning worksheet reads **key trust**, write **N/A** in box **5b** on your planning worksheet. Key trust doesn't require any change in public key infrastructure, skip this part and go to **Cloud** section.
The registration authority only relates to certificate trust deployments and the management used for domain and nondomain joined devices. Microsoft Entra hybrid joined devices managed by Group Policy need the Windows Server 2016 AD FS role to issue certificates. Microsoft Entra hybrid joined devices and Microsoft Entra joined devices managed by Intune or a compatible MDM need the Windows Server NDES server role to issue certificates.
If box **2a** reads **GP** and box **2b** reads **modern management**, write **AD FS RA and NDES** in box **5b** on your planning worksheet. In box **5c**, write the following certificate templates names and issuances:
| Certificate Template Name | Issued To |
| --- | --- |
| Exchange Enrollment Agent | AD FS RA |
| Web Server | AD FS RA |
| Exchange Enrollment Agent | NDES |
| Web Server | NDES |
| CEP Encryption | NDES |
If box **2a** reads **GP** and box **2b** reads **N/A**, write **AD FS RA** in box **5b** and write the following certificate template names and issuances in box **5c** on your planning worksheet.
| Certificate Template Name | Issued To |
| --- | --- |
| Exchange Enrollment Agent | AD FS RA |
| Web Server | AD FS RA |
If box **2a** or **2b** reads modern management, write **NDES** in box **5b** and write the following certificate template names and issuances in box 5c on your planning worksheet.
| Certificate Template Name | Issued To |
| --- | --- |
| Exchange Enrollment Agent | NDES |
| Web Server | NDES |
| CEP Encryption | NDES |
### Cloud
Nearly all deployments of Windows Hello for Business require an Azure account.
If box **1a** on your planning worksheet reads **cloud only** or **hybrid**, write **Yes** in boxes **6a** and **6b** on your planning worksheet.
If box **1a** on your planning worksheet reads **on-premises**, and box **1f** reads **AD FS with third party**, write **No** in box **6a** on your planning worksheet. Otherwise, write **Yes** in box **6a** as you need an Azure account for per-consumption MFA billing. Write **No** in box **6b** on your planning worksheet—on-premises deployments don't use the cloud directory.
Windows Hello for Business doesn't require a Microsoft Entra ID P1 or P2 subscription. However, some dependencies, such as [MDM automatic enrollment](/mem/intune/enrollment/quickstart-setup-auto-enrollment) and [Conditional Access](/azure/active-directory/conditional-access/overview) do.
If box **1a** on your planning worksheet reads **on-premises**, write **No** in box **6c** on your planning worksheet.
If box **1a** on your planning worksheet reads **hybrid** and box **1b** reads **key trust**, write **No** in box **6c** on your planning worksheet. You can deploy Windows Hello for Business using the Microsoft Entra ID Free tier. All Microsoft Entra ID Free accounts can use Microsoft Entra multifactor authentication through the use of security defaults. Some Microsoft Entra multifactor authentication features require a license. For more details, see [Features and licenses for Microsoft Entra multifactor authentication](/azure/active-directory/authentication/concept-mfa-licensing).
If box **5b** on your planning worksheet reads **AD FS RA**, write **Yes** in box **6c** on your planning worksheet. Enrolling a certificate using the AD FS registration authority requires devices to authenticate to the AD FS server, which requires device write-back, a Microsoft Entra ID P1 or P2 feature.
Modern managed devices don't require a Microsoft Entra ID P1 or P2 subscription. By forgoing the subscription, your users must manually enroll devices in the modern management software, such as Intune or a supported third-party MDM.
If boxes **2a** or **2b** read **modern management** and you want devices to automatically enroll in your modern management software, write **Yes** in box **6c** on your planning worksheet. Otherwise, write **No** in box **6c**.
## Congratulations, You're Done
Your Windows Hello for Business planning worksheet should be complete. This guide provided understanding of the components used in the Windows Hello for Business infrastructure and rationalization of why they're used. The worksheet gives you an overview of the requirements needed to continue the next phase of the deployment. With this worksheet, you'll be able to identify key elements of your Windows Hello for Business deployment.

54
windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md
View File

@ -1,54 +0,0 @@
---
title: Prepare people to use Windows Hello
description: When you set a policy to require Windows Hello for Business in the workplace, you will want to prepare people in your organization.
ms.date: 08/19/2018
ms.topic: end-user-help
---
# Prepare people to use Windows Hello
When you set a policy to require Windows Hello for Business in the workplace, you will want to prepare people in your organization by explaining how to use Hello.
After enrollment in Hello, users should use their gesture (such as a PIN or fingerprint) for access to corporate resources. Their gesture is only valid on the enrolled device.
Although the organization may require users to change their Active Directory or Microsoft Entra account password at regular intervals, changes to their passwords have no effect on Hello.
People who are currently using virtual or physical smart cards for authentication can use their virtual smart card to verify their identity when they set up Hello.
[!INCLUDE [virtual-smart-card-deprecation-notice](../../includes/virtual-smart-card-deprecation-notice.md)]
## On devices owned by the organization
When someone sets up a new device, they are prompted to choose who owns the device. For corporate devices, they select **This device belongs to my organization**.
![who owns this pc.](images/corpown.png)
Next, they select a way to connect. Tell the people in your enterprise which option they should pick here.
![choose how you'll connect.](images/connect.png)
They sign in, and are then asked to verify their identity. People have options to choose from a text message, phone call, or the authentication application. After verification, they create their PIN. The **Create a PIN** screen displays any complexity requirements that you have set, such as minimum length.
After Hello is set up, people use their PIN to unlock the device, and that will automatically log them on.
## On personal devices
People who want to access work resources on their personal devices can add a work or school account in **Settings** &gt; **Accounts** &gt; **Work or school**, and then sign in with work credentials. The person selects the method for receiving the verification code, such as text message or email. The verification code is sent and the person then enters the verification code. After verification, the person enters and confirms new PIN. The person can access any token-based resource using this device without being asked for credentials.
People can go to **Settings** &gt; **Accounts** &gt; **Work or school**, select the work account, and then select **Unjoin** to remove the account from their device.
## Using Windows Hello and biometrics
If your policy allows it, people can use biometrics (fingerprint, iris, and facial recognition) with Windows Hello for Business, if the hardware supports it.
:::image type="content" alt-text="This screenshot shows account sign-in options to windows, apps, and services using fingerprint or face." source="images/hellosettings.png":::
## Related topics
- [Windows Hello for Business](deploy/requirements.md)
- [How Windows Hello for Business works](hello-how-it-works.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
- [Windows Hello and password changes](hello-and-password-changes.md)
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
- [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)

68
windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md
View File

@ -1,68 +0,0 @@
---
title: Why a PIN is better than an online password
description: Windows Hello enables users to sign in to their devices using a PIN. Learn how is a PIN different from (and better than) an online password.
ms.date: 03/15/2023
ms.topic: concept-article
---
# Why a PIN is better than an online password
Windows Hello enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a local password?
On the surface, a PIN looks much like a password. A PIN can be a set of numbers, but enterprise policy might enforce complex PINs that include special characters and letters, both upper-case and lower-case. Something like **t758A!** could be an account password or a complex Hello PIN. It isn't the structure of a PIN (length, complexity) that makes it better than an online password, it's how it works. First, we need to distinguish between two types of passwords: *local passwords* are validated against the machine's password store, whereas *online passwords* are validated against a server. This article mostly covers the benefits a PIN has over an online password, and also why it can be considered even better than a local password.
Watch Dana Huang explain why a Windows Hello for Business PIN is more secure than an online password.
> [!VIDEO https://www.youtube.com/embed/cC24rPBvdhA]
## A PIN is tied to the device
One important difference between an online password and a Hello PIN is that the PIN is tied to the specific device on which it was set up. That PIN is useless to anyone without that specific hardware. Someone who obtains your online password can sign in to your account from anywhere, but if they obtain your PIN, they'd have to access your device too.
The PIN can't be used anywhere except on that specific device. If you want to sign in on multiple devices, you have to set up Hello on each device.
## PIN is local to the device
An online password is transmitted to the server. The password can be intercepted in transmission or obtained from a server. A PIN is local to the device, never transmitted anywhere, and it isn't stored on the server.
When the PIN is created, it establishes a trusted relationship with the identity provider and creates an asymmetric key pair that is used for authentication. When you enter your PIN, you unlock the authentication key, which is used to sign the request that is sent to the authenticating server.
Even though local passwords are local to the device, they're less secure than a PIN, as described in the next section.
>[!NOTE]
>For details on how Hello uses asymmetric key pairs for authentication, see [Windows Hello for Business](index.md#benefits-of-windows-hello).
## PIN is backed by hardware
The Hello PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. Windows doesn't link local passwords to TPM, therefore PINs are considered more secure than local passwords.
User key material is generated and available within the TPM of the device. The TPM protects the key material from attackers who want to capture and reuse it. Since Hello uses asymmetric key pairs, users credentials can't be stolen in cases where the identity provider or websites the user accesses have been compromised.
The TPM protects against various known and potential attacks, including PIN brute-force attacks. After too many incorrect guesses, the device is locked.
## PIN can be complex
The Windows Hello for Business PIN is subject to the same set of IT management policies as a password, such as complexity, length, expiration, and history. Although we generally think of a PIN as a simple four-digit code, administrators can set [policies](hello-manage-in-organization.md) for managed devices to require a PIN complexity similar to a password. You can require or block: special characters, uppercase characters, lowercase characters, and digits.
## What if someone steals the device?
To compromise a Windows Hello credential that TPM protects, an attacker must have access to the physical device. Then, the attacker must find a way to spoof the user's biometrics or guess the PIN. All these actions must be done before [TPM anti-hammering](/windows/device-security/tpm/tpm-fundamentals#anti-hammering) protection locks the device.
You can provide more protection for laptops that don't have TPM by enabling BitLocker and setting a policy to limit failed sign-ins.
### Configure BitLocker without TPM
To enable BitLocker without TPM, follow these steps:
1. Open the Local Group Policy Editor (gpedit.msc) and enable the policy: **Computer Configuration > Administrative Templates > Windows Components > BitLocker Drive Encryption > Operating System Drives > Require additional authentication at startup**
1. In the policy option, select **Allow BitLocker without a compatible TPM > OK**
1. On the device, open **Control Panel > System and Security > BitLocker Drive Encryption**
1. Select the operating system drive to protect
### Set account lockout threshold
To configure account lockout threshold, follow these steps:
1. Open the Local Group Policy Editor (gpedit.msc) and enable the policy: **Computer Configuration > Windows Settings > Security Settings > Account Policies > Account Lockout Policy > Account lockout threshold**
1. Set the number of invalid logon attempts to allow, and then select OK
## Why do you need a PIN to use biometrics?
Windows Hello enables biometric sign-in for Windows: fingerprint, iris, or facial recognition. When you set up Windows Hello, you're asked to create a PIN after the biometric setup. The PIN enables you to sign in when you can't use your preferred biometric because of an injury or because the sensor is unavailable or not working properly.
If you only had a biometric sign-in configured and, for any reason, were unable to use that method to sign in, you would have to sign in using your account and password, which doesn't provide you with the same level of protection as Hello.

14
windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md → windows/security/identity-protection/hello-for-business/how-it-works-authentication.md
View File

@ -10,8 +10,6 @@ Windows Hello for Business authentication is a passwordless, two-factor authenti
Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in and can, optionally, authenticate to Active Directory. Microsoft Entra hybrid joined devices authenticate to Active Directory during sign-in, and authenticate to Microsoft Entra ID in the background.
<a name='azure-ad-join-authentication-to-azure-ad'></a>
## Microsoft Entra join authentication to Microsoft Entra ID
![Microsoft Entra join authentication to Microsoft Entra ID.](images/howitworks/auth-aadj-cloud.png)
@ -27,8 +25,6 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
|D | The Cloud AP provider receives the encrypted PRT with session key. Using the device's private transport key, the Cloud AP provider decrypt the session key and protects the session key using the device's TPM.|
|E | The Cloud AP provider returns a successful authentication response to lsass. Lsass caches the PRT, and informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
<a name='azure-ad-join-authentication-to-active-directory-using-cloud-kerberos-trust'></a>
## Microsoft Entra join authentication to Active Directory using cloud Kerberos trust
![Microsoft Entra join authentication to Active Directory.](images/howitworks/auth-aadj-cloudtrust-kerb.png)
@ -38,8 +34,6 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
|A | Authentication to Active Directory from a Microsoft Entra joined device begins with the user first attempts to use a resource that needs Kerberos authentication. The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller.
|B | After locating a domain controller, the Kerberos provider sends a partial TGT that it received from Microsoft Entra ID from a previous Microsoft Entra authentication to the domain controller. The partial TGT contains only the user SID, and it's signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client.|
<a name='azure-ad-join-authentication-to-active-directory-using-a-key'></a>
## Microsoft Entra join authentication to Active Directory using a key
![Microsoft Entra join authentication to Active Directory using a Key.](images/howitworks/auth-aadj-keytrust-kerb.png)
@ -53,8 +47,6 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
> [!NOTE]
> You might have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on the Microsoft Entra joined device, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT and trigger authenticate against your DC (if LOS to DC is available) to get Kerberos. It no longer uses AD FS to authenticate for Windows Hello for Business sign-ins.
<a name='azure-ad-join-authentication-to-active-directory-using-a-certificate'></a>
## Microsoft Entra join authentication to Active Directory using a certificate
![Microsoft Entra join authentication to Active Directory using a Certificate.](images/howitworks/auth-aadj-certtrust-kerb.png)
@ -68,8 +60,6 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
> [!NOTE]
> You may have an on-premises domain federated with Microsoft Entra ID. Once you have successfully provisioned Windows Hello for Business PIN/Bio on, any future login of Windows Hello for Business (PIN/Bio) sign-in will directly authenticate against Microsoft Entra ID to get PRT, as well as authenticate against your DC (if LOS to DC is available) to get Kerberos as mentioned previously. AD FS federation is used only when Enterprise PRT calls are placed from the client. You need to have device write-back enabled to get "Enterprise PRT" from your federation.
<a name='hybrid-azure-ad-join-authentication-using-cloud-kerberos-trust'></a>
## Microsoft Entra hybrid join authentication using cloud Kerberos trust
![Microsoft Entra hybrid join authentication using Microsoft Entra Kerberos](images/howitworks/auth-haadj-cloudtrust.png)
@ -82,8 +72,6 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
|D | Cloud AP receives the encrypted PRT with session key. Using the device's private transport key, Cloud AP decrypts the session key and protects the session key using the device's TPM (if available). Cloud AP returns a successful authentication response to lsass. Lsass caches the PRT and the Partial TGT.
|E | The Kerberos security support provider, hosted in lsass, uses metadata from the Windows Hello for Business key to get a hint of the user's domain. Using the hint, the provider uses the DClocator service to locate a 2016 domain controller. After locating an active 2016 domain controller, the Kerberos provider sends the partial TGT that it received from Microsoft Entra ID to the domain controller. The partial TGT contains only the user SID and is signed by Microsoft Entra Kerberos. The domain controller verifies that the partial TGT is valid. On success, the KDC returns a TGT to the client. Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests. Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.|
<a name='hybrid-azure-ad-join-authentication-using-a-key'></a>
## Microsoft Entra hybrid join authentication using a key
![Microsoft Entra hybrid join authentication using a key.](images/howitworks/auth-haadj-keytrust.png)
@ -101,8 +89,6 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in
> [!IMPORTANT]
> In the above deployment model, a newly provisioned user will not be able to sign in using Windows Hello for Business until (a) Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory and (b) device has line of sight to the domain controller for the first time.
<a name='hybrid-azure-ad-join-authentication-using-a-certificate'></a>
## Microsoft Entra hybrid join authentication using a certificate
![Microsoft Entra hybrid join authentication using a Certificate.](images/howitworks/auth-haadj-certtrust.png)

0
windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md → windows/security/identity-protection/hello-for-business/how-it-works-provisioning.md
View File

84
windows/security/identity-protection/hello-for-business/how-it-works.md Normal file
View File

@ -0,0 +1,84 @@
---
title: How Windows Hello for Business works
description: Learn how Windows Hello for Business works, and how it can help your users authenticate to services.
ms.date: 05/05/2018
ms.topic: overview
---
# How Windows Hello for Business works in Windows Devices
Windows Hello for Business is a two-factor credential that is a more secure alternative to passwords. Whether you are cloud or on-premises, Windows Hello for Business has a deployment option for you. For cloud deployments, you can use Windows Hello for Business with Microsoft Entra joined, Microsoft Entra hybrid joined, or Microsoft Entra registered devices. Windows Hello for Business also works for domain joined devices.
## Technical Deep Dive
Windows Hello for Business is a distributed system that uses several components to accomplish device registration, provisioning, and authentication. Use this section to gain a better understanding of each of the categories and how they support Windows Hello for Business.
### Device Registration
Registration is a fundamental prerequisite for Windows Hello for Business. Without registration, Windows Hello for Business provisioning cannot start. Registration is where the device **registers** its identity with the identity provider. For cloud and hybrid deployments, the identity provider is Microsoft Entra ID and the device registers with the Azure Device Registration Service (ADRS). For on-premises deployments, the identity provider is Active Directory Federation Services (AD FS), and the device registers with the enterprise device registration service hosted on the federation servers (AD FS).
For more information, read [how device registration works](/azure/active-directory/devices/device-registration-how-it-works).
### Provisioning
Provisioning is when the user uses one form of authentication to request a new Windows Hello for Business credential. Typically the user signs in to Windows using user name and password. The provisioning flow requires a second factor of authentication before it will create a strong, two-factor Windows Hello for Business credential.
For more information, read [how provisioning works](how-it-works-provisioning.md).
### Authentication
With the device registered and provisioning complete, users can sign-in to Windows using biometrics or a PIN. PIN is the most common gesture and is available on all computers unless restricted by policy requiring a TPM. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. Neither the PIN nor the private portion of the credential are ever sent to the identity provider, and the PIN is not stored on the device. It is user provided entropy when performing operations that use the private portion of the credential.
For more information read [how authentication works](how-it-works-authentication.md).
## Windows Hello biometrics in the enterprise
Windows Hello is the biometric authentication feature that helps strengthen authentication and helps to guard against potential spoofing through fingerprint matching and facial recognition.
## How does Windows Hello work?
Windows Hello lets your employees use fingerprint, facial recognition, or iris recognition as an alternative method to unlocking a device. With Windows Hello, authentication happens when the employee provides his or her unique biometric identifier while accessing the device-specific Windows Hello credentials.
The Windows Hello authenticator works to authenticate and allow employees onto your enterprise network. Authentication doesn't roam among devices, isn't shared with a server, and can't easily be extracted from a device. If multiple employees share a device, each employee will use his or her own biometric data on the device.
## Why should I let my employees use Windows Hello?
Windows Hello provides many benefits, including:
- It helps to strengthen your protections against credential theft. Because an attacker must have both the device and the biometric info or PIN, it's much more difficult to gain access without the employee's knowledge.
- Employees get a simple authentication method (backed up with a PIN) that's always with them, so there's nothing to lose. No more forgetting passwords!
- Support for Windows Hello is built into the operating system so you can add additional biometric devices and policies as part of a coordinated rollout or to individual employees or groups using Group Policy or Mobile Device Management (MDM) configurations service provider (CSP) policies.<br>For more info about the available Group Policies and MDM CSPs, see the [Implement Windows Hello for Business in your organization](hello-manage-in-organization.md) topic.
## Where is Windows Hello data stored?
The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was actually able to get the biometric data from a device, it cannot be converted back into a raw biometric sample that could be recognized by the biometric sensor.
> [!NOTE]
>Each sensor on a device will have its own biometric database file where template data is stored. Each database has a unique, randomly generated key that is encrypted to the system. The template data for the sensor will be encrypted with this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors will store biometric data on the fingerprint module instead of in the database file.
## Windows Hello for Business and password changes
Changes to a user account password doesn't affect sign-in or unlock, since Windows Hello for Business uses a key or certificate.
## How Windows Hello for Business works: key points
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Microsoft Entra ID, or a Microsoft account.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture doesn't roam between devices and isn't shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process.
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
- Personal (Microsoft account) and corporate (Active Directory or Microsoft Entra ID) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
For details, see [How Windows Hello for Business works](hello-how-it-works.md).

3
windows/security/identity-protection/hello-for-business/images/fingerprint.svg Normal file
View File

File diff suppressed because one or more lines are too long
Side by Side

After

Width:  |  Height:  |  Size: 6.7 KiB

3
windows/security/identity-protection/hello-for-business/images/hello.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="14" height="12" viewBox="0 0 14 12" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M6.95117 11.3809C6.29362 11.3809 5.64258 11.2962 4.99805 11.127C4.36003 10.9577 3.7513 10.7168 3.17188 10.4043C2.59896 10.0853 2.06836 9.70117 1.58008 9.25195C1.0918 8.80273 0.678385 8.29492 0.339844 7.72852C0.229167 7.55924 0.173828 7.37695 0.173828 7.18164C0.173828 7.04492 0.19987 6.91471 0.251953 6.79102C0.304036 6.66732 0.375651 6.5599 0.466797 6.46875C0.564453 6.3776 0.671875 6.30599 0.789062 6.25391C0.91276 6.20182 1.04297 6.17578 1.17969 6.17578C1.36198 6.17578 1.52474 6.2181 1.66797 6.30273C1.8112 6.38737 1.9349 6.50456 2.03906 6.6543C2.65104 7.53971 3.36719 8.21354 4.1875 8.67578C5.01432 9.13802 5.97786 9.36914 7.07812 9.36914C8.11979 9.36914 9.05078 9.12826 9.87109 8.64648C10.6979 8.1582 11.401 7.49414 11.9805 6.6543C12.0781 6.51107 12.1921 6.39714 12.3223 6.3125C12.459 6.22135 12.6185 6.17578 12.8008 6.17578C13.0938 6.17578 13.3411 6.26693 13.543 6.44922C13.7448 6.63151 13.8457 6.87565 13.8457 7.18164C13.8457 7.2793 13.8327 7.37044 13.8066 7.45508C13.7806 7.5332 13.7415 7.61458 13.6895 7.69922C13.5332 7.98568 13.3444 8.2526 13.123 8.5C12.9082 8.7474 12.6836 8.98503 12.4492 9.21289C11.7005 9.92253 10.8542 10.4629 9.91016 10.834C8.96615 11.1986 7.97982 11.3809 6.95117 11.3809ZM4.95898 1.6543C4.95898 1.86914 4.91667 2.07422 4.83203 2.26953C4.7474 2.46484 4.63346 2.63737 4.49023 2.78711C4.34701 2.93034 4.17773 3.04427 3.98242 3.12891C3.79362 3.21354 3.58854 3.25586 3.36719 3.25586C3.14583 3.25586 2.9375 3.21354 2.74219 3.12891C2.55339 3.04427 2.38737 2.93034 2.24414 2.78711C2.10091 2.64388 1.98698 2.47786 1.90234 2.28906C1.81771 2.09375 1.77539 1.88542 1.77539 1.66406C1.77539 1.44271 1.81445 1.23438 1.89258 1.03906C1.97721 0.84375 2.09115 0.674479 2.23438 0.53125C2.3776 0.38151 2.54362 0.264323 2.73242 0.179688C2.92773 0.0950521 3.13607 0.0527344 3.35742 0.0527344C3.57878 0.0527344 3.78385 0.0950521 3.97266 0.179688C4.16797 0.264323 4.33724 0.38151 4.48047 0.53125C4.63021 0.674479 4.7474 0.84375 4.83203 1.03906C4.91667 1.22786 4.95898 1.43294 4.95898 1.6543ZM9.06055 1.6543C9.06055 1.43294 9.10286 1.22461 9.1875 1.0293C9.27214 0.833984 9.38607 0.664714 9.5293 0.521484C9.67253 0.378255 9.8418 0.264323 10.0371 0.179688C10.2324 0.0950521 10.4408 0.0527344 10.6621 0.0527344C10.8835 0.0527344 11.0885 0.0950521 11.2773 0.179688C11.4727 0.264323 11.6419 0.38151 11.7852 0.53125C11.9284 0.674479 12.0391 0.84375 12.1172 1.03906C12.2018 1.22786 12.2441 1.43294 12.2441 1.6543C12.2441 1.87565 12.2018 2.08398 12.1172 2.2793C12.0326 2.4681 11.9186 2.63737 11.7754 2.78711C11.6322 2.93034 11.4629 3.04427 11.2676 3.12891C11.0788 3.21354 10.8737 3.25586 10.6523 3.25586C10.431 3.25586 10.2227 3.21354 10.0273 3.12891C9.83854 3.04427 9.67253 2.93034 9.5293 2.78711C9.38607 2.63737 9.27214 2.4681 9.1875 2.2793C9.10286 2.08398 9.06055 1.87565 9.06055 1.6543Z" fill="#0883D9"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.9 KiB

BIN
windows/security/identity-protection/hello-for-business/images/hellosettings.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 56 KiB

3
windows/security/identity-protection/hello-for-business/images/iris.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="20" height="15" viewBox="0 0 20 15" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M10.0117 0.816406C10.9023 0.816406 11.793 0.941406 12.6836 1.19141C13.5742 1.43359 14.4141 1.78516 15.2031 2.24609C15.9922 2.70703 16.707 3.26562 17.3477 3.92188C17.9961 4.57031 18.5273 5.29687 18.9414 6.10156C18.9883 6.20312 19.0273 6.30469 19.0586 6.40625C19.0898 6.50781 19.1055 6.61328 19.1055 6.72266C19.1055 6.91797 19.0703 7.09766 19 7.26172C18.9297 7.41797 18.832 7.55469 18.707 7.67188C18.582 7.78125 18.4375 7.86719 18.2734 7.92969C18.1094 7.99219 17.9336 8.02344 17.7461 8.02344C17.5039 8.02344 17.2969 7.96094 17.125 7.83594C16.9531 7.70312 16.8047 7.54297 16.6797 7.35547C16.5781 7.19922 16.4805 7.04297 16.3867 6.88672C16.293 6.73047 16.1914 6.57812 16.082 6.42969C15.7305 5.95312 15.3242 5.52734 14.8633 5.15234C14.4102 4.77734 13.9219 4.46094 13.3984 4.20312C12.8828 3.9375 12.3359 3.73828 11.7578 3.60547C11.1875 3.46484 10.6055 3.39453 10.0117 3.39453C9.36328 3.39453 8.73047 3.47656 8.11328 3.64062C7.49609 3.79687 6.91016 4.02734 6.35547 4.33203C5.80859 4.63672 5.30078 5.00781 4.83203 5.44531C4.36328 5.875 3.95312 6.36328 3.60156 6.91016C3.54688 6.99609 3.5 7.07812 3.46094 7.15625C3.42188 7.22656 3.375 7.30469 3.32031 7.39062C3.20312 7.58594 3.04688 7.74219 2.85156 7.85938C2.65625 7.96875 2.44531 8.02344 2.21875 8.02344C2.03906 8.02344 1.87109 7.98828 1.71484 7.91797C1.55859 7.84766 1.42188 7.75391 1.30469 7.63672C1.1875 7.51953 1.09375 7.38281 1.02344 7.22656C0.953125 7.07031 0.917969 6.90234 0.917969 6.72266C0.917969 6.51172 0.972656 6.30469 1.08203 6.10156C1.53516 5.28125 2.07812 4.54687 2.71094 3.89844C3.35156 3.24219 4.05469 2.6875 4.82031 2.23438C5.59375 1.77344 6.41797 1.42188 7.29297 1.17969C8.16797 0.9375 9.07422 0.816406 10.0117 0.816406ZM10.0117 7.27344C10.5273 7.27344 11.0117 7.37109 11.4648 7.56641C11.918 7.76172 12.3125 8.03125 12.6484 8.375C12.9844 8.71094 13.25 9.10547 13.4453 9.55859C13.6406 10.0117 13.7383 10.4961 13.7383 11.0117C13.7383 11.5352 13.6367 12.0234 13.4336 12.4766C13.2383 12.9297 12.9688 13.3242 12.625 13.6602C12.2891 13.9961 11.8945 14.2617 11.4414 14.457C10.9883 14.6523 10.5039 14.75 9.98828 14.75C9.46484 14.75 8.97656 14.6523 8.52344 14.457C8.07812 14.2617 7.6875 13.9961 7.35156 13.6602C7.02344 13.3164 6.76172 12.918 6.56641 12.4648C6.37891 12.0039 6.28516 11.5156 6.28516 11C6.28516 10.4844 6.38281 10.0039 6.57812 9.55859C6.77344 9.10547 7.03906 8.71094 7.375 8.375C7.71875 8.03125 8.11328 7.76172 8.55859 7.56641C9.01172 7.37109 9.49609 7.27344 10.0117 7.27344Z" fill="#0883D9"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.5 KiB

BIN
windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gp-setting.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 39 KiB

BIN
windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gpme.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 112 KiB

3
windows/security/identity-protection/hello-for-business/images/pin.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="10" height="14" viewBox="0 0 10 14" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M2 2H0V0H2V2ZM6 2H4V0H6V2ZM10 2H8V0H10V2ZM2 6H0V4H2V6ZM6 6H4V4H6V6ZM10 6H8V4H10V6ZM2 10H0V8H2V10ZM6 10H4V8H6V10ZM6 14H4V12H6V14ZM10 10H8V8H10V10Z" fill="#0883D9"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 276 B

3
windows/security/identity-protection/hello-for-business/images/smartcard.svg Normal file
View File

@ -0,0 +1,3 @@
<svg width="20" height="20" viewBox="0 0 20 20" fill="none" xmlns="http://www.w3.org/2000/svg">
<path d="M16.3281 2.5C16.8164 2.5 17.2819 2.59766 17.7246 2.79297C18.1673 2.98828 18.5579 3.25521 18.8965 3.59375C19.235 3.93229 19.502 4.32292 19.6973 4.76562C19.8926 5.20833 19.9935 5.67708 20 6.17188V13.8281C20 14.3164 19.9023 14.7819 19.707 15.2246C19.5117 15.6673 19.2448 16.0579 18.9062 16.3965C18.5677 16.735 18.1771 17.002 17.7344 17.1973C17.2917 17.3926 16.8229 17.4935 16.3281 17.5H3.67188C3.18359 17.5 2.7181 17.4023 2.27539 17.207C1.83268 17.0117 1.44206 16.7448 1.10352 16.4062C0.764974 16.0677 0.498047 15.6771 0.302734 15.2344C0.107422 14.7917 0.00651042 14.3229 0 13.8281V6.17188C0 5.68359 0.0976562 5.2181 0.292969 4.77539C0.488281 4.33268 0.755208 3.94206 1.09375 3.60352C1.43229 3.26497 1.82292 2.99805 2.26562 2.80273C2.70833 2.60742 3.17708 2.50651 3.67188 2.5H16.3281ZM18.75 6.20117C18.75 5.87565 18.6849 5.56641 18.5547 5.27344C18.4245 4.98047 18.2454 4.72005 18.0176 4.49219C17.7897 4.26432 17.5293 4.08529 17.2363 3.95508C16.9434 3.82487 16.6309 3.75651 16.2988 3.75H3.70117C3.37565 3.75 3.06641 3.8151 2.77344 3.94531C2.48047 4.07552 2.22005 4.25456 1.99219 4.48242C1.76432 4.71029 1.58529 4.9707 1.45508 5.26367C1.32487 5.55664 1.25651 5.86914 1.25 6.20117V13.7988C1.25 14.1243 1.3151 14.4336 1.44531 14.7266C1.57552 15.0195 1.75456 15.2799 1.98242 15.5078C2.21029 15.7357 2.4707 15.9147 2.76367 16.0449C3.05664 16.1751 3.36914 16.2435 3.70117 16.25H16.2988C16.6243 16.25 16.9336 16.1849 17.2266 16.0547C17.5195 15.9245 17.7799 15.7454 18.0078 15.5176C18.2357 15.2897 18.4147 15.0293 18.5449 14.7363C18.6751 14.4434 18.7435 14.1309 18.75 13.7988V6.20117ZM14.375 6.25C14.6289 6.25 14.8698 6.29883 15.0977 6.39648C15.3255 6.49414 15.5241 6.6276 15.6934 6.79688C15.8626 6.96615 15.9993 7.16797 16.1035 7.40234C16.2077 7.63672 16.2565 7.8776 16.25 8.125V11.875C16.25 12.1289 16.2012 12.3698 16.1035 12.5977C16.0059 12.8255 15.8724 13.0241 15.7031 13.1934C15.5339 13.3626 15.332 13.4993 15.0977 13.6035C14.8633 13.7077 14.6224 13.7565 14.375 13.75H10.625C10.3711 13.75 10.1302 13.7012 9.90234 13.6035C9.67448 13.5059 9.47591 13.3724 9.30664 13.2031C9.13737 13.0339 9.00065 12.832 8.89648 12.5977C8.79232 12.3633 8.74349 12.1224 8.75 11.875V8.125C8.75 7.87109 8.79883 7.63021 8.89648 7.40234C8.99414 7.17448 9.1276 6.97591 9.29688 6.80664C9.46615 6.63737 9.66797 6.50065 9.90234 6.39648C10.1367 6.29232 10.3776 6.24349 10.625 6.25H14.375ZM10.625 7.5C10.4557 7.5 10.3092 7.56185 10.1855 7.68555C10.0618 7.80924 10 7.95573 10 8.125V8.75H15V8.125C15 7.95573 14.9382 7.80924 14.8145 7.68555C14.6908 7.56185 14.5443 7.5 14.375 7.5H10.625ZM10 11.875C10 12.0443 10.0618 12.1908 10.1855 12.3145C10.3092 12.4382 10.4557 12.5 10.625 12.5H11.25V10H10V11.875ZM14.375 12.5C14.5443 12.5 14.6908 12.4382 14.8145 12.3145C14.9382 12.1908 15 12.0443 15 11.875V10H12.5V12.5H14.375Z" fill="#0883D9"/>
</svg>
Side by Side

After

Width:  |  Height:  |  Size: 2.8 KiB

17
windows/security/identity-protection/hello-for-business/includes/allow-enumeration-of-emulated-smart-card-for-all-users.md Normal file
View File

@ -0,0 +1,17 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Allow enumeration of emulated smart card for all users
Windows prevents users on the same device from enumerating provisioned Windows Hello for Business credentials for other users. If you enable this policy setting, Windows allows all users of the device to enumerate all Windows Hello for Business credentials, but still require each user to provide their own factors for authentication. If you disable or don't configure this policy setting, Windows doesn't allow the enumeration of provisioned Windows Hello for Business credentials for other users on the same device.
This policy setting is designed for a single user who enrolls *privileged* and *nonprivileged* accounts on a single device. The user owns both credentials, which enable them to sign-in using nonprivileged credentials, but can perform elevated tasks without signing-out. This policy setting is incompatible with Windows Hello for Business credentials provisioned when the *Turn off smart card emulation* policy setting is enabled.
| | Path |
|--|--|
| **CSP** | Not available |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

19
windows/security/identity-protection/hello-for-business/includes/configure-device-unlock-factors.md Normal file
View File

@ -0,0 +1,19 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Configure device unlock factors
Configure a comma separated list of credential provider GUIDs, such as face and fingerprint provider GUIDs, to be used as the first and second unlock factors. If the trusted signal provider is specified as one of the unlock factors, you should also configure a comma separated list of signal rules in the form of xml for each signal type to be verified.
If you enable this policy setting, the user must use one factor from each list to successfully unlock. If you disable or don't configure this policy setting, users can continue to unlock with existing options.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/`[DeviceUnlock](/windows/client-management/mdm/passportforwork-csp#devicedeviceunlock) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |
For more information about multi-factor unlock, see [Multi-factor unlock with Windows Hello for Business](/windows/security/identity-protection/hello-for-business/multi-factor-unlock).

18
windows/security/identity-protection/hello-for-business/includes/configure-dynamic-lock-factors.md Normal file
View File

@ -0,0 +1,18 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Configure dynamic lock factors
Configure a comma separated list of signal rules in the form of xml for each signal type.
- If you enable this policy setting, the signal rules are evaluated to detect user absence and automatically lock the device
- If you disable or don't configure the setting, users can continue to lock with existing options
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/DynamicLock/`[DynamicLock](/windows/client-management/mdm/passportforwork-csp#devicedynamiclock) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

20
windows/security/identity-protection/hello-for-business/includes/configure-enhanced-anti-spoofing.md Normal file
View File

@ -0,0 +1,20 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Configure enhanced anti-spoofing
This policy setting determines whether enhanced anti-spoofing is required for Windows Hello face authentication.
- If you enable this setting, Windows requires to use enhanced anti-spoofing for face authentication
> [!IMPORTANT]
> This disables face authentication on devices that don't support enhanced anti-spoofing.
- If you disable or don't configure this setting, Windows doesn't require enhanced anti-spoofing for face authentication
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/Biometrics/`[FacialFeaturesUseEnhancedAntiSpoofing](/windows/client-management/mdm/passportforwork-csp#devicebiometricsfacialfeaturesuseenhancedantispoofing) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

25
windows/security/identity-protection/hello-for-business/includes/enable-ess-with-supported-peripherals.md Normal file
View File

@ -0,0 +1,25 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Enable ESS with supported peripherals
Enhanced Sign-in Security (ESS) adds a layer of security to biometric data by using specialized hardware and software components, for example Virtualization Based Security (VBS) and Trusted Platform Module 2.0.
With ESS, Windows Hello biometric (face and fingerprint) template data and matching operations are isolated to trusted hardware or specified memory regions, and the rest of the operating system can't access or tamper with them. Since the channel of communication between the sensors and the algorithm is also secured, it's impossible for malware to inject or replay data in order to simulate a user signing in or to lock a user out of their machine.
If you enable this policy, you can configure the following values:
- `0`: ESS is enabled with peripheral or built-in non-ESS sensors. Authentication operations of peripheral Windows Hello capable devices are allowed, subject to current feature limitations. ESS is enabled on devices with a mixture of biometric devices, such as an ESS-capable fingerprint reader and a non-ESS capable camera. Therefore, this setting is not recommended
- `1`: ESS is enabled without peripheral or built-in non-ESS sensors. Authentication operations of any peripheral biometric device are blocked and not available for Windows Hello. This setting is recommended for highest security
If you disable or not configure this setting, then non-ESS sensors are blocked on the ESS device.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/Biometrics/`[EnableESSwithSupportedPeripherals](/windows/client-management/mdm/passportforwork-csp#devicebiometricsenableesswithsupportedperipherals) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |
For more information, see [How does Enhanced Sign-in Security protect biometric data](windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security#how-does-enhanced-sign-in-security-protect-biometric-data).

17
windows/security/identity-protection/hello-for-business/includes/expiration.md Normal file
View File

@ -0,0 +1,17 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Expiration
This setting specifies the period of time (in days) that a PIN can be used before the system requires the user to change it. The PIN can be set to expire after any number of days between 1 and 730, or PINs can be set to never expire if the policy is set to 0.
The default value is 0.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexityexpiration](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexityexpiration)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityexpiration](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityexpiration) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity**|

20
windows/security/identity-protection/hello-for-business/includes/history.md Normal file
View File

@ -0,0 +1,20 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### History
This setting specifies the number of past PINs that can be associated to a user account that can't be reused. This policy enhances security by ensuring that old PINs are not reused continually. The value must be between 0 to 50 PINs. If this policy is set to 0, then storage of previous PINs is not required.
The default value is 0.
> [!NOTE]
> PIN history is not preserved through PIN reset.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexityhistory](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexityhistory)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityhistory](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityhistory) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

20
windows/security/identity-protection/hello-for-business/includes/maximum-pin-length.md Normal file
View File

@ -0,0 +1,20 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Maximum PIN length
Maximum PIN length configures the maximum number of characters allowed for the PIN. The largest number you can configure for this policy setting is 127. The lowest number you can configure must be larger than the number configured in the Minimum PIN length policy setting or the number 4, whichever is greater. If you configure this policy setting, the PIN length must be less than or equal to this number.
If you disable or don't configure this policy setting, the PIN length must be less than or equal to 127.
> [!NOTE]
> If the above specified conditions for the maximum PIN length aren't met, default values are used for both the maximum and minimum PIN lengths.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexitymaximumpinlength](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexitymaximumpinlength)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexitymaximumpinlength](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexitymaximumpinlength) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

21
windows/security/identity-protection/hello-for-business/includes/minimum-pin-length.md Normal file
View File

@ -0,0 +1,21 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Minimum PIN length
Minimum PIN length configures the minimum number of characters required for the PIN. The lowest number you can configure for this policy setting is 4. The largest number you can configure must be less than the number configured in the Maximum PIN length policy setting or the number 127, whichever is the lowest.
If you configure this policy setting, the PIN length must be greater than or equal to this number.
If you disable or don't configure this policy setting, the PIN length must be greater than or equal to 6.
> [!NOTE]
> If the above specified conditions for the minimum PIN length are not met, default values will be used for both the maximum and minimum PIN lengths.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexityminimumpinlength](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexityminimumpinlength)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityminimumpinlength](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityminimumpinlength)|
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

19
windows/security/identity-protection/hello-for-business/includes/require-digits.md Normal file
View File

@ -0,0 +1,19 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Require digits
Use this policy setting to configure the use of digits in the PIN:
- If you enable this policy setting, Windows requires the user to include at least one digit in their PIN
- If you disable this policy setting, Windows doesn't allow the user to include digits in their PINs
- If you don't configure this policy setting, Windows allows, but doesn't require, digits in the PIN
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexitydigits](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexitydigits)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexitydigits](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexitydigits) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

19
windows/security/identity-protection/hello-for-business/includes/require-lowercase-letters.md Normal file
View File

@ -0,0 +1,19 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Require lowercase letters
Use this policy setting to configure the use of lowercase letters in the PIN:
- If you enable this policy setting, Windows requires the user to include at least one lowercase letter in their PIN
- If you disable this policy setting, Windows doesn't allow the user to include lowercase letters in their PIN
- If you don't configure this policy setting, Windows allows, but doesn't require, lowercase letters in the PIN
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexitylowercaseletters](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexitylowercaseletters)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexitylowercaseletters](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexitylowercaseletters) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

25
windows/security/identity-protection/hello-for-business/includes/require-special-characters.md Normal file
View File

@ -0,0 +1,25 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Require special characters
Scope: Machine
Use this policy setting to configure the use of special characters in the PIN. Special characters include the following set:
``` text
! " # $ % & ' ( ) * + , - . / : ; < = > ? @ [ \ ] ^ _ ` { | } ~
```
- If you enable this policy setting, Windows requires the user to include at least one special character in their PIN
- If you disable this policy setting, Windows doesn't allow the user to include special characters in their PIN
- If you don't configure this policy setting, Windows allows, but doesn't require, special characters in the PIN
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexityspecialcharacters](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexityspecialcharacters)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityspecialcharacters](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityspecialcharacters) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

19
windows/security/identity-protection/hello-for-business/includes/require-uppercase-letters.md Normal file
View File

@ -0,0 +1,19 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Require uppercase letters
Use this policy setting to configure the use of uppercase letters in the PIN:
- If you enable this policy setting, Windows requires the user to include at least one uppercase letter in their PIN
- If you disable this policy setting, Windows doesn't allow the user to include uppercase letters in their PIN
- If you don't configure this policy setting, Windows allows, but doesn't require, uppercase letters in the PIN
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[devicetenantidpoliciespincomplexityuppercaseletters](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciespincomplexityuppercaseletters)<br><br>`./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityuppercaseletters](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityuppercaseletters) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** |

21
windows/security/identity-protection/hello-for-business/includes/turn-off-smart-card-emulation.md Normal file
View File

@ -0,0 +1,21 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Turn off smart card emulation
Windows Hello for Business automatically provides smart card emulation for compatibility with smart card enabled applications.
- If you enable this policy setting, Windows Hello for Business provisions Windows Hello for Business credentials that are not compatible with smart card applications
- If you disable or don't configure this policy setting, Windows Hello for Business provisions Windows Hello for Business credentials compatible with smart card applications
> [!IMPORTANT]
> This policy affects Windows Hello for Business credentials at the time of creation. Credentials created before the application of this policy continue to provide smart card emulation. To change an existing credential, enable this policy setting and select *I forgot my PIN* from Settings.
| | Path |
|--|--|
| **CSP** | Not available |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

20
windows/security/identity-protection/hello-for-business/includes/use-a-hardware-security-device.md Normal file
View File

@ -0,0 +1,20 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use a hardware security device
A Trusted Platform Module (TPM) provides additional security benefits over software because data protected by it can't be used on other devices.
- If you enable this policy setting, Windows Hello for Business provisioning only occurs on devices with usable 1.2 or 2.0 TPMs. You can optionally exclude TPM revision 1.2 modules, which prevents Windows Hello for Business provisioning on those devices
> [!TIP]
> The TPM 1.2 specification only allows the use of RSA and the SHA-1 hashing algorithm. TPM 1.2 implementations vary in policy settings, which may result in support issues as lockout policies vary. It's recommended to exclude TPM 1.2 devices from Windows Hello for Business provisioning.
-If you disable or don't configure this policy setting, the TPM is still preferred, but all devices can provision Windows Hello for Business using software if the TPM is nonfunctional or unavailable.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[RequireSecurityDevice](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesrequiresecuritydevice)<br><br>`./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/ExcludeSecurityDevices/`[TPM12](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesexcludesecuritydevicestpm12) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

21
windows/security/identity-protection/hello-for-business/includes/use-biometrics.md Normal file
View File

@ -0,0 +1,21 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use biometrics
Windows Hello for Business enables users to use biometric gestures, such as face and fingerprints, as an alternative to the PIN gesture. However users must still configure a PIN to use in case of failures.
- If you enable or don't configure this policy setting, Windows Hello for Business allows the use biometric gestures
- If you disable this policy setting, Windows Hello for Business prevents the use of biometric gestures
> [!NOTE]
> Disabling this policy prevents the user of biometric gestures on the device for all account types.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/Biometrics/`[UseBiometrics](/windows/client-management/mdm/passportforwork-csp#devicebiometricsusebiometrics) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

18
windows/security/identity-protection/hello-for-business/includes/use-certificate-for-on-premises-authentication.md Normal file
View File

@ -0,0 +1,18 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use certificate for on-premises authentication
Use this policy setting to configure Windows Hello for Business to enroll a sign-in certificate used for on-premises authentication.
- If you enable this policy setting, Windows Hello for Business enrolls a sign-in certificate that is used for on-premises authentication
- If you disable or don't configure this policy setting, Windows Hello for Business will use a key or a Kerberos ticket (depending on other policy settings) for on-premises authentication
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[UseCertificateForOnPremAuth](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesusecertificateforonpremauth)|
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** <br><br> **User Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**|

21
windows/security/identity-protection/hello-for-business/includes/use-cloud-trust-for-on-premises-authentication.md Normal file
View File

@ -0,0 +1,21 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use cloud trust for on-premises authentication
Use this policy setting to configure Windows Hello for Business to use the cloud Kerberos trust model.
- If you enable this policy setting, Windows Hello for Business uses a Kerberos ticket retrieved from authenticating to Microsoft Entra ID for on-premises authentication
- If you disable or don't configure this policy setting, Windows Hello for Business uses a key or certificate (depending on other policy settings) for on-premises authentication
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[UseCloudTrustForOnPremAuth](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesusecloudtrustforonpremauth) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |
> [!NOTE]
> Cloud Kerberos trust is incompatible with certificate trust. If the certificate trust policy setting is enabled, it takes precedence over this policy setting.

24
windows/security/identity-protection/hello-for-business/includes/use-pin-recovery.md Normal file
View File

@ -0,0 +1,24 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use PIN recovery
PIN Recovery enables a user to change a forgotten PIN using the Windows Hello for Business PIN recovery service, without losing any associated credentials or certificates, including any keys associated with the user's personal accounts on the device.
To achieve this, the PIN recovery service encrypts a recovery secret, which is stored on the device, and requires both the PIN recovery service and the device to decrypt.
PIN recovery requires the user to perform multi-factor authentication to Microsoft Entra ID.
- If you enable this policy setting, Windows Hello for Business uses the PIN recovery service
- If you disable or don't configure this policy setting, Windows doesn't create or store the PIN recovery secret. If the user forgets their PIN, they must delete their existing PIN and create a new one, and they must re-register with any services to which the old PIN provided access
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[EnablePinRecovery](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesenablepinrecovery) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |
For more information, see [PIN reset](../pin-reset.md).

20
windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business-certificates-as-smart-card-certificates.md Normal file
View File

@ -0,0 +1,20 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use Windows Hello for Business certificates as smart card certificates
This policy setting is designed to allow compatibility with applications that rely exclusively on smart card certificates.
- If you enable this policy setting, applications use Windows Hello for Business certificates as smart card certificates. Biometric factors are unavailable when a user is asked to authorize the use of the certificate's private key
- If you disable or don't configure this policy setting, applications don't use Windows Hello for Business certificates as smart card certificates, and biometric factors are available when a user is asked to authorize the use of the certificate's private key
This policy setting is incompatible with Windows Hello for Business credentials provisioned when [Turn off smart card emulation](/windows/security/identity-protection/hello-for-business/policy-settings#turn-off-smart-card-emulation) is enabled.
| | Path |
|--|--|
| **CSP** | ./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/[UseHelloCertificatesAsSmartCardCertificates](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesusehellocertificatesassmartcardcertificates) |
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |

22
windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business.md Normal file
View File

@ -0,0 +1,22 @@
---
author: paolomatarazzo
ms.author: paoloma
ms.date: 12/19/2023
ms.topic: include
---
### Use Windows Hello for Business
- If you enable this policy, the device provisions Windows Hello for Business using keys or certificates for all users
- If you disable this policy setting, the device doesn't provision Windows Hello for Business for any user
- If you don't configure this policy setting, users can provision Windows Hello for Business
Select the option *Don't start Windows Hello provisioning after sign-in* when you use a third-party solution to provision Windows Hello for Business:
- If you select *Don't start Windows Hello provisioning after sign-in*, Windows Hello for Business doesn't automatically start provisioning after the user has signed in
- If you don't select *Don't start Windows Hello provisioning after sign-in*, Windows Hello for Business automatically starts provisioning after the user has signed in
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[UsePassportForWork](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesusepassportforwork) <br><br> `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[DisablePostLogonProvisioning](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesdisablepostlogonprovisioning)|
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** <br><br>**User Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**|

193
windows/security/identity-protection/hello-for-business/index.md
View File

@ -4,19 +4,26 @@ description: Learn how Windows Hello for Business replaces passwords with strong
ms.topic: overview
ms.date: 04/24/2023
---
<!-- Windows Hello is a feature that lets you sign in to your Windows device with your biometric data, such as your face, fingerprint or iris. It is more secure and convenient than using a password, and it works with compatible devices and cameras. To use Windows Hello, you need to set up a PIN and then enable the facial or fingerprint recognition option in the Settings app. You can also use a PIN as an alternative sign-in method.
It is different from Windows Hello, which is designed for personal devices and individual accounts. Windows Hello for Business provides stronger security and more configuration options for enterprises and organizations. It also requires additional infrastructure and policies to support it. Some of the key differences are:
Windows Hello for Business uses a two-factor authentication method that combines a device-specific credential with a biometric or PIN gesture. This credential is tied to your identity provider, such as Active Directory or Azure AD, and can be used to access enterprise apps, websites, and services. Windows Hello for individuals uses a single-factor authentication method that is unique to the device, but can use a password hash depending on the account type.
Windows Hello for Business can be managed and enforced by IT administrators using Group Policy or Mobile Device Management (MDM) tools. They can set policies to control the use of biometrics, PINs, and security keys, as well as the enrollment and revocation of credentials. Windows Hello for individuals does not have these management options and is configured by the user.
Windows Hello for Business supports Fast Identity Online (FIDO) 2.0 authentication standards, which enable passwordless sign-in to compatible websites and services. Windows Hello for individuals does not support FIDO 2.0, but can use FIDO U2F security keys as
-->
# Windows Hello for Business Overview
Windows Hello for Business replaces passwords with strong two-factor authentication on devices. This authentication consists of a type of user credential that is tied to a device and uses a biometric or PIN.
>[!NOTE]
> When Windows 10 first shipped, it included Microsoft Passport and Windows Hello, which worked together to provide multi-factor authentication. To simplify deployment and improve supportability, Microsoft has combined these technologies into a single solution under the Windows Hello name. Customers who have already deployed these technologies will not experience any change in functionality. Customers who have yet to evaluate Windows Hello will find it easier to deploy due to simplified policies, documentation, and semantics.
Windows Hello addresses the following problems with passwords:
- Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites.
- Server breaches can expose symmetric network credentials (passwords).
- Passwords are subject to [replay attacks](/previous-versions/dotnet/netframework-4.0/aa738652(v=vs.100)).
- Users can inadvertently expose their passwords due to phishing attacks.
- Strong passwords can be difficult to remember, and users often reuse passwords on multiple sites
- Server breaches can expose symmetric network credentials (passwords)
- Passwords are subject to replay attacks
- Users can inadvertently expose their passwords due to phishing attacks
Windows Hello lets users authenticate to:
@ -37,7 +44,7 @@ As an administrator in an enterprise or educational organization, you can create
- **Fingerprint recognition**. This type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Fingerprint readers have been available for Windows computers for years, but the current generation of sensors is more reliable and less error-prone. Most existing fingerprint readers work with Windows 10 and Windows 11, whether they're external or integrated into laptops or USB keyboards.
- **Iris Recognition**. This type of biometric recognition uses cameras to perform scan of your iris. HoloLens 2 is the first Microsoft device to introduce an Iris scanner. These iris scanners are the same across all HoloLens 2 devices.
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there's no single collection point an attacker can compromise to steal biometric data. For more information about biometric authentication with Windows Hello for Business, see [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md).
Windows stores biometric data that is used to implement Windows Hello securely on the local device only. The biometric data doesn't roam and is never sent to external devices or servers. Because Windows Hello only stores biometric identification data on the device, there's no single collection point an attacker can compromise to steal biometric data.
## The difference between Windows Hello and Windows Hello for Business
@ -64,49 +71,165 @@ Windows Hello helps protect user identities and user credentials. Because the us
[!INCLUDE [windows-hello-for-business](../../../../includes/licensing/windows-hello-for-business.md)]
## How Windows Hello for Business works: key points
## Hardware requirements
- Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials can be bound to the device, and the token that is obtained using the credential is also bound to the device.
We've been working with the device manufacturers to help ensure a high-level of performance and protection is met by each sensor and device, based on these requirements:
- An identity provider validates the user identity and maps the Windows Hello public key to a user account during the registration step. Example providers are Active Directory, Microsoft Entra ID, or a Microsoft account.
- **False Accept Rate (FAR).** Represents the instance a biometric identification solution verifies an unauthorized person. This is normally represented as a ratio of number of instances in a given population size, for example 1 in 100 000. This can also be represented as a percentage of occurrence, for example, 0.001%. This measurement is heavily considered the most important with regard to the security of the biometric algorithm.
- Keys can be generated in hardware (TPM 1.2 or 2.0 for enterprises, and TPM 2.0 for consumers) or software, based on the policy. To guarantee that keys are generated in hardware, you must set policy.
- **False Reject Rate (FRR).** Represents the instances a biometric identification solution fails to verify an authorized person correctly. Usually represented as a percentage, the sum of the True Accept Rate and False Reject Rate is 1. Can be with or without anti-spoofing or liveness detection.
- Authentication is the two-factor authentication with the combination of a key or certificate tied to a device and something that the person knows (a PIN) or something that the person is (biometrics). The Windows Hello gesture doesn't roam between devices and isn't shared with the server. Biometrics templates are stored locally on a device. The PIN is never stored or shared.
### Fingerprint sensor requirements
- The private key never leaves a device when using TPM. The authenticating server has a public key that is mapped to the user account during the registration process.
To allow fingerprint matching, you must have devices with fingerprint sensors and software. Fingerprint sensors, or sensors that use an employee's unique fingerprint as an alternative logon option, can be touch sensors (large area or small area) or swipe sensors. Each type of sensor has its own set of detailed requirements that must be implemented by the manufacturer, but all of the sensors must include anti-spoofing measures.
- PIN entry and biometric gesture both trigger Windows 10 and later to use the private key to cryptographically sign data that is sent to the identity provider. The identity provider verifies the user's identity and authenticates the user.
**Acceptable performance range for small to large size touch sensors**
- Personal (Microsoft account) and corporate (Active Directory or Microsoft Entra ID) accounts use a single container for keys. All keys are separated by identity providers' domains to help ensure user privacy.
- False Accept Rate (FAR): <0.001 - 0.002%
- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture.
- Effective, real world FRR with Anti-spoofing or liveness detection: <10%
For details, see [How Windows Hello for Business works](hello-how-it-works.md).
**Acceptable performance range for swipe sensors**
## Comparing key-based and certificate-based authentication
- False Accept Rate (FAR): <0.002%
Windows Hello for Business can use either keys (hardware or software) or certificates in hardware or software. Enterprises that have a public key infrastructure (PKI) for issuing and managing end user certificates can continue to use PKI in combination with Windows Hello for Business. Enterprises that don't use PKI or want to reduce the effort associated with managing user certificates can rely on key-based credentials for Windows Hello. This functionality still uses certificates on the domain controllers as a root of trust. Starting with Windows 10 version 21H2, there's a feature called cloud Kerberos trust for hybrid deployments, which uses Microsoft Entra ID as the root of trust. cloud Kerberos trust uses key-based credentials for Windows Hello but doesn't require certificates on the domain controller.
- Effective, real world FRR with Anti-spoofing or liveness detection: <10%
Windows Hello for Business with a key, including cloud Kerberos trust, doesn't support supplied credentials for RDP. RDP doesn't support authentication with a key or a self signed certificate. RDP with Windows Hello for Business is supported with certificate based deployments as a supplied credential. Windows Hello for Business with a key credential can be used with [Remote Credential Guard](../remote-credential-guard.md).
### Facial recognition sensors
## Learn more
To allow facial recognition, you must have devices with integrated special infrared (IR) sensors and software. Facial recognition sensors use special cameras that see in IR light, letting them tell the difference between a photo and a living person while scanning an employee's facial features. These sensors, like the fingerprint sensors, must also include anti-spoofing measures (required) and a way to configure them (optional).
[Implementing strong user authentication with Windows Hello for Business](https://www.microsoft.com/insidetrack/implementing-strong-user-authentication-with-windows-hello-for-business)
- False Accept Rate (FAR): <0.001%
[Implementing Windows Hello for Business at Microsoft](https://www.microsoft.com/insidetrack/implementing-windows-hello-for-business-at-microsoft)
- False Reject Rate (FRR) without Anti-spoofing or liveness detection: <5%
[Windows Hello for Business: Authentication](https://youtu.be/WPmzoP_vMek): In this video, learn about Windows Hello for Business and how it's used to sign-in and access resources.
- Effective, real world FRR with Anti-spoofing or liveness detection: <10%
[Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication)
> [!NOTE]
>Windows Hello face authentication does not currently support wearing a mask during enrollment or authentication. Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. The product group is aware of this behavior and is investigating this topic further. Please remove a mask if you are wearing one when you enroll or unlock with Windows Hello face authentication. If your working environment doesn't allow you to remove a mask temporarily, please consider unenrolling from face authentication and only using PIN or fingerprint.
## Related articles
### Iris recognition sensor requirements
- [How Windows Hello for Business works](hello-how-it-works.md)
- [Manage Windows Hello for Business in your organization](hello-manage-in-organization.md)
- [Why a PIN is better than a password](hello-why-pin-is-better-than-password.md)
- [Prepare people to use Windows Hello](hello-prepare-people-to-use.md)
- [Windows Hello and password changes](hello-and-password-changes.md)
- [Windows Hello errors during PIN creation](hello-errors-during-pin-creation.md)
- [Event ID 300 - Windows Hello successfully created](/windows/security/identity-protection/hello-for-business/hello-faq)
- [Windows Hello biometrics in the enterprise](hello-biometrics-in-enterprise.md)
To use Iris authentication, you'll need a [HoloLens 2 device](/hololens/). All HoloLens 2 editions are equipped with the same sensors. Iris is implemented the same way as other Windows Hello technologies and achieves biometrics security FAR of 1/100K.
# Why a PIN is better than an online password
Windows Hello enables users to sign in to their device using a PIN. How is a PIN different from (and better than) a local password?
On the surface, a PIN looks much like a password. A PIN can be a set of numbers, but enterprise policy might enforce complex PINs that include special characters and letters, both upper-case and lower-case. Something like **t758A!** could be an account password or a complex Hello PIN. It isn't the structure of a PIN (length, complexity) that makes it better than an online password, it's how it works. First, we need to distinguish between two types of passwords: *local passwords* are validated against the machine's password store, whereas *online passwords* are validated against a server.
:::row:::
:::column span="1":::
**A PIN is tied to a device**
:::column-end:::
:::column spna="3":::
One important difference between an online password and a Hello PIN is that the PIN is tied to the specific device on which it's set up. That PIN is useless to anyone without that specific hardware. Someone who obtains your online password can sign in to your account from anywhere, but if they obtain your PIN, they'd have to access your device too. The PIN can't be used anywhere except on that specific device. If you want to sign in on multiple devices, you have to set up Hello on each device.
:::row-end:::
:::row:::
:::column span="1":::
**A PIN is local to the device**
:::column-end:::
:::column spna="3":::
An online password is transmitted to the server. The password can be intercepted in transmission or obtained from a server. A PIN is local to the device, never transmitted anywhere, and it isn't stored on the server.
When the PIN is created, it establishes a trusted relationship with the identity provider and creates an asymmetric key pair that is used for authentication. When you enter your PIN, you unlock the authentication key, which is used to sign the request that is sent to the authenticating server.
Even though local passwords are local to the device, they're less secure than a PIN, as described in the next section.
:::row-end:::
:::row:::
:::column span="1":::
**A PIN is backed by hardware**
:::column-end:::
:::column spna="3":::
The Hello PIN is backed by a Trusted Platform Module (TPM) chip, which is a secure crypto-processor that is designed to carry out cryptographic operations. The chip includes multiple physical security mechanisms to make it tamper resistant, and malicious software is unable to tamper with the security functions of the TPM. Windows doesn't link local passwords to TPM, therefore PINs are considered more secure than local passwords.
User key material is generated and available within the TPM of the device. The TPM protects the key material from attackers who want to capture and reuse it. Since Hello uses asymmetric key pairs, users credentials can't be stolen in cases where the identity provider or websites the user accesses have been compromised.
The TPM protects against various known and potential attacks, including PIN brute-force attacks. After too many incorrect guesses, the device is locked.
:::row-end:::
## What if someone steals the device?
To compromise a Windows Hello credential that TPM protects, an attacker must have access to the physical device. Then, the attacker must find a way to spoof the user's biometrics or guess the PIN. All these actions must be done before [TPM anti-hammering](/windows/device-security/tpm/tpm-fundamentals#anti-hammering) protection locks the device.
## Why do you need a PIN to use biometrics?
Windows Hello enables biometric sign-in for Windows: fingerprint, iris, or facial recognition. When you set up Windows Hello, you're asked to create a PIN after the biometric setup. The PIN enables you to sign in when you can't use your preferred biometric because of an injury or because the sensor is unavailable or not working properly.
If you only had a biometric sign-in configured and, for any reason, were unable to use that method to sign in, you would have to sign in using your account and password, which doesn't provide you with the same level of protection as Hello.
<!--
## Conditional access considerations
Conditional Access can prevent or grant access to services like Exchange Online and SharePoint Online, based on the status of Windows Hello. To learn more about the Intune options to configure and monitor Windows Hello for Business, check the following articles.
Windows Hello can replace passwords with two-factor authentication that consists of a Windows Hello biometric credential or PIN along with the device itself with the set of private/public keys. Windows Hello lets users authenticate to a Microsoft account, an Active Directory account, a Microsoft Entra ID account, or non-Microsoft service that supports Fast ID Online (FIDO) authentication. After an initial two-step verification during Windows Hello enrollment, a Windows Hello credential is set up on the user's device and the user sets a gesture, which can be Windows Hello or a PIN. The user provides the gesture to verify identity; Windows then uses Hello to authenticate users and help them to access protected resources and services.
Benefits
User convenience: users provide their credentials, and are then guided to set up Windows Hello. From that point on, they can access enterprise resources by providing a gesture
Security: Windows Hello helps protect user identities and user credentials. Since no passwords are used, it circumvents phishing and brute force attacks, but most importantly it prevents server breaches as Windows Hello credentials are asymmetric key pair and replayability attacks when these keys are generated within isolated environments of TPMs
How Windows Hello for Business Works
Windows Hello credentials are based on certificate or asymmetrical key pair (RSA 2048 bit key pairs).
The identity provider (Microsoft Entra ID, Active Directory,Microsoft Account) validates the user identity and maps a Windows Hello public key to the user account during the registration step.
Keys can be generated in hardware (TPM 1.2 or 2.0) or software, based on configured policy settings:
- Keys generated in hardware, on select TPMs, can be attested to cryptographicly prove the fact that they are hardware bound
- If a device doesn't have a supported TPM, you can configure a policy setting to enable software keys
Authentication is the two factor authentication with combination of a device (key or certificate) and something that the user sknows (a PIN), or something that person is (biometric). We refer to PIN and biometrics as *Windows Hello gestures*. Windows Hello gestures don't roam between devices and aren't shared with the server; they are stored locally on the device.
The private key never leaves a device. The authenticating server has a public key mapped to user account during the registration process
PIN entry and biogesture both trigger Windows to verify the user's identity and authenticate using Windows Hello keys or certificates
Personal (Microsoft account) and corporate (Microsoft Entra ID/Active Directory) accounts use separate containers for keys, separated by domains, to ensure user privacy
The biometric data used to support Windows Hello is stored on the local device only. It doesn't roam and is never sent to external devices or servers. This separation helps to stop potential attackers by providing no single collection point that an attacker could potentially compromise to steal biometric data. Additionally, even if an attacker was able to get the biometric data from a device, it cannot be converted back into a raw biometric sample that could be recognized by the biometric sensor.
Each sensor on a device has its own biometric database file where template data is stored. Each database has a unique, randomly generated key that is encrypted to the system. The template data for the sensor is encrypted with this per-database key using AES with CBC chaining mode. The hash is SHA256. Some fingerprint sensors have the capability to complete matching on the fingerprint sensor module instead of in the OS. These sensors store biometric data on the fingerprint module instead of in the database file.
PIN is better than password:
Tied to the device
- Pin is useless to anyone without the specific device
Local to the device
- Pin isn't transmitted anywhere, and it isn't stored on the server
Backed by hardware
- Protect PIN against brute-force and other potentials known attacks
Can be complex
*The Windows Hello for Business Container (NGC) can be used to protect keys from many sources.
*Each key is generated and bound to the TPM if the hardware is capable.
*It may also protect a custom enrolled certificate (e.g. SmartCard emulation)
*Can also contain generic passkey credentials
Deployment steps:
Device Registration
- Device is joined to AD and/or AAD
Provisioning
*Enable WHfB using Group Policy or Intune
*When the policy is received, if all the prerequisites are met, the user will be able to configure WHfB
*The dsregcmd tool is critical to solve registration and provisioning issues
- WHFB is enrolled on the client: During enrollment: the user is required to perform MFA
- Keys are registered with AD and/or AAD
Authentication
- WHfB is used to authenticate user against AAD and/or AD
## User experience
Windows Hello for Business provisioning begins immediately after the user has signed in, after the user profile is loaded, but before the user can access their desktop. Windows only launches the provisioning experience if all the prerequisite checks pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** in the **Event Viewer** under **Applications and Services Logs\Microsoft\Windows**.
> [!NOTE]
> You must allow access to the URL `account.microsoft.com` to initiate Windows Hello for Business provisioning. This URL launches the subsequent steps in the provisioning process and is required to successfully complete Windows Hello for Business provisioning. This URL doesn't require any authentication and as such, doesn't collect any user data.
-->

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

@ -1,9 +1,10 @@
---
title: Multi-factor unlock
description: Learn how Windows offers multi-factor device unlock by extending Windows Hello with trusted signals.
ms.date: 03/30/2023
description: Learn how to configure Windows Hello for Business multi-factor unlock by extending Windows Hello with trusted signals.
ms.date: 12/19/2023
ms.topic: how-to
---
# 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.
@ -331,35 +332,66 @@ The following example configures **Wi-Fi** as a trusted signal.
</rule>
```
## Deploy Multifactor Unlock
## Configure multi-factor 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).
To configure multi-factor unlock you can use:
### 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.
- Microsoft Intune/CSP
- Group policy
>[!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. For more information, see [Passport For Work CSP](/windows/client-management/mdm/passportforwork-csp).
> - You can't use the same unlock factor to satisfy both categories. Therefore, if you include any credential provider in bothcategories, it means it can satisfy either category, but not both
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.
[!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)]
#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/CSP**](#tab/intune)
[!INCLUDE [intune-settings-catalog-1](../../../../includes/configure/intune-settings-catalog-1.md)]
| Category | Setting name |
|--|--|
| **Administrative Templates** > **Windows Hello for Business** | Device Unlock Plugins |
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)
[!INCLUDE [intune-settings-catalog-2](../../../../includes/configure/intune-settings-catalog-2.md)]
Alternatively, you can configure devices using a [custom policy][INT-1] with the [PassportForWork CSP][CSP-1].
| Setting |
|--------|
| ./Device/Vendor/MSFT/PassportForWork/[DeviceUnlock](/windows/client-management/mdm/passportforwork-csp#devicedeviceunlock)|
#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo)
[!INCLUDE [gpo-settings-1](../../../../includes/configure/gpo-settings-1.md)]
| Group policy path | Group policy setting | Value |
| - | - | - |
| **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** | Configure device unlock factors | Enabled |
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)
[!INCLUDE [gpo-settings-2](../../../../includes/configure/gpo-settings-2.md)]
---
>[!IMPORTANT]
>You should 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).
## User experience
Here's a brief video showing the user experience when multi-factor unlock is enabled:
1. The user first signs in with fingerprint + Bluetooth-paired phone
1. The user then signs in with fingerprint + PIN
> [!VIDEO https://learn-video.azurefd.net/vod/player?id=2bdf21db-30c9-4d8e-99ff-f3ae72c494fe alt-text="Video showing the user experience of multi-factor unlock using fingerprint+Bluetooth and fingerprint+PIN."]
## Troubleshoot
@ -374,3 +406,8 @@ Multi-factor unlock writes events to event log under **Application and Services
|6520|Warning event|
|7520|Error event|
|8520|Success event|
<!--links-->
[CSP-1]: /windows/client-management/mdm/passportforwork-csp
[INT-1]: /mem/intune/configuration/settings-catalog

4
windows/security/identity-protection/hello-for-business/pin-reset.md
View File

@ -38,8 +38,6 @@ The following table compares destructive and nondestructive PIN reset:
|**Additional configuration required**|Supported by default and doesn't require configuration|Deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature.|
|**MSA/Enterprise**|MSA and Enterprise|Enterprise only.|
<a name='enable-the-microsoft-pin-reset-service-in-your-azure-ad-tenant'></a>
## Enable the Microsoft PIN Reset Service in your Microsoft Entra tenant
Before you can use nondestructive PIN reset, you must register two applications in your Microsoft Entra tenant:
@ -176,8 +174,6 @@ The _PIN reset_ configuration can be viewed by running [**dsregcmd /status**](/a
+----------------------------------------------------------------------+
```
<a name='configure-allowed-urls-for-federated-identity-providers-on-azure-ad-joined-devices'></a>
## Configure allowed URLs for federated identity providers on Microsoft Entra joined devices
**Applies to:** Microsoft Entra joined devices

85
windows/security/identity-protection/hello-for-business/policy-settings.md Normal file
View File

@ -0,0 +1,85 @@
---
title: Windows Hello for Business policy settings
description: Learn about the policy settings to configure Configure Windows Hello for Business.
ms.topic: reference
ms.date: 12/19/2023
---
# Windows Hello for Business policy settings
The list of settings is sorted alphabetically and organized in four categories:
- **Feature settings**: used to enable Windows Hello for Business and configure basic options
- **PIN setting**: used to configure PIN authentication, like PIN complexity and recovery
- **Biometric setting**: used to configure biometric authentication
- **Smart card settings**: used to configure smart card authentication used in conjunction with Windows Hello for Business
Select one of the tabs to see the list of available settings:
# [:::image type="icon" source="images/hello.svg"::: **Feature settings**](#tab/feature)
|Setting Name|CSP|GPO|
|-|-|-|
|[Configure device unlock factors](#configure-device-unlock-factors)|✅|✅|
|[Configure dynamic lock factors](#configure-dynamic-lock-factors)|✅|✅|
|[Use a hardware security device](#use-a-hardware-security-device)|✅|✅|
|[Use certificate for on-premises authentication](#use-certificate-for-on-premises-authentication)|✅|✅|
|[Use cloud (Kerberos) trust for on-premises authentication](#use-cloud-trust-for-on-premises-authentication)|✅|✅|
|[Use Windows Hello for Business](#use-windows-hello-for-business)|✅|✅|
[!INCLUDE [configure-device-unlock-factors](includes/configure-device-unlock-factors.md)]
[!INCLUDE [configure-dynamic-lock-factors](includes/configure-dynamic-lock-factors.md)]
[!INCLUDE [use-a-hardware-security-device](includes/use-a-hardware-security-device.md)]
[!INCLUDE [use-certificate-for-on-premises-authentication](includes/use-certificate-for-on-premises-authentication.md)]
[!INCLUDE [use-cloud-trust-for-on-premises-authentication](includes/use-cloud-trust-for-on-premises-authentication.md)]
[!INCLUDE [use-windows-hello-for-business](includes/use-windows-hello-for-business.md)]
# [:::image type="icon" source="images/pin.svg"::: **PIN settings**](#tab/pin)
|Setting Name|CSP|GPO|
|-|-|-|-|
|[Expiration](#expiration)|✅|✅|
|[History](#history)|✅|✅|
|[Maximum PIN length](#maximum-pin-length)|✅|✅|
|[Minimum PIN length](#minimum-pin-length)|✅|✅|
|[Require digits](#require-digits)|✅|✅|
|[Require lowercase letters](#require-lowercase-letters)|✅|✅|
|[Require special characters](#require-special-characters)|✅|✅|
|[Require uppercase letters](#require-uppercase-letters)|✅|✅|
[!INCLUDE [expiration](includes/expiration.md)]
[!INCLUDE [history](includes/history.md)]
[!INCLUDE [maximum-pin-length](includes/maximum-pin-length.md)]
[!INCLUDE [minimum-pin-length](includes/minimum-pin-length.md)]
[!INCLUDE [require-digits](includes/require-digits.md)]
[!INCLUDE [require-lowercase-letters](includes/require-lowercase-letters.md)]
[!INCLUDE [require-special-characters](includes/require-special-characters.md)]
[!INCLUDE [require-uppercase-letters](includes/require-uppercase-letters.md)]
[!INCLUDE [use-pin-recovery](includes/use-pin-recovery.md)]
# [:::image type="icon" source="images/fingerprint.svg"::: **Biometric settings**](#tab/bio)
|Setting Name|CSP|GPO|
|-|-|-|
|[Configure enhanced anti-spoofing](#configure-enhanced-anti-spoofing)|✅|✅|
|[Enable ESS with Supported Peripherals](#enable-ess-with-supported-peripherals)|✅|✅|
|[Use biometrics](#use-biometrics)|✅|✅|
[!INCLUDE [configure-enhanced-anti-spoofing](includes/configure-enhanced-anti-spoofing.md)]
[!INCLUDE [enable-ess-with-supported-peripherals](includes/enable-ess-with-supported-peripherals.md)]
[!INCLUDE [use-biometrics](includes/use-biometrics.md)]
# [:::image type="icon" source="images/smartcard.svg"::: **Smart card settings**](#tab/smartcard)
|Setting Name|CSP|GPO|
|-|-|-|
|[Turn off smart card emulation](#turn-off-smart-card-emulation)|❌|✅|
|[Allow enumeration of emulated smart card for all users](#allow-enumeration-of-emulated-smart-card-for-all-users)|❌|✅|
|[Use Windows Hello for Business certificates as smart card certificates](#use-windows-hello-for-business-certificates-as-smart-card-certificates)|✅|✅|
[!INCLUDE [allow-enumeration-of-emulated-smart-card-for-all-users](includes/allow-enumeration-of-emulated-smart-card-for-all-users.md)]
[!INCLUDE [turn-off-smart-card-emulation](includes/turn-off-smart-card-emulation.md)]
[!INCLUDE [use-windows-hello-for-business-certificates-as-smart-card-certificates](includes/use-windows-hello-for-business-certificates-as-smart-card-certificates.md)]
---

11
windows/security/identity-protection/hello-for-business/rdp-sign-in.md
View File

@ -271,16 +271,7 @@ Here's a brief video showing the user experience from a Microsoft Entra joined d
While users appreciate the convenience of biometrics, and administrators value the security, you might experience compatibility issues with applications and Windows Hello for Business certificates. In such scenarios, you can deploy a policy setting to revert to the previous behavior for the users needing it.
### Use Windows Hello for Business certificates as smart card certificates
If you enable this policy setting, applications use Windows Hello for Business certificates as smart card certificates. Biometric factors are unavailable when a user is asked to authorize the use of the certificate's private key. This policy setting is designed to allow compatibility with applications that rely exclusively on smart card certificates.
If you disable or don't configure this policy setting, applications don't use Windows Hello for Business certificates as smart card certificates. Biometric factors are available when a user is asked to authorize the use of the certificate's private key.
| | Path |
|--|--|
| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[UseHelloCertificatesAsSmartCardCertificates][WIN-1]|
| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** |
For more information, see [Use Windows Hello for Business certificates as smart card certificate](policy-settings.md#use-windows-hello-for-business-certificates-as-smart-card-certificates)
<!-- links -->

51
windows/security/identity-protection/hello-for-business/toc.yml
View File

@ -1,40 +1,25 @@
items:
- name: Overview
href: index.md
- name: Concepts
expanded: true
items:
- name: Why a PIN is better than a password
href: hello-why-pin-is-better-than-password.md
- name: Windows Hello biometrics in the enterprise
href: hello-biometrics-in-enterprise.md
- name: How Windows Hello for Business works
href: hello-how-it-works.md
- name: Plan a Windows Hello for Business deployment
href: hello-planning-guide.md
- name: How Windows Hello for Business works
href: how-it-works.md
- name: Windows Hello for Business planning guide
href: deploy/index.md
- name: Configure Windows Hello for Business
href: configure.md
- name: Deployment guides
href: deploy/toc.yml
- name: How-to Guides
- name: How-to-guides
items:
- name: Prepare people to use Windows Hello
href: hello-prepare-people-to-use.md
- name: Manage Windows Hello for Business in your organization
href: hello-manage-in-organization.md
- name: Windows Hello and password changes
href: hello-and-password-changes.md
- name: Windows Hello for Business features
items:
- name: PIN reset
- name: Configure PIN reset
href: pin-reset.md
- name: Windows Hello Enhanced Security Sign-in (ESS) 🔗
href: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security
- name: Dual enrollment
- name: Configure dual enrollment
href: hello-feature-dual-enrollment.md
- name: Dynamic Lock
- name: Configure dynamic lock
href: hello-feature-dynamic-lock.md
- name: Multi-factor Unlock
href: feature-multifactor-unlock.md
- name: Remote desktop (RDP) sign-in
- name: Configure multi-factor unlock
href: multifactor-unlock.md
- name: Configure remote desktop (RDP) sign-in
href: rdp-sign-in.md
- name: Troubleshooting
items:
@ -44,14 +29,18 @@ items:
href: hello-errors-during-pin-creation.md
- name: Reference
items:
- name: Windows Hello for Business policy settings
href: policy-settings.md
- name: How Windows Hello for Business provisioning works
href: hello-how-it-works-provisioning.md
href: how-it-works-provisioning.md
- name: How Windows Hello for Business authentication works
href: hello-how-it-works-authentication.md
href: how-it-works-authentication.md
- name: WebAuthn APIs
href: webauthn-apis.md
- name: Windows Hello Enhanced Security Sign-in (ESS) 🔗
href: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security
- name: Technology and terminology
href: hello-how-it-works-technology.md
href: glossary.md
- name: Frequently Asked Questions (FAQ)
href: hello-faq.yml
- name: Windows Hello for Business videos