Lesson 1: Understanding Account Policies | MCSA/MCSE Self-Paced Training Kit (Exam 70-214): Implementing and Administering Security in a Microsoft Windows 2000 Network (Pro-Certification)

Lesson 1: Understanding Account Policies

Account policies are Group Policy settings stored in GPOs that affect all user accounts. They control operating system features such as the maximum number of logon attempts, automatic enforcement of high-quality passwords, and the lifetime of Kerberos tickets.

After this lesson, you will be able to

Understand account policies
Manage account policy settings for a domain
Determine which account policy settings are appropriate for your network

Estimated lesson time: 20 minutes

Applying Account Policies

Account policies do not apply to individual accounts, they apply to all accounts, and their enforcement begins before a user logs on. This means that account policies apply to the Computer Configuration portion of a GPO rather than to the User Configuration portion. Account policies are located in the Computer Configuration\Windows Settings\Security Settings\Account Policies node of a GPO.

Only one account policy is valid per domain, so only account policy settings in GPOs linked to domain objects have effect on user accounts within the domain. Domain account policies automatically override account policy settings linked to organizational units (OUs). However, if a user does not log on to the domain, the OU account policy that applies to the computer the user logs on to locally remains valid. This means that

Users who log on locally to a computer that has a security account within an OU will have the account policy restrictions located in the GPO linked to that OU.
Users who log on to the domain will have the account policy restrictions linked to a domain GPO.

You can use this difference to change the account policy that is applied for users who log on using a local user account.

What Are the Account Policy Settings?

An account policy is comprised of several settings. The following sections explain each setting's purpose and detail its effect on your overall security posture.

Enforce Password History

Enforce Password History allows you to keep users from rotating among a small set of preferred passwords when they are forced to change them. A user who attempts to reuse a password that is stored in the password history will be forced to choose another password.

Keep a relatively long password history of at least 10 previously used passwords to prevent users from recycling a few favorite passwords.

Maximum Password Age

Maximum Password Age identifies the length of time that a user can use a specific password before being required to change it. Traditional security policy has held that forcing users to change passwords often keeps others from learning their passwords and exploiting them.

Unfortunately, the requirement that users change passwords often leads users to select shorter, simpler passwords that are easier to remember. Users also frequently select simple variations of the same password, such as a single word followed by a different set of numbers. Anyone knowing the user might still have a relatively easy time determining the user's password.

Since the advent of the Internet, the true security threat has changed from coworker shenanigans to very serious intrusions by Internet hackers. Hackers usually don't know the end users or passwords on your system. Instead, they use very large dictionary files containing all words from the major world languages, common names and surnames, slang terms, and words appearing in the religious texts of the major world religions just about every word that most people know.

It is imperative that users select long and mostly random passwords that are somewhat difficult to remember.

Because it's more difficult for users to remember highly secure passwords, use somewhat less restrictive change times. Users should not be expected to memorize long and highly random passwords routinely. For this reason, many administrators either no longer enforce password changes or set them to very long durations such as one year. Be sure to accompany relaxing password age enforcement with a dramatic increase in minimum password length and the enforcement of complexity requirements to ensure security.

Minimum Password Age

Minimum Password Age identifies the length of time that a user must use a newly assigned password before changing it. This prevents hackers from obtaining a password and then changing it to something else to secure it for their own use.

The Minimum Password Age setting has the least effect of any setting on your overall security posture. The type of attack it prevents is extremely rare and very easy to detect. Most installations will not require an enforcement of minimum password age.

Minimum Password Length

Minimum Password Length identifies the shortest allowable length of a password. While simple, this setting has more impact on security posture than any other account policy setting.

Each character in a password makes the password about a hundred times harder to guess. A 1-character password can be guessed in about 80 attempts because there are about 80 characters that can appear in passwords. A 2-character password requires 8080 (or 6400) attempts. At one guess per second, that's the difference between about one minute and about two hours.

If you create passwords for international users, remember that their keyboards can't always create the same set of punctuation and other special characters as yours. For example, the number sign (#) does not appear on keyboards in Spanish-speaking countries.

If you work in a multinational environment, restrict the punctuation you use in passwords to symbols that are internationally valid. Better yet, delegate administration to regional administrators in the target country if possible. Using localized punctuation is not particularly effective for thwarting foreign hackers, because these hackers use password lists and brute-force software that generate all possible punctuation.

Prior to the wide accessibility of the Internet, a password of 8 characters or longer was considered secure. After all, at one attempt per second, a truly random password of this length would require over a billion years to guess. Unfortunately, users don't often select truly random passwords they select normal words and names they use every day. So, while in theory an 8-character password would be secure, a hacker could try out every word in the dictionary, or first and last names appearing in the telephone book of 8 or more characters in less than one day.

Hackers can use automated tools for password guessing that randomize their computer's name and IP address. A server can't reject multiple attempts coming from these hackers because they don't appear to be coming from the same computer. Exploiting this fact, automated tools have been created that can check up to 1200 passwords per second against a Windows 2000 server. In one hour, hackers can run well over 4 million passwords against a well-connected server attached to the Internet. When you consider that an extremely large vocabulary for a single language is just 25,000 words, hackers now have the capability to check every word that has ever been published on the Internet in any language in just one hour. What this means in practical terms is that hackers can now find words plus punctuation and two- and three-word combined passwords within a reasonable time. However, a truly random 8-character password would still require more than 40,000 years to crack even at this speed.

In practice, because users don't select truly random passwords, you should consider using no fewer than 12 characters as your minimum password length. Windows 2000 allows passwords up to 256 characters in length, but some code remains in the operating system that makes it difficult to use passwords longer than the Microsoft Windows NT limit of 14 characters. With a 12-letter minimum, users will naturally select multi-word passwords, and with complexity requirements enforced, these passwords take an extremely long time to crack.

Passwords Must Meet Complexity Requirements

With this setting enabled, all users must use complex passwords. This setting ensures that passwords will not appear in the dictionary-based password lists that hackers use. Select this option to force each user to create passwords that are not equal to any part of the user's name and must contain characters from three out of four of these classes:

Uppercase letters
Lowercase letters
Numbers
Punctuation and other special characters

This setting is mandatory for any secure network. Enabling this setting and forcing users to select new passwords will increase the security of your network more than any other single measure.

After exploiting system "bugs," exploiting low password quality is the second most likely way that hackers will get into your network. Unlike exploiting bugs, taking advantage of low password quality has always worked and will always work against some networks, so hackers routinely attempt it.

On networks with lockout policies, hackers don't try 10,000 passwords against one account; they try 10,000 accounts against one password. This ensures that no single account sees more than one logon attempt within a reasonable period, and it prevents audit measures from logging extremely high logon rates against individual accounts. The larger your network is, the more effective this sort of attack becomes.

The second most common password after "1234" is "123456," and on networks that require a minimum of 8 characters, "asdfasdf" is equally as common. On average, out of 10,000 accounts on a network that does not enforce complex password use, more than 100 accounts will have these trivial passwords. This fact almost guarantees hackers access to your network if you have a large number of accounts and you don't enforce password complexity.

Store Password Using Reversible Encryption for All Users in the Domain

Store Password Using Reversible Encryption For All Users In The Domain is a setting that weakens security to allow third-party client computers such as Apple Macintosh clients to authenticate in the domain.

Do not enable this setting unless you must for compatibility reasons. This setting makes it easier for hackers to use network analysis equipment to listen for (sniff) passwords on your network if they can gain physical access to it.

Account Lockout Duration

Account Lockout Duration identifies the amount of time that an account will remain disabled once the system has detected that the Account Lockout Threshold has been reached.

To keep high-speed automated logon attempts from working against your network, you must have this setting configured. However, to thwart high-speed logon attempts, the account lockout duration does not need to be particularly long. When hackers run dictionary attacks, they rely on logon rates faster than one per second to break into a system in a reasonable time. Any setting greater than five minutes will make an automated logon attempt take so long that it would not be worth perpetrating. Settings longer than 15 minutes are unusually burdensome for users and unnecessary to achieve the security goals of this policy setting.

The local and domain administrator account cannot be locked out, no matter how many times its password has been incorrectly entered. This is also the account that hackers want to access, so it is typically the only account they try. To remain secure, you must rename the administrator account. Don't use "root," "admin," or "supervisor" as a synonym, because these account names are routinely tried as well.

Account Lockout Threshold

Account Lockout Threshold indicates the number of times that a user can enter an incorrect password before being locked out. This setting is used to thwart high-speed logon attempts, so it is not necessary to set it to a low number. Many facilities use three, five, or seven attempts as a baseline for the number of times a user can incorrectly type a password. Fewer than four attempts is burdensome for users who must switch passwords regularly or who use different passwords frequently. More than 10 are more attempts than most valid users would make before giving up in frustration, so seven is probably a good compromise. Any reasonably low number will defeat automated logon attacks.

Reset Account Lockout Counter After

Reset Account Lockout Counter After indicates the duration before an attempt at logging on is considered separate from an earlier attempt. This value should be set to a value that is similar to your Account Lockout Duration so that users need only remember one timing value if they are having password problems.

Enforce User Logon Restrictions

Enforce User Logon Restrictions causes domain controllers to validate every request for a session ticket by examining the user rights policy on the target server to verify that the user has the right to log on through the network. This means that the Kerberos Key Distribution Center (KDC) service must go over the network to contact the target server, request its policy, and examine it.

In larger networks, enabling this restriction can cause unnecessary logon traffic if you do not deny users network access to servers.

The security effects of disabling this restriction are esoteric. If the user has a valid Kerberos session ticket, the user is logged on to the network. Unless you are in a network environment where internal network security is paramount, such as at a medical center or military installation, the effect of this setting on your security posture will be minimal.

Maximum Lifetime for Service Ticket

Maximum Lifetime For Service Ticket specifies how long session tickets are valid. This setting must be no less than 10 minutes and no more than the value specified in the Maximum Lifetime For User Ticket setting.

If normal working hours at your facility routinely exceed 10 hours (the default), change both of these values to encompass normal working hours. This will eliminate spurious logon activity when Ticket Granting Ticket (TGT) and session tickets expire. As long as these settings are less than 24 hours, you won't have to worry about ticket replay attacks.

Maximum Lifetime for User Ticket

Maximum Lifetime For User Ticket specifies the maximum lifetime for both TGT and session tickets, although the Maximum Lifetime For Service Ticket setting can further reduce the lifetime of individual session tickets.

Maximum Lifetime for User Ticket Renewal

This setting specifies the maximum time that a TGT or session ticket can be continuously renewed without requiring a physical logon. The default is seven days, which is more than long enough for most purposes.

The only real issue you might encounter that would require changing this setting is the use of user-mode software in a logged on session that runs continuously, such as IBM Lotus Notes. Software that runs in user mode should be either configured as a service using the Srvany.exe service wrapper from the Microsoft Windows 2000 Server Resource Kit or replaced with software that can be run as a service so that a user account doesn't need to remain logged on to run it.

Maximum Tolerance for Computer Clock Synchronization

Maximum Tolerance For Computer Clock Synchronization specifies the granularity of time-based encryption for session tickets. This setting allows you to increase the tolerance for time variances between servers. The default value for all Kerberos installations is five minutes. This means that a session ticket retrieved from a TGT must be used within this period to be valid. When the time settings on servers vary by more than this amount, session tickets will not be valid on them, and users will have no access to resources on those servers.

Normally, session tickets are used immediately so that session ticket expiration is not an issue. But it is an issue if the server being accessed doesn't have the same time set as the TGT, because the difference in time settings could easily be more than five minutes.

The disadvantage of increasing the Maximum Tolerance For Computer Clock Synchronization is that it increases the period of time during which a forged session ticket could be used. If hackers were able to decrypt a session ticket while it was still valid, they could forge the contents of the ticket and then use it to gain access to the server for which the session ticket was created. By keeping this setting short, you make this attack impossible.

Time synchronization is critical to the proper operation of Kerberos. By default, computers in a domain automatically synchronize with domain controllers. Domain controllers should be set to synchronize with an Internet time server such as time.windows.com or tock.usno.navy.mil to maintain synchrony with other domains. You can set a server's Simple Network Time Protocol (SNTP) time source by entering the following command in a command prompt and then restarting the Windows Time service:

net time /setsntp:time.windows.com

The clock synchronization tolerance setting directly affects the duration for which a session ticket can be replayed and should not be modified without good reason. Rather than changing the clock synchronization setting, set all domain controllers to synchronize daily with an atomic clock time source on the Internet, or at least with a single authoritative time server on your network.

Practice: Configuring Account Policies

To meet the threat of automated password guessing attempts, Fabrikam, Inc. has established the following account policy guidelines:

User accounts will be locked out after seven failed attempts to log on, and will remain locked out for 15 minutes.
Passwords must be complex, at least 12 characters in length, and consisting of no single words. While they need not be changed often, they should not be reused.

In this practice, you implement these acceptable use guidelines as domain-wide Group Policy settings.

To define account policies

Click Start, point to Programs, point to Administrative Tools, and click Active Directory Users And Computers.

The Active Directory Users And Computers management console appears.
Right-click domain.fabrikam.com, and click Properties.

The domain.fabrikam.com Properties dialog box appears.
Click the Group Policy tab.
Double-click Domain Security Policy.

The Group Policies management console appears with the Domain Security Policy GPO opened.
Expand Computer Configuration, Windows Settings, Security Settings, and then Account Policies.
Select Password Policy to view the settings, as shown in Figure 3.1.

Figure 3-1. The Password Policy settings
Double-click Enforce Password History. The Security Policy Setting dialog box appears, as shown in Figure 3.2.

Figure 3-2. The Security Policy Setting dialog box
Select the Define This Policy Setting check box, and click OK to accept the default of 18 days.
Double-click Maximum Password Age. The Security Policy Setting dialog box appears.
Select the Define This Policy Setting check box, type 356, and click OK.
If a dialog box appears recommending changes to other policy settings, click OK to accept the recommended changes.
Double-click the Minimum Password Length setting. The Security Policy Setting dialog box appears.
Select the Define This Policy check box, and type 12.
Click OK to accept the changes, and close the dialog box.
Double-click Passwords Must Meet Complexity Requirements. The Security Policy Settings dialog box appears.
Select the Define This Policy Setting check box, and click OK.

To define account lockout policies

In the Group Policies management console, click Account Lockout Policy to view the settings, as shown in Figure 3.3.

Figure 3-3. Account Lockout Policy settings
Double-click Account Lockout Duration. The Security Policy Setting dialog box appears.
Select the Define This Policy Setting check box, type 15, and click OK.
If a dialog box appears recommending changes to other policy settings, click OK to accept recommended changes to other settings.
Double-click Account Lockout Threshold. The Security Policy Setting dialog box appears.
Change the setting to 7 invalid logon attempts, and click OK to close the dialog box.
Close the Group Policies management console.
Click OK to close the domain.fabrikam.com Properties dialog box.
Close the Active Directory Users And Computers management console.

Lesson Review

The following questions are intended to reinforce key information in this lesson. If you are unable to answer a question, review the lesson and try the question again. Answers to the questions can be found in the appendix.

How many logon attempts can hackers perpetrate against a Windows 2000 server in one hour?
What is the shortest recommended length for a password for a network connected to the Internet?
What is the default maximum time difference between a client and a server before Kerberos tickets can no longer be decrypted?

Lesson Summary

The threat of automated password-guessing attacks from Internet-based hackers has risen dramatically since the rise of the Internet. To counter this threat, much stronger passwords are required than have been used traditionally.
Windows 2000 account policy allows administrators to define domain-wide account policies to enforce password complexity and length requirements.
Account lockout durations can be established to thwart high-speed logon guessing attacks.
The administrator account cannot be locked out and should be renamed to prevent it from being exploited.
Kerberos requires strict time synchronization to avoid ticket replay attacks. For this reason, all domain controllers should be time synchronized to a trusted Internet time source.