Random AD User Account Lockout

user-account-control-icon The last few weeks we’ve had a problem with one of our IT Staff user accounts where it would regularly get locked out during the day. We suspected some of the Students were trying to guess the password for the account and were probably hoping to get around our web content filter….

This made me realise, we’ve never really looked for account lockouts and and where/why/how they might be happening on the network. I wasn’t excited about scouring the security event logs on our domain controllers to find the info I needed. A quick search brought up the Account Lockout and Management Tools from Microsoft which has been around since 2003, but was new to me. I probably should have been a bit sharper on that one.

One of the applications in the download is that LockoutStatus. This app will take the AD username and return the lockout status and bad password count on each DC for that user.

lockoutstatus

After finding the lockout status if the user you then use the EventCombMT app to search the event logs of the domain controllers. EventCombMT can search the event logs for any event ID but to find events with login issues, I limited the search to the Security logs on the DC’s with event ID’s 529 644 675 676 and 681. More info on usage here

EventComb

EventCombMT produces a text file for each server with the results of the search:

644,AUDIT SUCCESS,Security,Wed Apr 14 10:21:08 2010,NT AUTHORITY\SYSTEM,User Account Locked Out:     Target Account Name: zdjb     Caller Machine Name: STNB4200ZKLC     Caller User Name: IDM$     Caller Domain: TEACH     Caller Logon ID: (0x0,0x3E7)   

644,AUDIT SUCCESS,Security,Wed Apr 14 10:08:14 2010,NT AUTHORITY\SYSTEM,User Account Locked Out:     Target Account Name: zdjb      Caller Machine Name: STTB2710ZJLW     Caller User Name: IDM$     Caller Domain: TEACH     Caller Logon ID: (0x0,0x3E7)  

Straight away I could see the two machines that were causing the account lockout and after calling them back into the Service Desk so we could see what was going on. We were able to work out that it was the Sophos Auto Update causing the problem because these machines had been using the credentials  of this account, with an old password, for receiving updates instead of the update account we normally use.

Solving the problem of the account lockout has prompted some new strategies for monitoring the network that we hadn’t considered before. Now that we have the tools, we can regularly search the event logs for bad passwords on Administrator accounts and follow up the results. Also, we may have started the ball rolling on a project to create more user accounts in AD for different network services. It was lucky that we’d found Sophos was the culprit, but next time it could be difficult to find old credentials being used in an Altiris job for example. By creating different user accounts for services like Sophos, Altiris Jobs, SQL, Exchange and Intranet applications it will help narrow down a search next time we have a password problem and will make it easier to change these passwords on a regular basis.

2 thoughts to “Random AD User Account Lockout”

  1. Hi Greg,

    Good post bro, and yes, isn’t it cool that Microsoft’s Account Lockout Tool is so helpful.

    By the way, speaking of free AD tools, I run a community blog on Free Active Directory Reporting Tools and I thought I’d share it with you.

    Feel free to stop by and check it out – perhaps you’ll find a tool that you may not know of, or you might find that there’s a tool that I’ve yet to cover (in which case just let me know.)

    Just trying to help, so appreciate the support.

    Thanks,
    Marc

  2. I came across this little gem recently. We had a user that was getting locked just about every day. It would usually occur at logon or sometime shortly thereafter (timing was never consistent).

    We used the lockout tools to determine that the lockout was coming from a desktop that she had never used. It turned out that the user naming convention y0000000 was part of the issue. The user on the machine that was locking out the account had transposed two numbers to match the locked out user account. It had gotten cached so when the user on the lockout machine logged in the other account would get locked out. We opened the Credential Store and deleted the offending entry.

    Fun!

Comments are closed.