Today, I had the lovely experience in trying to troubleshoot why a users account was locking out of the domain every 30 seconds. Inside of event viewer, I could see the account failing to login, but I had the most generic, useless, log to help track down what was going on.
The computer attempted to validate the credentials for an account.
Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0
Logon Account: username
Source Workstation:
Error Code: 0xc000006a
Scrolling through my logs, the only other thing I was was the error code switching from from a 0xc000006a to a 0xc000234. Even though this is beyond the scope of this document, here are what those codes mean:
0xc000006a - An invalid attempt to login has been made by the following user.
0xc0000234 - The user account has been automatically locked because too many invalid logon attempts or password change attempts have been requested.
Anyways, after scrolling through event viewer on my domain controllers, trying LockoutStatus.exe, and asking the user to power off their mobile devices, workstations, etc, in a desperate act, the error still peristed. Finally I came across the holy grail of Microsoft articles: http://support.microsoft.com/kb/109626/en-us
Solution: We had to put the domain controller in verbose logging for the netlogon service to actually find out where the logon attempt was coming from.
First, open up command prompt as an administrator and execute the following command:
nltest /dbflag:0x2080ffff
Once done, execute the following command to turn off the debugging:
nltest /dbflag:0x0
This logs every transaction made to the file: %windir%\debug\netlogon.log (note, you need to run notepad as an administrator to read this file).
Inside of there, find the logon attempt made by the user and it should list the workstation it came from. In this case, the logon attempt was coming from our NPS server, which then was coming from an old laptop he had logged into and left alone for a few months.
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.)
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!
Appreciate the response Jay! 🙂
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.
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?
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,
Jack
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!
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!
Hey Roe,
How did you manage to log the ip address? I'm running on Server 2012 AD.
Your post was very helpful. I will try this next time to troubleshoot on my DC.
Thanks a lot for this one. Very useful and hard to find this trick...
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!
This post helped me find the machine causing the issue. The security logs on the DC were not providing the source.
Thanks again!!
thank you so much for this. helped me track down the culprit when i had an account being locked out every minute.
Thanks, it helped me.
Great article, I used it to trace down a brute force from a trusted domain.
Saved my nuts here Jack. Worthless Windows Events telling me of failed credential validation but no source workstation.
Going to echo the comments above. Thank you for this article, saved my bacon many times !
Again, thank you !
Thanks
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.