Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

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

On a small network of machines (<1000) we have a user whose account is being locked out after an indeterminate interval following a password change.

We are having severe difficulties finding the source of the invalid logon attempts and I would appreciate it greatly if some of you could go through your thought process and the checks you would perform in order to fix the problem.

All I know for sure is that the account is locked out several (5+) times a day, I can't even be sure it's due to failed login attempts as there is no record of failure until the account is locked.

So far I have tried;

  • Logging the account out of everything we can think of and back in with the new password
  • Scanning the user's box for any non standard software which might perform an LDAP lookup
  • Checking all installed services on our production boxes to check none are attempting to run under the account
  • Changing the user back to their old password (Problem persists so perhaps password change is a red herring)
  • Wireshark on a box where lots of LDAP authentication is performed - Rejects only occur after account is already locked out
  • Clearing the credential cache in - Control Panel -> User Accounts -> Advanced
  • Looking at the local

I'm at a loss for what to try. I am happy to try any suggestions you have in order to diagnose the issue. I think my question boils down to a simple request;

I need a technique for deriving the source (Application/Host) of the invalid login attempts which are causing the account to be locked.

I'm not sure if that's even possible but I suspect there must be more I can try.

Many thanks,



TLDR - RSS Feed Reader configured on Client Box with old credentials caused the Continuous Build Software (Which the reader tried to log into) to lock the account as it made a failed login attempt every 5 minutes.


I looked at the logs for the key pieces of infrastructure we have, grepping for the username in question. It was clear there were a lot of failed attempts for the Continuous Build Software. It was then a case of performing a wireshark capture between the two boxes to try and work out where the requests we coming from. We killed processes until we found the right one.

Thank you all for your help, it sounds so easy now it's sorted!

share|improve this question

migrated from Mar 2 '11 at 14:58

This question came from our site for computer enthusiasts and power users.

At least yours isn't being locked out every 5 minutes... We had that problem here. The person in question finally found their credentials embedded in some VMWare monitor that made a connection attempt every minute. – Brian Knoblauch Mar 1 '11 at 20:41
up vote 0 down vote accepted

Unfortunately there are numerous circumstances where the security event log will event id 680 that look like this and the workstation name will be blank.

680,AUDIT FAILURE,Security,Fri Feb 25 14:29:37 2011,NT AUTHORITY\SYSTEM,Logon attempt by: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0    Logon account:  jdoe    Source Workstation:     Error Code: 0xC0000064    

One way to expose more information is to enable netlogon verbose logging. On a domain controller(s) where the events are recorded, create the following registry value:

Windows Registry Editor Version 5.00


Restart the netlogon service for this to take effect. The verbose information will be recorded in: %systemroot%\debug\netlogon.log and netlogon.bak. The log file rolls over and is renamed to .bak at around 19 MB. After one of the events, make a copy of the two files from the dc where the event occurred, and open them in a text editor and search for the user's name.

If you're lucky, it will have something like this:

02/12 10:54:39 [LOGON] ACMI: SamLogon: Transitive Network logon of (null)\jdoe from  (via EXCHANGE2) Entered
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: jdoe: Algorithm entered. UPN:0 Sam:1 Exp:0 Cross: 0 Root:0 DC:0
02/12 10:54:39 [LOGON] ACMI: NlPickDomainWithAccount: Username jdoe is\jdoe (found On GC)

Note that if you have multiple domain controllers, when you restart the netlogon service on one, the machine that is making the logon attempts may switch to another dc, so be prepared to enable this on more than one dc. If you have a multi-domain environment with child domains, you may have to track this from a child domain to the root domain and another child domain before the offending machine is located. The offending machine could be anything, it doesn't necessarily have to be a windows workstation. It could be a multifunction network printer/copier, or an email client that is attempting an authenticated SMTP connection with your Exchange server.

share|improve this answer
Whilst this wasn't actually the solution, this answer taught me most about the domain I was trying to understand. I appreciate your thoughtful and informative response. – CityView Mar 3 '11 at 11:25

FWIW (perhaps not much - just throwing stuff out there for you), when we had a similar problem with an AD Domain, we finally ended up using this toolset is to track down the perpetrator.

In one case, it turned out to be a training room workstation in another building that they had logged on to, but not out of, weeks ago - and that hadn't been used since.

share|improve this answer

Sounds like you have tried most everything. I would have thought the security log would have indicated the workstation that tried to connect.

Saw this with some users with Virtual Machines that had mapped a drive on physical server and then the VM would use old credentials and funally lock out the account. As the VM had been off for two password changes the users did not think to check. However, the security log gave us the computer name.

Interested in hearing a solution here

share|improve this answer
Perhaps I wasn't reading the security log correctly but I think the problem was the login failures were being proxied via the Continuous Build Server. The failures on the local box were a red herring, they were the first attempts after the account had already been locked. Thanks for taking the time to reply! – CityView Mar 3 '11 at 11:24

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.