Server Fault is a question and answer site for system and network administrators. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In a nutshell: Is it possible to determine the specific process/exe that locks out an A/D account?

We periodically receive account lockouts for a service account in use on a Windows application server. The domain controller reports when the failed login attempts result in the lockout but does not provide any other information that would help us track back to the process that locked the account. The account cannot be used to log in locally and is only used for executing processes on that server. Having said that, this server is a hodgepodge of automated shell scripts, scheduled tasks, and services setup by in-house developers and external consultants.

I know the following:

  • Account Name
  • Originating Server
  • Time of lockout

This whole thing has been terribly frustrating because it happens almost randomly (i.e. sometimes once a day, sometimes several times a day and rarely at the same hour). Even worse, it seems like this would be something that would be simple to trap if I just knew where to look.

I am an application developer and do not have extended privileges on our domain so any solution/suggestion that can be performed without domain admin privileges is a plus.


share|improve this question

Nah, you're out of luck.

It's a horrible, horrible pain to track at the best of times, and without the ability to increase the logging level or run apps with administrative privileges (procmon and perfmon come to mind immediately), there's not a lot you can do, aside from trail and error and digging through your scripts one by one. Only thing I can think to suggest (after making sure there's not a printer or drive mapped with an old password) is to do a search through the contents of the files on the server for the username of the account in question, and hope you get lucky.

share|improve this answer

Like HopelessN00b says, you've entered a world of pain. Microsoft have realised that many of us server admin-types have had to explain to the odd auditor/manager that we can't pin something down to this level, and have tried to improve things by writing the account lockout tools (see this link). The tools do a reasonable job at examining netlogon log files. I've also knocked up a script that monitors when an account actually locks, then unlocks it. This has proved useful in the past, as it gives you a historic view, making it potentially possible to nail a particular job, etc.

share|improve this answer

You (or someone with rights) need to enable auditing of logon failure events. For classic auditing (pre-2008), the seting is Audit logon events. The advanced auditing (post-2008) setting is Logon/Logoff | Audit logon. Whichever one you use, you need to audit failure events. Then look for events 529 (pre-2008) or 4625 (post-2008). These events will point you towards the offending process.

By the way, the 529 events will not include a process name, only a process ID. In order to find more information, enable process tracking audits and look for events 592.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.