I had a user contact me recently with a locked out account. Casually, I unlocked it and prayed it wouldn’t become locked again. A few hours later the same user came back. So began the great lockout hunt…

Scanning the security logs on both domain controllers turned up several failed NTLM bad password events, but the source workstation field was blank. In this case, the easiest way to find the source workstation was to enable debug logging for the network logon service on each domain controller. Luckily, this is a quick  registry edit that doesn’t require a system restart (instructions here). You should be able to search this output log for the user’s account alongside a 0x06A bad password attempt. In my case, it ended up being the user’s smart phone trying to connect to our 802.1x protected wireless network with a bad/old password.

Here are a few account lockout causes that I’ve come across:

• user’s account in stored user name and passwords
• user’s account tied to persistent mapped drive
• user’s account as a service account
• user’s credentials are cached on non domain joined virtual machines in the stored username and passwords/manage credentials windows application.
• user’s account used as an IIS application pool identity
• user’s account tied to a scheduled task
• un-suspending a virtual machine after a user’s pw as changed
• A SMARTPHONE!!!

Further resources:

• Microsoft has a thorough outline of Account Lockout Best Practices along with common causes, troubleshooting steps and tools