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