It is 9 a.m. on a Monday. You type your password once to log into your work laptop. Then the day just happens: the shared drive opens, the intranet loads, Outlook connects, you print to the machine down the hall, you SSH into a build server. Not one of those systems asked for your password. Somehow, they all know who you are.
That quiet magic is, in most corporate networks, Kerberos. It has been running underneath Windows Active Directory since 2000, underneath countless Linux and Hadoop environments, and underneath your working day, largely invisible. It is also famously hard to explain, which is unfair, because the core idea is one you already understand: a wristband at an amusement park.
The problem Kerberos solves
Picture a network with 500 users and 50 services: file servers, databases, mail, printers. Every service needs to answer one question about every request: who is this, really?
The naive answer is to send your password to each service. That fails three ways. First, the password crosses the network 50 times a day, and Kerberos was designed at MIT in the 1980s for networks where anyone could be listening; that assumption has aged well. Second, every service now stores or checks passwords, so every service is a place your password can leak. Third, nothing proves the service is genuine. A fake file server can happily collect passwords all day.
Kerberos solves all three with a single move: nobody ever sends a password across the network, and no service ever sees one. Instead, a trusted third party vouches for everyone, using cryptographic proof. You authenticate once, and for the rest of the day you present tickets: the wristband that gets you onto every ride without queueing at the ticket booth again.
The cast: three parties, two secrets
Every Kerberos exchange involves three parties, which is why the protocol is named after the three-headed dog guarding Hades.
The client is you, or software acting as you. The service is what you want to reach: a file share, a database, an HTTP endpoint. The Key Distribution Center, or KDC, is the trusted third party. In Active Directory, every domain controller is a KDC.
Now the part that unlocks everything. The KDC shares a long-term secret with every principal in the realm (the Kerberos word for a domain). Your secret is derived from your password. A service's secret is a random key stored in a file called a keytab, or held by the machine account in AD. But you and the service share nothing with each other. The entire protocol is a scheme for two strangers to establish trust using only their separate relationships with the same mutual friend.
The KDC has two internal roles that appear constantly in documentation: the Authentication Service (AS), which handles your initial login, and the Ticket Granting Service (TGS), which issues tickets for specific services afterward. Think of the AS as the entrance booth where you pay once, and the TGS as the wristband checker who hands out ride tokens all day without asking for your money again.
The one idea that makes it click
Before walking through the messages, here is the insight most explanations bury. Every reply the KDC sends you has the same two-part shape:
- One part encrypted with your key. You can open it. Inside is a fresh session key.
- One part encrypted with someone else's key. You cannot open it. You just carry it, sealed, to the next hop. That sealed part is the ticket.
A ticket is a sealed envelope, written by the KDC, addressed to a service, saying: "The bearer is alice. Here is a copy of the session key I gave her. Trust anyone who can prove they hold it." You ferry envelopes you cannot read. The service opens its envelope with its own long-term key and finds everything it needs, without ever calling the KDC. That is the whole trick. Everything else is bookkeeping.
How it works: six messages
Here is a full working day, compressed into three round trips.
Round 1: logging in (AS exchange)
At 9 a.m. you type your password. Your machine never sends it anywhere. Instead it sends the AS a request: "I am alice@CORP.EXAMPLE.COM", along with the current timestamp encrypted using the key derived from your password. This is pre-authentication: only someone who knows the password could have encrypted that timestamp correctly, so the KDC can verify you without the password ever leaving your keyboard.
The AS replies with the two-part shape from Figure 2. The part you can open contains session key number one. The sealed part is a special ticket called the Ticket Granting Ticket, or TGT: an envelope addressed to the KDC's own ticket desk, the TGS. The TGT is your wristband. It typically lives for 10 hours, which is why you log in once per working day.
Round 2: getting a ticket for a service (TGS exchange)
At 9:03 you open the file share. Your machine notices it has no ticket for it, so it asks the TGS: "Here is my TGT, and here is proof I own it. Please give me a ticket for cifs/fileserver.corp.example.com."
That name is a Service Principal Name, or SPN: the unique registered identity of a service. Most real-world Kerberos failures are SPN problems: a missing SPN, a duplicate SPN, or a client asking for a name the service never registered. When an engineer mutters about SPNs, this step is what is failing.
The proof of ownership is an authenticator: your name and the current time, encrypted with session key one. A thief who steals your TGT off the wire cannot forge this, because the session key was delivered inside the envelope only your password could open. The TGS opens the TGT with its own key, finds the matching session key inside, checks your authenticator, and is satisfied.
Back comes the same two-part shape: session key number two for you, and a sealed service ticket addressed to the file server, containing your name and a copy of key two.
Round 3: talking to the service (AP exchange)
You hand the file server its envelope, plus a fresh authenticator encrypted with key two. The server opens the ticket with its keytab, finds key two inside, checks your authenticator against it, and now knows two things with certainty: the KDC vouched for alice, and the person at the other end holds the matching key. You are in. The server never contacted the KDC and never saw a password.
Optionally, the server replies with your timestamp encrypted under key two. Only the genuine service could have opened the ticket to extract that key, so this proves the server's identity to you. That is mutual authentication, and it is what kills the fake-file-server attack.
The fine print worth knowing
Clocks matter. Authenticators are timestamps, and the whole replay defence assumes everyone agrees what time it is. Kerberos tolerates about five minutes of skew by default. A machine with a drifted clock produces the classic, cryptic KRB_AP_ERR_SKEW failure; this is why domain-joined machines aggressively sync via NTP, and why "have you checked the clock" is the first question in any Kerberos incident.
Tickets expire. A stolen service ticket is bad, but it is bad for hours, not forever, and it works for one service only. Compare that with a stolen password. Tickets can also be renewable up to a longer limit, typically seven days, so long-running jobs can keep refreshing without a stored password.
Realms can trust each other. Cross-realm authentication lets a user in one realm reach services in another via trust relationships between KDCs. This is the machinery behind Active Directory forest trusts.
Delegation exists, carefully. Sometimes a web server must call a database as you. Kerberos supports forwarding your identity through delegation, and modern deployments constrain it tightly, because unconstrained delegation is a gift to attackers.
It is not magic armour. Attacks like Kerberoasting (offline cracking of service tickets to recover weak service-account passwords) and Golden Tickets (forging TGTs after stealing the KDC's own krbtgt key) attack the secrets around the protocol rather than the protocol itself. The lesson is old: the cryptography holds; the passwords and key hygiene are where it breaks.
Where you have already met it
If you have ever logged into a Windows machine on a corporate domain, you have used Kerberos; it has been Active Directory's default authentication protocol since Windows 2000. Your browser uses it when an intranet site logs you in without a prompt: the Negotiate header you may have seen in dev tools is SPNEGO carrying a Kerberos ticket over HTTP.
On Linux, kinit obtains a TGT, klist shows your cached tickets, and kdestroy throws away the wristband. A "kerberized" Hadoop or Kafka cluster is one where every daemon authenticates this way using keytabs. SSSD joins Linux boxes to AD realms. MIT Kerberos and Heimdal are the two open-source implementations you will meet, and Microsoft's is interoperable with both.
Summary
Strip away the acronyms and Kerberos is one idea applied twice. Two strangers can trust each other if a mutual friend hands each of them the same secret, delivered in envelopes only the right party can open. You open yours with your password. The service opens its envelope, the ticket, with its keytab. Proving you hold the shared secret, freshly and with a timestamp, proves who you are; the service proving it back proves who it is. No password crosses the wire, no service stores one, and the KDC vouches for everyone without being in the middle of anything after breakfast. The AS exchange buys the wristband, the TGS exchange hands out ride tokens, and the rides never phone the ticket office. Once you see the sealed-envelope shape, every Kerberos diagram you have squinted at for 20 years becomes the same picture drawn three times.
Part of the Explained series — concepts in tech, clearly.