Kerberos troubleshooting

Follow the three exchanges

Kerberos troubleshooting becomes much easier once the failure has a place in the exchange:

The TGT is protected with the domain krbtgt account’s key. A service ticket is protected with the target service account’s key. The client and service also receive a session key. A TGT and a session key are different things; calling both of them a “session ticket” makes packet analysis harder.

The KDC’s reply also has a part the requester can decrypt. In a password-based AS exchange, that reply is protected using an appropriate client key; the client can’t decrypt the enclosed TGT. In a TGS exchange, the reply uses the existing TGT session key or an authenticator subkey, while the service ticket uses the service’s long-term key. The service can validate the AP exchange using its ticket and the authenticator. An AP-REP provides mutual authentication when requested. Each part can fail separately; RFC 4120 sections 3.1-3.3 describe the exchanges.

Windows applications often ask SSPI’s Negotiate package to choose the authentication mechanism. Seeing Negotiate in the settings doesn’t tell you which package won. Check the trace or resulting logon event for Kerberos.

For application failures that differ by process or service identity, use logon sessions, SSPI and access tokens to separate the credential handle, completed context, ticket cache and local access check.

A useful trace has a beginning and an endpoint

For a fresh password-authentication test, the expected sequence is an AS exchange with the account-domain KDC, any necessary TGS referrals, a final service ticket, and an application AP exchange. Existing tickets can legitimately eliminate earlier exchanges. No new 4768 or 4769 during an application attempt can simply mean a cached ticket was reused.

KDC_ERR_PREAUTH_REQUIRED on an initial AS request can be a normal negotiation step: the client obtains preauthentication and encryption information, then retries. A final preauthentication failure is a different result. Similarly, a TCP or HTTP connection completing does not establish that the AP exchange succeeded. Confirm the last successful protocol stage before changing a setting. Microsoft’s log-analysis example shows how cached tickets, KDC requests, and the application request fit together.

Inspect the session that is failing

Run these on the client under the affected user’s identity:

klist
klist tgt
klist query_bind

Look at the client, server principal, issuing realm, expiry, ticket flags, and encryption type. A ticket for a different hostname is a useful clue when the user accessed an alias.

An administrator’s interactive ticket cache does not describe a service’s logon session. From an elevated prompt, enumerate sessions and inspect the appropriate LUID:

klist sessions
klist -li 0x3e7

0x3e7 is the Local System session. A service running as a domain account can have a different LUID. Microsoft’s klist reference describes the session selectors.

A LUID is local to one boot of one machine. Do not correlate a client LUID directly with the same number on the server. Elevation, runas, a scheduled task, and an application pool can also introduce a different session from the user’s ordinary desktop. Record both the process identity and the session being queried.

Active test: requesting a ticket changes the local cache and generates authentication traffic. It does not prove the application can use that ticket or pass the resource ACL:

klist get HTTP/app.contoso.com

Keep the exact failing URL or UNC name. Testing HTTP/app.contoso.com while the application requests HTTP/app can test a different registration.

Read the error at the correct stage

If TGS succeeds but the application returns access denied, check the service’s logon event and authorization decision. Repeatedly resetting the user’s password is unlikely to help there. Microsoft’s Kerberos troubleshooting guidance works through the checks for each exchange.

A valid ticket still carries authorization state

The PAC carries account and group authorization information used when the accepting system builds its security context. A fresh directory group query, an existing TGT, a cached service ticket, and a running application’s token can describe different points in time. Purging a client ticket does not rewrite an existing process token or necessarily close an authenticated SMB or HTTP session. Use a deliberately new logon and connection when the question is whether a membership change now affects access.

A service ticket is also not a promise that the service can operate without contacting a DC. PAC validation and cross-domain processing can add dependencies after ticket issuance. The PAC validation changes in KB5037754 introduced a new Network Ticket Logon flow; inspect both the accepting server and the domain path when it fails.

Encryption numbers need a number base

Decimal 17 is AES128. Hexadecimal 0x17 is RC4. This is an easy mistake to carry from a trace into an incident report. These assigned values are documented in Microsoft’s Kerberos protocol errata.

Also distinguish the ticket’s encryption type from the session key type. Enabling AES support on an account is only part of the investigation: the account must have usable AES keys and the client, KDC, service, and policy must agree. Record DC build and patch level when comparing different results.

See encryption types and key selection for the separate attribute bitmasks, 2026 default changes, and keytab checks.

Capture before clearing anything

Collect the failing time, client, user, target service name, contacted KDC, ticket cache, and relevant events before resetting state. Useful Security events include 4768 for TGT requests, 4769 for service ticket requests, and 4771 for preauthentication failures, when the corresponding audit subcategories are enabled.

Keep the raw XML and event version as well as the rendered message. Updated DCs expose more encryption fields than older event versions. Align clocks and correlate the client address, account, request time, KDC, failure code, and requested service; an account name by itself is a poor join key on a busy DC.

If the failure follows one DC, query the account and SPN on that DC and compare replication metadata. The administrator’s nearest DC may already have a change that the failing KDC hasn’t received. See replication health for the collection steps.

Local state change: klist purge deletes the selected session’s tickets. It can interrupt access and changes the evidence. Purge only the session being tested, then reproduce once. Do not purge Local System tickets across a fleet as an opening troubleshooting step.

If a front end authenticates the user successfully but the back end sees the wrong identity, continue with delegation. If the failure follows a name or alias, continue with SPNs.