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.

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:WindowsSystem32services.exe

I found this old question while researching a different issue, but for anyone with a similar issue:

The failure code 0x18 means that the account was already disabled or locked out when the client attempted to authenticate.

You need to find the same Event ID with failure code 0x24, which will identify the failed login attempts that caused the account to lock out. (This assumes it is occurring because of a bad cached password somewhere.)

You can then look at the Client Address on those events to see which system is passing the bad credentials. From there, you'd have to figure out if it's a service with an old password, a mapped network drive, etc.

There are a variety of failure codes, so you should look for anything besides 0x18 to determine what caused the account lockout if there are no events with 0x24 codes. I believe the only type of failure that will lead to a lockout is 0x24 (bad password), but I could be wrong.

This is from above notes. Looks like the initiator of this post stated on his last comment. Java calling vpxd.exe process.

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).

I've spend a lot of time today and find out the root cause. I went wrong way - from captured info with network sniffer (kerberos error process id was 566 = lsass.exe). Let me summarize information.

1. Log on to problem PC, run powershell with elevated rights



2. 
   

   Enable audit logon

   
   
   

   auditpol /set /subcategory:"logon" /failure:enable

   
   


3. 
   

   Check the source

   
   
   

   Get-WinEvent -Logname 'Security' -FilterXPath "*[System[EventID=4625]]" -MaxEvents 2 | fl

   
   

If you see:

Process Information:

Caller Process ID: 0x140

Caller Process Name: C:WindowsSystem32services.exe

It means that you have some service running from problem account with old password

Kerberos 0x18 is indeed a bad password attempt.

Kerberos 0x12 is account disabled, expired, locked out, or logon hours restriction.

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4771