Kerberos Authentication Explained

Every time a domain-joined Windows account authenticates to a service — logging in, mapping a network drive, opening an internal web app — Kerberos is almost certainly doing the work underneath, without the user ever seeing a password prompt after their initial login. This post covers what actually happens during that exchange, why the design uses two separate ticket types instead of one, and why a handful of specific settings (clock skew tolerance, ticket lifetimes, the krbtgt account) matter as much as they do in practice.

The core idea: prove identity without repeatedly sending a password

Kerberos exists to solve a specific problem: authenticating to many different services throughout a session without transmitting (or even re-deriving) a password each time, and without any single service ever needing to see or store the password directly. It does this with a trusted third party — the KDC (Key Distribution Center, a role every domain controller plays) — and a two-ticket system that separates "prove who you are, once" from "get access to this specific service."

Step one: getting a TGT

At logon, a client sends an AS-REQ (Authentication Service Request) to the KDC, and receives back a TGT (Ticket Granting Ticket) — encrypted with a key derived from the special krbtgt account's password, which only the KDC itself knows. The client can't read the TGT's contents at all; it just holds onto it and presents it for everything that follows. This single exchange is the only point in the entire process where the user's actual password (or a hash derived from it) is involved.

Step two: getting a service ticket

To actually access a specific service, the client sends a TGS-REQ (Ticket Granting Service Request) — presenting the TGT it already has, plus which service it wants — and the KDC issues a service ticket specific to that one service, encrypted with a key derived from that service's own account password, not the user's. This is the step that repeats for every different service accessed during a session, each time reusing the same TGT rather than re-authenticating with credentials.

Why splitting it into two tickets matters

A single combined ticket type would mean either re-authenticating with a password for every single service (defeating the entire point) or having one ticket usable everywhere, which would make a stolen ticket dramatically more dangerous and would require every service to somehow validate directly against the user's credential material. Splitting it means the TGT never leaves the client-to-KDC relationship, service tickets are scoped to exactly one service each, and a compromised service ticket only grants access to the one service it was issued for.

The PAC: how authorization data rides along

Microsoft's Kerberos implementation extends the standard protocol with a PAC (Privilege Attribute Certificate) embedded in the ticket, carrying the user's SID and the SIDs of every group they're effectively a member of — direct and nested. This is what lets a service check authorization immediately from the ticket itself, without a separate directory query, and it's also exactly why deep or broad group nesting can eventually hit real ticket-size limits (historically 12,000 bytes, MaxTokenSize) — a problem generally referred to as Kerberos token bloat.

Why krbtgt is the single most sensitive account in a domain

Every TGT the KDC issues is encrypted with a key derived from the krbtgt account's password hash. Obtaining that hash lets an attacker forge a valid TGT for any account — including Domain Admins — entirely offline, without ever touching that account's real credentials or triggering the authentication events a normal logon would produce. This is precisely the mechanism behind a Golden Ticket attack, and it's why remediation after a suspected domain compromise specifically includes rotating the krbtgt password — twice, with a deliberate delay between rotations, since outstanding tickets encrypted with the old key otherwise remain valid until they naturally expire.

Delegation: when a service needs to act on your behalf

Some scenarios need more than one hop — a web application authenticating a user, then needing to query a database as that same user rather than as its own service account, so the database's own permission checks apply correctly. Kerberos supports this through delegation, most safely via constrained delegation: an administrator explicitly lists exactly which downstream services a given service is allowed to request tickets on a user's behalf for, rather than granting blanket "impersonate anyone, for anything" trust. Unconstrained delegation — an older, far more permissive option that hands the intermediate service a copy of the user's own TGT — is now specifically flagged by security tooling and hardening guides as a serious risk, since compromising a server with unconstrained delegation configured effectively compromises every account that has ever authenticated through it.

Ticket lifetime and renewal

A TGT has a limited lifetime (10 hours by Active Directory's default Kerberos Policy) and, if issued as renewable, an absolute renew-till cap (7 days by default) measured from when it was originally issued — each renewal can extend the ticket's expiry, but never past that fixed cap, which forces a genuine re-logon with real credentials periodically no matter how actively the ticket is renewed in between.

Why clock synchronization is non-negotiable

Kerberos leans on timestamps specifically to prevent a captured, otherwise-valid exchange from being replayed later by an attacker who intercepted it — but that protection only works if the client and the KDC roughly agree on the current time. Windows domains enforce this strictly enough that a client clock drifting beyond the configured skew tolerance (5 minutes by default) fails authentication outright, a deliberate tradeoff favoring replay protection over convenience.

Common mistakes

• Treating clock drift failures as a Kerberos bug. It's the intended, deliberate behavior — the fix is fixing time sync, not loosening the skew tolerance as a first response.
• Underestimating krbtgt's sensitivity. It's not just another service account; its password is the root of trust for every ticket the domain issues.
• Setting an unusually long maximum ticket lifetime without weighing the tradeoff. A compromised ticket stays usable for exactly as long as that lifetime allows.
• Not accounting for PAC size when nesting groups deeply. Authorization data riding in the ticket has a real size limit, not an unlimited one.

FAQ

Try it yourself

Kerberos Ticket Lifetime Calculator computes a ticket's expiry, renew-till cap, and renewal outcome from your domain's Kerberos Policy settings, entirely in your browser.