From 509670a105a74049b570281127aab9e21e7b50e4 Mon Sep 17 00:00:00 2001 From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com> Date: Fri, 10 Mar 2023 10:49:28 -0500 Subject: [PATCH 1/3] updates to WHFB articles --- .../hello-adequate-domain-controllers.md | 26 +++++++------- .../hello-feature-dynamic-lock.md | 36 ++++++++----------- .../hello-feature-pin-reset.md | 15 +++----- 3 files changed, 33 insertions(+), 44 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md index 32dc3ba63e..7a9614f71c 100644 --- a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md +++ b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md @@ -1,23 +1,23 @@ --- title: Having enough Domain Controllers for Windows Hello for Business deployments -description: Guide for planning to have an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments -ms.date: 08/20/2018 +description: Guide for planning to have an adequate number of Domain Controllers for Windows Hello for Business deployments +ms.date: 03/10/2023 appliesto: - ✅ Windows 10 and later - ✅ Windows Server 2016 and later -ms.topic: article +ms.topic: conceptual --- -# Planning an adequate number of Windows Server 2016 or later Domain Controllers for Windows Hello for Business deployments +# Plan an adequate number of Domain Controllers for Windows Hello for Business deployments > [!NOTE] ->There was an issue with key trust authentication on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/en-us/help/4487044/windows-10-update-kb4487044). +>There was an issue with key trust authentication on Windows Server 2019. To fix it, refer to [KB4487044](https://support.microsoft.com/help/4487044/windows-10-update-kb4487044). ## How many is adequate How can you find out how many domain controllers are needed? You can use performance monitoring on your domain controllers to determine existing authentication traffic. Windows Server 2016 and above includes the KDC AS Requests performance counter. You can use this counter to determine how much of a domain controller's load is due to initial Kerberos authentication. It's important to remember that authentication for a Windows Hello for Business key trust deployment does not affect Kerberos authentication - it remains unchanged. Windows 10 or Windows 11 accomplishes Windows Hello for Business key trust authentication by mapping an Active Directory user account to one or more public keys. This mapping occurs on the domain controller, which is why the deployment needs Windows Server 2016 or later domain controllers. Public key mapping is only supported by Windows Server 2016 domain controllers and above. Therefore, users in a key trust deployment must authenticate to a Windows Server 2016 and above domain controller. - + Determining an adequate number of Windows Server domain controllers is important to ensure you have enough domain controllers to satisfy all authentication requests, including users mapped with public key trust. What many administrators do not realize is that adding a domain controller that supports public key mapping (in this case Windows Server 2016 or later) to a deployment of existing domain controllers which do not support public key mapping (Windows Server 2008R2, Windows Server 2012R2) instantly makes that single domain controller susceptible to carrying the most load, or what is commonly referred to as "piling on". To illustrate the "piling on" concept, consider the following scenario: Consider a controlled environment where there are 1000 client computers and the authentication load of these 1000 client computers is evenly distributed across 10 domain controllers in the environment. The Kerberos AS requests load would look something like the following: @@ -55,7 +55,7 @@ The preceding was an example to show why it's unrealistic to have a "one-size-fi ## Determining total AS Request load Each organization needs to have a baseline of the AS request load that occurs in their environment. Windows Server provides the KDC AS Requests performance counter that helps you determine this. - + Pick a site where you plan to upgrade the clients to Windows Hello for Business public key trust. Pick a time when authentication traffic is most significant--Monday morning is great time as everyone is returning to the office. Enable the performance counter on *all* the domain controllers in that site. Collect KDC AS Requests performance counters for two hours: - A half-hour before you expect initial authentication (sign-ins and unlocks) to be significant @@ -72,15 +72,15 @@ Aggregate the performance data of all domain controllers. Look for the maximum K Add the number of authentications for each domain controller for the median time. You now have the total authentication for the site during a peak time. Using this metric, you can determine the distribution of authentication across the domain controllers in the site by dividing the domain controller's authentication number for the median time by the total authentication. Multiply the quotient by 10 to convert the distribution to a percentage. To validate your math, all the distributions should equal 100 percent. Review the distribution of authentication. Hopefully, none of these are above 70 percent. It's always good to reserve some capacity for the unexpected. Also, the primary purposes of a domain controller are to provide authentication and handle Active Directory operations. Identify domain controllers with lower distributions of authentication as potential candidates for the initial domain controller upgrades in conjunction with a reasonable distribution of clients provisioned for Windows Hello for Business. - + ## Monitoring Authentication Using the same methods described above, monitor the Kerberos authentication after upgrading a domain controller and your first phase of Windows Hello for Business deployments. Make note of the delta of authentication before and after upgrading the domain controller to Windows Server 2016 or newer. This delta is representative of authentication resulting from the first phase of your Windows Hello for Business clients. It gives you a baseline for your environment to where you can form a statement such as: ```"Every n Windows Hello for Business clients results in x percentage of key-trust authentication."``` -Where *n* equals the number of clients you switched to Windows Hello for Business and _x_ equals the increased percentage of authentication from the upgraded domain controller. Armed with this information, you can apply the observations of upgrading domain controllers and increasing Windows Hello for Business client count to appropriately phase your deployment. - +Where *n* equals the number of clients you switched to Windows Hello for Business and *x* equals the increased percentage of authentication from the upgraded domain controller. Armed with this information, you can apply the observations of upgrading domain controllers and increasing Windows Hello for Business client count to appropriately phase your deployment. + Remember, increasing the number of clients changes the volume of authentication distributed across the Windows Server 2016 or newer domain controllers. If there is only one Windows Server 2016 or newer domain controller, there's no distribution and you are simply increasing the volume of authentication for which THAT domain controller is responsible. Increasing the number of domain controllers distributes the volume of authentication, but doesn't change it. Therefore, as you add more domain controllers, the burden of authentication, for which each domain controller is responsible, decreases. Upgrading two domain controller changes the distribution to 50 percent. Upgrading three domain controllers changes the distribution to 33 percent, and so on. @@ -88,9 +88,9 @@ Increasing the number of domain controllers distributes the volume of authentica ## Strategy The simplest strategy you can employ is to upgrade one domain controller and monitor the single domain controller as you continue to phase in new Windows Hello for Business key-trust clients until it reaches a 70 or 80 percent threshold. - + Then, upgrade a second domain controller. Monitor the authentication on both domain controllers to determine how the authentication distributes between the two domain controllers. Introduce more Windows Hello for Business clients while monitoring the authentication on the two upgraded domain controllers. Once those reach your environment's designated capacity, you can upgrade another domain controller. - + Repeat until your deployment for that site is complete. Now, monitor authentication across all your domain controllers like you did the very first time. Determine the distribution of authentication for each domain controller. Identify the percentage of distribution for which it is responsible. If a single domain controller is responsible for 70 percent of more of the authentication, you may want to consider adding a domain controller to reduce the distribution of authentication volume. - + However, before considering this, ensure the high load of authentication is not a result of applications and services where their configuration has a statically-configured domain controller. Adding domain controllers will not resolve the additional authentication load problem in this scenario. Instead, manually distribute the authentication to different domain controllers among all the services or applications. Alternatively, try simply using the domain name rather than a specific domain controller. Each domain controller has an A record registered in DNS for the domain name, which DNS will round robin with each DNS query. It's not the best load balancer, however, it is a better alternative to static domain controller configurations, provided the configuration is compatible with your service or application. diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md b/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md index 9f461f9697..9268eb6f52 100644 --- a/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md +++ b/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md @@ -1,33 +1,38 @@ --- title: Dynamic lock -description: Learn how to set Dynamic lock on Windows 10 and Windows 11 devices, by configuring group policies. This feature locks a device when a Bluetooth signal falls below a set value. -ms.date: 07/12/2022 +description: Learn how to configure dynamic lock on Windows devices via group policies. This feature locks a device when a Bluetooth signal falls below a set value. +ms.date: 03/10/2023 appliesto: - ✅ Windows 10 and later -ms.topic: article +ms.topic: how-to --- # Dynamic lock -Dynamic lock enables you to configure Windows devices to automatically lock when Bluetooth paired device signal falls below the maximum Received Signal Strength Indicator (RSSI) value. This makes it more difficult for someone to gain access to your device if you step away from your PC and forget to lock it. +Dynamic lock is a feature that automatically locks a Windows device when a Bluetooth paired phone signal falls below the maximum Received Signal Strength Indicator (RSSI) value. The feature makes it more difficult for someone to gain access to your device if you step away from your PC and forget to lock it. > [!IMPORTANT] -> This feature only locks the computer if the Bluetooth signal falls and the system is idle. If the system isn't idle (for example, an intruder gets access _before_ the Bluetooth signal falls below the limit), the device won't lock. Therefore, the dynamic lock feature is an additional barrier. It doesn't replace the need for the user to lock the computer. It only reduces the probability of someone gaining access if the user forgets to lock it. +> The dynamic lock feature only locks the device if the Bluetooth signal falls **and** the system is idle. If the system isn't idle (for example, an intruder gets access *before* the Bluetooth signal falls below the limit), the device won't lock. Therefore, the dynamic lock feature is an additional barrier. It doesn't replace the need for the user to lock the computer. It only reduces the probability of someone gaining access if the user forgets to lock it. -You configure the dynamic lock policy using Group Policy. You can locate the policy setting at **Computer Configuration\Administrative Templates\Windows Components\Windows Hello for Business**. The name of the policy is **Configure dynamic lock factors**. +You can configure Windows devices to use the **dynamic lock** using a Group Policy Object (GPO). + +1. Using the Group Policy Management Console (GPMC), scope a domain-based Group Policy to computer accounts in Active Directory. +1. Edit the Group Policy object from Step 1. +1. Enable the **Configure dynamic lock factors** policy setting located under **Computer Configuration > Administrative Templates > Windows Components > Windows Hello for Business**. +1. Close the Group Policy Management Editor to save the Group Policy object. The Group Policy Editor, when the policy is enabled, creates a default signal rule policy with the following value: -``` +```xml - + ``` >[!IMPORTANT] >Microsoft recommends using the default values for this policy settings. Measurements are relative based on the varying conditions of each environment. Therefore, the same values may produce different results. Test policy settings in each environment prior to broadly deploying the setting. -For this policy setting, the **type** and **scenario** attribute values are static and cannot change. The **classofDevice** is configurable but Phone is the only currently supported configuration. The attribute defaults to Phones and uses the values from the following table: +For this policy setting, the **type** and **scenario** attribute values are static and can't change. The **classofDevice** is configurable but Phone is the only currently supported configuration. The attribute defaults to Phone and uses the values from the following table: |Description|Value| |:-------------|:-------:| @@ -43,17 +48,6 @@ For this policy setting, the **type** and **scenario** attribute values are stat |Health|2304| |Uncategorized|7936| -The **rssiMin** attribute value signal indicates the strength needed for the device to be considered "in-range". The default value of **-10** enables a user to move about an average size office or cubicle without triggering Windows to lock the device. The **rssiMaxDelta** has a default value of **-10**, which instruct Windows to lock the device once the signal strength weakens by more than measurement of 10. +The **rssiMin** attribute value signal indicates the strength needed for the device to be considered *in-range*. The default value of **-10** enables a user to move about an average size office or cubicle without triggering Windows to lock the device. The **rssiMaxDelta** has a default value of **-10**, which instruct Windows to lock the device once the signal strength weakens by more than measurement of 10. RSSI measurements are relative and lower as the bluetooth signals between the two paired devices reduces. Therefore a measurement of 0 is stronger than -10, which is stronger than -60, which is an indicator the devices are moving further apart from each other. - -## Related topics - -* [Windows Hello for Business](hello-identity-verification.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-feature-pin-reset.md b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md index 7b1fdf338f..ea7e72e5d4 100644 --- a/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md +++ b/windows/security/identity-protection/hello-for-business/hello-feature-pin-reset.md @@ -4,10 +4,10 @@ description: Learn how Microsoft PIN reset services enable you to help users rec ms.collection: - highpri - tier1 -ms.date: 07/29/2022 +ms.date: 03/10/2023 appliesto: - ✅ Windows 10 and later -ms.topic: article +ms.topic: how-to --- # PIN reset @@ -20,12 +20,10 @@ There are two forms of PIN reset: - **Non-destructive PIN reset**: with this option, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. For non-destructive PIN reset, you must deploy the **Microsoft PIN Reset Service** and configure your clients' policy to enable the **PIN Recovery** feature. ## Using PIN reset - There are two forms of PIN reset called destructive and non-destructive. Destructive PIN reset is the default and doesn't require configuration. During a destructive PIN reset, the user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned. For non-destructive PIN reset, you must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed. Destructive and non-destructive PIN reset use the same steps for initiating a PIN reset. If users have forgotten their PINs, but have an alternate sign-in method, they can navigate to Sign-in options in *Settings* and initiate a PIN reset from the PIN options. If users don't have an alternate way to sign into their devices, PIN reset can also be initiated from the Windows lock screen in the PIN credential provider. - >[!IMPORTANT] >For hybrid Azure AD-joined devices, users must have corporate network connectivity to domain controllers to complete destructive PIN reset. If AD FS is being used for certificate trust or for on-premises only deployments, users must also have corporate network connectivity to federation services to reset their PIN. @@ -35,7 +33,6 @@ Destructive and non-destructive PIN reset use the same steps for initiating a PI 1. Open **Settings**, select **Accounts** > **Sign-in options**. 1. Select **PIN (Windows Hello)** > **I forgot my PIN** and follow the instructions. - ### Reset PIN above the Lock Screen For Azure AD-joined devices: @@ -46,7 +43,6 @@ For Azure AD-joined devices: 1. Follow the instructions provided by the provisioning process. 1. When finished, unlock your desktop using your newly created PIN. - For Hybrid Azure AD-joined devices: 1. If the PIN credential provider isn't selected, expand the **Sign-in options** link, and select the PIN pad icon. @@ -58,14 +54,14 @@ For Hybrid Azure AD-joined devices: > [!NOTE] > Key trust on hybrid Azure AD-joined devices does not support destructive PIN reset from above the Lock Screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. For this deployment model, you must deploy non-destructive PIN reset for above lock PIN reset to work. -You may find that PIN reset from settings only works post login. Also, the "lock screen" PIN reset function won't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations). +You may find that PIN reset from settings only works post login. Also, the lock screen PIN reset function won't work if you have any matching limitation of self-service password reset from the lock screen. For more information, see [Enable Azure Active Directory self-service password reset at the Windows sign-in screen - General ](/azure/active-directory/authentication/howto-sspr-windows#general-limitations). ## Non-Destructive PIN reset **Requirements:** - Azure Active Directory -- Windows 10, version 1709 to 1809, Enterprise Edition. There's no licensing requirement for this feature since version 1903. +- Windows Enterprise and Pro editions. There's no licensing requirement for this feature. - Hybrid Windows Hello for Business deployment - Azure AD registered, Azure AD joined, and Hybrid Azure AD joined @@ -83,7 +79,7 @@ Using Group Policy, Microsoft Intune or a compatible MDM solution, you can confi |Category|Destructive PIN Reset|Non-Destructive PIN Reset| |--- |--- |--- | |**Functionality**|The user's existing PIN and underlying credentials, including any keys or certificates added to their Windows Hello container, will be deleted from the client and a new logon key and PIN are provisioned.|You must deploy the Microsoft PIN reset service and client policy to enable the PIN recovery feature. For more information on how to deploy the Microsoft PIN reset service and client policy, see [Connect Azure Active Directory with the PIN reset service](#connect-azure-active-directory-with-the-pin-reset-service). During a non-destructive PIN reset, the user's Windows Hello for Business container and keys are preserved, but the user's PIN that they use to authorize key usage is changed.| -|**Windows editions and versions**|Reset from settings - Windows 10, version 1703 or later, Windows 11. Reset above Lock - Windows 10, version 1709 or later, Windows 11.|Windows 10, version 1709 to 1809, Enterprise Edition. There isn't any licensing requirement for this feature since version 1903. Enterprise Edition and Pro edition with Windows 10, version 1903 and newer Windows 11.| +|**Windows editions and versions**| Windows Enterprise and Pro editions.| |**Azure Active Directory Joined**|Cert Trust, Key Trust, and cloud Kerberos trust|Cert Trust, Key Trust, and cloud Kerberos trust| |**Hybrid Azure Active Directory Joined**|Cert Trust and cloud Kerberos trust for both settings and above the lock support destructive PIN reset. Key Trust doesn't support this from above the lock screen. This is due to the sync delay between when a user provisions their Windows Hello for Business credential and being able to use it for sign-in. It does support from the settings page and the users must have a corporate network connectivity to the DC. |Cert Trust, Key Trust, and cloud Kerberos trust for both settings and above the lock support non-destructive PIN reset. No network connection is required for the DC.| |**On Premises**|If ADFS is being used for on premises deployments, users must have a corporate network connectivity to federation services. |The PIN reset service relies on Azure Active Directory identities, so it's only available for Hybrid Azure Active Directory Joined and Azure Active Directory Joined devices.| @@ -94,7 +90,6 @@ Using Group Policy, Microsoft Intune or a compatible MDM solution, you can confi > The **Microsoft PIN Reset Service** is not currently available in Azure Government. - ### Enable the Microsoft PIN Reset Service in your Azure AD tenant Before you can remotely reset PINs, you must register two applications in your Azure Active Directory tenant: From d39bf963d04928f2a9df8a9bf720f88da124b9f4 Mon Sep 17 00:00:00 2001 From: Paolo Matarazzo <74918781+paolomatarazzo@users.noreply.github.com> Date: Fri, 10 Mar 2023 10:52:57 -0500 Subject: [PATCH 2/3] udpate --- .../hello-for-business/hello-adequate-domain-controllers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md index 7a9614f71c..6607d17abb 100644 --- a/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md +++ b/windows/security/identity-protection/hello-for-business/hello-adequate-domain-controllers.md @@ -1,6 +1,6 @@ --- -title: Having enough Domain Controllers for Windows Hello for Business deployments -description: Guide for planning to have an adequate number of Domain Controllers for Windows Hello for Business deployments +title: Plan an adequate number of Domain Controllers for Windows Hello for Business deployments +description: Learn how to plan for an adequate number of Domain Controllers to support Windows Hello for Business deployments. ms.date: 03/10/2023 appliesto: - ✅ Windows 10 and later From 3e2d0d266854819e50de4a9ae95fb61dcec9b9ff Mon Sep 17 00:00:00 2001 From: Angela Fleischmann Date: Fri, 10 Mar 2023 14:15:01 -0700 Subject: [PATCH 3/3] Apply suggestions from code review Line 35: Delete extra space. --- .../hello-for-business/hello-feature-dynamic-lock.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md b/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md index 9268eb6f52..5fea59fc25 100644 --- a/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md +++ b/windows/security/identity-protection/hello-for-business/hello-feature-dynamic-lock.md @@ -32,7 +32,7 @@ The Group Policy Editor, when the policy is enabled, creates a default signal ru >[!IMPORTANT] >Microsoft recommends using the default values for this policy settings. Measurements are relative based on the varying conditions of each environment. Therefore, the same values may produce different results. Test policy settings in each environment prior to broadly deploying the setting. -For this policy setting, the **type** and **scenario** attribute values are static and can't change. The **classofDevice** is configurable but Phone is the only currently supported configuration. The attribute defaults to Phone and uses the values from the following table: +For this policy setting, the **type** and **scenario** attribute values are static and can't change. The **classofDevice** is configurable but Phone is the only currently supported configuration. The attribute defaults to Phone and uses the values from the following table: |Description|Value| |:-------------|:-------:|