Threats and Countermeasures

This chapter discusses those Group Policy settings that are applied at the domain level. The built-in Default Domain Controller policy includes default setting values for these policies, which are collectively referred to as Account policies.

On This Page

	Account Policies
	More Information

Account Policies

There are three different types of Account policies: password policies, account lockout policies, and Kerberos authentication protocol policies. A single Microsoft Windows Server™ 2003 domain may have one of each of these policies. If these policies are set at any other level in Active Directory, only local accounts on member servers will be affected.

Note: For domain accounts, there can be only one Account policy per domain. The Account policy must be defined in the Default Domain Policy or in a new policy that is linked to the root of the domain and given precedence over the Default Domain Policy, which is enforced by the domain controllers that make up the domain. A domain controller always pulls the Account policy from the root of the domain, even if there is a different Account policy applied to the OU that contains the domain controller. The root of the domain is the top level container of the domain, not to be confused with the root domain in a forest; the root domain in a forest is the top level domain within that forest.

The Account policy settings in Group Policy are all applied at the domain level. Default values are present in the built-in Default Domain Controller policy for password policies, account lockout policies, and Kerberos policies. When you configure these policies in the Active Directory® directory service, remember that Microsoft® Windows® only allows one domain Account policy—the Account policy that is applied to the root domain of the domain tree. The domain Account policy will become the default Account policy of any Windows computer that is a member of the domain.

The only exception to this rule is when another Account policy is defined for an organizational unit (OU). The Account policy settings for the OU will affect the local policy on any computers that are contained in the OU. For example, if an OU policy defines a maximum password age that differs from the domain-level Account policy, the OU policy will only be applied and enforced when users log on to the local computer. Only default local computer policies will apply to computers that are in a workgroup or in a domain where neither an OU Account policy nor a domain policy applies.

The settings for each of these policy types are discussed throughout this chapter.

Password Policy

In Windows and many other operating systems, the most common method to authenticate a user’s identity is to use a secret pass phrase or password. A secure network environment requires all users to use strong passwords (ones that have at least ten characters and include a combination of letters, numbers, and symbols). These passwords help prevent the compromise of user accounts and administrative accounts by unauthorized people who use either manual methods or automated tools to guess weak passwords. Strong passwords that are changed regularly reduce the likelihood of a successful password attack. (More detailed information about strong passwords is provided in the "Passwords must meet complexity requirements" section later in this chapter.)

You can enforce the use of strong passwords through an appropriate password policy. Password policy settings control the complexity and lifetime of passwords. This section discusses each specific password policy account setting. This guide also includes a Microsoft Excel® workbook, "Windows Default Security and Services Configuration," that documents the default settings.

You can configure the password policy settings in the following location within the Group Policy Object Editor:

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

If groups exist that require separate password policies, they should be segmented into another domain or forest based on any additional requirements.

Enforce password history

This policy setting determines the number of unique new passwords that must be associated with a user account before an old password can be reused.

The possible values for the Enforce password history setting are:

Vulnerability

Password reuse is an important concern in any organization. Many users will want to use or reuse the same password for their account over a long period of time. The longer the same password is in use for a particular account, the greater the chance that an attacker will be able to 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 can 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 will be able to repeatedly change their passwords until they can reuse their original password.

Countermeasure

Configure the Enforce password history setting to 24, the maximum setting, to help minimize the number of vulnerabilities that are caused by password reuse.

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

Potential Impact

The major impact of this configuration is that users will have to 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. Also, an excessively low value for the Minimum password age setting will likely increase administrative overhead, because users who forget their passwords may require help desk assistance to reset them.

Maximum password age

This policy setting determines the number of days that a password can be used before the user must change it.

The possible values for the Maximum password age setting are:

Vulnerability

Any password, even the most complex password, can be guessed (or "cracked") by an attacker with sufficient time and computer processing power. Some of the following policy settings can make it harder to crack passwords in a reasonable amount of time. The risk of a valid password being cracked can be reduced if users are frequently required to change their passwords, which can also mitigate the risk of unauthorized logon by someone who wrongfully acquired a password. You can configure the Maximum password age setting so that users are never required to change their passwords, but such a configuration would be a major security risk.

Countermeasure

Configure the Maximum password age setting to a value that is suitable for your organization’s business requirements. Microsoft recommends a value of 90 days for most organizations. Although such a configuration is not recommended, you can configure the Maximum Password Age setting to 0 so that passwords will never expire.

Potential Impact

If the Maximum password age setting is too low, users will be required to change their passwords very often. Such a configuration may actually reduce security in the organization, because users may be more likely to write their passwords somewhere so that they do not forget them and then leave the information in an insecure location or lose it. If you configure the value for this policy setting too high, the level of security within an organization will be reduced because it will allow potential attackers a much larger timeframe in which to crack user passwords or to use compromised accounts.

Minimum password age

This policy setting determines the number of days that a password must be used before the user is allowed to change it. The Minimum password age value must be less than the Maximum password age value.

Configure this policy setting to a number that is greater than 0 if you want the Enforce password history setting to be effective. If you configure the Enforce password history setting to 0, the user is not required to choose a new unique password when they are prompted to change their password. If password history is used, users will have to enter a new unique password when they change their password.

The possible values for the Minimum password age setting are:

Vulnerability

It is ineffective to require users to change passwords regularly if they can cycle through passwords until they can reuse a favorite password. Use this policy setting with the Enforce password history setting to prevent the 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 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.

Countermeasure

Configure the Minimum password age setting to a value of at least 2 days. If you configure the number of days to 0, immediate password changes would be allowed, which is not recommended.

Potential Impact

One minor issue is associated with a Minimum password age setting configuration of a number that is greater than 0. If an administrator sets a password for a user but would like that user to change the password when they first log on, 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 next day.

Minimum password length

This policy setting determines the least number of characters that may 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 and later versions, pass phrases can be quite long and they can include spaces, punctuation marks, and Unicode characters. Therefore, a phrase such as "I want to drink a $5 beverage!" is a valid pass phrase. Such a phrase is considerably stronger than an 8 or 10 character string of random numbers and letters, but it is easier to remember.

The possible values for the Minimum password length setting are:

Vulnerability

There are several types of password attacks that can be performed to obtain the password for a particular user account. These 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 utilities to crack the accounts and passwords.

Countermeasure

Configure the Minimum password length 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, an 8-character password is recommended because it is long enough to provide adequate security but not too difficult for users to easily remember. This configuration will provide adequate defense against a brute force attack. Additional complexity requirements will help reduce the possibility of a dictionary attack. Complexity requirements are discussed in the next section of this chapter. You should also note that some countries have legal requirements with respect to password length.

Potential Impact

Requirements for extremely long passwords can actually decrease the security of an organization, because users may be more likely to write their passwords somewhere so that they do not forget them and then leave the information in an insecure location or lose it. However, if users are taught that they can use pass phrases as described earlier, they should be able to easily remember them.

If short passwords are permitted, security will be reduced because they can be easily cracked with tools that perform either dictionary or brute force attacks. If very long passwords are required, mistyped passwords could cause account lockouts and subsequently increase the volume of help desk calls.

Older versions of Windows such as Windows 98 and Windows NT® 4.0 do not support passwords that are longer than 14 characters. Computers that run these older operating systems will be unable to authenticate with computers or domains that use accounts that require long passwords.

Passwords must meet complexity requirements

This policy setting determines whether passwords must meet a series of guidelines that are considered important for a strong password.

If this policy setting is enabled, passwords must meet the following requirements:

These complexity requirements are enforced upon password change or creation of new passwords.

The rules that are included in the Windows Server 2003 policy cannot be directly modified. However, you can create a new version of the Passfilt.dll file to apply a different set of rules. For more information about how to create your own password filter, see the Password Filters documentation in the Windows Platform software development kit (SDK) on MSDN® at http://msdn2.microsoft.com/en-us/library/ms721882.

The possible values for the Passwords must meet complexity requirements setting are:

Vulnerability

Passwords that contain only alphanumeric characters are extremely easy to crack with several publicly available utilities. To prevent passwords from being cracked, they should contain a wider range of characters.

Countermeasure

Configure the Passwords must meet complexity requirements setting to Enabled.

When combined with a Minimum password length of 8, this policy setting ensures that the number of different possibilities for a single password is so great that it will be difficult (but not impossible) for a brute force attack to succeed. An attacker who had enough processing power to test 1 million passwords per second could determine such a password in about seven and one-half days or less. (If the Minimum password length setting is increased, the average amount of time necessary for a successful attack will also increase.)

Potential Impact

If the default password complexity configuration is retained, additional help desk calls for locked-out accounts could occur because users may 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 0128 – 0159 range. (ALT characters outside of this range may represent standard alphanumeric characters that would not add additional complexity to the password.)

Store password using reversible encryption for all users in the domain

This policy setting determines whether Microsoft Windows Server 2003, Windows 2000 Server, Windows 2000 Professional, and Windows XP Professional use reversible encryption when they store passwords.

The Store password using reversible encryption for all users in the domain setting provides support for application protocols that require knowledge of the user's password for authentication purposes. However, encrypted passwords that are stored in a way that is reversible can be decrypted. A knowledgeable attacker who was able to break this encryption could then log on to network resources with the compromised account.

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

Use of Challenge Handshake Authentication Protocol (CHAP) authentication through remote access or Internet Authentication Service (IAS) services requires that this policy setting be enabled. CHAP is an authentication protocol that can be used by Microsoft remote access and Network Connections.

The possible values for the Store password using reversible encryption for all users in the domain setting are:

Vulnerability

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

Countermeasure

Configure the Store password using reversible encryption for all users in the domain setting to Disabled.

Potential 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 the Microsoft Management Console (MMC) Active Directory Users and Computers snap-in.

Account Lockout Policy

More than a few unsuccessful password submissions during an attempt to log on to a computer might represent an attacker's attempts to determine an account password by trial and error. Windows Server 2003 with SP1 tracks logon attempts, and you can configure the operating system to disable the account for a preset period of time after a specified number of failed attempts. Account lockout policy settings control the threshold for this response and what action to take after the threshold is reached. This guide includes a Microsoft Excel workbook, "Windows Default Security and Services Configuration," that documents the default settings.

You can configure the account lockout policy settings in the following location within the Group Policy Object Editor:

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

Account lockout duration

This policy setting determines the number of minutes that a locked-out account remains locked out before it is automatically unlocked. The available range is from 1 to 99,999 minutes. To specify that the account will be locked out until an administrator manually unlocks it, configure the value to 0. If an account lockout threshold is defined, the Account lockout duration must be greater than or equal to the reset time.

The possible values for the Account lockout duration setting are:

Vulnerability

A denial of service (DoS) condition may be created if an attacker abuses the Account lockout threshold and repeatedly attempts to log on with a specific account. If 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.

Countermeasure

Configure the Account lockout duration setting to an appropriate value for your environment. To specify that the account will remain locked until an administrator manually unlocks it, configure the value to 0. When the Account lockout duration setting is configured to a non-zero value, automated attempts to guess account passwords must wait out this interval before they resume attempts against a specific account. If you use this setting in combination with the Account lockout threshold setting, such automated password guessing attempts can be made difficult or useless.

Potential Impact

Although it may seem like a good idea to configure this policy setting to never automatically unlock an account, such a configuration may increase the number of requests that your organization's help desk receives to unlock accounts that were locked by mistake.

Account lockout threshold

This policy setting determines the number of failed logon attempts that causes a user account to become locked out. A locked-out account cannot be used until it is reset by an administrator or until the lockout duration for the account expires. You can specify up to 999 failed logon attempts, or you can set the value to 0 to specify that the account will never be locked out. If you define an Account lockout threshold, then the Account lockout duration must be greater than or equal to the reset time.

Failed password attempts against workstations or member servers that have been locked using either CTRL+ALT+DELETE or password-protected screen savers do not count as failed logon attempts unless the policy setting Interactive logon: Require Domain Controller authentication to unlock workstation is enabled. If it is, then repeated failed password attempts to unlock the workstation will count against the account lockout threshold.

The possible values for the Account lockout threshold setting are:

Vulnerability

Password attacks may use automated methods to try thousands or even millions of password combinations for any or all user accounts. The effectiveness of such attacks can be almost eliminated if you limit the number of failed logons that can be performed.

However, it is important to note that a DoS attack could be performed on a domain that has an account lockout threshold configured. A malicious attacker could programmatically attempt a series of password attacks against all users in the organization. If the number of attempts is greater than the account lockout threshold, the attacker may be able to lock out every account.

Countermeasure

Because vulnerabilities can exist when this value is configured as well as when it is not configured, two distinct countermeasures are defined. Any organization should weigh the choice between the two based on their identified threats and the risks that they wish to mitigate. The two countermeasure options are:

Potential 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 will likely generate a number of additional help desk calls. In fact, locked accounts cause the greatest number of calls to the help desk in many organizations.

If you configure the Account Lockout Threshold to 0, there is a possibility that an attacker's attempt to crack passwords with a brute force password attack may go undetected if a robust audit mechanism is not in place.

Reset account lockout counter after

This policy setting determines the number of minutes that must elapse before the counter that tracks failed logon attempts and triggers account lockouts is reset to 0. If an Account lockout threshold is defined, this reset time must be less than or equal to the Account lockout duration setting configuration.

The possible values for the Reset account lockout counter after setting are:

Vulnerability

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.

Countermeasure

Configure the Reset account lockout counter after setting to 30 minutes.

Potential 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.

Kerberos Policy

In Windows Server 2003 with SP1, the Kerberos authentication protocol provides the default mechanism for domain authentication services and the authorization data that is necessary for a user to access a resource and perform a task on that resource. If the lifetime of Kerberos tickets is reduced, the risk of a legitimate user’s credentials being stolen and successfully used by an attacker decreases. However, authorization overhead increases.

In most environments, the Kerberos policy settings should not need to be changed. These policy settings are applied at the domain level, and the default values are configured in the Default Domain Policy GPO in a default installation of a Windows 2000 or Windows Server 2003 Active Directory domain. This guide includes a Microsoft Excel workbook, "Windows Default Security and Services Configuration," that documents the default settings.

You can configure the Kerberos policy settings in the following location within the Group Policy Object Editor:

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

Enforce user logon restrictions

This policy setting determines whether the Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validation of each request for a session ticket is optional, because the extra step takes time and may slow network access to services.

The possible values for the Enforce user logon restrictions setting are:

Vulnerability

If you disable this policy setting, users could receive session tickets for services that they no longer have the right to use because the right was removed after they logged on.

Countermeasure

Configure the Enforce user logon restrictions setting to Enabled.

Potential Impact

None. This is the default configuration.

Maximum lifetime for service ticket

This policy setting determines the maximum amount of time (in minutes) that a granted session ticket can be used to access a particular service. The setting must be 10 minutes or greater, and less than or equal to the configuration of the Maximum lifetime for user ticket setting.

If a client presents an expired session ticket when it requests a connection to a server, the server returns an error message and the client must request a new session ticket from the KDC. After a connection is authenticated, however, it does not matter if the session ticket remains valid. Session tickets are used only to authenticate new connections with servers. Operations are not interrupted if the session ticket that authenticated the connection expires during the connection.

The possible values for the Maximum lifetime for service ticket setting are:

Vulnerability

If you configure the value for the Maximum lifetime for service ticket setting too high, then users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might have continued access to network services with valid service tickets that were issued before their accounts were disabled.

Countermeasure

Configure the Maximum lifetime for service ticket setting to 600 minutes.

Potential Impact

None. This is the default configuration.

Maximum lifetime for user ticket

This policy setting determines the maximum amount of time (in hours) of a user's ticket-granting ticket (TGT). When a user's TGT expires, a new one must be requested or the existing one must be renewed.

The possible values for the Maximum lifetime for user ticket setting are:

Vulnerability

If you configure the value for the Maximum lifetime for user ticket setting too high, then users might be able to access network resources outside of their logon hours. Also, users whose accounts were disabled might continue to have access to network services with valid service tickets that were issued before their accounts were disabled.

Countermeasure

Configure the Maximum lifetime for user ticket setting to 10 hours.

Potential Impact

None. This is the default configuration.

Maximum lifetime for user ticket renewal

This policy setting determines the period of time (in days) during which a user's ticket-granting ticket (TGT) may be renewed.

The possible values for the Maximum lifetime for user ticket renewal setting are:

Vulnerability

If the value for the Maximum lifetime for user ticket renewal setting is too high, then users may be able to renew very old user tickets.

Countermeasure

Configure the Maximum lifetime for user ticket renewal setting to 10080 minutes (7 days).  

Potential Impact

None. This is the default configuration.

Maximum tolerance for computer clock synchronization

This policy setting determines the maximum time difference (in minutes) that the Kerberos protocol will allow between the time on the client computer's clock and the time on the Windows Server 2003–based domain controller that provides Kerberos authentication.

The possible values for the Maximum tolerance for computer clock synchronization setting are:

Vulnerability

To prevent "replay attacks," the Kerberos authentication protocol 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 not synchronized, administrators can use this policy to establish the maximum elapsed time within which a Kerberos negotiation must complete; the elapsed time is computed from the timestamps. The value of this setting limits the maximum time difference that can be tolerated between the domain controller and the client computer.

Countermeasure

Configure the Maximum tolerance for computer clock synchronization setting to 5 minutes.

Potential Impact

None. This is the default configuration.

Top of page

More Information

The following links provide additional information about topics that relate to hardening domain controllers that run Windows Server 2003 with SP1:

Top of page

3 of 14