No one needs to tell IT admins what’s on their short list of headaches: users forgetting their passwords usually ranks number one. For those who demand documented proof, there are survey results here to validate this point. Closely related, and just behind in terms of frequency and irritation level, are account lockouts. In an earlier and simpler era—before multiple devices—it was a straightforward matter to completely stomp this out.

Employees would call or email tech support, and they’d unlock the account in their Active Directory console and reset the password. But then came laptops, smartphones, tablets, and telecommuting— in other words, modern life as we know it. And what was once a simple solution to a common problem suddenly became far less so.

The underlying cause for most account lockouts—outside of forgetful users– is a running application or background service on one of those devices that is authenticating with stale credentials based on an old password.

How Do I Authenticate Thee, Let Me Count the Ways

How many different ways can this happen? Microsoft has an entire TechNet article on lockout troubleshooting, and their list includes, for starters, these variations on the theme:

  • Persistent drive mappings
  • Scheduled tasks
  • Terminal server sessions
  • Service accounts
  • Any programs that store user names and passwords

And if you factor in all the new computing devices, admins have more places to look for the offending process. As a purely practical matter, it means that to pinpoint the culprit, IT will have to carefully review audit logs, often across multiple domains.

Lockout Policy Might Be an Answer but…

I can practically hear the IT admin community collectively saying something like, “the real solution to all this is to have an intelligent lockout policy”. One school of thought recommends that the admin go into the default GPO for the domain and change the appropriate lockout parameters to a more reasonable setting.

The “account lockout threshold” setting should be shifted to a much higher number than three—perhaps 20 or 30—so that you, or more to the point, a hacker really has to be hammering at the account to trigger a lockout. “account lockout duration”, the time to wait before the account is automatically unlocked, set to a more sensible ten minutes (instead of, say, 12 hours), and different from the default of zero, which is a permanent lockout. And finally, the tricky “reset account lockout policy after” defaut set to one minute. You can read more about this approach here.

After receiving wise counsel from a few Varonis SEs, I learned that changing the default Active Directory lockout parameters can help. But tread carefully here, there are assumptions about the overall strength of employee passwords that have to be first proved out. According to the SEs, if you have a robust password policy in place, then it might make sense to ramp up the “account lockout threshold”, otherwise this may not fly. There is also a good case to be made that this threshold parameter should always be zero, and users forced to ultimately deal with support to unfreeze their accounts.

Finding the Stale App

However, to get to the bottom of the lockout problem caused by computers and devices using stored credentials, admins and tech support staff must first find the offending app or service. And that means they’ll have to search the event logs of the affected domains—either manually (not recommended), with a third-party app, or Microsoft’s own LockoutStatus.exe.

AD lockout event includes computer name or IP address of device.
AD lockout event includes computer name or IP address.

The particular event they’re looking for is Event ID 4771 on Server 2008 or Event ID 529 on Server 2003. When they view this Account Lockout event, they should see the client computer name or else the device’s IP address (see the screenshot).

For Windows OS, at least for Windows 7 and beyond, the admin remotely logs onto the client’s machine and brings up the Credential Manager to remove the old credentials. Very likely this was the user’s secondary computer, and after a password change was made on the more frequently used computer, the other machine continued to run services that forced the “account lockout threshold” to be crossed.

And if the Lockout event points to an IP address?

Then the admin will have to look up the MAC address from another device on the local network segment in question, and then the mac address vendor—using, for example http://www.macvendorlookup.com—to learn the device type. Ninety nine times out of a hundred the app on the IOS or Android gadget that was sending out the bad credentials is an Exchange email client—e.g., ActiveSync. The locked out user will then need to update the password to refresh the credentials and bring everything back in sync.

Andy Green

Andy Green

Andy blogs about data privacy and security regulations. He also loves writing about malware threats and what it means for IT security.