Windows Server 2003 on HP ProLiant Servers : Security Planning and Design (part 2) - Account Lockout

Account Security

Account security consists of password policy, account lockout policy, and Kerberos policy. You can implement account security by applying Group Policies. Just as in Windows 2000, you can apply account security only at the domain level in Windows Server 2003. This is a very important concept. These settings are located under Computer Configuration\Windows Settings\Security Settings\Account Policies and include password policy, account lockout policy, and Kerberos policy settings. This means that settings in any of these areas apply to objects only if they are applied in a GPO at the domain level. They cannot be applied at the GPO level. This means, for instance, that if you have a corporate password policy that defines the minimum password length as eight characters, you must define that in a GPO that is applied at the domain level. Further, if you have a multiple domain structure, it must be defined at the domain level for each domain. Note also that you can define these settings in GPOs that are applied at the OU level, but they will never take effect.

For instance, if you define a GPO called Security at the domain level and define the minimum password length to be eight characters, and an OU Administrator creates a GPO called OUSecurity and defines the minimum password length to be five characters, the effective setting for the users will be eight characters, even without setting the No Override option.

Security settings follow the same rules as other settings if multiple GPOs are at the domain level that defines security. These GPOs are listed in the Group Policy Editor in a list, as shown in Figure 1. The GPOs are processed bottom to top in the list. Thus, the GPO at the top of the list has highest priority because it follows the last writer wins rule. In the example in Figure 1, if the Administrators policy has password length set to ten, the accounting policy has it set to eight, and the default domain policy has it set to five, the effective policy will be five because the default domain policy is highest in the list and it's the last one processed (it overrides the others due to the last writer wins operation).

Account Security and DCs

One of the most important things for you to note in GPO design is that DCs just act differently when applying security. A good example is a customer who complained that he had defined the account security settings in the default domain policy at the domain level to have a minimum password length of 6 and retain a history of 15 passwords. However, when his users tried to change their passwords, they get a notification that passwords must be 10 characters and it retains a history of 6 passwords. We looked at the local security database (sdb) on a test client and it indicated the effective setting was a length of 6 and history of 15. We ran GPResult from an XP client (GPResult is built-in to 2003 and XP), and it indicated that the applied security settings were 6 and 15. Yet when we attempted to change the password, we got a message saying the settings were 10 and 6. We then discovered that logging in to the client with a local account allowed us to change to a 6-character password. Logging in to a domain account gave us the other settings of 10 and 6. We eventually discovered that the client had blocked inheritance on the DCs OU because it didn't want their desktop lockdown policies to apply to DCs. Because DCs get their security settings from the domain GPO like everyone else, this blocked them from getting the correct security settings of password length = 6 and history =15. Prior to setting the block inheritance option, the security policy had settings defining password length = 10 and history = 6. Those settings were written into the local sdb of each DC. Because that is the only security the DCs could see and the DCs actually apply their security to clients they authenticate, the clients were getting the DC's version of security, rather than what was defined at the domain level.

The important points here are to understand this scenario that shows how DCs determine security policy, and remember to not set the block inheritance option at the DC's OU.

Account Lockout

Perhaps one of the most frustrating issues in Windows 2000 Security is that of account lockout. Account lockout is a security feature that permits the Admin to have an account locked out (deny login privileges) when a bad password has been attempted for a certain number of tries. Although intended to prevent hackers from easily guessing account names and passwords, it becomes a big help desk issue for legitimate users who get locked out, typically during a password change operation. The issue is complicated by replication latency between the DC that the help desk technician changes the password on and the DC that authenticates the user.

Account lockout became such a huge issue at Compaq prior to the HP merger that scripts were run nightly to reset accounts and others were developed to be triggered by the user selecting an option in an automated phone message.

Microsoft made the claim at the release of Windows 2000 SP3 that the account lockout issue was solved, but it's still a problem area. Not to say anything is particularly broken or a bug that should be fixed, but it's a problem Administrators have to deal with. It is important to understand this issue and develop account lockout strategies accordingly.

Account lockout is implemented as a security policy at the domain level or for local user accounts. Three settings comprise account lockout policy, as shown in Figure 2:

• Account Lockout Threshold: The number of failed logon attempts (range 0 to 99,999) before the user account is locked out. The lower the number, the more secure you are from hackers guessing the password; however, low numbers also increase calls to the help desk. Microsoft recommends 10, which makes account lockout a little more tolerant. After an account is locked out, it cannot be used until reset by an Administrator or until the Lockout Duration period has expired. A value of 0 prevents the account from being locked out.

• Reset Account Lockout Counter: The number of minutes (range 1 to 99,999) after a failed logon attempt before the failed logon attempt counter is reset to 0. A lower number here makes it less secure, but makes the user wait longer to reset the password without calling the help desk to have the account reset. If the Account Lockout Threshold is defined, the reset counter value must be less than or equal to the Account Lockout Duration value.

• Account Lockout Duration: The number of minutes (range 0 to 99,999) that an account remains locked out before it is reset and becomes unlocked. A setting of 0 causes the account to remain locked out until manually reset by an Administrator.

Figure 2. Account Lockout Policy settings in the GPO.

In addition, features are built in that prevent you from defining settings that are incompatible with these rules. For example, in Company.com, I configured the Account Lockout Duration to 60 minutes. A pop-up message, shown in Figure 3, informed me that the Account Lockout Threshold and Account Lockout Duration would be changed to 5 attempts and 30 minutes, respectively.

Microsoft doesn't go out of its way to tell you that resources, such as shares or interactive sessions on multiple computers using those credentials, cause account lockout policy to be such a problem. For instance, if you are logged in with a single account to a Terminal Server session on a server in the lab with an interactive logon to your laptop and have a VPN connection from home, and you change your password from your laptop without logging the other sessions off, your account soon will be locked out. This has never been an issue in Windows NT 4.0 domains, so what's so new in AD that could cause this issue? Kerberos. When users log on from Kerberos-capable clients (Windows 2000 and greater) and authenticate against an AD domain, the Kerberos protocol is used instead of the NTLM protocol (as was the case in Windows NT 4.0). However, to tighten security in the Windows world, the Kerberos credentials expire after a defined period of time (maximum lifetime for a user or Ticket Granting Ticket is ten hours by default), which causes a machine to re-evaluate a user's credentials over time against an AD DC (Kerberos Distribution Center). If the password has been changed without logging on and off, the credential validation takes place with the old password and thus soon locks out the account.

In addition, having shares mapped using those credentials will have the same effect. Most likely, in our network, if I change my password and haven't logged off all sessions and disconnected all shares using that account, it will be locked out within about 15 minutes. Before changing my password, I have to go through all my home network computers, lab servers, laptop, and desktop to make sure I'm logged off from all Terminal Server, Remote Desktop, and interactive sessions, as well as to make sure all the shares are disconnected. Once it took me three days to find all the sessions I had going, because I tend to not log out of the lab machines to save time when testing.

Let's follow a couple of scenarios to see how this works. Consider the configuration shown in Figure 4. User Nancy in San Jose forgets her password. The incorrect password is attempted at the authenticating DC in San Jose, SJC-DC3. Because the password is incorrect, the password request is sent to the PDC Emulator, ATL-DC1, in case the password was changed and this DC isn't aware of it. This fails and Nancy gets the invalid username or password error. She tries five times, at which time her account is locked out by the PDC by setting the lockoutTime on the user account, and SJC-DC3 locks it out as well. The PDC now replicates the lockoutTime to all DCs, informing them of when the account was locked out so they can make the comparison for the Account Lockout Duration time.

Figure 4. Scenario for account lockout after password change.

Nancy could wait for the Account Lockout Duration period of three hours to expire before trying again or she could call the help desk to have it reset. However, suppose Nancy has to drive to San Francisco for a meeting. She connects to the company network and attempts to log in again two hours after the account was locked out. Here, the authenticating DC is SFO-DC8, which hasn't had the lockout message replicated yet. It refers the request to the PDC and the client gets the account lockout message.

Now Nancy calls the help desk technician who resets the password and then expires the password, forcing Nancy to change it again when she logs in. The Admin, however, is in Atlanta and he resets the password on ATL-DC1. The account reset is replicated urgently, but the password change is not. Before replication makes it to SFO-DC8, Nancy tries the new password. The request is passed to the PDC who authenticates it, but SFO-DC8 prompts Nancy to change the password. Because SFO-DC8 doesn't know about the password set by the Admin, it gives Nancy a failure and she might retry it until it locks out again. To prevent this, the Admin can change the password on the user's local DC, in this case, SFO-DC8.

Microsoft created a couple of tools that help in this matter. One, the acctinfo.dll, registered on each DC, provides the Additional Account Info tab in the user account attributes dialog box, as shown in Figure 5. Note the Set PW on Site DC button at the lower left of the dialog box. Assuming the subnet/site mapping is correct, this will force the change to take place initially on a DC in the user's site. Note that Site Affinity is a function of the workstation, so the reset takes place at the site where the user's workstation exists. In the previous example, Nancy's normal “home” site is San Jose, but because she uses DHCP, when she connects to the network in San Francisco, her laptop's Site Affinity is San Francisco so the authentication is to SFO-DC8.

Another scenario could be that Nancy successfully changes her password, but forgets that she has several drives mapped to shares using the old credentials and the account is locked out. She calls the help desk; they reset the account and password. Nancy logs in, changes the password, and awhile later the account is locked out. Nancy sees the account is locked out when she tries to use Outlook, map a new share, or perform any other operation requiring her to specify credentials. The message that the account is locked out is a clear indication of the problem. Nancy would have to make sure all drive mappings are disconnected and all Terminal Server and interactive logon sessions are logged off—except the one used to change the password.

Another tool Microsoft has provided is the LockoutStatus.exe utility. Figure 6 shows the features of this tool. Note that it identifies each user, the account's locked status, the bad password count, and so on. This gives you the ability to monitor the account lockout status. You also can see in the figure that the user's current password settings are displayed. This user is in a test domain with a password that doesn't expire, which is why the numbers in this example, such as current password age, are so high.

Figure 6. The LockoutStatus tool monitors the current status of bad password count and other parameters for managing account lockout.