"Account locked out" security event at midnight

Question

The last three midnights I've gotten an Event ID 539 in the log...about my own account:

Event Type: Failure Audit
Event Source:   Security
Event Category: Logon/Logoff 
Event ID:   539
Date:       2010-04-26
Time:       12:00:20 AM
User:       NT AUTHORITY\SYSTEM
Computer:   SERVERNAME
Description:
Logon Failure:
    Reason:     Account locked out
    User Name:  MyUser
    Domain: MYDOMAIN
    Logon Type: 3
    Logon Process:  NtLmSsp 
    Authentication Package: NTLM
    Workstation Name:   SERVERNAME
    Caller User Name:   -
    Caller Domain:  -
    Caller Logon ID:    -
    Caller Process ID: -
    Transited Services: -
    Source Network Address: -
    Source Port:    -

It's always within a half minute of midnight. There are no login attempts before it. Right after it (in the same second) there's a success audit entry:

Logon attempt using explicit credentials:
 Logged on user:
    User Name:  SERVERNAME$
    Domain:     MYDOMAIN
    Logon ID:       (0x0,0x3E7)
    Logon GUID: -
 User whose credentials were used:
    Target User Name:   MyUser
    Target Domain:  MYDOMAIN
    Target Logon GUID: -

 Target Server Name:    servername.mydomain.lan
 Target Server Info:    servername.mydomain.lan
 Caller Process ID: 2724
 Source Network Address:    -
 Source Port:   -

The process ID was the same on all three of them, so I looked it up, and right now at least it maps to TCP/IP Services (Microsoft).

I don't believe I changed any policies or anything on Friday. How should I interpret this?

Solution 1

Do you have a schedule task that runs under your account that connects to a share at midnight? Event ID 552 (the second event) is usually generated when a user (in this case the system) uses runas to run a process as another account.

However- upon a closer look, the Logon ID: (0x0,0x3E7)- shows that a service is the one doing the impersonation. Take a closer look at the services on the machine. You can also get this if another machine is mapping a drive with your credentials and the saved credentials have expired. Since the service was tcpip that's where I'm betting my nickel on now.

Solution 2

Account lockouts can be a pain to troubleshoot. My first reccomendation would be to get the Account Lockout Tools from Microsoft.

Using these tools you can figure out which of your DC's are actually locking out the account. From there you'll need to do some snooping in the security log to figure out which server is causing the lockout to happen, then you can figure out what on that server is locking your account.

Solution 3

It's likely an automated event, like a service running under your credentials. Hop on the server and sort services.msc by the Logon As field and see if you're in there.

Comments

[sipher_z]

Thanks, but, I did as you said, and I'm not listed. I stopped running services under my account ever since I discovered that when you do that, things break when you change your password.

[gravyface]

+1 forgot about these tools.

[sipher_z]

So, the tools only help you determine the DC? I can already tell you it's "SERVERNAME" above, since we only have the one DC right now. I guess my question then is, what does it look like to "figure out what on that server is locking your account"? I have no scheduled tasks at midnight and there's nothing going on in the log immediately before or after these events.

[Satanicpuppy]

If you check the originating DC, you can see the machine in it's event log.

[sipher_z]

This is the event log on the originating DC...there's only one DC, and it is the only machine referred to in these log entries.

[sipher_z]

No, nothing. I looked in the properties of every scheduled task just now, and the only ones that run under my account are the two Google updaters that come with Chrome, and they run at 28 minutes past the hour. (Sorry, I should've mentioned that. Thanks for bringing it up.)

[sipher_z]

I did have to enter some credentials recently on other machines. Would this still happen even if they weren't running? Because normally nothing is running at night except for the DC.

[raja]

the account lockout tools only work on 2003 R2 and below (well in particular acctinfo.dll dies under vista+ - the rest should work but I'm not sure that netlogon.log has the same events in 2008)

[raja]

No a machine that's turned off can't generate events, maybe one is waking up from a sleep state to run somethign unrelated (like a defrag?)

[sipher_z]

Hmm...no clients have night jobs like that that I know of. I'll keep an eye out tonight to see if something gets left on. Thanks for the lead!

[sipher_z]

On 2003 R1 here. I'm still not clear on whether I should bother with the tools. If they only help determine the offending DC, and I already know that information, is there any point to installing them?

[Zypher]

@Kev: I would install them and have them available, yes they are more effective in a multi DC environment, but there are a lot of good tools in there to troubleshoot lockouts - check out the event comber application it might help you here.

[sipher_z]

The event comber didn't seem to help--I can already see the only three instances of this event ID, because they're the only failure audit entries.

[sipher_z]

Aloinfo.exe didn't tell me anything I didn't know...searching the output of aloinfo /stored for my username just showed it on the Google Updater tasks.

[sipher_z]

I installed acctinfo.dll and can see the extra page in AD Users and Computers, but again, it doesn't seem to provide any clues as to the cause.

[sipher_z]

BTW, now that I think of it, when I supplied manual credentials on a client, they didn't allow me access, for some reason. But there don't seem to be any events related to that, and I certainly wasn't doing that at midnight.

[Zypher]

@Kev: There should be a zip called Alockout.zip included with the tools, if you install this dll, and reboot the box you will get a much more detailed log of what is causing the lockout.

[sipher_z]

I glossed that one since it wasn't on the help page. Oops! Thanks, I'll give that a shot tonight.