Tracking Source of Account Lockout

Hi folks!

Got about 120 Windows XP Professional SP3 workstations running in a Windows Server 2003 R2 x64-based Active Directory environment.

A few days ago, started having a particular user account -- an administrator account -- that is getting repeatedly locked out. Unlock it, wait a few minutes, locked out again.

My best guesses are that either someone is trying a brute force attack to compromise it (unlikely) or that there's a scheduled task laying around the network somewhere that's repeatedly trying to access it using an old password (likely).

Can someone suggest a way to track where the failed login attempts, and ultimately lockouts, are coming from?

Thanks,
Ithizar
IthizarAsked:
Who is Participating?
 
IthizarConnect With a Mentor Author Commented:
Found the answer! And, boy, was it obscure.

In the advanced DHCP properties of the server in question, it was set to authenticate using that user name. And apparently failing. I updated the credentials and the problem went away.

Now, why that had worked forever and then suddenly stopped working a few days before I posted my question, I have no idea. But there's the solution.

Thanks to everyone for your help!
0
 
Alan HardistyConnect With a Mentor Co-OwnerCommented:
Check your Security Event Logs and filter by Failure Audit - that should show the invalid login attempts.

Look down those entries and look at the source IP and the Processor ID being used.  Then fire up Task Manager (CTRL + SHIFT + ESC) and on the Processes Tab, add the PID column and then look for the Process ID.

If it is System - do you have Exchange on your server?

Check your firewall - do you have RDP (TCP Port 3389) open and forwarded to the server from all Remote IP Addresses?
0
 
BCipolloneConnect With a Mentor Commented:
Please read this to help solve your issue: http://technet.microsoft.com/en-us/library/cc776964(WS.10).aspx
0
Has Powershell sent you back into the Stone Age?

If managing Active Directory using Windows Powershell® is making you feel like you stepped back in time, you are not alone.  For nearly 20 years, AD admins around the world have used one tool for day-to-day AD management: Hyena. Discover why.

 
Mike KlineCommented:
Take a look at this blog entry

http://blogs.technet.com/b/instan/archive/2009/09/01/troubleshooting-account-lockout-the-pss-way.aspx

They have links to the account lockout and management tools.  The network traces can also be useful.  I'm with you it is most likely going to be a scheduled task or service that is using an old password.

Thanks

Mike
0
 
IthizarAuthor Commented:
Hmm.

I've checked the security logs on our domain controller, and what I'm seeing are dozens and dozens of entries for this user name where it says "pre-authentication failed" and it lists the IP address as the loopback address (127.0.0.1). Those are the only errors involving this user name that I can find. But there are tons of them, occurring every few seconds.

I'm posting the complete error details below.

Any thoughts?

Thanks,
Ithizar

Error Details:
Event Type:      Failure Audit
Event Source:      Security
Event Category:      Account Logon
Event ID:      675
Date:            3/22/2011
Time:            11:03:57 AM
User:            NT AUTHORITY\SYSTEM
Computer:      CHTNSDC01
Description:
Pre-authentication failed:
       User Name:      tpinkerton
       User ID:            CHTN\tpinkerton
       Service Name:      krbtgt/CHTN
       Pre-Authentication Type:      0x2
       Failure Code:      0x12
       Client Address:      127.0.0.1
0
 
IthizarAuthor Commented:
Accepting my own solution, but awarding points to those who helped point me toward the solution.
0
 
BCipolloneCommented:
Probably a password policy in place caused the problem. Do your passwords expire? - Anyway glad you found the problem.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.