Kerberos authentication, explained from scratch
How tickets let you prove who you are once — and never send your password again.
Explain like I'm 5
Imagine a big theme park. At the front gate you show your ID once. In return you get a wristband that says “this person is allowed in today.”
Now you want to ride the rollercoaster. You don't show your ID again. You show your wristband to a little booth, and the booth gives you a single-ride token for that one ride. You hand the token to the ride operator and hop on.
The ride operator never sees your ID. They just trust the token, because only the park can make real tokens. And every token expires quickly, so a dropped one is useless minutes later.
You prove who you are once to a trusted gatekeeper, get a wristband (a ticket-granting ticket), and then collect short-lived tokens (service tickets) for each thing you want to use — all without ever sending your password to the rides themselves.
- 1Show your ID at the gateProve who you are to the KDC once and get a wristband (the TGT).
- 2Swap the wristband for a ride tokenAsk the KDC for a ticket to one specific service.
- 3Hand the token to the rideThe service trusts the ticket — no password, no call back to the gate.
Beginner
Kerberos is a network authentication protocol. Its job is to let a client prove its identity to a service over an untrusted network — without sending the password across the wire. It was created at MIT in the 1980s (named after the three-headed dog guarding the underworld) and is the default authentication mechanism in Active Directory, so almost every Windows domain on earth runs it.
It works using tickets and symmetric (shared-key) cryptography, coordinated by a trusted third party that both sides already trust.
Three reasons: (1) never transmit the password — only proofs derived from it; (2) single sign-on — log in once, reach many services; (3) mutual authentication — the client can verify the service is genuine too, not just the other way round.
There are three parties in every Kerberos conversation:
| Party | Role |
|---|---|
| Client | The user or machine that wants access (e.g. alice on her laptop). |
| KDC (Key Distribution Center) | The trusted gatekeeper. In Active Directory, every Domain Controller is a KDC. It has two sub-services: the AS and the TGS. |
| Service | The thing being accessed: a file share, web app, database, etc. Identified by a Service Principal Name (SPN) like HTTP/web01. |
The KDC has two halves:
- AS — Authentication Service: checks who you are and issues your wristband, the TGT.
- TGS — Ticket-Granting Service: takes your TGT and issues service tickets for specific services.
- 1Authenticate to the KDC (AS)Client proves its identity and receives a Ticket-Granting Ticket (TGT) plus a session key.
- 2Request a service ticket (TGS)Client presents the TGT and asks for a ticket to a specific SPN.
- 3Present the ticket to the serviceThe service validates the ticket on its own — it never has to phone the KDC.
A few more words you'll see everywhere:
| Term | Meaning |
|---|---|
| Principal | A unique identity in Kerberos: a user, computer, or service (e.g. alice@CORP.LOCAL). |
| Realm | The administrative domain, written in UPPERCASE (e.g. CORP.LOCAL). In AD the realm = the domain. |
| TGT | Ticket-Granting Ticket — your wristband, encrypted so only the KDC can read it. |
| Service ticket | A per-service token, encrypted with that service's key. |
| Keytab | A file holding a service's long-term key, so a service can decrypt tickets without a human typing a password. |
Intermediate
Kerberos is really three message exchanges. Each is a request/response pair, and each ticket is encrypted with a key only its intended reader holds. Follow the keys and the whole protocol makes sense.
1. The AS exchange (get a TGT). The client sends an AS-REQ containing its name and an encrypted timestamp (more on that in a second). The KDC looks up the client's long-term key — derived from the user's password — and replies with an AS-REP containing two things:
- A TGT, encrypted with the krbtgt key (a secret only the KDC knows). The client cannot read its own TGT — it just stores it and hands it back later.
- A session key for talking to the KDC, encrypted with the client's key so only the real alice can unwrap it.
2. The TGS exchange (get a service ticket). To reach HTTP/web01, the client sends a TGS-REQ: its TGT plus the SPN it wants. The KDC decrypts the TGT with the krbtgt key (proving it's genuine), then returns a TGS-REP with a service ticket encrypted with the service's own key, plus a new session key for client↔service.
3. The AP exchange (use the ticket). The client sends the service an AP-REQ: the service ticket plus a fresh authenticator (an encrypted current timestamp). The service decrypts the ticket with its own key, pulls out the session key, and uses it to validate the authenticator. Optionally it sends an AP-REP so the client knows the service is genuine too — that's the mutual authentication.
The service validates the ticket entirely on its own, using a key it already has. It never contacts the KDC during normal access. That's why Kerberos scales to huge networks: the KDC isn't in the path of every request.
Why the timestamp? The encrypted timestamp (the authenticator) proves the request is fresh, not a recording of an old one being replayed. Because timestamps must be recent, every machine's clock has to be roughly in sync — the default tolerance is 5 minutes. This is why Kerberos breaks the moment a server's clock drifts.
Modern Kerberos requires the client to prove it knows the password before the KDC sends an AS-REP, by encrypting that first timestamp with the user's key (PA-ENC-TIMESTAMP). Accounts with pre-auth disabled can be attacked offline — see AS-REP roasting in the deep dive.
Advanced
A Kerberos ticket isn't just an opaque blob — it has structured contents. Understanding what's inside explains both authorization and the attacks.
The PAC. In Active Directory the KDC stuffs a Privilege Attribute Certificate into tickets. It contains the user's SID and group memberships — i.e. authorization data. The service reads the PAC to decide what you can do, rather than querying the directory itself. The PAC is signed by the KDC so it can't be tampered with… in theory (see the deep dive).
Encryption types (etypes). Kerberos is crypto-agile. The important ones today:
| Etype | Status |
|---|---|
| AES256-CTS-HMAC-SHA1-96 / AES128 | Current standard. Prefer these everywhere. |
| RC4-HMAC (arcfour) | Legacy. Keyed directly from the NT hash — weak and the root of Kerberoasting. Disable it. |
| DES | Broken. Should be long gone. |
SPNs and service keys. A service ticket is bound to a Service Principal Name (e.g. MSSQLSvc/db01.corp.local:1433). The service decrypts it with its own long-term key — which for a Windows computer is the machine-account password, and for a service account is that account's password (stored in a keytab on Linux/Unix). This is why what password protects a ticket matters so much.
Delegation lets a service act on behalf of a user to reach a further back-end (think a web app querying a database as you). There are three flavours, in increasing safety:
- Unconstrained delegation — the front-end receives a forwardable TGT and can impersonate the user to anything. Dangerous; avoid.
- Constrained delegation (S4U2Proxy) — limited to a specific list of SPNs the service may delegate to.
- Resource-based constrained delegation (RBCD) — the resource decides who may delegate to it, configured on the target. The modern, least-bad option.
Constrained delegation exists because of a real limitation: a service that authenticated you with Kerberos can't reuse your ticket to reach a second back-end on your behalf — the ticket was minted for it, not the database behind it. Delegation (S4U2Proxy / RBCD) is the sanctioned way to bridge that second hop. The same limitation is why NTLM authentication to a web app often can't reach a SQL back-end at all.
To reach a service in another realm, the client gets a referral ticket for the trusted realm from its own KDC, then talks to the remote KDC. Trust chains are walked one hop at a time using inter-realm krbtgt keys.
Deep dive
Almost every well-known Active Directory attack is really a Kerberos attack. Knowing the protocol turns these from scary names into obvious consequences.
| Attack | How it works | Defence |
|---|---|---|
| Kerberoasting | Any authenticated user can request a service ticket for any SPN. Tickets encrypted with RC4 are keyed from the service account's password, so the attacker cracks it offline. | Long random passwords / gMSA, AES-only, alert on bulk TGS-REQ (4769). |
| AS-REP roasting | Accounts with pre-auth disabled return an AS-REP encrypted with the user's key — crackable offline, no creds needed first. | Never disable pre-auth; strong passwords. |
| Golden Ticket | With the krbtgt hash, an attacker forges any TGT for any user — total domain compromise. | Protect DCs; rotate krbtgt twice after compromise. |
| Silver Ticket | With a service account key, forge a service ticket directly — bypasses the KDC entirely. | Strong service passwords; PAC validation. |
| Pass-the-Ticket | Steal a ticket from a machine's memory and reuse it elsewhere. | Credential Guard, limit admin logons, short lifetimes. |
The krbtgt key encrypts every TGT in the domain. Anyone who learns it can mint a Golden Ticket and impersonate anyone, indefinitely. After any suspected DC compromise you must reset krbtgt twice (it keeps the previous key for one generation to avoid breaking active tickets).
Flexible Authentication Secure Tunneling (FAST) wraps the Kerberos pre-auth exchange inside an encrypted channel keyed by the machine's credentials, so the AS-REQ/REP can't be sniffed and brute-forced offline. It's the main hardening against AS-REP/Kerberoast-style offline attacks and underpins Windows' Kerberos Armoring and Protected Users group. Enable it where your domain functional level allows.
The PAC carries your group memberships, so forging or tampering with it is a privilege-escalation jackpot — the class of bugs behind CVE-2021-42287/42278 (sAMAccountName spoofing) and the 2022 PAC signature fixes (CVE-2022-37967). Keep domain controllers patched and enforce PAC signature validation; an unpatched DC will trust a PAC it should reject.
Ticket lifetimes bound the blast radius. Defaults are roughly a 10-hour ticket life with renewal up to 7 days. Shorter is safer but noisier. Renewable tickets let long sessions continue without re-entering the password, up to the renew-till limit.
Hardening checklist:
- Enforce AES and disable RC4/DES domain-wide.
- Use group Managed Service Accounts (gMSA) so service passwords are long, random and auto-rotated.
- Remove unconstrained delegation; prefer RBCD.
- Keep clocks in sync (NTP) — Kerberos dies past ~5 minutes of skew.
- Monitor events 4768 (TGT issued), 4769 (service ticket issued), 4624 (logon) for anomalies.
Seeing it for yourself. On Windows, klist shows your cached tickets; on Linux, klist reads the credentials cache after kinit:
# Linux / macOS
kinit alice@CORP.LOCAL # get a TGT (you'll be prompted for the password)
klist # list cached tickets
# Example output:
# Ticket cache: FILE:/tmp/krb5cc_1000
# Default principal: alice@CORP.LOCAL
#
# Valid starting Expires Service principal
# 06/20/26 09:14:02 06/20/26 19:14:02 krbtgt/CORP.LOCAL@CORP.LOCAL <-- the TGT
# 06/20/26 09:15:31 06/20/26 19:14:02 HTTP/web01.corp.local@CORP.LOCAL <-- a service ticket
# Windows: list SPNs registered to an account
setspn -L svc_sqlKerberos uses a trusted KDC and symmetric keys so you authenticate once (getting a TGT), then collect per-service tickets the services validate offline. Passwords never cross the wire; freshness comes from synced clocks. Its security rests entirely on the secrecy of a handful of keys — your password, each service's key, and above all the domain's krbtgt key.
Frequently asked questions
What is the difference between a TGT and a service ticket?
A TGT (Ticket-Granting Ticket) is your master credential, issued once at logon and encrypted with the KDC's krbtgt key — you use it to request other tickets. A service ticket is issued per service, encrypted with that service's key, and is what you actually present to access a resource.
Does Kerberos encrypt my data?
Not by itself. Kerberos handles authentication and establishes a shared session key. Applications can use that key to encrypt traffic, but confidentiality of your data is up to the application/protocol (e.g. SMB encryption, LDAPS, TLS).
Why does Kerberos need accurate time?
Requests include encrypted timestamps to prevent replay attacks. If a client's clock differs from the KDC's by more than the allowed skew (5 minutes by default), authentication fails. This is the single most common cause of Kerberos errors.
Is Kerberos the same as NTLM?
No. NTLM is an older challenge-response protocol with no trusted third party and weaker properties (no mutual auth, vulnerable to relay). Active Directory prefers Kerberos and falls back to NTLM only when Kerberos can't be used (e.g. connecting by IP instead of hostname).
What is the KDC in Active Directory?
Every Domain Controller acts as the KDC. It runs both the Authentication Service (issues TGTs) and the Ticket-Granting Service (issues service tickets), and holds the krbtgt key plus every account's keys.
Why is Kerberoasting possible at all?
Any authenticated user may request a service ticket for any SPN, and that ticket is encrypted with the service account's password-derived key. If that password is weak (and especially if RC4 is allowed), an attacker can crack it offline without ever touching the service.
ShellQuest turns concepts like this into bite-sized lessons, puzzles and labs you actually practise.
Join the waitlist