Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

We have a domain account that is being locked out via 1 of 2 servers. The built-in auditing only tells us that much (locked out from SERVER1, SERVER2).

The account gets locked out within 5 minutes, about 1 request per minute it seems.

I initially tried to run procmon (from sysinternals) to see if any new PROCESS START were being spawned after I unlock the account. Nothing suspicious comes up. After running procmon on my workstation and elevating to a UAC shell (conscent.exe) it seems like from the stack that ntdll.dll and rpct4.dll get called when you try to auth against AD (not sure).

Is there anyway to narrow down which process is causing an authentication request to our DC? It's always the same DC so we know it must be a server out in that site. I could try looking for the calls in wireshark, but I'm not sure that would narrow down which process is actually triggering it.

No services, drive mappings, or scheduled tasks are using that domain account either -- so it must be something that has the domain creds stored. There are no open RDP sessions with that domain account either on any server (we checked).

Further notes

Yes, "Success/Failure" Logon Audits are enabled on the DC in question -- no failure events are logged until the account is actually locked out.

Further digging shows that LSASS.exe makes a KERBEROS call to the DC in question once the account is unlocked. It's preceded (generally) by java which seems to be called by vpxd.exe which is a vCenter process. BUT, when I look at the other "server2" were the account lockout can (also) happen from, I never see a call to lsass.exe and only apache processes are being spawned. The only relation the two have are that SERVER2 is part of SERVER1's vSphere cluster (server1 being a vSphere OS).

Error on DC

So, it seems all I'm going to be told by AD is that it's a pre-auth Kerberos error. I checked and there were no tickets with klist and did a flush anyways just in case. Still have no idea what is causing this kerberos error.

Index              : 202500597
EntryType          : FailureAudit
InstanceId         : 4771
Message            : Kerberos pre-authentication failed.

                     Account Information:
                         Security ID:        S-1-5-21-3381590919-2827822839-3002869273-5848
                         Account Name:        USER

                     Service Information:
                         Service Name:        krbtgt/DOMAIN

                     Network Information:
                         Client Address:        ::ffff:x.x.x.x
                         Client Port:        61450

                     Additional Information:
                         Ticket Options:        0x40810010
                         Failure Code:        0x18
                         Pre-Authentication Type:    2

                     Certificate Information:
                         Certificate Issuer Name:
                         Certificate Serial Number:
                         Certificate Thumbprint:

                     Certificate information is only provided if a certificate was used for pre-authentication.

                     Pre-authentication types, ticket options and failure codes are defined in RFC 4120.

                     If the ticket was malformed or damaged during transit and could not be decrypted, then many fields
                      in this event might not be present.
share|improve this question
add comment

1 Answer

Logon events record the process attempting logon. Enable failed logon auditing (Security Settings > Local Policies > Audit Policy > Audit Logon Events) in the Local Security Policy (secpol.msc) then look in the security event log for an event. You can also enable it via Group Policy, if that would be preferable.

There will be a Process Information section which records both the executable path and process ID.

Example:

Process Information:
    Process ID:         0x2a4
    Process Name:       C:\Windows\System32\services.exe
share|improve this answer
    
It seems this was already in our GPOs. I can see when the object gets modified/unlocked in the security log, but I do not see bad attempts after that. –  Jai Kang Aug 8 '13 at 17:10
    
@JaiKang, unless the servers in question are DCs, they would not be affected by the "Audit Failed Logons" setting in the Default Domain Controllers Policy. The failed logon event would be logged by the server attempting the authentication and would be set by the "Default Domain Policy" or another computer policy applying to that server. –  Mitch Aug 8 '13 at 17:35
    
I actually figured it out. I had to set some settings in the "Advanced" section of Audit settings. I updated my original post with the events. –  Jai Kang Aug 8 '13 at 20:37
    
@JaiKang, pre-authentication is just the process used to verify credentials prior to returning a token. There should still be a failure audit on the server attempting authentication which includes the process id. –  Mitch Aug 8 '13 at 22:06
add comment

Your Answer

 
discard

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.