Kerberos Authentication Fundamentals Brief
What It Is
Kerberos authentication is stateless: the Key Distribution Center (KDC) never keeps a running record of who is currently logged in. Every ticket a user holds is a self-contained, cryptographically sealed statement that the KDC issued it and vouches for what it says, so a domain controller can validate a ticket the instant it sees one, with no session table to consult.
The Coat Room, Not the Bouncer
Think of a ticket less like a wristband a bouncer remembers handing you, and more like a sealed claim check at a coat room: the attendant doesn't need to recognize your face, because the paper itself is the proof. A TGT is a general claim check proving the coat room already confirmed who you are today. A service ticket is a specific claim check, good for one item at one counter, and you only get one after showing a valid TGT.
Key Facts
- The KDC never remembers a past exchange; each ticket is self-contained cryptographic proof, validated on the spot
- A TGT proves domain authentication and is used to request service tickets; it doesn't grant access to any resource by itself
- A service ticket is scoped to one specific service; a separate one is required for every resource accessed
- Pre-authentication proves possession of a password-derived key by producing something only that key could generate; the password itself never crosses the network
- Tickets carry their own built-in lifetime, encoded in the ticket, because there's no server-side session to time out
- Clock skew tolerance defaults to around five minutes; authentication fails once client and domain-controller clocks drift further apart than that
Interview Phrasing
Kerberos is a stateless, ticket-based authentication protocol. Stateless means the KDC doesn't keep a record of who is currently logged in: every ticket is a self-contained, encrypted proof that stands on its own the moment it's presented, so a domain controller can validate it without checking any session list. There are two ticket types, and they differ in scope. The Ticket Granting Ticket proves you already authenticated to the domain and lets you request more specific tickets. A service ticket is scoped to one particular service, and you need a separate one for each resource you access. None of this requires sending a password over the network, because Kerberos proves you possess the right secret instead of revealing it.
Common Pitfalls
- Assuming Kerberos maintains a live logged-in connection: there's no persistent tunnel between client and KDC, and every ticket request is a discrete, one-shot exchange
- Treating a TGT as a universal all-access pass: it only lets you request service tickets, and every resource still needs its own separate ticket
- Confusing stateless with unlimited or unchecked: tickets carry their own built-in expiration precisely because there's no session table to time out
- Assuming a fresh TGT gets requested for every action: a TGT is deliberately reusable for its lifetime, which is exactly why a stolen TGT is so valuable