Forum Discussion
Kerberos Event ID 4771 (0x18) across multiple users while interactive logons succeed
Users are able to perform interactive/manual logons successfully with their current credentials.
The failures are also generated outside normal working hours.
The Client Address in the 4771 events corresponds to the workstation/IP of the respective user.
We have observed many different Client Addresses (at least 15 different source IPs), so the failures are not originating from a single host.
As an initial troubleshooting step, we executed:
klist purge
for one affected user. The Kerberos ticket cache was cleared successfully, but the Event ID 4771 failures continued afterward with no noticeable change.
Previous guidance suggested checking for stale/stored credentials, scheduled tasks, Windows services, Credential Manager entries, mapped resources, proxy authentication, or background applications that might be attempting authentication with outdated credentials.
Another recommendation was to use Sysmon on an affected workstation and correlate outbound Kerberos traffic on port 88 with the timestamp of the 4771 event in order to identify the process or executable generating the request.
Before making changes or deploying additional monitoring software in the client's environment, we would like to determine the safest and most appropriate troubleshooting approach.
Given that:
interactive logons work normally;
0x18 failures occur for many users;
each user's Client Address generally corresponds to their own workstation;
the issue occurs across many different workstations;
and clearing the Kerberos ticket cache did not change the behavior,
what would be the recommended Microsoft troubleshooting method to identify the exact process, service, application, or stored credential generating these failed Kerberos pre-authentication requests?
Thank you.
1 Reply
Event 4771 with failure code 0x18 means a bad password was sent for Kerberos pre-authentication. Since the client address matches each user's own workstation, many users are failing from their own machines, outside working hours, and interactive logons still work, the usual cause is something running as those users with an old stored password, not an attack. A safe order that needs no new software on the workstations:
- Use the data you already have on the domain controllers. Compare 4771 against 4768 (a TGT request) and 4776 (NTLM validation) for the same user and time. If the same user also shows a successful 4768 right after, an app is retrying with a stale password while the logon itself is fine. Check the times: repeating at fixed intervals (every 10, 15 or 60 minutes) points to a scheduled task, service or sync client, and failures only after password changes point to cached credentials.
- Turn on the audit that names the process on the workstation. Enable Audit Logon failures (Logon/Logoff > Audit Logon) with a Group Policy on a small pilot group of computers, then look for 4625 events. They show the logon type (4 batch or scheduled task, 5 service, 8 or 9 for network or stored credentials), the process name and the caller. That is built in, harmless and reversible.
- Check the usual stored-credential suspects on one affected workstation: Credential Manager (Windows credentials), mapped drives that were set to reconnect with other credentials, scheduled tasks and services running as a user, Outlook, Teams and OneDrive sign-ins, and RDP or VPN profiles with a saved password.
- Only if that does not find it, take a short packet capture with pktmon or netsh trace on one workstation, filtered on port 88, and match the timestamp to the 4771. It also needs no install, and Sysmon is a last step.
If you see failures from the same workstation for many different usernames, treat that differently: that points to a shared service or a spray and should be handled separately.
