Kerberos on Windows: klist, klist purge, and setspn -L/-Q for SPN problems

Goal

Inspect and clear cached Kerberos tickets on a Windows client, and diagnose service-principal-name (SPN) problems that break Kerberos authentication to a service, on Windows Server 2016 and later / Windows 10 and later.

Prerequisites

A command prompt on the client for klist (no elevation for your own session; the computer account's cache, klist -li 0x3e7, needs an elevated prompt); setspn from the RSAT/AD DS tools. Querying SPNs (-L, -Q, -X) works for any domain user; adding or removing them needs Domain Admins or delegated write access to the account's servicePrincipalName.

Steps

1. List cached tickets for the current logon session: klist. It shows each ticket's server principal, client principal, and validity window.
2. Clear the cache when testing a fresh authentication (for example after a group or SPN change): klist purge, which removes all cached tickets for the current session so the next request forces a new exchange with the KDC.
3. Check what SPNs exist for a service account: setspn -L <accountname> lists every SPN currently registered on that account.
4. Check whether an SPN is already registered before adding it: setspn -Q <SPN>; setspn -X lists duplicate SPNs, and setspn -S <SPN> <account> adds one only after checking for duplicates (Microsoft recommends it over -A).
5. If a service will not receive a Kerberos ticket and instead falls back to NTLM, setspn -Q HTTP/servername (or the relevant service class) is the first check: if the query returns no result, the SPN is missing; if it returns an account other than the one running the service, that is a duplicate-SPN conflict, which Kerberos treats as a fatal ambiguity rather than picking one.

Expected result

After registering the correct SPN and clearing the client's ticket cache with klist purge, a fresh connection to the service in klist output shows a ticket for that service's SPN, and the service authenticates via Kerberos instead of falling back to NTLM.

Limits and test basis

setspn -Q and -X search the current domain by default; add -F to query at forest level. An SPN present on the wrong account (a leftover from a renamed or reinstalled service) must be removed with setspn -D before setspn -S will add it to the right one. As on Linux, Kerberos on Windows also rejects authentication when client and domain-controller clocks differ beyond the domain's configured maximum skew (5 minutes by default in AD's Kerberos policy); this shows as an authentication failure with no SPN symptom at all, so check time sync before spending time on setspn.