Friday Tip: One way to track down elusive account lockouts

Here’s a Friday tech tip before you head out for the weekend.

You know how your users (and sometimes even yourself) get locked out of their accounts, and they don’t know where they logged in exactly? Going to the AD Event viewer is not always very helpful either.

You see the account name and the error message, but there is something missing – no calling computer or source computer. The only thing listed is the domain controller itself.

There are a couple different ways that you can find where account lockouts originate. The first is to go buy an expensive piece of software, but that means you’ll probably have to get procurement involved, plus the time to set it up. All sorts of hassle that you probably don’t want to deal with, which is why you just searched for a way to track down account lockouts manually.

Manually tracking down the source of account lockouts takes a little sleuthing – oh come on, you know you used to dream about being Sherlock Holmes and solving those awesome conundrums. And if you have a large number of AD servers, you may be in for some hunting.

If you were to go to the AD server the logins are being shown at, you need to follow the the steps Microsoft outlines to enable debug logging for the Netlogon service found in this document: https://docs.microsoft.com/en-us/troubleshoot/windows-client/windows-security/enable-debug-logging-netlogon-service

After enabling debugging for the Netlogon service, you need to start searching for the username in question. I used findstr (similar in function to grep).

From Windows CMD:
C:\windows\debug\findstr /i “username” netlogon.log

Running this command will show you all the instances of that username, followed by the type of login and where it is coming from.

Most likely the end of the line will show “VIA” and either a hostname or IP address.

Next step is to turn off the debug, and proceed to the machine listed above and repeat the same steps again: enable netlogon debug, search for username, find next location, disable netlogon debug, etc.

Following this process, you will eventually find the source, and it could very well be OWA/Exchange, or a VPN, or another Domain Controller

Like I said, the more AD servers you have, the longer this will take, so just settle in, grab some coffee, throw on your sleuthing cap, then follow the white rabbit errr…account lockout down the hole.