Previously, I introduced account basics and issues associated with the account lockout setting for Group Policy. In today's article, I'll describe some methods of troubleshooting account lockout.
First, a quick review. Account lockout is a security feature that allows an administrator to prevent (to a large degree) attackers from guessing passwords. It accomplishes that by implementing three account settings in Group Policy:
Another important point involves default settings. In a brand new domain, the account threshold is set at zero (0), which means that lockouts are disabled. This is important since it effectively turns off account lockout. The duration and reset settings are set as "Not Defined." Microsoft recommends a threshold setting of 10.
Unraveling account lockout issues
Typical account lockout problems usually involve an account that is inexplicably locked for no apparent reason, or when lockout parameters do not work as expected. In the latter case, there is probably a Group Policy Object application problem, and you can handle it with normal troubleshooting techniques for GPO failures. Unexpected lockouts, on the other hand, can be much more difficult and frustrating to resolve.
Microsoft has provided a set of tools for account lockout troubleshooting. The package includes the following tools:
Figure 1
[IMAGE]As I noted earlier, it is possible to have accounts locked out in what seems to be a random or unpredictable fashion -- even while the user is logged in to that account. Here are some potential reasons for this:
[IMAGE] The user has shares mapped using their domain account, then changes the domain account password. Since these shares are using the old credentials, it enters invalid passwords causing the account to be locked out. This is very easily reproducible (if lockouts are enabled).
[IMAGE] The user is logged on to more than one compute
To continue reading for free, register below or login
To read more you must become a member of SearchWindowsServer.com
r with a domain account, then changes the password on one of the machines. Again, the old credentials in the other sessions will bump up the badPwdcount and lock out the account.
[IMAGE] Having terminal sessions open using the domain account and then changing the password will similarly cause a lockout.
[IMAGE] Applications that cache the credentials or a service running under a user context can cause a lockout when the password is changed.
A lockout can affect one or two users or hundreds of users. It is important to determine the scope and see if you can isolate it to a particular client or perhaps note that the lockouts are all occurring on one DC. Here are some tips for troubleshooting:
Lockout sources: What to look for
In the event logs, look first for security attacks. If you see logons failing repeatedly for accounts like Guest, Administrator, etc., it's likely caused by an attack such as a virus. Look for accounts that are failing logons over and over. See if you can isolate the problem to a single client, then look for the things listed earlier in this article.
Use the NetLogon log and ALockout.txt files in a similar manner -- looking for the problem to be isolated to certain users, clients or DCs that are recording the lockouts. Oftentimes, removing a problem client from the domain or resetting a user account will resolve the issue.
You might also solve the problem by raising the account lockout threshold. I once saw a situation where an administrator had set the threshold to five, which is half of Microsoft's recommended value. At this value, they were getting several hundred lockouts a day.
The administrator complained that he didn't have this issue previously when using the default of zero. That's because a threshold of zero disables lockouts. So, in this case, setting it to a non-zero value just made the lockouts show up.
When he raised the threshold to 10, the lockouts dropped to about 20 per day. This emphasizes the fact that there are normal events in the environment that cause the badPasswordCount to increment. If you have the threshold set to a reasonable level, these events won't be frequent enough to lock out the account.
For a "light" security setting, Microsoft recommends setting the threshold to 50. Remember you want to set it high enough to provide reasonable protection against password crackers, while not pestering the users with locked out accounts. If you are getting a lot of lockouts with no reasonable explanation and you look at security logs and see no evidence of an attack, then raise the threshold.
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.
