Kerberos is a network authentication protocol built on symmetric-key cryptography and a trusted third party. The current version, Kerberos 5, is standardized in RFC 4120 and underpins Microsoft Active Directory, many Linux and Unix environments, and a long tail of enterprise services. Its central insight is that a user should authenticate once to a central authority, then receive time-limited, cryptographically protected credentials — tickets — to present to individual services. The password never travels the network, and services never need to store it.
The Three Heads: KDC, TGT, and Service Tickets
At the center sits the Key Distribution Center (KDC), usually split into two logical services: the Authentication Server (AS) and the Ticket Granting Server (TGS). The KDC shares a long-term secret key with every user and every service in its realm. For users, that key is derived from their password; for services, it is a key stored in a keytab file.
| Component | Role |
|---|---|
| KDC | Trusted authority that knows every principal's long-term key |
| TGT | Ticket-Granting Ticket — proves you authenticated, lets you request service tickets |
| Service ticket | Proves your identity to one specific service for a limited time |
| Authenticator | A timestamp encrypted with the session key, proving you hold it right now |
The Exchange, Step by Step
The protocol's elegance is best seen in sequence. Suppose Alice logs in and wants to access a file server.
- 1. AS exchange. Alice's machine asks the AS to authenticate her. The AS replies with a session key and a Ticket-Granting Ticket, the whole reply encrypted so that only someone who knows Alice's password-derived key can unwrap it. If Alice's password is correct, her client decrypts it; if not, it gets gibberish. Crucially, the password itself was never sent.
- 2. TGS exchange. To reach the file server, Alice presents the TGT to the TGS along with a fresh authenticator. The TGS verifies the TGT (which it can, because it encrypted it), and issues a service ticket for the file server, encrypted with the file server's secret key.
- 3. Service exchange. Alice hands the service ticket to the file server. The file server decrypts it with its own key, reads who Alice is and the shared session key, and verifies her authenticator. Access granted — and the file server never contacted the KDC at all.
The authenticator is a timestamp encrypted with the session key. A captured ticket alone is useless without a fresh authenticator, which an attacker can't forge without the session key. This is also why Kerberos is famously sensitive to clock skew — by default, machines must agree on the time within five minutes, or tickets are rejected as potential replays.
What Kerberos Gets Right
Several properties made Kerberos durable for forty years:
- No password transmission. The user's secret never crosses the wire, defeating eavesdroppers in a way that early plaintext protocols could not.
- Mutual authentication. Optionally, the service proves its identity to the client too, so Alice knows she is talking to the real file server, not an impostor — conceptually related to the guarantees of mutual TLS.
- Single sign-on. One authentication yields a TGT good for many services, removing the friction of repeated logins.
- Stateless services. Each service validates tickets with its own key; the KDC isn't a bottleneck on every request.
Where It Breaks
Kerberos's age shows, and its failure modes are a staple of modern penetration tests against Active Directory.
The KDC is a single point of trust
The KDC knows everyone's keys. Compromise it — specifically, steal the key of the special krbtgt account that signs all TGTs — and an attacker can forge a "Golden Ticket": a TGT for any user, including domain admin, valid until the krbtgt key is rotated twice. This is among the most severe outcomes in enterprise security.
Offline cracking of weak secrets
Because tickets are encrypted with keys derived from passwords or service secrets, an attacker who captures the right ticket can attempt to crack it offline. Kerberoasting requests service tickets for accounts running services, then brute-forces the service account's password offline — devastating when service accounts have weak, non-expiring passwords. AS-REP roasting targets accounts configured without pre-authentication.
Pass-the-ticket
A ticket extracted from a compromised machine's memory can be replayed from another machine for its lifetime, much as stolen session tokens enable session hijacking on the web. Kerberos authenticates the ticket holder, and it cannot tell a legitimate holder from a thief.
Kerberos eliminated password transmission, but it relocated the risk to long-lived tickets and a central key store. The lesson generalizes: every authentication system trades one secret for another, and the security question is always "what is the new secret, and how well is it protected?"
Kerberos and the Broader Authentication Picture
Kerberos is a network-perimeter protocol: it assumes a trusted realm and a central authority. Modern identity has shifted toward token-based federation across organizational boundaries, and toward passkeys and other phishing-resistant credentials that bind authentication to public-key cryptography held on the user's device. The trajectory is away from any centrally held secret that, once stolen, unlocks everything.
That direction matters for privacy-focused systems. Haven deliberately avoids a Kerberos-style design where a central server holds the keys to everyone's identity. Instead, identity private keys are derived from and protected by a passphrase that never leaves the user's device, and the server stores only material it cannot use to impersonate anyone. There is no krbtgt-equivalent master key whose theft would compromise every account at once. Different problem, different era — but the same underlying question Kerberos forced the industry to ask in 1988: where does ultimate trust live, and what happens when that point falls?