Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1590
  • Last Modified:

Help with account lockout issue (very strange)

I'm pretty well versed on tracking down account lockouts in a windows domain.  In fact I'm tracing such an issue several times a week as we have a pretty strict password policy that forces users to change pw every 42 days.  However I've run across such an issue that I cannot seem to narrow down.

I have a user, a server administrator, whos account locks every night at 10 PM.  I cannot for the life of me track where the bad passwords are coming from.

I make extensive use of the MS Account Lockout tools, but eventcomb is not being any help.

I've narrowed the problem down to several Event ID 680 events (attached as code snippet).  It would seem these are NTLM authentication attempts, however the problem is no source workstation is listed!  This is what I usually go by to find the culprit machine.

If I have no machine listed to investigate, how can I possibly track this down?  Are there any tools that I can set up scheduled captures of login information?  Is there some additional logging I can configure to better trap this failed logon attempt?  The DC event logs are just no help here.

Event Type:	Failure Audit
Event Source:	Security
Event Category:	Account Logon 
Event ID:	680
Date:		12/21/2009
Time:		10:00:33 PM
Computer:	NOAMIND01DCX01
 Logon account:	MyUserName
 Source Workstation:	
 Error Code:	0xC000006A

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

Open in new window

1 Solution
NikSystems SpecialistCommented:
Hi Mathew,

I have the similar issues in our domain and I can surely suggest that you try to use Account Lockout Examiner tool which can track from which machine/service/scheduled task etc, bad password attempts are coming from.
There's a 20 day evaluation period which should be enough for you to find the problematic machine:
The other question to go through is 'What happens at 10PM?". Backup jobs executing, overnight script processing, etc.? Maybe this can help identify which host is causing the lockout.
MMcDonaldAuthor Commented:
Thanks for the suggestion.  I'm looking into it now.

This is of course one of the first questions I ask as an enterprise administrator.  Unfortunately there's no easy answer there.  We have over 500 servers in the environment in countries all over the world.  There are different backup schedules running at any given site (some backups run all throughout the night).  It could very well be a script/scheduled task, but the problem is identifying *where* they are running.  We can usually track this down by the data the event logs provide.  In this case, there is no information to go on in the event logs.

The only thing I have right now, is the lockout seems to always happen on a DC in a particular site.  That should help me narrow it down, but I still have a hundred or more servers in this site alone as it is a core hub site for the entire enterprise.  Many satellite sites utilize this core site for various services, i.e. domain authentication, so that ups the complexity.
Concerto Cloud for Software Providers & ISVs

Can Concerto Cloud Services help you focus on evolving your application offerings, while delivering the best cloud experience to your customers? From DevOps to revenue models and customer support, the answer is yes!

Learn how Concerto can help you.

MMcDonaldAuthor Commented:
Well, I tried the NetWrix Account Lockout Examiner tool that was suggested and that was a bust.  It basically tells me the same thing I've already found in the event logs:  The account was locked.

It fails to list the workstation that actually sent the bad passwords!!  This information is not being logged, at all.

I'm stumped on where to go from here.
How about something off the domain? PDA, Smart Phone, web service, etc.? I'm thinking these access attempts would fail to record a source workstation.
MMcDonaldAuthor Commented:
I guess that's possible, but it seems unlikely.  A PDA contacts a server somewhere (be it OWA, or some other web service).  That server is what handles the authentication and the DC logs should reflect the authentication request coming from that server.

The domain is supposed to log all authentication attempts and where they come from.  That seems like a pretty big security risk, and a complete waste of auditing if there are ways to circumvent the recording of authentication requests.
did you enabled  debug logging for the Net Logon service on the domain controller  NOAMIND01DCX01?
MMcDonaldAuthor Commented:
Actually yes, after not getting anywhere, I did indeed turn on debug logging for the Net Logon Service.  That did get me farther than I were as I could see the bad logons were being passed transitively from another DC (why the event log didn't log this kind of information is beyond me).

Ultimately it lead me to a particular DC, but the netlogon logs for that particular DC didn't show *anything*.  It was as if that DC itself was sending the bad lockout information.

Ultimately just by stroke of luck, my admin (who was getting locked) stumbled upon the culprit.  It turns out it was his account being tied to our Tripwire monitoring.  He saw logon errors in some SQL logs while parsing them.

Featured Post

What does it mean to be "Always On"?

Is your cloud always on? With an Always On cloud you won't have to worry about downtime for maintenance or software application code updates, ensuring that your bottom line isn't affected.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now