Perhaps the most confusing of all Group Policy settings are those involving account lockouts. Even Microsoft documentation isn't clear on it, and troubleshooting problems where accounts are inappropriately locked out is never easy.
The idea behind the Account Lockout tool is to foil viruses and would-be hackers or other attackers who try to steal valid domain accounts by guessing account passwords. The settings, defined in GPOs, make it more difficult for this to happen. The down side is that there are circumstances that cause lockouts for valid users doing valid work, generating help desk calls.
The trick is to define these settings to provide reasonable protection against password crackers, but not be an annoyance to users.
There are three account lockout settings -- account lockout threshold, account lockout duration and reset account lockout counter after. Account lockout threshold is the most important setting. This sets up the number of bad passwords that can be entered during authentication before the account is locked out. For example, if you set it to five, then on the sixth bad password, the account will lock out. This requires an administrator to unlock it so the account can be used again.
The duration setting is the minimum amount of time that an account must remain in a locked out state before it can be unlocked and used again. The reset setting specifies a period of time. When it passes, the account becomes unlocked automatically.
There are some rules about using these values. For instance, if you set the duration setting to 30 minutes, then the reset setting must be at least 30 minutes to avoid a conflict. The good news is that when you set any of these three values, a pop-up will appear and propose values for the other settings (I always accept those values).
Note: The default values for these settings are defined in Chapter 2, Table 2.2, of Microsoft's Windows XP Security Guide.
Microsoft's table, shown here, shows the default values as well as recommendations for two different scenarios.
Table 2.2: Account lockout policy setting recommendations
| Setting |
Domain controller |
Default EC |
SSLF |
| Account lockout duration |
Not defined |
15 minutes |
15 minutes |
| Account lockout threshold |
0 invalid logon attempts |
50 invalid logon attempts |
10 invalid logon attempts |
| Reset account lockout counter after |
Not defined |
15 minutes |
15 minutes |
The "Domain controller default" column shows the settings for a brand new domain. These settings are defined in the default domain policy initially, but can be defined in any policy. The EC (Enterprise Client) and SSLF (Specialized Security Limited Functionality) column are Microsoft's recommendations for low and high security, respectively.
WARNING: Account policies (including account lockout) must be applied to Group Policy Objects at the domain level to affect domain users. Applying them in a GPO at the OU level will only apply the settings to local users.
In the table we see that the default threshold is defined as zero (0) invalid attempts. According to the Windows XP Security Guide, this means that locked out accounts will remain locked until unlocked by an administrator (which means the automatic reset won't work). But how many bad passwords does that allow? In Figure 1, I edited a GPO and set the value to zero. Note that it states that account lockouts are disabled.
Figure 1
Just to test this out, I created an account, set the account lockout threshold to 0 and tried logging in and entering bad passwords. Microsoft's LockoutStatus tool, shown in Figure 2, shows 55 bad password attempts, but the account is still not locked out, and that means lockouts are indeed disabled. Therefore, by default, you have no lockout security. If lockouts are turned off, the duration and reset values are irrelevant.
Note: Windows XP's default threshold value is "Not Defined." But, in a domain, the domain policies will overwrite the local policy.
Figure 2
To validate the default settings, I built a new domain on a virtual machine. Figure 3 shows the default values.
Figure 3
Note: In this configuration, getting a GPResult report for an account shows the "Lockout Bad count" (the account lockout threshold) equal to "N/A." Duration and the reset settings don't show up. If you set it to another number, however, all settings will be displayed in GPResult.
Example:
GPO: Default Domain Policy
Policy: LockoutBadCount
Computer Setting: N/A
When bad passwords are entered for an account, the badPwdCount attribute will be incremented on the authenticating DC and the PDC, since domain controllers always contact the PDC in case of a bad password. This prevents a hacker from hitting an account on several DCs, since badPwdCount is not replicated.
We know, of course, that entering bad passwords during logon can lock out the account. But there are a number of different things that can lock out accounts even while the user is logged in. In these cases, "something" holds the old credentials then tries to reuse them for authentication.
These possibilities include:
Being logged into multiple machines (or terminal server sessions) with an account and then changing the password of that account.
Connecting to shares with the old credentials, then changing the password.
Applications may cache credentials and use the old password.
Services running under that user context may use the old password.
Of course an actual virus or malicious attack will lock out the account.
Microsoft recommends a minimum value of 10 for an account lockout threshold. Setting it at a small value could cause lockouts under normal circumstances, thus generating a lot of annoying help desk calls.
But you want to be safe, too. A threshold of 10 is low enough to give you good protection from attackers, yet high enough to filter out the bogus lockouts.
To make sure a client isn't being attacked, enable auditing for:
Account Logon Events - Failure
Account Management - Success
Logon Events - Failure
Search the security logs on the client machine for events 529, 539 and 644. Look for many attempts in a short period of time or failed logon attempts for administrator or guest accounts. A large number of logon failures using several accounts is a good indication of an attack. Talk to the user and find out if he did this. If you don't see any hacker evidence, then you can probably raise the threshold and make the users' lives easier.
There are some tools we can use to monitor and troubleshoot account lockout, and I will describe those along with other troubleshooting methods in an upcoming article.
Gary Olsen is a systems software engineer for Hewlett-Packard in Global Solutions Engineering. He authored Windows 2000: Active Directory Design and Deployment and co-authored Windows Server 2003 on HP ProLiant Servers. Gary is a Microsoft MVP for Directory Services and formerly for Windows File Systems.
|
Rate this Tip
|
To rate tips, you must be a member of SearchWinIT.com.
Register now
to start rating these tips. Log in if you are already a member.
|
DISCLAIMER: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.
|
|
