Domain Administrator Accounts Keeps getting Locked

Does the Security Event Log on the Domain Controller potentially give any insight into this?  Normally it lists the name of the computer from which the failed logins occur.

My guess it is a service or other software set to run with the Admin account and that the credentials have been changed since the software or service was set up.

Ms has lockout tool that identifies the DC that locked tge account and eventmgmt tool that scours the event log for the event which would include the source of the auth request. Then you would need to check the system ........

Nirsoft I think has an account lockout determinant.

Have you configured the email of Administrator in any of the mobile devices? If you have Exchange, login to the exchange management console and check the administrator recipient's mobile options.

It seems somewhere you have configured the Admin account and password and later you might have changed it. That might keep your account locked.

Rgds.

Also a common cause is if your domain admin used RDP and closed a connection instead of logging off. The connection stays and if they change their password, account lockouts.

Sorry guys been MIA for a little bit. Still trying to chase down why this account locks. I run the MS Lockout utility and shows orig lock as one of our DC. Scouring the logs doesn't seem to show anything useful

The issue depending on the size of the log, and how quickly you run the event scouring tool.
528,529,530,535. 4096... Security log..

You may need to either increase the log file size, or configure event forwarders to aggregate the logs on a central server where the log file size can be set large enough to avoid the log rotating before you can find the event.
Another option to minimize space consumption is to use SNMP on the DCs with eventwin or evntcmd to configure trap events that match the preconfigured criteria to report on the login failure events while configuring the snmptrapd receiver/rsyslog to convert those events into a db entry that San be queried for source/access type. Note the log on the DC might point to a workstation/server as the source of the request, you might have to look on that devices/server's logs for those events primarily deals with services and requests from remote sources.

You can try this. I use a script from Here
 http://scriptingblog.com/2014/03/30/powershell-get-locked-out-ad-user-accounts-and-export-to-csv/

I find it to be exceptionally useful in tracking down account lockouts. I would attach the script itself but since Noam Wajnman wrote it, it is best you get it from the source. THe site describes the changes needed to make it work in your environment. We have multiple DCs and searching every Security Log is ridiculously time consuming.

still struggling with this issue. :-( Tried the tool Arnold sugesseted and the powershell script ivjeff suggested.

Are you not able to find the events in question on the DC identified as the source?
your issue might be that your security events require more space than you currently allocate such that those events roll over.

A comment such as yours has no information on which I can base any suggestion since I have no idea what the issue you are encountering using either tool.

Do you get any information from either, but unable to track down the issue. I.e. the auth came from server10, when you use eventcombmt against server10's security log looking for those same events, you find none, or the server does not have any security log entries i.e. auditing for these events is not enabled?

Hi guys so I narrowed it down to a domain controller. After using this tool.
 https://start.netwrix.com/free_tool_for_account_lockout_troubleshooting.html

There were mapped network drives that I disconnected and since then no more locks....So I am hoping that was it.

check your control keymgr.dll or credential manager to make sure you did not record a username/password to a resource such as a network drive which could explain the issue after you changed your password and those credentials are no longer valid.