Explain Kerberos Like I'm 5

Luke Hebert

- 3 minutes read - 511 words

You have probably heard “Kerberos” thrown around in a security meeting and felt the room go quiet. That is normal. The protocol is powerful, but the name and the moving parts make it feel intimidating. Here is the short version, and by the end you will be able to explain it to a colleague without reaching for a whiteboard.

The Core Idea

Kerberos is a ticket-based authentication system. Instead of typing your password to every single service on the network, you prove who you are once, get a set of tickets, and then show those tickets to other services. Think of it like a hotel key card: you check in at the front desk (prove your identity), get a card, and then use that card to open your room, the gym, and the pool without showing your ID again.

The Three Players

  • The Client - that is you, or your workstation. You want to access a resource.
  • The Key Distribution Center (KDC) - the authority that issues tickets. In a Windows environment this is typically an Active Directory domain controller.
  • The Service - the thing you actually want to reach, like a file share, a database, or an internal web app.

The Ticket Dance, Step by Step

  1. Ask for a Ticket-Granting Ticket (TGT). Your client sends a request to the KDC’s Authentication Server, saying “I am user X.” You prove it with your password (or a cached credential). The KDC replies with a TGT, encrypted with the TGT key.
  2. Ask for a Service Ticket. You take that TGT to the KDC’s Ticket-Granting Server and say, “I need to talk to the file server.” The KDC issues a Service Ticket, encrypted with the file server’s key.
  3. Access the Service. You present the Service Ticket to the file server. The server decrypts it, confirms the KDC signed it, and lets you in. Your password never travels to the file server.

Why It Matters

  • Password isolation. Your password is only used in step one. Every other interaction relies on tickets, so a compromised service cannot harvest your password.
  • Mutual authentication. The service can also prove its identity to you, so you are not talking to a rogue box on the network.
  • Single sign-on. One initial login covers many services, which is why Kerberos underpins Active Directory SSO in most Windows shops.

Common Gotchas

  • Clock skew. Kerberos tickets are time-stamped. If your workstation clock is more than five minutes off from the KDC, authentication fails. Check your NTP settings first.
  • SPN conflicts. If two services register the same Service Principal Name, the KDC may issue a ticket for the wrong one. Use setspn to audit.
  • Restricted delegation. By default, a service can pass your TGT to another service (delegation). In most environments you want to restrict this to only the services that truly need it.

A Quick Mental Model

If the analogy above helped, here is the one-liner: Kerberos is a trusted middleman that hands you pre-signed passes so you never have to flash your password at every door.

Reference