20 thoughts on “Finding the source to something that keeps locking a domain user

  1. Manfred Strasser

    Thank you for this article, it helped me a lot. I had an issue with a Windows Phone using the wrong credentials to Access the WLAN over our NPS-Server.
    (The Domain was missing in front of the username.)

  2. Jay Montalbo

    Just had to troubleshoot this for a client that kept getting her account locked out every 5 minutes today and this article helped a lot.

    I'd like to add that, at least in my case, in the netlogon.log I was able to identify the name of the computer that was logging in with invalid credentials by searching for a SamLogon line with the %computername% entry returning a 0xC000006A error.

    Here is an example:

    SamLogon: Network logon of DOMAIN\USER-PC$ from USER-PC Entered
    SamLogon: Network logon of DOMAIN\USER-PC$ from USER-PC Returns 0xC000006A

    Hope this helps someone out in the future!

    1. newmantalent

      This is great! Thanks for pointing me in the right direction. In my case, the troubled machine also appears in the security log. However the netlogon log is a bit easier to read. Thanks again.

  3. Ash Dando

    Does anyone know if there's a way to log the actual IP address of the workstation that attempted the failed login? My problem is that there's an account that gets locked out sometimes, and Windows is logging this as coming from a computer called "System-02.local". Trouble is, we aren't using the .local domain, and I have no idea what "system-02.local" is. Surely there's a way to get Netlogon to log the IP address of the offending workstation?

    1. Jack Post author

      Hey Ash,

      If you do a nslookup system-02.local does the workstation get resolved to its IP? If Windows can resolve the DNS name in the logs, it should be able to resolve the name to an IP.

      Please let me know how it goes,

  4. Gary Bell

    We had a database process on a virtual Linux box that was causing about 30K event 680s on one of our domain controllers on a daily basis for several weeks. I couldn't even trace the host they were coming from down with Wireshark. Verbose logging to netlogon did the trick, but I'd like to add a caveat: don't leave it in verbose mode too long if you can avoid it because your netlogon.log will get HUGE very quickly. Thanks for the tip!

  5. roe

    Awesome awesome job. This makes eventcom bmt and lockoutstatus even better tools!
    a. enable logging (or repeat after step c)
    b. allow events to pool up a few minutes
    c. run lockout status on the user, pinpoint the dcs having lockout issues (enable logging at this level if you have many dcs)
    d. then use eventcomb mt for security (run as admin), check errors/warnings/failure
    e. use options to specify a time range in eventcombmt, also select your dcs
    f. in text, search their login, then begin search
    g. when done turn off via the commands above logging

    after the logs complete analyze, NOW THE IPS RESOLVE TO DEVICES AND NOT DC NAMES!! awesome, ping -a ips and get the info you need. THANKS A TON!

  6. Dennis

    Thanks for the place to look. Unfortunately, the Netlogon.log file just said the request kept coming from the Domain Controller.

    Looking in the DC Security Log for Audit Failures showed more info. Said the source address was our Barracuda Firewall. This device does use AD to authenticate people via a RADIUS server.

    Turned off AD authentication on Barracuda and rebooted it. Still same problem. Account tried 3 times then locks.

    Rebooted both RADIUS servers and problem stopped. Account back to normal!

  7. FloRod

    This post helped me find the machine causing the issue. The security logs on the DC were not providing the source.

    Thanks again!!

  8. Vin

    thank you so much for this. helped me track down the culprit when i had an account being locked out every minute.

  9. DanL

    Saved my nuts here Jack. Worthless Windows Events telling me of failed credential validation but no source workstation.

  10. Roman P

    Going to echo the comments above. Thank you for this article, saved my bacon many times !
    Again, thank you !

  11. David Z

    Thank you!!! 8 years later and this post is still helping engineers solve real-world problems.
    Searching Google for event ID 4776 is such a beat down.


Leave a Reply

Your email address will not be published. Required fields are marked *