Account Policies
Applies To: Windows Server 2008
This section of this 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
Account Lockout Policy
Kerberos Policy
A single Windows Server 2008 domain can have one of each of these policies. If these policies are set at any other level below the domain level in the Active Directory® directory service, they affect only local accounts on member servers.
The Account Policies settings in Group Policy are all 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 Windows®-based computer that is a member of the domain.
Note
Each domain can have only one Account Policies setting. The Default Domain Policy is the policy that is enforced by the domain controllers in the domain by default. The Account Policies setting must either 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. These domain-wide Account Policies settings (Password Policy, Account Lockout Policy, and Kerberos Policy) are enforced by the domain controllers in the domain. Therefore, domain controllers always retrieve the values of these Account Policies settings from the Default Domain Policy GPO.
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 (ones that have at least 10 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.
Windows Server® 2008 supports 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 Windows® 2000 and Windows Server® 2003 Active Directory® domains, 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 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 to use fine-grained password policies. Fine-grained password policies cannot be applied to an organizational unit (OU) directly.
To apply 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 setting.
You can configure the password policy settings in the following location by using the Group Policy Management Console 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 setting is 24. On stand-alone servers the default value for this 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 setting, users might repeatedly change their passwords until they can reuse their original password.
Note
After an account has been compromised, a simple password reset might not be enough to restrict a malicious user because the malicious user might have modified the user's environment so that the password is changed back to a known value automatically at a certain time. If an account has been compromised, it is best to delete the account and assign the user a new account after all affected systems have been restored to normal operations and verified that they are no longer compromised.
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, you should also configure effective values for the Minimum password age and Maximum password age settings.
Potential impact
The major impact of configuring the Enforce password history 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 make them easier to guess. Also, an excessively low value for the Maximum password age 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 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 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 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.
Countermeasure
Configure the Maximum password age setting to a value that is suitable for your organization's business requirements.
Potential 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 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 setting to make this setting effective. If you configure the Enforce password history 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 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 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 but do not configure the Minimum password age 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 setting to be effective.
Countermeasure
Configure the Minimum password age setting to a value of at least 1 day, which is the default for domain controllers. Users should know about this limitation and contact the help desk if they need to change their password during that 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. Starting with Microsoft Windows 2000, 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. Assuming a computer performing a brute force attack that can attempt 10,000,000 character combinations a second, the amount of time that it would take to discover a password for a user account is as follows:
| 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 |
Note
With a computer that could perform a brute force attack at a rate of 1,000,000,000 character combinations per second, it would take 83.5 days to discover an eight-symbol password that includes a combination of uppercase and lowercase letters, digits, symbols, and punctuation.
Possible values:
User-specified number between 0 and 14
Not Defined
The default value for this 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 setting to a value of 12 or more. If the number of characters is set to 0, no password will be required.
In most environments, we recommend a 12-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 setting in addition to the Minimum password length setting helps reduce the possibility of a dictionary attack.
Note
Some jurisdictions have established legal requirements for password length as part of establishing computer security regulations.
Potential impact
Requirements for extremely long passwords can actually decrease the security of an organization because users might leave the information in an unsecured location or lose it. If very long passwords are required, mistyped passwords could cause account lockouts and increase the volume of help desk calls. If your organization has issues with forgotten passwords due to password length requirements, consider teaching your users about passphrases, which are often easier to remember and, due to the larger number of character combinations, much harder to discover.
Note
Older versions of Windows such as Microsoft Windows 98 and Microsoft Windows NT® 4.0 do not support passwords that are longer than 14 characters. Computers that run these older operating systems are 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 is enabled, passwords must meet the following minimum requirements when they are changed or created:
Passwords must not contain the user's entire samAccountName (Account Name) value or entire displayName (Full Name) value. Both checks are not case sensitive:
The samAccountName is checked in its entirety only to determine whether it is part of the password. If the samAccountName is less than three characters long, this check is skipped.
The displayName is parsed for delimiters: commas, periods, dashes or hyphens, underscores, spaces, pound signs, and tabs. If any of these delimiters are found, the displayName is split and all parsed sections (tokens) are confirmed not to be included in the password. Tokens that are less than three characters in length are ignored, and substrings of the tokens are not checked. For example, the name "Erin M. Hagens" is split into three tokens: "Erin," "M," and "Hagens." Because the second token is only one character long, it is ignored. Therefore, this user could not have a password that included either "erin" or "hagens" as a substring anywhere in the password.
Passwords must contain characters from three of the following five categories:
Uppercase characters of European languages (A through Z, with diacritic marks, Greek and Cyrillic characters)
Lowercase characters of European languages (a through z, sharp-s, with diacritic marks, Greek and Cyrillic characters)
Base 10 digits (0 through 9)
Nonalphanumeric characters: ~!@#$%^&*_-+=`|\(){}[]:;"'<>,.?/
Any Unicode character that is categorized as an alphabetic character but is not uppercase or lowercase. This includes Unicode characters from Asian languages.
Note
A given character can satisfy only one category. The GetStringTypeW API (https://go.microsoft.com/fwlink/?LinkId=205607) is used to test whether each character in the password is uppercase, lowercase, or alphanumeric.
For specific instructions about how to configure password policy settings, see Apply or modify password policy (https://go.microsoft.com/fwlink/?LinkID=68014).
For more information, see:
Strong Passwords (https://go.microsoft.com/fwlink/?LinkID=34295)
Password Best practices (https://go.microsoft.com/fwlink/?LinkId=120395)
Apply or modify password policy (https://go.microsoft.com/fwlink/?LinkID=68014)
Security Configuration Manager Tools (https://go.microsoft.com/fwlink/?LinkId=120396)
The rules that are included in the Windows Server 2008 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 (https://go.microsoft.com/fwlink/?LinkId=100432).
Possible values:
Enabled
Disabled
Not Defined
By default this 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 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 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.
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 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 Windows Server 2008, Windows Vista, 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 potentially be decrypted by an attacker that gets hold of 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 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.
Warning
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. 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 setting.
Possible values:
Enabled
Disabled
Not Defined
The default value for this 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 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. 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.
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 Group Policy Management Console:
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 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 the Account lockout threshold setting is defined, the Account lockout duration must be greater than or equal to the value for the Reset account lockout counter after setting.
Possible values:
User-defined value in minutes between 0 and 99,999
Not Defined
This policy setting is dependent upon the Account lockout threshold setting being defined and must be greater than or equal to the value specified for the Reset lockout counter after 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 setting, the account will be locked out after the specified number of failed attempts. If you configure the Account lockout duration setting to 0, the account remains locked out until an administrator unlocks it manually.
Countermeasure
Configure the Account lockout duration setting to 15 minutes. 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 nonzero value, automated attempts to guess account passwords are delayed for this interval before resuming attempts against a specific account. Using this setting in combination with the Account lockout threshold 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 zero 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 an Account lockout threshold, you must also define the Reset lockout counter after and the Account lockout duration settings.
Failed password attempts against workstations or member servers that have been locked by either pressing CTRL+ALT+DELETE or 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 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 even being authenticated in the network.
Note
Offline password attacks are not countered by this setting.
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 setting to 0. This configuration ensures that accounts will not be locked out and will prevent 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 12 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 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 10 invalid logon attempts, which prevents accidental account lockouts and reduce 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 to unlock locked accounts that can be implemented whenever 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 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 discover passwords with a brute force password attack might go undetected if a robust audit mechanism is not in place. If you configure this 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 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 setting to 15.
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 used for this policy setting so that they wait for the lockout timer to expire before they call the help desk.
Kerberos Policy settings
In Windows Server 2003 with Service Pack 1 (SP1) and later, 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 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 a Windows Server 2008 or Windows Server 2003 Active Directory domain.
You can configure the Kerberos policy settings in the following location within the Group Policy Management Console:
Computer Configuration\Windows Settings\Security Settings\Account Policies\Kerberos Policy
Note
In Windows Vista and Windows Server 2008 Kerberos settings also can be specified in the Local Group Policy Editor. Any setting specified there is superseded by domain policy settings.
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 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 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 setting must be 10 minutes or greater, and less than or equal to the value 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 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 10 and 99,999. If you configure this policy setting to 0, service tickets do not expire.
Not Defined.
The default value for this setting is 600.
Vulnerability
If you configure the value for the Maximum lifetime for service ticket 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 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 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 setting is 10.
Vulnerability
If you configure the value for the Maximum lifetime for user ticket 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 setting with a value between 4 and 10 hours.
Potential impact
Reducing this setting from the default value of 10 hours 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 four 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 setting is 7.
Vulnerability
If the value for the Maximum lifetime for user ticket renewal setting is too high, users might be able to renew very old user tickets.
Countermeasure
Configure the Maximum lifetime for user ticket renewal 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 that provides Kerberos authentication.
Possible values:
User-defined value in minutes between 1 and 99,999
Not Defined
The default value for this setting is 5.
Note
This setting is not persistent. If you configure this setting and then restart the computer, this setting reverts to the default value.
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 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 to Kerberos between a client clock and a domain controller clock. If the difference between the client clock and the domain controller clock is less than the maximum time difference specified in this 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 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: