acrolinx fixes: acrolinx-security-policy

This commit is contained in:
ShannonLeavitt 2020-11-05 16:51:20 -07:00
parent ed6e482a95
commit 185cd9c800
10 changed files with 57 additions and 57 deletions

View File

@ -46,12 +46,12 @@ This setting has these possible values:
For a local logon, the user's full name is displayed.
If the user signed in using a Microsoft account, the user's email address is displayed.
For a domain logon, the domain\username is displayed.
This has the same effect as turning on the **Privacy** setting.
This setting has the same effect as turning on the **Privacy** setting.
- **User display name only**
The full name of the user who locked the session is displayed.
This has the same effect as turning off the **Privacy** setting.
This setting has the same effect as turning off the **Privacy** setting.
- **Do not display user information**
@ -69,7 +69,7 @@ This setting has these possible values:
- **Blank**
Default setting.
This translates to “Not defined,” but it will display the users full name in the same manner as the option **User display name only**.
This setting translates to “Not defined,” but it will display the user's full name in the same manner as the option **User display name only**.
When an option is set, you cannot reset this policy to blank, or not defined.
### Hotfix for Windows 10 version 1607
@ -149,7 +149,7 @@ When a computer displays the Secure Desktop in an unsecured area, certain user i
Enabling this policy setting allows the operating system to hide certain user information from being displayed on the Secure Desktop (after the device has been booted or when the session has been locked by using CTRL+ALT+DEL). However, user information is displayed if the **Switch user** feature is used so that the logon tiles are displayed for each logged on user.
You might also want to enable the [Interactive logon: Do not display last signed-in](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to logon.
You might also want to enable the [Interactive logon: Do not display last signed-in](interactive-logon-do-not-display-last-user-name.md) policy, which will prevent the Windows operating system from displaying the logon name and logon tile of the last user to log on.
## Related topics

View File

@ -43,7 +43,7 @@ A malicious user might install malware that looks like the standard logon dialog
### Best practices
- It is advisable to set **Disable CTRL+ALT+DEL requirement for logon** to **Not configured**.
- We recommend that you set **Disable CTRL+ALT+DEL requirement for logon** to **Not configured**.
### Location

View File

@ -22,7 +22,7 @@ ms.date: 08/27/2018
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting.
Describes the best practices, location, values, policy management, and security considerations for the **Interactive logon: Number of previous logons to cache (in case domain controller is not available)** security policy setting.
## Reference
@ -36,7 +36,7 @@ If a domain controller is unavailable and a user's logon information is not cach
The system cannot log you on now because the domain *DOMAIN NAME* is not available.
The value of this policy setting indicates the number of users whose logon information the server caches locally. If the value is 10, the server caches logon information for 10 users. When an eleventh user logs on to the device, the server overwrites the oldest cached logon session.
The value of this policy setting indicates the number of users whose logon information the server caches locally. If the value is 10, the server caches logon information for 10 users. When an 11th user logs on to the device, the server overwrites the oldest cached logon session.
Users who access the server console will have their logon credentials cached on that server. A malicious user who is able to access the file system of the server can locate this cached information and use a brute-force attack to determine user passwords. Windows mitigates this type of attack by
encrypting the information and keeping the cached credentials in the system's registries, which are spread across numerous physical locations.
@ -89,7 +89,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
The number that is assigned to this policy setting indicates the number of users whose logon information is cache locally by the servers. If the number is set to 10, the server caches logon information for 10 users. When an eleventh user logs on to the device, the server overwrites the oldest cached logon session.
The number that is assigned to this policy setting indicates the number of users whose logon information is cache locally by the servers. If the number is set to 10, the server caches logon information for 10 users. When an 11th user logs on to the device, the server overwrites the oldest cached logon session.
Users who access the server console have their logon credentials cached on that server. An attacker who is able to access the file system of the server could locate this cached information and use a brute force attack to attempt to determine user passwords.

View File

@ -1,6 +1,6 @@
---
title: Interactive logon Require smart card - security policy setting (Windows 10)
description: Describes the best practices, location, values, policy management and security considerations for the Interactive logon Require smart card security policy setting.
description: Describes the best practices, location, values, policy management, and security considerations for the Interactive logon Require smart card security policy setting.
ms.assetid: c6a8c040-cbc7-472d-8bc5-579ddf3cbd6c
ms.reviewer:
ms.author: dansimp
@ -31,7 +31,7 @@ Describes the best practices, location, values, policy management, and security
The **Interactive logon: Require smart card** policy setting requires users to log on to a device by using a smart card.
Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This reduces the chance that a malicious user will be able to guess a user's password through a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it is nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to log on must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's device and the domain controller will find it extremely difficult to decrypt the traffic: even if they do, the next time the user logs on to the network, a new session key will be generated for encrypting traffic between the user and the domain controller.
Requiring users to use long, complex passwords for authentication enhances network security, especially if the users must change their passwords regularly. This requirement reduces the chance that a malicious user will be able to guess a user's password through a brute-force attack. Using smart cards rather than passwords for authentication dramatically increases security because, with today's technology, it is nearly impossible for a malicious user to impersonate another user. Smart cards that require personal identification numbers (PINs) provide two-factor authentication: the user who attempts to log on must possess the smart card and know its PIN. A malicious user who captures the authentication traffic between the user's device and the domain controller will find it difficult to decrypt the traffic: even if they do, the next time the user logs on to the network, a new session key will be generated for encrypting traffic between the user and the domain controller.
### Possible values
@ -41,7 +41,7 @@ Requiring users to use long, complex passwords for authentication enhances netwo
### Best practices
- Set **Interactive logon: Require smart card** to Enabled. All users will have to use smart cards to log on to the network. This means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users.
- Set **Interactive logon: Require smart card** to Enabled. All users will have to use smart cards to log on to the network. This requirement means that the organization must have a reliable public key infrastructure (PKI) in place, and provide smart cards and smart card readers for all users.
### Location
@ -49,7 +49,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policys property page.
The following table lists the actual and effective default values for this policy, by server type or Group Policy Object (GPO). Default values are also listed on the policy's property page.
| Server type or GPO | Default value |
| - | - |
@ -74,7 +74,7 @@ None.
### Group Policy
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through GPOs. If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@ -90,7 +90,7 @@ For users with access to computers that contain sensitive data, issue smart card
### Potential impact
All users of a device with this setting enabled must use smart cards to log on locally. This means that the organization must have a reliable public key infrastructure (PKI) as well as smart cards and smart card readers for these users. These requirements are significant challenges because
All users of a device with this setting enabled must use smart cards to log on locally. So the organization must have a reliable public key infrastructure (PKI) as well as smart cards and smart card readers for these users. These requirements are significant challenges because
expertise and resources are required to plan for and deploy these technologies. Active Directory Certificate Services (AD CS) can be used to implement and manage certificates. You can use automatic user and device enrollment and renewal on the client.
## Related topics

View File

@ -1,6 +1,6 @@
---
title: Interactive logon Smart card removal behavior (Windows 10)
description: Best practices, location, values, policy management and security considerations for the security policy setting, Interactive logon Smart card removal behavior.
description: Best practices, location, values, policy management, and security considerations for the security policy setting, Interactive logon Smart card removal behavior.
ms.assetid: 61487820-9d49-4979-b15d-c7e735999460
ms.reviewer:
ms.author: dansimp
@ -22,13 +22,13 @@ ms.date: 04/19/2017
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.
Describes the recommended practices, location, values, policy management, and security considerations for the **Interactive logon: Smart card removal behavior** security policy setting.
## Reference
This policy setting determines what happens when the smart card for a logged-on user is removed from the smart card reader.
If smart cards are used for authentication, the device should automatically lock itself when the card is removed—that way, if users forget to manually lock their devices when they are away from them, malicious users cannot gain access.
If smart cards are used for authentication, the device should automatically lock itself when the card is removed. So if users forget to manually lock their devices when they leave, malicious users cannot gain access.
If you select **Force Logoff** in the property sheet for this policy setting, the user is automatically logged off when the smart card is removed. Users will have to reinsert their smart cards and reenter their PINs when they return to their workstations.
@ -40,21 +40,21 @@ If you select **Force Logoff** in the property sheet for this policy setting, th
- No Action
- Lock Workstation
If you select this, the workstation is locked when the smart card is removed, allowing users to leave the area, take their smart card with them, and still maintain a protected session.
If you use this setting, the workstation is locked when the smart card is removed. So users can leave the area, take their smart card with them, and still maintain a protected session.
- Force Logoff
If you select this, the user is automatically logged off when the smart card is removed.
If you use this setting, the user is automatically logged off when the smart card is removed.
- Disconnect if a remote Remote Desktop Services session
If you select this, removal of the smart card disconnects the session without logging the user off. This allows the user to insert the smart card and resume the session later, or at another smart card reader-equipped computer, without having to log on again. If the session is local, this policy functions identically to Lock Workstation.
If you use this setting, removal of the smart card disconnects the session without logging off the user. So the user can insert the smart card and resume the session later, or at another smart card reader-equipped computer, without having to log on again. If the session is local, this policy functions identically to Lock Workstation.
- Not Defined
### Best practices
- Set **Interactive logon: Smart card removal behavior** to **Lock Workstation**. If you select **Lock Workstation** in the property sheet for this policy setting, the workstation is locked when the smart card is removed. This allows users to leave the area, take their smart card with them, and still maintain a protected session.
- Set **Interactive logon: Smart card removal behavior** to **Lock Workstation**. If you select **Lock Workstation** in the property sheet for this policy setting, the workstation is locked when the smart card is removed. So users can leave the area, take their smart card with them, and still maintain a protected session.
### Location
@ -62,7 +62,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Sec
### Default values
The following table lists the actual and effective default values for this policy. Default values are also listed on the policys property page.
The following table lists the actual and effective default values for this policy, by server type or Group Policy Object (GPO). Default values are also listed on the policy's property page.
| Server type or GPO | Default value |
| - | - |
@ -79,7 +79,7 @@ This section describes features and tools that are available to help you manage
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
### Policy conflict considerations
@ -87,7 +87,7 @@ None
### Group Policy
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through Group Policy Objects (GPOs). If this policy is not contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
This policy setting can be configured by using the Group Policy Management Console (GPMC) to be distributed through GPOs. If this policy isn't contained in a distributed GPO, this policy can be configured on the local computer by using the Local Security Policy snap-in.
## Security considerations
@ -95,7 +95,7 @@ This section describes how an attacker might exploit a feature or its configurat
### Vulnerability
Users sometimes forget to lock their workstations when they are away from them, allowing the possibility for malicious users to access their devices. If smart cards are used for authentication, the device should automatically lock itself when the card is removed to ensure that only the user with the smart card is accessing resources by using those credentials.
Users sometimes forget to lock their workstations when they're away from them, allowing the possibility for malicious users to access their devices. If smart cards are used for authentication, the device should automatically lock itself when the card is removed to ensure that only the user with the smart card is accessing resources by using those credentials.
### Countermeasure

View File

@ -22,7 +22,7 @@ ms.date: 04/19/2017
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Log on as a batch job** security policy setting.
This article describes the recommended practices, location, values, policy management, and security considerations for the **Log on as a batch job** security policy setting.
## Reference
@ -48,7 +48,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
By default, this setting is for Administrators, Backup Operators, and Performance Log Users on domain controllers and on stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policys property page.
The following table lists the actual and effective default policy values. Default values are also listed on the policy's property page.
| Server type or GPO | Default value |
| - | - |
@ -63,13 +63,13 @@ The following table lists the actual and effective default policy values. Defaul
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
A restart of the computer isn't required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
### Group Policy
Task Scheduler automatically grants this right when a user schedules a task. To override this behavior use the [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) User Rights Assignment setting.
Task Scheduler automatically grants this right when a user schedules a task. To override this behavior, use the [Deny log on as a batch job](deny-log-on-as-a-batch-job.md) User Rights Assignment setting.
Group Policy settings are applied in the following order, which will overwrite settings on the local computer at the next Group Policy update:
@ -80,7 +80,7 @@ Group Policy settings are applied in the following order, which will overwrite s
## 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.
This section describes how an attacker might exploit a feature or its configuration. It describes how to apply the countermeasure and the possible negative consequences of countermeasure.
### Vulnerability
@ -88,13 +88,13 @@ The **Log on as a batch job** user right presents a low-risk vulnerability. For
### Countermeasure
You should allow the computer to manage this user right automatically if you want to allow scheduled tasks to run for specific user accounts. If you do not want to use the Task Scheduler in this manner, configure the **Log on as a batch job** user right for only the Local Service account.
Allow the computer to manage this user right automatically if you want to allow scheduled tasks to run for specific user accounts. If you don't want to use the Task Scheduler in this manner, configure the **Log on as a batch job** user right for only the Local Service account.
For IIS servers, you should configure this policy locally instead of through domainbased Group Policy settings so that you can ensure the local IUSR\_*<ComputerName>* and IWAM\_*<ComputerName>* accounts have this user right.
For IIS servers, configure this policy locally instead of through domainbased Group Policy settings so that you can ensure the local IUSR\_*<ComputerName>* and IWAM\_*<ComputerName>* accounts have this user right.
### Potential impact
If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer cannot assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you may need to assign this user right to additional accounts that are required by those components. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*<ComputerName>*, ASPNET, and IWAM\_*<ComputerName>* accounts. If this user right is not assigned to this group and these accounts, IIS cannot run some COM objects that are necessary for proper functionality.
If you configure the **Log on as a batch job** setting by using domain-based Group Policy settings, the computer can't assign the user right to accounts that are used for scheduled jobs in the Task Scheduler. If you install optional components such as ASP.NET or IIS, you might need to assign this user right to additional accounts that those components require. For example, IIS requires assignment of this user right to the IIS\_WPG group and the IUSR\_*<ComputerName>*, ASPNET, and IWAM\_*<ComputerName>* accounts. If this user right isn't assigned to this group and these accounts, IIS can't run some COM objects that are necessary for proper functionality.
## Related topics

View File

@ -22,7 +22,7 @@ ms.date: 04/19/2017
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Log on as a service** security policy setting.
This article describes the recommended practices, location, values, policy management, and security considerations for the **Log on as a service** security policy setting.
## Reference
@ -47,7 +47,7 @@ Computer Configuration\\Windows Settings\\Security Settings\\Local Policies\\Use
By default this setting is Network Service on domain controllers and Network Service on stand-alone servers.
The following table lists the actual and effective default policy values. Default values are also listed on the policys property page.
The following table lists the actual and effective default policy values. The policy's property page also lists default values.
| Server type or GPO | Default value |
| - | - |
@ -62,7 +62,7 @@ The following table lists the actual and effective default policy values. Defaul
This section describes features, tools, and guidance to help you manage this policy.
A restart of the computer is not required for this policy setting to be effective.
A restart of the computer isn't required for this policy setting to be effective.
Any change to the user rights assignment for an account becomes effective the next time the owner of the account logs on.
@ -79,21 +79,21 @@ Group Policy settings are applied in the following order, which will overwrite s
## 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.
This section describes how an attacker might exploit a feature or its configuration. It explains the countermeasure. And it addresses the possible negative consequences of the countermeasure.
### Vulnerability
The **Log on as a service** user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced by the fact that only users with administrative privileges can install and configure services. An
attacker who has already attained that level of access could configure the service to run with the Local System account.
The **Log on as a service** user right allows accounts to start network services or services that run continuously on a computer, even when no one is logged on to the console. The risk is reduced because only users who have administrative privileges can install and configure services. An
attacker who has already reached that level of access could configure the service to run with the Local System account.
### Countermeasure
By definition, the Network Service account has the **Log on as a service** user right. This right is not granted through the Group Policy setting. You should minimize the number of other accounts that are granted this user right.
By definition, the Network Service account has the **Log on as a service** user right. This right isn't granted through the Group Policy setting. Minimize the number of other accounts that are granted this user right.
### Potential impact
On most computers, restricting the **Log on as a service** user right to the Local System, Local Service, and Network Service built-in accounts is the default configuration, and there is no negative impact. However, if you have installed optional components such as ASP.NET or IIS, you may need to
assign the **Log on as a service** user right to additional accounts that are required by those components. IIS requires that this user right be explicitly granted to the ASPNET user account.
On most computers, the **Log on as a service** user right is restricted to the Local System, Local Service, and Network Service built-in accounts by default, and there's no negative impact. But if you have optional components such as ASP.NET or IIS, you might need to
assign the user right to the additional accounts that those components require. IIS requires this user right to be explicitly granted to the ASPNET user account.
## Related topics

View File

@ -37,7 +37,7 @@ If the value for this policy setting is too high, users might be able to access
### Best practices
- It is advisable to set **Maximum lifetime for user ticket** to 10 hours.
- We recommend that you set the **Maximum lifetime for user ticket** to 10 hours.
### Location

View File

@ -32,9 +32,9 @@ The **Minimum password age** policy setting determines the period of time (in da
### Best practices
[Windows security baselines](https://docs.microsoft.com/windows/security/threat-protection/windows-security-baselines) recommend setting **Minimum password age** to 1 day.
[Windows security baselines](https://docs.microsoft.com/windows/security/threat-protection/windows-security-baselines) recommend setting **Minimum password age** to one day.
Setting the number of days to 0 allows immediate password changes, which is not recommended.
Setting the number of days to 0 allows immediate password changes. This setting is not recommended.
Combining immediate password changes with password history allows someone to change a password repeatedly until the password history requirement is met and re-establish the original password again.
For example, suppose a password is "Ra1ny day!" and the history requirement is 24.
If the minimum password age is 0, the password can be changed 24 times in a row until finally changed back to "Ra1ny day!".
@ -76,7 +76,7 @@ This section describes how an attacker might exploit a feature or its configurat
Users may have favorite passwords that they like to use because they are easy to remember and they believe that their password choice is secure from compromise. Unfortunately, passwords can be compromised and if an attacker is targeting a specific individual user account, with knowledge of data about that user, reuse of old passwords can cause a security breach.
To address password reuse, you must use a combination of security settings. Using this policy setting with the [Enforce password history](enforce-password-history.md) policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users cannot reuse any of their last 12 passwords, but you do not configure the **Minimum password age** policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. You must configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.
To address password reuse, you must use a combination of security settings. Using this policy setting with the [Enforce password history](enforce-password-history.md) policy setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history policy setting to ensure that users cannot reuse any of their last 12 passwords, but you do not configure the **Minimum password age** policy setting to a number that is greater than 0, users could change their password 13 times in a few minutes and reuse their original password. Configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.
### Countermeasure

View File

@ -22,7 +22,7 @@ ms.date: 04/19/2017
**Applies to**
- Windows 10
Describes the best practices, location, values, policy management, and security considerations for the **Minimum password length** security policy setting.
This article describes the recommended practices, location, values, policy management, and security considerations for the **Minimum password length** security policy setting.
## Reference
@ -35,9 +35,9 @@ The **Minimum password length** policy setting determines the least number of ch
### Best practices
Set Minimum password length to at least a value of 8. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it is long enough to provide adequate security and still short enough for users to easily remember. A minimum password length greater than 14 is not supported at this time. This value will help provide adequate defense against a brute force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. For more info, see [Password must meet complexity requirements](password-must-meet-complexity-requirements.md).
Set Minimum password length to at least a value of 8. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it's long enough to provide adequate security and still short enough for users to easily remember. A minimum password length greater than 14 isn't supported at this time. This value will help provide adequate defense against a brute force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. For more info, see [Password must meet complexity requirements](password-must-meet-complexity-requirements.md).
Permitting short passwords reduces security because short passwords can be easily broken with tools that perform dictionary or brute force attacks against the passwords. Requiring very long passwords can result in mistyped passwords that might cause an account lockout and subsequently increase the volume of Help Desk calls.
Permitting short passwords reduces security because short passwords can be easily broken with tools that do dictionary or brute force attacks against the passwords. Requiring very long passwords can result in mistyped passwords that might cause account lockouts and might increase the volume of Help Desk calls.
In addition, requiring extremely long passwords can actually decrease the security of an organization because users might be more likely to write down their passwords to avoid forgetting them. However, if users are taught that they can use passphrases (sentences such as "I want to drink a $5 milkshake"), they should be much more likely to remember.
@ -51,12 +51,12 @@ The following table lists the actual and effective default policy values. Defaul
| Server type or Group Policy Object (GPO) | Default value |
| - | - |
| Default domain policy| 7 characters|
| Default domain policy| Seven characters|
| Default domain controller policy | Not defined|
| Stand-alone server default settings | 0 characters|
| Domain controller effective default settings | 7 characters|
| Member server effective default settings | 7 characters|
| Effective GPO default settings on client computers | 0 characters|
| Stand-alone server default settings | Zero characters|
| Domain controller effective default settings | Seven characters|
| Member server effective default settings | Seven characters|
| Effective GPO default settings on client computers | Zero characters|
## Policy management
@ -64,7 +64,7 @@ This section describes features, tools, and guidance to help you manage this pol
### Restart requirement
None. Changes to this policy become effective without a device restart when they are saved locally or distributed through Group Policy.
None. Changes to this policy become effective without a device restart when they're saved locally or distributed through Group Policy.
## Security considerations
@ -78,14 +78,14 @@ Types of password attacks include dictionary attacks (which attempt to use commo
Configure the **Minimum password length** policy setting to a value of 8 or more. If the number of characters is set to 0, no password will be required.
In most environments, we recommend an eight-character password because it is long enough to provide adequate security, but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the [Password must meet complexity requirements](password-must-meet-complexity-requirements.md) policy setting in addition to the **Minimum password length** setting helps reduce the possibility of a dictionary attack.
In most environments, we recommend an eight-character password because it's long enough to provide adequate security, but not too difficult for users to easily remember. This configuration provides adequate defense against a brute force attack. Using the [Password must meet complexity requirements](password-must-meet-complexity-requirements.md) policy setting in addition to the **Minimum password length** setting helps reduce the possibility of a dictionary attack.
> [!NOTE]
> Some jurisdictions have established legal requirements for password length as part of establishing security regulations.
### Potential impact
Requirements for extremely long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about passphrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover.
Requirements for extremely long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of Help Desk calls. If your organization has issues with forgotten passwords because of password length requirements, consider teaching your users about passphrases, which are often easier to remember and, because of the larger number of character combinations, much harder to discover.
## Related topics