Kerberos Pre-Authentication Failed – Event ID 4771 (0x18) for all domain users

Question

Kerberos Pre-Authentication Failed – Event ID 4771 (0x18) for all domain users

MS 0

Hello,

At one of our clients, we are experiencing repeated Kerberos Pre-Authentication Failed – Event ID 4771, with Failure Code 0x18, on the primary Domain Controller.

The issue affects all domain users. All users are able to log in manually without any issues using their credentials. The Event ID 4771 failures are generated in the background and do not prevent normal interactive logon. The events are generated repeatedly even when users are not actively attempting to log in, including outside normal working hours.

From the Event ID 4771 entries, we can see authentication attempts originating from different internal systems, including user workstations, the secondary Domain Controller, and the proxy server.

As part of the troubleshooting, we performed:

klist purge

for one of the affected users in order to clear the Kerberos ticket cache.

The cache was cleared successfully, but after monitoring the environment again, Event ID 4771 continued to be generated and the issue remained unchanged.

We would appreciate your assistance in identifying the root cause of these repeated Kerberos pre-authentication failures and advising us on the recommended next troubleshooting steps.

Thank you.

0 comments

2 answers

Your answer

Answer 1

For repeated Event ID 4771 Kerberos pre-authentication failures across many users and from multiple internal systems, the supported next step is to treat this as a broader Kerberos infrastructure issue instead of a single-user ticket-cache issue.

Since clearing one user’s Kerberos cache did not change the behavior, continue with a domain-wide check in this order:

Review logs on all involved systems Use Event Viewer to check the Security and System logs on:
- the affected client computers
- the target servers generating the requests
- both domain controllers
Focus on events from these sources:
- Kerberos
- Key Distribution Center (KDC)
- LSA (LsaSrv)
- Netlogon
On target servers, also check the Security log for failure audits.
Correlate the source systems from the 4771 events Because the failures are coming from workstations, the secondary DC, and the proxy server, isolate which systems are continuously submitting Kerberos requests outside business hours. That pattern points to background services, scheduled activity, or server-to-server authentication rather than interactive sign-in.
Check domain controller availability On affected systems, run:
```
   nltest /dsgetdc:<DomainName> /force /kdc
```
This verifies that the client or server can locate a domain controller. If the command returns that the domain could not be contacted, follow the domain controller connectivity path for Error 1355 / Event ID 5719 / Error 1311.
Check DNS resolution between clients and target systems On affected clients, run:
```
   nslookup <TargetName>
```
Kerberos depends on correct name resolution. If name resolution is wrong, authentication can be directed to the wrong service or server.
Verify time synchronization Kerberos failures can occur when clocks are out of sync. Resynchronize time on affected systems with:
```
   w32tm /resync /computer:<Target> /rediscover
```
After resynchronizing, test authentication again.
Check firewall and required service connectivity Verify that required Kerberos-related traffic is allowed between clients, servers, and domain controllers. The checklist specifically includes:
- LDAP / DC Locator: 49152-65535 TCP/UDP, 389 TCP/UDP
- LDAP SSL: 49152-65535 TCP, 636 TCP
- SMB: 49152-65535 TCP/UDP, 445 TCP
- RPC endpoint mapper: 49152-65535 TCP, 135 TCP
- RPC for LSA, SAM, NetLogon: 49152-65535 TCP
- W32Time: 49152-65535 UDP, 123 UDP
If firewall settings are changed, test authentication again.
Check update state Make sure all domain controllers, affected clients, and target servers have relevant Windows updates installed. If updates were installed, restart the affected computers and test again.
Collect simultaneous network traces if the issue persists The documented advanced step is to collect traces on both the client and target server by using Network Monitor. In the trace, look for Kerberos messages and note any server names, IP addresses, and SPNs associated with errors. In particular, if trace data shows:
- KDC_ERR_S_PRINCIPAL_UNKNOWN or KDC_ERR_PRINCIPAL_NOT_UNIQUE: investigate SPN problems
- KRB_AP_ERR_MODIFIED: review related events and trace data
- KRB_AP_ERR_SKEW: fix time synchronization
- KDC_ERR_ETYPE_NOTSUPP: review encryption-type mismatch
If the environment includes Windows 11 24H2 or Windows Server 2025, check for duplicate SID symptoms Microsoft documents a condition where duplicate SIDs can cause Kerberos and NTLM authentication failures, repeated credential prompts, and lsasrv.dll Event ID 6167 with machine ID mismatch text. If those symptoms are present, include duplicate SID investigation in the root-cause analysis.

The key point from the documented guidance is that repeated Kerberos failures from multiple systems should be investigated through logs, DC reachability, DNS, time sync, firewall paths, updates, and then network traces. Clearing a single user’s ticket cache does not address those infrastructure causes.

Answer 2

Hi MS,

Event ID 4771 with Failure Code 0x18 is a Kerberos pre-authentication failure due to an incorrect password. Interactive logins succeed, which means your users' actual passwords are correct. These widespread failures are being caused by background applications, network vulnerability scanners, or stale credentials in the Windows Credential Manager that are attempting to authenticate using outdated password hashes.

The klist purge command did not resolve the issue because it merely empties the temporary Ticket Granting Ticket cache. It does not delete saved passwords or prevent a background service from immediately requesting a new ticket with bad credentials. To identify the root cause, you must trace the authentication traffic back to its source executable. Install Microsoft Sysinternals Sysmon on one of the affected workstations and configure it to monitor outbound network connections on port 88. By matching the timestamp of the failure on your Domain Controller to the Sysmon logs on the client, you will expose the exact process ID and application generating the invalid requests, enabling you to reconfigure or remove the offending software.

Hope this answer has brought you some useful information. If it did, please hit “accept answer”. Should you have any questions, feel free to leave a comment.

VPHAN