Hardening, Microsoft Windows server 2016

Windows Server Hardening – Account Policies

The following were tested on Windows Server 2016 (Screenshots included).

Account Policies

Password Policy

1. Ensure ‘Enforce password history’ is set to ’24 or more password(s)

Description:
This policy setting determines the number of renewed, unique passwords that have to be associated with a user account before you can reuse an old password. The value for this policy setting must be between 0 and 24 passwords. The default value for Windows Vista is 0 passwords, but the default setting in a domain is 24 passwords. To maintain the effectiveness of this policy setting, use the Minimum password age setting to prevent users from repeatedly changing their password.

The recommended state for this setting is: 24 or more password(s).

Remediation:
To establish the recommended configuration via GP, set the following UI path to 24 or more password(s):
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Enforce password history

Impact:
The major impact of this configuration is that users must create a new password every time they are required to change their old one. If users are required to change their passwords to new unique values, there is an increased risk of users who write their passwords somewhere so that they do not forget them. Another risk is that users may create passwords that change incrementally (for example, password01, password02, and so on) to facilitate memorization but make them easier to guess. Also, an excessively low value for the Minimum password age setting will likely increase administrative overhead, because users who forget their passwords might ask the help desk to reset them frequently.
Rationale:
The longer a user uses the same password, the greater the chance that an attacker can determine the password through brute force attacks. Also, any accounts that may have been compromised will remain exploitable for as long as the password is left unchanged. If password changes are required but password reuse is not prevented, or if users continually reuse a small number of passwords, the effectiveness of a good password policy is greatly reduced.
If you specify a low number for this policy setting, users will be able to use the same small number of passwords repeatedly. If you do not also configure the Minimum password age setting, users might repeatedly change their passwords until they can reuse their original password.

2. Ensure ‘Maximum password age’ is set to ’60 or fewer days, but not 0′

Description:
This policy setting defines how long a user can use their password before it expires.Values for this policy setting range from 0 to 999 days. If you set the value to 0, the password will never expire.
Because attackers can crack passwords, the more frequently you change the password the less opportunity an attacker has to use a cracked password. However, the lower this value is set, the higher the potential for an increase in calls to help desk support due to users having to change their password or forgetting which password is current.
The recommended state for this setting is 60 or fewer days, but not 0.

Remediation:
To establish the recommended configuration via GP, set the following UI path to 60 or fewer days, but not 0:
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Maximum password age

Impact:
If the Maximum password age setting is too low, users are required to change their passwords very often. Such a configuration can reduce security in the organization, because users might write their passwords in an insecure location or lose them. If the value for this policy setting is too high, the level of security within an organization is reduced because it allows potential attackers more time in which to discover user passwords or to use compromised accounts.
Rationale:
The longer a password exists the higher the likelihood that it will be compromised by a brute force attack, by an attacker gaining general knowledge about the user, or by the user sharing the password. Configuring the Maximum password age setting to 0 so that users are never required to change their passwords is a major security risk because that allows a compromised password to be used by the malicious user for as long as the valid user is authorized access.

3. Ensure ‘Minimum password age’ is set to ‘1 or more day(s)’

Description:
This policy setting determines the number of days that you must use a password before you can change it. The range of values for this policy setting is between 1 and 999 days. (You may also set the value to 0 to allow immediate password changes.) The default value for this setting is 0 days.
The recommended state for this setting is: 1 or more day(s).

Remediation:
To establish the recommended configuration via GP, set the following UI path to 1 or more day(s):
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Minimum password age

Impact:
If an administrator sets a password for a user but wants that user to change the password when the user first logs on, the administrator must select the User must change password at next logon check box, or the user will not be able to change the password until the next day.
Rationale:
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 are compromised and if an attacker is targeting a specific individual user account, with foreknowledge of data about that user, reuse of old passwords can cause a security breach. To address password, reuse a combination of security settings is required. Using this policy setting with the Enforce password history setting prevents the easy reuse of old passwords. For example, if you configure the Enforce password history setting to ensure that users cannot reuse any of their last 12 passwords, they could change their password 13 times in a few minutes and reuse the password they started with, unless you also configure the Minimum password age setting to a number that is greater than 0. You must configure this policy setting to a number that is greater than 0 for the Enforce password history setting to be effective.

4. Ensure ‘Minimum password length’ is set to ’14 or more character(s)’

Description:
This policy setting determines the least number of characters that make up a password for a user account. There are many different theories about how to determine the best password length for an organization, but perhaps “pass phrase” is a better term than “password.” In Microsoft Windows 2000 or later, pass phrases can be quite long and can include spaces. Therefore, a phrase such as “I want to drink a $5 milkshake” is a valid pass phrase; it is a considerably stronger password than an 8 or 10 character string of random numbers and letters, and yet is easier to remember. Users must be educated about the proper selection and maintenance of passwords, especially with regard to password length. In enterprise environments, the ideal value for the Minimum password length setting is 14 characters, however you should adjust this value to meet your organization’s business requirements.
The recommended state for this setting is: 14 or more character(s).

Remediation:
To establish the recommended configuration via GP, set the following UI path to 14 or more character(s):
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Minimum password length

Impact:
Requirements for extremely long passwords can actually decrease the security of an organization, because users might leave the information in an insecure 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 pass phrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover.
Rationale:
Types of password attacks include dictionary attacks (which attempt to use common words and phrases) and brute force attacks (which try every possible combination of characters). Also, attackers sometimes try to obtain the account database so they can use tools to discover the accounts and passwords.

5. Ensure ‘Password must meet complexity requirements’ is set to ‘Enabled’

Description:
This policy setting checks all new passwords to ensure that they meet basic requirements for strong passwords.
When this policy is enabled, passwords must meet the following minimum requirements: – Not contain the user’s account name or parts of the user’s full name that exceed two consecutive characters – Be at least six characters in length – Contain characters from three of the following four categories: – English uppercase characters (A through Z) – English lowercase characters (a through z) – Base 10 digits (0 through 9) – Non-alphabetic characters (for example, !, $, #, %) – A catch-all category of any Unicode character that does not fall under the previous four categories. This fifth category can be regionally specific.
Each additional character in a password increases its complexity exponentially. For instance, a seven-character, all lower-case alphabetic password would have 267 (approximately 8 x 109 or 8 billion) possible combinations. At 1,000,000 attempts per second (a capability of many password-cracking utilities), it would only take 133 minutes to crack. A seven-character alphabetic password with case sensitivity has 527 combinations. A seven-character case-sensitive alphanumeric password without punctuation has 627 combinations. An eight-character password has 268 (or 2 x 1011) possible combinations. Although this might seem to be a large number, at 1,000,000 attempts per second it would take only 59 hours to try all possible passwords. Remember, these times will significantly increase for passwords that use ALT characters and other special keyboard characters such as “!” or “@”. Proper use of the password settings can help make it difficult to mount a brute force attack.
The recommended state for this setting is: Enabled.
Remediation:
To establish the recommended configuration via GP, set the following UI path to Enabled:
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Password must meet complexity requirements

Impact:
If the default password complexity configuration is retained, additional help desk calls for locked-out accounts could occur because users might not be accustomed to passwords that contain non-alphabetic characters. However, all users should be able to comply with the complexity requirement with minimal difficulty.
If your organization has more stringent security requirements, you can create a custom version of the Passfilt.dll file that allows the use of arbitrarily complex password strength rules. For example, a custom password filter might require the use of non-upper row characters. (Upper row characters are those that require you to hold down the SHIFT key and press any of the digits between 1 and 0.) A custom password filter might also perform a dictionary check to verify that the proposed password does not contain common dictionary words or fragments.
Also, the use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in unhappy users and an extremely busy help desk. Alternatively, your organization could consider a requirement for all administrator passwords to use ALT characters in the 01280159 range. (ALT characters outside of this range can represent standard alphanumeric characters that would not add additional complexity to the password.)
Rationale:
Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.

6. Ensure ‘Store passwords using reversible encryption’ is set to ‘Disabled’

Description:
This policy setting determines whether the operating system stores passwords in a way that uses reversible encryption, which provides support for application protocols that require knowledge of the user’s password for authentication purposes. Passwords that are stored with reversible encryption are essentially the same as plaintext versions of the passwords.
The recommended state for this setting is: Disabled.

Remediation:
To establish the recommended configuration via GP, set the following UI path to Disabled:
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Password Policy\Store passwords using reversible encryption

Impact:
If your organization uses either the CHAP authentication protocol through remote access or IAS services or Digest Authentication in IIS, you must configure this policy setting to Enabled. This setting is extremely dangerous to apply through Group Policy on a user-by-user basis, because it requires the appropriate user account object to be opened in Active Directory Users and Computers.
Rationale:
Enabling this policy setting allows the operating system to store passwords in a weaker format that is much more susceptible to compromise and weakens your system security.

Account Lockout Policy

1.Ensure ‘Account lockout duration’ is set to ’15 or more minute(s)’

Description:

This policy setting determines the length of time that must pass before a locked account is unlocked and a user can try to log on again. The setting does this by specifying the number of minutes a locked-out account will remain unavailable. If the value for this policy setting is configured to 0, locked out accounts will remain locked out until an administrator manually unlocks them.

Although it might seem like a good idea to configure the value for this policy setting to a high value, such a configuration will likely increase the number of calls that the help desk receives to unlock accounts locked by mistake. Users should be aware of the length of time a lock remains in place, so that they realize they only need to call the help desk if they have an extremely urgent need to regain access to their computer.
The recommended state for this setting is: 15 or more minute(s).
Remediation:
To establish the recommended configuration via GP, set the following UI path to 15 or more minute(s):
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\Account lockout duration

Impact:
Although it may seem like a good idea to configure this policy setting to never automatically unlock an account, such a configuration can increase the number of requests that your organization’s help desk receives to unlock accounts that were locked by mistake.
Rationale:
A denial of service (DoS) condition can be created if an attacker abuses the Account lockout threshold and repeatedly attempts to log on with a specific account. Once you configure the Account lockout threshold setting, the account will be locked out after the specified number of failed attempts. If you configure the Account lockout duration setting to 0, then the account will remain locked out until an administrator unlocks it manually.

2. Ensure ‘Account lockout threshold’ is set to ’10 or fewer invalid logon attempt(s), but not 0′

Description:
This policy setting determines the number of failed logon attempts before the account is locked. Setting this policy to 0 does not conform with the benchmark as doing so disables the account lockout threshold.
The recommended state for this setting is: 10 or fewer invalid logon attempt(s), but not 0.
Remediation:
To establish the recommended configuration via GP, set the following UI path to 10 or fewer invalid login attempt(s), but not 0:
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\Account lockout threshold

Impact:
If this policy setting is enabled, a locked-out account will not be usable until it is reset by an administrator or until the account lockout duration expires. This setting may generate additional help desk calls.
If you enforce this setting an attacker could cause a denial of service condition by deliberately generating failed logons for multiple user, therefore you should also configure the Account Lockout Duration to a relatively low value.
If you configure the Account Lockout Threshold to 0, there is a possibility that an attacker’s attempt to discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place.
Rationale:
Setting an account lockout threshold reduces the likelihood that an online password brute force attack will be successful. Setting the account lockout threshold too low introduces risk of increased accidental lockouts and/or a malicious actor intentionally locking out accounts.

3. Ensure ‘Reset account lockout counter after’ is set to ’15 or more minute(s)’

Description:
This policy setting determines the length of time before the Account lockout threshold resets to zero. The default value for this policy setting is Not Defined. If the Account lockout threshold is defined, this reset time must be less than or equal to the value for the Account lockout duration setting.
If you leave this policy setting at its default value or configure the value to an interval that is too long, your environment could be vulnerable to a DoS attack. An attacker could maliciously perform a number of failed logon attempts on all users in the organization, which will lock out their accounts. If no policy were determined to reset the account lockout, it would be a manual task for administrators. Conversely, if a reasonable time value is configured for this policy setting, users would be locked out for a set period until all of the accounts are unlocked automatically.
The recommended state for this setting is: 15 or more minute(s).
Remediation:
To establish the recommended configuration via GP, set the following UI path to 15 or more minute(s):
Computer Configuration\Policies\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\Reset account lockout counter after

Impact:
If you do not configure this policy setting or if the value is configured to an interval that is too long, a DoS attack could occur. An attacker could maliciously attempt to log on to each user’s account numerous times and lock out their accounts as described in the preceding paragraphs. If you do not configure the Reset account lockout counter after setting, administrators would have to manually unlock all accounts. If you configure this policy setting to a reasonable value the users would be locked out for some period, after which their accounts would unlock automatically. Be sure that you notify users of the values used for this policy setting so that they will wait for the lockout timer to expire before they call the help desk about their inability to log on.
Rationale:
Users can accidentally lock themselves out of their accounts if they mistype their password multiple times. To reduce the chance of such accidental lockouts, the Reset account lockout counter after setting determines the number of minutes that must elapse before the counter that tracks failed logon attempts and triggers lockouts is reset to 0.

 

References
– CIS-Microsoft-Windows-Server-2012-R2-Benchmark-v2.2.0