Repeated Kerberos Event ID 4771 pre-authentication failures for multiple users from different internal systems

Question

We are seeing repeated Kerberos pre-authentication failures (Event ID 4771, Failure Code 0x18) on our primary Domain Controller.

The events affect multiple domain users and occur from different internal client systems, including user workstations, another Domain Controller, and a proxy server.

We also observe these events outside normal working hours, when the affected users are not expected to be actively logged in.

We would like to understand what could generate these repeated Kerberos authentication failures and how we can identify the exact application, process, service, or stored credential responsible for them.

What is the recommended Microsoft troubleshooting method for identifying the source of these Event ID 4771 failures?

Answer 1

Hello,

Kerberos pre‑authentication failures with Event ID 4771 and failure code 0x18 indicate “bad password.” When you see them repeatedly across multiple users and systems, especially outside working hours, it usually means some process is attempting to use cached or stored credentials that are no longer valid. Common culprits include scheduled tasks, services running under user accounts, mapped drives, proxy authentication, or applications that cache credentials locally.

The recommended Microsoft troubleshooting method is to correlate the event details with the originating IP and logon information. In the 4771 event, check the Client Address and Account Name fields. This tells you which system is generating the failed pre‑auth. Once you know the source host, you can enable Kerberos logging on that client (HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters\LogLevel = 1) and review its System and Security logs for the process attempting authentication. On the Domain Controller side, you can also enable Netlogon debug logging (nltest /dbflag:0x2080ffff) to capture detailed authentication attempts and see which service or process is making the calls.

Another useful step is to run klist on the client to check for stale tickets, and review scheduled tasks or services configured to run under user accounts. Proxy servers are a frequent source of these failures, as they often reuse cached credentials for background connections.

I hope you've found something useful here. If it helps you get more insight into the issue, it's appreciated to accept the answer. Should you have more questions, feel free to leave a message. Have a nice day!

Domic Vo.

Answer 2

Recommended Microsoft troubleshooting method:

1. Check the Security and System logs on all three sides of the authentication flow:
   • the authenticating client
   • the target server or service
   • the domain controller
   In Event Viewer, review events from these sources in particular:
   • Kerberos
   • Key Distribution Center (KDC)
   • LSA (LsaSrv)
   • Netlogon
   On the target server, also check Security log failure audits. This establishes whether Kerberos is being used and which systems are involved.
2. Capture a network trace on both the client and the target server while reproducing the failure. Microsoft’s documented method is to use Network Monitor and start tracing on both systems.
3. Before reproducing the issue, clear cached name resolution and Kerberos tickets on both systems from an elevated Command Prompt:

      ipconfig /flushdns
      nbtstat -RR
      klist purge
      klist -li 0x3e7 purge
   

   Then reproduce the Event ID 4771 failure, stop the traces, and save them.
4. Record the Kerberos tickets generated during the test by running:

      klist tickets
   

   Save that output for later comparison.
5. Review the trace data for KerberosV5 messages and note:
   • server names
   • IP addresses
   • the SPN the client tried to access
   • whether the failure occurs during AS, TGS, or AP exchanges
   This is the key step for identifying the exact application or service path that is generating the repeated requests.
6. If the trace or logs show SPN-related errors such as KDC_ERR_S_PRINCIPAL_UNKNOWN, KDC_ERR_PRINCIPAL_NOT_UNIQUE, or KRB_AP_ERR_MODIFIED, investigate SPN configuration. Duplicate or incorrect SPNs are a common cause of Kerberos failures. For duplicate SPN detection, the documented command is:

      setspn -X
   

7. If trace data shows KRB_AP_ERR_SKEW, verify clock synchronization between the client and target server.

For repeated Event ID 4771 failures outside working hours and from multiple internal systems, the practical interpretation is that the source is often a background process rather than interactive sign-in. The likely generators are:

• a service running under a user account
• a scheduled task
• an application pool identity or other server-side process
• stored credentials on a workstation, server, or proxy

The Microsoft troubleshooting path is therefore to correlate:

• the DC’s Event ID 4771 entries
• the client and target server Security/System logs
• simultaneous network traces
• klist tickets output

That correlation identifies which host initiated the request, which SPN was requested, and which service or application path is responsible.

---

References:

• Kerberos authentication troubleshooting guidance
• How to enable Kerberos event logging
• Troubleshoot Kerberos failures in Internet Explorer
• Use a log analysis test scenario to troubleshoot Kerberos authentication