FFoundationalActive Directory
Kerberos Authentication Fundamentals
Kerberos authentication rests on one design choice most people gloss over: the Key Distribution Center never remembers who is logged in. This lesson builds the mental model underneath that choice, how a self-contained ticket replaces a remembered session, why a TGT and a service ticket differ in scope rather than just name, and how identity gets proven without a password ever crossing the network.
This lesson builds on
Why it matters
Every technique lesson that touches Kerberos assumes you already have a working mental model of what a ticket is and why the KDC behaves the way it does. Before you can follow a detailed walkthrough of a ticket exchange, or explain why a specific attack targets one ticket type over another, you need a picture of the system that holds together on its own. That picture starts with statelessness, not with the session intuition most people bring from web authentication. Get this part wrong and every explanation you give afterward will sound like memorized trivia instead of understanding.
Key Concepts
- Stateless authentication — a design where the KDC and every service validate tickets on the spot, using the cryptographic proof inside the ticket itself, rather than checking a stored record of who is currently logged in
- Key Distribution Center (KDC) — the trusted domain authority that issues every ticket; it never has to remember a past exchange because each ticket it issues is self-contained proof
- Ticket Granting Ticket (TGT) — a general-purpose credential proving a user already authenticated to the domain; it is presented to request more specific service tickets, not to access a resource directly
- Service ticket — a credential scoped to one specific service; obtained by presenting a valid TGT, and required separately for every resource a user wants to access
- Pre-authentication — proving possession of the correct password-derived key by producing something only that key could generate, rather than transmitting the password itself
- Clock skew tolerance — the small allowed difference between a client's clock and a domain controller's clock, by default around five minutes; because tickets rely on timestamps instead of session state, authentication fails once clocks drift too far apart
Theory
Core idea
Most authentication systems people learn first are stateful. A web application sets a session cookie, and a server somewhere keeps a matching record that says this session belongs to this user until it expires. If that server restarts or loses the record, the session is gone and the user has to log in again.
Kerberos does not work that way. The Key Distribution Center never keeps a running record of who is currently authenticated. Every ticket a user holds is a self-contained, cryptographically sealed statement that the KDC issued it and vouches for what it says. A domain controller can validate a ticket the instant it sees one, without checking any list of active sessions, because the proof lives inside the ticket itself rather than in server memory. That is what stateless means here: no session table to consult, no state to lose, and no state that multiple domain controllers need to keep synchronized with each other.
Mental model
Think of a Kerberos ticket less like a wristband a bouncer remembers handing you, and more like a sealed claim check at a large coat room. The attendant behind the counter does not need to recognize your face or recall serving you ten minutes ago. The paper itself is the proof: it carries a stamp that cannot be forged without the attendant's key, and anyone holding a valid one gets served, no memory required on the attendant's part.
Kerberos issues two kinds of claim checks, and the difference between them is about scope, not just format. The TGT is a general claim check: it proves the coat room already confirmed who you are today, and you take it back to the counter repeatedly to request more specific tickets. A service ticket is a specific claim check, good for one item at one counter (one service on the domain), and you only get one after showing a valid TGT. Neither ticket requires the coat room to remember you between visits. Each is independently valid the moment it is presented, and each expires on its own, regardless of what else is happening on the network.
This is also where "no password on the wire" fits, not as an isolated fact but as a consequence of the design. If proving your identity meant sending your password to the KDC, the KDC would need to be trusted with a live, reusable secret on every single request. Kerberos avoids that by having you prove you possess the secret rather than reveal it. In practice, that means encrypting a small piece of data with a key derived from your password, so that only someone with the right password could have produced something the KDC can successfully decrypt back. This first step is called pre-authentication, and the exact mechanics of that exchange, what gets encrypted and when, are worth studying closely on their own. For the fundamentals, what matters is the shape of the idea: identity gets demonstrated through what you can compute, not through what you transmit.
Common misunderstandings
- Assuming Kerberos maintains a live "logged in" connection. There is no persistent tunnel between a client and the KDC. Every ticket request is a discrete, one-shot exchange. Nothing stays connected in the way a VPN or an SSH session does.
- Treating a TGT as a universal all-access pass. A TGT proves you authenticated to the domain, but it does not grant access to anything by itself. It only lets you request service tickets. Every actual resource still needs its own separate ticket.
- Confusing stateless with unlimited or unchecked. No session table does not mean no expiration. Tickets carry their own built-in lifetime, encoded in the ticket itself, precisely because there is no server-side session left to time out. The clock is baked into the credential.
- Assuming a fresh TGT gets requested for every single action. The opposite is true. A TGT is deliberately reusable for its lifetime so a user is not re-prompted constantly, which is exactly why a stolen TGT is so valuable: it keeps working across many service requests without the KDC ever noticing it changed hands.
Real-world context
Statelessness has a practical cost that shows up constantly in real AD environments: Kerberos leans hard on accurate clocks. Because there is no session state to fall back on, tickets rely on timestamps to prove they are current and to stop old tickets from being replayed. Windows domains tolerate only a small amount of drift between a client's clock and a domain controller's, by default around five minutes, before authentication starts failing outright.
This is why checking the time is one of the first troubleshooting steps for a confusing Kerberos failure in the field, and why virtualized lab environments, where clocks drift easily after a snapshot restore, are a classic source of authentication errors that have nothing to do with credentials at all. It is also why domain controllers themselves must stay tightly synchronized with one another. Statelessness is what lets any domain controller validate any ticket without first coordinating with the others, but that independence only holds if their clocks agree closely enough for the math to line up.
Communication
Interview answer
Kerberos is a stateless, ticket-based authentication protocol. Stateless means the KDC does not 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 is 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. Neither requires the KDC to remember an earlier exchange.
The reason none of this requires sending a password over the network is that Kerberos proves you possess the right secret instead of revealing it, by having you demonstrate you can produce something only that secret could produce. The exact protocol steps behind that proof are worth knowing in detail on their own, but the mental model starts with a stateless system built entirely on self-contained, expiring tickets.
Follow-up questions
- Why does a stateless design mean tickets need their own built-in expiration, when a stateful session could just be revoked directly?
- What is actually different in scope between a TGT and a service ticket, beyond which key encrypts them?
- Why does clock synchronization matter so much in a protocol that never sends a password?
- If nothing about Kerberos requires session state, why do domain controllers still need to communicate with each other at all?
- What would go wrong if a client tried to reuse an expired TGT?
