Domain user always locked out when attempting to log in. Need help to trace the source.

I would recommend using Auditing for Active Directory by Lepide Software. This is a great product for all auditing and also will tell you exactly where your machine is being locked out.

You need to make sure that you also have Auditing enabled on the default domain controllers policy as well.

http://www.lepide.com/lepideauditor/active-directory.html

Will.

You should have a clear log of logon/logoff success/failures on your domain controllers event viewer.  You could filter the security event log for failures only, then hunt down the 539 and 529 audit entries.  There, it should show a machine/host name where the failure ocurred.

choward16980,

From the screenshot, am I only checking security logs for the DCs highlighted that showed he has a bad pwd count? Or, do I check all DC's? How do I narrow it down?

Any DC in the domain should have any domain audit failure.  

EDIT:  WITHIN SITES

It appears Auditing has not been set. We have two Domain Controllers (e.g. - abc.com, and 123.abc.com). abc.com mainly stores all our users account, while 123.abc.com consist mainly of admin accounts (not to many). This user's account resides on 123.abc.com as he is an admin. It appears auditing is not set on that DC, but it is set on abc.com. So, would I still be able to trace where the account is locked out from if Auditing is not set?

I beleive logon/logoff events differ from account logon:

check here;
https://www.ultimatewindowssecurity.com/blog/default.aspx?p=26180f8b-42a6-49a2-949d-ac44494353cb

I could have sworn, by default, any failed attempts to log into a domain would reflect 529 and 539 errors.  Can another expert verify that?

Will Szymkowski,

Is Auditing for Active Directory by Lepide Software a free tool? We do not want to pay for anything at the moment just to troubleshoot this.

I'd rather save the trouble of downloading the tool, just to troubleshoot a simple user's problem. We don't get these issues enough to buy a tool. What is the best method to troubleshoot is what I am more after, so I can reference this the next time I need to.

Enabling auditing can help pinpoint the workstation or appliance sending the bad authentication requests.  Enable on both of your domain controllers for security purposes anyways.  Then, you should be able to check your security event viewer and see where the failures are being sent from.

I was right, you should just check for 529 and 539 audit failures on your abc.com domain controller security logs in the  event viewer.  Filter it by failure.  (right lick security in event viewer and click filter - check failure)

From my local secpol on my win 7 workstation:

Default values on Server editions:
  Logon: Success, Failure
  Logoff: Success
  Account Lockout: Success
  IPsec Main Mode: No Auditing
  IPsec Quick Mode: No Auditing
  IPsec Extended Mode: No Auditing
  Special Logon: Success
  Other Logon/Logoff Events: No Auditing
  Network Policy Server: Success, Failure

Actually, where I said check "Failure", it's actually uncheck "success".  My bad

Is there a something on the web that will guide me step-by-step with visuals on how to troubleshoot this?

So I found the source to where the user is locked out. Now what? He has a session on a server. Do i first unlocked his domain account, then log into the target server where he still has a session on, then disconnect or log him off the target server?

Login to the server and check to make sure that the account does not have any scheduled tasks or services running with this account. Then also log the account off of the computer and unlock the account.

Monitor the logs to ensure that no other events come up for this user.

Will.