Troubleshooting account lockouts in Group Policy

While the account lockout setting in Group Policy is designed to protect systems from attackers, it can also be an inconvenience to users. Directory services expert Gary Olsen explains how to troubleshoot account lockout issues and offers tips for deciphering which problems are worth debugging.

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:

  • Account threshold -- The number of times an incorrect password will be entered in a logon attempt before the account is locked out, which prevents anyone from using that account, even with a correct password.
  • Account lockout duration -- The minimum period of time that an account must remain locked out before the account can be reset.
  • Reset account lockout after -- After the account lockout duration passes, the account is unlocked (reset). This is a convenience for users who mistakenly enter incorrect passwords, as the account is reset without administrator assistance.

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:

  • LockoutStatus.exe -- This tool displays the badPasswordCount attribute value (number of bad passwords entered) by a given user on each domain controller. Figure 1 demonstrates that the user in question is locked out and shows which DC locked the account and the badPasswordCount value on each DC. Unfortunately, you can only view one account at a time with this tool.

Figure 1

  • AcctInfo.dll -- Register this DLL on each DC. It adds an extra tab in user object properties viewed in the Active Directory Users and Computers snap-in. This has account lockout information as well as an option to force a password change to take place at the DC in the site of a user, which allows the user to apply the new password without waiting for replication.
  • ALockout.dll -- This consists of a registry key and the ALockout.dll with a ReadMe.txt. When implemented on a client experiencing the lockout problem, it creates detailed lockout information in the ALockout.txt file in the %windir%\debug directory.
  • EventCombMT.exe -- Permits searches for specific events and is useful in searching security logs to determine why a lockout has occurred. Of course, auditing should be turned on.
  • NLParse.exe -- Parses the NetLogon.log that is in the %windir%\debug directory. Verbose logging needs to be enabled (noted later in this article).
  • EnableKerbLog.vbs -- This script will enable Kerberos logging.

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:

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).

The user is logged on to more than one computer 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.

Having terminal sessions open using the domain account and then changing the password will similarly cause a lockout.

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:

  1. Determine the scope of the problem.
    • This can usually be noticed by help desk calls, where a few lockouts are normal. In fact, just by using lockout settings you are guaranteeing there will be help desk calls. If there are more than normal, however, then you'll want to troubleshoot.
    • Find out if the users are limited to a single site. This will let you focus on probably one DC.
  2. Enable auditing at the domain level for the following events:
    • Account Logon Events -- Failure
    • Account Management -- Success
    • Logon Events -- Failure

    Then you can use the EventComb utility. Configure it to (a) search all DCs, (b) select the security log, (c) select success and failure audits and (d) select event IDs 529, 539 and 644.

  3. On the PDC and on the authenticating DC of a client experiencing the lockout, enable NetLogon logging. Go to a command prompt, and type nltest /dbflag:2080ffff (assuming you have Windows support tools installed to get NLTest). The NetLogon.log file will be located in the %systemroot%\Debug\Netlogon.log. If the log file is not in that location, stop and restart the NetLogon service on that computer. (Reference KB109626 Enabling Debug Logging for the Netlogon Service.

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 OlsenGary 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.

Dig Deeper on Windows systems and network management