klist in Windows: read and clear the Kerberos ticket cache

Kerberos fails quietly. When a ticket cannot be issued, Windows falls back to NTLM or simply returns access denied, and nothing on screen mentions Kerberos at all. klist is the one built-in tool that shows what the machine actually holds and what it asked for.

It reads the Kerberos ticket cache of a logon session: the ticket-granting ticket, every service ticket obtained with it, the flags on each one, and when they expire. That is enough to answer the two questions that come up in every authentication incident. Did this machine get a ticket for the service it was trying to reach, and is the group membership in that ticket current.

None of it requires a domain controller, a debugger, or a network trace. It runs on the machine that is failing and takes a second.

Applies to: Windows 10 / 11 and Windows Server 2016 / 2019 / 2022 / 2025, domain joined

Quick answer

Three commands cover most of it: see what you hold, throw it away so it is fetched fresh, and look at what the computer account holds rather than your own session.

rem Every ticket in the current logon session
klist

rem Discard them; the next access request gets a new ticket with current group membership
klist purge

rem The SYSTEM logon session, which is what services and scheduled tasks use
klist -li 0x3e7 tickets

The first two run as an ordinary user. Reading or purging another session, including SYSTEM, needs an elevated prompt.

What klist does

Kerberos works in two steps. The client gets a ticket-granting ticket from a domain controller once, at logon, and then exchanges it for a service ticket each time it reaches a new service. klist shows both, and lets you clear them.

ParameterWhat it does
ticketsLists cached TGTs and service tickets. This is the default.
tgtShows the initial ticket-granting ticket on its own.
purgeDeletes every ticket in the session.
sessionsLists the logon sessions on the machine with their LUIDs.
get <SPN>Requests a ticket for a named service principal, on demand.
query_bindShows which domain controller Kerberos is currently using per domain.
add_bind, purge_bindPin a preferred domain controller, or clear the pin.
kcd_cacheConstrained delegation cache, for double-hop problems.
-li <luid>Targets another logon session. 0x3e7 is SYSTEM.
Note: Group membership is carried inside the ticket, not checked at each request. That single fact explains most of what follows.

Practical examples

1. The group membership that will not take effect

The problem: You added a user to FIN-Reports-RW twenty minutes ago. The share still says access denied. Active Directory shows the membership, and replication is healthy.

The solution: The user is still presenting the ticket they received at logon, and that ticket lists the groups they had at logon. Purging the cache forces a new one.

rem Confirm what the session currently holds
klist

rem Throw it away; the next connection requests a fresh TGT and service ticket
klist purge

rem Prove the new ticket carries the new membership
whoami /groups | findstr /i "FIN-Reports-RW"
Result: This is the mechanism behind “log off and back on”. Purging the cache does the same thing without ending the session, which matters on a server nobody wants to log out of.

2. Did this machine even get a Kerberos ticket?

The problem: An intranet application prompts for credentials repeatedly instead of signing the user in transparently. The security log on the server shows NTLM authentication, not Kerberos.

The solution: List the tickets and look for a service ticket matching the service being reached. If there is none, Kerberos never succeeded and Windows fell back to NTLM silently.

klist tickets
Current LogonId is 0:0x2f1a4

Cached Tickets: (2)

#0>     Client: jsmith @ CORP.LOCAL
        Server: krbtgt/CORP.LOCAL @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40e10000 -> forwardable renewable initial pre_authent
        Start Time: 9/4/2026 8:41:02 (local)
        End Time:   9/4/2026 18:41:02 (local)
        Renew Time: 9/11/2026 8:41:02 (local)

#1>     Client: jsmith @ CORP.LOCAL
        Server: cifs/SRV-FILE01.corp.local @ CORP.LOCAL
        KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96
        Ticket Flags 0x40a50000 -> forwardable renewable pre_authent ok_as_delegate
        Start Time: 9/4/2026 8:41:07 (local)
        End Time:   9/4/2026 18:41:02 (local)

Ticket 0 is the TGT: the Server field is krbtgt. Ticket 1 is a service ticket for the file server. If the application lives on HTTP/app.corp.local and no ticket with that server name appears after you have used it, the ticket request failed.

You can ask for one directly and watch it succeed or fail, which is far quicker than reproducing the problem through the application.

rem Request a ticket for a named SPN without going through the app
klist get HTTP/app.corp.local
Warning: An error of KDC_ERR_S_PRINCIPAL_UNKNOWN here means no account in the directory owns that service principal name. That is an SPN registration problem, and setspn is where it gets fixed. A ticket that is issued to the wrong account points at a duplicate SPN instead.

3. A service or scheduled task fails, but a logged-on user works

The problem: A backup job running as SYSTEM cannot reach a UNC path. The same path opens fine when you are logged in interactively.

The solution: Those are different logon sessions with different ticket caches. A process running as SYSTEM authenticates as the computer account, and its tickets live in session 0x3e7.

rem Every logon session on the machine, with its LUID
klist sessions

rem The SYSTEM session; note the client is SRV-APP01$, the computer account
klist -li 0x3e7 tickets

rem Purge just that session, without disturbing interactive users
klist -li 0x3e7 purge

If the computer account has no valid TGT, the machine account password is out of step with the directory, which is the same underlying fault described in the trust relationship guide.

4. Which domain controller issued this ticket?

The problem: Authentication works for most users and fails for some, and you suspect one domain controller in the site is the difference.

The solution: Kerberos caches a preferred DC per domain. You can read it, and pin a specific one to test a theory.

rem Which DC this machine is currently talking to for each domain
klist query_bind

rem Pin one DC to test it in isolation
klist add_bind CORP.LOCAL SRV-DC02.corp.local
klist purge
klist get cifs/SRV-FILE01.corp.local

rem Remove the pin when the test is over
klist purge_bind
Common mistake: Leaving a bind in place. A pinned domain controller stays pinned for the session, so a machine left that way keeps authenticating against one DC and fails completely when that DC reboots. Always run klist purge_bind afterwards.

Hidden gems

klist purge does not touch services. It clears the session you run it from. A service running as SYSTEM keeps its tickets, which is why a permissions change appears to work for you and not for the application. Purge 0x3e7 as well, or restart the service.

Ticket lifetime is where “it started working overnight” comes from. The default domain policy issues user tickets valid for 10 hours, renewable for 7 days. A group change quietly takes effect at the next renewal, which is why the problem reported on Monday afternoon cannot be reproduced on Tuesday.

A user in too many groups stops authenticating at all. Group membership travels in the ticket, so it has a size limit. The default maximum token size is 48000 bytes on Windows Server 2012 and later. A user in several hundred nested groups can exceed it and receive HTTP 400 errors from web applications, while file shares keep working. Count the groups before blaming the application.

The Server field tells you the SPN that was actually requested. A ticket for cifs/SRV-FILE01 and one for cifs/srv-file01.corp.local are separate tickets. If a client connects by short name where the SPN is registered by FQDN, Kerberos fails and NTLM takes over without a word.

klist get is a test, not just a read. Requesting a ticket for a specific SPN reproduces the exact failure in one line, on the machine that has the problem, with no application involved. It is the fastest way to separate a service problem from an authentication problem.

PowerShell equivalent

There is no cmdlet for the ticket cache. klist is the tool, and PowerShell is the wrapper when you need it across machines or want the output as objects.

# Pull just the Server lines, which is usually all you need
klist | Select-String 'Server:' | ForEach-Object { $_.Line.Trim() }

# The same check on several machines at once
Invoke-Command -ComputerName SRV-APP01,SRV-APP02 -ScriptBlock { klist } |
    Select-String 'Server:|Client:'

# Groups actually present in the current token, which is what the ticket carried
whoami /groups /fo csv | ConvertFrom-Csv | Select-Object 'Group Name', Type
Note: whoami /groups reads the access token that was built from the ticket. If a group is missing there, purging the ticket cache and reconnecting is the fix, not editing permissions.

Where this matters

  • Permission changes that do not apply. The first question is always whether the ticket predates the change.
  • Single sign-on that prompts for credentials. A missing service ticket is the evidence that Kerberos was attempted and failed, which sends you to the SPN rather than to the browser settings.
  • SQL Server and IIS double-hop failures. klist kcd_cache shows whether constrained delegation produced anything at all.
  • Clock skew. Kerberos refuses a ticket more than five minutes out. If no ticket is issued at all, check time synchronisation before anything else.
  • Scheduled tasks and services that fail against network resources. Session 0x3e7 is the one to look at, not yours.

Tips and limitations

  • Reading or purging your own session needs no elevation. Touching another session, including SYSTEM, does.
  • klist reports the client side only. It cannot tell you why a domain controller refused a request; the Security log on the DC carries that.
  • An empty cache is normal immediately after a purge or on a machine that has not yet touched a domain resource. Absence of tickets is not by itself a fault.
  • Encryption type matters. A ticket issued as RC4 where the environment expects AES usually means an account with an old msDS-SupportedEncryptionTypes value, and it will break when RC4 is disabled.
  • Purging the cache on a busy terminal server affects only the session you target, but every application in that session will re-authenticate, which can look like a brief hang.

Official documentation

Related tools

Related guides