SSOGEN / Learn / What Is Kerberos? Tickets, Realms and How to Read klist Output

Learn

What Is Kerberos? Tickets, Realms and How to Read klist Output

Kerberos is a network sign-in protocol where a trusted server issues tickets, so you prove who you are once and then reach many services without sending your password to any of them.

Updated Oct 8, 2026

Request More Info

Kerberos: a ticket for one service

Read your own Kerberos tickets

The klist command lists the tickets your computer holds. Paste its output and the reader explains each ticket:

Issued to. Who the ticket was issued to.
Service. Which service the ticket is for.
Encryption type. The type the ticket uses.
Flags. The ticket flags, in words.
Expiry. Whether the ticket has expired.

The reader is free and runs in your browser with no network request; expiry is judged against your browser’s clock, and the result says so.

Paste the klist output

Windows: run klist in a command prompt. MIT or Heimdal: run klist, or klist -e to include the encryption types and klist -f for the flags. Both layouts are recognized.

Private by design. Reading happens in this page and nothing is sent anywhere. Ticket listings hold user names, service names and host names: use a copy you are allowed to look at. A listing never contains the ticket or session key itself.

The rest of this page explains what the result means and how the tickets got there.

What Kerberos is

What is Kerberos?

It is a network authentication protocol in which the Key Distribution Center (KDC), a server that both sides trust, issues tickets. In short:

Sign in once. The user proves their identity to the KDC once and receives a ticket-granting ticket (TGT).
Trade the TGT. The client exchanges the TGT for a ticket to each service the user opens.
No shared password. No service ever sees the password.

Microsoft’s Kerberos overview (read 2026-10-09) covers the Windows implementation, and RFC 4120 defines the protocol.

In this example, Maria Lopez at Acme Corp signs in to her office laptop in the realm ACME.EXAMPLE, then opens https://sso.acme.example.

Three exchanges follow, all defined in RFC 4120: the authentication service exchange (section 3.1), the ticket-granting service exchange (section 3.3) and the client/server exchange (section 3.2).

One Kerberos sign-in, three exchanges

LaptopMaria Lopez
KDCKey Distribution Center
Web serverHTTP/sso.acme.example

Laptop to KDC1Sign in to Windows
KDC to Laptop2Ticket-granting ticket and session key
Laptop to KDC3Open the web site, presenting the TGT
KDC to Laptop4Service ticket for HTTP/sso.acme.example
Laptop to Web server5Present the ticket with an authenticatorThe authenticator proves the client holds the session key.
Web server6Opens the ticket with its own key and accepts Maria

The password goes to the KDC once. After that the TGT is traded for a ticket per service, and the web server never sees the password.

Step	Who talks to whom	What comes back
1. Sign in to Windows	Laptop to the KDC	A ticket-granting ticket (TGT) and a session key
2. Open the web site	Laptop to the KDC, presenting the TGT	A service ticket for `HTTP/sso.acme.example`
3. Present the ticket	Laptop to the web server	The server opens the ticket with its own key and accepts Maria

Microsoft’s overview adds two details. The client keeps the TGT in its ticket cache and reuses it until it expires.

The service ticket already carries what the service needs, so the service can authenticate the client without contacting a domain controller for each connection (read 2026-10-08).

The client also sends an authenticator that proves it holds the session key. This prevents an attacker from replaying a stolen ticket.

What are the KDC, realms and service principal names?

KDC. The server that issues tickets. In Windows Server it runs on every domain controller and uses the Active Directory database as its account store, according to the Microsoft overview. For how Active Directory differs from a plain LDAP directory, see LDAP vs Active Directory.
Realm. The Kerberos name of an administrative domain, written in capitals by convention: ACME.EXAMPLE. Realms can trust each other through shared inter-realm keys (RFC 4120, section 1.2).
Principal. Any identity Kerberos can authenticate: a user, a computer or a service. Microsoft calls this a security principal.
Service principal name (SPN). The name a service is known by, such as HTTP/sso.acme.example. For web sites using the Negotiate scheme, RFC 4559, section 4.1 (read 2026-10-09) says the server uses a principal of the form HTTP/hostname. The ticket is issued for that exact name, so a typo or an alias produces no ticket.

Why does the clock matter so much?

Kerberos detects replays with timestamps, so every host needs a clock that is loosely synchronized with the others.

Allowed difference. RFC 4120, section 1.6 makes it configurable per server, typically around five minutes.
The error. Beyond that, the server returns KRB_AP_ERR_SKEW (error 37, “clock skew too great”, section 7.5.9).
SSOGEN limit. SSOGEN uses the same limit: at most five minutes between a computer and the SSOGEN server.
Typical causes. A virtual machine restored from a snapshot or a laptop with a failed clock battery.

Fix the time synchronization rather than widening the tolerance.

Which encryption types should you see?

Each ticket uses an encryption type, shown by klist -e on MIT and Heimdal systems, and as KerbTicket Encryption Type on Windows (Microsoft’s klist reference, read 2026-10-08).

The MIT documentation on kdc.conf encryption types classifies them as follows.

MIT classification	Encryption types
Deprecated	`rc4-hmac` and `des3-cbc-sha1`
Weak	The exportable RC4 and `des3-cbc-raw`

Types marked weak or deprecated remain available for compatibility but are not recommended (read 2026-10-09).

The reader above follows that classification: it flags RC4 and DES as weak and AES as current.

How do you read klist output?

On MIT-style systems, klist -e -f prints the tickets with encryption types and flags. An Acme example in that style:

Ticket cache: FILE:/tmp/krb5cc_1000
Default principal: maria.lopez@ACME.EXAMPLE

Valid starting     Expires            Service principal
10/08/26 08:02:11  10/08/26 18:02:11  krbtgt/ACME.EXAMPLE@ACME.EXAMPLE
  renew until 10/15/26 08:02:11, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
  Flags: FRIA
10/08/26 08:14:40  10/08/26 18:02:11  HTTP/sso.acme.example@ACME.EXAMPLE
  Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96
  Flags: FRA

How to read it:

The first entry is the TGT. Its service is krbtgt/ACME.EXAMPLE@ACME.EXAMPLE, the ticket-granting service of the realm.
The second entry is the service ticket from step 2 of the walk-through. It names the SPN and expires no later than the TGT it came from.
In the MIT klist documentation (read 2026-10-09), F means forwardable, R renewable, I initial, A preauthenticated, and lowercase f means forwarded. The TGT is therefore initial (I) and preauthenticated (A); the service ticket is not initial.
If there is no service ticket for the expected SPN, the browser never requested one. Check the browser’s trusted-site setting or the SPN, not the KDC.

On Windows, plain klist prints Client, Server, KerbTicket Encryption Type, Ticket Flags, Start Time, End Time, Renew Time and Session Key Type for each ticket.

Three more klist commands help:

klist tgt. Shows the initial TGT with a TimeSkew field against the KDC.
klist get HTTP/sso.acme.example. Requests a ticket for one SPN, which shows whether a ticket for that name can be obtained.
klist purge. Deletes every ticket in the logon session; Microsoft warns that this can cut off access to resources until you log off and on again.

What are the common Kerberos errors?

RFC 4120, section 7.5.9 lists the error numbers. These are the most common:

Error	Number	Meaning in the RFC	Usual cause
Client principal not found (`KDC_ERR_C_PRINCIPAL_…`)	6	Client not found in the Kerberos database	Wrong user name or realm
Server principal not found (`KDC_ERR_S_PRINCIPAL_…`)	7	Server not found in the Kerberos database	The SPN is not registered, or the host was opened by an alias
`KDC_ERR_ETYPE_NOSUPP`	14	KDC has no support for the encryption type	Old and new encryption types disagree
`KDC_ERR_PREAUTH_FAILED`	24	Pre-authentication information was invalid	Wrong password
`KRB_AP_ERR_TKT_EXPIRED`	32	Ticket expired	Old ticket; purge and sign in again
`KRB_AP_ERR_REPEAT`	34	Request is a replay	The same authenticator was sent twice
`KRB_AP_ERR_SKEW`	37	Clock skew too great	Clocks more than the allowed difference apart

Domain controllers log failures as numbered Windows events. To decode 4768 and 4771 (Kerberos ticket requests and pre-authentication failures), paste them into the event 4768 decoder or the event 4771 decoder.

How do browsers use Kerberos with SPNEGO?

A browser does not speak Kerberos to the web server directly. It wraps the ticket in SPNEGO and sends it in an HTTP header. RFC 4559, sections 4 and 5 (read 2026-10-09) describe the exchange:

The server answers an unauthenticated request with 401 and WWW-Authenticate: Negotiate.
The browser retries with Authorization: Negotiate and a base64 token.
The server may run more 401 rounds until the security context is complete, then ends with a 200.

Browsers do this only for sites they are configured to trust. For SSOGEN, that means the AuthServerAllowlist policy for Chrome and Edge, or network.negotiate-auth.trusted-uris in Firefox.

A related failure is silent: if the SPN is missing or registered on two accounts, the browser can fall back to an older NTLM sign-in, and the server never sees a Kerberos ticket.

For the full web-application picture, see Kerberos SSO for web applications.

How SSOGEN uses Kerberos

SSOGEN uses Kerberos in two separate places.

A person on a domain-joined computer opens My Apps and lands on their applications, with no password page.

Browser. The browser sends the Windows ticket.
Keytab. SSOGEN opens the ticket with a keytab for the HTTP/ service name.
Directory. SSOGEN finds the person in Active Directory and signs them in.
AES only. SSOGEN accepts only AES keys, not RC4 or DES.
Single factor. SSOGEN counts this as a single-factor sign-in. If a policy requires a second factor, SSOGEN still asks for it.

Steps and the error table are in the Windows desktop sign-in guide.

Kerberos to the back end

Delegation. The SSOGEN Gateway App Proxy can ask a domain controller for a ticket on the employee’s behalf, using constrained delegation.
Windows-only applications. It hands the ticket to an application that only understands Windows authentication.
AES only. Tickets use AES only.

The setup and the SSO-KRB- error codes are in the form fill and Kerberos sign-in guide.

Questions people ask

What is Kerberos used for?

It proves identity on a network without sending a password to each service.

MIT calls it a network authentication protocol that lets a client prove its identity to a server, and the server to the client, across an insecure connection (read 2026-10-09).

Microsoft’s overview calls it the protocol for domain-based authentication in Windows Server.

What is the difference between LDAP and Kerberos?

Kerberos proves who you are. LDAP looks up and manages directory entries; RFC 4511 (read 2026-10-09) calls it access to distributed directory services. Active Directory uses both. See LDAP vs Active Directory.

Is Kerberos the same as Cerberus?

They are the same mythological dog with a different spelling.

The MIT team that built the protocol named it after the three-headed guard dog of Greek myth. The Greek name starts with a K, as the Athena dialogue explains (read 2026-10-09).

Is Kerberos the same as Active Directory?

No. Kerberos is the protocol. Active Directory is Microsoft’s directory, and its domain controllers run a KDC that speaks Kerberos.

What is the difference between a TGT and a service ticket?

The TGT proves the user signed in, and the client uses it only to request more tickets from the KDC. A service ticket is valid for one named service.

Does Kerberos send my password to each service?

No. According to Microsoft’s overview, after the first sign-in the TGT lets the client request service tickets without presenting the password again.

Why do I get prompted for a password in the browser?

Usually one of three causes:

the site is not on the browser’s trusted list
the computer is not on the corporate network
the SPN is wrong and the browser fell back to NTLM

Where to go next

Single sign-on. Read how single sign-on works.
Web applications. See Kerberos SSO for web applications.
SPN checks. To check an SPN or find duplicates, use the setspn command builder and SPN checker.
Learn hub. Go back to the Learn hub.

Sources, all read 2026-10-09: Microsoft Learn Kerberos authentication overview, MIT Kerberos kdc.conf documentation, RFC 4120.