From 557eeb305fa38f1297593ac2ba81679a8222a689 Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Thu, 25 Oct 2018 16:15:55 -0700 Subject: [PATCH 1/3] edits --- .../account-lockout-threshold.md | 14 ++++++++------ .../reset-account-lockout-counter-after.md | 4 ++-- 2 files changed, 10 insertions(+), 8 deletions(-) diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md index 1023c1e03f..f881b9fedb 100644 --- a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md +++ b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md @@ -8,7 +8,7 @@ ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium author: brianlic-msft -ms.date: 04/19/2017 +ms.date: 10/25/2018 --- # Account lockout threshold @@ -22,22 +22,22 @@ Describes the best practices, location, values, and security considerations for The **Account lockout threshold** policy setting determines the number of failed sign-in attempts that will cause a user account to be locked. A locked account cannot be used until you reset it or until the number of minutes specified by the [Account lockout duration](account-lockout-duration.md) policy setting expires. You can set a value from 1 through 999 failed sign-in attempts, or you can specify that the account will never be locked by setting the value to 0. If **Account lockout threshold** is set to a number greater than zero, **Account lockout duration** must be greater than or equal to the value of [Reset account lockout counter after](reset-account-lockout-counter-after.md). -Failed password attempts on workstations or member servers that have been locked by using CTRL+ALT+DELETE or password-protected screen savers do not count as failed sign-in attempts unless [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) is set to **Enabled**. If Interactive logon: Require Domain Controller authentication to unlock workstation is enabled, repeated failed password attempts to unlock the workstation will count against the account lockout threshold. - Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed sign-ins that can be performed nearly eliminates the effectiveness of such attacks. However, it is important to note that a denial-of-service (DoS) attack could be performed on a domain that has an account lockout threshold configured. A malicious user could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the value of **Account lockout threshold**, the attacker could potentially lock every account. +Failed attempts to unlock a workstation can cause account lockout even if the [Interactive logon: Require Domain Controller authentication to unlock workstation](interactive-logon-require-domain-controller-authentication-to-unlock-workstation.md) security option is disabled. Windows doesn’t need to contact a domain controller for an unlock if you enter the same password that you logged on with, but if you enter a different password, Windows has to contact a domain controller in case you had changed your password from another machine. + ### Possible values It is possible to configure the following values for the **Account lockout threshold** policy setting: - A user-defined number from 0 through 999 - Not defined -Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their identified threats and the risks that they are trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this topic +Because vulnerabilities can exist when this value is configured and when it is not, organizations should weigh their identified threats and the risks that they are trying to mitigate. For information these settings, see [Countermeasure](#bkmk-countermeasure) in this topic. ### Best practices -The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, a setting above 4 and below 10 could be an acceptable starting point for your organization. +The threshold that you select is a balance between operational efficiency and security, and it depends on your organization's risk level. To allow for user error and to thwart brute force attacks, a value of 10 could be an acceptable starting point for your organization. > **Important:**  Implementation of this policy setting is dependent on your operational environment; threat vectors, deployed operating systems, and deployed apps. For more information, see [Implementation considerations](#bkmk-impleconsiderations) in this topic.   ### Location @@ -72,6 +72,8 @@ Implementation of this policy setting is dependent on your operational environme - When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases. - Not all apps that are used in your environment effectively manage how many times a user can attempt to sign-in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold. +For more information about Windows security baseline recommendatiosn for account lockout, see [Configuring Account Lockout](https://blogs.technet.microsoft.com/secguide/2014/08/13/configuring-account-lockout/). + ## Security considerations This section describes how an attacker might exploit a feature or its configuration, how to implement the countermeasure, and the possible negative consequences of countermeasure implementation. @@ -91,7 +93,7 @@ Because vulnerabilities can exist when this value is configured and when it is n - A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment. - Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account. - A good recommendation for such a configuration is 50 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed sign-in attempts. + Windows security baselines recommend configuring a threshold of 10 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems. ### Potential impact diff --git a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md index e735885b8d..d836f95a6e 100644 --- a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md +++ b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md @@ -8,7 +8,7 @@ ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium author: brianlic-msft -ms.date: 04/19/2017 +ms.date: 10/25/2018 --- # Reset account lockout counter after @@ -60,7 +60,7 @@ Users can accidentally lock themselves out of their accounts if they mistype the ### Countermeasure -Configure the **Reset account lockout counter after** policy setting to 30. +Configure the **Reset account lockout counter after** policy setting to 15. ### Potential impact From af48945a657a89daa2edc7b77ff680211a61911c Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Thu, 25 Oct 2018 16:37:43 -0700 Subject: [PATCH 2/3] eits --- .../security-policy-settings/account-lockout-threshold.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md index f881b9fedb..8375b9b36f 100644 --- a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md +++ b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md @@ -72,7 +72,7 @@ Implementation of this policy setting is dependent on your operational environme - When negotiating encryption types between clients, servers, and domain controllers, the Kerberos protocol can automatically retry account sign-in attempts that count toward the threshold limits that you set in this policy setting. In environments where different versions of the operating system are deployed, encryption type negotiation increases. - Not all apps that are used in your environment effectively manage how many times a user can attempt to sign-in. For instance, if a connection drops repeatedly when a user is running the app, all subsequent failed sign-in attempts count toward the account lockout threshold. -For more information about Windows security baseline recommendatiosn for account lockout, see [Configuring Account Lockout](https://blogs.technet.microsoft.com/secguide/2014/08/13/configuring-account-lockout/). +For more information about Windows security baseline recommendations for account lockout, see [Configuring Account Lockout](https://blogs.technet.microsoft.com/secguide/2014/08/13/configuring-account-lockout/). ## Security considerations From 0be53eeed6b01dbfa839aef5eddda0b8bf2080af Mon Sep 17 00:00:00 2001 From: Justin Hall Date: Fri, 26 Oct 2018 13:49:58 -0700 Subject: [PATCH 3/3] edits --- .../security-policy-settings/account-lockout-threshold.md | 4 ++-- .../reset-account-lockout-counter-after.md | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md index 8375b9b36f..681ff23ad9 100644 --- a/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md +++ b/windows/security/threat-protection/security-policy-settings/account-lockout-threshold.md @@ -8,7 +8,7 @@ ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium author: brianlic-msft -ms.date: 10/25/2018 +ms.date: 10/26/2018 --- # Account lockout threshold @@ -93,7 +93,7 @@ Because vulnerabilities can exist when this value is configured and when it is n - A robust audit mechanism is in place to alert administrators when a series of failed sign-ins occur in the environment. - Configure the **Account lockout threshold** policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account. - Windows security baselines recommend configuring a threshold of 10 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. + [Windows security baselines](https://docs.microsoft.com/windows/security/threat-protection/windows-security-baselines) recommend configuring a threshold of 10 invalid sign-in attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack. Using this type of policy must be accompanied by a process to unlock locked accounts. It must be possible to implement this policy whenever it is needed to help mitigate massive lockouts caused by an attack on your systems. ### Potential impact diff --git a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md index d836f95a6e..8af58b7acd 100644 --- a/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md +++ b/windows/security/threat-protection/security-policy-settings/reset-account-lockout-counter-after.md @@ -8,7 +8,7 @@ ms.sitesec: library ms.pagetype: security ms.localizationpriority: medium author: brianlic-msft -ms.date: 10/25/2018 +ms.date: 10/26/2018 --- # Reset account lockout counter after @@ -60,7 +60,7 @@ Users can accidentally lock themselves out of their accounts if they mistype the ### Countermeasure -Configure the **Reset account lockout counter after** policy setting to 15. +[Windows security baselines](https://docs.microsoft.com/windows/security/threat-protection/windows-security-baselines) recommend configuring the **Reset account lockout counter after** policy setting to 15. ### Potential impact