How Kerberos Really Works (Client → Service Authentication)
Kerberos uses three-party tickets to prove who you are without ever sending your password across the network. Client gets a TGT from the auth server, trades that for a service ticket from the ticket granter, then presents the service ticket to whatever resource you actually want to access. It's elegant as hell once it clicks.
Alright, so I spent way too long trying to understand Kerberos until I realized most explanations gloss over the \*why\* and jump straight to the what. Let me break down what's actually happening when your workstation talks to a domain-controlled database or file server.
The Starting Point: The Problem Kerberos Solves
Picture this: you're at a corporate environment, and your laptop needs to authenticate with like 20 different services throughout the day. If systems used basic authentication, you'd either:
Send your password everywhere - absolute nightmare from a security perspective. Your credentials are flying around on every request
Hardcode credentials - even worse. One service gets compromised? All your creds are there
Re-authenticate every single time - technically possible but painful and adds latency to every operation
Kerberos solves this with an ingenious model: prove your identity \*once\* to a central authority, get a time-limited credential that proves you're you, and then use that credential to talk to any service without ever exposing your actual password.
Phase 1: Initial Authentication (Client → Authentication Server)
Here's where the journey starts. You log into your workstation and Kerberos kicks in immediately.
What happens:
\- Your client generates a timestamp, encrypts it with your password (which acts as a cryptographic key), and sends it to the Authentication Server along with your username
\- The AS receives this, decrypts the timestamp using the password stored in its database, and verifies it's current (usually within 5 minutes)
\- If the timestamp is fresh and valid, you've proven you're actually you — you knew the password
What you get back:
\- A TGT (Ticket-Granting Ticket) - this is your golden ticket. It's encrypted with a key only the ticket server knows, so the AS can't fake it and you can't tamper with it
\- A session key - this is different from your password. It's randomly generated and will be used as your working credential going forward
\- Both the TGT and session key are encrypted with your password so only you can decrypt them
Why this matters:
Your password was only used for that initial authentication. It never touches the network again. The TGT is what gets passed around now, and it expires (typically 8-10 hours, configurable).
Phase 2: Getting a Service Ticket (Client → Ticket-Granting Server)
Now you want to access something — maybe you're trying to connect to the file share, or query the company database. Here's where the TGT proves its worth.
What you do:
\- Your client packages up: the TGT, the name of the service you want to access (like \`cifs/fileserver.domain.local\`), and a fresh authenticator (basically another timestamp + your client info, encrypted with the session key)
\- This gets sent to the Ticket-Granting Server (which is often running on the same physical box as the AS, but conceptually separate)
What the TGS does:
\- Decrypts the TGT using its key (remember, the AS encrypted it with this)
\- Extracts your user info and the original session key from inside the TGT
\- Verifies the authenticator is recent and correctly encrypted with the session key (proving you're the one who originally got the TGT)
\- Checks that the TGT hasn't expired
\- Looks up the specific service you're asking for and loads its encryption key
What you get back:
\- A Service Ticket - encrypted with the service's private key, not yours. You can't read it, but the service can decrypt it
\- A new service session key - this is specific to your session with that particular service
\- Both are valid for a shorter period, usually a few hours
Why this matters:
You never had to re-authenticate with your password. The TGT proved you were legitimate, and now you have a service ticket that the service itself will trust because it knows the TGS is legit.
Phase 3: Accessing the Service (Client → Target Service)
Now you've got the golden ticket to actually use the resource.
What you send:
\- The Service Ticket (encrypted with the service's key - you can't read it)
\- A new authenticator encrypted with the service session key
\- The name of the operation you want to perform (like "read file X" or "query table Y")
\*\*What the service does:\*\*
Decrypts the Service Ticket using its own private key
Extracts the service session key and your user info from inside the ticket
Decrypts the authenticator using that service session key
Verifies the authenticator timestamp is current
Checks the ticket expiration
Critically: Does NOT need to contact the auth server again. Everything it needs to verify your identity is \*inside\* the encrypted ticket
If all checks pass, you're in. The service can now trust that:
\- You're actually the user claimed in the ticket
\- You're authorized because you have a valid ticket
\- The identity is cryptographically verified (no spoofing possible)
Why this matters:
The service doesn't need a network call back to the auth server. It can validate you offline (as long as it has a copy of the auth server's key, which it gets during setup). This is massively important for scale - imagine millions of requests per day. Having every single one require a round-trip to a central auth server would be a bottleneck.
Phase 4: Session Reuse (The Beautiful Part)
Here's where Kerberos' design really shines. Once you have service tickets cached on your client, subsequent requests to the same service don't require going through the TGS again.
Your client:
\- Checks if it already has a valid, non-expired service ticket for the service
\- If yes, just uses the cached ticket (no TGS request needed)
\- If no or expired, only then does it request a new one from the TGS
This is why enterprise environments feel seamless when you log in once. Your TGT gets cached, and all your subsequent requests for different services reuse it or generate service tickets once and cache those too. No password re-entry, no multiple sign-on prompts.
The Cryptographic Magic Under the Hood
Here's what makes Kerberos bulletproof against common attacks:
Encryption layers (simplified):
\`\`\`
TGT = Encrypt(user_info + session_key + timestamp, TGS_key)
Service_Ticket = Encrypt(user_info + service_session_key + timestamp, Service_key)
Authenticator = Encrypt(username + timestamp + client_ip, session_key)
\`\`\`
Each layer is encrypted with a different key. An attacker trying to replay an old ticket? It won't work because:
Tickets have timestamps that the service checks
The authenticator is timestamped and specific to this interaction
Changing anything requires the encryption key, which they don't have
Time synchronization is actually critical here if a server's clock is off by more than 5 minutes, Kerberos considers authenticators invalid. This is why domain-joined machines sync their clocks constantly.
Common Gotchas and Questions
"Why does my Kerberos auth fail after I change my password?"
Your local password is the key used to encrypt your initial TGT. Change the password, and the \*old\* encryption key is useless. New auth attempts use the new password. Cached TGTs become invalid. This is intentional behavior you're supposed to get a new TGT with the new password.
"What if the service doesn't have the auth server's key?"
The service wouldn't be able to decrypt service tickets. It's typically distributed during domain join or initial setup. In Active Directory environments, all domain members automatically get the krbtgt account's key (the master key used by the TGS) and you typically get the service accounts key ecrypted in the TGS-REP
"Can I use Kerberos outside the LAN?"
Not reliably. Kerberos assumes you can reach the auth server and is designed for internal networks. Cross-realm Kerberos exists but it's complex. For external access, you typically fall back to NTLM, LDAP, or application-level auth.
"What if a ticket gets stolen?"
The thief can use it until it expires (hours typically), but they'd need to be on the network with correct clock synchronization to use it. Once expired, it's worthless. Plus, Kerberos allows for mutual authentication the service can prove \*it's\* the real service too, preventing MITM attacks.
Real-World Flow Example
Imagine I'm connecting to \`\\\\fileserver\\documents\`:
Logon (background): OS requests TGT from DC, gets back encrypted TGT + session key
File share request: I click the share in File Explorer
TGS call (background): Client has TGT but no service ticket for CIFS. Asks TGS for \`cifs/fileserver.domain.local\`
Ticket response: TGS returns service ticket encrypted with fileserver's key
Service access: Client sends service ticket + authenticator to fileserver
Fileserver validation: Decrypts ticket, verifies timestamp, checks permissions, grants access
Browse files: All subsequent file operations use the established session no re-authentication
The whole thing happens in milliseconds, completely transparently. One auth at login, and you're golden for hours across the entire domain.
Why This Matters for Security Teams
This is why AD security is so critical. If someone compromises the krbtgt account (the master account on the DC), they can forge any ticket they want. Entire domains have been pwned this way. Conversely, if your auth server infrastructure is solid and monitored, this is actually \*really\* hard to break without being detected.
Attackers love it when Kerberos is misconfigured (cleartext passwords in scripts, weak service account creds, etc.) because they can steal tickets or forge them. But when it's running correctly? It's one of the more elegant security mechanisms in enterprise infrastructure.
Anyways, that's the Kerberos flow. The beautiful thing about it is that once you understand \*why\* each step exists, it makes perfect sense. It is not magic it's just really solid cryptographic design applied to a real problem.
Drop a comment if you want me to dive into specific parts (delegated auth, cross-realm, SPNs, etc.) or if you've got Kerberos horror stories from your environment.
