Account Policies

The policy settings under Account Policies are implemented at the domain level. A Windows Server 2003 domain must have a single password policy, account lockout policy, and Kerberos version 5 authentication protocol policy for the domain. Configuring these policy settings at any other level in Active Directory will only affect local accounts on member servers. If there are groups that require separate password policies, they should be segmented into another domain or forest, based on any additional requirements.

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 a Group Policy object (GPO)linked to the domain, which by default is the Default Domain Policy GPO. This behavior occurs even if there is a different account policy applied to the organizational unit (OU) that contains the domain controller.

By default, workstations and servers joined to a domain — the domain member computers — also receive the same account policy for their local accounts. However, local account policies for member computers can be differentiated from the domain account policy by defining an account policy for the OU that contains the member computers.

Account Policies contains three subsets:

Password Policy. These policy settings are used for domain or local user accounts. They determine settings for passwords, such as enforcement and lifetimes.

Account Lockout Policy. These policy settings are used for domain or local user accounts. They determine the circumstances and length of time that an account will be locked out of the system.

Kerberos Policy. These policy settings are used for domain user accounts. They determine Kerberos-related settings, such as ticket lifetimes and enforcement. Kerberos policy settings do not exist in local computer policy.

Account Policies policy settings can be configured in the following location in Group Policy Object Editor:

Password Policy

In Windows and many other operating systems, the most common method for authenticating a user’s identity is to use a secret passphrase or password. Securing your network environment requires that strong passwords be used by all users. This helps avoid the threat of a malicious user guessing a weak password, whether through manual methods or by using tools, to acquire the credentials of a compromised user account. This is especially true for administrative accounts. When you change a complex password regularly, it reduces the likelihood of a successful password attack. Password policy settings control the complexity and lifetime of passwords. Each specific password policy account setting is discussed in this section. Password Policy settings can be configured in the following location in Group Policy Object Editor:

Enforce password history

The Enforce password history 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 this Group Policy setting are:

A user-defined number from 0 through 24.

Not defined.

Discussion

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

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

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

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

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

Maximum password age

The Maximum password age policy setting determines the number of days that a password can be used before the system requires the user to change it.

The possible values for this Group Policy setting are:

A user-defined number of days from 0 through 999.

Not defined.

Discussion

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

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

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

Minimum password age

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

Configure this to be greater than 0 if you want the Enforce password history policy setting to be effective. If Enforce password history is set to 0, the user does not have to choose a new password. If Enforce password history is set to a number greater than zero, users must enter a new unique password when they change their password.

The possible values for this Group Policy setting are:

A user-defined number of days from 0 through 999.

Not defined.

Discussion

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

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

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

Minimum password length

The Minimum password length policy setting determines the least number of characters that can make up a password for a user account. There are many different theories about determining the best password length for an organization. One possibility is to use pass phrases rather than passwords. In Microsoft Windows 2000, Windows XP, and Windows Server 2003, pass phrases can be quite long and they can include spaces. A valid pass phrase such as “I want to drink a $5 milkshake” is considerably stronger than a ten-character string of random numbers and letters, yet is easier to remember.

The possible values for this Group Policy setting are:

A user-defined number of characters from 0 through 14.

Not defined.

Discussion

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

Set Minimum password length to at least a value of 8. If the number of characters is set to 0, no password is required. In most environments, an eight-character password is recommended because it is long enough to provide adequate security and still short enough for users to easily remember. This value will help to provide adequate defense against a brute-force attack. Adding complexity requirements will help reduce the possibility of a dictionary attack. Complexity requirements are discussed in the description of the Passwords must meet complexity requirements policy setting.

Permitting short passwords reduces security, because short passwords can be easily broken with tools that perform either dictionary or brute-force attacks against the passwords. Requiring very long passwords can result in mistyped passwords that might cause an account lockout and subsequently increase the volume of Help desk calls.

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

Passwords must meet complexity requirements

The Passwords must meet complexity requirements policy setting determines whether passwords must meet a series of guidelines that are considered important for a strong password. Enabling this policy setting requires passwords to meet the following requirements:

The password is at least six characters long.

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

English uppercase characters (from A through Z)

English lowercase characters (from a through z)

Base 10 digits (from 0 through 9)

Non-alphanumeric characters (for example: !, $, #, or %)

The password does not contain three or more characters from the user’s account name. If the account name is less than three characters long, this check is not performed because the rate at which passwords would be rejected would be too high. When checking against the user’s full name, several characters are treated as delimiters that separate the name into individual tokens: commas, periods, dashes, hyphens, underscores, spaces, number signs (#), and tab characters. Each 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. None of these checks are case-sensitive.

These complexity requirements are enforced when passwords are changed or new passwords created.

The rules that are included in the Windows Server 2003 password complexity requirements are part of Passfilt.dll and cannot be directly modified. The possible values for this Group Policy setting are:

Enabled.

Disabled.

Not defined.

Discussion

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

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

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

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

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

Store password using reversible encryption for all users in the domain

The Store password using reversible encryption for all users in the domain policy setting determines whether Windows Server 2003, Windows 2000, and Windows XP Professional store passwords by using reversible encryption.

This policy setting provides support for applications that use protocols that require knowledge of the user’s password for authentication purposes. By definition, storing encrypted passwords in a way that is reversible means that the encrypted passwords can be decrypted. A knowledgeable attacker who is able to break this encryption can then log on to network resources by using the compromised account. For this reason, never enable Store password using reversible encryption for all users in the domain unless application requirements outweigh the need to protect password information.

If you use Challenge Handshake Authentication Protocol (CHAP) authentication through remote access or Internet Authentication Service (IAS) services, you must enable this policy setting. CHAP is an authentication protocol used by Microsoft remote access and Network Connections. Digest Authentication in Internet Information Services (IIS) also requires that you enable this policy setting.

The possible values for this Group Policy setting are:

Enabled.

Disabled.

Not defined.

Discussion

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

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

Note

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

Account Lockout Policy

Someone who attempts to use more than a few unsuccessful passwords while trying to log on to your system might be a malicious user attempting to determine an account password by trial and error. Windows Server 2003 keeps track of logon attempts, and it can be configured to respond to this type of potential attack by disabling the account for a preset period of time. Account Lockout Policy settings control the threshold for this response and the actions to be taken after the threshold is reached. The Account Lockout Policy settings can be configured in the following location in Group Policy Object Editor:

Account lockout duration

The Account lockout duration policy setting determines the number of minutes a locked-out account remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If Account lockout threshold is set to a number greater than zero, Account lockout duration must be greater than or equal to the value of Reset account lockout counter after.

The possible values for this Group Policy setting are:

A user-defined number of minutes from 0 through 99,999.

Not defined.

Discussion

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

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

Account lockout threshold

The Account lockout threshold policy setting determines the number of failed logon attempts that will cause a user account to be locked out. A locked-out account cannot be used until it is reset by an administrator or until the number of minutes specified by Account lockout duration expires. You can set a value from 1 through 999 failed logon attempts, or you can specify that the account will never be locked out by setting the value to 0. If Account lockout threshold is set to a number greater than zero, Account lockout duration must be greater than or equal to the value of Reset account lockout counter after.

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

The possible values for this Group Policy setting are:

A user-defined number from 0 through 999.

Not defined.

Discussion

Brute force password attacks can be automated to try thousands or even millions of password combinations for any or all user accounts. Limiting the number of failed logons that can be performed nearly eliminates the effectiveness of such attacks.

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

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

Set Account lockout threshold to 0. This ensures that accounts will not be locked out. This setting will prevent a denial-of-service attack that intentionally locks out all or some accounts. In addition, this setting helps reduce Help desk calls because users cannot accidentally lock themselves out of their accounts.

Because it will not prevent a brute force attack, a value of 0 should only be chosen if both of the following criteria are explicitly met:

Password Policy settings force all users to have complex passwords made up of eight or more characters.

A robust auditing mechanism is in place to alert administrators when a series of failed logons are occurring in the environment.

If these criteria cannot be met, set Account lockout threshold to a high enough value that users can accidentally mistype their password several times before they are locked out of their account, but ensure that a brute-force password attack would still lock out the account. It is advisable to specify a value of 50 invalid logon attempts. Keep in mind, however, that although this setting can reduce the number of Help desk calls by reducing the number of user lockouts, it cannot prevent a denial-of-service attack.

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

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

Reset account lockout counter after

The Reset account lockout counter after policy setting determines the number of minutes that must elapse from the time a user fails to log on before the failed logon attempt counter is reset to 0 bad logon attempts. If Account lockout threshold is set to a number greater than zero, this reset time must be less than or equal to the value of Account lockout duration.

The possible values for this Group Policy setting are:

A user-defined number of minutes from 1 through 99,999.

Not defined.

Discussion

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

Kerberos Policy

In Windows Server 2003, the Kerberos version 5 authentication protocol provides the default mechanism for authentication services and the authorization data necessary for a user to access a resource and perform a task on that resource. By reducing the lifetime of Kerberos tickets, you reduce the risk of a legitimate user’s credentials’ being stolen and successfully used by an attacker; however, you increase authorization overhead. In most environments, these settings should not need to be changed. In a default installation of a Windows 2000 or Windows Server 2003 Active Directory domain, the default values of these policy settings, which are applied at the domain level, are configured in the Default Domain Policy Group Policy object (GPO). The Kerberos Policy settings can be configured in the following location in Group Policy Object Editor:

Enforce user logon restrictions

The Enforce user logon restrictions policy setting determines whether the Kerberos V5 Key Distribution Center (KDC) validates every request for a session ticket against the user rights policy of the user account. Validating each request for a session ticket is optional because the extra step takes time, and that can slow network access to services.

The possible values for this Group Policy setting are:

Enabled.

Disabled.

Not defined.

Discussion

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

Maximum lifetime for service ticket

The Maximum lifetime for service ticket policy setting determines the maximum number of minutes that a granted session ticket can be used to access a particular service. The value 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.

The possible values for this Group Policy setting are:

A user-defined number of minutes from 10 through 99,999, or 0, in which case service tickets do not expire.

Not defined.

Discussion

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

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

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

Maximum lifetime for user ticket

The Maximum lifetime for user ticket policy setting determines the maximum amount of time (in hours) that a user’s ticket-granting ticket can be used. When a user’s ticket-granting ticket expires, a new one must be requested or the existing one must be renewed.

The possible values for this Group Policy setting are:

A user-defined number of hours from 0 through 99,999.

Not defined.

Discussion

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

Maximum tolerance for computer clock synchronization

The Maximum tolerance for computer clock synchronization policy setting determines the maximum time difference (in minutes) that Kerberos V5 tolerates between the time on the client clock and the time on the domain controller running Windows Server 2003 that provides Kerberos authentication.

The possible values for this Group Policy setting are:

A user-defined number of minutes from 1 through 99,999.

Not defined.

Discussion

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

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