Threats and Countermeasures Guide: Account Policies

Applies To: Windows 7, Windows Server 2008 R2

This section of the Threats and Countermeasures Guide discusses Group Policy settings that are applied at the domain level. The default setting values for these policies, which are collectively referred to as Account Policies settings, are included in the built-in Default Domain Controllers Policy Group Policy Object (GPO).

Account Policies overview

There are three folders in the Account Policies folder:

• Password Policy settings

• Account Lockout Policy settings

• Kerberos Policy settings

A single Windows Server® 2008 R2 domain can have one of each of these policies. If these policies are set at any level below the domain level in Active Directory® Domain Services, they affect only local accounts on member servers.

The Account Policies settings in Group Policy are applied at the domain level. Default values are present in the built-in Default Domain Controllers Policy GPO for Password Policy settings, Account Lockout Policy settings, and Kerberos Policy settings. The domain Account Policies settings become the default local Account Policies settings of any computer that is running the Windows® operating system and that is a member of the domain.

The only exception to this rule is when another Account Policies setting is defined for an organizational unit (OU). The Account Policies settings for the OU 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 Policies settings, the OU policy is applied and enforced only when users log on to the local computer. The default local computer policies apply only to computers that are in a workgroup or in a domain where neither an OU Account Policies setting nor a domain policy applies.

The following sections discuss the settings for each of the policies that is in the Account Policies folder.

Password Policy settings

In Windows and many other operating systems, the most common method to authenticate a user's identity is to use a secret passphrase or password. A secure network environment requires all users to use strong passwords. A strong password has at least 10 characters, and it includes a combination of letters, numbers, and symbols. These passwords help prevent the compromise of user accounts and administrative accounts by unauthorized people who use manual methods or automated tools to guess weak passwords. Strong passwords that are changed regularly reduce the likelihood of a successful password attack.

Windows Server 2008 R2 and Windows Server 2008 support fine-grained password policies. This feature provides organizations with a way to define different password and account lockout policies for different sets of users in a domain. In the Active Directory domains in Windows 2000 and Windows Server 2003, only one password policy and account lockout policy could be applied to all users in the domain. Fine-grained password policies apply only to user objects (or inetOrgPerson objects if they are used instead of user objects) and global security groups.

Fine-grained password policies include attributes for all the settings that can be defined in the Default Domain Policy (except Kerberos protocol settings) as well as account lockout settings. When you specify a fine-grained password policy, you must specify all of these settings. By default, only members of the Domain Admins group can set fine-grained password policies. However, you can also delegate the ability to set these policies to other users. The domain functional level must be Windows Server 2008 or Windows Server 2008 R2 to use fine-grained password policies. Fine-grained password policies cannot be applied to an organizational unit (OU) directly.

To apply a fine-grained password policy to users of an OU, you can use a shadow group. A shadow group is a global security group that is logically mapped to an OU to enforce a fine-grained password policy. You add users of the OU as members of the newly created shadow group and then apply the fine-grained password policy to this shadow group. You can create additional shadow groups for other OUs as needed. If you move a user from one OU to another, you must update the membership of the corresponding shadow groups.

Fine-grained password policies do not interfere with custom password filters that you might use in the same domain. Organizations that have deployed custom password filters to domain controllers running Windows 2000 or Windows Server 2003 can continue to use those password filters to enforce additional restrictions for passwords. For more information about fine-grained password policies, see AD DS: Fine-Grained Password Policies.

You can enforce the use of strong passwords through an appropriate password policy. There are password policy settings that control the complexity and lifetime of passwords, such as the Passwords must meet complexity requirements policy setting.

You can configure the password policy settings in the following location by using the Group Policy Management Console (GPMC) on your domain controller:

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

If individual groups require distinct password policies, these groups should be separated 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.

Possible values:

• User-specified value between 0 and 24

• Not Defined

On domain controllers, the default value for this policy setting is 24. On stand-alone servers, the default value for this policy setting is 0.

Vulnerability

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 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 can use the same small number of passwords repeatedly. If you do not also configure the Minimum password age policy setting, users might repeatedly change their passwords until they can reuse their original password.

Countermeasure

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

For this policy setting to be effective, you should also configure effective values for the Minimum password age and Maximum password age policy settings.

Potential impact

The major impact of configuring the Enforce password history policy setting to 24 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 this makes them easier to guess. Also, an excessively low value for the Maximum password age policy setting is likely to increase administrative overhead because users who forget their passwords might ask the help desk to reset them frequently.

Maximum password age

This policy setting determines the maximum number of days that a password can be used before the user must change it. Its value must be more than the Minimum password age value.

Possible values:

• User-specified number of days between 0 and 999

• Not Defined

The default value for this policy setting is 42.

Vulnerability

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 policy 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 a malicious user for as long as the valid user is authorized access.

Countermeasure

Configure the Maximum password age policy setting to a value that is suitable for your organization's business requirements.

Potential impact

If the Maximum password age policy 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 unsecured 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.

Minimum password age

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

Configure this policy setting to a number that is greater than 0, and set the Enforce password history policy setting. If you configure the Enforce password history policy setting to 0, users are not required to choose a new unique password when prompted to change their password. If password history is used, users must enter a new unique password when they change their password.

Possible values:

• User-specified number of days between 0 and 998

• Not Defined

The default value for this policy setting is 1 on domain controllers and 0 on stand-alone servers.

Vulnerability

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, you must use a combination of security settings. Using this policy setting with the Enforce password history 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, they could change their password 13 times in a few minutes and reuse the password they started with. You must configure this policy setting to a number that is greater than 0 for the Enforce password history policy setting to be effective.

Countermeasure

Configure the Minimum password age policy setting to a value of at least 2 days. Users should know about this limitation and contact the help desk if they need to change their password during that 2-day period. If you configure the number of days to 0, immediate password changes would be allowed, which we do not recommend.

Potential 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 cannot change the password until the next day.

Minimum password length

This policy setting determines the fewest number of characters that can make up a password for a user account. Some prefer using a passphrase rather than a password. Passphrases 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 passphrase. Such a phrase is considerably stronger than an 8 or 10 character string and is easier to remember.

The longer a password is, the better security it provides, especially if it includes a character combination of uppercase and lowercase letters, digits, symbols, and punctuation. The following table shows the amount of time that it would take a computer that is performing a brute force attack (at 10 million character combinations per second) to discover a password for a user account.

Password length	Alphanumeric case-sensitive (62 characters)	Alphanumeric case-sensitive including symbols (96 characters)
2	Instant	Instant
3	Instant	Instant
4	Less than 2 seconds	8.5 seconds
5	1.5 minutes	13.5 minutes
6	1.5 hours	22 hours
7	4 days	87 days
8	253 days	23 years

Possible values:

• User-specified number between 0 and 14

• Not Defined

The default value for this policy setting is 7 on domain controllers and 0 on stand-alone servers.

Vulnerability

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.

Countermeasure

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 8-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 Passwords must meet complexity requirements policy setting in addition to the Minimum password length policy setting helps reduce the possibility of a dictionary attack.

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. They are often easier to remember, and due to the larger number of character combinations, they are much harder to discover.

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:

• The password is at least six characters long.

• The password contains characters from three of the following four categories:

  • Uppercase characters

  • Lowercase characters

  • Numerals

• Non-alphanumeric and Unicode characters, which include the following characters as well as other accented characters and characters not present in common keyboards: (( ) ` ~ ! @ # $ % ^ & * - + = | \ { } [ ] : ; " ' < > , . ? / € Γ ƒ λ and space). This group also includes extended characters that can only be specified by using keystroke combinations.

• The password does not contain three or more consecutive characters from the user's account name or display name. If the account name is fewer than three characters long, this check is not performed because the rate at which passwords would be rejected would be too high. When a check is performed against the user's full name, several characters separate the name into individual tokens: commas, periods, dashes/hyphens, underscores, spaces, number signs, and tabs. A token that is three or more characters long is searched for in the password and if it is present, the password change is rejected.

  For example, the name Erin M. Hagens would be split into three tokens: Erin, M, and Hagens. Because the second token is only one character long, it would be ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password. All of these checks are case-insensitive.

These complexity requirements are enforced when a password is changed or a new password is created.

For specific instructions about how to configure password policy settings, see Apply or modify password policy.

For more information, see:

• Strong passwords

• Password best practices

• Apply or modify password policy

• Security Configuration Manager tools

The rules that are included in the Windows Server 2008 R2 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 Password Filters.

Possible values:

• Enabled

• Disabled

• Not Defined

By default, this policy setting is enabled on domain controllers and disabled on stand-alone servers.

Vulnerability

Passwords that contain only alphanumeric characters are extremely easy to discover with several publicly available tools.

Countermeasure

Configure the Passwords must meet complexity requirements policy setting to Enabled and advise users to use a variety of characters in their passwords.

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 is difficult (but not impossible) for a brute force attack to succeed. (If the Minimum password length policy setting is increased, the average amount of time necessary for a successful attack also increases.)

Potential 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-alphabetical characters or might have problems entering passwords that contain accented characters or symbols on keyboards with different layouts. 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 symbols. (Upper row symbols are those that require you to press and hold the SHIFT key and then 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.

The use of ALT key character combinations can greatly enhance the complexity of a password. However, such stringent password requirements can result in increased Help Desk requests. 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 can 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 the following Windows operating systems use reversible encryption when they store passwords:

• Windows Server 2008 R2

• Windows Server 2008

• Windows Server 2003

• Windows 2000 Server

• Windows 7 Professional

• Windows 7 Ultimate

• Windows 7 Enterprise

• Windows Vista® Business N

• Windows Vista Ultimate

• Windows Vista Enterprise

• Windows XP Professional

• Windows 2000 Professional

The Store password using reversible encryption for all users in the domain policy 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 potentially be decrypted by an attack that obtains the encrypted version and is able to find the encryption key. Also, a successful brute force attack could obtain not only a usable password (one that is able to perform authentications to the domain), but one that is identical to the actual user's password (which could give insight into the user's password selection criteria, or be usable in other systems that are sharing the same password). A knowledgeable attacker who was able to break this encryption could then log on to network resources with the compromised account.

Use of Challenge Handshake Authentication Protocol (CHAP) 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. It is also required when using Digest authentication in Internet Information Services (IIS). Both IAS and IIS support more secure methods of authentication that do not require reversible encryption. If possible, move those services to a different authentication protocol instead of enabling this policy setting.

Possible values:

• Enabled

• Disabled

• Not Defined

The default value for this policy setting is Disabled.

Vulnerability

Enabling this policy setting allows the operating system to store passwords in a format that can weaken your overall security.

Countermeasure

Disable the Store password using reversible encryption for all users in the domain policy setting.

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. Application of this policy through Group Policy on a user-by-user basis increases security risks because it requires the appropriate user account object to be opened in Active Directory Users and Computers.

Account Lockout Policy settings

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. The Windows operating system can track 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.

You can configure the account lockout policy settings in the following location within the GPMC:

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

Account lockout duration

This policy setting determines the number of minutes that a locked-out account remains locked 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 the Account lockout threshold policy setting is defined, the Account lockout duration must be greater than or equal to the value for the Reset account lockout counter after policy setting.

Possible values:

• User-defined value in minutes between 0 and 99,999

• Not Defined

This policy setting is dependent on the Account lockout threshold policy setting that is being defined, and it must be greater than or equal to the value specified for the Reset lockout counter after policy setting.

Vulnerability

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. After you configure the Account lockout threshold policy setting, the account will be locked after the specified number of failed attempts. If you configure the Account lockout duration policy setting to 0, the account remains locked until an administrator unlocks it manually.

Countermeasure

Configure the Account lockout duration policy 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 policy setting is configured to a non-zero value, automated attempts to guess account passwords are delayed for this interval before resuming attempts against a specific account. Using this policy setting in combination with the Account lockout threshold policy setting makes automated password guessing attempts more difficult.

Potential impact

Although it may seem like a good idea to configure the Account lockout duration policy setting to 0 so that accounts cannot be automatically unlocked, such a configuration can 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. A locked 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 is never locked out. When you define Account lockout threshold policy, you must also define the Reset lockout counter after and the Account lockout duration policy settings.

Failed password attempts against workstations or member servers that have been locked by pressing CTRL+ALT+DELETE or by password-protected screen savers do not count as failed logon attempts unless the Interactive logon: Require Domain Controller authentication to unlock workstation policy setting is enabled in the Security Options section of Group Policy. If it is, repeated failed password attempts to unlock the workstation count against the account lockout threshold.

Possible values:

• User-defined value between 0 and 999

• Not Defined

The default value for this policy setting is 0.

Vulnerability

Online brute force password attacks can use automated methods to try millions of password combinations for any user account. The effectiveness of such attacks can be almost eliminated if you limit the number of failed logons that can be performed.

However, a DoS attack could be performed on a domain that has an account lockout threshold configured. An 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 might be able to lock out every account without needing any special privileges or being authenticated in the network.

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 want to mitigate. The two countermeasure options are:

• Configure the Account lockout threshold policy setting to 0. This configuration ensures that accounts will not be locked out, and it prevents a DoS attack that intentionally attempts to lock out accounts. This configuration also helps reduce Help Desk calls because users cannot accidentally lock themselves out of their accounts. Because it does not prevent a brute force attack, this configuration should be chosen only if both of the following criteria are explicitly met:

  • The password policy requires all users to have complex passwords of 8 or more characters.

  • A robust audit mechanism is in place to alert administrators when a series of failed logons occur in the environment.

• Configure the Account Lockout Threshold policy setting to a sufficiently high value to provide users with the ability to accidentally mistype their password several times before the account is locked, but ensure that a brute force password attack still locks the account. A good recommendation for such a configuration is 50 invalid logon attempts, which prevents accidental account lockouts and reduces the number of Help Desk calls, but does not prevent a DoS attack.

  We recommend this option if your organization cannot implement complex password requirements and an audit policy that alerts administrators to a series of failed logon attempts. Using this type of policy must be accompanied by a good, fast process that can be implemented to unlock locked accounts when needed on weekends, at night, or during holidays to help mitigate massive lockouts caused by an attack on your systems.

Potential impact

If this policy setting is enabled, a locked-out account is not usable until it is reset by an administrator or until the account lockout duration expires. This policy 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 policy 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. If you configure this policy setting to a number greater than zero, an attacker can easily lock out any accounts for which the account name is known. This is especially dangerous considering that no privileges other than access to the network are necessary to lock the accounts.

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. This reset time must be less than or equal to the Account lockout duration policy setting configuration.

Possible values:

• User-defined number of minutes between 1 and 99,999

• Not Defined

Vulnerability

Users can accidentally lock themselves out of their accounts if they mistype their password multiple times.

Countermeasure

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

Potential impact

If you do not configure this policy setting or if the value is configured to an interval that is too long, an attacker could attempt to log on to each user's account numerous times and lock out their accounts, a DoS attack might succeed, or administrators might have to manually unlock all locked-out accounts. If you configure this policy setting to a reasonable value, users can perform new attempts to log on after a failed logon within a reasonable time, without making brute force attacks feasible at high speeds. Be sure that you notify users of the values that are used for this policy setting so that they wait for the lockout timer to expire before they call the Help Desk.

Kerberos Policy settings

The Kerberos protocol authentication 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 protocol 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 do 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 Windows server operating systems beginning with the Active Directory domain in Windows Server 2003.

You can configure the Kerberos Policy settings in the following location within the Group Policy Management Console (GPMC):

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 can slow down network access to services.

Possible values:

• Enabled

• Disabled

• Not Defined

The default value for this policy setting is Enabled.

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

Enable the Enforce user logon restrictions policy setting.

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 policy setting must be 10 minutes or greater, and it must be less than or equal to the value of the Maximum lifetime for user ticket policy setting.

If a client computer presents an expired session ticket when it requests a connection to a server, the server returns an error message and the client computer must request a new session ticket from the KDC. However, after a connection is authenticated, it does not matter whether 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.

Possible values:

• User-defined value in minutes between 0 and 99,999

• Not Defined

The default value for this policy setting is 600. If you configure this policy setting to 0, service tickets do not expire.

Vulnerability

If you configure the value for the Maximum lifetime for service ticket policy setting too high, 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 service ticket policy 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.

Possible values:

• User-defined value in hours between 0 and 99,999

• Not Defined

The default value for this policy setting is 10.

Vulnerability

If you configure the value for the Maximum lifetime for user ticket policy setting too high, 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 user tickets that were issued before their accounts were disabled. If you configure this value too low, ticket requests to the KDC may affect the performance of your KDC and present an opportunity for a DoS attack.

Countermeasure

Configure the Maximum lifetime for user ticket policy setting with a value between 4 and 10 hours.

Potential impact

Reducing this policy setting from the default value reduces the likelihood that the TGT will be used to access resources that the user does not have rights to. However, it requires more frequent requests to the KDC for TGTs on behalf of users. Most KDCs can support a value of 4 hours without too much additional burden.

Maximum lifetime for user ticket renewal

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

Possible values:

• User-defined value in minutes between 0 and 99,999

• Not Defined

The default value for this policy setting is 7.

Vulnerability

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

Countermeasure

Configure the Maximum lifetime for user ticket renewal policy setting to 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 allows between the time on the client computer's clock and the time on the domain controller in Windows Server 2003, Windows Server 2008, or Windows Server 2008 R2 that provides Kerberos protocol authentication.

Possible values:

• User-defined value in minutes between 1 and 99,999

• Not Defined

The default value for this policy setting is 5.

Vulnerability

To prevent "replay attacks," which are attacks in which an authentication credential is resubmitted by a malicious user or program to gain access to a protected resource, the Kerberos authentication protocol uses time stamps as part of its protocol definition. For time stamps to work properly, the clocks of the client computer and the domain controller need to be closely synchronized. Because the clocks of two computers are often not synchronized, administrators can use this policy to establish the maximum acceptable difference for the Kerberos protocol between the clocks on the client computer and a domain controller. If the difference between the clocks is less than the maximum time difference that is specified in this policy setting, any time stamp that is used in a session between the two computers is considered to be authentic.

Countermeasure

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

Potential impact

None. This is the default configuration.

Additional references

The following links provide additional information about topics that relate to securing domain controllers that run Windows Server 2003, Windows Server 2008, and Windows Server 2008 R2:

• Modify Security Policies in Default Domain Controllers Policy

• Best Practice Guide for Securing Windows Server Active Directory Installations