diff --git a/.openpublishing.redirection.windows-security.json b/.openpublishing.redirection.windows-security.json index d0bee7874b..9ddad9824f 100644 --- a/.openpublishing.redirection.windows-security.json +++ b/.openpublishing.redirection.windows-security.json @@ -8217,13 +8217,123 @@ }, { "source_path": "windows/security/identity-protection/hello-for-business/hello-key-trust-validate-pki.md", - "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust", "redirect_document_id": false }, { "source_path": "windows/security/identity-protection/hello-for-business/hello-identity-verification.md", "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/requirements", "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-mfa.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-mfa.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/requirements.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/multifactor-unlock", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-and-password-changes.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/how-it-works", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/how-it-works", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-how-it-works.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/how-it-works", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/how-it-works-authentication", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/how-it-works-provisioning", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/policy-settings", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-planning-guide.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/prepare-users", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/passwordless-strategy.md", + "redirect_url": "/windows/security/identity-protection/passwordless-strategy/", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/cloud.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/cloud-only", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-pki.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-pki.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-videos.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/hello-faq.yml", + "redirect_url": "/windows/security/identity-protection/hello-for-business/faq", + "redirect_document_id": false + }, + { + "source_path": "windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki.md", + "redirect_url": "/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust", + "redirect_document_id": false } ] } \ No newline at end of file diff --git a/images/group-policy.svg b/images/group-policy.svg index ace95add6b..95957a5914 100644 --- a/images/group-policy.svg +++ b/images/group-policy.svg @@ -1,3 +1,9 @@ - - - \ No newline at end of file + + + + + + + + + diff --git a/windows/client-management/mdm/policy-csp-admx-externalboot.md b/windows/client-management/mdm/policy-csp-admx-externalboot.md index 966421095a..ea236024a2 100644 --- a/windows/client-management/mdm/policy-csp-admx-externalboot.md +++ b/windows/client-management/mdm/policy-csp-admx-externalboot.md @@ -41,6 +41,8 @@ Specifies whether the PC can use the hibernation sleep state (S4) when started f +> [!IMPORTANT] +> Windows To Go was announced as deprecated in Windows 10, version 1903, and was removed in version 2004. For more information, see [Features and functionality removed in Windows](/windows/whats-new/removed-features). @@ -102,6 +104,8 @@ This policy setting controls whether the PC will boot to Windows To Go if a USB +> [!IMPORTANT] +> Windows To Go was announced as deprecated in Windows 10, version 1903, and was removed in version 2004. For more information, see [Features and functionality removed in Windows](/windows/whats-new/removed-features). @@ -161,6 +165,8 @@ Specifies whether the PC can use standby sleep states (S1-S3) when starting from +> [!IMPORTANT] +> Windows To Go was announced as deprecated in Windows 10, version 1903, and was removed in version 2004. For more information, see [Features and functionality removed in Windows](/windows/whats-new/removed-features). diff --git a/windows/deployment/windows-10-deployment-scenarios.md b/windows/deployment/windows-10-deployment-scenarios.md index c216cfa830..977a188cdd 100644 --- a/windows/deployment/windows-10-deployment-scenarios.md +++ b/windows/deployment/windows-10-deployment-scenarios.md @@ -94,7 +94,7 @@ There are some situations where you can't use in-place upgrade; in these situati - Changing from Windows 7, Windows 8, or Windows 8.1 x86 to Windows 10 x64. The upgrade process can't change from a 32-bit operating system to a 64-bit operating system, because of possible complications with installed applications and drivers. -- Windows To Go and Boot from VHD installations. The upgrade process is unable to upgrade these installations. Instead, new installations would need to be performed. +- Boot from VHD installations. The upgrade process is unable to upgrade these installations. Instead, new installations would need to be performed. - Updating existing images. It can be tempting to try to upgrade existing Windows 7, Windows 8, or Windows 8.1 images to Windows 10 by installing the old image, upgrading it, and then recapturing the new Windows 10 image. But, it's not supported. Preparing an upgraded OS via `Sysprep.exe` before capturing an image isn't supported and won't work. When `Sysprep.exe` detects the upgraded OS, it will fail. diff --git a/windows/security/application-security/application-control/user-account-control/settings-and-configuration.md b/windows/security/application-security/application-control/user-account-control/settings-and-configuration.md index 284e549300..e9d01861ab 100644 --- a/windows/security/application-security/application-control/user-account-control/settings-and-configuration.md +++ b/windows/security/application-security/application-control/user-account-control/settings-and-configuration.md @@ -35,7 +35,7 @@ To configure UAC, you can use: The following instructions provide details how to configure your devices. Select the option that best suits your needs. -#### [:::image type="icon" source="../../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune) +#### [:::image type="icon" source="../../../images/icons/intune.svg" border="false"::: **Intune/CSP**](#tab/intune) ### Configure UAC with a Settings catalog policy @@ -61,7 +61,7 @@ The policy settings are located under: `./Device/Vendor/MSFT/Policy/Config/Local | **Setting name**: Switch to the secure desktop when prompting for elevation
**Policy CSP name**: `UserAccountControl_SwitchToTheSecureDesktopWhenPromptingForElevation`| | **Setting name**: Virtualize file and registry write failures to per-user locations
**Policy CSP name**: `UserAccountControl_VirtualizeFileAndRegistryWriteFailuresToPerUserLocations`| -#### [:::image type="icon" source="../../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +#### [:::image type="icon" source="../../../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) You can use security policies to configure how User Account Control works in your organization. The policies can be configured locally by using the Local Security Policy snap-in (`secpol.msc`) or configured for the domain, OU, or specific groups by group policy. @@ -80,7 +80,7 @@ The policy settings are located under: `Computer Configuration\Windows Settings\ |User Account Control: Switch to the secure desktop when prompting for elevation | Enabled | |User Account Control: Virtualize file and registry write failures to per-user locations | Enabled | -#### [:::image type="icon" source="../../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg) +#### [:::image type="icon" source="../../../images/icons/registry.svg" border="false"::: **Registry**](#tab/reg) The registry keys are found under the key: `HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System`. diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/administer-applocker.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/administer-applocker.md index ef477ce467..a095fd7246 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/administer-applocker.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/administer-applocker.md @@ -3,7 +3,7 @@ title: Administer AppLocker description: This article for IT professionals provides links to specific procedures to use when administering AppLocker policies. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Administer AppLocker diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-overview.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-overview.md index ffd2a32a70..654b172dca 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-overview.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/applocker-overview.md @@ -6,7 +6,7 @@ ms.collection: - must-keep ms.topic: conceptual ms.localizationpriority: medium -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # AppLocker diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md index e237fc6361..e974fdf194 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/deploy-applocker-policies-by-using-the-enforce-rules-setting.md @@ -3,7 +3,7 @@ title: Deploy AppLocker policies by using the enforce rules setting description: This article for IT professionals describes the steps to deploy AppLocker policies by using the enforcement setting method. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Deploy AppLocker policies by using the enforce rules setting diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/edit-an-applocker-policy.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/edit-an-applocker-policy.md index ed64315838..fe3ac2062b 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/edit-an-applocker-policy.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/edit-an-applocker-policy.md @@ -3,7 +3,7 @@ title: Edit an AppLocker policy description: This article for IT professionals describes the steps required to modify an AppLocker policy. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Edit an AppLocker policy diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/maintain-applocker-policies.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/maintain-applocker-policies.md index 933deb03c0..75f6df943a 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/maintain-applocker-policies.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/maintain-applocker-policies.md @@ -3,7 +3,7 @@ title: Maintain AppLocker policies description: Learn how to maintain rules within AppLocker policies. View common AppLocker maintenance scenarios and see the methods to use to maintain AppLocker policies. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Maintain AppLocker policies diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/optimize-applocker-performance.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/optimize-applocker-performance.md index 6523b1bccc..63277272b1 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/optimize-applocker-performance.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/optimize-applocker-performance.md @@ -3,7 +3,7 @@ title: Optimize AppLocker performance description: This article for IT professionals describes how to optimize AppLocker policy enforcement. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Optimize AppLocker performance diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md index 33b57f4bc0..e47477a31a 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/test-and-update-an-applocker-policy.md @@ -3,7 +3,7 @@ title: Test and update an AppLocker policy description: This article discusses the steps required to test an AppLocker policy prior to deployment. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Test and update an AppLocker policy diff --git a/windows/security/application-security/application-control/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md b/windows/security/application-security/application-control/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md index ffefd947e7..0678fb60b9 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/applocker/use-the-applocker-windows-powershell-cmdlets.md @@ -3,7 +3,7 @@ title: Use the AppLocker Windows PowerShell cmdlets description: This article for IT professionals describes how each AppLocker Windows PowerShell cmdlet can help you administer your AppLocker application control policies. ms.localizationpriority: medium ms.topic: conceptual -ms.date: 12/19/2023 +ms.date: 01/03/2024 --- # Use the AppLocker Windows PowerShell cmdlets diff --git a/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview.md b/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview.md index b6495d2d01..5e998b8788 100644 --- a/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview.md +++ b/windows/security/application-security/application-control/windows-defender-application-control/wdac-and-applocker-overview.md @@ -2,7 +2,7 @@ title: WDAC and AppLocker Overview description: Compare Windows application control technologies. ms.localizationpriority: medium -ms.date: 12/19/2023 +ms.date: 01/03/2024 ms.topic: article --- diff --git a/windows/security/identity-protection/credential-guard/configure.md b/windows/security/identity-protection/credential-guard/configure.md index e6e9d95ed6..9f8373b96b 100644 --- a/windows/security/identity-protection/credential-guard/configure.md +++ b/windows/security/identity-protection/credential-guard/configure.md @@ -37,7 +37,7 @@ To enable Credential Guard, you can use: [!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)] -#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune) +#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/CSP**](#tab/intune) ### Configure Credential Guard with Intune @@ -64,7 +64,7 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the Once the policy is applied, restart the device. -#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) ### Configure Credential Guard with group policy @@ -81,7 +81,7 @@ Once the policy is applied, restart the device. Once the policy is applied, restart the device. -#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg) +#### [:::image type="icon" source="../../images/icons/registry.svg" border="false"::: **Registry**](#tab/reg) ### Configure Credential Guard with registry settings @@ -232,7 +232,7 @@ There are different options to disable Credential Guard. The option you choose d [!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)] -#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune) +#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/CSP**](#tab/intune) ### Disable Credential Guard with Intune @@ -254,7 +254,7 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the Once the policy is applied, restart the device. -#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) ### Disable Credential Guard with group policy @@ -270,7 +270,7 @@ If Credential Guard is enabled via Group Policy and without UEFI Lock, disabling Once the policy is applied, restart the device. -#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg) +#### [:::image type="icon" source="../../images/icons/registry.svg" border="false"::: **Registry**](#tab/reg) ### Disable Credential Guard with registry settings @@ -336,7 +336,7 @@ Use one of the following options to disable VBS: [!INCLUDE [tab-intro](../../../../includes/configure/tab-intro.md)] -#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune) +#### [:::image type="icon" source="../../images/icons/intune.svg" border="false"::: **Intune/CSP**](#tab/intune) ### Disable VBS with Intune @@ -358,7 +358,7 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the Once the policy is applied, restart the device. -#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +#### [:::image type="icon" source="../../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) ### Disable VBS with group policy @@ -374,7 +374,7 @@ Configure the policy used to enable VBS to **Disabled**. Once the policy is applied, restart the device -#### [:::image type="icon" source="../../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg) +#### [:::image type="icon" source="../../images/icons/registry.svg" border="false"::: **Registry**](#tab/reg) ### Disable VBS with registry settings diff --git a/windows/security/identity-protection/hello-for-business/configure.md b/windows/security/identity-protection/hello-for-business/configure.md new file mode 100644 index 0000000000..7c498d0bb4 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/configure.md @@ -0,0 +1,137 @@ +--- +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: 01/03/2024 +--- + +# Configure Windows Hello for Business + +This article describes the options to configure Windows Hello for Business in an organization, 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. CSPs can also be configured with [provisioning packages](/windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers#csps-in-windows-configuration-designer), which are usually used at deployment time or for unamanged devices. To configure Windows Hello for Business, 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 + +## Policy precedence + +Some of the Windows Hello for Business policies are available for both computer and user configuration. The following list describes the policy precedence for 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 +- Windows Hello for Business policy settings 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 settings 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="deploy/images/whfb-intune-disable.png" alt-text="Disablement of Windows Hello for Business from Microsoft Intune admin center." lightbox="deploy/images/whfb-intune-disable.png"::: + +## 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*. + +> [!NOTE] +> For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). + +## 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, including: + +- Disable Windows Hello using the [tenant-wide policy](#verify-the-tenant-wide-policy) +- Disable it using one of the policy types available in Intune, while enabling the Enrollment Status Page (ESP). The ESP can be configured to prevent a user from accessing the desktop until the device receives all the required policies. For more information, see [Set up the Enrollment Status Page](/mem/intune/enrollment/windows-enrollment-status). The policy setting to configure is [Use Windows Hello for Business](policy-settings.md#use-windows-hello-for-business) +- Provision the devices using a provisioning package that disables Windows Hello for Business. For more information, see [Provisioning packages for Windows](/windows/configuration/provisioning-packages/provisioning-packages) +- Scripted solutions that can modify the registry settings to disable Windows Hello for Business during OS deployment + +Configuration type| Details | +|--|-| +| CSP (user)|**Key path**: `HHKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\\UserSid\Policies`
**Key name**: `UsePassportForWork`
**Type**: `REG_DWORD`
**Value**:
 `1` to enable
 `0` to disable | +| CSP (device)|**Key path**: `HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Policies\PassportForWork\\Device\Policies`
**Key name**: `UsePassportForWork`
**Type**: `REG_DWORD`
**Value**:
 `1` to enable
 `0` to disable | +| GPO (user)|**Key path**: `HKEY_USERS\\SOFTWARE\Policies\Microsoft\PassportForWork`
**Key name**: `Enabled`
**Type**: `REG_DWORD`
**Value**:
 `1` to enable
 `0` to disable | +| GPO (user)|**Key path**: `KEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\PassportForWork`
**Key name**: `Enabled`
**Type**: `REG_DWORD`
**Value**:
 `1` to enable
 `0` to disable | + +> [!NOTE] +> If there's a conflicting device policy and user policy, the user policy takes precedence. It's not recommended to create Local GPO or registry settings that could conflict with an MDM policy. This conflict could lead to unexpected results. + +## Next steps + +For a list of Windows Hello for Business policy settings, see [Windows Hello for Business policy settings](policy-settings.md). + +To learn more about Windows Hello for Business features and how to configure them, see: + +- [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) + + + +[CSP-1]: /windows/client-management/mdm/passportforwork-csp#devicetenantid +[CSP-2]: /windows/client-management/mdm/passportforwork-csp +[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-4]: /windows/client-management/mdm/passportforwork-csp +[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy +[MEM-6]: /mem/intune/protect/identity-protection-configure diff --git a/windows/security/identity-protection/hello-for-business/deploy/cloud-only.md b/windows/security/identity-protection/hello-for-business/deploy/cloud-only.md new file mode 100644 index 0000000000..475b2dc597 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/cloud-only.md @@ -0,0 +1,117 @@ +--- +title: Windows Hello for Business cloud-only deployment guide +description: Learn how to deploy Windows Hello for Business in a cloud-only deployment scenario. +ms.date: 01/03/2024 +ms.topic: how-to +--- + +# Cloud-only deployment guide + +[!INCLUDE [apply-to-cloud](includes/apply-to-cloud.md)] + +[!INCLUDE [requirements](includes/requirements.md)] + +> [!div class="checklist"] +> +> - [Authentication](index.md#authentication-to-microsoft-entra-id) +> - [Device configuration](index.md#device-configuration-options) +> - [Licensing for cloud services](index.md#licensing-for-cloud-services-requirements) +> - [Prepare users to use Windows Hello](prepare-users.md) + +## Deployment steps + +> [!div class="checklist"] +> Once the prerequisites are met, deploying Windows Hello for Business consists of the following steps: +> +> - [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) +> - [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business) + +## Configure Windows Hello for Business policy settings + +When you Microsoft Entra join a device, the system attempts to automatically enroll you in Windows Hello for Business. If you want to use Windows Hello for Business in a cloud-only environment with its default settings, there's no extra configuration needed. + +Cloud-only deployments use Microsoft Entra multifactor authentication (MFA) during Windows Hello for Business enrollment, and there's no other MFA configuration needed. If you aren't already registered in MFA, you're guided through the MFA registration as part of the Windows Hello for Business enrollment process. + +Policy settings can be configured to control the behavior of Windows Hello for Business, via configuration service provider (CSP) or group policy (GPO). In cloud-only deployments, devices are +typically configured via an MDM solution like Microsoft Intune, using the [PassportForWork CSP][WIN-1]. + +> [!NOTE] +> Review the article [Configure Windows Hello for Business using Microsoft Intune](../configure.md#configure-windows-hello-for-business-using-microsoft-intune) to learn about the different options offered by Microsoft Intune to configure Windows Hello for Business. + +If the Intune tenant-wide policy is configured to *disable Windows Hello for Business*, or if devices are deployed with Windows Hello disabled, you must configure one policy setting to enable Windows Hello for Business: + +- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business) + +Another optional, but recommended, policy setting is: + +- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device) + +Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). + +# [:::image type="icon" source="images/intune.svg"::: **Intune/CSP**](#tab/intune) + +[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)] + +| Category | Setting name | Value | +|--|--|--| +| **Windows Hello for Business** | Use Passport For Work | true | +| **Windows Hello for Business** | Require Security Device | true | + +[!INCLUDE [intune-settings-catalog-2](../../../../../includes/configure/intune-settings-catalog-2.md)] + +Alternatively, you can configure devices using a [custom policy][MEM-1] with the [PassportForWork CSP][CSP-1]. + +| Setting | +|--------| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork`
- **Data type:** `bool`
- **Value:** `True`| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice`
- **Data type:** `bool`
- **Value:** `True`| + +# [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo) + +To configure a device with group policy, use the [Local Group Policy Editor](/previous-versions/windows/it-pro/windows-server-2008-r2-and-2008/cc731745(v=ws.10)). + +| Group policy path | Group policy setting | Value | +| - | - | - | +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**
or
**User Configuration\Administrative Templates\Windows Components\Windows Hello for Business**|Use Windows Hello for Business| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use a hardware security device| **Enabled**| + +--- + +> [!TIP] +> If you're using Microsoft Intune, and you're not using the [tenant-wide policy](../configure.md#verify-the-tenant-wide-policy), enable the Enrollment Status Page (ESP) to ensure that the devices receive the Windows Hello for Business policy settings before users can access their desktop. For more information about ESP, see [Set up the Enrollment Status Page][MEM-1]. + +More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md). + +## Enroll in Windows Hello for Business + +The Windows Hello for Business provisioning process begins immediately after a user signs in, if certain prerequisite checks are passed. + +### User experience + +[!INCLUDE [user-experience](includes/user-experience.md)] + +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."] + +### Sequence diagrams + +To better understand the provisioning flows, review the following sequence diagrams based on the authentication type: + +- [Provisioning for Microsoft Entra joined devices with managed authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-managed-authentication) +- [Provisioning for Microsoft Entra joined devices with federated authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-federated-authentication) + +To better understand the authentication flows, review the following sequence diagram: + +- [Microsoft Entra join authentication to Microsoft Entra ID](../how-it-works-authentication.md#microsoft-entra-join-authentication-to-microsoft-entra-id) + +## Disable automatic enrollment + +If you want to disable the automatic Windows Hello for Business enrollment, you can configure your devices with a policy setting or registry key. For more information, see [Disable Windows Hello for Business enrollment](../configure.md#disable-windows-hello-for-business-enrollment). + +> [!NOTE] +> During the out-of-box experience (OOBE) flow of a Microsoft Entra join, you are guided to enroll in Windows Hello for Business when you don't have Intune. You can cancel the PIN screen and access the desktop without enrolling in Windows Hello for Business. + + + +[CSP-1]: /windows/client-management/mdm/passportforwork-csp +[MEM-1]: /mem/intune/enrollment/windows-enrollment-status +[WIN-1]: /windows/client-management/mdm/passportforwork-csp diff --git a/windows/security/identity-protection/hello-for-business/deploy/cloud.md b/windows/security/identity-protection/hello-for-business/deploy/cloud.md deleted file mode 100644 index ca409fc0b7..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/cloud.md +++ /dev/null @@ -1,84 +0,0 @@ ---- -title: Windows Hello for Business cloud-only deployment -description: Learn how to configure Windows Hello for Business in a cloud-only deployment scenario. -ms.date: 10/03/2023 -ms.topic: how-to ---- -# Cloud-only deployment - -[!INCLUDE [apply-to-cloud](includes/apply-to-cloud.md)] - -## Introduction - -When you Microsoft Entra join a Windows device, the system prompts you to enroll in Windows Hello for Business by default. If you want to use Windows Hello for Business in a cloud-only environment, there's no additional configuration needed. - -You may wish to disable the automatic Windows Hello for Business enrollment prompts if you aren't ready to use it in your environment. This article describes how to disable Windows Hello for Business enrollment in a cloud only environment. - -> [!NOTE] -> During the out-of-box experience (OOBE) flow of a Microsoft Entra join, you will see a provisioning PIN when you don't have Intune. You can always cancel the PIN screen and set this cancellation with registry keys to prevent future prompts. - -## Prerequisites - -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). - -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: - -```powershell -Connect-MgGraph -$DomainId = "" -Get-MgDomainFederationConfiguration -DomainId $DomainId |fl -``` - -To reject the MFA claim from the federated IdP, use the following command. This change impacts all MFA scenarios for the federated domain. - -```powershell -Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp -``` - -If you use configure the flag with a value of either `acceptIfMfaDoneByFederatedIdp` (default) or `enforceMfaByFederatedIdp`, you must verify that your federated IDP is correctly configured and working with the MFA adapter and provider used by your IdP. - -## Use Intune to disable Windows Hello for Business enrollment - -We recommend that you disable or manage Windows Hello for Business provisioning behavior through an Intune policy. For more specific information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello). - -### Disable Windows Hello for Business using Intune Enrollment policy - -The following method explains how to disable Windows Hello for Business enrollment using Intune. - -1. Sign into the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -2. Go to **Devices** > **Enrollment** > **Enroll devices** > **Windows enrollment** > **Windows Hello for Business**. The Windows Hello for Business pane opens. -3. If you don't want to enable Windows Hello for Business during device enrollment, select **Disabled** for **Configure Windows Hello for Business**. - - When disabled, users can't provision Windows Hello for Business. When set to Disabled, you can still configure the subsequent settings for Windows Hello for Business even though this policy won't enable Windows Hello for Business. - -> [!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\\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\\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. diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-adfs.md index c5e4939fc8..447f1f5c55 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-adfs.md @@ -1,23 +1,17 @@ --- 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. -ms.date: 12/15/2023 -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +description: Learn how to configure Active Directory Federation Services (AD FS) to support the Windows Hello for Business hybrid certificate trust model. +ms.date: 01/03/2024 ms.topic: tutorial --- -# Configure Active Directory Federation Services - hybrid certificate trust +# Configure Active Directory Federation Services in a hybrid certificate trust model [!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)] The Windows Hello for Business certificate-based deployments use AD FS as the certificate registration authority (CRA). The CRA is responsible for issuing and revoking certificates to users. Once the registration authority verifies the certificate request, it signs the certificate request using its enrollment agent certificate and sends it to the certificate authority.\ -The CRA enrolls for an *enrollment agent certificate*, and 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 CRA enrolls for an *enrollment agent certificate*, and the Windows Hello for Business *authentication certificate template* is configured to only issue certificates to requests signed with an enrollment agent certificate. > [!NOTE] > In order for AD FS to verify user certificate requests for Windows Hello for Business, it needs to be able to access the `https://enterpriseregistration.windows.net` endpoint. @@ -39,11 +33,11 @@ Set-AdfsCertificateAuthority -EnrollmentAgent -EnrollmentAgentCertificateTemplat AD FS performs its own certificate lifecycle management. Once the registration authority is configured with the proper certificate template, the AD FS server attempts to enroll the certificate on the first certificate request or when the service first starts. -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. +Approximately 60 days prior to enrollment agent certificate's expiration, the AD FS service attempts to renew the certificate until it's successful. If the certificate fails to renew, and the certificate expires, the AD FS server requests a new enrollment agent certificate. You can view the AD FS event logs to determine the status of the enrollment agent certificate. ### Group Memberships for the AD FS service account -The AD FS service account must be member of the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*). The security group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user. +The AD FS service account must be member of the security group targeted by the authentication certificate template autoenrollment (for example, *Window Hello for Business Users*). The security group provides the AD FS service with the permissions needed to enroll a Windows Hello for Business authentication certificate on behalf of the provisioning user. > [!TIP] > The adfssvc account is the AD FS service account. @@ -51,7 +45,7 @@ The AD FS service account must be member of the security group targeted by the a Sign-in a domain controller or management workstation with _Domain Admin_ equivalent credentials. 1. Open **Active Directory Users and Computers** -1. Search for the security group targeted by the authentication certificate template auto-enrollment (e.g. *Window Hello for Business Users*) +1. Search for the security group targeted by the authentication certificate template autoenrollment (for example, *Window Hello for Business Users*) 1. Select the **Members** tab and select **Add** 1. In the **Enter the object names to select** text box, type **adfssvc** or substitute the name of the AD FS service account in your AD FS deployment > **OK** 1. Select **OK** to return to **Active Directory Users and Computers** diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md index a9363c8a74..2bc061e33b 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-enroll.md @@ -1,104 +1,62 @@ --- -title: Configure and provision Windows Hello for Business in a hybrid certificate trust model +title: Configure and enroll in Windows Hello for Business in 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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +ms.date: 01/03/2024 ms.topic: tutorial --- -# Configure and provision Windows Hello for Business - hybrid certificate trust +# Configure and enroll in Windows Hello for Business in hybrid certificate trust model [!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-cert-trust.md)] -## Policy Configuration +> [!div class="checklist"] +> Once the prerequisites are met, and the PKI and AD FS configurations are validated, deploying Windows Hello for Business consists of the following steps: +> +> - [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) +> - [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business) -After the prerequisites are met and the PKI and AD FS configurations are validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). +## Configure Windows Hello for Business policy settings + +There are two policy settings required to enable Windows Hello for Business in a certificate trust model: + +- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business) +- [Use certificate for on-premises authentication](../policy-settings.md#use-certificate-for-on-premises-authentication) + +Another optional, but recommended, policy setting is: + +- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device) + +Use the following instructions to configure your devices using either Microsoft Intune or group policy (GPO). # [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo) -> [!IMPORTANT] -> The information in this section applies to Microsoft Entra hybrid joined devices only. +[!INCLUDE [gpo-enable-whfb](includes/gpo-enable-whfb.md)] -For Microsoft Entra hybrid joined devices, you can use group policies to configure Windows Hello for Business. -It is suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign the **Group Policy** and **Certificate template 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 and to enroll in the Windows Hello for Business authentication certificate. - -### Enable Windows Hello for Business group policy setting - -The *Enable Windows Hello for Business* group policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to **enabled**.\ -You can configure the *Enable Windows Hello for Business* setting for computer or users: - -- Deploying this policy setting to computers (or group of computers) results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment -- Deploying this policy setting to a user (or group of users), results in only that user attempting a Windows Hello for Business enrollment - -If both user and computer policy settings are deployed, the user policy setting has precedence. - -### Use certificate for on-premises authentication group policy setting - -The *Use certificate for on-premises authentication* group policy setting determines if the deployment uses the *key-trust* or *certificate trust* authentication model. You must configure this Group Policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust authentication. - -### Enable automatic enrollment of certificates group policy setting +> [!TIP] +> Use the same *Windows Hello for Business Users* security group to assign **Certificate template permissions** to ensure the same members can enroll in the Windows Hello for Business authentication certificate. Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business *authentication certificate* template. The process requires no user interaction, provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires. -### Enable and configure Windows Hello for Business with group policy +[!INCLUDE [gpo-settings-1](../../../../../includes/configure/gpo-settings-1.md)] -Sign-in a domain controller or management workstations 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 *Enable Windows Hello for Business* in the name box and select **OK** -1. In the content pane, right-click the **Enable Windows Hello for Business** group policy object and select **Edit** -1. In the navigation pane, expand **Policies** under **User Configuration** -1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business** -1. In the content pane, open **Use Windows Hello for Business**. Select **Enable > OK** -1. Open **Use certificate for on-premises authentication**. Select **Enable > OK** -1. Expand **Windows Settings > Security Settings > Public Key Policies** -1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties** -1. Select **Enabled** from the **Configuration Model** list -1. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check boxes -1. Select the **Update certificates that use certificate templates** check box -1. Select **OK** -1. Close the **Group Policy Management Editor** +| Group policy path | Group policy setting | Value | +| - | - | - | +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**
or
**User Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use Windows Hello for Business| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**
or
**User Configuration\Administrative Templates\Windows Components\Windows Hello for Business**|Use certificate for on-premises authentication| **Enabled**| +| **Computer Configuration\Windows Settings\Security Settings\Public Key Policies**
or
**User Configuration\Windows Settings\Security Settings\Public Key Policies** |Certificate Services Client - Auto-Enrollment| - Select **Enabled** from the **Configuration Model**
- Select the **Renew expired certificates, update pending certificates, and remove revoked certificates**
- Select **Update certificates that use certificate templates**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use a hardware security device| **Enabled**| > [!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). +> The enablement of the *Use a hardware security device* policy setting is optional, but recommended. -### Configure security for GPO +[!INCLUDE [gpo-settings-2](../../../../../includes/configure/gpo-settings-2.md)] -The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. +> [!TIP] +> The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all security principals. The security group filtering ensures that only the members of the global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. -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. Open the **Enable Windows Hello for Business** GPO -1. In the **Security Filtering** section of the content pane, select **Add**. Type the name of the security group you previously created (for example, *Windows Hello for Business Users*) and select **OK** -1. Select the **Delegation** tab. Select **Authenticated Users > Advanced** -1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK** - -### Deploy the Windows Hello for Business Group Policy object - -The application of Group Policy object uses security group filtering. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all users. The security group filtering ensures that only the members of the *Windows Hello for Business Users* global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. - -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 *Enable Windows Hello for Business* or the name of the Windows Hello for Business Group Policy object you previously created and select **OK** - -### Add members to the targeted group - -Users (or devices) must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business. - -# [:::image type="icon" source="images/intune.svg"::: **Intune**](#tab/intune) - -## Configure Windows Hello for Business using Microsoft Intune +# [:::image type="icon" source="images/intune.svg"::: **Intune/CSP**](#tab/intune) > [!IMPORTANT] > The information in this section applies to Microsoft Entra joined devices managed by Intune. Before proceeding, ensure that you completed the steps described in: @@ -106,99 +64,77 @@ Users (or devices) must receive the Windows Hello for Business group policy sett > - [Configure single sign-on for Microsoft Entra joined devices](../hello-hybrid-aadj-sso.md) > - [Using Certificates for AADJ On-premises Single-sign On](../hello-hybrid-aadj-sso-cert.md) -For Microsoft Entra joined devices enrolled in Intune, you can use Intune policies to manage Windows Hello for Business. +> [!NOTE] +> Review the article [Configure Windows Hello for Business using Microsoft Intune](../configure.md#configure-windows-hello-for-business-using-microsoft-intune) to learn about the different options offered by Microsoft Intune to configure Windows Hello for Business. -There are different ways to enable and configure Windows Hello for Business in Intune: +If the Intune 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). -- 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. Choose from the following policy types: - - [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] +[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)] -### Verify the tenant-wide policy +| Category | Setting name | Value | +|--|--|--| +| **Windows Hello for Business** | Use Passport For Work | true | +| **Windows Hello for Business** | Use Certificate For On Prem Auth | Enabled | +| **Windows Hello for Business** | Require Security Device | true | -To check the Windows Hello for Business policy applied at enrollment time: +[!INCLUDE [intune-settings-catalog-2](../../../../../includes/configure/intune-settings-catalog-2.md)] -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 +Alternatively, you can configure devices using a [custom policy][MEM-1] with the [PassportForWork CSP][CSP-1]. -:::image type="content" source="images/whfb-intune-disable.png" alt-text="Screenshot that shows disablement of Windows Hello for Business from Microsoft Intune admin center." lightbox="images/whfb-intune-disable.png"::: +| Setting | +|--------| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork`
- **Data type:** `bool`
- **Value:** `True`| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCertificateForOnPremAuth`
- **Data type:** `bool`
- **Value:** `True`| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice`
- **Data type:** `bool`
- **Value:** `True`| -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. - -### Enable and configure Windows Hello for Business - -To configure Windows Hello for Business using an *account protection* policy: - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Endpoint security** > **Account protection** -1. Select **+ Create Policy** -1. For *Platform**, select **Windows 10 and later** and for *Profile* select **Account protection** -1. Select **Create** -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) -1. Under *Enable to certificate for on-premises resources*, select **YES** -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** -1. Review the policy configuration and select **Create** - -:::image type="content" source="images/whfb-intune-account-protection-cert-enable.png" alt-text="Screenshot that shows enablement of Windows Hello for Business from Microsoft Intune admin center using an account protection policy." lightbox="images/whfb-intune-account-protection-cert-enable.png"::: +For more information about the certificate trust policy, see [Windows Hello for Business policy settings](../policy-settings.md#use-certificate-for-on-premises-authentication). --- +If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources) + +More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md). + ## Enroll in Windows Hello for Business The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > Windows**.\ -This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4]. +This information is also available using the `dsregcmd.exe /status` command from a console. For more information, see [dsregcmd][AZ-4]. -### PIN Setup +### User experience -This is the process that occurs after a user signs in, to enroll in Windows Hello for Business: +[!INCLUDE [user-experience](includes/user-experience.md)] -1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** -1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry -1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device -1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Microsoft Entra ID to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key to Active Directory +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."] -:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Screenshot that shows animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: - -> [!IMPORTANT] -> The following is the enrollment behavior prior to Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). -> -> The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval. -> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources. -> Read [Microsoft Entra Connect Sync: Scheduler](/azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler) to view and adjust the **synchronization cycle** for your organization. -> -> [!NOTE] -> Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users no longer need to wait for Microsoft Entra Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers. - -After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows send the certificate request to the AD FS server for certificate enrollment. +After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows sends the certificate request to the AD FS server for certificate enrollment. The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority. > [!NOTE] -> In order for AD FS to verify the key used in the certificate request, it needs to be able to access the ```https://enterpriseregistration.windows.net``` endpoint. +> In order for AD FS to verify the key used in the certificate request, it needs to be able to access the `https://enterpriseregistration.windows.net` endpoint. -The certificate authority validates the certificate was signed by the registration authority. On successful validation of the signature, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Windows Action Center. +The CA validates that the certificate is signed by the registration authority. On successful validation, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Action Center. + +> [!NOTE] +> Windows Server 2016 update [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889) provides synchronous certificate enrollment during hybrid certificate trust provisioning. With this update, users don't need to wait for Microsoft Entra Connect to sync their public key on-premises. Users enroll their certificate during provisioning and can use the certificate for sign-in immediately after completing the provisioning. The update needs to be installed on the federation servers. + +### Sequence diagrams + +To better understand the provisioning flows, review the following sequence diagrams based on the device join and authentication type: + +- [Provisioning for Microsoft Entra joined devices with managed authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-managed-authentication) +- [Provisioning for Microsoft Entra joined devices with federated authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-federated-authentication) +- [Provisioning in a hybrid certificate trust deployment model with federated authentication](../how-it-works-provisioning.md#provisioning-in-a-hybrid-certificate-trust-deployment-model-with-federated-authentication) + +To better understand the authentication flows, review the following sequence diagram: + +- [Microsoft Entra join authentication to Active Directory using a certificate](../how-it-works-authentication.md#microsoft-entra-join-authentication-to-active-directory-using-a-certificate) +- [Microsoft Entra hybrid join authentication using a certificate](../how-it-works-authentication.md#microsoft-entra-hybrid-join-authentication-using-a-certificate) -[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd -[MEM-1]: /mem/intune/configuration/settings-catalog -[MEM-2]: /mem/intune/protect/security-baselines -[MEM-3]: /mem/intune/configuration/custom-settings-configure -[MEM-4]: /windows/client-management/mdm/passportforwork-csp -[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy -[MEM-6]: /mem/intune/protect/identity-protection-configure +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd +[CSP-1]: /windows/client-management/mdm/passportforwork-csp +[MEM-1]: /mem/intune/configuration/custom-settings-configure diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki.md index 7ff5c70e48..85dd13860f 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust-pki.md @@ -1,20 +1,15 @@ --- 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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +ms.date: 01/03/2024 ms.topic: tutorial --- + # Configure and validate the PKI in a hybrid certificate trust model [!INCLUDE [apply-to-hybrid-cert-trust](includes/apply-to-hybrid-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. +Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *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. Hybrid certificate trust deployments issue users a sign-in certificate, enabling them to authenticate to Active Directory using Windows Hello for Business credentials. Additionally, hybrid certificate trust deployments issue certificates to registration authorities to provide defense-in-depth security when issuing user authentication certificates. @@ -22,22 +17,15 @@ 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. - -> [!IMPORTANT] -> For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to: -> -> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune -> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL +[!INCLUDE [dc-certificate-template-dc-hybrid-notes](includes/certificate-template-dc-hybrid-notes.md)] [!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)] diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust.md index a9d49ebfec..3fcb86b928 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cert-trust.md @@ -1,74 +1,51 @@ --- -title: Windows Hello for Business hybrid certificate trust deployment +title: Windows Hello for Business hybrid certificate trust deployment guide description: Learn how to deploy Windows Hello for Business in a hybrid certificate trust scenario. -ms.date: 12/15/2023 -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +ms.date: 01/03/2024 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. - > [!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 +[!INCLUDE [requirements](includes/requirements.md)] > [!div class="checklist"] -> The following prerequisites must be met for a hybrid certificate trust deployment: > -> - Directories and directory synchronization -> - Federated authentication to Microsoft Entra ID -> - Device registration -> - Public Key Infrastructure -> - Multifactor authentication -> - Device management +> - [Public Key Infrastructure](index.md#pki-requirements) +> - [Authentication](index.md#authentication-to-microsoft-entra-id) +> - [Device configuration](index.md#device-configuration-options) +> - [Licensing for cloud services](index.md#licensing-for-cloud-services-requirements) +> - [Prepare users to use Windows Hello](prepare-users.md) -### Directories and directory synchronization +## Deployment steps -Hybrid Windows Hello for Business needs two directories: +> [!div class="checklist"] +> Once the prerequisites are met, deploying Windows Hello for Business consists of the following steps: +> +> - [Configure and validate the Public Key Infrastructure](hybrid-cert-trust-pki.md) +> - [Configure Active Directory Federation Services](hybrid-cert-trust-adfs.md) +> - [Configure and enroll in Windows Hello for Business](hybrid-cert-trust-enroll.md) +> - (optional) [Configure single sign-on for Microsoft Entra joined devices](../hello-hybrid-aadj-sso.md) -- An on-premises Active Directory -- A Microsoft Entra tenant with a Microsoft Entra ID P1 or P2 subscription +## Federated authentication to Microsoft Entra ID -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. - -> [!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. - -> [!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. - -### Federated authentication to Microsoft Entra ID - -Windows Hello for Business hybrid certificate trust doesn't support Microsoft Entra ID *Pass-through Authentication* (PTA) or *password hash sync* (PHS).\ -Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Microsoft Entra ID using AD FS. Additionally, you need to configure your AD FS farm to support Azure registered devices. +Windows Hello for Business hybrid certificate trust requires Active Directory to be federated with Microsoft Entra ID using AD FS. You must also configure the AD FS farm to support Azure registered devices. If you're new to AD FS and federation services: - Review [key AD FS concepts][SER-3] prior to deploying the AD FS farm - Review the [AD FS design guide][SER-4] to design and plan your federation service -Once you have your AD FS design ready: - -- Review [deploying a federation server farm][SER-2] to configure AD FS in your environment +Once you have your AD FS design ready, review [deploying a federation server farm][SER-2] to configure AD FS in your environment The AD FS farm used with Windows Hello for Business must be Windows Server 2016 with minimum update of [KB4088889 (14393.2155)](https://support.microsoft.com/help/4088889). -### Device registration and device write-back +## Device registration and device write-back Windows devices must be registered in Microsoft Entra ID. Devices can be registered in Microsoft Entra ID using either *Microsoft Entra join* or *Microsoft Entra hybrid join*.\ For Microsoft Entra hybrid joined devices, review the guidance on the [plan your Microsoft Entra hybrid join implementation][AZ-8] page. @@ -79,9 +56,9 @@ For a **manual configuration** of your AD FS farm to support device registration Hybrid certificate trust deployments require the *device write-back* feature. Authentication to AD FS needs both the user and the device to authenticate. Typically the users are synchronized, but not devices. This prevents AD FS from authenticating the device and results in Windows Hello for Business certificate enrollment failures. For this reason, Windows Hello for Business deployments need device write-back. > [!NOTE] -> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Microsoft Entra ID and Active Directory. Device write-back is used to update the *msDS-KeyCredentialLink* attribute on the computer object. +> Windows Hello for Business is tied between a user and a device. Both the user and device need to be synchronized between Microsoft Entra ID and Active Directory. Device write-back is used to update the `msDS-KeyCredentialLink` attribute on the computer object. -If you manually configured AD FS, or if you ran Microsoft Entra Connect Sync using *Custom Settings*, you must ensure that you have configured **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5]. +If you manually configured AD FS, or if you ran Microsoft Entra Connect Sync using *Custom Settings*, you must ensure to configure **device write-back** and **device authentication** in your AD FS farm. For more information, see [Configure Device Write Back and Device Authentication][SER-5]. ### Public Key Infrastructure @@ -90,21 +67,6 @@ The enterprise PKI and a certificate registration authority (CRA) are required t During Windows Hello for Business provisioning, users receive a sign-in certificate through the CRA. -### 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.\ -Hybrid deployments can use: - -- [Microsoft Entra multifactor authentication][AZ-2] -- A multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS - -For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][AZ-3].\ -For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. - -### Device management - -To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy. - ## Next steps > [!div class="checklist"] @@ -120,14 +82,10 @@ To configure Windows Hello for Business, devices can be configured through a mob > [Next: configure and validate the Public Key Infrastructure >](hybrid-cert-trust-pki.md) -[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis -[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication -[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next [AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan [AZ-10]: /azure/active-directory/devices/howto-hybrid-azure-ad-join#federated-domains [AZ-11]: /azure/active-directory/devices/hybrid-azuread-join-manual -[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa [SER-2]: /windows-server/identity/ad-fs/deployment/deploying-a-federation-server-farm [SER-3]: /windows-server/identity/ad-fs/technical-reference/understanding-key-ad-fs-concepts [SER-4]: /windows-server/identity/ad-fs/design/ad-fs-design-guide-in-windows-server-2012-r2 diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll.md deleted file mode 100644 index da843f036d..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust-enroll.md +++ /dev/null @@ -1,218 +0,0 @@ ---- -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: -- ✅ Windows 10, version 21H2 and later -ms.topic: tutorial ---- -# Configure and provision Windows Hello for Business - cloud Kerberos trust - -[!INCLUDE [apply-to-hybrid-cloud-kerberos-trust](includes/apply-to-hybrid-cloud-kerberos-trust.md)] - -## Deployment steps - -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. - - - -### 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. - -If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the [Enable passwordless security key sign-in to on-premises resources by using Microsoft Entra ID][AZ-2] documentation. This page includes information on how to install and use the Microsoft Entra Kerberos PowerShell module. Use the module to create a Microsoft Entra Kerberos server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust. - -### Configure Windows Hello for Business policy - -After setting up the Microsoft Entra Kerberos object, Windows Hello for business cloud Kerberos trust must be enabled on your Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). - -#### [:::image type="icon" source="images/intune.svg"::: **Intune**](#tab/intune) - -For devices managed by Intune, you can use Intune policies to configure Windows Hello for Business. - -There are different ways to enable and configure Windows Hello for Business in Intune: - -- When the device is enrolled in Intune, a tenant-wide policy is applied to the device. This policy is applied at enrollment time only, and any changes to its configuration won't apply to devices already enrolled in Intune. For this reason, this policy is usually disabled, and Windows Hello for Business can be enabled using a policy targeted to a security group. -- After the device is enrolled in Intune, you can apply a device configuration policy. 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-7] - - [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. -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." border="true" lightbox="images/whfb-intune-disable.png"::: - -If the tenant-wide policy is enabled and configured to your needs, you can skip to [Configure cloud Kerberos trust policy](#configure-the-cloud-kerberos-trust-policy). Otherwise, follow the instructions below to create a policy using an *account protection* policy. - -### Enable Windows Hello for Business - -To configure Windows Hello for Business using an account protection policy: - -1. Sign in to the Microsoft Intune admin center. -1. Select **Endpoint security** > **Account protection**. -1. Select **+ Create Policy**. -1. For **Platform**, select **Windows 10 and later** and for **Profile** select **Account protection**. -1. Select **Create**. -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). -1. Under **Enable to certificate for on-premises resources**, select **Not configured** -1. Select **Next**. -1. Optionally, add **scope tags** and select **Next**. -1. Assign the policy to a security group that contains as members the devices or users that you want to configure > **Next**. -1. Review the policy configuration and select **Create**. - -> [!TIP] -> If you want to enforce the use of digits for your Windows Hello for Business PIN, use the settings catalog and choose **Digits** or **Digits (User)** instead of using the Account protection template. - -:::image type="content" source="images/whfb-intune-account-protection-enable.png" alt-text="This image shows the enablement of Windows Hello for Business from Microsoft Intune admin center using an account protection policy." lightbox="images/whfb-intune-account-protection-enable.png"::: - -Assign the policy to a security group that contains as members the devices or users that you want to configure. - -### Configure the cloud Kerberos trust policy - -The cloud Kerberos trust policy can be configured using a custom template, and it's configured separately from enabling Windows Hello for Business. - -To configure the cloud Kerberos trust policy: - -1. Sign in to the Microsoft Intune admin center. -1. Select **Devices** > **Windows** > **Configuration Profiles** > **Create profile**. -1. For Profile Type, select **Templates** and select the **Custom** Template. -1. Name the profile with a familiar name, for example, "Windows Hello for Business cloud Kerberos trust". -1. In Configuration Settings, add a new configuration with the following settings: - - - Name: **Windows Hello for Business cloud Kerberos trust** or another familiar name - - Description (optional): *Enable Windows Hello for Business cloud Kerberos trust for sign-in and on-premises SSO* - - OMA-URI: **`./Device/Vendor/MSFT/PassportForWork/`*\*`/Policies/UseCloudTrustForOnPremAuth`** - - Data type: **Boolean** - - Value: **True** - - > [!IMPORTANT] - > *Tenant ID* in the OMA-URI must be replaced with the tenant ID for your Microsoft Entra tenant. See [How to find your Microsoft Entra tenant ID][AZ-3] for instructions on looking up your tenant ID. - - :::image type="content" alt-text ="Intune custom-device configuration policy creation" source="images/hello-cloud-trust-intune.png" lightbox="images/hello-cloud-trust-intune-large.png"::: - -1. Assign the policy to a security group that contains as members the devices or users that you want to configure. - -#### [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo) - -Microsoft Entra hybrid joined organizations can use Windows Hello for Business Group Policy to manage the feature. Group Policy can be configured to enable users to enroll and use Windows Hello for Business. - -The Enable Windows Hello for Business Group Policy setting is used by Windows to determine if a user should attempt to enroll a credential. A user will only attempt enrollment if this policy is configured to enabled. - -You can configure the Enable Windows Hello for Business Group Policy setting for computers or users. Deploying this policy setting to computers results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment. Deploying this policy setting to a user results in only that user attempting a Windows Hello for Business enrollment. Additionally, you can deploy the policy setting to a group of users so only those users attempt a Windows Hello for Business enrollment. If both user and computer policy settings are deployed, the user policy setting has precedence. - -Cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy is only available as a computer configuration. - -> [!NOTE] -> If you deployed Windows Hello for Business configuration using both Group Policy and Microsoft Intune, Group Policy settings will take precedence and Intune settings will be ignored. For more information about deploying Windows Hello for Business configuration using Microsoft Intune, see [Windows device settings to enable Windows Hello for Business in Intune][MEM-1] and [PassportForWork CSP](/windows/client-management/mdm/passportforwork-csp). For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../hello-manage-in-organization.md#policy-conflicts-from-multiple-policy-sources). - -#### Update administrative templates - -You may need to update your Group Policy definitions to be able to configure the cloud Kerberos trust policy. You can copy the ADMX and ADML files from a Windows client that supports cloud Kerberos trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the *Passport.admx* and *Passport.adml* files. - -You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows][TS-1]. - -#### Create the Windows Hello for Business group policy object - -You can configure Windows Hello for Business cloud Kerberos trust using a Group Policy Object (GPO). - -1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer objects in Active Directory. -1. Edit the Group Policy object from Step 1. -1. Expand **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**. -1. Select **Use Windows Hello for Business** > **Enable** > **OK**. -1. Select **Use cloud Kerberos trust for on-premises authentication** > **Enable** > **OK**. -1. Optional, but recommended: select **Use a hardware security device** > **Enable** > **OK**. - ---- - -> [!IMPORTANT] -> If the **Use certificate for on-premises authentication** policy is enabled, certificate trust will take precedence over cloud Kerberos trust. Ensure that the machines that you want to enable cloud Kerberos trust have this policy **not configured**. - -## Provision Windows Hello for Business - -The Windows Hello for Business provisioning process begins immediately after a user has signed in if certain prerequisite checks are passed. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy. - -You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs** > **Microsoft** > **Windows**.\ -This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4]. - -:::image type="content" alt-text="Cloud Kerberos trust prerequisite check in the user device registration log" source="images/cloud-trust-prereq-check.png" lightbox="images/cloud-trust-prereq-check.png"::: - -The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user will receive a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't being enforced by policy or if the device is Microsoft Entra joined. - -> [!NOTE] -> The cloud Kerberos trust prerequisite check isn't done on Microsoft Entra joined devices. If Microsoft Entra Kerberos isn't provisioned, a user on a Microsoft Entra joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory. - -### PIN Setup - -After a user signs in, this is the process that occurs to enroll in Windows Hello for Business: - -1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK**. -1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry. -1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device. - -:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: - -### Sign-in - -Once a user has set up a PIN with cloud Kerberos trust, it can be used **immediately** for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user has signed in or unlocked with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity. - -## Migrate from key trust deployment model to cloud Kerberos trust - -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. [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. - -> [!NOTE] -> For Microsoft Entra hybrid joined devices, users must perform the first sign in with new credentials while having line of sight to a DC. - -## Migrate from certificate trust deployment model to cloud Kerberos trust - -> [!IMPORTANT] -> There is no *direct* migration path from a certificate trust deployment to a cloud Kerberos trust deployment. The Windows Hello container must be deleted before you can migrate to cloud Kerberos trust. - -If you deployed Windows Hello for Business using the certificate trust model, and want to use the cloud Kerberos trust model, you must redeploy Windows Hello for Business by following these steps: - -1. Disable the certificate trust policy. -1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy). -1. Remove the certificate trust credential using the command `certutil -deletehellocontainer` from the user context. -1. Sign out and sign back in. -1. Provision Windows Hello for Business using a method of your choice. - -> [!NOTE] -> For Microsoft Entra hybrid joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC. - -## Frequently Asked Questions - -For a list of frequently asked questions about Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business Frequently Asked Questions](../hello-faq.yml#cloud-kerberos-trust). - - - -[AZ-2]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azure-ad-kerberos-powershell-module -[AZ-3]: /azure/active-directory/fundamentals/how-to-find-tenant -[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd - -[MEM-1]: /mem/intune/protect/identity-protection-windows-settings -[MEM-2]: /mem/intune/protect/security-baselines -[MEM-3]: /mem/intune/configuration/custom-settings-configure -[MEM-4]: /windows/client-management/mdm/passportforwork-csp -[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy -[MEM-6]: /mem/intune/protect/identity-protection-configure -[MEM-7]: /mem/intune/configuration/settings-catalog - -[TS-1]: /troubleshoot/windows-client/group-policy/create-and-manage-central-store diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust.md index c53e872bb1..1c67b375b7 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-cloud-kerberos-trust.md @@ -1,38 +1,43 @@ --- -title: Windows Hello for Business cloud Kerberos trust deployment +title: Windows Hello for Business cloud Kerberos trust deployment guide description: Learn how to deploy Windows Hello for Business in a cloud Kerberos trust scenario. -ms.date: 02/24/2023 -appliesto: -- ✅ Windows 10, version 21H2 and later +ms.date: 01/03/2024 ms.topic: tutorial --- -# Cloud Kerberos trust deployment + +# Cloud Kerberos trust deployment guide [!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. +[!INCLUDE [requirements](includes/requirements.md)] -## Introduction to cloud Kerberos trust +> [!div class="checklist"] +> +> - [Authentication](index.md#authentication-to-microsoft-entra-id) +> - [Device configuration](index.md#device-configuration-options) +> - [Windows requirements](index.md#windows-requirements) +> - [Windows Server requirements](index.md#windows-server-requirements) +> - [Prepare users to use Windows Hello](prepare-users.md) -The goal of Windows Hello for Business cloud Kerberos trust is to bring the simplified deployment experience of [*passwordless security key sign-in*][AZ-1] to Windows Hello for Business, and it can be used for new or existing Windows Hello for Business deployments. +> [!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]. -Windows Hello for Business cloud Kerberos trust uses *Microsoft Entra Kerberos*, which enables a simpler deployment when compared to the *key trust model*: +## Deployment steps -- 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 -- [Passwordless security key sign-in][AZ-1] can be deployed with minimal extra setup +> [!div class="checklist"] +> Once the prerequisites are met, deploying Windows Hello for Business consists of the following steps: +> +> - [Deploy Microsoft Entra Kerberos](#deploy-microsoft-entra-kerberos) +> - [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) +> - [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business) -> [!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. +## Deploy Microsoft Entra Kerberos - +If you've already deployed on-premises SSO for passwordless security key sign-in, then Microsoft Entra Kerberos is already deployed in your organization. You don't need to redeploy or change your existing Microsoft Entra Kerberos deployment to support Windows Hello for Business, and you can skip to the [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) section. -## Microsoft Entra Kerberos and cloud Kerberos trust authentication +If you haven't deployed Microsoft Entra Kerberos, follow the instructions in the [Enable passwordless security key sign-in][ENTRA-1] documentation. This page includes information on how to install and use the Microsoft Entra Kerberos PowerShell module. Use the module to create a Microsoft Entra Kerberos server object for the domains where you want to use Windows Hello for Business cloud Kerberos trust. -*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. - -Cloud Kerberos trust uses Microsoft Entra Kerberos, which doesn't require a PKI to request TGTs.\ -With Microsoft Entra Kerberos, Microsoft Entra ID can issue TGTs for one or more AD domains. Windows can request a TGT from Microsoft Entra ID when authenticating with Windows Hello for Business, and use the returned TGT for sign-in or to access AD-based resources. The on-premises domain controllers are still responsible for Kerberos service tickets and authorization. +### Microsoft Entra Kerberos and cloud Kerberos trust authentication When Microsoft Entra Kerberos is enabled in an Active Directory domain, an *AzureADKerberos* computer object is created in the domain. This object: @@ -42,55 +47,164 @@ When Microsoft Entra Kerberos is enabled in an Active Directory domain, an *Azur > [!NOTE] > Similar rules and restrictions used for RODCs apply to the AzureADKerberos computer object. For example, users that are direct or indirect members of priviliged built-in security groups won't be able to use cloud Kerberos trust. -:::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 "::: +:::image type="content" source="images/azuread-kerberos-object.png" alt-text="Screenshot of the 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). - -> [!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]. - -## Prerequisites - -| Requirement | Notes | -| --- | --- | -| Multifactor authentication | This requirement can be met using [Microsoft Entra multifactor authentication](/azure/active-directory/authentication/howto-mfa-getstarted), multifactor authentication provided through AD FS, or a comparable solution. | -| Windows 10, version 21H2 or Windows 11 and later | If you're using Windows 10 21H2, KB5010415 must be installed. If you're using Windows 11 21H2, KB5010414 must be installed. There's no Windows version support difference between Microsoft Entra joined and Microsoft Entra hybrid joined devices. | -| Windows Server 2016 or later Domain Controllers | If you're using Windows Server 2016, [KB3534307][SUP-1] must be installed. If you're using Server 2019, [KB4534321][SUP-2] must be installed. | -| Microsoft Entra Kerberos PowerShell module | This module is used for enabling and managing Microsoft Entra Kerberos. It's available through the [PowerShell Gallery](https://www.powershellgallery.com/packages/AzureADHybridAuthenticationManagement).| -| Device management | Windows Hello for Business cloud Kerberos trust can be managed with group policy or through mobile device management (MDM) policy. This feature is disabled by default and must be enabled using policy. | - -### Unsupported scenarios - -The following scenarios aren't supported using Windows Hello for Business cloud Kerberos trust: - -- 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" -- Signing in with cloud Kerberos trust on a Microsoft Entra hybrid joined device without previously signing in with DC connectivity +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](../how-it-works-authentication.md#microsoft-entra-hybrid-join-authentication-using-cloud-kerberos-trust). > [!NOTE] > The default *Password Replication Policy* configured on the AzureADKerberos computer object doesn't allow to sign high privilege accounts on to on-premises resources with cloud Kerberos trust or FIDO2 security keys. > -> Due to possible attack vectors from Microsoft Entra ID to Active Directory, it **isn't recommended** to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,`. +> Due to possible attack vectors from Microsoft Entra ID to Active Directory, it's not recommended to unblock these accounts by relaxing the Password Replication Policy of the computer object `CN=AzureADKerberos,OU=Domain Controllers,`. -## Next steps +## Configure Windows Hello for Business policy settings -Once the prerequisites are met, deploying Windows Hello for Business with a cloud Kerberos trust model consists of the following steps: +After setting up the Microsoft Entra Kerberos object, Windows Hello for business must be enabled and configured to use cloud Kerberos trust. There are two policy settings required to configure Windows Hello for Business in a cloud Kerberos trust model: -> [!div class="checklist"] -> * Deploy Microsoft Entra Kerberos -> * Configure Windows Hello for Business settings -> * Provision Windows Hello for Business on Windows clients +- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business) +- [Use cloud trust for on-premises authentication](../policy-settings.md#use-cloud-trust-for-on-premises-authentication) -> [!div class="nextstepaction"] -> [Next: configure and provision Windows Hello for Business >](hybrid-cloud-kerberos-trust-enroll.md) +Another optional, but recommended, policy setting is: + +- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device) + +> [!IMPORTANT] +> If the **Use certificate for on-premises authentication** policy is enabled, certificate trust takes precedence over cloud Kerberos trust. Ensure that the machines that you want to enable cloud Kerberos trust have this policy **not configured**. + +The following instructions explain how to configure your devices using either Microsoft Intune or group policy (GPO). + +# [:::image type="icon" source="images/intune.svg"::: **Intune/CSP**](#tab/intune) + +> [!NOTE] +> Review the article [Configure Windows Hello for Business using Microsoft Intune](../configure.md#configure-windows-hello-for-business-using-microsoft-intune) to learn about the different options offered by Microsoft Intune to configure Windows Hello for Business. + +If the Intune tenant-wide policy is enabled and configured to your needs, you only need to enable the policy setting **Use Cloud Trust For On Prem Auth**. Otherwise, both settings must be configured. + +[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)] + +| Category | Setting name | Value | +|--|--|--| +| **Windows Hello for Business** | Use Passport For Work | true | +| **Windows Hello for Business** | Use Cloud Trust For On Prem Auth | Enabled | +| **Windows Hello for Business** | Require Security Device | true | + +[!INCLUDE [intune-settings-catalog-2](../../../../../includes/configure/intune-settings-catalog-2.md)] + +Alternatively, you can configure devices using a [custom policy][MEM-1] with the [PassportForWork CSP][CSP-1]. + +| Setting | +|--------| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork`
- **Data type:** `bool`
- **Value:** `True`| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UseCloudTrustForOnPremAuth`
- **Data type:** `bool`
- **Value:** `True`| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice`
- **Data type:** `bool`
- **Value:** `True`| + +# [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo) + +[!INCLUDE [gpo-enable-whfb](includes/gpo-enable-whfb.md)] + +> [!NOTE] +> Cloud Kerberos trust requires setting a dedicated policy for it to be enabled. This policy setting is only available as a computer configuration. +> +>You may need to update your Group Policy definitions to be able to configure the cloud Kerberos trust policy. You can copy the ADMX and ADML files from a Windows client that supports cloud Kerberos trust to their respective language folder on your Group Policy management server. Windows Hello for Business settings are in the *Passport.admx* and *Passport.adml* files. +> +>You can also create a Group Policy Central Store and copy them their respective language folder. For more information, see [How to create and manage the Central Store for Group Policy Administrative Templates in Windows][TS-1]. + +[!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**
or
**User Configuration\Administrative Templates\Windows Components\Windows Hello for Business**|Use Windows Hello for Business| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use cloud Kerberos trust for on-premises authentication| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use a hardware security device| **Enabled**| + +[!INCLUDE [gpo-settings-2](../../../../../includes/configure/gpo-settings-2.md)] + +> [!TIP] +> The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all security principals. The security group filtering ensures that only the members of the global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. + +--- + +If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources). + +More policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md). + +## Enroll in Windows Hello for Business + +The Windows Hello for Business provisioning process begins immediately after a user signs in, if the prerequisite checks pass. Windows Hello for Business *cloud Kerberos trust* adds a prerequisite check for Microsoft Entra hybrid joined devices when cloud Kerberos trust is enabled by policy. + +You can determine the status of the prerequisite check by viewing the **User Device Registration** admin log under **Applications and Services Logs** > **Microsoft** > **Windows**.\ +This information is also available using the `dsregcmd.exe /status` command from a console. For more information, see [dsregcmd][AZ-4]. + +The cloud Kerberos trust prerequisite check detects whether the user has a partial TGT before allowing provisioning to start. The purpose of this check is to validate whether Microsoft Entra Kerberos is set up for the user's domain and tenant. If Microsoft Entra Kerberos is set up, the user receives a partial TGT during sign-in with one of their other unlock methods. This check has three states: Yes, No, and Not Tested. The *Not Tested* state is reported if cloud Kerberos trust isn't enforced by policy or if the device is Microsoft Entra joined. + +> [!NOTE] +> The cloud Kerberos trust prerequisite check isn't done on Microsoft Entra joined devices. If Microsoft Entra Kerberos isn't provisioned, a user on a Microsoft Entra joined device will still be able to sign in, but won't have SSO to on-premises resources secured by Active Directory. + +### User experience + +[!INCLUDE [user-experience](includes/user-experience.md)] + +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."] + +Once a user completes enrollment with cloud Kerberos trust, the Windows Hello gesture can be used **immediately** for sign-in. On a Microsoft Entra hybrid joined device, the first use of the PIN requires line of sight to a DC. Once the user signs in or unlocks with the DC, cached sign-in can be used for subsequent unlocks without line of sight or network connectivity. + +After enrollment, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory. + +### Sequence diagrams + +To better understand the provisioning flows, review the following sequence diagrams based on the device join and authentication type: + +- [Provisioning for Microsoft Entra joined devices with managed authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-managed-authentication) +- [Provisioning for Microsoft Entra joined devices with federated authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-federated-authentication) +- [Provisioning in a cloud Kerberos trust deployment model with managed authentication](../how-it-works-provisioning.md#provisioning-in-a-cloud-kerberos-trust-deployment-model-with-managed-authentication) + +To better understand the authentication flows, review the following sequence diagram: + +- [Microsoft Entra join authentication to Active Directory using cloud Kerberos trust](../how-it-works-authentication.md#microsoft-entra-join-authentication-to-active-directory-using-cloud-kerberos-trust) + +## Migrate from key trust deployment model to cloud Kerberos trust + +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-microsoft-entra-kerberos) +1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy-settings) +1. For Microsoft Entra joined devices, sign out and sign in to the device using Windows Hello for Business + +> [!NOTE] +> For Microsoft Entra hybrid joined devices, users must perform the first sign in with new credentials while having line of sight to a DC. + +## Migrate from certificate trust deployment model to cloud Kerberos trust + +> [!IMPORTANT] +> There is no *direct* migration path from a certificate trust deployment to a cloud Kerberos trust deployment. The Windows Hello container must be deleted before you can migrate to cloud Kerberos trust. + +If you deployed Windows Hello for Business using the certificate trust model, and want to use the cloud Kerberos trust model, you must redeploy Windows Hello for Business by following these steps: + +1. Disable the certificate trust policy +1. [Enable cloud Kerberos trust via Group Policy or Intune](#configure-windows-hello-for-business-policy-settings) +1. Remove the certificate trust credential using the command `certutil.exe -deletehellocontainer` from the user context +1. Sign out and sign back in +1. Provision Windows Hello for Business using a method of your choice + +> [!NOTE] +> For Microsoft Entra hybrid joined devices, users must perform the first sign-in with new credentials while having line of sight to a DC. + +## Frequently Asked Questions + +For a list of frequently asked questions about Windows Hello for Business cloud Kerberos trust, see [Windows Hello for Business Frequently Asked Questions](../hello-faq.yml#cloud-kerberos-trust). + +## Unsupported scenarios + +The following scenarios aren't supported using Windows Hello for Business cloud Kerberos trust: + +- 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* +- Signing in with cloud Kerberos trust on a Microsoft Entra hybrid joined device without previously signing in with DC connectivity -[AZ-1]: /azure/active-directory/authentication/howto-authentication-passwordless-security-key-on-premises - +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd +[CSP-1]: /windows/client-management/mdm/passportforwork-csp +[ENTRA-1]: /entra/identity/authentication/howto-authentication-passwordless-security-key-on-premises#install-the-azureadhybridauthenticationmanagement-module +[MEM-1]: /mem/intune/configuration/custom-settings-configure [SERV-1]: /windows-server/administration/performance-tuning/role/active-directory-server/capacity-planning-for-active-directory-domain-services - -[SUP-1]: https://support.microsoft.com/topic/january-23-2020-kb4534307-os-build-14393-3474-b181594e-2c6a-14ea-e75b-678efea9d27e -[SUP-2]: https://support.microsoft.com/topic/january-23-2020-kb4534321-os-build-17763-1012-023e84c3-f9aa-3b55-8aff-d512911c459f +[TS-1]: /troubleshoot/windows-client/group-policy/create-and-manage-central-store diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md index 10b8e56a94..a1686099b6 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-enroll.md @@ -1,165 +1,114 @@ --- -title: Windows Hello for Business hybrid key trust clients configuration and enrollment +title: Configure and enroll in Windows Hello for Business in a hybrid key trust model description: Learn how to configure devices and enroll them in Windows Hello for Business in a hybrid key trust scenario. -ms.date: 01/03/2023 +ms.date: 12/29/2023 ms.topic: tutorial --- -# Configure and enroll in Windows Hello for Business - hybrid key trust +# Configure and enroll in Windows Hello for Business in a hybrid key trust model [!INCLUDE [apply-to-hybrid-key-trust](includes/apply-to-hybrid-key-trust.md)] -After the prerequisites are met and the PKI configuration is validated, Windows Hello for business must be enabled on the Windows devices. Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). - -#### [:::image type="icon" source="images/intune.svg"::: **Intune**](#tab/intune) - -## 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. - -### Enable and configure Windows Hello for Business - -To configure Windows Hello for Business using an *account protection* policy: - -1. Go to the [Microsoft Intune admin center](https://go.microsoft.com/fwlink/?linkid=2109431). -1. Select **Endpoint security** > **Account protection** -1. Select **+ Create Policy** -1. For *Platform**, select **Windows 10 and later** and for *Profile* select **Account protection** -1. Select **Create** -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) -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** -1. Review the policy configuration and select **Create** - -:::image type="content" source="images/whfb-intune-account-protection-enable.png" alt-text="Enablement of Windows Hello for Business from Microsoft Intune admin center using an account protection policy." lightbox="images/whfb-intune-account-protection-enable.png"::: - -#### [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo) - -## Configure Windows Hello for Business using group policies - -For Microsoft Entra hybrid joined devices, you can use group policies to configure Windows Hello for Business. -It's suggested to create a security group (for example, *Windows Hello for Business Users*) to make it easy to deploy Windows Hello for Business in phases. You assign **Group Policy permissions** to this group to simplify the deployment by adding the users to the group. - -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) - -### Enable Windows Hello for Business group policy setting - -The *Enable Windows Hello for Business* group policy setting is the configuration needed for Windows to determine if a user should attempt to enroll for Windows Hello for Business. A user will only attempt enrollment if this policy setting is configured to **enabled**.\ -You can configure the *Enable Windows Hello for Business* setting for computer or users: - -- Deploying this policy setting to computers (or group of computers) results in all users that sign-in that computer to attempt a Windows Hello for Business enrollment -- Deploying this policy setting to a user (or group of users), results in only that user attempting a Windows Hello for Business enrollment - -If both user and computer policy settings are deployed, the user policy setting has precedence. - -### Enable and configure Windows Hello for Business - -Sign-in a domain controller or management workstations 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 *Enable Windows Hello for Business* in the name box and select **OK** -1. In the content pane, right-click the **Enable Windows Hello for Business** group policy object and select **Edit** -1. In the navigation pane, expand **Policies** under **User Configuration** -1. Expand **Administrative Templates > Windows Component**, and select **Windows Hello for Business** -1. In the content pane, open **Use Windows Hello for Business**. Select **Enable > OK** -1. Close the **Group Policy Management Editor** - -> [!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*. +> [!div class="checklist"] +> Once the prerequisites are met and the PKI configuration is validated, deploying Windows Hello for Business consists of the following steps: > -> 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). +> - [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) +> - [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business) -### Configure security for GPO +## Configure Windows Hello for Business policy settings -The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. +There's one policy setting required to enable Windows Hello for Business in a key trust model: -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. Open the **Enable Windows Hello for Business** GPO -1. In the **Security Filtering** section of the content pane, select **Add**. Type the name of the security group you previously created (for example, *Windows Hello for Business Users*) and select **OK** -1. Select the **Delegation** tab. Select **Authenticated Users > Advanced** -1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK** +- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business) -### Deploy the Windows Hello for Business Group Policy object +Another optional, but recommended, policy setting is: -The application of Group Policy object uses security group filtering. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all users. The security group filtering ensures that only the members of the *Windows Hello for Business Users* global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. +- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device) -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 *Enable Windows Hello for Business* or the name of the Windows Hello for Business Group Policy object you previously created and select **OK** +The following instructions describe how to configure your devices using either Microsoft Intune or group policy (GPO). -### Add members to the targeted group +# [:::image type="icon" source="images/intune.svg"::: **Intune/CSP**](#tab/intune) -Users (or devices) must receive the Windows Hello for Business group policy settings and have the proper permission to provision Windows Hello for Business. You can provide users with these settings and permissions by adding members to the *Windows Hello for Business Users* group. Users and groups who aren't members of this group won't attempt to enroll for Windows Hello for Business. +> [!NOTE] +> Review the article [Configure Windows Hello for Business using Microsoft Intune](../configure.md#configure-windows-hello-for-business-using-microsoft-intune) to learn about the different options offered by Microsoft Intune to configure Windows Hello for Business. + +If the Intune 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). + +[!INCLUDE [intune-settings-catalog-1](../../../../../includes/configure/intune-settings-catalog-1.md)] + +| Category | Setting name | Value | +|--|--|--| +| **Windows Hello for Business** | Use Passport For Work | true | +| **Windows Hello for Business** | Require Security Device | true | + +[!INCLUDE [intune-settings-catalog-2](../../../../../includes/configure/intune-settings-catalog-2.md)] + +Alternatively, you can configure devices using a [custom policy][MEM-1] with the [PassportForWork CSP][CSP-1]. + +| Setting | +|--------| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/UsePassportForWork`
- **Data type:** `bool`
- **Value:** `True`| +| - **OMA-URI:** `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/RequireSecurityDevice`
- **Data type:** `bool`
- **Value:** `True`| + +# [:::image type="icon" source="images/group-policy.svg"::: **GPO**](#tab/gpo) + +[!INCLUDE [gpo-enable-whfb](includes/gpo-enable-whfb.md)] + +[!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**
or
**User Configuration\Administrative Templates\Windows Components\Windows Hello for Business**|Use Windows Hello for Business| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use a hardware security device| **Enabled**| + +[!INCLUDE [gpo-settings-2](../../../../../includes/configure/gpo-settings-2.md)] + +> [!TIP] +> The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all security principals. The security group filtering ensures that only the members of the global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. --- +If you deploy Windows Hello for Business configuration using both Group Policy and Intune, Group Policy settings take precedence, and Intune settings are ignored. For more information about policy conflicts, see [Policy conflicts from multiple policy sources](../configure.md#policy-conflicts-from-multiple-policy-sources) + +Other policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md). + ## Enroll in Windows Hello for Business The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass. You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > Windows**.\ -This information is also available using the `dsregcmd /status` command from a console. For more information, see [dsregcmd][AZ-4]. +This information is also available using the `dsregcmd.exe /status` command from a console. For more information, see [dsregcmd][AZ-4]. :::image type="content" source="images/Event358.png" alt-text="Details about event ID 358 showing that the device is ready to enroll in Windows Hello for Business." border="false" lightbox="images/Event358.png"::: -### PIN Setup +### User experience -The following process occurs after a user signs in, to enroll in Windows Hello for Business: +[!INCLUDE [user-experience](includes/user-experience.md)] -1. The user is prompted with a full screen page to use Windows Hello with the organization account. The user selects **OK** -1. The enrollment flow proceeds to the multi-factor authentication phase. The process informs the user that there's an MFA contact attempt, using the configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry -1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device -1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with Microsoft Entra ID to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and see their desktop. While the user has completed provisioning, Microsoft Entra Connect synchronizes the user's key to Active Directory +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."] -:::image type="content" source="images/haadj-whfb-pin-provisioning.gif" alt-text="Animation showing a user logging on to an HAADJ device with a password, and being prompted to enroll in Windows Hello for Business."::: +After enrollment, Microsoft Entra Connect synchronizes the user's key from Microsoft Entra ID to Active Directory. > [!IMPORTANT] > The minimum time needed to synchronize the user's public key from Microsoft Entra ID to the on-premises Active Directory is 30 minutes. The Microsoft Entra Connect scheduler controls the synchronization interval. -> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and use on-premises resources. +> **This synchronization latency delays the user's ability to authenticate and use on-premises resources until the user's public key has synchronized to Active Directory.** Once synchronized, the user can authenticate and access on-premises resources. > Read [Microsoft Entra Connect Sync: Scheduler][AZ-5] to view and adjust the **synchronization cycle** for your organization. +### Sequence diagrams + +To better understand the provisioning flows, review the following sequence diagrams based on the device join and authentication type: + +- [Provisioning for Microsoft Entra joined devices with managed authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-managed-authentication) +- [Provisioning for Microsoft Entra joined devices with federated authentication](../how-it-works-provisioning.md#provisioning-for-microsoft-entra-joined-devices-with-federated-authentication) +- [Provisioning in a hybrid key trust deployment model with managed authentication](../how-it-works-provisioning.md#provisioning-in-a-hybrid-key-trust-deployment-model-with-managed-authentication) + +To better understand the authentication flows, review the following sequence diagram: + +- [Microsoft Entra hybrid join authentication using a key](../how-it-works-authentication.md#microsoft-entra-hybrid-join-authentication-using-a-key) +- [Microsoft Entra join authentication to Active Directory using a key](../how-it-works-authentication.md#microsoft-entra-join-authentication-to-active-directory-using-a-key) + [AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd [AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler - -[MEM-1]: /mem/intune/configuration/settings-catalog -[MEM-2]: /mem/intune/protect/security-baselines -[MEM-3]: /mem/intune/configuration/custom-settings-configure -[MEM-4]: /windows/client-management/mdm/passportforwork-csp -[MEM-5]: /mem/intune/protect/endpoint-security-account-protection-policy -[MEM-6]: /mem/intune/protect/identity-protection-configure +[CSP-1]: /windows/client-management/mdm/passportforwork-csp +[MEM-1]: /mem/intune/configuration/custom-settings-configure diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-pki.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-pki.md deleted file mode 100644 index 2fa08c15c9..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust-pki.md +++ /dev/null @@ -1,107 +0,0 @@ ---- -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -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)] - -Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. 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. - -Key trust deployments do not need client-issued certificates for on-premises authentication. Active Directory user accounts are configured for public key mapping by *Microsoft Entra Connect Sync*, which synchronizes the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink`). - -A Windows Server-based PKI or a third-party Enterprise certification authority can be used. The requirements for the domain controller certificate are shown below. For more details, see [Requirements for domain controller certificates from a third-party CA][SERV-1]. - -## Deploy an enterprise certification authority - -This guide assumes most enterprises have an existing public key infrastructure. Windows Hello for Business depends on an enterprise PKI running the Windows Server *Active Directory Certificate Services* role.\ -If you don't have an existing PKI, review [Certification Authority Guidance][PREV-1] to properly design your infrastructure. Then, consult the [Test Lab Guide: Deploying an AD CS Two-Tier PKI Hierarchy][PREV-2] for instructions on how to configure your PKI using the information from your design session. - -### Lab-based PKI - -The following instructions may be used to deploy simple public key infrastructure that is suitable **for a lab environment**. - -Sign in using *Enterprise Administrator* equivalent credentials on a Windows Server where you want the certification authority (CA) installed. - ->[!NOTE] ->Never install a certification authority on a domain controller in a production environment. - -1. Open an elevated Windows PowerShell prompt -1. Use the following command to install the Active Directory Certificate Services role. - ```PowerShell - Add-WindowsFeature Adcs-Cert-Authority -IncludeManagementTools - ``` -1. Use the following command to configure the CA using a basic certification authority configuration - ```PowerShell - Install-AdcsCertificationAuthority - ``` - -## Configure the enterprise PKI - -[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.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. - -> [!IMPORTANT] -> For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to: -> -> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune -> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL - -[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] - -[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] - -### Publish the certificate template to the CA - -A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. - -Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. - -1. Open the **Certification Authority** management console -1. Expand the parent node from the navigation pane -1. Select **Certificate Templates** in the navigation pane -1. Right-click the **Certificate Templates** node. Select **New > Certificate Template to issue** -1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)* template you created in the previous steps > select **OK** -1. Close the console - -> [!IMPORTANT] -> If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](../hello-hybrid-aadj-sso.md). - -## Configure and deploy certificates to domain controllers - -[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] - -## Validate the configuration - -[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] - -## Section review and next steps - -Before moving to the next section, ensure the following steps are complete: - -> [!div class="checklist"] -> -> - Configure domain controller certificates -> - Supersede existing domain controller certificates -> - Unpublish superseded certificate templates -> - Publish the certificate template to the CA -> - Deploy certificates to the domain controllers -> - Validate the domain controllers configuration - -> [!div class="nextstepaction"] -> [Next: configure and provision Windows Hello for Business >](hybrid-key-trust-enroll.md) - - -[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller -[PREV-1]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831574(v=ws.11) -[PREV-2]: /previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/hh831348(v=ws.11) diff --git a/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust.md index 2b0ec7021d..e5a08f2117 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/hybrid-key-trust.md @@ -1,109 +1,93 @@ --- -title: Windows Hello for Business hybrid key trust deployment +title: Windows Hello for Business hybrid key trust deployment guide description: Learn how to deploy Windows Hello for Business in a hybrid key trust scenario. -ms.date: 12/28/2022 -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -ms.topic: how-to +ms.date: 01/03/2024 +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. - > [!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: +[!INCLUDE [requirements](includes/requirements.md)] > [!div class="checklist"] -> * Directories and directory synchronization -> * Authentication to Microsoft Entra ID -> * Device registration -> * Public Key Infrastructure -> * Multifactor authentication -> * Device management +> +> - [Public Key Infrastructure](index.md#pki-requirements) +> - [Authentication](index.md#authentication-to-microsoft-entra-id) +> - [Device configuration](index.md#device-configuration-options) +> - [Prepare users to use Windows Hello](prepare-users.md) -### Directories and directory synchronization - -Hybrid Windows Hello for Business needs two directories: - -- An on-premises Active Directory -- A Microsoft Entra tenant - -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.\ -During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Microsoft Entra ID. *Microsoft Entra Connect Sync* synchronizes the Windows Hello for Business public key to Active Directory. - -> [!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. - - - -### Authentication to Microsoft Entra ID - -Authentication to Microsoft Entra ID can be configured with or without federation: - -- [Password hash synchronization][AZ-6] or [Microsoft Entra pass-through authentication][AZ-7] is required for non-federated environments -- Active Directory Federation Services (AD FS) or a third-party federation service is required for federated environments - -### Device registration - -The Windows devices must be registered in Microsoft Entra ID. Devices can be registered in Microsoft Entra ID using either *Microsoft Entra join* or *Microsoft Entra hybrid join*.\ -For *Microsoft Entra hybrid joined* devices, review the guidance on the [Plan your Microsoft Entra hybrid join implementation][AZ-8] page. - -### Public Key Infrastructure - -An enterprise PKI is required as *trust anchor* for authentication. Domain controllers require a certificate for Windows clients to trust them. - - - -### 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.\ -Hybrid deployments can use: - -- [Microsoft Entra multifactor authentication][AZ-2] -- A multifactor authentication provided by AD FS, which includes an adapter model that enables third parties to integrate their MFA into AD FS - -For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][AZ-3].\ -For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. - -### Device management - -To configure Windows Hello for Business, devices can be configured through a mobile device management (MDM) solution like Intune, or via group policy. - -## Next steps - -Once the prerequisites are met, deploying Windows Hello for Business with a hybrid key trust model consists of the following steps: +## Deployment 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 consists of the following steps: +> +> - [Configure and validate the Public Key Infrastructure](#configure-and-validate-the-public-key-infrastructure) +> - [Configure and enroll in Windows Hello for Business](hybrid-key-trust-enroll.md) +> - (optional) [Configure single sign-on for Microsoft Entra joined devices](../hello-hybrid-aadj-sso.md) + +## Configure and validate the Public Key Infrastructure + +Windows Hello for Business must have a Public Key Infrastructure (PKI) when using the *key trust* model. 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. + +Key trust deployments don't need client-issued certificates for on-premises authentication. *Microsoft Entra Connect Sync* configures Active Directory user accounts for public key mapping, by synchronizing the public key of the Windows Hello for Business credential to an attribute on the user's Active Directory object (`msDS-KeyCredentialLink` attribute). + +A Windows Server-based PKI or a third-party Enterprise certification authority can be used. For more information, see [Requirements for domain controller certificates from a third-party CA][SERV-1]. + +[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] + +## Configure the enterprise PKI + +[!INCLUDE [dc-certificate-template](includes/certificate-template-dc.md)] + +[!INCLUDE [dc-certificate-template-dc-hybrid-notes](includes/certificate-template-dc-hybrid-notes.md)] + +[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] + +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] + +### Publish the certificate template to the CA + +A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. + +Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. + +1. Open the **Certification Authority** management console +1. Expand the parent node from the navigation pane +1. Select **Certificate Templates** in the navigation pane +1. Right-click the **Certificate Templates** node. Select **New > Certificate Template to issue** +1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)* template you created in the previous steps > select **OK** +1. Close the console + +> [!IMPORTANT] +> If you plan to deploy **Microsoft Entra joined** devices, and require single sign-on (SSO) to on-premises resources when signing in with Windows Hello for Business, follow the procedures to [update your CA to include an http-based CRL distribution point](../hello-hybrid-aadj-sso.md). + +## Configure and deploy certificates to domain controllers + +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] + +## Validate the configuration + +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] + +## Section review and next steps + +> [!div class="checklist"] +> Before moving to the next section, ensure the following steps are complete: +> +> - Configure domain controller certificate template +> - Supersede existing domain controller certificates +> - Unpublish superseded certificate templates +> - Publish the certificate template to the CA +> - Deploy certificates to the domain controllers +> - Validate the domain controllers configuration > [!div class="nextstepaction"] -> [Next: configure and validate the Public Key Infrastructure >](hybrid-key-trust-pki.md) +> [Next: configure and enroll in Windows Hello for Business >](hybrid-key-trust-enroll.md) -[AZ-1]: /azure/active-directory/hybrid/how-to-connect-sync-whatis -[AZ-2]: /azure/multi-factor-authentication/multi-factor-authentication -[AZ-3]: /azure/multi-factor-authentication/multi-factor-authentication-whats-next -[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd -[AZ-5]: /azure/active-directory/connect/active-directory-aadconnectsync-feature-scheduler -[AZ-6]: /azure/active-directory/hybrid/whatis-phs -[AZ-7]: /azure/active-directory/connect/active-directory-aadconnect-pass-through-authentication -[AZ-8]: /azure/active-directory/devices/hybrid-azuread-join-plan - -[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa +[SERV-1]: /troubleshoot/windows-server/windows-security/requirements-domain-controller diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/cloud-trust-prereq-check.png b/windows/security/identity-protection/hello-for-business/deploy/images/cloud-trust-prereq-check.png deleted file mode 100644 index f327f79f32..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/deploy/images/cloud-trust-prereq-check.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/group-policy.svg b/windows/security/identity-protection/hello-for-business/deploy/images/group-policy.svg index ace95add6b..c9cb511415 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/images/group-policy.svg +++ b/windows/security/identity-protection/hello-for-business/deploy/images/group-policy.svg @@ -1,3 +1,9 @@ - - - \ No newline at end of file + + + + + + + + + diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/haadj-whfb-pin-provisioning.gif b/windows/security/identity-protection/hello-for-business/deploy/images/haadj-whfb-pin-provisioning.gif deleted file mode 100644 index 7bff02eada..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/deploy/images/haadj-whfb-pin-provisioning.gif and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune-large.png b/windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune-large.png deleted file mode 100644 index e9d0876738..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune-large.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune.png b/windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune.png deleted file mode 100644 index fd6644b8b7..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/deploy/images/hello-cloud-trust-intune.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-cert-enable.png b/windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-cert-enable.png deleted file mode 100644 index ec2ba07684..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-cert-enable.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-enable.png b/windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-enable.png deleted file mode 100644 index b5ff9bbb58..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/deploy/images/whfb-intune-account-protection-enable.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-additional-servers.md b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-additional-servers.md new file mode 100644 index 0000000000..04964c59b0 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-additional-servers.md @@ -0,0 +1,95 @@ +--- +ms.date: 01/03/2024 +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 `` 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. [!NOTE] +> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.` 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** diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-deploy.md b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-deploy.md new file mode 100644 index 0000000000..acbd3a6a42 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-deploy.md @@ -0,0 +1,95 @@ +--- +ms.date: 01/03/2024 +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."::: \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-mfa.md b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-mfa.md similarity index 56% rename from windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-mfa.md rename to windows/security/identity-protection/hello-for-business/deploy/includes/adfs-mfa.md index bcc3c3b497..e9f18f3925 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-mfa.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-mfa.md @@ -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -ms.topic: tutorial +ms.date: 01/03/2024 +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) diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-validate.md b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-validate.md new file mode 100644 index 0000000000..2e56e0614a --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/adfs-validate.md @@ -0,0 +1,47 @@ +--- +ms.date: 01/03/2024 +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. diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-cloud.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-cloud.md index 69c159b0a2..5e7aad158e 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-cloud.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-cloud.md @@ -1,9 +1,9 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- [!INCLUDE [intro](intro.md)] - **Deployment type:** [!INCLUDE [tooltip-deployment-cloud](tooltip-deployment-cloud.md)] - **Join type:** [!INCLUDE [tootip-join-entra](tooltip-join-entra.md)] ---- \ No newline at end of file +--- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust-entra.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust-entra.md index 31073eae23..b36534846f 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust-entra.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust-entra.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust.md index 4f8eb7e613..9e61b4c795 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cert-trust.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cloud-kerberos-trust.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cloud-kerberos-trust.md index 9fd4c16a63..0c93b4c352 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cloud-kerberos-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-cloud-kerberos-trust.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- @@ -7,4 +7,4 @@ ms.topic: include - **Deployment type:** [!INCLUDE [tooltip-deployment-hybrid](tooltip-deployment-hybrid.md)] - **Trust type:** [!INCLUDE [tooltip-trust-cloud-kerberos](tooltip-trust-cloud-kerberos.md)] - **Join type:** [!INCLUDE [tooltip-join-entra](tooltip-join-entra.md)], [!INCLUDE [tooltip-join-hybrid](tooltip-join-hybrid.md)] ---- \ No newline at end of file +--- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-and-cert-trust.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-and-cert-trust.md index 1a17ea9d1f..427b68841d 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-and-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-and-cert-trust.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-trust.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-trust.md index a74e9ead78..f3f5b968e1 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-hybrid-key-trust.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust-entra.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust.md similarity index 92% rename from windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust-entra.md rename to windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust.md index e3c6bad7b3..ea1dc22c2d 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust-entra.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-cert-trust.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- @@ -7,4 +7,4 @@ ms.topic: include - **Deployment type:** [!INCLUDE [tooltip-deployment-onpremises](tooltip-deployment-onpremises.md)] - **Trust type:** [!INCLUDE [tooltip-cert-trust](tooltip-trust-cert.md)] - **Join type:** [!INCLUDE [tooltip-join-domain](tooltip-join-domain.md)] ---- \ No newline at end of file +--- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-key-trust.md b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-key-trust.md index 1966807ca5..c7a85a3e1d 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/apply-to-on-premises-key-trust.md @@ -1,5 +1,5 @@ --- -ms.date: 12/08/2022 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/auth-certificate-template.md b/windows/security/identity-protection/hello-for-business/deploy/includes/auth-certificate-template.md deleted file mode 100644 index c3f30f246e..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/auth-certificate-template.md +++ /dev/null @@ -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<[!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. - - \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-auth.md b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-auth.md new file mode 100644 index 0000000000..aab8d0e4c9 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-auth.md @@ -0,0 +1,64 @@ +--- +ms.date: 01/03/2024 +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* |
  • Clear the **Show resulting changes** check box
  • Select **Windows Server 2016** from the *Certification Authority list*
  • Select **Windows 10 / Windows Server 2016** from the *Certification Recipient list*
| + | *General* |
  • Specify a **Template display name**, for example *WHFB Authentication*
  • Set the validity period to the desired value
  • Take note of the template name for later, which should be the same as the Template display name minus spaces
| + | *Subject Name* |
  • Select **Build from this Active Directory information**
  • 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**
| + |*Cryptography*|
  • Set the *Provider Category* to **Key Storage Provider**
  • Set the *Algorithm name* to **RSA**
  • Set the *minimum key size* to **2048**
  • Set the *Request hash* to **SHA256**
    • | + |*Extensions*|Verify the **Application Policies** extension includes **Smart Card Logon**| + |*Issuance Requirements*|
    • 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
    | + |*Request Handling*|Select the **Renew with same key** check box| + |*Security*|
    • 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**
    • 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. 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<[!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. diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc-hybrid-notes.md b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc-hybrid-notes.md new file mode 100644 index 0000000000..7024a9071d --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc-hybrid-notes.md @@ -0,0 +1,13 @@ +--- +ms.date: 01/03/2024 +ms.topic: include +--- + +> [!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. + +> [!IMPORTANT] +> For Microsoft Entra joined devices to authenticate to on-premises resources, ensure to: +> +> - Install the root CA certificate in the device's trusted root certificate store. See [how to deploy a trusted certificate profile](/mem/intune/protect/certificates-trusted-root#to-create-a-trusted-certificate-profile) via Intune +> - Publish your certificate revocation list to a location that is available to Microsoft Entra joined devices, such as a web-based URL diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-template.md b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc.md similarity index 99% rename from windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-template.md rename to windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc.md index 9c85020231..422ff72167 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-template.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-dc.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-enrollment-agent.md b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-enrollment-agent.md new file mode 100644 index 0000000000..b43c9f754a --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-enrollment-agent.md @@ -0,0 +1,53 @@ +--- +ms.date: 01/03/2024 +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* |
    • Clear the **Show resulting changes** check box
    • Select **Windows Server 2016** from the *Certification Authority list*
    • Select **Windows 10 / Windows Server 2016** from the *Certification Recipient list*
    | + | *General* |
    • Specify a **Template display name**, for example *WHFB Enrollment Agent*
    • Set the validity period to the desired value
    | + | *Subject Name* | Select **Supply in the request**

    **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* |
    • Set the *Provider Category* to **Key Storage Provider**
    • Set the *Algorithm name* to **RSA**
    • Set the *minimum key size* to **2048**
    • Set the *Request hash* to **SHA256**
      • | + | *Security* |
      • Select **Add**
      • Select **Object Types** and select the **Service Accounts** check box
      • Select **OK**
      • Type `adfssvc` in the **Enter the object names to select** text box and select **OK**
      • 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. 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* |
      • 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
      | + | *General* |
      • Specify a **Template display name**, for example *WHFB Enrollment Agent*
      • Set the validity period to the desired value
      | + | *Subject Name* |
      • Select **Build from this Active Directory information**
      • 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**
      | + |*Cryptography*|
      • Set the *Provider Category* to **Key Storage Provider**
      • Set the *Algorithm name* to **RSA**
      • Set the *minimum key size* to **2048**
      • Set the *Request hash* to **SHA256**
      | + | *Security* |
      • Select **Add**
      • Select **Object Types** and select the **Service Accounts** check box
      • Select **OK**
      • Type `adfssvc` in the **Enter the object names to select** text box and select **OK**
      • 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. Select **OK** to finalize your changes and create the new template +1. Close the console diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/web-server-certificate-template.md b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-web-server.md similarity index 98% rename from windows/security/identity-protection/hello-for-business/deploy/includes/web-server-certificate-template.md rename to windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-web-server.md index 1bde4860fe..c75a03a96f 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/web-server-certificate-template.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/certificate-template-web-server.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-deployment.md b/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-deployment.md index 07d8c9cc38..77fad7cbbf 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-deployment.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-deployment.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- @@ -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** - diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-supersede.md b/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-supersede.md index 92853ac52e..e2d6f588de 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-supersede.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-supersede.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-validate.md b/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-validate.md index ec0faae68f..87e7467d71 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-validate.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/dc-certificate-validate.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- @@ -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. \ No newline at end of file +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. \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/enrollment-agent-certificate-template.md b/windows/security/identity-protection/hello-for-business/deploy/includes/enrollment-agent-certificate-template.md deleted file mode 100644 index 8e3cfc064b..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/enrollment-agent-certificate-template.md +++ /dev/null @@ -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 - diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/gpo-enable-whfb.md b/windows/security/identity-protection/hello-for-business/deploy/includes/gpo-enable-whfb.md new file mode 100644 index 0000000000..4a2a01ac0b --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/gpo-enable-whfb.md @@ -0,0 +1,11 @@ +--- +ms.date: 01/03/2024 +ms.topic: include +--- + +You can configure the [Use Windows Hello for Business](../../policy-settings.md#use-windows-hello-for-business) policy setting in the computer or user node of a GPO: + +- Deploying the computer node policy setting, results in all users that sign-in to the targeted devices to attempt a Windows Hello for Business enrollment +- Deploying the user node policy setting, results in only the targeted users to attempt a Windows Hello for Business enrollment + +If both user and computer policy settings are deployed, the user policy setting has precedence. diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/intro.md b/windows/security/identity-protection/hello-for-business/deploy/includes/intro.md index 89062e7d07..6f98abf51b 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/intro.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/intro.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- -This document describes Windows Hello for Business functionalities or scenarios that apply to: \ No newline at end of file +**This article describes Windows Hello for Business functionalities or scenarios that apply to:** \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/lab-based-pki-deploy.md b/windows/security/identity-protection/hello-for-business/deploy/includes/lab-based-pki-deploy.md index 2ccadb00cb..c0ad0664a4 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/lab-based-pki-deploy.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/lab-based-pki-deploy.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/requirements.md b/windows/security/identity-protection/hello-for-business/deploy/includes/requirements.md new file mode 100644 index 0000000000..86a5353764 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/requirements.md @@ -0,0 +1,10 @@ +--- +ms.date: 01/03/2024 +ms.topic: include +--- + +## Requirements + +Before starting the deployment, review the requirements described in the [Plan a Windows Hello for Business Deployment](../index.md) article. + +Ensure that the following requirements are met before you begin: diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-cloud.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-cloud.md index fa5e9a3489..128a9cd1a5 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-cloud.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-cloud.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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-only :::image type="icon" source="../images/information.svg" border="false":::](../index.md#deployment-models "For organizations using Microsoft Entra-only identities. Device management is usually done via Intune/MDM") diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-hybrid.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-hybrid.md index d273002ddd..7ebb44bfc0 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-hybrid.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-hybrid.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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":::](../index.md#deployment-models "For organizations using Active Directory identities synchronized to Microsoft Entra ID. Device management is usually done via Group Policy or Intune/MDM") diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-onpremises.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-onpremises.md index 5594bf39dd..6406e82fc4 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-onpremises.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-deployment-onpremises.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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":::](../index.md#deployment-models "For organizations using Active Directory identities, not synchronized to Microsoft Entra ID. Device management is usually done via Group Policy") diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-domain.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-domain.md index 5e4dd851b9..512be88987 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-domain.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-domain.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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":::](../index.md "Devices that are Active Directory joined don't have any dependencies on Microsoft Entra ID. Only local users accounts and Active Directory users can sign in to these devices") diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-entra.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-entra.md index dbddf38006..05bbdd63e1 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-entra.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-entra.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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":::](../index.md "Devices that are Microsoft Entra joined don't have any dependencies on Active Directory. Only local users accounts and Microsoft Entra users can sign in to these devices") diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-hybrid.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-hybrid.md index 206857ace8..b878a41559 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-hybrid.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-join-hybrid.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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":::](../index.md "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 have single-sign on to both Active Directory and Microsoft Entra protected resources") diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cert.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cert.md index 8719e2a1cc..17ffcc98b4 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cert.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cert.md @@ -1,6 +1,6 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 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") \ No newline at end of file +[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") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cloud-kerberos.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cloud-kerberos.md index 57fd74f5c3..58bad86a1c 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cloud-kerberos.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-cloud-kerberos.md @@ -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") \ No newline at end of file +[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") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-key.md b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-key.md index 3bbbe2214f..41d9b6cdf9 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-key.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/tooltip-trust-key.md @@ -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") \ No newline at end of file +[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") \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/unpublish-superseded-templates.md b/windows/security/identity-protection/hello-for-business/deploy/includes/unpublish-superseded-templates.md index 22db188040..94d2e088de 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/includes/unpublish-superseded-templates.md +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/unpublish-superseded-templates.md @@ -1,5 +1,5 @@ --- -ms.date: 12/15/2023 +ms.date: 01/03/2024 ms.topic: include --- diff --git a/windows/security/identity-protection/hello-for-business/deploy/includes/user-experience.md b/windows/security/identity-protection/hello-for-business/deploy/includes/user-experience.md new file mode 100644 index 0000000000..e8185673e6 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/includes/user-experience.md @@ -0,0 +1,12 @@ +--- +ms.date: 01/03/2024 +ms.topic: include +--- + +After a user signs in, the Windows Hello for Business enrollment process begins: + +1. If the device supports biometric authentication, the user is prompted to set up a biometric gesture. This gesture can be used to unlock the device and authenticate to resources that require Windows Hello for Business. The user can skip this step if they don't want to set up a biometric gesture +1. The user is prompted to use Windows Hello with the organization account. The user selects **OK** +1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry +1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device +1. The remainder of the provisioning includes Windows Hello for Business requesting an asymmetric key pair for the user, preferably from the TPM (or required if explicitly set through policy). Once the key pair is acquired, Windows communicates with the IdP to register the public key. When key registration completes, Windows Hello for Business provisioning informs the user they can use their PIN to sign-in. The user may close the provisioning application and access their desktop diff --git a/windows/security/identity-protection/hello-for-business/deploy/index.md b/windows/security/identity-protection/hello-for-business/deploy/index.md index 46c44a5c62..061c4a62e1 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/index.md +++ b/windows/security/identity-protection/hello-for-business/deploy/index.md @@ -1,65 +1,310 @@ --- -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: 01/02/2024 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 available for deploying Windows Hello for Business, ensuring compatibility with various organizational infrastructures. While the deployment process may appear complex, most organizations will find that they have already implemented the necessary infrastructure. It is important to note that Windows Hello for Business is a distributed system and requires 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 aims to simplify the deployment process by helping you make informed decisions about each aspect of your Windows Hello for Business deployment. It provides information on the options available and assists in selecting the deployment approach 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 to evaluate the available options and to determine requirements for your Windows Hello for Business deployment. -## Deployment and trust models +There are seven main areas to consider when planning 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*. +> [!div class="checklist"] +> +> - [Deployment options](#deployment-options) +> - [Public Key Infrastructure (PKI) requirements](#pki-requirements) +> - [Authentication to Microsoft Entra ID requirements](#authentication-to-microsoft-entra-id) +> - [Device configuration options](#device-configuration-options) +> - [Licensing for cloud services requirements](#licensing-for-cloud-services-requirements) +> - [Operating System requirements](#operating-system-requirements) +> - [Prepare users](#prepare-users) -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 might 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) +| | Deployment model | Description | +|--|--|--| +| **🔲** | **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. | +| **🔲** | **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 single sign-on (SSO) experience for both on-premises and Microsoft Entra resources. | +| **🔲** | **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 an 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**. The trust type doesn't affect authentication to Microsoft Entra ID. 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. +Windows Hello for Business authentication to Microsoft Entra ID always uses the key, not a certificate (excluding smart card authentication in a federated environment). + +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. More infrastructure needed for certificate-trust deployments includes a certificate registration authority. In a federated environment, you must activate the Device Writeback option in Microsoft Entra Connect. + +There are three trust types from which you can choose: + +|| Trust type | Description | +|--|--|--| +| **🔲**| **Cloud Kerberos**| 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. | +| **🔲**| **Key**| Users authenticate to the on-premises Active Directory using a device-bound key (hardware or software) created during the Windows Hello provisioning experience. It requires to distribute certificates to domain controllers. | +| **🔲**| **Certificate**| The certificate trust type issues authentication certificates to users. Users authenticate using a certificate requested using a device-bound key (hardware or software) created during the Windows Hello provisioning experience. | + +*Key trust* and *certificate trust* use certificate authentication-based Kerberos when 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 simpler deployment experience, when compared to the other trust types: + +- 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][ENTRA-1] can be deployed with minimal extra setup + +> [!TIP] +> 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. + +Cloud Kerberos trust requires the deployment of Microsoft Entra Kerberos. 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][ENTRA-1]. + +## PKI requirements + +Cloud Kerberos trust is the only hybrid deployment option that doesn't require the deployment of any certificates. The other hybrid and on-premises 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 + +| | Deployment model | Trust type | PKI required? | +|--|--|--|--| +| **🔲** | **Cloud-only** | n/a | no | +| **🔲** | **Hybrid** | Cloud Kerberos | no | +| **🔲** | **Hybrid** | Key | yes | +| **🔲** | **Hybrid** | Certificate | yes | +| **🔲** | **On-premises** | Key | yes | +| **🔲** | **On-premises** | Certificate | yes | + +## Authentication to Microsoft Entra ID + +Users can authenticate to Microsoft Entra ID using federated authentication or cloud (nonfederated) authentication. Requirements vary based on trust type: + +| | Deployment model | Trust type | Authentication to Microsoft Entra ID | Requirements | +|--|--|--|--|--| +| **🔲** | **Cloud-only** | n/a | Cloud authentication | n/a | +| **🔲** | **Cloud-only** | n/a | Federated authentication | Third-party federation service | +| **🔲** | **Hybrid** | Cloud Kerberos trust | Cloud authentication | Password hash sync (PHS) or Pass-through authentication (PTA) | +| **🔲** | **Hybrid** | Cloud Kerberos trust | Federated authentication | AD FS or third-party federation service | +| **🔲** | **Hybrid** | Key trust | Cloud authentication | Password hash sync (PHS) or Pass-through authentication (PTA) | +| **🔲** | **Hybrid** | Key trust | Federated authentication | AD FS or third-party federation service | +| **🔲** | **Hybrid** | Certificate trust | Federated authentication | This deployment model doesn't support PTA or PHS. Active Directory must be federated with Microsoft Entra ID using AD FS| + +To learn more: + +- [Federation with Microsoft Entra ID][ENTRA-10] +- [Password hash synchronization (PHS)][ENTRA-6] +- [Pass-through authentication (PTA)][ENTRA-7] + +### Device registration + +For on-premises deployments, the server running the Active Directory Federation Services (AD FS) role is responsible for device registration. For cloud-only and hybrid deployments, devices must register in Microsoft Entra ID. + +| Deployment model | Supported join type | Device registration service provider | +|-|-|-| +| **Cloud-only** |Microsoft Entra joined
      Microsoft Entra registered|Microsoft Entra ID | +| **Hybrid** |Microsoft Entra joined
      Microsoft Entra hybrid joined
      Microsoft Entra registered|Microsoft Entra ID| +| **On-premises** | Active Directory domain joined | AD FS | + +> [!IMPORTANT] +> For *Microsoft Entra hybrid joined* guidance, review [Plan your Microsoft Entra hybrid join implementation][ENTRA-5]. + +### 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, there 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 information, see [Microsoft and third-party additional authentication methods][SER-2] + +> [!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. For more information, see [Getting started with the Azure Multi-Factor Authentication Server][ENTRA-2]. + +|| Deployment model | MFA options | +|--|--|--| +| **🔲** | **Cloud-only** | Microsoft Entra MFA | +| **🔲** | **Cloud-only** | Third-party MFA via Microsoft Entra ID custom controls or federation | +| **🔲** | **Hybrid** | Microsoft Entra MFA | +| **🔲** | **Hybrid** | Third-party MFA via Microsoft Entra ID custom controls or federation| +| **🔲** | **On-premises** | AD FS MFA adapter | + +For more information how to configure Microsoft Entra multifactor authentication, see [Configure Microsoft Entra multifactor authentication settings][ENTRA-4]. + +For more information how to configure AD FS to provide multifactor authentication, see [Configure Azure MFA as authentication provider with AD FS][SER-1]. + +#### MFA and federated authentication + +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: + +```powershell +Connect-MgGraph +$DomainId = "" +Get-MgDomainFederationConfiguration -DomainId $DomainId |fl +``` + +To reject the MFA claim from the federated IdP, use the following command. This change impacts all MFA scenarios for the federated domain: + +```powershell +Update-MgDomainFederationConfiguration -DomainId $DomainId -FederatedIdpMfaBehavior rejectMfaByFederatedIdp +``` + +If you configure the flag with a value of either `acceptIfMfaDoneByFederatedIdp` (default) or `enforceMfaByFederatedIdp`, you must verify that your federated IDP is correctly configured and working with the MFA adapter and provider used by your IdP. + +### Key registration + +The built-in Windows Hello for Business provisioning experience creates a device-bound asymmetric key pair as the 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: + +| Deployment model | Key registration service provider | +|-|-| +| **Cloud-only** | Microsoft Entra ID | +| **Hybrid** | Microsoft Entra ID | +| **On-premises** | AD FS | + +### Directory synchronization + +Hybrid and on-premises deployments use directory synchronization, however, each for a different purpose: + +- Hybrid deployments use [Microsoft Entra Connect Sync][ENTRA-3] to synchronize Active Directory identities (users and devices) or credentials between itself and Microsoft Entra ID. During the Window Hello for Business provisioning process, users register the public portion of their Windows Hello for Business credential with Microsoft Entra ID. Microsoft Entra Connect Sync synchronizes the Windows Hello for Business public key to Active Directory. This synchronization enables SSO to Microsoft Entra ID and its federated components. + > [!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. +- On-premises deployments use directory synchronization to import users from Active Directory to the Azure MFA server, which sends data to the MFA cloud service to perform the verification + +| Deployment model | Directory sync options | +|-|-| +| **Cloud-only** | n/a | +| **Hybrid** | Microsoft Entra Connect Sync| +| **On-premises** | Azure MFA server | + +## Device configuration options + +Windows Hello for Business provides a rich set of granular policy settings. 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. CSPs can also be configured with [provisioning packages][WIN-1] +- GPO can be used to configure domain joined devices and where devices aren't managed via MDM + +|| Deployment model | Device configuration options| +|--|--|--| +| **🔲** | **Cloud-only** | CSP | +| **🔲** | **Cloud-only** | GPO (local) | +| **🔲** | **Hybrid** | CSP | +| **🔲** | **Hybrid** | GPO (Active Directory or local) | +| **🔲** | **On-premises** | CSP | +| **🔲** | **On-premises** | GPO (Active Directory or local) | + +## Licensing for cloud services requirements + +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-1] and [Conditional Access][ENTRA-8] 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 for the Windows passwordless features + - Some Microsoft Entra multifactor authentication features require a license. For more information, see [Features and licenses for Microsoft Entra multifactor authentication][ENTRA-9]. +- 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 + +|| Deployment model | Trust type | Cloud services licenses (minimum)| +|--|--|--|--| +| **🔲** | **Cloud-only** | n/a | not required | +| **🔲** | **Hybrid** | Cloud Kerberos | not required | +| **🔲** | **Hybrid** | Key| not required | +| **🔲** | **Hybrid** | Certificate | Microsoft Entra ID P1 | +| **🔲** | **On-premises** | Key | Azure MFA, if used as MFA solution | +| **🔲** | **On-premises** | Certificate | Azure MFA, if used as MFA solution | + +## Operating System requirements + +### Windows requirements + +All supported Windows versions can be used with Windows Hello for Business. However, cloud Kerberos trust requires minimum versions: + +|| Deployment model | Trust type | Windows version| +|--|--|--|--| +| **🔲** | **Cloud-only** | n/a | All supported versions | +| **🔲** | **Hybrid** | Cloud Kerberos | - Windows 10 21H2, with [KB5010415][KB-1] and later
      - Windows 11 21H2, with [KB5010414][KB-2] and later | +| **🔲** | **Hybrid** | Key | All supported versions | +| **🔲** | **Hybrid** | Certificate | All supported versions | +| **🔲** | **On-premises** | Key| All supported versions | +| **🔲** | **On-premises** | Certificate | All supported versions | + +### Windows Server requirements + +All supported Windows Server versions can be used with Windows Hello for Business as Domain Controller. However, cloud Kerberos trust requires minimum versions: + +| | Deployment model | Trust type | Domain Controller OS version | +|--|--|--|--| +| **🔲** | **Cloud-only** | n/a | All supported versions | +| **🔲** | **Hybrid** | Cloud Kerberos | - Windows Server 2016, with [KB3534307][KB-3] and later
      - Windows Server 2019, with [KB4534321][KB-4] and later
      - Windows Server 2022 | +| **🔲** | **Hybrid** | Key | All supported versions | +| **🔲** | **Hybrid** | Certificate | All supported versions | +| **🔲** | **On-premises** | Key | All supported versions | +| **🔲** | **On-premises** | Certificate | All supported versions | + +## Prepare users + +When you are ready to enable Windows Hello for Business in your organization, make sure to prepare the users by explaining how to provision and use Windows Hello. + +To learn more, see [Prepare users](prepare-users.md). + +## Next steps + +Now that you've read about the different deployment options and requirements, you can choose the implementation that best suits your organization. + +> [!div class="op_multi_selector" title1="Deployment model:" title2="Trust type:"] +> To learn more about the deployment process, chose a deployment model and trust type from the following drop-down lists: +> +> - [(cloud-only|n/a)](cloud-only.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) + + + +[ENTRA-1]: /entra/identity/authentication/concept-mfa-howitworks +[ENTRA-2]: /entra/identity/authentication/howto-mfaserver-deploy +[ENTRA-3]: /entra/identity/hybrid/connect/how-to-connect-sync-whatis +[ENTRA-4]: /entra/identity/authentication/howto-mfa-mfasettings +[ENTRA-5]: /entra/identity/devices/hybrid-join-plan +[ENTRA-6]: /entra/identity/hybrid/connect/whatis-phs +[ENTRA-7]: /entra/identity/hybrid/connect/how-to-connect-pta +[ENTRA-8]: /entra/identity/conditional-access/overview +[ENTRA-9]: /entra/identity/authentication/concept-mfa-licensing +[ENTRA-10]: /entra/identity/hybrid/connect/whatis-fed + +[SER-1]: /windows-server/identity/ad-fs/operations/configure-ad-fs-2016-and-azure-mfa +[SER-2]: /windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods + +[KB-1]: https://support.microsoft.com/topic/5010415 +[KB-2]: https://support.microsoft.com/topic/5010414 +[KB-3]: https://support.microsoft.com/topic/4534307 +[KB-4]: https://support.microsoft.com/topic/4534321 +[MEM-1]: /mem/intune/enrollment/quickstart-setup-auto-enrollment +[WIN-1]: /windows/configuration/provisioning-packages/how-it-pros-can-use-configuration-service-providers#csps-in-windows-configuration-designer diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs.md index 1757f9c6b1..335e4d5cb6 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-adfs.md @@ -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. -ms.date: 12/15/2023 -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +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: 01/03/2024 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 `` 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. [!NOTE] -> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.` 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 `. +[!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) diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md index 016c4b4c9e..045a6ba24c 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md +++ b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-enroll.md @@ -1,131 +1,85 @@ --- +ms.date: 01/03/2024 +ms.topic: tutorial 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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -ms.topic: tutorial --- -# Configure Windows Hello for Business group policy settings - on-premises certificate Trust +# Configure and enroll in Windows Hello for Business in an on-premises certificate trust model -[!INCLUDE [apply-to-on-premises-cert-trust-entra](includes/apply-to-on-premises-cert-trust-entra.md)] - -On-premises certificate-based deployments of Windows Hello for Business need three Group Policy settings: - -- Enable Windows Hello for Business -- Use certificate for on-premises authentication -- Enable automatic enrollment of certificates - -## Enable Windows Hello for Business group policy setting - -The group policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users. - -If you configure the group policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the group policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business. - -## Use certificate for on-premises authentication group policy setting - -The group policy setting determines if the on-premises deployment uses the key-trust or certificate trust on-premises authentication model. You must configure this group policy setting to configure Windows to enroll for a Windows Hello for Business authentication certificate. If you do not configure this policy setting, Windows considers the deployment to use key-trust on-premises authentication. - -You can configure this setting for computer or users. Deploying this setting to computers results in *all* users requesting a Windows Hello for Business authentication certificate. Deploying this policy setting to a user results in only that user requesting a Windows Hello for Business authentication certificate. Additionally, you can deploy the policy setting to a group of users so only those users request a Windows Hello for Business authentication certificate. If both user and computer policy settings are deployed, the user policy setting has precedence. - -## Enable automatic enrollment of certificates group policy setting - -Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business authentication certificate template. The process requires no user interaction provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires. - -## Create the GPO - -Sign in to a domain controller or management workstations with *Domain Administrator* 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 *Enable Windows Hello for Business* in the name box and select **OK** -1. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and select **Edit** -1. In the navigation pane, select **User Configuration > Policies > Administrative Templates > Windows Component > Windows Hello for Business** -1. In the content pane, double-click **Use Windows Hello for Business**. Select **Enable** and **OK** -1. Select **Use certificate for on-premises authentication > Enable > OK** -1. In the navigation pane, expand **Policies > User Configuration** -1. Expand **Windows Settings > Security Settings > Public Key Policies** -1. In the details pane, right-click **Certificate Services Client - Auto-Enrollment** and select **Properties** -1. Select **Enabled** from the **Configuration Model** list -1. Select the **Renew expired certificates**, **update pending certificates**, and **remove revoked certificates** check box -1. Select the **Update certificates that use certificate templates** check box -1. Select **OK** and close the **Group Policy Management Editor**. - -## Configure security in the Windows Hello for Business GPO - -The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases. - -Sign in to a domain controller or management workstations with *Domain Administrator* 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. Double-click the **Enable Windows Hello for Business** Group Policy object -1. In the **Security Filtering** section of the content pane, select **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and select **OK** -1. Select the **Delegation** tab. Select **Authenticated Users** and **Advanced** -1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK** - -## Deploy the Windows Hello for Business Group Policy object - -The application of the Windows Hello for Business Group Policy object uses security group filtering. This solution enables you to link the Group Policy object at the domain level, ensuring the GPO is within scope to all users. However, the security group filtering ensures that only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business. - -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 **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK** - -## Other Related Group Policy settings - -There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. - -### Use a hardware security device - -The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential. - -You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business. - -Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object. - -### Use biometrics - -Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security. - -The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disables all biometrics. Currently, Windows does not provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition, but disallowing fingerprint recognition. - -### PIN Complexity - -PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed. - -Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically. The policy settings included are: - -- Require digits -- Require lowercase letters -- Maximum PIN length -- Minimum PIN length -- Expiration -- History -- Require special characters -- Require uppercase letters - -The settings can be found in *Administrative Templates\System\PIN Complexity*, under both the Computer and User Configuration nodes of the Group Policy editor. - -## Review to validate the configuration - -Before you continue with the deployment, validate your deployment progress by reviewing the following items: +[!INCLUDE [apply-to-on-premises-cert-trust](includes/apply-to-on-premises-cert-trust.md)] > [!div class="checklist"] -> - 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 -> - Confirm you removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions) -> - Confirm you added the Windows Hello for Business Users group to the Group Policy object, and gave the group the allow permission to Apply Group Policy -> - Linked the Group Policy object to the correct locations within Active Directory -> - Deployed any additional Windows Hello for Business Group Policy settings +> Once the prerequisites are met, and the PKI and AD FS configurations are validated, deploying Windows Hello for Business consists of the following steps: +> +> - [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) +> - [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business) -## Add users to the Windows Hello for Business Users group +## Configure Windows Hello for Business policy settings -Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the *Windows Hello for Business Users* group. Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business. \ No newline at end of file +There are 2 policy setting required to enable Windows Hello for Business in a certificate trust model: + +- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business) +- [Use certificate for on-premises authentication](../policy-settings.md#use-certificate-for-on-premises-authentication) + +Another optional, but recommended, policy setting is: + +- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device) + +Follow the instructions below to configure your devices using either Microsoft Intune or group policy (GPO). + +[!INCLUDE [gpo-enable-whfb](includes/gpo-enable-whfb.md)] + +> [!TIP] +> Use the same *Windows Hello for Business Users* security group to assign **Certificate template permissions** to ensure the same members can enroll in the Windows Hello for Business authentication certificate. + +### Enable automatic enrollment of certificates group policy setting + +Windows Hello for Business provisioning performs the initial enrollment of the Windows Hello for Business authentication certificate. This certificate expires based on the duration configured in the Windows Hello for Business *authentication certificate* template. + +The process requires no user interaction, provided the user signs-in using Windows Hello for Business. The certificate is renewed in the background before it expires. + +[!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**
      or
      **User Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use Windows Hello for Business| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**
      or
      **User Configuration\Administrative Templates\Windows Components\Windows Hello for Business**|Use certificate for on-premises authentication| **Enabled**| +| **Computer Configuration\Windows Settings\Security Settings\Public Key Policies**
      or
      **User Configuration\Windows Settings\Security Settings\Public Key Policies** |Certificate Services Client - Auto-Enrollment| - Select **Enabled** from the **Configuration Model**
      - Select the **Renew expired certificates, update pending certificates, and remove revoked certificates**
      - Select **Update certificates that use certificate templates**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use a hardware security device| **Enabled**| + +> [!NOTE] +> The enablement of the *Use a hardware security device* policy setting is optional, but recommended. + +[!INCLUDE [gpo-settings-2](../../../../../includes/configure/gpo-settings-2.md)] + +> [!TIP] +> The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all security principals. The security group filtering ensures that only the members of the global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. + +Additional policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md). + +## Enroll in Windows Hello for Business + +The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass. + +You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > Windows**.\ +This information is also available using the `dsregcmd.exe /status` command from a console. For more information, see [dsregcmd][AZ-4]. + +### User experience + +[!INCLUDE [user-experience](includes/user-experience.md)] + +After a successful key registration, Windows creates a certificate request using the same key pair to request a certificate. Windows sends the certificate request to the AD FS server for certificate enrollment. + +The AD FS registration authority verifies the key used in the certificate request matches the key that was previously registered. On a successful match, the AD FS registration authority signs the certificate request using its enrollment agent certificate and sends it to the certificate authority. + +The CA validates that the certificate is signed by the registration authority. On successful validation, it issues a certificate based on the request and returns the certificate to the AD FS registration authority. The registration authority returns the certificate to Windows where it then installs the certificate in the current user's certificate store. Once this process completes, the Windows Hello for Business provisioning workflow informs the user that they can use their PIN to sign-in through the Action Center. + +### Sequence diagram + +To better understand the provisioning flows, review the following sequence diagram: + +- [Provisioning in an on-premises certificate trust deployment model](../how-it-works-provisioning.md#provisioning-in-an-on-premises-certificate-trust-deployment-model) + + +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-mfa.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-mfa.md deleted file mode 100644 index 35fd08dd4d..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-mfa.md +++ /dev/null @@ -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -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) diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-pki.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-pki.md deleted file mode 100644 index 2c8db04a8f..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust-pki.md +++ /dev/null @@ -1,60 +0,0 @@ ---- -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -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)] - -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. - -[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] - -## Configure the enterprise PKI - -[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] - -[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] - -[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)] - -[!INCLUDE [enrollment-agent-certificate-template](includes/enrollment-agent-certificate-template.md)] - -[!INCLUDE [auth-certificate-template](includes/auth-certificate-template.md)] - -[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] - -### Publish certificate templates to the CA - -A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. - -Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. - -1. Open the **Certification Authority** management console -1. Expand the parent node from the navigation pane -1. Select **Certificate Templates** in the navigation pane -1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue -1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, *Internal Web Server*, *WHFB Enrollment Agent* and *WHFB Authentication* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority -1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list - - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation -1. Close the console - -## Configure and deploy certificates to domain controllers - -[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] - -## Validate the configuration - -[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] - -> [!div class="nextstepaction"] -> [Next: prepare and deploy AD FS >](on-premises-cert-trust-adfs.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust.md index 4c3f3c04e8..6bd1a94800 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/on-premises-cert-trust.md @@ -1,43 +1,94 @@ --- -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +title: Windows Hello for Business on-premises certificate trust deployment guide +description: Learn how to deploy Windows Hello for Business in an on-premises, certificate trust scenario. +ms.date: 01/03/2024 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)] -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. +[!INCLUDE [apply-to-on-premises-cert-trust](includes/apply-to-on-premises-cert-trust.md)] -There are four steps to deploying Windows Hello for Business in an on-premises certificate trust model: +[!INCLUDE [requirements](includes/requirements.md)] -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) +> [!div class="checklist"] +> +> - [Public Key Infrastructure](index.md#pki-requirements) +> - [Authentication](index.md#authentication-to-microsoft-entra-id) +> - [Device configuration](index.md#device-configuration-options) +> - [Licensing for cloud services](index.md#licensing-for-cloud-services-requirements) +> - [Windows requirements](index.md#windows-requirements) +> - [Windows Server requirements](index.md#windows-server-requirements) +> - [Prepare users to use Windows Hello](prepare-users.md) -## Create the Windows Hello for Business Users security group +## Deployment steps -While this is not a required step, it is recommended to create a security group to simplify the deployment. +Once the prerequisites are met, deploying Windows Hello for Business consists of the following steps: -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. +> [!div class="checklist"] +> +> - [Configure and validate the Public Key Infrastructure](#configure-and-validate-the-public-key-infrastructure) +> - [Prepare and deploy AD FS with MFA](on-premises-cert-trust-adfs.md) +> - [Configure and enroll in Windows Hello for Business](on-premises-cert-trust-enroll.md) -Sign-in to a domain controller or to a management workstation with a *Domain Administrator* equivalent credentials. +## Configure and validate the Public Key Infrastructure -1. Open **Active Directory Users and Computers** -1. Select **View > Advanced Features** -1. Expand the domain node from the navigation pane -1. Right-click the **Users** container. Select **New > Group** -1. Type *Windows Hello for Business Users* in the **Group Name** -1. Select **OK** +[!INCLUDE [apply-to-on-premises-cert-trust](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. + +[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] + +## Configure the enterprise PKI + +[!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/certificate-template-web-server.md)] + +[!INCLUDE [enrollment-agent-certificate-template](includes/certificate-template-enrollment-agent.md)] + +[!INCLUDE [auth-certificate-template](includes/certificate-template-auth.md)] + +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] + +### Publish certificate templates to the CA + +A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. + +Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. + +1. Open the **Certification Authority** management console +1. Expand the parent node from the navigation pane +1. Select **Certificate Templates** in the navigation pane +1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue +1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, *Internal Web Server*, *WHFB Enrollment Agent* and *WHFB Authentication* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority +1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list + - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation +1. Close the console + +## Configure and deploy certificates to domain controllers + +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] + +## Validate the configuration + +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] + +## Section review and next steps + +> [!div class="checklist"] +> Before moving to the next section, ensure the following steps are complete: +> +> - Configure domain controller and web server certificate templates +> - Supersede existing domain controller certificates +> - Unpublish superseded certificate templates +> - Configure an enrollment agent certificate template +> - Publish the certificate templates to the CA +> - Deploy certificates to the domain controllers +> - Validate the domain controllers configuration > [!div class="nextstepaction"] -> [Next: validate and configure a PKI >](on-premises-cert-trust-pki.md) \ No newline at end of file +> [Next: prepare and deploy AD FS >](on-premises-cert-trust-adfs.md) diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs.md index 4446ced825..12685b46eb 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs.md +++ b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-adfs.md @@ -1,264 +1,46 @@ --- -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 +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: 01/03/2024 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 `` 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. [!NOTE] -> If your forest has multiple UPN suffixes, please make sure that `enterpriseregistration.` 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) diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-enroll.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-enroll.md index eca8d12e30..442ead237c 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-enroll.md +++ b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-enroll.md @@ -1,108 +1,61 @@ --- -ms.date: 09/07/2023 +ms.date: 01/03/2024 +ms.topic: tutorial title: Configure Windows Hello for Business Policy settings in an on-premises key trust description: Configure Windows Hello for Business Policy settings for Windows Hello for Business in an on-premises key trust scenario -appliesto: -- ✅ Windows 11 -- ✅ Windows 10 -ms.topic: tutorial --- -# Configure Windows Hello for Business group policy settings - on-premises key trust + +# Configure and enroll in Windows Hello for Business in an on-premises key trust model [!INCLUDE [apply-to-on-premises-key-trust](includes/apply-to-on-premises-key-trust.md)] -On-premises key trust deployments of Windows Hello for Business need one Group Policy setting: *Enable Windows Hello for Business*. -The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users. - -If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business. - -## Enable Windows Hello for Business group policy setting - -The Group Policy setting determines whether users are allowed, and prompted, to enroll for Windows Hello for Business. It can be configured for computers or users. - -If you configure the Group Policy for computers, all users that sign-in to those computers will be allowed and prompted to enroll for Windows Hello for Business. If you configure the Group Policy for users, only those users will be allowed and prompted to enroll for Windows Hello for Business. - -## Create the GPO - -Sign in to a domain controller or management workstations with *Domain Administrator* 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 *Enable Windows Hello for Business* in the name box and select **OK** -1. In the content pane, right-click the **Enable Windows Hello for Business** Group Policy object and select **Edit** -1. In the navigation pane, select **User Configuration > Policies > **Administrative Templates > Windows Component > Windows Hello for Business** -1. In the content pane, double-click **Use Windows Hello for Business**. Select **Enable** and **OK** -1. Close the **Group Policy Management Editor** - -## Configure security in the Windows Hello for Business GPO - -The best way to deploy the Windows Hello for Business Group Policy object is to use security group filtering. The enables you to easily manage the users that should receive Windows Hello for Business by simply adding them to a group. This enables you to deploy Windows Hello for Business in phases. - -Sign in to a domain controller or management workstations with *Domain Administrator* 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. Double-click the **Enable Windows Hello for Business** Group Policy object -1. In the **Security Filtering** section of the content pane, select **Add**. Type *Windows Hello for Business Users* or the name of the security group you previously created and select **OK** -1. Select the **Delegation** tab. Select **Authenticated Users** and **Advanced** -1. In the **Group or User names** list, select **Authenticated Users**. In the **Permissions for Authenticated Users** list, clear the **Allow** check box for the **Apply Group Policy** permission. Select **OK** - -## Deploy the Windows Hello for Business Group Policy object - -The application of the Windows Hello for Business Group Policy object uses security group filtering. This solution enables you to link the Group Policy object at the domain level, ensuring the GPO is within scope to all users. However, the security group filtering ensures that only the users included in the *Windows Hello for Business Users* global group receive and apply the Group Policy object, which results in the provisioning of Windows Hello for Business. - -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 **Enable Windows Hello for Business** or the name of the Windows Hello for Business Group Policy object you previously created and select **OK** - -## Other Related Group Policy settings - -There are other Windows Hello for Business policy settings you can configure to manage your Windows Hello for Business deployment. These policy settings are computer-based policy setting; so they are applicable to any user that sign-in from a computer with these policy settings. - -### Use a hardware security device - -The default configuration for Windows Hello for Business is to prefer hardware protected credentials; however, not all computers are able to create hardware protected credentials. When Windows Hello for Business enrollment encounters a computer that cannot create a hardware protected credential, it will create a software-based credential. - -You can enable and deploy the **Use a hardware security device** Group Policy Setting to force Windows Hello for Business to only create hardware protected credentials. Users that sign-in from a computer incapable of creating a hardware protected credential do not enroll for Windows Hello for Business. - -Another policy setting becomes available when you enable the **Use a hardware security device** Group Policy setting that enables you to prevent Windows Hello for Business enrollment from using version 1.2 Trusted Platform Modules (TPM). Version 1.2 TPMs typically perform cryptographic operations slower than version 2.0 TPMs and are more unforgiving during anti-hammering and PIN lockout activities. Some organizations may not want slow sign-in performance and management overhead associated with version 1.2 TPMs. To prevent Windows Hello for Business from using version 1.2 TPMs, select the TPM 1.2 check box after you enable the Use a hardware security device Group Policy object. - -### Use biometrics - -Windows Hello for Business provides a great user experience when combined with the use of biometrics. Rather than providing a PIN to sign-in, a user can use a fingerprint or facial recognition to sign-in to Windows, without sacrificing security. - -The default Windows Hello for Business enables users to enroll and use biometrics. However, some organization may want more time before using biometrics and want to disable their use until they are ready. To not allow users to use biometrics, configure the **Use biometrics** Group Policy setting to disabled and apply it to your computers. The policy setting disables all biometrics. Currently, Windows does not provide the ability to set granular policies that enable you to disable specific modalities of biometrics, such as allowing facial recognition, but disallowing fingerprint recognition. - -### PIN Complexity - -PIN complexity is not specific to Windows Hello for Business. Windows enables users to use PINs outside of Windows Hello for Business. PIN Complexity Group Policy settings apply to all uses of PINs, even when Windows Hello for Business is not deployed. - -Windows provides eight PIN Complexity Group Policy settings that give you granular control over PIN creation and management. You can deploy these policy settings to computers, where they affect all users creating PINs on that computer; or, you can deploy these settings to users, where they affect those users creating PINs regardless of the computer they use. If you deploy both computer and user PIN complexity Group Policy settings, the user policy settings have precedence over computer policy settings. Also, this conflict resolution is based on the last applied policy. Windows does not merge the policy settings automatically. The policy settings included are: - -- Require digits -- Require lowercase letters -- Maximum PIN length -- Minimum PIN length -- Expiration -- History -- Require special characters -- Require uppercase letters - -The settings can be found in *Administrative Templates\System\PIN Complexity*, under both the Computer and User Configuration nodes of the Group Policy editor. - -## Review to validate the configuration - -Before you continue with the deployment, validate your deployment progress by reviewing the following items: - > [!div class="checklist"] -> * Confirm you configured the Enable Windows Hello for Business to the scope that matches your deployment (Computer vs. User) -> * Confirm you configured the proper security settings for the Group Policy object -> * Confirm you removed the allow permission for Apply Group Policy for Domain Users (Domain Users must always have the read permissions) -> * Confirm you added the Windows Hello for Business Users group to the Group Policy object, and gave the group the allow permission to Apply Group Policy -> * Linked the Group Policy object to the correct locations within Active Directory -> * Deployed any additional Windows Hello for Business Group Policy settings +> Once the prerequisites are met, and the PKI and AD FS configurations are validated, deploying Windows Hello for Business consists of the following steps: +> +> - [Configure Windows Hello for Business policy settings](#configure-windows-hello-for-business-policy-settings) +> - [Enroll in Windows Hello for Business](#enroll-in-windows-hello-for-business) -## Add users to the Windows Hello for Business Users group +## Configure Windows Hello for Business policy settings -Users must receive the Windows Hello for Business group policy settings and have the proper permission to enroll for the Windows Hello for Business Authentication certificate. You can provide users with these settings and permissions by adding the group used synchronize users to the *Windows Hello for Business Users* group. Users and groups that are not members of this group will not attempt to enroll for Windows Hello for Business. +There's 1 policy setting required to enable Windows Hello for Business in a key trust model: + +- [Use Windows Hello for Business](../policy-settings.md#use-windows-hello-for-business) + +Another optional, but recommended, policy setting is: + +- [Use a hardware security device](../policy-settings.md#use-a-hardware-security-device) + +[!INCLUDE [gpo-enable-whfb](includes/gpo-enable-whfb.md)] + +[!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**
      or
      **User Configuration\Administrative Templates\Windows Components\Windows Hello for Business**|Use Windows Hello for Business| **Enabled**| +| **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business** |Use a hardware security device| **Enabled**| + +[!INCLUDE [gpo-settings-2](../../../../../includes/configure/gpo-settings-2.md)] + +> [!TIP] +> The best way to deploy the Windows Hello for Business GPO is to use security group filtering. Only members of the targeted security group will provision Windows Hello for Business, enabling a phased rollout. This solution allows linking the GPO to the domain, ensuring the GPO is scoped to all security principals. The security group filtering ensures that only the members of the global group receive and apply the GPO, which results in the provisioning of Windows Hello for Business. + +Additional policy settings can be configured to control the behavior of Windows Hello for Business. For more information, see [Windows Hello for Business policy settings](../policy-settings.md). + +## Enroll in Windows Hello for Business + +The Windows Hello for Business provisioning process begins immediately after the user profile is loaded and before the user receives their desktop. For the provisioning process to begin, all prerequisite checks must pass. + +You can determine the status of the prerequisite checks by viewing the **User Device Registration** admin log under **Applications and Services Logs > Microsoft > Windows**.\ +This information is also available using the `dsregcmd.exe /status` command from a console. For more information, see [dsregcmd][AZ-4]. + +### User experience + +[!INCLUDE [user-experience](includes/user-experience.md)] + +### Sequence diagram + +To better understand the provisioning flows, review the following sequence diagram: + +- [Provisioning in an on-premises key trust deployment model](../how-it-works-provisioning.md#provisioning-in-an-on-premises-key-trust-deployment-model) + +[AZ-4]: /azure/active-directory/devices/troubleshoot-device-dsregcmd diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki.md deleted file mode 100644 index 6d7aef36c5..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust-pki.md +++ /dev/null @@ -1,55 +0,0 @@ ---- -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 -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)] - -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. - -[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] - -## Configure the enterprise PKI - -[!INCLUDE [dc-certificate-template](includes/dc-certificate-template.md)] - -[!INCLUDE [dc-certificate-template-supersede](includes/dc-certificate-supersede.md)] - -[!INCLUDE [web-server-certificate-template](includes/web-server-certificate-template.md)] - -[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] - -### Publish certificate templates to the CA - -A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. - -Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. - -1. Open the **Certification Authority** management console -1. Expand the parent node from the navigation pane -1. Select **Certificate Templates** in the navigation pane -1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue -1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, and *Internal Web Server* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority -1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list - - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation -1. Close the console - -## Configure and deploy certificates to domain controllers - -[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] - -## Validate the configuration - -[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] - -> [!div class="nextstepaction"] -> [Next: prepare and deploy AD FS >](on-premises-key-trust-adfs.md) \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust.md b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust.md index 961219b27e..a5a2281196 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust.md +++ b/windows/security/identity-protection/hello-for-business/deploy/on-premises-key-trust.md @@ -1,35 +1,86 @@ --- -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 +title: Windows Hello for Business on-premises key trust deployment guide +description: Learn how to deploy Windows Hello for Business in an on-premises, key trust scenario. +ms.date: 01/03/2024 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: +[!INCLUDE [requirements](includes/requirements.md)] -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) +> [!div class="checklist"] +> +> - [Public Key Infrastructure](index.md#pki-requirements) +> - [Authentication](index.md#authentication-to-microsoft-entra-id) +> - [Device configuration](index.md#device-configuration-options) +> - [Licensing for cloud services](index.md#licensing-for-cloud-services-requirements) +> - [Windows requirements](index.md#windows-requirements) +> - [Windows Server requirements](index.md#windows-server-requirements) +> - [Prepare users to use Windows Hello](prepare-users.md) -## Create the Windows Hello for Business Users security group +## Deployment steps -While this isn't a required step, it's recommended to create a security group to simplify the deployment. +Once the prerequisites are met, deploying Windows Hello for Business consists of the following steps: -The *Windows Hello for Business Users* group is used to make it easy to deploy Windows Hello for Business in phases. You assign 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. +> [!div class="checklist"] +> +> - [Configure and validate the Public Key Infrastructure](#configure-and-validate-the-public-key-infrastructure) +> - [Prepare and deploy AD FS with MFA](on-premises-key-trust-adfs.md) +> - [Configure and enroll in Windows Hello for Business](on-premises-key-trust-enroll.md) -Sign-in to a domain controller or to a management workstation with a *Domain Administrator* equivalent credentials. +## Configure and validate the Public Key Infrastructure -1. Open **Active Directory Users and Computers** -1. Select **View > Advanced Features** -1. Expand the domain node from the navigation pane -1. Right-click the **Users** container. Select **New > Group** -1. Type *Windows Hello for Business Users* in the **Group Name** -1. Select **OK** +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. + +[!INCLUDE [lab-based-pki-deploy](includes/lab-based-pki-deploy.md)] + +## Configure the enterprise PKI + +[!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/certificate-template-web-server.md)] + +[!INCLUDE [unpublish-superseded-templates](includes/unpublish-superseded-templates.md)] + +### Publish certificate templates to the CA + +A certification authority can only issue certificates for certificate templates that are published to it. If you have more than one CA, and you want more CAs to issue certificates based on the certificate template, then you must publish the certificate template to them. + +Sign in to the CA or management workstations with **Enterprise Admin** equivalent credentials. + +1. Open the **Certification Authority** management console +1. Expand the parent node from the navigation pane +1. Select **Certificate Templates** in the navigation pane +1. Right-click the **Certificate Templates** node. Select **New > Certificate Template** to issue +1. In the **Enable Certificates Templates** window, select the *Domain Controller Authentication (Kerberos)*, and *Internal Web Server* templates you created in the previous steps. Select **OK** to publish the selected certificate templates to the certification authority +1. If you published the *Domain Controller Authentication (Kerberos)* certificate template, then unpublish the certificate templates you included in the superseded templates list + - To unpublish a certificate template, right-click the certificate template you want to unpublish and select **Delete**. Select **Yes** to confirm the operation +1. Close the console + +## Configure and deploy certificates to domain controllers + +[!INCLUDE [dc-certificate-deployment](includes/dc-certificate-deployment.md)] + +## Validate the configuration + +[!INCLUDE [dc-certificate-validate](includes/dc-certificate-validate.md)] + +## Section review and next steps + +> [!div class="checklist"] +> Before moving to the next section, ensure the following steps are complete: +> +> - Configure domain controller and web server certificate templates +> - Supersede existing domain controller certificates +> - Unpublish superseded certificate templates +> - Publish the certificate templates to the CA +> - Deploy certificates to the domain controllers +> - Validate the domain controllers configuration > [!div class="nextstepaction"] -> [Next: validate and configure PKI >](on-premises-key-trust-pki.md) \ No newline at end of file +> [Next: prepare and deploy AD FS >](on-premises-key-trust-adfs.md) diff --git a/windows/security/identity-protection/hello-for-business/deploy/prepare-users.md b/windows/security/identity-protection/hello-for-business/deploy/prepare-users.md new file mode 100644 index 0000000000..9dbdfc8a07 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/deploy/prepare-users.md @@ -0,0 +1,45 @@ +--- +title: Prepare users to provision and use Windows Hello for Business +description: Learn how to prepare users to enroll and to use Windows Hello for Business. +ms.date: 01/02/2024 +ms.topic: end-user-help +--- + +# Prepare users to provision and use Windows Hello for Business + +This article provides guidance on how to prepare users to enroll and to use Windows Hello for Business. It also provides guidance on how to communicate the benefits of Windows Hello for Business to users. + +## Multi-factor authentication + +The provisioning of Windows Hello requires users to authenticate with multi-factor (MFA). Ensure that you have a solution in place for users to use MFA during the process. + +> [!TIP] +> To facilitate user communication and to ensure a successful Windows Hello for Business deployment, you can find customizable material (email templates, posters, trainings, etc.) at [Microsoft Entra templates](https://aka.ms/adminmails). + +## Biometric gestures + +Depending on the hardware, users might be prompted to register their fingerprint or face. Explain to users that for convenience, they should register their biometric gesture during the provisioning process. The biometric gesture can be used to unlock the device and to authenticate to resources that require Windows Hello for Business. Biometric gestures are valid only on the enrolled device and are not stored outside the device. + +## User experience + +The next video shows the Windows Hello for Business enrollment experience after a user signs in with a password: + +1. Since the device supports biometric authentication, the user is prompted to set up a biometric gesture. This gesture can be used to unlock the device and authenticate to resources that require Windows Hello for Business. The user can skip this step if they don't want to set up a biometric gesture +1. The user is prompted to use Windows Hello with the organization account. The user selects **OK** +1. The provisioning flow proceeds to the multi-factor authentication portion of the enrollment. Provisioning informs the user that it's actively attempting to contact the user through their configured form of MFA. The provisioning process doesn't proceed until authentication succeeds, fails or times out. A failed or timeout MFA results in an error and asks the user to retry +1. After a successful MFA, the provisioning flow asks the user to create and validate a PIN. This PIN must observe any PIN complexity policies configured on the device + +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."] + +After enrollment in Windows Hello, users should use their gesture (such as a PIN or fingerprint) for access to their devices and corporate resources. The unlock gesture is valid only on the enrolled device. + +> [!IMPORTANT] +> Although the organization might require users to change their Active Directory or Microsoft Entra account password at regular intervals, changes to their passwords have no effect on Hello. + +The next video shows the Windows Hello for Business enrollment experience as part of the out-of-box-experience (OOBE) process: + +1. The user joins the device to Microsoft Entra ID and is prompted for MFA during the join process +1. The device is Managed by Microsoft Intune and applies Windows Hello for Business policy settings +1. After the user profile is loaded, but before the access to the desktop is granted, the user must enroll in Windows Hello + +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=44c16430-756f-490a-9fc1-80e2724fef8d alt-text="Video showing the Windows Hello for Business enrollment steps after the out-of-box-experience process."] \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/deploy/requirements.md b/windows/security/identity-protection/hello-for-business/deploy/requirements.md deleted file mode 100644 index 61dffe9d37..0000000000 --- a/windows/security/identity-protection/hello-for-business/deploy/requirements.md +++ /dev/null @@ -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: -- ✅ Windows 11 -- ✅ Windows 10 -- ✅ Windows Server 2022 -- ✅ Windows Server 2019 -- ✅ Windows Server 2016 ---- - -# Windows Hello for Business Deployment Prerequisite Overview - -This article lists the infrastructure requirements for the different deployment models for Windows Hello for Business. - - - -## 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
      Group Policy or Modern managed | Key trust
      Group Policy or Modern managed | Certificate Trust
      Mixed managed | Certificate Trust
      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
      AD FS w/Azure MFA adapter, or
      AD FS w/Azure MFA Server adapter, or
      AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
      AD FS w/Azure MFA adapter, or
      AD FS w/Azure MFA Server adapter, or
      AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
      AD FS w/Azure MFA adapter, or
      AD FS w/Azure MFA Server adapter, or
      AD FS w/3rd Party MFA Adapter | Azure MFA tenant, or
      AD FS w/Azure MFA adapter, or
      AD FS w/Azure MFA Server adapter, or
      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
      Group Policy managed | Certificate trust
      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 | diff --git a/windows/security/identity-protection/hello-for-business/deploy/toc.yml b/windows/security/identity-protection/hello-for-business/deploy/toc.yml index 87ab1eb026..55964be416 100644 --- a/windows/security/identity-protection/hello-for-business/deploy/toc.yml +++ b/windows/security/identity-protection/hello-for-business/deploy/toc.yml @@ -1,29 +1,18 @@ items: -- name: Windows Hello for Business deployment overview +- name: Plan a Windows Hello for Business Deployment href: index.md -- name: Deployment prerequisite overview - href: requirements.md - name: Cloud-only deployment - href: cloud.md + href: cloud-only.md - name: Hybrid deployments items: - name: Cloud Kerberos trust deployment - items: - - name: Overview - href: hybrid-cloud-kerberos-trust.md - displayName: cloud Kerberos trust - - name: Configure and provision Windows Hello for Business - href: hybrid-cloud-kerberos-trust-enroll.md - displayName: cloud Kerberos trust + href: hybrid-cloud-kerberos-trust.md - name: Key trust deployment items: - - name: Overview + - name: Requirements and validation href: hybrid-key-trust.md displayName: key trust - - name: Configure and validate the PKI - href: hybrid-key-trust-pki.md - displayName: key trust - - name: Configure and provision Windows Hello for Business + - name: Configure and enroll in Windows Hello for Business href: hybrid-key-trust-enroll.md displayName: key trust - name: Configure SSO for Microsoft Entra joined devices @@ -31,7 +20,7 @@ items: displayName: key trust - name: Certificate trust deployment items: - - name: Overview + - name: Requirements and validation href: hybrid-cert-trust.md displayName: certificate trust - name: Configure and validate Public Key Infrastructure (PKI) @@ -53,25 +42,19 @@ items: items: - name: Key trust deployment items: - - name: Overview - href: hybrid-cloud-kerberos-trust.md - - name: Configure and validate the PKI - href: on-premises-key-trust-pki.md + - name: Requirements and validation + href: on-premises-key-trust.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: - - name: Overview + - name: Requirements and validation href: on-premises-cert-trust.md - - name: Configure and validate Public Key Infrastructure (PKI) - 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 +- name: Prepare users to provision and use Hello + href: prepare-users.md diff --git a/windows/security/identity-protection/hello-for-business/hello-faq.yml b/windows/security/identity-protection/hello-for-business/faq.yml similarity index 58% rename from windows/security/identity-protection/hello-for-business/hello-faq.yml rename to windows/security/identity-protection/hello-for-business/faq.yml index 6f42bde365..1b9e0947ca 100644 --- a/windows/security/identity-protection/hello-for-business/hello-faq.yml +++ b/windows/security/identity-protection/hello-for-business/faq.yml @@ -5,7 +5,7 @@ metadata: author: paolomatarazzo ms.author: paoloma ms.topic: faq - ms.date: 12/08/2023 + ms.date: 01/03/2024 title: Common questions about Windows Hello for Business summary: Windows Hello for Business replaces password sign-in with strong authentication, using an asymmetric key pair. This Frequently Asked Questions (FAQ) article is intended to help you learn more about Windows Hello for Business. @@ -17,45 +17,31 @@ sections: - question: What's the difference between Windows Hello and Windows Hello for Business? answer: | Windows Hello represents the biometric framework provided in Windows. Windows Hello lets users use biometrics to sign in to their devices by securely storing their user name and password and releasing it for authentication when the user successfully identifies themselves using biometrics. Windows Hello for Business uses asymmetric keys protected by the device's security module that requires a user gesture (PIN or biometrics) to authenticate. - - question: How can a PIN be more secure than a password? + - question: Why a PIN is better than an online 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. - - 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. - These keys are used to sign requests that are sent to the IDP, requesting access to specified resources. It's important to understand that although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn't require explicit validation through a user gesture, and the key material isn't exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure an application to require re-authentication anytime a specific operation is performed, even though the same account and PIN or gesture were already used to unlock the device. - For more information about the different authentication flows used by Windows Hello for Business, see [Windows Hello for Business and Authentication](hello-how-it-works-authentication.md). - - question: What happens after a user registers a PIN during the Windows Hello for Business enrollment process? - answer: | - Windows Hello generates a new public-private key pair on the device. The TPM generates and protects this private key; if the device doesn't have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the *protector key*. It's associated only with a single gesture; in other words, if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures will have a unique protector key. **Each unique gesture generates a unique protector key**. The protector key securely wraps the *authentication key*. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. Windows Hello also generates an administrative key that the user or administrator can use to reset credentials, when necessary (for example, when using the PIN reset service). In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM. - At this point, the user has a PIN gesture defined on the device and an associated protector key for that PIN gesture. That means the user is able to securely sign in to the device with the PIN and thus be able to establish a trusted session with the device to add support for a biometric gesture as an alternative for the PIN. When you add a biometric gesture, it follows the same basic sequence: the user authenticates to the system by using the PIN, and then registers the new biometric, after which Windows generates a unique key pair and stores it securely. Future sign-ins can then use either the PIN or the registered biometric gestures. - - question: What's a container? - answer: | - In the context of Windows Hello for Business, a container is a logical grouping of *key material* or data. Windows Hello uses a single container that holds user key material for personal accounts, including key material associated with the user's Microsoft account or with other consumer identity providers, and credentials associated with a workplace or school account. - The container holds enterprise credentials only on devices that have been registered with an organization; it contains key material for the enterprise IDP, such as on-premises Active Directory or Microsoft Entra ID. - - > [!NOTE] - > There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders. + Three main reasons: + 1. **A PIN is tied to a 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'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 + 1. **A 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. 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 + 1. **A 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 - The container contains a set of keys, some of which are used to protect other keys. The following image shows an example: the protector key is used to encrypt the authentication key, and the authentication key is used to encrypt the individual keys stored in the container. Each logical container holds one or more sets of keys.\ - :::image type="content" source="images/passport-fig3-logicalcontainer.png" alt-text="logical container with set of keys"::: - - Containers can contain several types of key material: - - An authentication key, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key will be generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key. - - The IDP key. These keys can be either symmetric or asymmetric, depending on which IDP you use. A single container may contain zero or more IDP keys, with some restrictions (for example, the enterprise container can contain zero or one IDP key). IDP keys are stored in the container. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the IDP key or key pair can request access. IDP keys are used to sign or encrypt authentication requests or tokens sent from this device to the IDP. IDP keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IDP (which stores it for later verification), and securely stores the private key. For enterprises, the IDP keys can be generated in two ways: - - The IDP key pair can be associated with an enterprise Certificate Authority (CA) through the Windows Network Device Enrollment Service (NDES). In this case, Windows Hello requests a new certificate with the same key as the certificate from the existing PKI. This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the enterprise to store additional certificates in the protected container. - - The IDP can generate the IDP key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI. + The statement *A PIN is stronger than a 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: What if someone steals the device? + answer: | + 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. + - question: Why do you need a PIN to use biometrics? + answer: | + Windows Hello enables biometric sign-in with 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. - question: How are keys protected? answer: | - Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IDP before the IDP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed. + Anytime key material is generated, it must be protected against attack. The most robust way to do this is through specialized hardware. There's a long history of using hardware security modules (HSMs) to generate, store, and process keys for security-critical applications. Smart cards are a special type of HSM, as are devices that are compliant with the Trusted Computing Group TPM standard. Wherever possible, the Windows Hello for Business implementation takes advantage of onboard TPM hardware to generate and protect keys. Administrators can choose to allow key operations in software, but it's recommended the use of TPM hardware. The TPM protects against a variety of known and potential attacks, including PIN brute-force attacks. The TPM provides an additional layer of protection after an account lockout, too. When the TPM has locked the key material, the user will have to reset the PIN (which means the user will have to use MFA to reauthenticate to the IdP before the IdP allows re-registration). Resetting the PIN means that all keys and certificates encrypted with the old key material will be removed. - question: How does PIN caching work with Windows Hello for Business? answer: | Windows Hello for Business provides a PIN caching user experience by using a ticketing system. Rather than caching a PIN, processes cache a ticket they can use to request private key operations. Microsoft Entra ID and Active Directory sign-in keys are cached under lock. This means the keys remain available for use without prompting, as long as the user is interactively signed-in. Microsoft Account sign-in keys are transactional keys, which means the user is always prompted when accessing the key. - Beginning with Windows 10, version 1709, Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation will prompt the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN. + Windows Hello for Business used as a smart card (smart card emulation that is enabled by default) provides the same user experience of default smart card PIN caching. Each process requesting a private key operation prompts the user for the PIN on first use. Subsequent private key operations won't prompt the user for the PIN. - The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. Windows 10 doesn't provide any Group Policy settings to adjust this caching. + The smart card emulation feature of Windows Hello for Business verifies the PIN and then discards the PIN in exchange for a ticket. The process doesn't receive the PIN, but rather the ticket that grants them private key operations. There isn't a policy setting to adjust the caching. - question: Where is Windows Hello biometrics data stored? answer: | When you enroll in Windows Hello, a representation of your biometrics, called an enrollment profile, is created more information can be found on [Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication). This enrollment profile biometrics data is device specific, is stored locally on the device, and does not leave the device or roam with the user. Some external fingerprint sensors store biometric data on the fingerprint module itself rather than on Windows device. Even in this case, the biometrics data is stored locally on those modules, is device specific, doesn't roam, never leaves the module, and is never sent to Microsoft cloud or external server. For more details, see [Windows Hello biometrics in the enterprise](/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise#where-is-windows-hello-data-stored). @@ -65,34 +51,26 @@ sections: - question: Who has access on Windows Hello biometrics data? answer: | Since Windows Hello biometrics data is stored in encrypted format, no user, or any process other than Windows Hello has access to it. - - question: What's the difference between non-destructive and destructive PIN reset? - answer: | - Windows Hello for Business has two types of PIN reset: non-destructive and destructive. Organizations running Windows 10 version 1903 and later and Microsoft Entra ID can take advantage of the Microsoft PIN Reset service. Once on-boarded to a tenant and deployed to computers, users who have forgotten their PINs can authenticate to Azure, provide a second factor of authentication, and reset their PIN without reprovisioning a new Windows Hello for Business enrollment. This flow is a non-destructive PIN reset because the user doesn't delete the current credential and obtain a new one. For more information, see [PIN Reset](hello-feature-pin-reset.md). - - Organizations that have the on-premises deployment of Windows Hello for Business, or those not using Windows 10 version 1903 and later can use destructive PIN reset. With destructive PIN reset, users that have forgotten their PIN can authenticate by using their password and then performing a second factor of authentication to reprovision their Windows Hello for Business credential. Reprovisioning deletes the old credential and requests a new credential and certificate. On-premises deployments need network connectivity to their domain controllers, Active Directory Federation Services, and their issuing certificate authority to perform a destructive PIN reset. For Microsoft Entra hybrid joined devices, destructive PIN reset is only supported with the certificate trust model and the latest updates to Active Directory Federation Services. - question: When is Windows Hello biometrics database file created? How is a user enrolled into Windows Hello face or fingerprint authentication? answer: | - Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. Your workplace or IT administrator may have turned certain authentication functionality, however, it is always your choice if you want to use Windows Hello or an alternative method, like a PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users. + Windows Hello biometrics template database file is created on the device only when a user is enrolled into Windows Hello biometrics-based authentication. An IT administrator may configure policy settings, but it's always a user's choice if they want to use biometrics or PIN. Users can check their current enrollment into Windows Hello biometrics by going to sign-in options on their device. Go to **Start > Settings > Accounts > Sign-in** options. If you don't see Windows Hello in Sign-in options, then it may not be available for your device or blocked by admin via policy. Admins can request users to enroll into Windows Hello during Autopilot or during the initial setup of the device. Admins can disallow users to enroll into biometrics via Windows Hello for Business policy configurations. However, when allowed via policy configurations, enrollment into Windows Hello biometrics is always optional for users. - question: When is Windows Hello biometrics database file deleted? How can a user be unenrolled from Windows Hello face or fingerprint authentication? answer: | - To remove Windows Hello and any associated biometric identification data from the device, user can go to **Start > Settings > Accounts > Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. This will u-enroll the user from Windows Hello biometrics authentication and will also delete the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy). + To remove Windows Hello and any associated biometric identification data from the device, open **Start > Settings > Accounts > Sign-in options**. Select the Windows Hello biometrics authentication method you want to remove, and then select **Remove**. The action unenrolls from Windows Hello biometrics authentication and deletes the associated biometrics template database file. For more details, see [Windows sign-in options and account protection (microsoft.com)](https://support.microsoft.com/windows/windows-sign-in-options-and-account-protection-7b34d4cf-794f-f6bd-ddcc-e73cdf1a6fbf#bkmk_helloandprivacy). - name: Management and operations questions: - - question: Can I deploy and manage Windows Hello for Business using Microsoft Intune? - answer: | - Yes, hybrid and cloud-only Windows Hello for Business deployments can use Microsoft Intune. For more information, see [Integrate Windows Hello for Business with Microsoft Intune](/mem/intune/protect/windows-hello). - question: Can I deploy and manage Windows Hello for Business by using Microsoft Configuration Manager? answer: | Starting in Configuration Manager, version 2203, Windows Hello for Business deployments using Configuration Manager are no longer supported. - question: How do I delete a Windows Hello for Business container on a device? answer: | - You can effectively disable Windows Hello for Business by launching `certutil.exe -deleteHelloContainer` on the end device under a user account, and then restarting the device. + You can delete the Windows Hello for Business container by executing the command `certutil.exe -deleteHelloContainer`. - question: What happens when a user forgets their PIN? answer: | - If the user can sign in with a password, they can reset their PIN by selecting the *I forgot my PIN* link in the Settings app. Users can reset also their PIN from the lock screen by selecting the *I forgot my PIN* link on the PIN credential provider. + If the user can sign in with a password, they can reset their PIN by selecting the *I forgot my PIN* link in the Settings app or from the lock screen, by selecting the *I forgot my PIN* link on the PIN credential provider. - For on-premises deployments, devices must be connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid deployments can onboard their Azure tenant to use the Windows Hello for Business PIN reset service to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset). + For on-premises deployments, devices must be connected to their on-premises network (domain controllers and/or certificate authority) to reset their PINs. Hybrid deployments can onboard their Microsoft Entra tenant to use the *Windows Hello for Business PIN reset service* to reset their PINs. Non-destructive PIN reset works without access to the corporate network. Destructive PIN reset requires access to the corporate network. For more details about destructive and non-destructive PIN reset, see [PIN reset](/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset). - question: Does Windows Hello for Business prevent the use of simple PINs? answer: | Yes. Our simple PIN algorithm looks for and disallows any PIN that has a constant delta from one digit to the next. The algorithm counts the number of steps required to reach the next digit, overflowing at 10 ('zero'). @@ -118,9 +96,6 @@ sections: - question: Can I disable the PIN while using Windows Hello for Business? answer: | No. The movement away from passwords is accomplished by gradually reducing the use of the password. In situations where you can't authenticate by using biometrics, you need a fallback mechanism that isn't a password. The PIN is the fallback mechanism. Disabling or hiding the PIN credential provider will disable the use of biometrics. - - question: What is Event ID 300? - answer: | - This event is created when Windows Hello for Business is successfully created and registered with Microsoft Entra ID. Applications or services can trigger actions on this event. For example, a certificate provisioning service can listen to this event and trigger a certificate request. This is a normal condition and no further action is required. - question: What happens when an unauthorized user gains possession of a device enrolled in Windows Hello for Business? answer: | The unauthorized user won't be able to utilize any biometric options and will have the only option to enter a PIN. @@ -144,7 +119,7 @@ sections: No. If your organization is using Microsoft cloud services, then you must use a hybrid deployment model. On-premises deployments are exclusive to organizations who need more time before moving to the cloud and exclusively use Active Directory. - question: What attributes are synchronized by Microsoft Entra Connect with Windows Hello for Business? answer: | - Review [Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#windows-10) scenario and the [Device writeback](/azure/active-directory/connect/active-directory-aadconnectsync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes. + Review [Microsoft Entra Connect Sync: Attributes synchronized to Microsoft Entra ID](/entra/identity/hybrid/connect/reference-connect-sync-attributes-synchronized) for a list of attributes that sync based on scenarios. The base scenarios that include Windows Hello for Business are the [Windows 10](/entra/identity/hybrid/connect/reference-connect-sync-attributes-synchronized#windows-10) scenario and the [Device writeback](/entra/identity/hybrid/connect/reference-connect-sync-attributes-synchronized#device-writeback) scenario. Your environment may include other attributes. - question: Can I use third-party MFA providers with Windows Hello for Business? answer: | Yes, if you're using federated hybrid deployment, you can use any third-party that provides an AD FS MFA adapter. A list of third-party MFA adapters can be found [here](/windows-server/identity/ad-fs/operations/configure-additional-authentication-methods-for-ad-fs#microsoft-and-third-party-additional-authentication-methods). @@ -166,19 +141,19 @@ sections: Read [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements) for more information. - question: Can I wear a mask to enroll or unlock using Windows Hello face authentication? answer: | - 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 article further. Remove a mask if you're 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, consider un-enrolling from face authentication and only using PIN or fingerprint. + Wearing a mask to enroll is a security concern because other users wearing a similar mask may be able to unlock your device. Remove a mask if you're 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, consider un-enrolling from face authentication and only using PIN or fingerprint. - question: How does Windows Hello for Business work with Microsoft Entra registered devices? answer: | - A user will be prompted to set up a Windows Hello for Business key on a Microsoft Entra registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures. + A user will be prompted to set up a Windows Hello for Business key on a Microsoft Entra registered devices if the feature is enabled by policy. If the user has an existing Windows Hello container, the Windows Hello for Business key will be enrolled in that container and will be protected using existing gestures. If a user has signed into their Microsoft Entra registered device with Windows Hello, their Windows Hello for Business key will be used to authenticate the user's work identity when they try to use Microsoft Entra resources. The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources. It's possible to Microsoft Entra register a domain joined device. If the domain joined device has a convenience PIN, sign in with the convenience PIN will no longer work. This configuration isn't supported by Windows Hello for Business. - For more information, please read [Microsoft Entra registered devices](/azure/active-directory/devices/concept-azure-ad-register). + For more information, see [Microsoft Entra registered devices](/azure/active-directory/devices/concept-azure-ad-register). - question: Does Windows Hello for Business work with non-Windows operating systems? answer: | - Windows Hello for Business is a feature of the Windows platform. At this time, Microsoft isn't developing clients for other platforms. However, Microsoft is open to third-parties who are interested in moving these platforms away from passwords. Interested third-parties can get more information by emailing [whfbfeedback@microsoft.com](mailto:whfbfeedback@microsoft.com?subject=collaboration). + Windows Hello for Business is a feature of the Windows platform. - question: Does Windows Hello for Business work with Microsoft Entra Domain Services clients? answer: | No, Microsoft Entra Domain Services is a separately managed environment in Azure, and hybrid device registration with cloud Microsoft Entra ID isn't available for it via Microsoft Entra Connect. Hence, Windows Hello for Business doesn't work with Microsoft Entra Domain Services. @@ -191,7 +166,7 @@ sections: - question: Which is a better or more secure for of authentication, key or certificate? answer: | Both types of authentication provide the same security; one is not more secure than the other. - The trust models of your deployment determine how you authenticate to Active Directory (on-premises). Both key trust and certificate trust use the same hardware-backed, two-factor credential. The difference between the two trust types is the issuance of end-entity certificates: + The trust models of your deployment determine how you authenticate to Active Directory. Both key trust and certificate trust use the same hardware-backed, two-factor credential. The difference between the two trust types is the issuance of end-entity certificates: - The *key trust* model authenticates to Active Directory by using a raw key. Key trust doesn't require an enterprise-issued certificate, therefore you don't need to issue certificates to users (domain controller certificates are still needed) - The *certificate trust* model authenticates to Active Directory by using a certificate. Therefore, you need to issue certificates to users. The certificate used in certificate trust uses the TPM-protected private key to request a certificate from your enterprise's issuing CA - question: What is convenience PIN? @@ -202,7 +177,7 @@ sections: No. While it's possible to set a convenience PIN on Microsoft Entra joined and Microsoft Entra hybrid joined devices, convenience PIN isn't supported for Microsoft Entra user accounts (including synchronized identities). Convenience PIN is only supported for on-premises Active Directory users and local account users. - question: What about virtual smart cards? answer: | - Windows Hello for Business is the modern, two-factor authentication for Windows. Microsoft will deprecate virtual smart cards in the near future. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business. Microsoft will publish the deprecation date to ensure customers have adequate lead time to move to Windows Hello for Business. We recommend that new Windows deployments use Windows Hello for Business. + Windows Hello for Business is the modern, two-factor authentication for Windows. Customers using virtual smart cards are strongly encouraged to move to Windows Hello for Business. - question: What URLs do I need to allow for a hybrid deployment? answer: | For a list of required URLs, see [Microsoft 365 Common and Office Online](/microsoft-365/enterprise/urls-and-ip-address-ranges?view=o365-worldwide#microsoft-365-common-and-office-online). @@ -222,13 +197,13 @@ 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: - question: What is Windows Hello for Business cloud Kerberos trust? answer: | - Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment 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). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/hello-hybrid-cloud-kerberos-trust). + Windows Hello for Business *cloud Kerberos trust* is a *trust model* that enables Windows Hello for Business deployment 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). Cloud Kerberos trust is the preferred deployment model if you do not need to support certificate authentication scenarios. For more information, see [cloud Kerberos trust deployment](/windows/security/identity-protection/hello-for-business/deploy). - question: Does Windows Hello for Business cloud Kerberos trust work in my on-premises environment? answer: | This feature doesn't work in a pure on-premises AD domain services environment. @@ -242,7 +217,7 @@ sections: - attempting to access on-premises resources secured by Active Directory - question: Can I use RDP/VDI with Windows Hello for Business cloud Kerberos trust? answer: | - Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP with [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) or if a [certificate is enrolled into Windows Hello for Business](rdp-sign-in.md) for this purpose. + Windows Hello for Business cloud Kerberos trust can't be used as a supplied credential with RDP/VDI. Similar to key trust, cloud Kerberos trust can be used for RDP if a [certificate is enrolled into Windows Hello for Business](rdp-sign-in.md) for this purpose. As an alternative, consider using [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) which doesn't require to deploy certificates. - question: Do all my domain controllers need to be fully patched as per the prerequisites for me to use Windows Hello for Business cloud Kerberos trust? answer: | No, only the number necessary to handle the load from all cloud Kerberos trust devices. @@ -254,4 +229,4 @@ sections: In a hybrid deployment, a user's public key must sync from Microsoft Entra ID to Active Directory before it can be used to authenticate against a domain controller. This sync is handled by Microsoft Entra Connect and will occur during a normal sync cycle. - question: Can I use Windows Hello for Business key trust and RDP? answer: | - Remote Desktop Protocol (RDP) doesn't currently support using key-based authentication and self-signed certificates as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). In addition, Windows Hello for Business key trust can be also used with RDP with [Remote Credential Guard](../remote-credential-guard.md) without deploying certificates. + Remote Desktop Protocol (RDP) doesn't support using key-based authentication as supplied credentials. However, you can deploy certificates in the key trust model to enable RDP. For more information, see [Deploying certificates to key trust users to enable RDP](hello-deployment-rdp-certs.md). As an alternative, consider using [Remote Credential Guard](/windows/security/identity-protection/remote-credential-guard) which doesn't require to deploy certificates. diff --git a/windows/security/identity-protection/hello-for-business/hello-and-password-changes.md b/windows/security/identity-protection/hello-for-business/hello-and-password-changes.md deleted file mode 100644 index 3d9b51898d..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-and-password-changes.md +++ /dev/null @@ -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. diff --git a/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md b/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md deleted file mode 100644 index d80393b040..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-biometrics-in-enterprise.md +++ /dev/null @@ -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.
      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): <0.001 – 0.002% - -- Effective, real world FRR with Anti-spoofing or liveness detection: <10% - -**Acceptable performance range for swipe sensors** - -- False Accept Rate (FAR): <0.002% - -- Effective, real world FRR with Anti-spoofing or liveness detection: <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): <0.001% - -- False Reject Rate (FRR) without Anti-spoofing or liveness detection: <5% - -- Effective, real world FRR with Anti-spoofing or liveness detection: <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) diff --git a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md index b5c4e51668..a1df8320f4 100644 --- a/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md +++ b/windows/security/identity-protection/hello-for-business/hello-deployment-issues.md @@ -4,12 +4,11 @@ description: This article is a troubleshooting guide for known Windows Hello for ms.date: 06/02/2023 ms.topic: troubleshooting --- + # Windows Hello for Business known deployment issues The content of this article is to help troubleshoot known deployment issues for Windows Hello for Business. - - ## 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 +49,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)). - - ## Microsoft Entra joined device access to on-premises resources using key trust and third-party Certificate Authority (CA) Applies to: @@ -71,10 +68,10 @@ The issue can be identified using network traces or Kerberos logging from the cl Log Name: Microsoft-Windows-Kerberos/Operational Source: Microsoft-Windows-Security-Kerberos Event ID: 107 -GUID: {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1} +GUID: {98e6cfcb-ee0a-41e0-a57b-622d4e1b30b1} Task Category: None Level: Error -Keywords: +Keywords: User: SYSTEM Description: @@ -137,7 +134,7 @@ Date: Event ID: 362 Task Category: None Level: Warning -Keywords: +Keywords: User: Computer: Description: @@ -150,7 +147,7 @@ Local computer meets Windows hello for business hardware requirements: Yes User is not connected to the machine via Remote Desktop: Yes User certificate for on premise auth policy is enabled: Yes Enterprise user logon certificate enrollment endpoint is ready: Not Tested -Enterprise user logon certificate template is : No ( 1 : StateNoPolicy ) +Enterprise user logon certificate template is : No ( 1 : StateNoPolicy ) User has successfully authenticated to the enterprise STS: No Certificate enrollment method: enrollment authority See https://go.microsoft.com/fwlink/?linkid=832647 for more details. diff --git a/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md b/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md index d048d6409f..2c3b021381 100644 --- a/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md +++ b/windows/security/identity-protection/hello-for-business/hello-errors-during-pin-creation.md @@ -2,7 +2,7 @@ title: Windows Hello errors during PIN creation description: When you set up Windows Hello, you may get an error during the Create a work PIN step. ms.topic: troubleshooting -ms.date: 04/24/2023 +ms.date: 01/26/2024 --- # Windows Hello errors during PIN creation @@ -13,7 +13,7 @@ When you set up Windows Hello in Windows client, you may get an error during the The following image shows an example of an error during **Create a PIN**. -![PIN error.](images/pinerror.png) +![PIN error.](images/provisioning-error.png) ## Error mitigations @@ -28,12 +28,12 @@ If the error occurs again, check the error code against the following table to s | Hex | Cause | Mitigation | | :--------- | :----------------------------------------------------------------- | :------------------------------------------ | -| 0x80090005 | NTE\_BAD\_DATA | Unjoin the device from Microsoft Entra ID and rejoin. | +| 0x80090005 | NTE_BAD_DATA | Unjoin the device from Microsoft Entra ID and rejoin. | | 0x8009000F | The container or key already exists. | Unjoin the device from Microsoft Entra ID and rejoin. | | 0x80090011 | The container or key was not found. | Unjoin the device from Microsoft Entra ID and rejoin. | | 0x80090029 | TPM is not set up. | Sign on with an administrator account. Select **Start**, type `tpm.msc`, and select **tpm.msc Microsoft Common Console Document**. In the **Actions** pane, select **Prepare the TPM**. | -| 0x8009002A | NTE\_NO\_MEMORY | Close programs which are taking up memory and try again. | -| 0x80090031 | NTE\_AUTHENTICATION\_IGNORED | Reboot the device. If the error occurs again after rebooting, [reset the TPM](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd851452(v=ws.11)) or run [Clear-TPM](/powershell/module/trustedplatformmodule/clear-tpm). | +| 0x8009002A | NTE_NO_MEMORY | Close programs which are taking up memory and try again. | +| 0x80090031 | NTE_AUTHENTICATION_IGNORED | Reboot the device. If the error occurs again after rebooting, [reset the TPM](/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd851452(v=ws.11)) or run [Clear-TPM](/powershell/module/trustedplatformmodule/clear-tpm). | | 0x80090035 | Policy requires TPM and the device does not have TPM. | Change the Windows Hello for Business policy to not require a TPM. | | 0x80090036 | User canceled an interactive dialog. | User will be asked to try again. | | 0x801C0003 | User is not authorized to enroll. | Check if the user has permission to perform the operation​. | @@ -53,11 +53,11 @@ If the error occurs again, check the error code against the following table to s | 0x801C03ED | Multi-factor authentication is required for a 'ProvisionKey' operation, but was not performed.

      -or-

      Token was not found in the Authorization header.

      -or-

      Failed to read one or more objects.

      -or-

      The request sent to the server was invalid.

      -or-

      User does not have permissions to join to Microsoft Entra ID. | Sign out and then sign in again. If that doesn't resolve the issue, unjoin the device from Azure AD and rejoin.
      Allow user(s) to join to Microsoft Entra ID under Microsoft Entra Device settings. | 0x801C03EE | Attestation failed. | Sign out and then sign in again. | | 0x801C03EF | The AIK certificate is no longer valid. | Sign out and then sign in again. | -| 0x801C03F2 | Windows Hello key registration failed. | ERROR\_BAD\_DIRECTORY\_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Microsoft Entra ID and the Primary SMTP address are the same in the proxy address. +| 0x801C03F2 | Windows Hello key registration failed. | ERROR_BAD_DIRECTORY_REQUEST. Another object with the same value for property proxyAddresses already exists. To resolve the issue, refer to [Duplicate Attributes Prevent Dirsync](/office365/troubleshoot/administration/duplicate-attributes-prevent-dirsync). Also, if no sync conflict exists, please verify that the "Mail/Email address" in Microsoft Entra ID and the Primary SMTP address are the same in the proxy address. | 0x801C044D | Authorization token does not contain device ID. | Unjoin the device from Microsoft Entra ID and rejoin. | | | Unable to obtain user token. | Sign out and then sign in again. Check network and credentials. | | 0x801C044E | Failed to receive user credentials input. | Sign out and then sign in again. | -| 0x801C0451 | User token switch account. | Delete the Web Account Manager token broker files located in `%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts\*.*\` and reboot.| +| 0x801C0451 | User token switch account. | Delete the Web Account Manager token broker files located in `%LOCALAPPDATA%\Packages\Microsoft.AAD.BrokerPlugin_cw5n1h2txyewy\AC\TokenBroker\Accounts\*.*\` and reboot.| | 0xC00000BB | Your PIN or this option is temporarily unavailable. | The destination domain controller doesn't support the login method. Most often the KDC service doesn't have the proper certificate to support the login. Another common cause can be the client cannot verify the KDC certificate CRL. Use a different login method.| ## Errors with unknown mitigation @@ -70,9 +70,9 @@ For errors listed in this table, contact Microsoft Support for assistance. | 0X80072F0C | Unknown | | 0x80072F8F | A mismatch happens between the system's clock and the activation server's clock when attempting to activate Windows.| | 0x80090010 | NTE_PERM | -| 0x80090020 | NTE\_FAIL | +| 0x80090020 | NTE_FAIL | | 0x80090027 | Caller provided a wrong parameter. If third-party code receives this error, they must change their code. | -| 0x8009002D | NTE\_INTERNAL\_ERROR | +| 0x8009002D | NTE_INTERNAL_ERROR | | 0x801C0001 | ADRS server response is not in a valid format. | | 0x801C0002 | Server failed to authenticate the user. | | 0x801C0006 | Unhandled exception from server. | diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md deleted file mode 100644 index 3ed49353ea..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-technology.md +++ /dev/null @@ -1,412 +0,0 @@ ---- -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 -ms.topic: glossary ---- - -# Technology and terms - -## Attestation identity keys - -Because the endorsement certificate is unique for each device and doesn't change, the usage of it may present privacy concerns because it's theoretically possible to track a specific device. To avoid this privacy problem, Windows issues a derived attestation anchor based on the endorsement certificate. This intermediate key, which can be attested to an endorsement key, is the Attestation Identity Key (AIK) and the corresponding certificate is called the AIK certificate. This AIK certificate is issued by a Microsoft cloud service. - -> [!NOTE] -> The AIK certificate must be provisioned in conjunction with a third-party service like the Microsoft Cloud CA service. After it is provisioned, the AIK private key can be used to report platform configuration. Windows creates a signature over the platform log state (and a monotonic counter value) at each boot by using the AIK. -> The AIK is an asymmetric (public/private) key pair that is used as a substitute for the EK as an identity for the TPM for privacy purposes. The private portion of an AIK is never revealed or used outside the TPM and can only be used inside the TPM for a limited set of operations. Furthermore, it can only be used for signing, and only for limited, TPM-defined operations. - -Windows creates AIKs protected by the TPM, if available, that are 2048-bit RSA signing keys. Microsoft hosts a cloud service called Microsoft Cloud CA to establish cryptographically that it's communicating with a real TPM and that the TPM possesses the presented AIK. After the Microsoft Cloud CA service has established these facts, it will issue an AIK certificate to the Windows device. - -Many existing devices that will upgrade to Windows 10 won't have a TPM, or the TPM won't contain an endorsement certificate. **To accommodate those devices, Windows 10 or Windows 11 allows the issuance of AIK certificates without the presence of an endorsement certificate.** Such AIK certificates aren't issued by Microsoft Cloud CA. This behavior isn't as trustworthy as an endorsement certificate that is burned into the device during manufacturing, but it will provide compatibility for advanced scenarios like Windows Hello for Business without TPM. - -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/) - - - -## 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. - - - -### Related to Microsoft Entra join - -- [Join type](#join-type) -- [Microsoft Entra hybrid join](#hybrid-azure-ad-join) - - - -### More information about Microsoft Entra join - -[Introduction to device identity in Microsoft Entra ID](/azure/active-directory/devices/overview). - - - -## 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. - - - -### Related to Microsoft Entra registration - -- [Microsoft Entra join](#azure-active-directory-join) -- [Microsoft Entra hybrid join](#hybrid-azure-ad-join) -- [Join type](#join-type) - - - -### 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.\ -With cloud Kerberos trust, there's no need to deploy certificates to the users or to the domain controllers, which is ideal for environments without an existing PKI. - -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: - -- Cloud -- 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). - -The endorsement key public key is used for sending securely sensitive parameters, such as when taking possession of the TPM that contains the defining hash of the owner password. The EK private key is used when creating secondary keys like AIKs. - -The endorsement key acts as an identity card for the TPM. - -The endorsement key is often accompanied by one or two digital certificates: - -- One certificate is produced by the TPM manufacturer and is called the **endorsement certificate**. The endorsement certificate is used to prove the authenticity of the TPM (for example, that it's a real TPM manufactured by a specific chip maker) to local processes, applications, or cloud services. The endorsement certificate is created during manufacturing or the first time the TPM is initialized by communicating with an online service. - -- The other certificate is produced by the platform builder and is called the **platform certificate** to indicate that a specific TPM is integrated with a certain device. - -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) - - - -## Microsoft Entra hybrid join - -For more than a decade, many organizations have used the domain join to their on-premises Active Directory to enable: - -- IT departments to manage work-owned devices from a central location. -- Users to sign in to their devices with their Active Directory work or school accounts. - -Typically, organizations with an on-premises footprint rely on imaging methods to provision devices, and they often use or group policy to manage them. - -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. - - - -### Related to Microsoft Entra hybrid join - -- [Microsoft Entra join](#azure-active-directory-join) -- [Microsoft Entra registration](#azure-ad-registration) -- [Hybrid deployment](#hybrid-deployment) - - - -### 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. - -Registering a device to Microsoft Entra ID enables you to manage a device's identity. When a device is registered, Microsoft Entra device registration provides the device with an identity that is used to authenticate the device when a user signs-in to Microsoft Entra ID. You can use the identity to enable or disable a device. - -When combined with a mobile device management (MDM) solution such as Microsoft Intune, the device attributes in Microsoft Entra ID are updated with additional information about the device. This behavior allows you to create conditional access rules that enforce access from devices to meet your standards for security and compliance. For more information on enrolling devices in Microsoft Intune, see Enroll devices for management in Intune. - -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. - -The PRT is initially obtained during Windows user sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Microsoft Entra joined and Microsoft Entra hybrid joined devices. For personal devices registered with Microsoft Entra ID, the PRT is initially obtained upon Add Work or School Account. For a personal device the account to unlock the device isn't the work account, but a consumer account. For example, hotmail.com, live.com, or outlook.com. - -The PRT is needed for SSO. Without it, the user will be prompted for credentials when accessing applications every time. The PRT also contains information about the device. If you have any [device-based conditional access](/azure/active-directory/conditional-access/concept-conditional-access-grant) policy set on an application, without the PRT, access will be denied. - -## Storage root key - -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. - -Windows uses security characteristics of a TPM for the following functions: - -- Measuring boot integrity sequence. Based on that sequence, it automatically unlocks BitLocker-protected drives -- Protecting credentials -- Health attestation - -A TPM implements controls that meet the specification described by the Trusted Computing Group (TCG). There are currently two versions of the TPM specification produced by TCG that aren't compatible with each other: - -- The first TPM specification, version 1.2, was published in February 2005 by the TCG and standardized under ISO / IEC 11889 standard. -- The latest TPM specification, referred to as TPM 2.0, was released in April 2014 and has been approved by the ISO/IEC Joint Technical Committee (JTC) as ISO/IEC 11889:2015. - -Windows 10 and Windows 11 use the TPM for cryptographic calculations as part of health attestation and to protect the keys for BitLocker, Windows Hello, virtual smart cards, and other public key certificates. For more information, see [TPM requirements in Windows](../../hardware-security/tpm/tpm-recommendations.md). - -Windows recognizes versions 1.2 and 2.0 TPM specifications produced by the TCG. For the most recent and modern security features, Windows 10 and Windows 11 support only TPM 2.0. - -TPM 2.0 provides a major revision to the capabilities over TPM 1.2: - -- Update cryptography strength to meet modern security needs - - Support for SHA-256 for PCRs - - Support for HMAC command -- Cryptographic algorithms flexibility to support government needs - - TPM 1.2 is severely restricted in terms of what algorithms it can support - - TPM 2.0 can support arbitrary algorithms with minor updates to the TCG specification documents -- Consistency across implementations - - The TPM 1.2 specification allows vendors wide latitude when choosing implementation details - - TPM 2.0 standardizes much of this behavior - -In a simplified manner, the TPM is a passive component with limited resources. It can calculate random numbers, RSA keys, decrypt short data, store hashes taken when booting the device. A TPM incorporates in a single component: - -- An RSA 2048-bit key generator -- A random number generator -- 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/) diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works.md b/windows/security/identity-protection/hello-for-business/hello-how-it-works.md deleted file mode 100644 index d8f299c354..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works.md +++ /dev/null @@ -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) diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md index ba06402421..1b1ad680bf 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso-cert.md @@ -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. - - ## 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. - - ### 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. - - ### 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. diff --git a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md index 4a2846f9e6..f1666e6453 100644 --- a/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md +++ b/windows/security/identity-protection/hello-for-business/hello-hybrid-aadj-sso.md @@ -4,6 +4,7 @@ description: Learn how to configure single sign-on to on-premises resources for ms.date: 12/30/2022 ms.topic: how-to --- + # Configure single sign-on for Microsoft Entra joined devices [!INCLUDE [apply-to-hybrid-key-and-cert-trust](deploy/includes/apply-to-hybrid-key-and-cert-trust.md)] @@ -65,7 +66,7 @@ Use this set of procedures to update the CA that issues domain controller certif You need to host your new certificate revocation list on a web server so Microsoft Entra joined devices can easily validate certificates without authentication. You can host these files on web servers many ways. The following steps are just one and may be useful for admins unfamiliar with adding a new CRL distribution point. > [!IMPORTANT] -> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. +> Do not configure the IIS server hosting your CRL distribution point to use https or a server authentication certificate. Clients should access the distribution point using http. ### Install the web server @@ -119,7 +120,7 @@ These procedures configure NTFS and share permissions on the web server to allow > [!Tip] > Make sure that users can access **\\\Server FQDN\sharename**. -### Disable Caching +### Disable Caching 1. On the web server, open **Windows Explorer** and navigate to the **cdp** folder you created in step 3 of [Configure the Web Server](#configure-the-web-server) 1. Right-click the **cdp** folder and select **Properties**. Select the **Sharing** tab. Select **Advanced Sharing** 1. Select **Caching**. Select **No files or programs from the shared folder are available offline** @@ -190,7 +191,7 @@ Validate the new CRL distribution point is working. #### Reissue domain controller certificates -With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. +With the CA properly configured with a valid HTTP-based CRL distribution point, you need to reissue certificates to domain controllers as the old certificate doesn't have the updated CRL distribution point. 1. Sign-in a domain controller using administrative credentials 1. Open the **Run** dialog box. Type **certlm.msc** to open the **Certificate Manager** for the local computer @@ -217,8 +218,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) - - ## 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. diff --git a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md b/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md deleted file mode 100644 index 896453d0bf..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-manage-in-organization.md +++ /dev/null @@ -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.
      - **Enabled**: Device provisions Windows Hello for Business using keys or certificates for all users.
      - **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.
      - **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.
      - **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.
      - **Enabled**: Windows Hello for Business enrolls a sign-in certificate using ADFS that is used for on-premises authentication.
      - **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
      - **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
      - **Enabled**: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset
      - **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.
      - 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
      - **Enabled**: Biometrics can be used as a gesture in place of a PIN.
      - **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.
      - **Enabled**: Users must include a digit in their PIN.
      - **Disabled**: Users can't use digits in their PIN.| -|Require lowercase letters|Computer|- **Not configured**: Users can't use lowercase letters in their PIN
      - **Enabled**: Users must include at least one lowercase letter in their PIN.
      - **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.
      - **Enabled**: PIN length must be less than or equal to the number you specify.
      - **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.
      - **Enabled**: PIN length must be greater than or equal to the number you specify.
      - **Disabled**: PIN length must be greater than or equal to 4.| -|Expiration|Computer|- **Not configured**: PIN doesn't expire.
      - **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.
      - **Disabled**: PIN doesn't expire.| -|History|Computer|- **Not configured**: Previous PINs aren't stored.
      - **Enabled**: Specify the number of previous PINs that can be associated to a user account that can't be reused.
      - **Disabled**: Previous PINs aren't stored.
      **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.
      - **Enabled**: Windows requires the user to include at least one special character in their PIN.
      - **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.
      - **Enabled**: Users must include at least one uppercase letter in their PIN.
      - **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.
      - False: Users won't be able to provision Windows Hello for Business.
      **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.
      - False: Windows Hello for Business will be provisioned using TPM if available, and will be provisioned using software if TPM isn't available.| -|ExcludeSecurityDevice
      - TPM12|Device|False|Added in Windows 10, version 1703
      - True: TPM revision 1.2 modules will be disallowed from being used with Windows Hello for Business.
      - 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
      - True: Windows Hello for Business uses the Azure-based PIN recovery service for PIN reset.
      - 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.
      - False: Only a PIN can be used as a gesture for domain sign-in.| -|- FacialFeaturesUser
      - EnhancedAntiSpoofing|Device|Not configured|- Not configured: users can choose whether to turn on enhanced anti-spoofing.
      - True: Enhanced anti-spoofing is required on devices which support it.
      - False: Users can't turn on enhanced anti-spoofing.| - -### PINComplexity - -|Policy|Scope|Default|Options| -|--- |--- |--- |--- | -|Digits |Device or user|1 |- 0: Digits are allowed.
      - 1: At least one digit is required.
      - 2: Digits aren't allowed.| -|Lowercase letters |Device or user|2|- 0: Lowercase letters are allowed.
      - 1: At least one lowercase letter is required.
      - 2: Lowercase letters aren't allowed.| -|Special characters|Device or user|2|- 0: Special characters are allowed.
      - 1: At least one special character is required.
      - 2: Special characters aren't allowed.| -|Uppercase letters|Device or user|2|- 0: Uppercase letters are allowed.
      - 1: At least one uppercase letter is required.
      - 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. diff --git a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md b/windows/security/identity-protection/hello-for-business/hello-planning-guide.md deleted file mode 100644 index 55a70b9a89..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-planning-guide.md +++ /dev/null @@ -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**. - Optionally, you may write **1511 or later* 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. diff --git a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md b/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md deleted file mode 100644 index 52459fe655..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-prepare-people-to-use.md +++ /dev/null @@ -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** > **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. - -## 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) diff --git a/windows/security/identity-protection/hello-for-business/hello-videos.md b/windows/security/identity-protection/hello-for-business/hello-videos.md deleted file mode 100644 index 24b362c125..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-videos.md +++ /dev/null @@ -1,36 +0,0 @@ ---- -title: Windows Hello for Business Videos -description: View several informative videos describing features and experiences in Windows Hello for Business in Windows 10 and Windows 11. -ms.date: 09/07/2023 -ms.topic: get-started ---- -# Windows Hello for Business Videos -## Overview of Windows Hello for Business and Features - -Watch Pieter Wigleven explain Windows Hello for Business, Multi-factor Unlock, and Dynamic Lock - -> [!VIDEO https://www.youtube.com/embed/G-GJuDWbBE8] - -## Why PIN is more secure than a password - -Watch Dana Huang explain why a Windows Hello for Business PIN is more secure than a password. - -> [!VIDEO https://www.youtube.com/embed/cC24rPBvdhA] - -## Microsoft's passwordless strategy - -Watch Karanbir Singh's Ignite 2017 presentation **Microsoft's guide for going password-less** - -> [!VIDEO https://www.youtube.com/embed/mXJS615IGLM] - -## Windows Hello for Business Provisioning - -Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business provisioning works. - -> [!VIDEO https://www.youtube.com/embed/RImGsIjSJ1s] - -## Windows Hello for Business Authentication - -Watch Matthew Palko and Ravi Vennapusa explain how Windows Hello for Business authentication works. - -> [!VIDEO https://www.youtube.com/embed/WPmzoP_vMek] \ No newline at end of file diff --git a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md b/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md deleted file mode 100644 index 6fe91595bc..0000000000 --- a/windows/security/identity-protection/hello-for-business/hello-why-pin-is-better-than-password.md +++ /dev/null @@ -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. diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md b/windows/security/identity-protection/hello-for-business/how-it-works-authentication.md similarity index 81% rename from windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md rename to windows/security/identity-protection/hello-for-business/how-it-works-authentication.md index af0ff0de5a..5bd47775ff 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-authentication.md +++ b/windows/security/identity-protection/hello-for-business/how-it-works-authentication.md @@ -1,7 +1,7 @@ --- title: How Windows Hello for Business authentication works description: Learn about the Windows Hello for Business authentication flows. -ms.date: 05/24/2023 +ms.date: 01/03/2024 ms.topic: reference --- # Windows Hello for Business authentication @@ -10,11 +10,9 @@ 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. - - ## Microsoft Entra join authentication to Microsoft Entra ID -![Microsoft Entra join authentication to Microsoft Entra ID.](images/howitworks/auth-aadj-cloud.png) +:::image type="content" source="images/howitworks/auth/entra-join-entra.png" alt-text="Diagram of a Microsoft Entra join device authenticating to Microsoft Entra ID." lightbox="images/howitworks/auth/entra-join-entra.png" border="false"::: > [!NOTE] > All Microsoft Entra joined devices authenticate with Windows Hello for Business to Microsoft Entra ID the same way. The Windows Hello for Business trust type only impacts how the device authenticates to on-premises AD. @@ -27,37 +25,31 @@ 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.| - - ## 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) +:::image type="content" source="images/howitworks/auth/entra-join-ad-ckt.png" alt-text="Diagram of a Microsoft Entra join device authenticating to Active Directory using cloud Kerberos trust." lightbox="images/howitworks/auth/entra-join-ad-ckt.png" border="false"::: | Phase | Description | | :----: | :----------- | -|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. +|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 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.| - - ## 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) +:::image type="content" source="images/howitworks/auth/entra-join-ad-kt.png" alt-text="Diagram of a Microsoft Entra join device authenticating to Active Directory using key trust." lightbox="images/howitworks/auth/entra-join-ad-kt.png" border="false"::: | Phase | Description | | :----: | :----------- | -|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. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.| -|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
      The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| +|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 domain controller. After the provider locates a domain controller, the provider uses the private key to sign the Kerberos preauthentication data.| +|B | The Kerberos provider sends the signed preauthentication data and its public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.
      The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.| > [!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. - - ## 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) +:::image type="content" source="images/howitworks/auth/entra-join-ad-ct.png" alt-text="Diagram of a Microsoft Entra join device authenticating to Active Directory using certificate trust." lightbox="images/howitworks/auth/entra-join-ad-ct.png" border="false"::: | Phase | Description | | :----: | :----------- | @@ -68,11 +60,9 @@ 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. - - ## Microsoft Entra hybrid join authentication using cloud Kerberos trust -![Microsoft Entra hybrid join authentication using Microsoft Entra Kerberos](images/howitworks/auth-haadj-cloudtrust.png) +:::image type="content" source="images/howitworks/auth/hybrid-entra-join-ckt.png" alt-text="Diagram of a Microsoft Entra hybrid join device authenticating to Active Directory using cloud Kerberos trust." lightbox="images/howitworks/auth/hybrid-entra-join-ckt.png" border="false"::: | Phase | Description | | :----: | :----------- | @@ -80,18 +70,16 @@ Microsoft Entra joined devices authenticate to Microsoft Entra ID during sign-in |B | Cloud AP signs the nonce using the user's private key and returns the signed nonce to Microsoft Entra ID. |C | Microsoft Entra ID validates the signed nonce using the user's securely registered public key against the nonce signature. After validating the signature, Microsoft Entra ID then validates the returned signed nonce. After validating the nonce, Microsoft Entra ID creates a PRT with session key that is encrypted to the device's transport key and creates a Partial TGT from Microsoft Entra Kerberos and returns them to Cloud AP. |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.| - - +|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 domain controller. After locating an active 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.| ## Microsoft Entra hybrid join authentication using a key -![Microsoft Entra hybrid join authentication using a key.](images/howitworks/auth-haadj-keytrust.png) +:::image type="content" source="images/howitworks/auth/hybrid-entra-join-kt.png" alt-text="Diagram of a Microsoft Entra hybrid join device authenticating to Active Directory using key trust." lightbox="images/howitworks/auth/hybrid-entra-join-kt.png" border="false"::: | Phase | Description | | :----: | :----------- | |A | Authentication begins when the user dismisses the lock screen, which triggers Winlogon to show the Windows Hello for Business credential provider. The user provides their Windows Hello gesture (PIN or biometrics). The credential provider packages these credentials and returns them to Winlogon. Winlogon passes the collected credentials to lsass. Lsass passes the collected credentials to the Kerberos security support provider. The Kerberos provider gets domain hints from the domain joined workstation to locate a domain controller for the user.| -|B | The Kerberos provider sends the signed preauthentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the 2016 domain controller in the form of a KERB_AS_REQ.
      The 2016 domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| +|B | The Kerberos provider sends the signed preauthentication data and the user's public key (in the form of a self-signed certificate) to the Key Distribution Center (KDC) service running on the domain controller in the form of a KERB_AS_REQ.
      The domain controller determines the certificate is a self-signed certificate. It retrieves the public key from the certificate included in the KERB_AS_REQ and searches for the public key in Active Directory. It validates the UPN for authentication request matches the UPN registered in Active Directory and validates the signed preauthentication data using the public key from Active Directory. On success, the KDC returns a TGT to the client with its certificate in a KERB_AS_REP.| |C | The Kerberos provider ensures it can trust the response from the domain controller. First, it ensures the KDC certificate chains to a root certificate that is trusted by the device. Next, it ensures the certificate is within its validity period and that it hasn't been revoked. The Kerberos provider then verifies the certificate has the KDC Authentication present and that the subject alternate name listed in the KDC's certificate matches the domain name to which the user is authenticating. |D | After passing this criteria, Kerberos returns the TGT to lsass, where it's cached and used for subsequent service ticket requests.| |E | Lsass informs Winlogon of the success authentication. Winlogon creates a logon session, loads the user's profile, and starts explorer.exe.| @@ -101,11 +89,9 @@ 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. - - ## Microsoft Entra hybrid join authentication using a certificate -![Microsoft Entra hybrid join authentication using a Certificate.](images/howitworks/auth-haadj-certtrust.png) +:::image type="content" source="images/howitworks/auth/hybrid-entra-join-ct.png" alt-text="Diagram of a Microsoft Entra hybrid join device authenticating to Active Directory using certificate trust." lightbox="images/howitworks/auth/hybrid-entra-join-ct.png" border="false"::: | Phase | Description | | :----: | :----------- | diff --git a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md b/windows/security/identity-protection/hello-for-business/how-it-works-provisioning.md similarity index 85% rename from windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md rename to windows/security/identity-protection/hello-for-business/how-it-works-provisioning.md index b2e01e88dd..9c6ef249eb 100644 --- a/windows/security/identity-protection/hello-for-business/hello-how-it-works-provisioning.md +++ b/windows/security/identity-protection/hello-for-business/how-it-works-provisioning.md @@ -1,7 +1,7 @@ --- title: How Windows Hello for Business provisioning works description: Explore the provisioning flows for Windows Hello for Business, from within a variety of environments. -ms.date: 12/12/2022 +ms.date: 01/03/2024 ms.topic: reference appliesto: --- @@ -14,23 +14,12 @@ Windows Hello for Business provisioning enables a user to enroll a new, strong, - The Windows Hello for Business deployment type - If the environment is managed or federated -List of provisioning flows: - -- [Microsoft Entra joined provisioning in a managed environment](#microsoft-entra-joined-provisioning-in-a-managed-environment) -- [Microsoft Entra joined provisioning in a federated environment](#microsoft-entra-joined-provisioning-in-a-federated-environment) -- [Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-cloud-kerberos-trust-deployment-in-a-managed-environment) -- [Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment](#microsoft-entra-hybrid-joined-provisioning-in-a-key-trust-deployment-in-a-managed-environment) -- [Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment](#microsoft-entra-hybrid-joined-provisioning-in-a-synchronous-certificate-trust-deployment-in-a-federated-environment) -- [Domain joined provisioning in an On-premises key trust deployment](#domain-joined-provisioning-in-an-on-premises-key-trust-deployment) -- [Domain joined provisioning in an On-premises certificate trust deployment](#domain-joined-provisioning-in-an-on-premises-certificate-trust-deployment) - > [!NOTE] > The flows in this section are not exhaustive for every possible scenario. For example, Federated Key Trust is also a supported configuration. -## Microsoft Entra joined provisioning in a managed environment +## Provisioning for Microsoft Entra joined devices with managed authentication -![Microsoft Entra joined provisioning in a managed environment.](images/howitworks/prov-aadj-managed.png) -[Full size image](images/howitworks/prov-aadj-managed.png) +:::image type="content" source="images/howitworks/prov/entra-join-managed.png" alt-text="Sequence diagram of the Windows Hello provisioning flow for Microsoft Entra joined devices with managed authentication." lightbox="images/howitworks/prov/entra-join-managed.png" border="false"::: | Phase | Description | |:-:|:-| @@ -38,10 +27,9 @@ List of provisioning flows: | B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). | | C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits. | -## Microsoft Entra joined provisioning in a federated environment +## Provisioning for Microsoft Entra joined devices with federated authentication -![Microsoft Entra joined provisioning in federated environment.](images/howitworks/prov-aadj-federated.png) -[Full size image](images/howitworks/prov-aadj-federated.png) +:::image type="content" source="images/howitworks/prov/entra-join-federated.png" alt-text="Sequence diagram of the Windows Hello provisioning flow for Microsoft Entra joined devices with federated authentication." lightbox="images/howitworks/prov/entra-join-federated.png" border="false"::: | Phase | Description | |:-:|:-| @@ -49,10 +37,9 @@ List of provisioning flows: | B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). | | C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns key ID to the application, which signals the end of user provisioning and the application exits. | -## Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a managed environment +## Provisioning in a cloud Kerberos trust deployment model with managed authentication -![Microsoft Entra hybrid joined provisioning in a cloud Kerberos trust deployment in a Managed environment.](images/howitworks/prov-haadj-cloudtrust-managed.png) -[Full size image](images/howitworks/prov-haadj-cloudtrust-managed.png) +:::image type="content" source="images/howitworks/prov/hybrid-entra-join-ckt.png" alt-text="Sequence diagram of the Windows Hello provisioning flow in a hybrid cloud Kerberos trust deployment model with managed authentication." lightbox="images/howitworks/prov/hybrid-entra-join-ckt.png" border="false"::: | Phase | Description | |:-:|:-| @@ -63,25 +50,23 @@ List of provisioning flows: > [!NOTE] > Windows Hello for Business cloud Kerberos trust does not require users' keys to be synced from Microsoft Entra ID to Active Directory. Users can immediately authenticate to Microsoft Entra ID and AD after provisioning their credential. -## Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment +## Provisioning in a hybrid key trust deployment model with managed authentication -![Microsoft Entra hybrid joined provisioning in a key trust deployment in a managed environment.](images/howitworks/prov-haadj-keytrust-managed.png) -[Full size image](images/howitworks/prov-haadj-keytrust-managed.png) +:::image type="content" source="images/howitworks/prov/hybrid-entra-join-managed-kt.png" alt-text="Sequence diagram of the Windows Hello provisioning flow in a hybrid key trust deployment model with managed authentication." lightbox="images/howitworks/prov/hybrid-entra-join-managed-kt.png" border="false"::: | Phase | Description | |:-:|:-| | A | The provisioning application hosted in the Cloud Experience Host (CXH) starts provisioning by requesting an access token for the Azure Device Registration Service (ADRS). The application makes the request using the Microsoft Entra Web Account Manager plug-in.
      Users must provide two factors of authentication. In this phase, the user has already provided one factor of authentication, typically user name and password. The Microsoft Entra multifactor authentication service provides the second factor of authentication. If the user has performed Microsoft Entra multifactor authentication within the last 10 minutes, such as when registering the device from the out-of-box-experience (OOBE), then they aren't prompted for MFA because the current MFA remains valid.
      Microsoft Entra ID validates the access token request and the MFA claim associated with it, creates an ADRS access token, and returns it to the application. | | B | After receiving an ADRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv). | | C | The application sends the ADRS token, ukpub, attestation data, and device information to ADRS for user key registration. Azure DRS validates the MFA claim remains current. On successful validation, Azure DRS locates the user's object in Microsoft Entra ID, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. Microsoft Entra ID returns a key ID to the application, which signals the end of user provisioning and the application exits. | -| D | Microsoft Entra Connect requests updates on its next synchronization cycle. Microsoft Entra ID sends the user's public key that was securely registered through provisioning. Microsoft Entra Connect receives the public key and writes it to user's msDS-KeyCredentialLink attribute in Active Directory. | +| D | Microsoft Entra Connect requests updates on its next synchronization cycle. Microsoft Entra ID sends the user's public key that was securely registered through provisioning. Microsoft Entra Connect receives the public key and writes it to user's `msDS-KeyCredentialLink` attribute in Active Directory. | > [!IMPORTANT] > The newly provisioned user will not be able to sign in using Windows Hello for Business until Microsoft Entra Connect successfully synchronizes the public key to the on-premises Active Directory. -## Microsoft Entra hybrid joined provisioning in a synchronous certificate trust deployment in a federated environment +## Provisioning in a hybrid certificate trust deployment model with federated authentication -![Microsoft Entra hybrid joined provisioning in a synchronous Certificate trust deployment in a federated environment.](images/howitworks/prov-haadj-instant-certtrust-federated.png) -[Full size image](images/howitworks/prov-haadj-instant-certtrust-federated.png) +:::image type="content" source="images/howitworks/prov/hybrid-entra-join-federated.png" alt-text="Sequence diagram of the Windows Hello provisioning flow in a hybrid certificate trust deployment model with federated authentication." lightbox="images/howitworks/prov/hybrid-entra-join-federated.png" border="false"::: | Phase | Description | |:-|:-| @@ -96,10 +81,9 @@ List of provisioning flows: > [!IMPORTANT] > Synchronous certificate enrollment doesn't depend on Microsoft Entra Connect to synchronize the user's public key to issue the Windows Hello for Business authentication certificate. Users can sign-in using the certificate immediately after provisioning completes. Microsoft Entra Connect continues to synchronize the public key to Active Directory, but is not shown in this flow. -## Domain joined provisioning in an On-premises Key Trust deployment +## Provisioning in an on-premises key trust deployment model -![Domain joined provisioning in an On-premises Key Trust deployment.](images/howitworks/prov-onprem-keytrust.png) -[Full size image](images/howitworks/prov-onprem-keytrust.png) +:::image type="content" source="images/howitworks/prov/onprem-kt.png" alt-text="Sequence diagram of the Windows Hello provisioning flow in an on-premises key trust deployment model." lightbox="images/howitworks/prov/onprem-kt.png" border="false"::: | Phase | Description | | :----: | :----------- | @@ -107,10 +91,9 @@ List of provisioning flows: | B| After receiving an EDRS access token, the application detects if the device has a Windows Hello biometric compatible sensor. If the application detects a biometric sensor, it gives the user the choice to enroll biometrics. After completing or skipping biometric enrollment, the application requires the user to create a PIN and the default (and fall-back gesture when used with biometrics). The user provides and confirms their PIN. Next, the application requests a Windows Hello for Business key pair from the key pregeneration pool, which includes attestation data. This is the user key (ukpub/ukpriv).| |C | The application sends the EDRS token, ukpub, attestation data, and device information to the Enterprise DRS for user key registration. Enterprise DRS validates the MFA claim remains current. On successful validation, the Enterprise DRS locates the user's object in Active Directory, writes the key information to a multi-values attribute. The key information includes a reference to the device from which it was created. The Enterprise DRS returns a key ID to the application, which represents the end of user key registration.| -## Domain joined provisioning in an On-premises Certificate Trust deployment +## Provisioning in an on-premises certificate trust deployment model -![Domain joined provisioning in an On-premises Certificate Trust deployment.](images/howitworks/prov-onprem-certtrust.png) -[Full size image](images/howitworks/prov-onprem-certtrust.png) +:::image type="content" source="images/howitworks/prov/onprem-ct.png" alt-text="Sequence diagram of the Windows Hello provisioning flow in an on-premises certificate trust deployment model." lightbox="images/howitworks/prov/onprem-ct.png" border="false"::: | Phase | Description | | :----: | :----------- | diff --git a/windows/security/identity-protection/hello-for-business/how-it-works.md b/windows/security/identity-protection/hello-for-business/how-it-works.md new file mode 100644 index 0000000000..87250d1fa9 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/how-it-works.md @@ -0,0 +1,236 @@ +--- +title: How Windows Hello for Business works +description: Learn how Windows Hello for Business works, and how it can help you protect your organization. +ms.date: 01/09/2024 +ms.topic: concept-article +--- + +# How Windows Hello for Business works + +Windows Hello for Business is a distributed system that requires multiple technologies to work together. To simplify the explanation of how Windows Hello for Business works, let's break it down into five phases, which represent the chronological order of the deployment process. + +> [!NOTE] +> Two of these phases are required only for certain deployment scenarios. +> +> The deployment scenarios are described in the article: [Plan a Windows Hello for Business deployment](deploy/index.md). + +:::row::: + :::column span="1"::: + :::image type="content" source="images/howitworks/device-registration.png" alt-text="Icon representing the device registration phase." border="false"::: + :::column-end::: + :::column span="3"::: + #### Device registration phase + :::column-end::: +:::row-end::: + +In this phase, the device registers its identity with the identity provider (IdP), so that it can be associated and authenticate to the IdP. + +:::row::: + :::column span="1"::: + :::image type="content" source="images/howitworks/provision.png" alt-text="Icon representing the provisioning phase." border="false"::: + :::column-end::: + :::column span="3"::: + #### Provisioning phase + :::column-end::: +:::row-end::: + +During this phase, the user authenticates using one form of authentication (typically, username/password) to request a new Windows Hello for Business credential. The provisioning flow requires a second factor of authentication before it can generate a public/private key pair. The public key is registered with the IdP, mapped to the user account. + +:::row::: + :::column span="1"::: + :::image type="content" source="images/howitworks/synchronization.png" alt-text="Icon representing the synchronization phase." border="false"::: + :::column-end::: + :::column span="3"::: + #### Key synchronization phase + :::column-end::: +:::row-end::: + +In this phase, **required by some hybrid deployments**, the user's public key is synchronized from Microsoft Entra ID to Active Directory. + +:::row::: + :::column span="1"::: + :::image type="content" source="images/howitworks/certificate-enrollment.png" alt-text="Icon representing the certificate enrollment phase." border="false"::: + :::column-end::: + :::column span="3"::: + #### Certificate enrollment phase + :::column-end::: +:::row-end::: + +In this phase, **required only by deployments using certificates**, a certificate is issued to the user using the organization's public key infrastructure (PKI). + +:::row::: + :::column span="1"::: + :::image type="content" source="images/howitworks/authentication.png" alt-text="Icon representing the authentication phase." border="false"::: + :::column-end::: + :::column span="3"::: + #### Authentication phase + :::column-end::: +:::row-end::: + +In this last phase, the user can sign-in to Windows using biometrics or a PIN. Regardless of the gesture used, authentication occurs using the private portion of the Windows Hello for Business credential. The IdP validates the user identity by mapping the user account to the public key registered during the provisioning phase. + +The following sections provide deeper insights into each of these phases. + +## 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 be associated and to authenticate to an IdP: + +- For cloud and hybrid deployments, the identity provider is Microsoft Entra ID, and the device registers with the *Device Registration Service* +- 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 AD FS + +When a device is registered, the IdP provides the device with an identity that is used to authenticate the device when a user signs-in. + +There are different registration types, which are identified as *join type*. For more information, see [What is a device identity][ENTRA-1]. + +For detailed sequence diagrams, see [how device registration works][ENTRA-4]. + +## Provisioning + +:::row::: + :::column::: + Windows Hello provisioning is triggered once device registration completes, and after the device receives a policy that enables Windows Hello. If all the prerequisites are met, a Cloud eXperience Host (CXH) window is launched to take the user through the provisioning flow. + :::column-end::: + :::column::: + :::image type="content" source="images/howitworks/cxh-provision.png" alt-text="Screenshot of the Cloud Experience Host prompting the user to provision Windows Hello." border="false" lightbox="images/howitworks/cxh-provision.png"::: + :::column-end::: +:::row-end::: + +> [!NOTE] +> The list of prerequisites varies depending on the deployment type, as described in the article [Plan a Windows Hello for Business deployment](deploy/index.md). + +During the provisioning phase, a *Windows Hello container* is created. A Windows Hello container is a logical grouping of *key material*, or data. The container holds organization's credentials only on devices that are *registered* with the organization's IdP. + +> [!NOTE] +> There are no physical containers on disk, in the registry, or elsewhere. Containers are logical units used to group related items. The keys, certificates, and credentials that Windows Hello stores, are protected without the creation of actual containers or folders. + +Here are the steps involved with the provisioning phase: + +1. In the CXH window, the user is prompted to authenticate to the IdP with MFA +1. After successful MFA, the user must provide a bio gesture (if available), and a PIN +1. After the PIN confirmation, the Windows Hello container is created +1. A public/private key pair is generated. The key pair is bound to the Trusted Platform Module (TPM), if available, or in software +1. The private key is stored locally and protected by the TPM, and can't be exported +1. The public key is registered with the IdP, mapped to the user account + 1. The Device Registration Service writes the key to the user object in Microsoft Entra ID + 1. For on-premises scenarios, AD FS writes the key to Active Directory + +The following video shows the Windows Hello for Business enrollment steps after signing in with a password: + +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=36dc8679-0fcc-4abf-868d-97ec8b749da7 alt-text="Video showing the Windows Hello for Business enrollment steps after signing in with a password."] + +For more information and detailed sequence diagrams, see [how provisioning works](how-it-works-provisioning.md). + +### Windows Hello container details + +:::row::: + :::column::: + During the provisioning phase, Windows Hello generates a new public/private key pair on the device. The TPM generates and protects the private key. If the device doesn't have a TPM, the private key is encrypted and stored in software. This initial key is referred to as the *protector key*. The protector key is associated with a single gesture: if a user registers a PIN, a fingerprint, and a face on the same device, each of those gestures has a unique protector key. + + The protector key securely wraps the *authentication key*. The authentication key is used to unlock the *user ID keys*. The container has only one authentication key, but there can be multiple copies of that key wrapped with different unique protector keys. + :::column-end::: + :::column::: + :::image type="content" source="images/howitworks/hello-container.png" alt-text="Diagram of the Windows Hello container." border="false" lightbox="images/howitworks/hello-container.png"::: + :::column-end::: +:::row-end::: + +Each protector encrypts its own copy of the authentication key. How the encryption is performed is up to the protector itself. For example, the PIN protector performs a TPM seal operation using the PIN as entropy, or when no TPM is available, performs symmetric encryption of the authentication key using a key derived from the PIN itself. + +> [!IMPORTANT] +> Keys can be generated in hardware (TPM 1.2 or 2.0) or software, based on the configured policy setting. To guarantee that keys are generated in hardware, you must configure a policy setting. For more information, see [Use a hardware security device](policy-settings.md#use-a-hardware-security-device). + +Personal (Microsoft account) and Work or School (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. + +Windows Hello also generates an *administrative key*. The administrative key can be used to reset credentials when necessary. For example, when using the [PIN reset service](pin-reset.md). In addition to the protector key, TPM-enabled devices generate a block of data that contains attestations from the TPM. + +Access to the key material stored in the container, is enabled only by the PIN or biometric gesture. The two-step verification that takes place during provisioning creates a trusted relationship between the IdP and the user. This happens when the public portion of the public/private key pair is sent to an identity provider and associated with the user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services. + +A container can contain several types of key material: + +- An *authentication key*, which is always an asymmetric public-private key pair. This key pair is generated during registration. It must be unlocked each time it's accessed, by using either the user's PIN or a biometric gesture. The authentication key exists until the user resets the PIN, at which time a new key is generated. When the new key is generated, all the key material that the old key previously protected must be decrypted and re-encrypted using the new key +- One or multiple *user ID keys*. These keys can be either symmetric or asymmetric, depending on which IdP you use. For certificate-based Windows Hello for Work, when the container is unlocked, applications that require access to the user ID key or key pair can request access. User ID keys are used to sign or encrypt authentication requests or tokens sent from this device to the IdP. User ID keys are typically long-lived but could have a shorter lifetime than the authentication key. Microsoft accounts, Active Directory accounts, and Microsoft Entra accounts all require the use of asymmetric key pairs. The device generates public and private keys, registers the public key with the IdP (which stores it for later verification), and securely stores the private key. For organizatrons, the user ID keys can be generated in two ways: + - The user ID key pair can be associated with an organization's Certificate Authority (CA). This option lets organizations that have an existing PKI continue to use it where appropriate. Given that many applications, such as VPN solutions, require the use of certificates, when you deploy Windows Hello in this mode, it allows a faster transition away from user passwords while still preserving certificate-based functionality. This option also allows the organization to store other certificates in the protected container. For example, certificates that allows the user to authenticate via RDP + - The IdP can generate the user ID key pair directly, which allows quick, lower-overhead deployment of Windows Hello in environments that don't have or need a PKI + +User ID keys are used to authenticate the user to a service. For example, by signing a nonce to prove possession of the private key, which corresponds to a registered public key. Users with an Active Directory, Microsoft Entra ID or Microsoft account have a key associated with their account. The key can be used to sign into their Windows device by authenticating to a domain controller (Active Directory scenario), or to the cloud (Microsoft Entra ID and MSA scenarios). + +Windows Hello can also be used as a FIDO2 authenticator to authenticate to any website that supports WebAuthn. Websites or application can create a FIDO user ID key in the user's Windows Hello container using APIs. On subsequent visits, the user can authenticate to the website or app using their Windows Hello PIN or biometric gesture. + +To learn more how Windows uses the TPM in support of Windows Hello for Business, see [How Windows uses the Trusted Platform Module](../../hardware-security/tpm/how-windows-uses-the-tpm.md). + +### Biometric data storage + +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. Even if an attacker could obtain the biometric data from a device, it couldn't be converted back into a raw biometric sample recognizable by the biometric sensor. + +Each sensor has its own biometric database file where template data is stored (path `C:\WINDOWS\System32\WinBioDatabase`). Each database file has a unique, randomly generated key that is encrypted to the system. The template data for the sensor is encrypted with the per-database key using AES with CBC chaining mode. The hash is SHA256. + +> [!NOTE] +>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. For more information, see [Windows Hello Enhanced Security Sign-in (ESS)][WINH-1]. + +## Key synchronization + +Key synchronization is required in hybrid environments. After the user provisions a Windows Hello for Business credential, the key must synchronize from Microsoft Entra ID to Active Directory. + +The user's public key is written to the `msDS-KeyCredentialLink` attribute of the user object in Active Directory. The synchronization is handled by Microsoft Entra Connect Sync. + +## Certificate enrollment + +For certificate deployments, after registering the key, the client generates a certificate request. The request is sent to the Certificate Registration Authority (CRA). The CRA is on the Active Directory Federation Services (AD FS) server, which validates the certificate request and fulfills it using the enterprise PKI. + +A certificate is enrolled on the user's Hello container, which is used to authenticate to on-premises resources. + +## Authentication + +Windows Hello credentials are based on certificate or asymmetrical key pair. Windows Hello credentials, and the token that is obtained using those credentials, are bound to the device. + +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) + +PIN entry and biometric gesture both trigger Windows to use the private key to cryptographically sign data that is sent to the identity provider. The IdP verifies the user's identity and authenticates the user. + +The PIN or the private portion of the credentials is never sent to the IdP, and the PIN isn't stored on the device. The PIN and bio gestures are *user-provided entropy* when performing operations that use the private portion of the credential. + +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 User ID keys reside inside the container. + +These keys are used to sign requests that are sent to the IdP, requesting access to specified resources. + +> [!IMPORTANT] +> Although the keys are unlocked, applications cannot use them at will. Applications can use specific APIs to request operations that require key material for particular actions (for example, decrypt an email message or sign in to a website). Access through these APIs doesn't require explicit validation through a user gesture, and the key material isn't exposed to the requesting application. Rather, the application asks for authentication, encryption, or decryption, and the Windows Hello layer handles the actual work and returns the results. Where appropriate, an application can request a forced authentication even on an unlocked device. Windows prompts the user to reenter the PIN or perform an authentication gesture, which adds an extra level of protection for sensitive data or actions. For example, you can configure an application to require re-authentication anytime a specific operation is performed, even though the same account and PIN or gesture were already used to unlock the device. + +For more information and detailed sequence diagrams, see [how authentication works](how-it-works-authentication.md). + +### Primary refresh token + +Single sign-on (SSO) relies on special tokens obtained to access specific applications. In the traditional Windows Integrated authentication case using Kerberos, the 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][WEB-1] that contains claims about both the user and the device. + +The PRT is initially obtained during sign-in or unlock in a similar way the Kerberos TGT is obtained. This behavior is true for both Microsoft Entra joined and Microsoft Entra hybrid joined devices. For personal devices registered with Microsoft Entra ID, the PRT is initially obtained upon *Add Work or School Account*. For a personal device, the account to unlock the device isn't the work account, but a consumer account (*Microsoft account*). + +The PRT is needed for SSO. Without it, users would be prompted for credentials every time they access applications. The PRT also contains information about the device. If you have any [device-based conditional access][ENTRA-3] policies set on an application, without the PRT access is denied. + +> [!TIP] +> The Windows Hello for Business key meets Microsoft Entra multifactor authentication (MFA) requirements and reduces the number of MFA prompts users will see when accessing resources. + +For more information, see [What is a Primary Refresh Token][ENTRA-2]. + +### Windows Hello for Business and password changes + +Changing a user account password doesn't affect sign-in or unlock, since Windows Hello for Business uses a key or certificate. + +## Next steps + +> [!div class="nextstepaction"] +> To accommodate the multitude of organizations needs and requirements, Windows Hello for Business offers different deployment options. To learn how to plan a Windows Hello for Business deployment, see: +> +> [Plan a Windows Hello for Business Deployment](deploy/index.md) + + + +[ENTRA-1]: /entra/identity/devices/overview +[ENTRA-2]: /entra/identity/devices/concept-primary-refresh-token +[ENTRA-3]: /entra/identity/conditional-access/concept-conditional-access-grant +[ENTRA-4]: /entra/identity/devices/device-registration-how-it-works + +[WEB-1]: https://openid.net/specs/draft-jones-json-web-token-07.html +[WINH-1]: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security diff --git a/windows/security/identity-protection/hello-for-business/images/authflow.png b/windows/security/identity-protection/hello-for-business/images/authflow.png deleted file mode 100644 index 1ddf18cc1f..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/authflow.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/connect.png b/windows/security/identity-protection/hello-for-business/images/connect.png deleted file mode 100644 index 2338eda8d2..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/connect.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/corpown.png b/windows/security/identity-protection/hello-for-business/images/corpown.png deleted file mode 100644 index f87d33ce86..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/corpown.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/fingerprint.svg b/windows/security/identity-protection/hello-for-business/images/fingerprint.svg new file mode 100644 index 0000000000..e2b816716a --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/images/fingerprint.svg @@ -0,0 +1,3 @@ + + + diff --git a/windows/security/identity-protection/hello-for-business/images/hello.svg b/windows/security/identity-protection/hello-for-business/images/hello.svg new file mode 100644 index 0000000000..5601c82127 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/images/hello.svg @@ -0,0 +1,3 @@ + + + diff --git a/windows/security/identity-protection/hello-for-business/images/hellosettings.png b/windows/security/identity-protection/hello-for-business/images/hellosettings.png deleted file mode 100644 index 9b897a136e..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/hellosettings.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-certtrust-kerb.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-certtrust-kerb.png deleted file mode 100644 index 344be6aa22..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-certtrust-kerb.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloud.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloud.png deleted file mode 100644 index 751e2fbe99..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloud.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloudtrust-kerb.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloudtrust-kerb.png deleted file mode 100644 index 1fec70ce5a..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-cloudtrust-kerb.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-keytrust-kerb.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-keytrust-kerb.png deleted file mode 100644 index 095ebc3417..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-aadj-keytrust-kerb.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-certtrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-certtrust.png deleted file mode 100644 index 905d36fa8f..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-certtrust.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-cloudtrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-cloudtrust.png deleted file mode 100644 index 0a803d8fbb..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-cloudtrust.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-keytrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-keytrust.png deleted file mode 100644 index 7f82cda5ae..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/auth-haadj-keytrust.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-ckt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-ckt.png new file mode 100644 index 0000000000..ef60414e70 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-ckt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-ct.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-ct.png new file mode 100644 index 0000000000..e45839808a Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-ct.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-kt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-kt.png new file mode 100644 index 0000000000..213efe1241 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-ad-kt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-entra.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-entra.png new file mode 100644 index 0000000000..584702dcd1 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/entra-join-entra.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-ckt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-ckt.png new file mode 100644 index 0000000000..2ee3ebd7ff Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-ckt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-ct.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-ct.png new file mode 100644 index 0000000000..7e4cb22dcf Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-ct.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-kt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-kt.png new file mode 100644 index 0000000000..9f085f40e9 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/auth/hybrid-entra-join-kt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/authentication.png b/windows/security/identity-protection/hello-for-business/images/howitworks/authentication.png new file mode 100644 index 0000000000..4c36e92b32 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/authentication.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/certificate-enrollment.png b/windows/security/identity-protection/hello-for-business/images/howitworks/certificate-enrollment.png new file mode 100644 index 0000000000..5b491739be Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/certificate-enrollment.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/cxh-provision.png b/windows/security/identity-protection/hello-for-business/images/howitworks/cxh-provision.png new file mode 100644 index 0000000000..28fe43819e Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/cxh-provision.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/device-registration.png b/windows/security/identity-protection/hello-for-business/images/howitworks/device-registration.png new file mode 100644 index 0000000000..f2efb0a732 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/device-registration.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/hello-container.png b/windows/security/identity-protection/hello-for-business/images/howitworks/hello-container.png new file mode 100644 index 0000000000..2cd717e7f4 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/hello-container.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-federated.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-federated.png deleted file mode 100644 index dd7eee063e..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-federated.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-managed.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-managed.png deleted file mode 100644 index 3e67ac6b42..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-aadj-managed.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-cloudtrust-managed.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-cloudtrust-managed.png deleted file mode 100644 index b2867c3aeb..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-cloudtrust-managed.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-federated.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-federated.png deleted file mode 100644 index b7f4927730..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-instant-certtrust-federated.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-keytrust-managed.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-keytrust-managed.png deleted file mode 100644 index 5bf7d96a34..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-haadj-keytrust-managed.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-certtrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-certtrust.png deleted file mode 100644 index 6afa492270..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-certtrust.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-keytrust.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-keytrust.png deleted file mode 100644 index 3e051918ce..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/howitworks/prov-onprem-keytrust.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/entra-join-federated.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/entra-join-federated.png new file mode 100644 index 0000000000..b1d934b030 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/entra-join-federated.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/entra-join-managed.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/entra-join-managed.png new file mode 100644 index 0000000000..8cba709a71 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/entra-join-managed.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-ckt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-ckt.png new file mode 100644 index 0000000000..2c49786e91 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-ckt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-federated.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-federated.png new file mode 100644 index 0000000000..9cbe229993 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-federated.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-managed-kt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-managed-kt.png new file mode 100644 index 0000000000..66b65155ee Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/hybrid-entra-join-managed-kt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/onprem-ct.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/onprem-ct.png new file mode 100644 index 0000000000..9a19b71d78 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/onprem-ct.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/prov/onprem-kt.png b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/onprem-kt.png new file mode 100644 index 0000000000..8a01d2dc3e Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/prov/onprem-kt.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/provision.png b/windows/security/identity-protection/hello-for-business/images/howitworks/provision.png new file mode 100644 index 0000000000..3c79cec610 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/provision.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/howitworks/synchronization.png b/windows/security/identity-protection/hello-for-business/images/howitworks/synchronization.png new file mode 100644 index 0000000000..2823638bc5 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/howitworks/synchronization.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/iris.svg b/windows/security/identity-protection/hello-for-business/images/iris.svg new file mode 100644 index 0000000000..871cac50d5 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/images/iris.svg @@ -0,0 +1,3 @@ + + + diff --git a/windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gp-setting.png b/windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gp-setting.png deleted file mode 100644 index 47823d76a8..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gp-setting.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gpme.png b/windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gpme.png deleted file mode 100644 index fd7afd80cb..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/multifactorUnlock/gpme.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passport-fig3-logicalcontainer.png b/windows/security/identity-protection/hello-for-business/images/passport-fig3-logicalcontainer.png deleted file mode 100644 index d00836529a..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passport-fig3-logicalcontainer.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/aduc-account-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/aduc-account-scril.png deleted file mode 100644 index 6b19520041..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/aduc-account-scril.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/exclude-credential-providers-properties.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/exclude-credential-providers-properties.png deleted file mode 100644 index 21329d0ffa..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/exclude-credential-providers-properties.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/four-steps-passwordless-strategy.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/four-steps-passwordless-strategy.png deleted file mode 100644 index 8552a3ee2f..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/four-steps-passwordless-strategy.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-exclude-credential-providers.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-exclude-credential-providers.png deleted file mode 100644 index fd9085fbd1..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-exclude-credential-providers.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-require-smart-card-policy.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-require-smart-card-policy.png deleted file mode 100644 index 1ec0fe5a29..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-require-smart-card-policy.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-security-options.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-security-options.png deleted file mode 100644 index 9731de1222..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/gpmc-security-options.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/require-whfb-smart-card-policy.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/require-whfb-smart-card-policy.png deleted file mode 100644 index 5935422718..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/require-whfb-smart-card-policy.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2012-adac-user-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2012-adac-user-scril.png deleted file mode 100644 index 9e3a5509a9..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2012-adac-user-scril.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-domain-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-domain-scril.png deleted file mode 100644 index 9b068a70a2..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-domain-scril.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-user-scril.png b/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-user-scril.png deleted file mode 100644 index b4e1575d05..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless-strategy/server-2016-adac-user-scril.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/edge-on.png b/windows/security/identity-protection/hello-for-business/images/passwordless/edge-on.png deleted file mode 100644 index 06a13b6f1a..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless/edge-on.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/key-credential-provider.svg b/windows/security/identity-protection/hello-for-business/images/passwordless/key-credential-provider.svg deleted file mode 100644 index dd8c09b2dd..0000000000 --- a/windows/security/identity-protection/hello-for-business/images/passwordless/key-credential-provider.svg +++ /dev/null @@ -1,11 +0,0 @@ - - - - - - - - - - - diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-on.png b/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-on.png deleted file mode 100644 index abb9b6456d..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-on.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/uac-off.png b/windows/security/identity-protection/hello-for-business/images/passwordless/uac-off.png deleted file mode 100644 index 8913baa8ce..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless/uac-off.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/uac-on.png b/windows/security/identity-protection/hello-for-business/images/passwordless/uac-on.png deleted file mode 100644 index b0d03a6299..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/passwordless/uac-on.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/pin.svg b/windows/security/identity-protection/hello-for-business/images/pin.svg new file mode 100644 index 0000000000..a34b2fa5db --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/images/pin.svg @@ -0,0 +1,3 @@ + + + diff --git a/windows/security/identity-protection/hello-for-business/images/pinerror.png b/windows/security/identity-protection/hello-for-business/images/pinerror.png deleted file mode 100644 index 28a759f2fc..0000000000 Binary files a/windows/security/identity-protection/hello-for-business/images/pinerror.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/provisioning-error.png b/windows/security/identity-protection/hello-for-business/images/provisioning-error.png new file mode 100644 index 0000000000..4f14752014 Binary files /dev/null and b/windows/security/identity-protection/hello-for-business/images/provisioning-error.png differ diff --git a/windows/security/identity-protection/hello-for-business/images/smartcard.svg b/windows/security/identity-protection/hello-for-business/images/smartcard.svg new file mode 100644 index 0000000000..c9d40368b5 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/images/smartcard.svg @@ -0,0 +1,3 @@ + + + diff --git a/windows/security/identity-protection/hello-for-business/includes/allow-enumeration-of-emulated-smart-card-for-all-users.md b/windows/security/identity-protection/hello-for-business/includes/allow-enumeration-of-emulated-smart-card-for-all-users.md new file mode 100644 index 0000000000..9157046e94 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/allow-enumeration-of-emulated-smart-card-for-all-users.md @@ -0,0 +1,17 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/configure-device-unlock-factors.md b/windows/security/identity-protection/hello-for-business/includes/configure-device-unlock-factors.md new file mode 100644 index 0000000000..23a614db9d --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/configure-device-unlock-factors.md @@ -0,0 +1,19 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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, see [Multi-factor unlock](../multifactor-unlock.md). diff --git a/windows/security/identity-protection/hello-for-business/includes/configure-dynamic-lock-factors.md b/windows/security/identity-protection/hello-for-business/includes/configure-dynamic-lock-factors.md new file mode 100644 index 0000000000..4cd7b376f1 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/configure-dynamic-lock-factors.md @@ -0,0 +1,18 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/configure-enhanced-anti-spoofing.md b/windows/security/identity-protection/hello-for-business/includes/configure-enhanced-anti-spoofing.md new file mode 100644 index 0000000000..057da41f74 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/configure-enhanced-anti-spoofing.md @@ -0,0 +1,20 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/enable-ess-with-supported-peripherals.md b/windows/security/identity-protection/hello-for-business/includes/enable-ess-with-supported-peripherals.md new file mode 100644 index 0000000000..d5308cbb87 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/enable-ess-with-supported-peripherals.md @@ -0,0 +1,25 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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). diff --git a/windows/security/identity-protection/hello-for-business/includes/expiration.md b/windows/security/identity-protection/hello-for-business/includes/expiration.md new file mode 100644 index 0000000000..6d5e71de6c --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/expiration.md @@ -0,0 +1,17 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityexpiration](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityexpiration) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity**| diff --git a/windows/security/identity-protection/hello-for-business/includes/history.md b/windows/security/identity-protection/hello-for-business/includes/history.md new file mode 100644 index 0000000000..f172d6e9f6 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/history.md @@ -0,0 +1,20 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityhistory](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityhistory) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/maximum-pin-length.md b/windows/security/identity-protection/hello-for-business/includes/maximum-pin-length.md new file mode 100644 index 0000000000..9ab86cb5f7 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/maximum-pin-length.md @@ -0,0 +1,20 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexitymaximumpinlength](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexitymaximumpinlength) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/minimum-pin-length.md b/windows/security/identity-protection/hello-for-business/includes/minimum-pin-length.md new file mode 100644 index 0000000000..ba9b806c2b --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/minimum-pin-length.md @@ -0,0 +1,21 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityminimumpinlength](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityminimumpinlength)| +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/require-digits.md b/windows/security/identity-protection/hello-for-business/includes/require-digits.md new file mode 100644 index 0000000000..e2ca5a2621 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/require-digits.md @@ -0,0 +1,19 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexitydigits](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexitydigits) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/require-lowercase-letters.md b/windows/security/identity-protection/hello-for-business/includes/require-lowercase-letters.md new file mode 100644 index 0000000000..b84ed743ee --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/require-lowercase-letters.md @@ -0,0 +1,19 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexitylowercaseletters](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexitylowercaseletters) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/require-special-characters.md b/windows/security/identity-protection/hello-for-business/includes/require-special-characters.md new file mode 100644 index 0000000000..deeb7f56e4 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/require-special-characters.md @@ -0,0 +1,25 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityspecialcharacters](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityspecialcharacters) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/require-uppercase-letters.md b/windows/security/identity-protection/hello-for-business/includes/require-uppercase-letters.md new file mode 100644 index 0000000000..b90cda9fa3 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/require-uppercase-letters.md @@ -0,0 +1,19 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/PINComplexity/`[usertenantidpoliciespincomplexityuppercaseletters](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciespincomplexityuppercaseletters) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **System** > **PIN Complexity** | diff --git a/windows/security/identity-protection/hello-for-business/includes/turn-off-smart-card-emulation.md b/windows/security/identity-protection/hello-for-business/includes/turn-off-smart-card-emulation.md new file mode 100644 index 0000000000..502e1d18f1 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/turn-off-smart-card-emulation.md @@ -0,0 +1,21 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/use-a-hardware-security-device.md b/windows/security/identity-protection/hello-for-business/includes/use-a-hardware-security-device.md new file mode 100644 index 0000000000..3dfb45f8ba --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-a-hardware-security-device.md @@ -0,0 +1,20 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)

      `./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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/use-biometrics.md b/windows/security/identity-protection/hello-for-business/includes/use-biometrics.md new file mode 100644 index 0000000000..761017763f --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-biometrics.md @@ -0,0 +1,21 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/use-certificate-for-on-premises-authentication.md b/windows/security/identity-protection/hello-for-business/includes/use-certificate-for-on-premises-authentication.md new file mode 100644 index 0000000000..78c1064fbe --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-certificate-for-on-premises-authentication.md @@ -0,0 +1,18 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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**

      **User Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**| diff --git a/windows/security/identity-protection/hello-for-business/includes/use-cloud-trust-for-on-premises-authentication.md b/windows/security/identity-protection/hello-for-business/includes/use-cloud-trust-for-on-premises-authentication.md new file mode 100644 index 0000000000..77b3878741 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-cloud-trust-for-on-premises-authentication.md @@ -0,0 +1,21 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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. diff --git a/windows/security/identity-protection/hello-for-business/includes/use-pin-recovery.md b/windows/security/identity-protection/hello-for-business/includes/use-pin-recovery.md new file mode 100644 index 0000000000..8f28f8f8d1 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-pin-recovery.md @@ -0,0 +1,24 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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)
      `./User/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[EnablePinRecovery](/windows/client-management/mdm/passportforwork-csp#usertenantidpoliciesenablepinrecovery) | +| **GPO** | **Computer Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business** | + +For more information, see [PIN reset](../pin-reset.md). diff --git a/windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business-certificates-as-smart-card-certificates.md b/windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business-certificates-as-smart-card-certificates.md new file mode 100644 index 0000000000..2d3b0707f3 --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business-certificates-as-smart-card-certificates.md @@ -0,0 +1,20 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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](../policy-settings.md#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** | diff --git a/windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business.md b/windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business.md new file mode 100644 index 0000000000..9278bcd9ef --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/includes/use-windows-hello-for-business.md @@ -0,0 +1,32 @@ +--- +author: paolomatarazzo +ms.author: paoloma +ms.date: 01/03/2024 +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 + +:::row::: +:::column span="1"::: +:::image type="content" source="../../../images/insider.png" alt-text="Logo of Windows Insider." border="false"::: +:::column-end::: +:::column span="3"::: +> [!IMPORTANT] +>This policy setting is available via CSP only for [Windows Insider Preview builds](/windows-insider/). +:::column-end::: +:::row-end::: + +| | Path | +|--|--| +| **CSP** | `./Device/Vendor/MSFT/PassportForWork/{TenantId}/Policies/`[UsePassportForWork](/windows/client-management/mdm/passportforwork-csp#devicetenantidpoliciesusepassportforwork)

      `./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**

      **User Configuration** > **Administrative Templates** > **Windows Components** > **Windows Hello for Business**| diff --git a/windows/security/identity-protection/hello-for-business/index.md b/windows/security/identity-protection/hello-for-business/index.md index e0be2b5b93..7c03078ac9 100644 --- a/windows/security/identity-protection/hello-for-business/index.md +++ b/windows/security/identity-protection/hello-for-business/index.md @@ -1,112 +1,106 @@ --- -title: Windows Hello for Business Overview +title: Windows Hello for Business overview description: Learn how Windows Hello for Business replaces passwords with strong two-factor authentication on Windows devices. ms.topic: overview -ms.date: 04/24/2023 +ms.date: 01/03/2024 --- -# 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. +# Windows Hello for Business ->[!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. +## Overview -Windows Hello addresses the following problems with passwords: +*Windows Hello* is an authentication technology that allows users to sign in to their Windows devices using biometric data, or a PIN, instead of a traditional password. It provides enhanced security through phish-resistant two-factor authentication, and built-in brute force protection. With FIDO/WebAuthn, Windows Hello can also be used to sign in to supported websites, reducing the need to remember multiple complex 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. +*Windows Hello for Business* is an **extension** of Windows Hello that provides enterprise-grade security and management capabilities, including device attestation, certificate-based authentication, and conditional access policies. Policy settings can be deployed to devices to ensure they're secure and compliant with organizational requirements. -Windows Hello lets users authenticate to: +The following table lists the main authentication and security differences between Windows Hello and Windows Hello for business: -- A Microsoft account. -- An Active Directory account. -- A Microsoft Entra account. -- Identity Provider Services or Relying Party Services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication. +||Windows Hello for Business|Windows Hello| +|-|-|-| +|**Authentication**|Users can authenticate to:
      - A Microsoft Entra ID account
      - An Active Directory account
      - Identity provider (IdP) or relying party (RP) services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.|Users can authenticate to:
      - A Microsoft account
      - Identity provider (IdP) or relying party (RP) services that support [Fast ID Online (FIDO) v2.0](https://fidoalliance.org/) authentication.| +|**Security**|It uses **key-based** or **certificate-based** authentication. There's no symmetric secret (password) which can be stolen from a server or phished from a user and used remotely.
      Enhanced security is available on devices with a Trusted Platform Module (TPM).|Users can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it's set up, but can use a password hash depending on the account type. This configuration is referred to as *Windows Hello convenience PIN*, and it's not backed by asymmetric (public/private key) or certificate-based authentication.| -After an initial two-step verification of the user during enrollment, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, such as a fingerprint, or a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users. +> [!NOTE] +> FIDO2 (Fast Identity Online) authentication is an open standard for passwordless authentication. It allows users to sign in to their devices and apps using biometric authentication or a physical security key, without the need for a traditional password. FIDO2 support in Windows Hello for Business provides an additional layer of security and convenience for users, while also reducing the risk of password-related attacks. -As an administrator in an enterprise or educational organization, you can create policies to manage Windows Hello for Business use on Windows 10-based devices that connect to your organization. +## Benefits + +Windows Hello for Business provides many benefits, including: + +- It helps to strengthen protections against credential theft. An attacker must have both the device and the biometric or PIN, making it much more difficult to gain access without the user's knowledge +- Since no passwords are used, it circumvents phishing and brute force attacks. Most importantly, it prevents server breaches and replay attacks because the credentials are asymmetric and generated within isolated environments of TPMs +- Users get a simple and convenient authentication method (backed up with a PIN) that's always with them, so there's nothing to lose. The use of a PIN doesn't compromise security, since Windows Hello has built-in brute force protection, and the PIN never leaves the device +- You can add biometric devices as part of a coordinated rollout or to specific users, as needed + +The following video shows a demonstration of Windows Hello for Business in action, where a user signs in with a fingerprint: + +> [!VIDEO https://learn-video.azurefd.net/vod/player?id=fb5ceb53-d82b-4997-bde1-d473b620038a] + +## Windows Hello and two factor authentication + +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 Microsoft Entra ID or Active Directory, and can be used to access organization apps, websites, and services. + +After an initial two-step verification of the user during provisioning, Windows Hello is set up on the user's device and Windows asks the user to set a gesture, which can be a biometric, and a PIN. The user provides the gesture to verify their identity. Windows then uses Windows Hello to authenticate users. + +Windows Hello for Business is considered two-factor authentication based on the observed authentication factors of: *something you have*, *something you know*, and *something that's part of you*. Windows Hello for Business incorporates two of these factors: something you have (the user's private key protected by the device's security module) and something you know (your PIN). With the proper hardware, you can enhance the user experience by introducing biometrics. By using biometrics, you can replace the *something you know* authentication factor with the *something that is part of you* factor, with the assurances that users can fall back to the *something you know factor*. ## Biometric sign-in - Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras. Fingerprint reader hardware can be used or added to devices that don't currently have it. On devices that support Windows Hello, an easy biometric gesture unlocks users' credentials. + Windows Hello provides reliable, fully integrated biometric authentication based on facial recognition or fingerprint matching. Windows Hello uses a combination of special infrared (IR) cameras and software to increase accuracy and guard against spoofing. Major hardware vendors are shipping devices that have integrated Windows Hello-compatible cameras and fingerprint readers. -- **Facial recognition**. This type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors are shipping external cameras that incorporate this technology, and major laptop manufacturers are incorporating it into their devices, as well. -- **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. +On devices that support Windows Hello, an easy biometric gesture unlocks users' credentials: -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). +- **Facial recognition**: this type of biometric recognition uses special cameras that see in IR light, which allows them to reliably tell the difference between a photograph or scan and a living person. Several vendors offer external cameras that incorporate this technology, and many laptop manufacturers incorporate it into their devices +- **Fingerprint recognition**: this type of biometric recognition uses a capacitive fingerprint sensor to scan your fingerprint. Most existing fingerprint readers work with Windows, 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 -## The difference between Windows Hello and Windows Hello for Business - -- Individuals can create a PIN or biometric gesture on their personal devices for convenient sign-in. This use of Windows Hello is unique to the device on which it's set up, but can use a password hash depending on an individual's account type. This configuration is referred to as *Windows Hello convenience PIN* and it's not backed by asymmetric (public/private key) or certificate-based authentication. - -- *Windows Hello for Business*, which is configured by group policy or mobile device management (MDM) policy, always uses key-based or certificate-based authentication. This behavior makes it more secure than *Windows Hello convenience PIN*. - -## Benefits of Windows Hello - -Reports of identity theft and large-scale hacking are frequent headlines. Nobody wants to be notified that their user name and password have been exposed. - -You may wonder [how a PIN can help protect a device better than a password](hello-why-pin-is-better-than-password.md). Passwords are shared secrets; they're entered on a device and transmitted over the network to the server. An intercepted account name and password can be used by anyone, anywhere. Because they're stored on the server, a server breach can reveal those stored credentials. - -In Windows 10 and later, Windows Hello replaces passwords. When an identity provider supports keys, the Windows Hello provisioning process creates a cryptographic key pair bound to the Trusted Platform Module (TPM), if a device has a TPM 2.0, or in software. Access to these keys and obtaining a signature to validate user possession of the private key is enabled only by the PIN or biometric gesture. The two-step verification that takes place during Windows Hello enrollment creates a trusted relationship between the identity provider and the user when the public portion of the public/private key pair is sent to an identity provider and associated with a user account. When a user enters the gesture on the device, the identity provider knows that it's a verified identity, because of the combination of Windows Hello keys and gestures. It then provides an authentication token that allows Windows to access resources and services. - -> [!NOTE] -> Windows Hello as a convenience sign-in uses regular username and password authentication, without the user entering the password. - -:::image type="content" alt-text="How authentication works in Windows Hello." source="images/authflow.png" lightbox="images/authflow.png"::: - -Imagine that someone is looking over your shoulder as you get money from an ATM and sees the PIN that you enter. Having that PIN won't help them access your account because they don't have your ATM card. In the same way, learning your PIN for your device doesn't allow that attacker to access your account because the PIN is local to your specific device and doesn't enable any type of authentication from any other device. - -Windows Hello helps protect user identities and user credentials. Because the user doesn't enter a password (except during provisioning), it helps circumvent phishing and brute force attacks. It also helps prevent server breaches because Windows Hello credentials are an asymmetric key pair, which helps prevent replay attacks when these keys are protected by TPMs. +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. [!INCLUDE [windows-hello-for-business](../../../../includes/licensing/windows-hello-for-business.md)] -## How Windows Hello for Business works: key points +> [!NOTE] +> Windows Hello for Business doesn't work with [Microsoft Entra Domain Services](/entra/identity/domain-services/overview). -- 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. +## Hardware 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. +Microsoft collaborates with manufacturers to help ensuring a high-level of performance and protection is met by each sensor and device, based on the following requirements: -- 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 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 regarding the security of the biometric algorithm +- **False Reject Rate (FRR):** represents the instances a biometric identification solution fails to verify an authorized person correctly. 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, devices must have fingerprint sensors and software. Fingerprint sensors 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% +- Effective, real world FRR with Anti-spoofing or liveness detection: <10% -- Certificate private keys can be protected by the Windows Hello container and the Windows Hello gesture. +Acceptable performance range for swipe sensors: -For details, see [How Windows Hello for Business works](hello-how-it-works.md). +- False Accept Rate (FAR): <0.002% +- Effective, real world FRR with Anti-spoofing or liveness detection: <10% -## Comparing key-based and certificate-based authentication +### Facial recognition sensors -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. +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). -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). +- False Accept Rate (FAR): <0.001% +- False Reject Rate (FRR) without Anti-spoofing or liveness detection: <5% +- Effective, real world FRR with Anti-spoofing or liveness detection: <10% -## Learn more +> [!NOTE] +>Windows Hello face authentication doesn't support wearing a mask during enrollment or authentication. If your working environment doesn't allow you to remove a mask temporarily, consider using PIN or fingerprint. -[Implementing strong user authentication with Windows Hello for Business](https://www.microsoft.com/insidetrack/implementing-strong-user-authentication-with-windows-hello-for-business) +### Iris recognition sensor requirements -[Implementing Windows Hello for Business at Microsoft](https://www.microsoft.com/insidetrack/implementing-windows-hello-for-business-at-microsoft) +To use Iris authentication, you 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. -[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. +For more information about the hardware requirements for Windows Hello, see [Windows Hello biometric requirements](/windows-hardware/design/device-experiences/windows-hello-biometric-requirements). -[Windows Hello face authentication](/windows-hardware/design/device-experiences/windows-hello-face-authentication) +## Next steps -## Related articles - -- [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) +> [!div class="nextstepaction"] +> +> [Learn how Windows Hello for Business works >](how-it-works.md) diff --git a/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md b/windows/security/identity-protection/hello-for-business/multifactor-unlock.md similarity index 82% rename from windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md rename to windows/security/identity-protection/hello-for-business/multifactor-unlock.md index a99c25dc3c..2662652a30 100644 --- a/windows/security/identity-protection/hello-for-business/feature-multifactor-unlock.md +++ b/windows/security/identity-protection/hello-for-business/multifactor-unlock.md @@ -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: 01/03/2024 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. ``` -## 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"::: **GPO**](#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| + + + +[CSP-1]: /windows/client-management/mdm/passportforwork-csp +[INT-1]: /mem/intune/configuration/settings-catalog diff --git a/windows/security/identity-protection/hello-for-business/passwordless-strategy.md b/windows/security/identity-protection/hello-for-business/passwordless-strategy.md deleted file mode 100644 index fd387134b6..0000000000 --- a/windows/security/identity-protection/hello-for-business/passwordless-strategy.md +++ /dev/null @@ -1,338 +0,0 @@ ---- -title: Password-less strategy -description: Learn about the password-less strategy and how Windows Hello for Business implements this strategy in Windows 10 and Windows 11. -ms.topic: conceptual -ms.date: 05/24/2022 ---- - -# Password-less strategy - -This article describes Windows' password-less strategy and how Windows Hello for Business implements this strategy. - -## Four steps to password freedom - -Over the past few years, Microsoft has continued their commitment to enabling a world without passwords. - -:::image type="content" source="images/passwordless-strategy/four-steps-passwordless-strategy.png" alt-text="Diagram of stair-step strategy with four steps."::: - -### 1. Develop a password replacement offering - -Before you move away from passwords, you need something to replace them. With Windows 10 and Windows 11, Microsoft introduced Windows Hello for Business, a strong, hardware protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory. - -Deploying Windows Hello for Business is the first step towards a password-less environment. Windows Hello for Business coexists nicely with existing password-based security. Users are likely to use Windows Hello for Business because of its convenience, especially when combined with biometrics. However, some workflows and applications may still need passwords. This early stage is about implementing an alternative and getting users used to it. - -### 2. Reduce user-visible password surface area - -With Windows Hello for Business and passwords coexisting in your environment, the next step is to reduce the password surface. The environment and workflows need to stop asking for passwords. The goal of this step is to achieve a state where the users know they have a password, but they never use it. This state helps decondition users from providing a password anytime a password prompt shows on their computer. This behavior is how passwords are phished. Users who rarely, if at all, use their password are unlikely to provide it. Password prompts are no longer the norm. - -### 3. Transition into a password-less deployment - -Once the user-visible password surface has been eliminated, your organization can begin to transition those users into a password-less world. A world where: - -- The users never type their password. -- The users never change their password. -- The users don't know their password. - -In this world, the user signs in to Windows using Windows Hello for Business and enjoys single sign-on to Azure and Active Directory resources. If the user is forced to authenticate, their authentication uses Windows Hello for Business. - -### 4. Eliminate passwords from the identity directory - -The final step of the password-less story is where passwords simply don't exist. At this step, identity directories no longer persist any form of the password. This stage is where Microsoft achieves the long-term security promise of a truly password-less environment. - -## Methodology - -Four steps to password freedom provide an overall view of how Microsoft envisions the road to eliminating passwords. But this road is frequently traveled and derailed by many. The scope of work is vast and filled with many challenges and frustrations. Nearly everyone wants the instant gratification of achieving a password-less environment, but can easily become overwhelmed by any of the steps. You aren't alone and Microsoft understands. While there are many ways to accomplish freedom from passwords, here's one recommendation based on several years of research, investigation, and customer conversations. - -### Prepare for the journey - -The road to being password-less is a journey. The duration of that journey varies for each organization. It's important for IT decision-makers to understand the criteria influencing the length of that journey. - -The most intuitive answer is the size of the organization, and that would be correct. However, what exactly determines size? One way to break down the size of the organization is by creating a summary of the following components: - -- Number of departments -- Organization or department hierarchy -- Number and type of applications and services -- Number of work personas -- Organization's IT structure - -#### Number of departments - -The number of departments within an organization varies. Most organizations have a common set of departments such as executive leadership, human resources, accounting, sales, and marketing. Other organizations will have those departments and others such as research and development or support. Small organizations may not explicitly segment their departments, while larger ones may. Additionally, there may be subdepartments, and subdepartments of those subdepartments as well. - -You need to know all the departments within your organization and you need to know which departments use computers and which ones don't. It's fine if a department doesn't use computers (probably rare, but acceptable). This circumstance means there's one less department with which you need to concern yourself. Nevertheless, ensure this department is in your list and you've assessed that it's not applicable. - -Your count of the departments must be thorough and accurate, as well as knowing the stakeholders for those departments that will put you and your staff on the road to password freedom. Realistically, many of us lose sight of our organizational chart and how it grows or shrinks over time. This realization is why you need to inventory all of them. Also, don't forget to include external departments such as vendors or federated partners. If your organization goes password-free, but your partners continue to use passwords and then access your corporate resources, you should know about it and include them in your password-less strategy. - -#### Organization or department hierarchy - -Organization and department hierarchy is the management layers within the departments or the organization as a whole. How the device is used, what applications and how they're used, most likely differs between each department, but also within the structure of the department. To determine the correct password-less strategy, you need to know these differences across your organization. An executive leader is likely to use their device differently compared to a member of middle management in the sales department. Both of those user cases are probably different to how an individual contributor in the customer service department uses their device. - -#### Number and type of applications and services - -Most organizations have many applications and rarely do they have one centralized list that's accurate. Applications and services are the most critical items in your password-less assessment. Applications and services take considerable effort to move to a different type of authentication. Changing policies and procedures can be a daunting task. Consider the trade-off between updating your standard operating procedures and security policies compared to changing 100 lines (or more) of authentication code in the critical path of your internally developed CRM application. - -Capturing the number of applications used is easier once you have the departments, their hierarchy, and their stakeholders. In this approach, you should have an organized list of departments and the hierarchy in each. You can now associate the applications that are used by all levels within each department. You'll also want to document whether the application is internally developed or commercially available off-the-shelf (COTS). If the latter, document the manufacturer and the version. Also, don't forget web-based applications or services when inventorying applications. - -#### Number of work personas - -Work personas are where the three previous efforts converge. You know the departments, the organizational levels within each department, the numbers of applications used by each, respectively, and the type of application. From this information, you want to create a work persona. - -A work persona classifies a category of user, title or role (individual contributor, manager, middle manager, etc.), within a specific department to a collection of applications used. There's a high probability that you'll have many work personas. These work personas will become units of work, and you'll refer to them in documentation and in meetings. You need to give them a name. - -Give your personas easy and intuitive names like Abby Accounting, Mark Marketing, or Sue Sales. If the organization levels are common across departments, then decide on a first name that represents the common levels in a department. For example, Abby could be the first name of an individual contributor in any given department, while the first name Sue could represent someone from middle management in any given department. Additionally, you can use suffixes such as (I, II, Senior, etc.) to further define departmental structure for a given persona. - -Ultimately, create a naming convention that doesn't require your stakeholders and partners to read through a long list of tables or a secret decoder ring. Also, if possible, try to keep the references as names of people. After all, you're talking about a person who is in that department and who uses that specific software. - -#### Organization's IT structure - -IT department structures can vary more than the organization. Some IT departments are centralized while others are decentralized. Also, the road to password freedom will probably have you interacting with the client authentication team, the deployment team, the security team, the PKI team, the Active Directory team, the cloud team, and the list continues. Most of these teams will be your partner on your journey to password freedom. Ensure there's a password-less stakeholder on each of these teams, and that the effort is understood and funded. - -#### Assess your organization - -You have a ton of information. You've created your work personas, you've identified your stakeholders throughout the different IT groups. Now what? - -By now you can see why it's a journey and not a weekend project. You need to investigate user-visible password surfaces for each of your work personas. Once you've identified the password surfaces, you need to mitigate them. Resolving some password surfaces are simple - meaning a solution already exists in the environment and it's only a matter of moving users to it. Resolution to some passwords surfaces may exist, but aren't deployed in your environment. That resolution results in a project that must be planned, tested, and then deployed. That project is likely to span multiple IT departments with multiple people, and potentially one or more distributed systems. Those types of projects take time and need dedicated cycles. This same sentiment is true with in-house software development. Even with agile development methodologies, changing the way someone authenticates to an application is critical. Without the proper planning and testing, it has the potential to severely affect productivity. - -How long does it take to become password-less? The answer is "it depends". It depends on the organizational alignment of a password-less strategy. Top-down agreement that a password-less environment is the organization's goal makes conversations much easier. Easier conversations mean less time spent convincing people and more time spent moving forward toward the goal. Top-down agreement, as a priority within the ranks of other on-going IT projects, helps everyone understand how to prioritize existing projects. Agreeing on priorities should reduce and minimize manager and executive level escalations. After these organizational discussions, modern project management techniques are used to continue the password-less effort. The organization allocates resources based on the priority (after they've agreed on the strategy). Those resources will: - -- Work through the work personas. -- Organize and deploy user acceptance testing. -- Evaluate user acceptance testing results for user visible password surfaces. -- Work with stakeholders to create solutions that mitigate user visible password surfaces. -- Add the solution to the project backlog and prioritize against other projects. -- Deploy the solution. -- Perform user acceptance testing to confirm that the solution mitigates the user visible password surface. -- Repeat the testing as needed. - -Your organization's journey to password freedom may take some time. Counting the number of work personas and the number of applications is probably a good indicator of the investment. Hopefully, your organization is growing, which means that the list of personas and the list of applications is unlikely to shrink. If the work to go password-less today is *n*, then it's likely that to go password-less tomorrow is *n x 2* or more, *n x n*. Don't let the size or duration of the project be a distraction. As you progress through each work persona, the actions and tasks will become more familiar for you and your stakeholders. Scope the project to sizable, realistic phases, pick the correct work personas, and soon you'll see parts of your organization transition to a password-less state. - -### Where to start? - -What's the best guidance for kicking off the journey to password freedom? You'll want to show your management a proof of concept as soon as possible. Ideally, you want to show it at each step of your password-less journey. Keeping your password-less strategy top of mind and showing consistent progress keeps everyone focused. - -#### Work persona - -You begin with your work personas. These were part of your preparation process. They have a persona name, such as Abby Accounting II, or any other naming convention your organization defined. That work persona includes a list of all the applications Abby uses to perform her assigned duties in the accounting department. To start, you need to pick a work persona. It's the targeted work persona you'll enable so that you can climb the steps to password freedom. - -> [!IMPORTANT] -> Avoid using any work personas from your IT department. This method is probably the worst way to start the password-less journey. IT roles are very difficult and time consuming. IT workers typically have multiple credentials, run a multitude of scripts and custom applications, and are the worst offenders of password usage. It is better to save these work personas for the middle or end of your journey. - -Review your collection of work personas. Early in your password-less journey, identify personas with the fewest applications. These work personas could represent an entire department or two. These roles are the perfect work personas for your proof-of-concept or pilot. - -Most organizations host their proof of concept in a test lab or environment. If you do that test with a password-free strategy, it may be more challenging and take more time. To test in a lab, you must first duplicate the environment of the targeted persona. This process could take a few days or several weeks, depending on the complexity of the targeted work persona. - -You'll want to balance lab testing with providing results to management quickly. Continuing to show forward progress on your journey to password freedom is always a good thing. If there are ways you can test in production with low or no risk, it may be advantageous to your timeline. - -## The process - -The journey to password freedom is to take each work persona through each step of the process. In the beginning, we encourage working with one persona at a time to ensure team members and stakeholders are familiar with the process. Once comfortable with the process, you can cover as many work personas in parallel as resources allow. The process looks something like this: - -1. Password-less replacement offering (step 1) - 1. Identify test users representing the targeted work persona. - 2. Deploy Windows Hello for Business to test users. - 3. Validate that passwords and Windows Hello for Business work. -2. Reduce user-visible password surface (step 2) - 1. Survey test user workflow for password usage. - 2. Identify password usage and plan, develop, and deploy password mitigations. - 3. Repeat until all user password usage is mitigated. - 4. Remove password capabilities from Windows. - 5. Validate that **none of the workflows** need passwords. -3. Transition into a password-less scenario (step 3) - 1. Awareness campaign and user education. - 2. Include remaining users who fit the work persona. - 3. Validate that **none of the users** of the work personas need passwords. - 4. Configure user accounts to disallow password authentication. - -After successfully moving a work persona to password freedom, you can prioritize the remaining work personas and repeat the process. - -### Password-less replacement offering (step 1) - -The first step to password freedom is providing an alternative to passwords. Windows 10 and Windows 11 provide an affordable and easy in-box alternative to passwords, Windows Hello for Business, a strong, two-factor authentication to Microsoft Entra ID and Active Directory. - -#### Identify test users that represent the targeted work persona - -A successful transition relies on user acceptance testing. It's impossible for you to know how every work persona goes about their day-to-day activities, or how to accurately validate them. You need to enlist the help of users who fit the targeted work persona. You only need a few users from the targeted work persona. As you cycle through step 2, you may want to change a few of the users (or add a few) as part of your validation process. - -#### Deploy Windows Hello for Business to test users - -Next, you'll want to plan your Windows Hello for Business deployment. Your test users will need an alternative way to sign-in during step 2 of the journey to becoming password-less. Use the [Windows Hello for Business planning guide](hello-planning-guide.md) to help learning which deployment is best suited for your environment. Next, use the [Windows Hello for Business deployment guides](index.md) to deploy Windows Hello for Business. - -With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you'll only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You'll use the first work persona to validate your Windows Hello for Business deployment. - -> [!NOTE] -> There are many different ways to connect a device to Azure. Deployments may vary based on how the device is joined to Microsoft Entra ID. Review your planning guide and deployment guide to ensure additional infrastructure is not needed for an additional Azure joined devices. - -#### Validate that passwords and Windows Hello for Business work - -In this first step, passwords and Windows Hello for Business must coexist. You want to validate that while your targeted work personas can sign in and unlock using Windows Hello for Business, but they can also sign-in, unlock, and use passwords as needed. Reducing the user-visible password surface too soon can create frustration and confusion with your targeted user personas. - -### Reduce user-visible password surface (step 2) - -Before you move to step 2, make sure you've: - -- Selected your targeted work persona. -- Identified your test users who represent the targeted work persona. -- Deployed Windows Hello for Business to test users. -- Validated passwords and Windows Hello for Business both work for the test users. - -#### Survey test user workflow for password usage - -Now is the time to learn more about the targeted work persona. You have a list of applications they use, but you don't know what, why, when, and how frequently. This information is important as you further your progress through step 2. - -Test users create the workflows associated with the targeted work persona. Their initial goal is to do one simple task: Document password usage. This list isn't a comprehensive one, but it gives you an idea of the type of information you want. The general idea is to learn about all the scenarios in which that work persona encounters a password. A good approach is to ask yourself the following set of questions: - -- What's the name of the application that asked for a password? -- Why do they use the application that asked for a password? For example, is there more than one application that can do the same thing? -- What part of their workflow makes them use the application? Try to be as specific as possible. For example, "I use application x to issue credit card refunds for amounts over y." -- How frequently do you use this application in a given day or week? -- Is the password you type into the application the same as the password you use to sign-in to Windows? - -Some organizations will empower their users to write this information while some may insist on having a member of the IT department shadow them. An objective viewer may notice a password prompt that the user overlooks simply because of muscle memory. As previously mentioned, this information is critical. You could miss one password prompt that could delay the transition to being password-less. - -#### Identify password usage and plan, develop, and deploy password mitigations - -Your test users have provided you valuable information that describes how, what, why, and when they use a password. It's now time for your team to identify each of these password use cases and understand why the user must use a password. - -Create a list of the scenarios. Each scenario should have a clear problem statement. Name the scenario with a one-sentence summary of the problem statement. Include in the scenario the results of your team's investigation as to why the user is prompted by a password. Include relevant, but accurate details. If it's policy or procedure driven, then include the name and section of the policy that dictates why the workflow uses a password. - -Keep in mind your test users won't uncover all scenarios. Some scenarios you'll need to force on your users because they're low percentage scenarios. Remember to include the following scenarios: - -- Provisioning a new brand new user without a password. -- Users who forget the PIN or other remediation flows when the strong credential is unusable. - -Next, review your list of scenarios. You can start with the workflows that are dictated by process or policy, or you can begin with workflows that need technical solutions, whichever of the two is easier or quicker. This choice will certainly vary by organization. - -Start mitigating password usages based on the workflows of your targeted personas. Document the mitigation as a solution to your scenario. Don't worry about the implementation details for the solution. An overview of the changes needed to reduce the password usages is all you need. If there are technical changes needed, either infrastructure or code changes, the exact details will likely be included in the project documentation. However your organization tracks projects, create a new project in that system. Associate your scenario to that project and start the processes needed to get that project funded. - -Mitigating password usage with applications is one of the more challenging obstacles in the password-less journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS). - -The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Azure identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases. - -Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to use federated identities or Windows integrated authentication. Work with third-party software vendors to update their software to support federated identities or Windows integrated authentication. - -#### Repeat until all user password usage is mitigated - -Some or all of your mitigations are in place. You need to validate that your solutions have solved their problem statements. This stage is where you rely on your test users. You want to keep a good portion of your first test users, but this point is a good opportunity to replace a few or add a few. Survey test users workflow for password usage. If all goes well, you've closed most or all of the gaps. A few are likely to remain. Evaluate your solutions and what went wrong, change your solution as needed until you reach a solution that removes your user's need to type a password. If you're stuck, others might be too. Use the forums from various sources or your network of IT colleagues to describe your problem and see how others are solving it. If you're out of options, contact Microsoft for assistance. - -#### Remove password capabilities from Windows - -You believe you've mitigated all the password usage for the targeted work persona. Now comes the true test: configure Windows so the user can't use a password. - -Windows provides two ways to prevent your users from using passwords. You can use an interactive logon security policy to only allow Windows Hello for Business sign-in and unlocks, or you can exclude the password credential provider. - -##### Security policy - -You can use Group Policy to deploy an interactive logon security policy setting to the computer. This policy setting is found under **Computer Configuration > Policies > Windows Settings > Local Policy > Security Options**. The name of the policy setting depends on the version of the operating systems you use to configure Group Policy. - -:::image type="content" source="images/passwordless-strategy/gpmc-security-options.png" alt-text="The Group Policy Management Editor displaying the location of the Security Options node."::: - -**Windows Server 2016 and earlier** -The policy name for these operating systems is **Interactive logon: Require smart card**. - -:::image type="content" source="images/passwordless-strategy/gpmc-require-smart-card-policy.png" alt-text="The Group Policy Management Editor displaying the location of the policy 'Interactive logon: Require smart card'."::: - -**Windows 10, version 1703 or later using Remote Server Administrator Tools** -The policy name for these operating systems is **Interactive logon: Require Windows Hello for Business or smart card**. - -:::image type="content" source="images/passwordless-strategy/require-whfb-smart-card-policy.png" alt-text="Highlighting the security policy 'Interactive logon: Require Windows Hello for Business or smart card'."::: - -When you enable this security policy setting, Windows prevents users from signing in or unlocking with a password. The password credential provider remains visible to the user. If a user tries to use a password, Windows informs the user they must use Windows Hello for Business or a smart card. - -#### Excluding the password credential provider - -You can use Group Policy to deploy an administrative template policy setting to the computer. This policy setting is found under **Computer Configuration > Policies > Administrative Templates > System > Logon**: - -:::image type="content" source="images/passwordless-strategy/gpmc-exclude-credential-providers.png" alt-text="The Group Policy Management Editor displaying the location of 'Logon' node and the policy setting 'Exclude credential providers'."::: - -The name of the policy setting is **Exclude credential providers**. The value to enter in the policy to hide the password credential provider is `{60b78e88-ead8-445c-9cfd-0b87f74ea6cd}`. - -:::image type="content" source="images/passwordless-strategy/exclude-credential-providers-properties.png" alt-text="Properties of the policy setting 'Exclude credential providers'."::: - -Excluding the password credential provider hides the password credential provider from Windows and any application that attempts to load it. This configuration prevents the user from entering a password using the credential provider. However, this change doesn't prevent applications from creating their own password collection dialogs and prompting the user for a password using custom dialogs. - -#### Validate that none of the workflows needs passwords - -This stage is the significant moment. You have identified password usage, developed solutions to mitigate password usage, and have removed or disabled password usage from Windows. In this configuration, your users won't be able to use a password. Users will be blocked if any of their workflows ask them for a password. Ideally, your test users should be able to complete all the work flows of the targeted work persona without any password usage. Don't forget those low percentage work flows, such as provisioning a new user or a user that forgot their PIN or can't use their strong credential. Ensure those scenarios are validated as well. - -### Transition into a password-less deployment (step 3) - -Congratulations! You're ready to transition one or more portions of your organization to a password-less deployment. You've validated that the targeted work persona is ready to go where the user no longer needs to know or use their password. You're just a few steps away from declaring success. - -#### Awareness and user education - -In this last step, you're going to include the remaining users that fit the targeted work persona to the wonderful world of password freedom. Before you do this step, you want to invest in an awareness campaign. - -An awareness campaign introduces the users to the new way of authenticating to their device, such as using Windows Hello for Business. The idea of the campaign is to positively promote the change to the users in advance. Explain the value and why your company is changing. The campaign should provide dates and encourage questions and feedback. This campaign can coincide with user education, where you can show the users the changes and, if your environment allows, enable the users to try out the experience. - -#### Including remaining users that fit the work persona - -You've implemented the awareness campaign for the targeted users. These users are informed and ready to transition to being password-less. Add the remaining users that match the targeted work persona to your deployment. - -#### Validate that none of the users of the work personas needs passwords - -You've successfully transitioned all users for the targeted work persona to being password-less. Monitor the users within the work persona to ensure they don't encounter any issues while working in a password-less environment. - -Track all reported issues. Set priority and severity to each reported issue and have your team triage the issues appropriately. As you triage issues, consider the following questions: - -- Is the reporting user performing a task outside the work persona? -- Is the reported issue affecting the entire work persona, or only specific users? -- Is the outage a result of a misconfiguration? -- Is the outage an overlooked gap from step 2? - -Each organization's priority and severity will differ. However, most organizations consider work stoppages to be fairly significant. Your team should predefine levels of priority and severity. With each of these levels, create service level agreements (SLAs) for each combination of severity and priority, and hold everyone accountable to those agreements. Reactive planning enables people to spend more time on the issue and resolving it, and less time on the process. - -Resolve the issues per your service level agreements. Higher severity items may require returning some or all of the user's password surface. Clearly this outcome isn't the end goal, but don't let it slow down your momentum towards becoming password-less. Refer to how you reduced the user's password surface in step 2 and progress forward to a solution, deploying that solution and validating it. - -#### Configure user accounts to disallow password authentication - -You transitioned all the users for the targeted work persona to a password-less environment and you've successfully validated all their workflows. The last step to complete the password-less transition is to remove the user's knowledge of the password and prevent the authenticating authority from accepting passwords. - -You can change the user's password to random data and prevent domain controllers from allowing users to use passwords for interactive sign-ins using an account configuration on the user object. - -The account options on a user account include the option **Smart card is required for interactive logon**, also known as SCRIL. - -> [!NOTE] -> Do not confuse the Interactive Logon security policy for SCRIL. Security policies are enforced on the client (locally). A user account configured for SCRIL is enforced at the domain controller. - -The following image shows the SCRIL setting for a user in Active Directory Users and Computers: - -:::image type="content" source="images/passwordless-strategy/aduc-account-scril.png" alt-text="Example user properties in Active Directory that shows the SCRIL setting on Account options."::: - -When you configure a user account for SCRIL, Active Directory changes the affected user's password to a random 128 bits of data. Additionally, domain controllers hosting the user account don't allow the user to sign-in interactively with a password. Users will no longer need to change their password when it expires, because passwords for SCRIL users don't expire. The users are effectively password-less because: - -- They don't know their password. -- Their password is 128 random bits of data and is likely to include non-typable characters. -- The user isn't asked to change their password. -- Domain controllers don't allow passwords for interactive authentication. - -The following image shows the SCRIL setting for a user in Active Directory Administrative Center on Windows Server 2012: - -:::image type="content" source="images/passwordless-strategy/server-2012-adac-user-scril.png" alt-text="Example user properties in Windows Server 2012 Active Directory Administrative Center that shows the SCRIL setting."::: - -> [!NOTE] -> Although a SCRIL user's password never expires in early domains, you can toggle the SCRIL configuration on a user account to generate a new random 128 bit password. Use the following process to toggle this configuration: -> -> 1. Disable the setting. -> 1. Save changes. -> 1. Enable the setting. -> 1. Save changes again. -> -> When you upgrade the domain functional level to Windows Server 2016 or later, the domain controller automatically does this action for you. - -The following image shows the SCRIL setting for a user in Active Directory Administrative Center on Windows Server 2016: - -:::image type="content" source="images/passwordless-strategy/server-2016-adac-user-scril.png" alt-text="Example user properties in Windows Server 2016 Active Directory Administrative Center that shows the SCRIL setting."::: - -> [!TIP] -> Windows Hello for Business was formerly known as Microsoft Passport. - -##### Automatic password change for SCRIL configured users - -Domains configured for Windows Server 2016 or later domain functional level can further secure the unknown password for SCRIL-enabled users by configuring the domain to automatically change the password for SCRIL users. - -In this configuration, passwords for SCRIL-configured users expire based on Active Directory password policy settings. When the SCRIL user authenticates from a domain controller, the domain controller recognizes the password has expired, and automatically generates a new random 128-bit password for the user as part of the authentication. This feature is great because your users don't experience any change password notifications or any authentication outages. - -:::image type="content" source="images/passwordless-strategy/server-2016-adac-domain-scril.png" alt-text="The Active Directory Administrative Center on Windows Server 2016 showing the domain setting for SCRIL."::: - -> [!NOTE] -> Some components within Windows 10, such as Data Protection APIs and NTLM authentication, still need artifacts of a user possessing a password. This configuration provides interoperability by reducing the usage surface while Microsoft continues to close the gaps to remove the password completely. diff --git a/windows/security/identity-protection/hello-for-business/pin-reset.md b/windows/security/identity-protection/hello-for-business/pin-reset.md index 1b06da1cd6..85a33cf10c 100644 --- a/windows/security/identity-protection/hello-for-business/pin-reset.md +++ b/windows/security/identity-protection/hello-for-business/pin-reset.md @@ -1,7 +1,7 @@ --- title: PIN reset description: Learn how Microsoft PIN reset service enables your users to recover a forgotten Windows Hello for Business PIN, and how to configure it. -ms.date: 12/12/2023 +ms.date: 01/03/2024 ms.topic: how-to --- @@ -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.| - - ## 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 +----------------------------------------------------------------------+ ``` - - ## Configure allowed URLs for federated identity providers on Microsoft Entra joined devices **Applies to:** Microsoft Entra joined devices diff --git a/windows/security/identity-protection/hello-for-business/policy-settings.md b/windows/security/identity-protection/hello-for-business/policy-settings.md new file mode 100644 index 0000000000..050b2a862d --- /dev/null +++ b/windows/security/identity-protection/hello-for-business/policy-settings.md @@ -0,0 +1,86 @@ +--- +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: 01/03/2024 +--- + +# Windows Hello for Business policy settings + +This reference article provides a comprehensive list of policy settings for Windows Hello for Business. 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 + +For information about how to configure these settings, see [Configure Windows Hello for Business](configure.md). + +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)|✅|✅| +|[Use PIN recovery](#use-pin-recovery)|✅|✅| + +[!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)] +--- diff --git a/windows/security/identity-protection/hello-for-business/rdp-sign-in.md b/windows/security/identity-protection/hello-for-business/rdp-sign-in.md index f3b6b984fe..6a84e6ea32 100644 --- a/windows/security/identity-protection/hello-for-business/rdp-sign-in.md +++ b/windows/security/identity-protection/hello-for-business/rdp-sign-in.md @@ -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) diff --git a/windows/security/identity-protection/hello-for-business/toc.yml b/windows/security/identity-protection/hello-for-business/toc.yml index 61aa6291c3..d328574c69 100644 --- a/windows/security/identity-protection/hello-for-business/toc.yml +++ b/windows/security/identity-protection/hello-for-business/toc.yml @@ -1,40 +1,31 @@ items: - name: Overview href: index.md -- name: Concepts - expanded: true +- name: How Windows Hello for Business works 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: Core concepts + href: how-it-works.md + - name: How device registration works 🔗 + href: /entra/identity/devices/device-registration-how-it-works + - name: How provisioning works + href: how-it-works-provisioning.md + - name: How authentication works + href: how-it-works-authentication.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,16 +35,11 @@ items: href: hello-errors-during-pin-creation.md - name: Reference items: - - name: How Windows Hello for Business provisioning works - href: hello-how-it-works-provisioning.md - - name: How Windows Hello for Business authentication works - href: hello-how-it-works-authentication.md + - name: Windows Hello for Business policy settings + href: policy-settings.md - name: WebAuthn APIs href: webauthn-apis.md - - name: Technology and terminology - href: hello-how-it-works-technology.md + - name: Windows Hello Enhanced Security Sign-in (ESS) 🔗 + href: /windows-hardware/design/device-experiences/windows-hello-enhanced-sign-in-security - name: Frequently Asked Questions (FAQ) - href: hello-faq.yml - - name: Windows Hello for Business videos - href: hello-videos.md - + href: faq.yml diff --git a/windows/security/identity-protection/images/security-stages.png b/windows/security/identity-protection/images/security-stages.png deleted file mode 100644 index 249ced9d4b..0000000000 Binary files a/windows/security/identity-protection/images/security-stages.png and /dev/null differ diff --git a/windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-off.png b/windows/security/identity-protection/passwordless-strategy/images/lock-screen.png similarity index 100% rename from windows/security/identity-protection/hello-for-business/images/passwordless/lock-screen-off.png rename to windows/security/identity-protection/passwordless-strategy/images/lock-screen.png diff --git a/windows/security/identity-protection/passwordless-strategy/images/passwordless-experience.png b/windows/security/identity-protection/passwordless-strategy/images/passwordless-experience.png new file mode 100644 index 0000000000..9e6208dc50 Binary files /dev/null and b/windows/security/identity-protection/passwordless-strategy/images/passwordless-experience.png differ diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-1-off.svg b/windows/security/identity-protection/passwordless-strategy/images/step-1-off.svg new file mode 100644 index 0000000000..e94f7a1297 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-1-off.svg @@ -0,0 +1,28 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-1-on.svg b/windows/security/identity-protection/passwordless-strategy/images/step-1-on.svg new file mode 100644 index 0000000000..e2aa74f089 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-1-on.svg @@ -0,0 +1,26 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-2-off.svg b/windows/security/identity-protection/passwordless-strategy/images/step-2-off.svg new file mode 100644 index 0000000000..add20cb602 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-2-off.svg @@ -0,0 +1,28 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-2-on.svg b/windows/security/identity-protection/passwordless-strategy/images/step-2-on.svg new file mode 100644 index 0000000000..688724e117 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-2-on.svg @@ -0,0 +1,26 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-3-off.svg b/windows/security/identity-protection/passwordless-strategy/images/step-3-off.svg new file mode 100644 index 0000000000..6faecafc75 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-3-off.svg @@ -0,0 +1,28 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-3-on.svg b/windows/security/identity-protection/passwordless-strategy/images/step-3-on.svg new file mode 100644 index 0000000000..b5cfd72d86 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-3-on.svg @@ -0,0 +1,26 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-4-off.svg b/windows/security/identity-protection/passwordless-strategy/images/step-4-off.svg new file mode 100644 index 0000000000..4507a878b5 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-4-off.svg @@ -0,0 +1,28 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/images/step-4-on.svg b/windows/security/identity-protection/passwordless-strategy/images/step-4-on.svg new file mode 100644 index 0000000000..2eeee15393 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/images/step-4-on.svg @@ -0,0 +1,26 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + diff --git a/windows/security/identity-protection/passwordless-strategy/index.md b/windows/security/identity-protection/passwordless-strategy/index.md new file mode 100644 index 0000000000..b0887dd2fd --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/index.md @@ -0,0 +1,153 @@ +--- +title: Passwordless strategy overview +description: Learn about the passwordless strategy and how Windows security features help implementing it. +ms.topic: concept-article +ms.date: 01/29/2024 +--- + +# Passwordless strategy overview + +This article describes Microsoft's passwordless strategy and how Windows security features help implementing it. + +## Four steps to password freedom + +Microsoft is working hard to create a world where passwords are no longer needed. This is how Microsoft envisions the four steps approach to end the era of passwords for the organizations: + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-1-on.svg" border="false"::: + :::column-end::: + :::column span="3"::: + ### Deploy a password replacement option + :::column-end::: +:::row-end::: + +Before you move away from passwords, you need something to replace them. Windows Hello for Business and FIDO2 security keys offer a strong, hardware-protected two-factor credential that enables single sign-on to Microsoft Entra ID and Active Directory.\ +Deploy Windows Hello for Business or FIDO2 security keys is the first step toward a passwordless environment. Users are likely to use these features because of their convenience, especially when combined with biometrics. However, some workflows and applications might still need passwords. This early stage is about implementing an alternative solution to passwords, and getting users accustomed to it. + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-2-on.svg" border="false"::: + :::column-end::: + :::column span="3"::: + ### Reduce user-visible password surface area + :::column-end::: +:::row-end::: + +With a password replacement option and passwords coexisting in the environment, the next step is to reduce the password surface area. The environment and workflows need to stop asking for passwords. The goal of this step is to achieve a state where the users know they have a password, **but they never use it**. This state helps decondition users from providing a password anytime a password prompt shows on their computer. This behavior is how passwords are phished. Users who rarely, if at all, use their password are unlikely to provide it. **Password prompts are no longer the norm**. + + + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-3-on.svg" border="false"::: + :::column-end::: + :::column span="3"::: + ### Transition into a passwordless deployment + :::column-end::: +:::row-end::: + +Once the user-visible password surface is eliminated, your organization can begin to transition users into a passwordless environment. In this stage, users never type, change, or even know their password.\ +The user signs in to Windows using Windows Hello for Business or FIDO2 security keys, and enjoys single sign-on to Microsoft Entra ID and Active Directory resources. If the user is forced to authenticate, their authentication uses Windows Hello for Business or FIDO2 security keys. + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-4-on.svg" border="false"::: + :::column-end::: + :::column span="3"::: + ### Eliminate passwords from the identity directory + :::column-end::: +:::row-end::: + +The final step of the passwordless journey is where passwords don't exist. At this stage, identity directories don't store any form of the password. + +## Prepare for the passwordless journey + +The road to being passwordless is a journey. The duration of the journey varies for each organization. It's important for IT decision makers to understand the criteria influencing the length of that journey. + +The most intuitive answer is the size of the organization, but what exactly defines size? We can look at these factors to get a summary of the organization's size: + +| Size factor | Details | +|--|--| +| **Number of departments**|The number of departments within an organization varies. Most organizations have a common set of departments such as *executive leadership*, *human resources*, *accounting*, *sales*, and *marketing*. Small organizations might not explicitly segment their departments, while larger ones might. Additionally, there may be subdepartments, and subdepartments of those subdepartments as well.

      You need to know all the departments within your organization, and you need to know which departments use computers and which ones don't. It's fine if a department doesn't use computers (probably rare, but acceptable). This circumstance means there's one less department with which you need to concern yourself. Nevertheless, ensure this department is in your list and that it's not applicable.

      Your count of the departments must be thorough and accurate, as well as knowing the stakeholders for those departments that put you and your staff on the road to password freedom. Realistically, many of us lose sight of our organizational chart and how it grows or shrinks over time. This realization is why you need to inventory all of them. Also, don't forget to include external departments such as vendors or federated partners. If your organization goes passwordless, but your partners continue to use passwords to access your corporate resources, you should know about it and include them in your passwordless strategy.| +| **Organization or department hierarchy**|Organization and department hierarchy is the management layers within the departments or the organization as a whole. How the device is used, what applications and how they're used, most likely differs between each department, but also within the structure of the department. To determine the correct passwordless strategy, you need to know these differences across your organization. An executive leader is likely to use their device differently compared to a member of middle management in the sales department. Both of those user cases are probably different to how an individual contributor in the customer service department uses their device.| +| **Number and type of applications and services**|Most organizations have many applications and rarely have one centralized list that's accurate. Applications and services are the most critical items in your passwordless assessment. Applications and services take considerable effort to move to a different type of authentication. Changing policies and procedures can be a daunting task. Consider the trade-off between updating your standard operating procedures and security policies compared to changing 100 lines (or more) of authentication code in the critical path of your internally developed CRM application.

      Capturing the number of applications used is easier once you have the departments, their hierarchy, and their stakeholders. In this approach, you should have an organized list of departments and the hierarchy in each. You can now associate the applications that are used by all levels within each department. You also want to document whether the application is internally developed or commercially available off-the-shelf. If the latter, document the manufacturer and the version. Also, don't forget web-based applications or services when inventorying applications.| +| **Number of work personas**|Work personas are where the three previous efforts converge. You know the departments, the organizational levels within each department, the numbers of applications used by each, respectively, and the type of application. From this information, you want to create a work persona.

      A work persona classifies a category of user, title or role (individual contributor, manager, middle manager, etc.), within a specific department to a collection of applications used. There's a high probability that you have many work personas. These work personas will become units of work, and you refer to them in documentation and in meetings. You need to give them a name.

      Give your personas easy and intuitive names like *Amanda - Accounting*, *Mark - Marketing*, or *Sue - Sales*. If the organization levels are common across departments, then decide on a first name that represents the common levels in a department. For example, *Amanda* could be the first name of an individual contributor in any given department, while the first name *Sue* could represent someone from middle management in any given department. Additionally, you can use suffixes (such as *I*, *II*, *Senior*, etc.) to further define departmental structure for a given persona.

      Ultimately, create a naming convention that doesn't require your stakeholders and partners to read through a long list of tables or a secret decoder ring. Also, if possible, try to keep the references as names of people. After all, you're talking about a person who is in that department and who uses that specific software.| +| **Organization's IT structure**|IT department structures can vary more than the organization. Some IT departments are centralized while others are decentralized. Also, the road to password freedom will probably have you interacting with the *client authentication* team, the *deployment* team, the *security* team, the *PKI* team, the *identity* team, the *cloud* team, etc. Most of these teams are your partner on your journey to password freedom. Ensure there's a passwordless stakeholder on each of these teams, and that the effort is understood and funded.| + +## Assess your organization + +By now you can understand why this is a journey and not a quick task. You need to investigate user-visible password surfaces for each of your work personas. Once you've identified the password surfaces, you need to mitigate them. Resolving some password surfaces are simple - meaning a solution already exists in the environment and it's only a matter of moving users to it. Resolution to some passwords surfaces might exist, but aren't deployed in your environment. That resolution results in a project that must be planned, tested, and then deployed. That project is likely to span multiple IT departments with multiple people, and potentially one or more distributed systems. Those types of projects take time and need dedicated cycles. This same sentiment is true with in-house software development. Even with agile development methodologies, changing the way someone authenticates to an application is critical. Without the proper planning and testing, it has the potential to severely affect productivity. + +The time to complete the passwordless journey varies, depending on the organizational alignment to a passwordless strategy. Top-down agreement that a passwordless environment is the organization's goal makes conversations easier. Easier conversations mean less time spent convincing people and more time spent moving toward the goal. Top-down agreement, as a priority within the ranks of other on-going IT projects, helps everyone understand how to prioritize existing projects. Agreeing on priorities should reduce and minimize manager and executive level escalations. After these organizational discussions, modern project management techniques are used to continue the passwordless effort. The organization allocates resources based on the priority (after they agreed on the strategy). Those resources will: + +- Work through the work personas +- Organize and deploy user acceptance testing +- Evaluate user acceptance testing results for user visible password surfaces +- Work with stakeholders to create solutions that mitigate user visible password surfaces +- Add the solution to the project backlog and prioritize against other projects +- Deploy the solution +- Perform user acceptance testing to confirm that the solution mitigates the user visible password surface +- Repeat the testing as needed + +Your organization's journey to password freedom may take some time. Counting the number of work personas and the number of applications is a good indicator of the investment. Hopefully, your organization is growing, which means that the list of personas and the list of applications is unlikely to shrink. If the work to go passwordless today is *n*, then it's likely that to go passwordless tomorrow is *n x 2* or more, *n x n*. Don't let the size or duration of the project be a distraction. As you progress through each work persona, the actions and tasks become more familiar for you and your stakeholders. Scope the project to sizable, realistic phases, pick the correct work personas, and soon you'll see parts of your organization transition to a passwordless state. + +What's the best guidance for kicking off the journey to password freedom? **You want to show your management a proof of concept as soon as possible**. Ideally, you want to show it at each step of your passwordless journey. Keeping your passwordless strategy top of mind and showing consistent progress keeps everyone focused. + +## Work persona + +You begin with your work personas. These were part of your preparation process. They have a persona name, such as *Amanda - Accounting II*, or any other naming convention your organization defined. That work persona includes a list of all the applications *Amanda* uses to perform her assigned duties in the accounting department. To start, you need to pick a work persona. It's the targeted work persona you enable to complete the journey. + +> [!TIP] +> Avoid using any work personas from your IT department. This method is probably the worst way to start the passwordless journey. IT roles are very difficult and time consuming. IT workers typically have multiple credentials, run a multitude of scripts and custom applications, and are the worst offenders of password usage. It is better to save these work personas for the middle or end of your journey. + +Review your collection of work personas. Early in your passwordless journey, identify personas with the fewest applications. These work personas could represent an entire department or two. These roles are the perfect work personas for your proof-of-concept (POC) or pilot. + +Most organizations host their POC in a test lab or environment. If you do that test with a password-free strategy, it might be more challenging and take more time. To test in a lab, you must first duplicate the environment of the targeted persona. This process could take a few days or several weeks, depending on the complexity of the targeted work persona. + +You want to balance lab testing with providing results to management quickly. Continuing to show forward progress on your journey to password freedom is always a good thing. If there are ways you can test in production with low or no risk, it might be advantageous to your timeline. + +The journey to password freedom is to take each work persona through each step of the process. In the beginning, we encourage working with one persona at a time to ensure team members and stakeholders are familiar with the process. Once comfortable with the process, you can cover as many work personas in parallel as resources allow. The process looks something like this: + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-1-on.svg" border="false" link="journey-step-1.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-2-on.svg" border="false" link="journey-step-2.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-3-on.svg" border="false" link="journey-step-3.md"::: + :::column-end::: +:::row-end::: +:::row::: + :::column span="1"::: +**[Deploy a passwordless replacement option](journey-step-1.md)** +- Identify test users representing the targeted work persona +- Deploy Windows Hello for Business to test users +- Validate that passwords and Windows Hello for Business work + :::column-end::: + :::column span="1"::: +**[Reduce user-visible password surface](journey-step-2.md)** +- Survey test user workflow for password usage +- Identify password usage and plan, develop, and deploy password mitigations +- Repeat until all user password usage is mitigated +- Remove password capabilities from Windows +- Validate that **none of the workflows** need passwords + :::column-end::: + :::column span="1"::: +**[Transition into a passwordless scenario](journey-step-3.md)** +- Awareness campaign and user education +- Include remaining users who fit the work persona +- Validate that **none of the users** of the work personas need passwords +- Configure user accounts to prevent password authentication + :::column-end::: +:::row-end::: + +After successfully moving a work persona to password freedom, you can prioritize the remaining work personas and repeat the process. + +## Next steps + +> [!div class="nextstepaction"] +> +> [Step 1: deploy a passwordless replacement option >](journey-step-1.md) diff --git a/windows/security/identity-protection/passwordless-strategy/journey-step-1.md b/windows/security/identity-protection/passwordless-strategy/journey-step-1.md new file mode 100644 index 0000000000..0708d80254 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/journey-step-1.md @@ -0,0 +1,61 @@ +--- +title: Deploy a passwordless replacement option +description: Learn about how to deploy a passwordless replacement option, the first step of the Microsoft passwordless journey. +ms.topic: concept-article +ms.date: 01/29/2024 +--- + +# Deploy a passwordless replacement option + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-1-on.svg" border="false" link="journey-step-1.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-2-off.svg" border="false" link="journey-step-2.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-3-off.svg" border="false" link="journey-step-3.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-4-off.svg" border="false"::: + :::column-end::: +:::row-end::: + +The first step to password freedom is providing an alternative to passwords.\ +Windows provides an affordable and easy in-box alternative to passwords, *Windows Hello for Business*. Another option is to use *FIDO2 security keys*, but they require the organization to purchase and distribute them. + +Both options provide a strong, two-factor authentication to Microsoft Entra ID and Active Directory. + +## Identify test users representing the targeted work persona + +A successful transition relies on user acceptance testing. It's impossible for you to know how every work persona goes about their day-to-day activities, or how to accurately validate them. You need to enlist the help of users who fit the targeted work persona. You only need a few users from the targeted work persona. As you cycle through step 2, you might want to change a few of the users (or add a few) as part of your validation process. + +## Deploy Windows Hello for Business or FIDO2 security keys to test users + +Next, you want to plan your password replacement deployment. Your test users need an alternative way to sign-in during step 2 of the journey to becoming passwordless. Use the [Windows Hello for Business planning guide](..\hello-for-business\deploy\index.md) to help learning which deployment is best suited for your environment. Next, use one of the deployment guides to deploy Windows Hello for Business. With the Windows Hello for Business infrastructure in place, you can limit Windows Hello for Business enrollments to the targeted work personas. The great news is that you only need to deploy the infrastructure once. When other targeted work personas need to start using Windows Hello for Business, add them to a group. You use the first work persona to validate your Windows Hello for Business deployment. + +If you decide to use FIDO2 security keys, follow the [Enable security key sign-in to Windows guide](/entra/identity/authentication/howto-authentication-passwordless-security-key-windows) to learn how to adopt FIDO2 security keys. + +> [!NOTE] +> Deployments vary based on how the device is joined to Microsoft Entra ID. Review the planning guide to learn the type of infrastructure required to support your devices. + +## Validate passwords and Windows Hello for Business or FIDO2 security keys + +In this first step, passwords and your password replacement choice must coexist. You want to validate all scenarios while the targeted work personas can sign in and unlock using Windows Hello or security keys. Users can also sign-in, unlock, and use passwords as needed. Reducing the user-visible password surface too soon can create frustration and confusion with your targeted user personas. + +:::image type="content" source="images/lock-screen.png" alt-text="Screenshot of the Windows lock screen showing the fingerprint, PIN and password credential providers." border="false"::: + +## Next steps + +> [!div class="checklist"] +> Before you move to step 2, make sure you've: +> +> - Selected your targeted work persona +> - Identified your test users who represent the targeted work persona +> - Deployed Windows Hello for Business or FIDO2 security keys to test users +> - Validated that both your password replacement choice and passwords work for the test users + +> [!div class="nextstepaction"] +> +> [Step 2: reduce the user-visible password surface area >](journey-step-2.md) diff --git a/windows/security/identity-protection/passwordless-strategy/journey-step-2.md b/windows/security/identity-protection/passwordless-strategy/journey-step-2.md new file mode 100644 index 0000000000..4d8d3b920a --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/journey-step-2.md @@ -0,0 +1,105 @@ +--- +title: Reduce the user-visible password surface area +description: Learn about how to reduce the user-visible password surface area, the second step of the Microsoft passwordless journey. +ms.topic: concept-article +ms.date: 01/29/2024 +--- + +# Reduce the user-visible password surface area + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-1-off.svg" border="false" link="journey-step-1.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-2-on.svg" border="false" link="journey-step-2.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-3-off.svg" border="false" link="journey-step-3.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-4-off.svg" border="false"::: + :::column-end::: +:::row-end::: + +## Survey test user workflow for password usage + +Now is the time to learn more about the targeted work persona. You should have a list of applications they use, but you don't know what, why, when, and how frequently. This information is important as you further your progress through step 2. Test users create the workflows associated with the targeted work persona. Their initial goal is to do one simple task: document password usage. This list isn't a comprehensive one, but it gives you an idea of the type of information you want. The goal is to learn about all the scenarios in which that work persona encounters a password. A good approach is to ask yourself the following set of questions: + +| | Question | +|--|--| +| **🔲** | *What's the name of the application that asked for a password?* | +| **🔲** | *Why do they use the application that asked for a password? For example, is there more than one application that can do the same thing?* | +| **🔲** | *What part of their workflow makes them use the application? Try to be as specific as possible. For example, "I use application x to issue credit card refunds for amounts over y."* | +| **🔲** | *How frequently do you use the application in a given day or week?* | +| **🔲** | *Is the password you type into the application the same as the password you use to sign-in to Windows?* | + +Some organizations empower their users to write this information, while some might insist on having a member of the IT department shadow them. An objective viewer might notice a password prompt that the user overlooks simply because of muscle memory. As previously mentioned, this information is critical. You could miss one password prompt that could delay the transition to being passwordless. + +## Identify password usage and plan, develop, and deploy password mitigations + +Your test users provided you valuable with information that describes how, what, why, and when they use a password. It's now time for your team to identify each of these password use cases and understand why the user must use a password.\ +Create a list of the scenarios. Each scenario should have a clear problem statement. Name the scenario with a one-sentence summary of the problem statement. Include in the scenario the results of your team's investigation as to why the user is asked to provide a password. Include relevant, but accurate details. If the scenario is policy or procedure-driven, then include the name and section of the policy that dictates why the workflow uses a password. + +Your test users won't uncover all scenarios, therefore you must force on them some uncommon scenarios. Remember to include the following: + +- Provision a new user with an unknown password +- Users who forget the PIN or other remediation flows when the strong credential is unusable + +Next, review your list of scenarios. You can start with the workflows that are dictated by process or policy, or you can begin with workflows that need technical solutions, whichever of the two is easier or quicker. This choice varies by organization. + +Start mitigating password usages based on the workflows of your targeted personas. Document the mitigation as a solution to your scenario. Don't worry about the implementation details for the solution. An overview of the changes needed to reduce the password usages is all you need. If there are technical changes needed, either infrastructure or code changes, the exact details are likely included in the project documentation. However your organization tracks projects, create a new project in that system. Associate your scenario to that project and start the processes needed to get that project funded. + +Mitigating password usage with applications is one of the more challenging obstacles in the passwordless journey. If your organization develops the application, then you are in better shape the common-off-the-shelf software (COTS). + +The ideal mitigation for applications that prompt the user for a password is to enable those applications to use an existing authenticated identity, such as Microsoft Entra ID or Active Directory. Work with the applications vendors to have them add support for Microsoft Entra identities. For on-premises applications, have the application use Windows integrated authentication. The goal for your users should be a seamless single sign-on experience where each user authenticates once when they sign-in to Windows. Use this same strategy for applications that store their own identities in their own databases. + +Each scenario on your list should now have a problem statement, an investigation as to why the password was used, and a mitigation plan on how to make the password usage go away. Armed with this data, one-by-one, close the gaps on user-visible passwords. Change policies and procedures as needed, make infrastructure changes where possible. Convert in-house applications to integrate in your Microsoft Entra ID tenant, use federated identities, or use Windows integrated authentication. Work with third-party software publishers to update their software to integrate in Microsoft Entra ID, support federated identities, or use Windows integrated authentication. + +## Repeat until all user password usage is mitigated + +Some or all of your mitigations are in place. You need to validate that your solutions solved their problem statements. This stage is where you rely on your test users. You want to keep a good portion of your first test users, but this point is a good opportunity to replace or add a few. Survey test users workflow for password usage. If all goes well, you closed most or all of the gaps. A few are likely to remain. Evaluate your solutions and what went wrong, change your solution as needed until you reach a solution that removes your user's need to type a password. If you're stuck, others might be too. Use the forums from various sources or your network of IT colleagues to describe your problem and see how others are solving it. If you're out of options, contact Microsoft for assistance. + +## Remove password capabilities from Windows + +You believe you mitigated all the password usage for the targeted work persona. Now comes the true test: configure Windows so the user can't use a password.\ +Windows offers three main options to reduce or eliminate the password surface area: + +- Windows passwordless experience +- Exclude the password credential provider +- Require Windows Hello for Business or a smart card + +### Windows passwordless experience + +*Windows Passwordless experience* is a security policy that hides the password credential provider for user accounts that sign in with Windows Hello or a FIDO2 security key. Windows Passwordless experience is the recommended option, but it's only available on Microsoft Entra joined devices. The following image shows the Windows lock screen when Windows passwordless experience is enabled. A user enrolled in Windows Hello for Business doesn't have the option to use a password to sign in: + +:::image type="content" source="images/passwordless-experience.png" alt-text="Screenshot of the Windows lock screen with passwordless experience enabled." border="false"::: + +To learn more, see [Windows passwordless experience](../passwordless-experience/index.md) + +### Exclude the password credential provider + +The *Exclude credential providers* policy setting can be used to disable the password credential provider. When configured, Windows disables the possibility to use passwords for *all accounts*, including local accounts. It also prevents the use of passwords for RDP and *Run as* authentication scenarios. This policy setting might impact support scenarios, such as when a user needs to sign in with a local account to troubleshoot a problem. For this reason, carefully evaluate all scenarios before you enable the setting. + +- GPO: **Computer Configuration** > **Administrative Templates** > **System** > **Logon** > **Exclude credential providers** +- CSP: `./Device/Vendor/MSFT/Policy/Config/ADMX_CredentialProviders/`[ExcludedCredentialProviders](/windows/client-management/mdm/policy-csp-admx-credentialproviders#excludedcredentialproviders) + +The value to enter in the policy to hide the password credential provider is `{60b78e88-ead8-445c-9cfd-0b87f74ea6cd}`. + +### Require Windows Hello for Business or a smart card + +The *Require Windows Hello for Business or a smart card* policy setting can be used to require Windows Hello for Business or a smart card for interactive logon. When enabled, Windows prevents users from signing in or unlocking with a password. The password credential provider remains visible to the user. If a user tries to use a password, Windows informs the user they must use Windows Hello for Business or a smart card. Before you enable this policy setting, the user must be enrolled in Windows Hello for Business or have a smart card. Therefore, implementing this policy requires careful planning and coordination. + +- GPO: **Computer Configuration** > **Windows Settings** > **Security Settings** > **Local Policies** > **Security Options** > **Interactive logon: Require Windows Hello for Business or smart card** +- CSP: not available + +## Validate that none of the workflows needs passwords + +This stage is the significant moment. You identified password usage, developed solutions to mitigate password usage, and removed or disabled password usage from Windows. In this configuration, your users can't use a password. Users are blocked if any of their workflows ask them for a password. Ideally, your test users should be able to complete all the work flows of the targeted work persona without any password usage. Don't forget those low percentage work flows, such as provisioning a new user or a user that forgot their PIN or can't use their strong credential. Ensure those scenarios are validated as well. + +## Next steps + +> [!div class="nextstepaction"] +> You're ready to transition one or more portions of your organization to a passwordless deployment. You've validated that the targeted work persona is ready to go where the user no longer needs to know or use their password. You're just a few steps away from declaring success. +> +> [Step 3: transition into a passwordless deployment >](journey-step-3.md) diff --git a/windows/security/identity-protection/passwordless-strategy/journey-step-3.md b/windows/security/identity-protection/passwordless-strategy/journey-step-3.md new file mode 100644 index 0000000000..b50cd4f910 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/journey-step-3.md @@ -0,0 +1,144 @@ +--- +title: Transition into a passwordless deployment +description: Learn about how to transition into a passwordless deployment, the third step of the Microsoft passwordless journey. +ms.topic: concept-article +ms.date: 01/29/2024 +--- + +# Transition into a passwordless deployment + +:::row::: + :::column span="1"::: + :::image type="icon" source="images/step-1-off.svg" border="false" link="journey-step-1.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-2-off.svg" border="false" link="journey-step-2.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-3-on.svg" border="false" link="journey-step-3.md"::: + :::column-end::: + :::column span="1"::: + :::image type="icon" source="images/step-4-off.svg" border="false"::: + :::column-end::: +:::row-end::: + +## Awareness and user education + +In this last step, you're going to include the remaining users that fit the targeted work persona to the passwordless deployment. Before you do this step, you want to invest in an awareness campaign. + +An awareness campaign introduces the users to the new way of authenticating to their device, such as using Windows Hello for Business. The idea of the campaign is to positively promote the change to the users in advance. Explain the value and why your company is changing. The campaign should provide dates and encourage questions and feedback. This campaign can coincide with user education, where you can show the users the changes and, if your environment allows, enable the users to try out the experience. + +> [!TIP] +> To facilitate user communication and to ensure a successful Windows Hello for Business deployment, you can find customizable material (email templates, posters, trainings, etc.) at [Microsoft Entra templates](https://aka.ms/adminmails). + +## Include remaining users that fit the work persona + +You implemented the awareness campaign for the targeted users. These users are informed and ready to transition to being passwordless. Add the remaining users that match the targeted work persona to your deployment. + +## Validate that none of the users of the work personas need passwords + +You successfully transitioned all users for the targeted work persona to being passwordless. Monitor the users within the work persona to ensure they don't encounter any issues while working in a passwordless environment. + +Track all reported issues. Set priority and severity to each reported issue and have your team triage the issues appropriately. As you triage issues, consider the following questions: + +| | Question | +|--|--| +| **🔲** | *Is the reporting user performing a task outside the work persona?* | +| **🔲** | *Is the reported issue affecting the entire work persona, or only specific users?* | +| **🔲** | *Is the outage a result of a misconfiguration?* | +| **🔲** | *Is the outage an overlooked gap from step 2?* | + +Each organization's priority and severity differ. However, most organizations consider work stoppages to be fairly significant. Your team should predefine levels of priority and severity. With each of these levels, create service level agreements (SLAs) for each combination of severity and priority, and hold everyone accountable to those agreements. Reactive planning enables people to spend more time on the issue and resolving it, and less time on the process. + +Resolve the issues per your service level agreements. Higher severity items might require returning some or all of the user's password surface. Clearly this outcome isn't the end goal, but don't let it slow down your momentum towards becoming passwordless. Refer to how you reduced the user's password surface in step 2, and progress forward to a solution, deploying that solution and validating it. + +> [!TIP] +> Monitor your domain controllers for password authentication events. This helps to proactively identify users who are still using passwords, and to reach out to them. + +## Configure user accounts to prevent password authentication + +You transitioned all the users for the targeted work persona to a passwordless environment and validated all their workflows. The last step to complete the passwordless transition is to remove the user's knowledge of the password. + +### Password scrambling + +While you can't completely remove the password from the user's account, you can prevent the user from using the password to authenticate. The easiest and most effective approach is to set the password to a random value. This approach prevents the user from knowing the password and using it to authenticate, but it allows the user to reset the password whenever needed. + +> [!TIP] +> Enable [Microsoft Entra self-service password reset (SSPR)](/entra/identity/authentication/tutorial-enable-sspr) to allow the users to reset their password. Once implemented, users can sign in to their Windows devices using Windows Hello for Business or a FIDO2 security key, and reset their password from https://aka.ms/sspr. Combine it with [password writeback](/entra/identity/authentication/tutorial-enable-cloud-sync-sspr-writeback) to have the password reset synchronized to your on-premises Active Directory. + +The following sample PowerShell script generates a random password of 64 characters and sets it for the user specified in the variable name $userId against Microsoft Entra ID. +Modify the **userId** variable of the script to match your environment (first line), and then run it in a PowerShell session. When prompted to authenticate to Microsoft Entra ID, use the credentials of an account with a role capable of resetting passwords. + +```azurepowershell-interactive +$userId = "" + +function Generate-RandomPassword{ + [CmdletBinding()] + param ( + [int]$Length = 64 + ) + $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+[]{};:,.<>/?\|`~" + $random = New-Object System.Random + $password = "" + for ($i = 0; $i -lt $Length; $i++) { + $index = $random.Next(0, $chars.Length) + $password += $chars[$index] + } + return $password +} + +Set-ExecutionPolicy -ExecutionPolicy RemoteSigned -Scope CurrentUser -Force +Install-Module Microsoft.Graph -Scope CurrentUser +Import-Module Microsoft.Graph.Users.Actions +Connect-MgGraph -Scopes "UserAuthenticationMethod.ReadWrite.All" -NoWelcome + +$passwordParams = @{ + UserId = $userId + AuthenticationMethodId = "28c10230-6103-485e-b985-444c60001490" + NewPassword = Generate-RandomPassword +} + +Reset-MgUserAuthenticationMethodPassword @passwordParams +``` + +A similar script can be used to reset the password against Active Directory. Modify the **samAccountName** variable of the script to match your environment (first line), and then run it in a PowerShell session. + +```PowerShell +$samAccountName = + +function Generate-RandomPassword{ + [CmdletBinding()] + param ( + [int]$Length = 64 + ) + $chars = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789!@#$%^&*()-_=+[]{};:,.<>/?\|`~" + $random = New-Object System.Random + $password = "" + for ($i = 0; $i -lt $Length; $i++) { + $index = $random.Next(0, $chars.Length) + $password += $chars[$index] + } + return $password +} + +$NewPassword = ConvertTo-SecureString -String (Generate-RandomPassword) -AsPlainText -Force + +Set-ADAccountPassword -identity $userId -NewPassword $NewPassword -Reset +``` + +If your organizational policies allow it, you can configure the randomized passwords to never expire, or use a long expiration period. This configuration prevents the user from being prompted to change their password. + +> [!CAUTION] +> Execute the script only from a secure and trusted environment, and ensure that the script is not logged. Treat the host where the script is executed as a privileged host, with the same level of security as a domain controller. + +### Password age and password rotation + +If your organization doesn't have password rotation requirements, it's recommended to disable password age. + +If your organization has a password rotation policy, consider implementing automation to rotate the user's password regularly. This approach ensures that the user's password is always randomized and prevents the user from knowing the password. + +For more password-related guidance, see the whitepaper [Password Guidance](https://aka.ms/PasswordGuidance). + +## Next steps + +Microsoft is working hard to make the passwordless journey easier for you. We're working on new features and capabilities to help you transition to a passwordless environment, and to achieve the long-term security promise of a truly passwordless environment. Check back often to see what's new. diff --git a/windows/security/identity-protection/passwordless-strategy/toc.yml b/windows/security/identity-protection/passwordless-strategy/toc.yml new file mode 100644 index 0000000000..452824f4c4 --- /dev/null +++ b/windows/security/identity-protection/passwordless-strategy/toc.yml @@ -0,0 +1,9 @@ +items: +- name: Overview + href: index.md +- name: 1. Deploy password replacement options + href: journey-step-1.md +- name: 2. Reduce the password surface area + href: journey-step-2.md +- name: 3. Transition into a passwordless deployment + href: journey-step-3.md \ No newline at end of file diff --git a/windows/security/identity-protection/remote-credential-guard.md b/windows/security/identity-protection/remote-credential-guard.md index d7ffee21b2..dc9d66ddbd 100644 --- a/windows/security/identity-protection/remote-credential-guard.md +++ b/windows/security/identity-protection/remote-credential-guard.md @@ -1,9 +1,9 @@ --- -title: Remote Credential Guard +title: Remote Credential Guard description: Learn how Remote Credential Guard helps to secure Remote Desktop credentials by never sending them to the target device. ms.topic: how-to ms.date: 12/08/2023 -appliesto: +appliesto: - ✅ Windows 11 - ✅ Windows 10 - ✅ Windows Server 2022 @@ -36,7 +36,7 @@ The security benefits of Remote Credential Guard include: - During the remote session, you can connect to other systems using SSO - An attacker can act on behalf of the user only when the session is ongoing -The security benefits of [Restricted Admin mode][TECH-1] include: +The security benefits of Restricted Admin mode include: - Credentials aren't sent to the remote host - The Remote Desktop session connects to other resources as the remote host's identity @@ -84,7 +84,7 @@ To enable delegation of nonexportable credentials on the remote hosts, you can u [!INCLUDE [tab-intro](../../../includes/configure/tab-intro.md)] -#### [:::image type="icon" source="../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune) +#### [:::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)] @@ -100,7 +100,7 @@ Alternatively, you can configure devices using a [custom policy][INT-3] with the |--------| | - **OMA-URI:** `./Device/Vendor/MSFT/Policy/Config/CredentialsDelegation/RemoteHostAllowsDelegationOfNonExportableCredentials`
      - **Data type:** string
      - **Value:** ``| -#### [:::image type="icon" source="../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +#### [:::image type="icon" source="../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) [!INCLUDE [gpo-settings-1](../../../includes/configure/gpo-settings-1.md)] @@ -109,7 +109,7 @@ Alternatively, you can configure devices using a [custom policy][INT-3] with the | **Computer Configuration\Administrative Templates\System\Credentials Delegation** | Remote host allows delegation of nonexportable credentials | Enabled | [!INCLUDE [gpo-settings-2](../../../includes/configure/gpo-settings-2.md)] -#### [:::image type="icon" source="../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg) +#### [:::image type="icon" source="../images/icons/registry.svg" border="false"::: **Registry**](#tab/reg) To configure devices using the registry, use the following settings: @@ -155,7 +155,7 @@ To configure your clients, you can use: [!INCLUDE [tab-intro](../../../includes/configure/tab-intro.md)] -#### [:::image type="icon" source="../images/icons/intune.svg" border="false"::: **Intune/MDM**](#tab/intune) +#### [:::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)] @@ -171,7 +171,7 @@ Alternatively, you can configure devices using a [custom policy][INT-3] with the |--| |- **OMA-URI:** `./Device/Vendor/MSFT/Policy/Config/ADMX_CredSsp/RestrictedRemoteAdministration`
      - **Data type:** string
      - **Value:** ``

      Possible values for `RestrictedRemoteAdministrationDrop` are:
      - `0`: Disabled
      - `1`: Require Restricted Admin
      - `2`: Require Remote Credential Guard
      - `3`: Restrict credential delegation | -#### [:::image type="icon" source="../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +#### [:::image type="icon" source="../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) [!INCLUDE [gpo-settings-1](../../../includes/configure/gpo-settings-1.md)] @@ -181,7 +181,7 @@ Alternatively, you can configure devices using a [custom policy][INT-3] with the [!INCLUDE [gpo-settings-2](../../../includes/configure/gpo-settings-2.md)] -#### [:::image type="icon" source="../images/icons/windows-os.svg" border="false"::: **Registry**](#tab/reg) +#### [:::image type="icon" source="../images/icons/registry.svg" border="false"::: **Registry**](#tab/reg) Not documented. @@ -224,5 +224,4 @@ Here are some considerations for Remote Credential Guard: [CSP-2]: /windows/client-management/mdm/policy-csp-admx-credssp [INT-3]: /mem/intune/configuration/settings-catalog [LEARN-1]: /windows-server/identity/laps/laps-overview -[TECH-1]: https://social.technet.microsoft.com/wiki/contents/articles/32905.how-to-enable-restricted-admin-mode-for-remote-desktop.aspx [PTH-1]: https://download.microsoft.com/download/7/7/A/77ABC5BD-8320-41AF-863C-6ECFB10CB4B9/Mitigating-Pass-the-Hash-Attacks-and-Other-Credential-Theft-Version-2.pdf diff --git a/windows/security/identity-protection/toc.yml b/windows/security/identity-protection/toc.yml index 26eafa1368..9d0a3a0397 100644 --- a/windows/security/identity-protection/toc.yml +++ b/windows/security/identity-protection/toc.yml @@ -4,7 +4,7 @@ items: - name: Passwordless sign-in items: - name: Passwordless strategy - href: hello-for-business/passwordless-strategy.md + href: passwordless-strategy/toc.yml - name: Windows Hello for Business href: hello-for-business/toc.yml - name: Windows presence sensing @@ -28,8 +28,8 @@ items: href: /education/windows/federated-sign-in - name: Advanced credential protection items: - - name: Windows LAPS (Local Administrator Password Solution) 🔗 - displayName: LAPS + - name: Windows LAPS 🔗 + displayName: Local Administrator Password Solution href: /windows-server/identity/laps/laps-overview - name: Account Lockout Policy 🔗 href: ../threat-protection/security-policy-settings/account-lockout-policy.md diff --git a/windows/security/images/icons/group-policy.svg b/windows/security/images/icons/group-policy.svg index ace95add6b..c9cb511415 100644 --- a/windows/security/images/icons/group-policy.svg +++ b/windows/security/images/icons/group-policy.svg @@ -1,3 +1,9 @@ - - - \ No newline at end of file + + + + + + + + + diff --git a/windows/security/images/icons/registry.svg b/windows/security/images/icons/registry.svg new file mode 100644 index 0000000000..bc4aa2f534 --- /dev/null +++ b/windows/security/images/icons/registry.svg @@ -0,0 +1,9 @@ + + + + + + + + + diff --git a/windows/security/images/insider.png b/windows/security/images/insider.png index dbe00408cb..dc227a95bd 100644 Binary files a/windows/security/images/insider.png and b/windows/security/images/insider.png differ diff --git a/windows/security/operating-system-security/data-protection/bitlocker/images/network-unlock-diagram.png b/windows/security/operating-system-security/data-protection/bitlocker/images/network-unlock-diagram.png deleted file mode 100644 index f158bc4c67..0000000000 Binary files a/windows/security/operating-system-security/data-protection/bitlocker/images/network-unlock-diagram.png and /dev/null differ diff --git a/windows/security/operating-system-security/data-protection/bitlocker/images/network-unlock-diagram.svg b/windows/security/operating-system-security/data-protection/bitlocker/images/network-unlock-diagram.svg new file mode 100644 index 0000000000..27acdfd665 --- /dev/null +++ b/windows/security/operating-system-security/data-protection/bitlocker/images/network-unlock-diagram.svg @@ -0,0 +1 @@ +WDSDHCPClientWDSDHCPClient1. Network unlock detected2. DHCP reqDHCP offer3. DHCP + Network key 🔑4. Request5. Decryption 🔓7. Intermediate key 🔑7. 🔑+🗝️8. Volume unlock 🔓9. Windows boot \ No newline at end of file diff --git a/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md b/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md index f81e6c585f..f0745f7122 100644 --- a/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md +++ b/windows/security/operating-system-security/data-protection/bitlocker/network-unlock.md @@ -46,7 +46,7 @@ The server side configuration to enable Network Unlock also requires provisionin The Network Unlock process follows these phases: :::row::: - :::column span="3"::: + :::column span="2"::: 1. The Windows boot manager detects a Network Unlock protector in the BitLocker configuration 2. The client computer uses its DHCP driver in the UEFI to get a valid IPv4 IP address 3. The client computer broadcasts a vendor-specific DHCP request that contains a network key (a 256-bit intermediate key) and an AES-256 session key for the reply. The network key is encrypted by using the 2048-bit RSA Public Key of the Network Unlock certificate from the WDS server @@ -57,8 +57,8 @@ The Network Unlock process follows these phases: 8. This combined key is used to create an AES-256 key that unlocks the volume 9. Windows continues the boot sequence :::column-end::: - :::column span="1"::: - :::image type="content" source="images/network-unlock-diagram.png" alt-text="Diagram of the Network Unlock sequence." lightbox="images/network-unlock-diagram.png" border="false"::: + :::column span="2"::: + :::image type="content" source="images/network-unlock-diagram.svg" alt-text="Diagram of the Network Unlock sequence." lightbox="images/network-unlock-diagram.svg" border="false"::: :::column-end::: :::row-end::: diff --git a/windows/security/operating-system-security/network-security/windows-firewall/configure-logging.md b/windows/security/operating-system-security/network-security/windows-firewall/configure-logging.md index 06fbba84f9..bce157495f 100644 --- a/windows/security/operating-system-security/network-security/windows-firewall/configure-logging.md +++ b/windows/security/operating-system-security/network-security/windows-firewall/configure-logging.md @@ -47,7 +47,7 @@ Alternatively, you can configure devices using a [custom policy][INT-1] with the | *Public* | Setting name: [EnableLogSuccessConnections][CSP-10]
      OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/EnableLogSuccessConnections` | | *Public* | Setting name: [LogMaxFileSize][CSP-13]
      OMA-URI: `./Vendor/MSFT/Firewall/MdmStore/PublicProfile/LogMaxFileSize` | -# [:::image type="icon" source="../../../images/icons/group-policy.svg" border="false"::: **Group policy**](#tab/gpo) +# [:::image type="icon" source="../../../images/icons/group-policy.svg" border="false"::: **GPO**](#tab/gpo) [!INCLUDE [gpo-settings-1](../../../../../includes/configure/gpo-settings-1.md)] diff --git a/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/images/icons/group-policy.svg b/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/images/icons/group-policy.svg index ace95add6b..95957a5914 100644 --- a/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/images/icons/group-policy.svg +++ b/windows/security/operating-system-security/virus-and-threat-protection/microsoft-defender-smartscreen/images/icons/group-policy.svg @@ -1,3 +1,9 @@ - - - \ No newline at end of file + + + + + + + + + diff --git a/windows/whats-new/deprecated-features.md b/windows/whats-new/deprecated-features.md index bdf7f70696..41186b15a7 100644 --- a/windows/whats-new/deprecated-features.md +++ b/windows/whats-new/deprecated-features.md @@ -81,7 +81,6 @@ The features in this article are no longer being actively developed, and might b | XDDM-based remote display driver | The Remote Desktop Services uses a Windows Display Driver Model (WDDM) based Indirect Display Driver (IDD) for a single session remote desktop. The support for Windows 2000 Display Driver Model (XDDM) based remote display drivers will be removed in a future release. Independent Software Vendors that use an XDDM-based remote display driver should plan a migration to the WDDM driver model. For more information on implementing remote display indirect display driver, check out [Updates for IddCx versions 1.4 and later](/windows-hardware/drivers/display/iddcx1.4-updates). | 1903 | | Taskbar settings roaming | Roaming of taskbar settings is no longer being developed and we plan to remove this capability in a future release. | 1903 | | Wi-Fi WEP and TKIP | Since the 1903 release, a warning message has appeared when connecting to Wi-Fi networks secured with WEP or TKIP (which aren't as secure as those using WPA2 or WPA3). In a future release, any connection to a Wi-Fi network using these old ciphers will be disallowed. Wi-Fi routers should be updated to use AES ciphers, available with WPA2 or WPA3. | 1903 | -| Windows To Go | Windows To Go is no longer being developed.

      The feature doesn't support feature updates and therefore doesn't enable you to stay current. It also requires a specific type of USB that is no longer supported by many OEMs.| 1903 | | Print 3D app | 3D Builder is the recommended 3D printing app. To 3D print objects on new Windows devices, customers must first install 3D Builder from the Store.| 1903 | |Companion device dynamic lock APIS|The companion device framework (CDF) APIs enable wearables and other devices to unlock a PC. In Windows 10, version 1709, we introduced [Dynamic Lock](/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock), including an inbox method using Bluetooth to detect whether a user is present and lock or unlock the PC. Because of this reason, and because non-Microsoft partners didn't adopt the CDF method, we're no longer developing CDF Dynamic Lock APIs.| 1809 | |OneSync service|The OneSync service synchronizes data for the Mail, Calendar, and People apps. We've added a sync engine to the Outlook app that provides the same synchronization.| 1809 | diff --git a/windows/whats-new/removed-features.md b/windows/whats-new/removed-features.md index d837c8fa8c..311b404b89 100644 --- a/windows/whats-new/removed-features.md +++ b/windows/whats-new/removed-features.md @@ -8,7 +8,7 @@ ms.author: mstewart manager: aaroncz ms.topic: conceptual ms.technology: itpro-fundamentals -ms.date: 01/05/2023 +ms.date: 01/30/2024 ms.collection: - highpri - tier1 @@ -39,31 +39,31 @@ The following features and functionalities have been removed from the installed |Feature | Details and mitigation | Support removed | | ----------- | --------------------- | ------ | | Update Compliance | Update Compliance, a cloud-based service for the Windows client, is retired. This service has been replaced with [Windows Update for Business reports](/windows/deployment/update/wufb-reports-overview), which provides reporting on client compliance with Microsoft updates from the Azure portal. | March 31, 2023 | -| Store uploader tool | Support has been removed for the store uploader tool. This tool is included in the Windows SDK only. The endpoint for the tool has been removed from service and the files will be removed from the SDK in the next release. | November, 2022 | +| Store uploader tool | Support has been removed for the store uploader tool. This tool is included in the Windows SDK only. The endpoint for the tool has been removed from service and the files will be removed from the SDK in the next release. | November 2022 | | Internet Explorer 11 | The Internet Explorer 11 desktop application is [retired and out of support](https://aka.ms/IEJune15Blog) as of June 15, 2022 for certain versions of Windows 10. You can still access older, legacy sites that require Internet Explorer with Internet Explorer mode in Microsoft Edge. [Learn how](https://aka.ms/IEmodewebsite). The Internet Explorer 11 desktop application will progressively redirect to the faster, more secure Microsoft Edge browser, and will ultimately be disabled via Windows Update. [Disable IE today](/deployedge/edge-ie-disable-ie11). | June 15, 2022 | -| XDDM-based remote display driver | Support for Windows 2000 Display Driver Model (XDDM) based remote display drivers is removed in this release. Independent Software Vendors that use an XDDM-based remote display driver should plan a migration to the WDDM driver model. For more information on implementing remote display indirect display driver, see [Updates for IddCx versions 1.4 and later](/windows-hardware/drivers/display/iddcx1.4-updates). | 21H1 | +| XDDM-based remote display driver | Support for Windows 2000 Display Driver Model (XDDM) based remote display drivers is removed in this release. Software publishers that use an XDDM-based remote display driver should plan a migration to the WDDM driver model. For more information on implementing remote display indirect display driver, see [Updates for IddCx versions 1.4 and later](/windows-hardware/drivers/display/iddcx1.4-updates). | 21H1 | |Microsoft Edge|The legacy version of Microsoft Edge is no longer supported after March 9, 2021. For more information, see [End of support reminder for Microsoft Edge Legacy](/lifecycle/announcements/edge-legacy-eos-details). | 21H1 | |MBAE service metadata|The MBAE app experience is replaced by an MO UWP app. Metadata for the MBAE service is removed. | 20H2 | | Connect app | The **Connect** app for wireless projection using Miracast is no longer installed by default, but is available as an optional feature. To install the app, select **Settings** > **Apps** > **Optional features** > **Add a feature**, and then install the **Wireless Display** app. | 2004 | | Rinna and Japanese Address suggestion | The Rinna and Japanese Address suggestion service for Microsoft Japanese Input Method Editor (IME) ended on August 13, 2020. For more information, see [Rinna and Japanese Address suggestion will no longer be offered](https://support.microsoft.com/help/4576767/windows-10-rinna-and-japanese-address-suggestion) | 2004 | | Cortana | Cortana has been updated and enhanced in the Windows 10 May 2020 Update. With [these changes](/windows/whats-new/whats-new-windows-10-version-2004#cortana), some previously available consumer skills such as music, connected home, and other non-Microsoft skills are no longer available. | 2004 | | Windows To Go | Windows To Go was announced as deprecated in Windows 10, version 1903 and is removed in this release. | 2004 | -| Mobile Plans and Messaging apps | Both apps are still supported, but are now distributed in a different way. OEMs can now include these apps in Windows images for cellular enabled devices. The apps are removed for non-cellular devices.| 2004 | -| PNRP APIs| ​The Peer Name Resolution Protocol (PNRP) cloud service was removed in Windows 10, version 1809. We're planning to complete the removal process by removing the corresponding APIs. | 1909 | +| Mobile Plans and Messaging apps | Both apps are still supported, but are now distributed in a different way. OEMs can now include these apps in Windows images for cellular enabled devices. The apps are removed for noncellular devices.| 2004 | +| PNRP APIs| The Peer Name Resolution Protocol (PNRP) cloud service was removed in Windows 10, version 1809. We're planning to complete the removal process by removing the corresponding APIs. | 1909 | | Taskbar settings roaming | Roaming of taskbar settings is removed in this release. This feature was announced as no longer being developed in Windows 10, version 1903. | 1909 | | Desktop messaging app doesn't offer messages sync | The messaging app on Desktop has a sync feature that can be used to sync SMS text messages received from Windows Mobile and keep a copy of them on the Desktop. The sync feature has been removed from all devices. Due to this change, you'll only be able to access messages from the device that received the message. | 1903 | -|Business Scanning, also called Distributed Scan Management (DSM)|We're removing this secure scanning and scanner management capability - there are no devices that support this feature.| 1809 | +|Business Scanning also called Distributed Scan Management (DSM)|We're removing this secure scanning and scanner management capability - there are no devices that support this feature.| 1809 | |[FontSmoothing setting](/windows-hardware/customize/desktop/unattend/microsoft-windows-shell-setup-visualeffects-fontsmoothing) in unattend.xml|The FontSmoothing setting lets you specify the font antialiasing strategy to use across the system. We've changed Windows 10 to use [ClearType](/typography/cleartype/) by default, so we're removing this setting as it is no longer necessary. If you include this setting in the unattend.xml file, it will be ignored.| 1809 | |Hologram app|We've replaced the Hologram app with the [Mixed Reality Viewer](https://support.microsoft.com/help/4041156/windows-10-mixed-reality-help). If you would like to create 3D word art, you can still do that in Paint 3D and view your art in VR or HoloLens with the Mixed Reality Viewer.| 1809 | |limpet.exe|We're releasing the limpet.exe tool, used to access TPM for Azure connectivity, as open source.| 1809 | |Phone Companion|When you update to Windows 10, version 1809, the Phone Companion app will be removed from your PC. Use the **Phone** page in the Settings app to sync your mobile phone with your PC. It includes all the Phone Companion features.| 1809 | -|Future updates through [Windows Embedded Developer Update](/previous-versions/windows/embedded/ff770079(v=winembedded.60)) for Windows Embedded Standard 7-SP1 (WES7-SP1) and Windows Embedded Standard 8 (WES8)|We're no longer publishing new updates to the WEDU server. Instead, you may secure any new updates from the [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/Home.aspx). [Learn how](https://techcommunity.microsoft.com/t5/Windows-Embedded/Change-to-the-Windows-Embedded-Developer-Update/ba-p/285704) to get updates from the catalog.| 1809 | +|Future updates through [Windows Embedded Developer Update](/previous-versions/windows/embedded/ff770079(v=winembedded.60)) for Windows Embedded Standard 7-SP1 (WES7-SP1) and Windows Embedded Standard 8 (WES8)|We're no longer publishing new updates to the WEDU server. Instead, download any new updates from the [Microsoft Update Catalog](https://www.catalog.update.microsoft.com/Home.aspx). [Learn how](https://techcommunity.microsoft.com/t5/Windows-Embedded/Change-to-the-Windows-Embedded-Developer-Update/ba-p/285704) to get updates from the catalog.| 1809 | |Groove Music Pass|[We ended the Groove streaming music service and music track sales through the Microsoft Store in 2017](https://support.microsoft.com/help/4046109/groove-music-and-spotify-faq). The Groove app is being updated to reflect this change. You can still use Groove Music to play the music on your PC. You can use Spotify or other music services to stream music on Windows 10, or to buy music to own.| 1803 | |People - Suggestions will no longer include unsaved contacts for non-Microsoft accounts|Manually save the contact details for people you send mail to or get mail from.| 1803 | |Language control in the Control Panel| Use the Settings app to change your language settings.| 1803 | |HomeGroup|We're removing [HomeGroup](https://support.microsoft.com/help/17145) but not your ability to share printers, files, and folders.

      When you update to Windows 10, version 1803, you won't see HomeGroup in File Explorer, the Control Panel, or Troubleshoot (**Settings > Update & Security > Troubleshoot**). Any printers, files, and folders that you shared using HomeGroup **will continue to be shared**.

      Instead of using HomeGroup, you can now share printers, files and folders by using features that are built into Windows 10:
      - [Share your network printer](https://www.bing.com/search?q=share+printer+windows+10)
      - [Share files in File Explorer](https://support.microsoft.com/help/4027674/windows-10-share-files-in-file-explorer) | 1803 | |**Connect to suggested open hotspots** option in Wi-Fi settings |We previously [disabled the **Connect to suggested open hotspots** option](https://privacy.microsoft.com/windows-10-open-wi-fi-hotspots) and are now removing it from the Wi-Fi settings page. You can manually connect to free wireless hotspots with **Network & Internet** settings, from the taskbar or Control Panel, or by using Wi-Fi Settings (for mobile devices).| 1803 | -|XPS Viewer|We're changing the way you get XPS Viewer. In Windows 10, version 1709 and earlier versions, the app is included in the installation image. If you have XPS Viewer and you update to Windows 10, version 1803, there's no action required. You'll still have XPS Viewer.

      However, if you install Windows 10, version 1803, on a new device (or as a clean installation), you may need to [install XPS Viewer from **Apps and Features** in the Settings app](/windows/application-management/add-apps-and-features) or through [Features on Demand](/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities). If you had XPS Viewer in Windows 10, version 1709, but manually removed it before updating, you'll need to manually reinstall it.| 1803 | +|XPS Viewer|We're changing the way you get XPS Viewer. In Windows 10, version 1709 and earlier versions, the app is included in the installation image. If you have XPS Viewer and you update to Windows 10, version 1803, there's no action required. You'll still have XPS Viewer.

      However, if you install Windows 10, version 1803, on a new device (or as a clean installation), you can [install XPS Viewer from **Apps and Features** in the Settings app](/windows/application-management/add-apps-and-features) or through [Features on Demand](/windows-hardware/manufacture/desktop/features-on-demand-v2--capabilities). If you had XPS Viewer in Windows 10, version 1709, but manually removed it before updating, you'll need to manually reinstall it.| 1803 | |3D Builder app | No longer installed by default. Consider using Print 3D and Paint 3D in its place. However, 3D Builder is still available for download from the Windows Store.| 1709 | |Apndatabase.xml | For more information about the replacement database, see the following Hardware Dev Center articles:
      [MO Process to update COSA](/windows-hardware/drivers/mobilebroadband/planning-your-apn-database-submission)
      [COSA FAQ](/windows-hardware/drivers/mobilebroadband/cosa---faq) | 1709 | |Enhanced Mitigation Experience Toolkit (EMET) |Use of this feature will be blocked. Consider using [Exploit Protection](https://blogs.windows.com/windowsexperience/2017/06/28/) as a replacement. | 1709 |