Kerberos Error Codes Troubleshooting Guide: decode failure codes and fix the cause

Kerberos failures surface as a hex code in an event log, a cryptic library message or a silent fall back to NTLM, and the code alone rarely tells you which of a dozen moving parts is broken. This guide is a working reference for the errors practitioners actually meet in Active Directory and MIT Kerberos estates: what each code means, the likely causes in order of frequency, where to look to confirm the cause, the fix, and how to stop it coming back. It is written for identity engineers, Windows and Linux administrators and SOC analysts who triage authentication incidents. It assumes you know the basic AS, TGS and AP exchanges; for the security model behind them see the Kerberos Security Guide.

Key takeaways

• Read the code, then the exchange. Codes from 0x1 to 0x1d are KDC errors on the AS or TGS exchange; codes from 0x1f upwards (KRB_AP_ERR_*) usually come from the service decrypting your ticket, so you troubleshoot a different machine.
• Not every code is a fault. KDC_ERR_PREAUTH_REQUIRED (0x19) is a normal step in the exchange and 0x20 ticket expiry in event 4769 is mostly informational; chasing them wastes hours.
• Four causes explain most outages. Clock skew above 5 minutes, missing or duplicate SPNs, service keys that changed without the keytab being updated, and encryption type mismatches account for the bulk of real incidents.
• Collect evidence on three hosts. The client, the target service and the domain controller each hold part of the story: Security log events 4768, 4769 and 4771, System log Kerberos events, and a network trace filtered on port 88.
• Service accounts break loudest. Non-human identities with hand-set SPNs, static keytabs and pinned encryption types cause the long outages; managed service accounts and SPN hygiene remove whole classes of error.

How Kerberos fails: locating the failing exchange

Kerberos has three exchanges, and each fails in a different place. Identify the exchange before you interpret the code.

Event 4771 is only written on domain controllers and only when the KDC fails to issue a TGT; it is not written for accounts with "Do not require Kerberos preauthentication" set. Event 4769 failures record a ticket encryption type of 0xFFFFFFFF, so take the encryption type from the account and trace, not from the failure event.

Error code reference

The codes below come from RFC 4120 section 7.5.9 as reproduced in Microsoft's event documentation. The "first check" column is the most common cause in practice, so start there.

PKINIT codes from 0x3e upwards (for example KDC_ERR_CLIENT_NOT_TRUSTED, KDC_ERR_INVALID_CERTIFICATE, KDC_ERR_REVOCATION_STATUS_UNKNOWN) belong to certificate logon; the Kerberos PKINIT and Certificate Mapping Guide covers mapping and revocation checks.

Triage order: the first ten minutes

Work through these steps in order. Most incidents end at step 3 or step 4.

1. Scope the failure: one user, one service, one site or everyone. One user points at the account (0x12, 0x17, 0x18); one service points at SPNs or keys (0x7, 0x8, 0x29); one site points at time, DNS or firewalls.
2. Confirm a domain controller is reachable: nltest /dsgetdc:<domain> /force /kdc from client and target. Netlogon Event ID 5719 or errors 1311 and 1355 mean the KDC is not being found at all.
3. Check time: compare client, target and DC clocks. A difference above 5 minutes produces 0x25 or 0x21. Resynchronise with w32tm /resync /computer:<target> /rediscover and find why the hierarchy drifted.
4. Check name resolution and the SPN: resolve the target name from both client and target with nslookup, then run setspn -Q <service>/<fqdn> to see which account holds it and setspn -X (add -F for forest scope) to find duplicates.
5. Purge and retry: klist purge for the user and klist -li 0x3e7 purge for the computer account, reproduce, then klist tickets to see whether a service ticket was issued and with which encryption type.
6. Read the DC events: filter 4768, 4769 and 4771 for the account and time window and record the failure code, client address and pre-authentication type.
7. Turn on detail only if needed: set LogLevel (REG_DWORD, 1) under HKLM\SYSTEM\CurrentControlSet\Control\Lsa\Kerberos\Parameters for Kerberos events in the System log, or set the KRB5_TRACE environment variable to a file on MIT krb5 1.9 and later. Remove the value afterwards: it is noisy and logs expected errors such as 0x19.
8. Capture the wire: a trace on client and target filtered on Kerberos (TCP and UDP 88) shows the exact KRB-ERROR, the realm and the requested SPN, which settles disputes between teams.

Symptom guide: the errors that cause real outages

Clock skew: KRB_AP_ERR_SKEW (0x25) and KRB_AP_ERR_TKT_NYV (0x21)

• Symptom: authentication fails for every user on one host or one site; Linux tools report "Clock skew too great".
• Likely causes: a virtual machine syncing time from its host instead of the domain hierarchy; a DC holding the PDC emulator role pointed at an unreliable external source; a firewall blocking UDP 123; a host restored from snapshot.
• Diagnose: compare clocks on all three parties; check the configured time source and the W32Time or chrony status.
• Fix: resynchronise and correct the source. Microsoft notes that clocks more than 48 hours apart, or using a different source from the DCs, need manual action.
• Prevent: one authoritative time hierarchy, an alert on offset above 2 minutes, and no host-time sync for domain members.

SPN problems: 0x7, 0x8 and KRB_AP_ERR_MODIFIED (0x29)

• Symptom: the application falls back to NTLM, prompts for credentials, or logs "access denied" while the user is valid. The client System log shows Kerberos Event ID 4 for KRB_AP_ERR_MODIFIED.
• Likely causes: the service was moved from the computer account to a domain service account (or back) without moving the SPN; the same SPN sits on two accounts; the client connects using a DNS alias with no SPN; an HTTP service runs under an account that does not hold the HTTP SPN.
• Diagnose: setspn -L <account> for the account the service runs as, setspn -Q for the SPN the client requested (visible in the trace and in 4769 Service Name), setspn -X for duplicates.
• Fix: remove the SPN from the wrong account with setspn -D and register it on the right one with setspn -S, which checks for duplicates first. Purge tickets on the client and retest.
• Prevent: register SPNs only through change control, run setspn -X on a schedule and alert on any result.

Key mismatch: 0x1f, 0x2c and 0x2d on keytab-based services

• Symptom: a Linux, Java or appliance service that authenticates with a keytab starts failing straight after a password reset or account rotation, while Windows clients are fine.
• Likely causes: the account password changed, so the KDC issues tickets with a new key version number (kvno), but the keytab still holds the old key; the keytab lacks the AES keys the KDC now prefers; the keytab was generated for a different principal name or realm case.
• Diagnose: compare the kvno in the keytab with the kvno of the issued ticket (visible in a trace or klist on the client), and list the encryption types present in the keytab.
• Fix: regenerate the keytab after every password change, with the encryption types the account supports, and deploy it before the old key stops being accepted.
• Prevent: treat the keytab as a secret with an owner and a rotation runbook; see the Secret Rotation Outage Troubleshooting Guide.

Encryption type mismatch: KDC_ERR_ETYPE_NOSUPP (0xe)

• Symptom: 4769 or 4768 failures with 0xe, System log Event ID 14 ("unsupported etype") for cross-domain access, or MIT clients reporting "KDC has no support for encryption type while getting initial credentials".
• Likely causes: RC4 or DES disabled on the KDC or client while a service account still only has RC4 or DES keys; an old account whose password predates AES key generation; a trust configured for a different set of types.
• Diagnose: check the encryption types configured on the service account (msDS-SupportedEncryptionTypes), the client policy and the KDC policy, and compare with the type requested in the trace.
• Fix: reset the service account password so AES keys are generated, set the account to AES, and regenerate keytabs. MIT documents allow_weak_crypto = true only as a fallback when DES cannot be removed; treat it as temporary and time-boxed.
• Prevent: follow the staged approach in the Kerberos RC4 Deprecation guide and alert on any 4769 with ticket encryption type 0x17, 0x18, 0x1 or 0x3.

Account state: 0x12, 0x17, 0x18 and 0xc

• Symptom: one account fails everywhere, often a service account that ran for years.
• Likely causes: password expired (0x17); account disabled, expired or locked out (0x12); wrong or stale password (0x18), commonly a service, scheduled task or mapped drive still using the old password and locking the account; logon hours, workstation restrictions or a smart card requirement (0xc).
• Diagnose: read the account's state and the client address on the 4771 events; repeated 0x18 from one address identifies the stale credential.
• Fix: update the stored credential at its source, then unlock. Do not simply set "password never expires".
• Prevent: move services to group managed service accounts so the platform rotates the password; see How to convert AD service accounts to gMSA.

Token size: HTTP 400 and KRB_ERR_GENERIC (0x3c)

• Symptom: a user in many groups sees "HTTP 400 - Bad Request (Request Header too long)" on IIS sites, Group Policy fails to apply, while NTLM still works.
• Cause: the PAC carries the user SID, every group SID and any sIDHistory SIDs. When the token exceeds MaxTokenSize (default 48,000 bytes on Windows Server 2012 and Windows 8 and later, 12,000 bytes on earlier versions) authentication fails.
• Diagnose: estimate with Microsoft's formula, TokenSize = 1200 + 40d + 8s (d for universal groups outside the account domain plus sIDHistory, s for groups inside), doubled where unconstrained delegation applies.
• Fix and decision: reducing group sprawl and cleaning sIDHistory is the durable fix. Raising MaxTokenSize under the Kerberos Parameters key needs a restart on every machine in the path and Microsoft warns that values above 48,000 cause IIS and other problems, so treat it as a last resort.

Decision guidance: quick fix or root cause

Small organisations with one domain and a handful of service accounts can usually work from the triage list and setspn. Large multi-forest estates should add forest-scope duplicate SPN scans, trust encryption type reviews and central collection of 4768, 4769 and 4771 from every DC, because the failing request often lands on a DC in another site.

Where identity fits: service accounts and machine identities

Most long Kerberos outages involve a non-human identity: a service account with a hand-registered SPN, a keytab copied to a Linux host years ago, a computer account whose secure channel broke after a snapshot restore. These identities rarely have an owner, so the error is noticed only when the dependent application fails. Inventory every account holding an SPN, record its owner, encryption types and where its keys live, and prefer group managed service accounts. The same inventory is your defence against Kerberoasting (MITRE ATT&CK T1558.003), which targets exactly these accounts; see the Group Managed Service Accounts (gMSA) Guide.

Detection and measurement

Errors you troubleshoot are also signals. The same events serve operations and the SOC.

• Brute force and spraying: bursts of 0x18 on 4771 for one account suggest password guessing; 0x18 across many accounts from one address suggests spraying (T1110.003).
• Accounts without pre-authentication: 4768 requests with pre-authentication type 0 are AS-REP Roasting exposure (T1558.004). Find and fix the accounts.
• Weak tickets: 4769 with encryption type 0x17 or 0x18 on modern systems, or 0x1 and 0x3 at all.
• Unexpected sources: 4769 or 4771 where the client address is outside internal ranges, or ::1 for accounts not allowed to log on to DCs.

Metrics that show the estate is healthy:

1. Kerberos failure events per 1,000 authentications, excluding 0x19 and 0x20, trended weekly.
2. Number of duplicate SPNs found by the scheduled setspn -X scan (target: zero).
3. Percentage of SPN-holding accounts that are gMSAs or have a recorded owner and rotation date.
4. Share of service tickets issued with AES (0x11 or 0x12).
5. Maximum clock offset from the authoritative source across domain members.
6. Mean time to resolve Kerberos incidents, before and after adopting the triage order.

For event collection and parsing in depth see the Active Directory Security Monitoring and Event IDs Guide.

Framework mapping

Common failure patterns

• Chasing 0x19: enabling Kerberos logging, seeing KDC_ERR_PREAUTH_REQUIRED and treating it as the fault. It is an expected step; look at the next message.
• Fixing NTLM fallback by doing nothing: the application "works", so the broken SPN stays, and the service keeps accepting NTLM long after policy says it should not.
• Rotating a password without the keytab: a scheduled rotation succeeds in the directory and silently breaks every Linux consumer that holds a keytab.
• Re-enabling RC4 globally to clear 0xe: it fixes one service and reopens Kerberoasting exposure across the domain.
• Using IP addresses or aliases in connection strings: no SPN matches, the client cannot request a ticket and authentication drops to NTLM.
• Leaving debug logging on: LogLevel left at 1 fills the System log and buries the next real problem.

Practitioner checklist

• Identify the failing exchange (AS, TGS or AP) before interpreting the code.
• Check DC reachability, time offset and DNS resolution from client and target first.
• Query the requested SPN with setspn -Q and scan for duplicates with setspn -X.
• Purge user and machine tickets, reproduce, and record the issued ticket and encryption type.
• Pull 4768, 4769 and 4771 for the account and window from every DC that served it.
• Regenerate keytabs after every service account password change and confirm the kvno matches.
• Fix encryption type gaps with password resets and AES settings, not domain-wide RC4.
• Remove temporary diagnostics (LogLevel, KRB5_TRACE, allow_weak_crypto) when the incident closes.
• Record the root cause against the service account owner and add a prevention control.

Standards and references

• IETF: RFC 4120 The Kerberos Network Authentication Service (V5)
• Microsoft Learn: 4771(F) Kerberos pre-authentication failed
• Microsoft Learn: 4769(S, F) A Kerberos service ticket was requested
• Microsoft Learn: Kerberos authentication troubleshooting guidance
• Microsoft Learn: Enable Kerberos event logging
• Microsoft Learn: setspn command reference
• Microsoft Learn: Kerberos authentication problems when a user belongs to many groups
• MIT Kerberos: Troubleshooting

Related NHI Mgmt Group resources: Kerberos Security Guide · Kerberos RC4 Deprecation · MITRE ATT&CK T1558 Steal or Forge Kerberos Tickets Guide · Group Managed Service Accounts (gMSA) Guide · SAML SSO Errors Troubleshooting Guide