Kerberos pre-authentication failures — event IDs decoded

Kerberos pre-authentication failures are one of the most common sources of noise in a Windows Security event log — and one of the least understood. Events 4768, 4771, and 4776 all fire for different reasons, and the failure code buried in each event is the only thing that tells you what actually went wrong. This runbook decodes every common failure code and gives you the exact fix for each.

The three event IDs you'll see

Event ID	What it means	Where logged
4768	Kerberos Authentication Service (AS) request. Logged for every TGT request — success and failure. Status code tells you which.	Domain Controller Security log
4771	Pre-authentication failed. The client sent the wrong encrypted timestamp — wrong password, clock skew, or bad keytab.	Domain Controller Security log
4776	NTLM credential validation attempt. Not Kerberos — fires when a machine falls back to NTLM because Kerberos failed. Proxies real Kerberos problems.	Authenticating DC Security log

4771 failure codes and what they mean

The Failure Code field in Event 4771 is the diagnostic. Here are every common code and what to do with it.

Failure Code	Meaning	Fix
0x6	Client not found in Kerberos database. Username doesn't exist in AD.	Confirm the UPN/sAMAccountName. Check for typos. Verify the user exists in the correct domain — not a trust issue.
0x7	Server not found in Kerberos database. The target SPN doesn't exist.	Run setspn -Q HTTP/servername. Register missing SPN or fix the application's target name.
0x12	Account disabled, expired, or locked. Account exists but cannot authenticate.	Check account status in ADUC. Unlock, re-enable, or extend expiry. Check fine-grained password policies.
0x17	Password has expired. User's password lifetime has passed.	Force a password reset. Check if the account is set to "password never expires" unexpectedly.
0x18	Pre-authentication info was invalid. Wrong password.	Verify credentials. If this fires in bulk from a service account, the stored credential (scheduled task, IIS app pool, service) has a stale password.
0x19	Additional pre-authentication required. Policy requires smartcard or MFA.	Ensure client supports required auth method. Check whether "Smart card is required for interactive logon" was set on the account.
0x25	Clock skew too great. Client and DC clocks differ by more than 5 minutes.	Run w32tm /query /status on the client. Check PDC emulator NTP source. Fix clock sync before anything else.
0x37	Skew too great (alternate code). Same as 0x25, surfaced differently in some clients.	Same as 0x25 — fix NTP.

The clock skew problem — the most common culprit

Kerberos requires client and server clocks to be within 5 minutes of each other. When they're not, every authentication attempt fails with 0x25 or 0x37. This is especially common after:

• A VM was paused or restored from snapshot
• A laptop was offline for an extended period
• The PDC emulator lost its NTP source
• A branch office DC was isolated from the hub

Diagnose clock skew

# Check client time sync status
w32tm /query /status

# Check source and stratum
w32tm /query /peers

# Test sync manually
w32tm /resync /force

# Check PDC emulator (run on PDC)
w32tm /query /configuration

Fix the PDC emulator's NTP source

# Run on the PDC emulator — set external NTP source
w32tm /config /manualpeerlist:"0.pool.ntp.org,1.pool.ntp.org" /syncfromflags:manual /reliable:YES /update

# Restart time service
net stop w32time && net start w32time

# Force sync
w32tm /resync /force

# Verify
w32tm /query /status

Bulk 4771 events — the service account password problem

If you see hundreds of 4771 0x18 events per minute from a single account, the password changed but something still has the old credential stored. The sources are predictable:

• Scheduled tasks — stored credentials don't auto-update
• IIS application pools — identity password cached in IIS
• Windows services — Services.msc stores credentials at config time
• Credential Manager — Windows credential vault on user machines
• ADFS or third-party SSO — service account keytab needs regeneration

Find the source machine

# The 4771 event includes the Client Address field
# Filter Security log on DC for the specific account
Get-WinEvent -ComputerName DC01 -FilterHashtable @{
    LogName='Security'
    Id=4771
} | Where-Object {$_.Message -like '*jsmith*'} |
    Select-Object -First 20 TimeCreated,Message |
    Format-List

Clear stale credentials from Credential Manager

# List stored credentials
cmdkey /list

# Remove specific entry
cmdkey /delete:DOMAIN\serviceaccount

# Or via GUI: Control Panel > Credential Manager > Windows Credentials

Event 4776 — when Kerberos falls back to NTLM

Event 4776 is not a Kerberos event — it's NTLM. But it fires because Kerberos failed first and the client fell back. Common reasons Kerberos fails and forces NTLM fallback:

• Client connecting to server by IP address instead of hostname (Kerberos requires a hostname or FQDN to build the SPN)
• Missing or duplicate SPN on the target service account
• Target service running as a non-domain user or built-in account
• DNS resolving to the wrong hostname

Fix IP-address-based fallback

The fix is to change the client connection to use the hostname. For mapped drives, update the UNC path from \\192.168.1.10\share to \\fileserver01\share. For GPO-mapped drives, update the GPO path preference.

Check for missing or duplicate SPNs

# List all SPNs for a service account
setspn -L DOMAIN\svcWebApp

# Check for duplicates (run on DC)
setspn -X

# Add a missing SPN
setspn -S HTTP/webserver01.domain.com DOMAIN\svcWebApp
setspn -S HTTP/webserver01 DOMAIN\svcWebApp

4771 and account lockout

Repeated 0x18 failures (wrong password) will trigger account lockout if a lockout policy is in place. The lockout itself logs a separate Event 4740. To find what's locking the account:

# On the PDC emulator — this is where lockouts are always recorded
Get-WinEvent -ComputerName PDC01 -FilterHashtable @{
    LogName='Security'
    Id=4740
} | Where-Object {$_.Message -like '*jsmith*'} |
    Select-Object -First 10 TimeCreated,Message |
    Format-List

# The "Caller Computer Name" field in 4740 tells you the source machine

Once you have the source machine, check Credential Manager and recently changed service configurations on that machine for the stale password.

0x19 — smartcard and MFA requirement failures

Failure code 0x19 means the KDC requires additional pre-authentication that the client didn't provide. This fires when:

• An account has "Smart card is required for interactive logon" enabled but the user is logging in without one
• A Conditional Access policy requires MFA for the resource
• A service account has smartcard enforcement set accidentally

# Check the flag on the account
Get-ADUser jsmith -Properties SmartcardLogonRequired |
    Select-Object Name,SmartcardLogonRequired

# Remove the flag if set accidentally
Set-ADUser jsmith -SmartcardLogonRequired $false

Quick reference — failure code cheat sheet

Code	Short cause	First thing to check
0x6	User not found	UPN/sAMAccountName typo, wrong domain
0x7	Server/SPN not found	setspn -Q
0x12	Account disabled/locked/expired	ADUC account status
0x17	Password expired	Force password reset
0x18	Wrong password	Stale stored credentials / service account
0x19	Additional auth required	SmartcardLogonRequired flag
0x25	Clock skew	w32tm /query /status
0x37	Clock skew (alternate)	Same as 0x25

Summary

Kerberos failures almost always have a specific, fixable cause — the failure code is the key. The most common production problems are clock skew (0x25), stale service account passwords (0x18 in bulk), and duplicate or missing SPNs (NTLM fallback via 4776). Start with the failure code, identify the source machine from the event's Client Address field, and work from there. Kerberos doesn't lie — it just doesn't explain itself well without this decoder ring.