Password reuse is an important concern in any organization. Many users want to reuse the same password for their account over a long period of time. The longer the same password is used for a particular account, the greater the chance that an attacker will be able to determine the password through brute force attacks. If users are required to change their password, but nothing prevents them from using the old password or continually reusing a small number of passwords, the effectiveness of a good password policy is greatly reduced.

Specifying a low number for Enforce password history allows users to continually use the same small number of passwords repeatedly. If you do not also set Minimum password age, users can change their password as many times in a row as necessary in order to reuse their original password.

If you set Enforce password history to a number greater than zero, users must come up with a new password every time they are required to change their old one. This improves security, but it can increase the risk that users will write down their passwords so they do not forget them.

If you set the value to the maximum of 24, it helps to ensure that vulnerabilities caused by password reuse are kept to a minimum.

For this policy setting to be effective in your organization, configure Minimum password age so that you do not allow passwords to be changed immediately. Enforce password history should be set at the level that combines a reasonable maximum password age with a reasonable password change interval requirement for users.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

If your users change their passwords frequently, it helps to reduce the risk that a valid password might be cracked, and it mitigates the risk that someone may use a password that has been wrongfully acquired. Maximum password age can be configured so that users are never required to change their passwords, but this results in a major security risk.

Many cautious administrators choose to set Maximum password age to a value between 30 and 60 days. You can set Maximum password age to never expire by setting the number of days to 0.

Setting Maximum password age very low requires users to change their passwords too often. This might actually reduce security in the organization, because it can increase the possibility of that users will write their passwords down to avoid forgetting them. If you set the value very high, it reduces the level of security within an organization, because it gives a potential attacker more time to guess a user’s password.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

Forcing users to change passwords regularly is ineffective if they can cycle through passwords until they get to an old favorite. Use Minimum password age with Enforce password history to prevent this. For example, if Enforce password history is set to 12 (which ensures that users cannot reuse any of their last 12 passwords) and Minimum password age is 0, users could change their password 13 times in a row to return to the password they were originally using. Therefore, Minimum password age must be set to a value greater than 0 for Enforce password history to be effective.

It is advisable to set Minimum password age to a value of 2 days. Setting the number of days to 0 allows immediate password changes, which is not recommended.

There is one minor issue associated with setting Minimum password age to a number greater than 0. If an administrator sets a password for a user, and then would like for that user to change the administrator-defined password, the administrator must select the User must change password at next logon check box. Otherwise, the user will not be able to change the password until the number of days specified by Minimum password age.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

There are several types of password attacks that can be performed to obtain the password for a particular user account. These include dictionary attacks — which attempt to use common words and phrases — and brute-force attacks, which try every possible combination of characters. In addition, an attack can be performed by obtaining the account database and using tools to crack the accounts and passwords.

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. This value will help to provide adequate defense against a brute-force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. Complexity requirements are discussed in the description of the Passwords must meet complexity requirements policy setting.

Permitting short passwords reduces security, because short passwords can be easily broken with tools that perform either 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.

In addition, requiring extremely long passwords can actually decrease the security of an organization because users might be more likely to write their passwords down to avoid forgetting them. However, if users are taught they can use pass phrases as described above, they should be much more likely to remember.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

Passwords that contain only alphanumeric characters are easy to crack by using publicly available tools. To prevent this, passwords should contain additional characters and meet complexity requirements.

Set Passwords must meet complexity requirements to Enabled. This policy setting, combined with a minimum password length of 8, ensures that there are at least 218,340,105,584,896 different possibilities for a single password. This makes the use of a brute-force attack difficult, but still not impossible. An attacker who had enough processing power to test 1 million passwords per second could determine such a password in about seven-and-a-half days or less.

Enabling the default Passfilt.dll may cause some additional Help desk calls for locked-out accounts because users might not be used to having passwords that contain characters other than those found in the alphabet. However, this policy setting is liberal enough that all users should be able to abide by the requirements with a minor learning curve.

Additional settings that can be included in a custom Passfilt.dll are the use of non–upper-row characters. Upper-row characters are those that are typed by holding down the SHIFT key and typing any of the digits from 1 through 10.

Also, the use of ALT key character combinations can greatly enhance the complexity of a password. However, requiring all users in an organization to adhere to such stringent password requirements can result in unhappy users and an extremely busy Help desk. Consider implementing a requirement in your organization to use ALT characters in the range from 0128 through 0159 as part of all administrator passwords. (ALT characters outside of this range can represent standard alphanumeric characters that do not add additional complexity to the password.)

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

This policy setting determines whether Windows Server 2003 will store passwords in a weaker format that is much more susceptible to brute force attacks.

It is advisable to set the value for Store password using reversible encryption for all users in the domain to Disabled. If you use either Digest Authentication in IIS or the CHAP authentication protocol through remote access or IAS, you must set this value to Enabled. This is an extremely dangerous policy setting to apply by using Group Policy on a user-by-user basis, because it requires opening the appropriate user account object in Active Directory Users and Computers.

Note

• Never enable this policy setting unless business requirements outweigh the need to protect password information.
  
  

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

A denial-of-service attack can occur if an attacker abuses the Account lockout threshold and repeatedly attempts to log on to an account. If the Account lockout thresholdis configured, after the specified number of failed attempts the account will be locked out. If the Account lockout duration is set to 0, the account will remain locked out until an administrator unlocks it manually.

It is advisable to set Account lockout duration to approximately 30 minutes. To specify that the account will never be locked out, set the value to 0. To configure the value for this policy setting so that it never automatically unlocks the account might seem like a good idea, doing so can increase the number of requests that your organization’s Help desk receives to unlock accounts that were locked by mistake.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Password Policy\

Default Values

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 logons that can be performed nearly eliminates the effectiveness of such attacks.

However, it is important to note that, in contrast, a denial-of-service 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 out every account.

Because vulnerabilities can exist both when this value is configured and when it is not, any organization should weigh their identified threats and the risks that they are trying to mitigate. There are two options to consider for this policy setting:

• Set Account lockout threshold to 0. This ensures that accounts will not be locked out. This setting will prevent a denial-of-service attack that intentionally locks out all or some accounts. In addition, this setting helps reduce Help desk calls because users cannot accidentally lock themselves out of their accounts. 
  
  Because it will not prevent a brute force attack, a value of 0 should only be chosen if both of the following criteria are explicitly met:
  
  
  • Password Policy settings force all users to have complex passwords made up of eight or more characters.
    
    
  • A robust auditing mechanism is in place to alert administrators when a series of failed logons are occurring in the environment.
    
    
  If these criteria cannot be met, set Account lockout threshold to a high enough value that users can accidentally mistype their password several times before they are locked out of their account, but ensure that a brute-force password attack would still lock out the account. It is advisable to specify a value of 50 invalid logon attempts. Keep in mind, however, that although this setting can reduce the number of Help desk calls by reducing the number of user lockouts, it cannot prevent a denial-of-service attack.
  
  

Setting Account lockout threshold to a number greater than zero locks out user accounts until they are reset by an administrator, or until the number of minutes specified inAccount lockout duration expires. This setting will likely generate a number of additional Help desk calls. In fact, in many organizations, locked accounts generate the most calls to the Help desk.

By setting Account lockout threshold to 0, you leave your organization open to the possibility that you will not detect a brute force attack.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\

Default Values

A disadvantage to setting this too high is that users lock themselves out for an inconveniently long period, if they exceed the account lockout threshold through login errors. Users may make excessive help desk calls.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policy\

Default Values

If this policy setting is disabled, users might be granted session tickets for services they do not have the right to use.

It is advisable to set Enforce user logon restrictions to Enabled.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

Default Values

If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message. The client must request a new session ticket from the Kerberos V5 KDC. After a connection is authenticated, however, it no longer matters whether the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Ongoing operations are not interrupted if the session ticket that authenticated the connection expires during the connection.

If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours, or users whose accounts have been disabled might be able to continue accessing network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, service tickets never expire.

It is advisable to set Maximum lifetime for service ticket to 600 minutes.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

Default Values

If the value for this policy setting is too high, users might be able to access network resources outside of their logon hours, or users whose accounts have been disabled might be able to continue to access network services by using valid service tickets that were issued before their account was disabled. If the value is set to 0, ticket-granting tickets never expire.

It is advisable to set Maximum lifetime for user ticket to 10 hours.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

Default Values

If the value for this policy setting is too high, users may be able to renew very old user ticket-granting tickets. If the value is 0, ticket-granting tickets never expire.

It is advisable to set Maximum lifetime for user ticket renewal to 7 days.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

Default Values

To prevent replay attacks, Kerberos V5 uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client and the domain controller need to be synchronized as closely as possible. Because the clocks of two computers are often out of sync, administrators can use this policy setting to establish the maximum acceptable difference to Kerberos V5 between a client clock and domain controller clock. If the difference between a client clock and the domain controller clock is less thanMaximum tolerance for computer clock synchronization, any time stamp that is used in a session between the two computers is considered authentic.

It is advisable to set Maximum tolerance for computer clock synchronization to a value of 5 minutes.

GPO_name\Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy\

Default Values