How Kerberos Works: Tickets, the KDC & Why AD Needs It

Kerberos is the authentication protocol that quietly runs underneath most Windows networks. When a user logs into a domain and then reaches a file server, a database, and an internal web app without typing their password again, Kerberos is what made that work. It was designed at MIT decades ago, standardised as RFC 4120, and adopted by Microsoft as the default authentication protocol in Active Directory.

The design solves a hard problem: how do you let a user prove who they are to many services, over an untrusted network, without any of those services ever handling the user's password. The answer is tickets, issued by a trusted third party, encrypted so they can only be read by their intended recipient. Understanding that mechanism is the foundation for understanding almost every Active Directory attack.

The players

Kerberos involves three parties, plus a trusted broker.

• The client. The user or machine trying to prove its identity.
• The service. The resource the client wants to reach, a file share, a web application, a database.
• The Key Distribution Center (KDC). The trusted broker that vouches for identities by issuing tickets. In Active Directory, every domain controller is a KDC.

The KDC runs two internal services that map to the two stages of the flow:

• The Authentication Service (AS) handles the initial login and issues the Ticket Granting Ticket.
• The Ticket Granting Service (TGS) issues per-service tickets to clients that already hold a valid TGT.

The whole scheme rests on shared secrets. Each account, whether a user or a service, has a secret key derived from its password, known to it and to the KDC. Nobody else holds it. Encryption with these keys is what makes a ticket trustworthy.

The two ticket types

Two kinds of ticket carry the whole protocol.

Ticket	Issued by	Proves	Used to
Ticket Granting Ticket (TGT)	Authentication Service	The user authenticated once	Request service tickets from the TGS
Service Ticket (TGS ticket)	Ticket Granting Service	The user is entitled to one specific service	Access that single service

The TGT is like a wristband you get at the door: it proves you were checked in, and you show it to get access to individual attractions. The service ticket is the access to one attraction. Both are time-limited, which bounds how long a stolen ticket stays useful.

The full flow, step by step

Here is the exchange when a user logs in and then reaches a service. There are three round trips.

Stage 1: Authentication Service exchange (getting the TGT)

1. The client sends a request to the AS, including a timestamp encrypted with the key derived from the user's password. This proves the client knows the password without sending it.
2. The KDC, which also knows that key, decrypts the timestamp. If it checks out, the user is authenticated.
3. The KDC returns a TGT. The TGT is encrypted with the KDC's own secret (the krbtgt account key), so the client cannot read or alter it. Alongside it, the KDC sends a session key encrypted with the user's key.

Stage 2: Ticket Granting Service exchange (getting a service ticket)

4. When the client wants to reach a specific service, it sends the TGT to the TGS, along with an authenticator proving current possession of the session key.
5. The TGS decrypts the TGT with the krbtgt key, confirms it is valid, and issues a service ticket for the requested service. That ticket is encrypted with the target service's own key.

Stage 3: Client-server exchange (using the service)

6. The client presents the service ticket to the service. The service decrypts it with its own key, reads the user's identity and permissions from inside, and grants access. The service never contacted the KDC and never saw the user's password.

The elegance is in step 6. The service trusts the ticket because only the KDC could have produced something encrypted with the service's key that also contains a valid, KDC-signed identity. Microsoft's Kerberos authentication overview walks the same flow in Windows terms.

One detail matters for later. When the client asks the TGS for a service ticket, it identifies the service by its Service Principal Name (SPN), a unique name that ties a service instance to the account running it. The TGS looks up the account behind that SPN and encrypts the service ticket with that account's key. This is why any authenticated user can request a service ticket for any registered service, and why the encryption of that ticket is only as strong as the service account's password. Hold that thought: it is the exact seam kerberoasting exploits.

Why time matters

Kerberos leans heavily on timestamps. The authenticators that prove a client currently holds a session key are timestamped, and the KDC rejects ones that fall outside a small tolerance window (five minutes by default). This blocks replay: an attacker who captures an authenticator cannot reuse it later, because the timestamp will have expired.

The practical consequence is that clocks across the domain must stay synchronised. When Kerberos breaks in a way that looks random, skewed clocks are a common cause. Time is a security control here, not just a convenience.

Tickets also carry their own lifetimes. A TGT is valid for a set period, after which it must be renewed or reissued, and service tickets expire on their own schedule. These bounds exist so a stolen ticket does not stay useful forever. The catch is that a forged ticket can lie about its own lifetime, which is part of what makes the golden ticket attack so durable, so the expiry model protects you only against theft of genuine tickets, not against an attacker who can mint their own.

Why this is the heart of AD security

Kerberos is not an academic curiosity in Active Directory, it is the machinery every domain logon runs through, which makes the ticket system the highest-value target on the network.

Look again at the krbtgt account. Every TGT in the domain is encrypted with its key. If an attacker steals that key, they can forge TGTs for any user, including domain administrators, with any privileges and long lifetimes. That is the golden ticket attack, and it is devastating precisely because of how central krbtgt is to the protocol.

Other attacks follow the same seams:

• Kerberoasting requests service tickets for accounts running services, then cracks the ticket encryption offline to recover the service account password, because that ticket is encrypted with the service account's key.
• Pass-the-ticket steals a valid ticket from memory and replays it, since a ticket is a bearer token: whoever holds it is treated as its owner until it expires.

All of these map to MITRE ATT&CK T1558, Steal or Forge Kerberos Tickets. Every one of them makes sense only once you can see the ticket flow, which is why this mechanism is the prerequisite for the rest of AD security. Our threat group intelligence tracks which intrusion sets rely on Kerberos ticket abuse, so you can see whether the techniques you are hardening against are ones active groups actually use.

How to keep Kerberos secure

Kerberos is well designed, so most of the defensive work is operational discipline around it.

1. Guard the krbtgt account. Rotate its key on a schedule and after incidents (twice, in sequence), and restrict who can read domain controller memory where its key lives.
2. Use strong, long service account passwords, or better, group managed service accounts, so kerberoasted tickets cannot be cracked offline in reasonable time.
3. Keep domain controllers patched and hardened, because a KDC compromise is a total compromise.
4. Enforce strong encryption types and retire weak legacy ciphers that make offline cracking faster.
5. Keep clocks synchronised across the domain so replay protection works and Kerberos stays reliable.
6. Monitor for anomalies in ticket requests: unusual service ticket volume (kerberoasting), tickets with impossible lifetimes (golden tickets), and logons that skip expected steps.

A worked example: one logon, three exchanges

Tracing a single logon makes the ticket flow concrete. Picture a user named Ana sitting down at a domain-joined workstation and later opening a file share on a server called FS01.

When Ana types her password, the workstation derives her secret key from it locally. It builds an AS-REQ to the domain controller, and in Kerberos preauthentication it includes a timestamp encrypted with Ana's key. The domain controller, which stores Ana's key, decrypts the timestamp. If it decrypts to a sensible current time, the controller is satisfied that whoever sent the request knows Ana's password, without that password ever crossing the network. This preauthentication step is important, because accounts that have it disabled can be attacked offline, which is the basis of AS-REP roasting.

The domain controller replies with an AS-REP containing two things. The first is a TGT, encrypted with the krbtgt account key, which Ana's workstation cannot read or alter. Inside the TGT sits Ana's identity, her group memberships in a structure called the PAC, and a session key. The second is a copy of that same session key, encrypted with Ana's own key so only her workstation can extract it. Ana's machine now holds a TGT it cannot read and a session key it can.

Later, Ana opens \\FS01\share. Her workstation needs a service ticket for the file service on FS01, so it sends a TGS-REQ to the domain controller. That request includes the TGT and an authenticator, a fresh timestamp encrypted with the session key, which proves the machine currently holds the session key that the TGT was issued with. The workstation names the service it wants by its Service Principal Name, something like cifs/FS01. The domain controller decrypts the TGT with the krbtgt key, validates the authenticator, looks up the account behind that SPN, and issues a service ticket encrypted with that service account's key. It also returns a new service session key for Ana to use with FS01.

Ana's workstation sends the service ticket to FS01 in an AP-REQ. FS01 decrypts the ticket with its own account key, reads Ana's identity and groups from the PAC inside, and grants or denies access based on that. FS01 never contacted the domain controller during this exchange and never saw Ana's password. The trust flows entirely from the fact that only the domain controller could have produced a ticket encrypted with FS01's key that also carries a coherent, controller-issued identity.

Kerberos versus NTLM

Kerberos replaced NTLM as the default in Active Directory, and understanding the contrast explains many defensive choices.

Property	NTLM	Kerberos
Model	Challenge and response	Ticket issued by a trusted third party
Trusted broker	None, the server validates directly	The KDC (every domain controller)
Mutual authentication	Not by default	Supported, the service can be authenticated to the client
Replay protection	Weaker, relay attacks are practical	Timestamps and authenticators bound to a session
Password exposure	A crackable hash traverses the exchange	No password material crosses the wire
Common abuse	Relay, pass-the-hash	Kerberoasting, golden and silver tickets, pass-the-ticket

NTLM still exists in Windows for cases where Kerberos cannot be used, such as connecting to a host by IP address rather than by name, since there is no SPN to request a ticket for. Attackers often try to force a fallback to NTLM precisely because it is easier to relay, which is why reducing NTLM use is a recurring hardening goal.

Detection signals: what ticket abuse looks like

Kerberos abuse leaves traces in domain controller logs and in ticket behavior, and knowing the signals turns the attacks from invisible to catchable.

Kerberoasting shows up as a burst of service ticket requests, logged as Kerberos service ticket operations, especially requests for many different SPNs from one account in a short window, and requests that ask for a weaker encryption type such as RC4 when the environment otherwise uses AES. An account harvesting service tickets to crack offline tends to request far more of them than normal use would.

Golden and silver tickets are forged, so they can carry values a legitimate KDC would never produce. Tickets with unusually long lifetimes, tickets for accounts that do not exist or were deleted, and tickets whose internal fields are inconsistent with domain policy are all signals. A golden ticket also lets an attacker skip the AS exchange entirely, so a service being accessed with a ticket for which no corresponding TGT request was ever logged is suspicious.

Pass-the-ticket reuses a genuine ticket from another machine, so the signal is context: the same ticket or account authenticating from a host or at a time that does not fit the user's pattern, or a ticket appearing on a machine the user never logged into. Encryption downgrade, sudden RC4 use in an AES environment, is a recurring thread across several of these attacks, because RC4 keys are faster to crack offline.

How Kerberos reached Active Directory

The protocol began as part of MIT's Project Athena in the 1980s, named after the three-headed dog of myth for its three parties: the client, the service, and the trusted broker. Version 5, standardized as RFC 4120, is the one in use today, and it fixed encryption and extensibility limits in the earlier versions. Microsoft adopted Kerberos version 5 as the default authentication protocol when Active Directory shipped, layering its own extensions on top, most visibly the PAC that carries authorization data inside tickets. That history is why a decades-old academic protocol now sits at the center of enterprise Windows security, and why its original design goal, authentication across a hostile network with no password exposure, still describes exactly what it does.

Common misconceptions

A few beliefs about Kerberos cause real mistakes.

The first is that a service ticket is checked with the domain controller each time it is used. It is not. The service validates the ticket itself using its own key, which is why the domain controller does not see the client-server exchange, and why a silver ticket forged with a service account key can be accepted without the domain controller ever being involved.

The second is that resetting a compromised user's password undoes a golden ticket. It does not. A golden ticket is forged with the krbtgt key, so it is independent of any single user's password. Only rotating the krbtgt key, twice in sequence, invalidates outstanding golden tickets.

The third is that any authenticated user requesting a service ticket is inherently suspicious. It is not, because requesting service tickets is normal Kerberos operation. What distinguishes kerberoasting is the volume, the spread across many SPNs, and often the request for a weaker cipher, rather than the act of requesting a ticket itself.

The fourth is that Kerberos secures the network by itself. It authenticates identities, and it depends on synchronized clocks, protected account keys, and hardened domain controllers to do so. The protocol is sound, and the failures in practice come from the secrets and infrastructure around it.

Frequently asked questions

Why does Kerberos care so much about clock synchronization? The authenticators that prove a client currently holds a session key are timestamped, and the KDC rejects timestamps outside a small tolerance, five minutes by default. This blocks replay of captured authenticators. If clocks drift beyond the tolerance, legitimate authentication fails, which is why time synchronization across the domain is a hard requirement rather than a nicety.

What exactly is the krbtgt account? It is a special account whose key encrypts every TGT in the domain. It is not used to log in interactively. Because its key protects all TGTs, an attacker who obtains it can forge TGTs for any user with any privileges, which is the golden ticket attack. This is why the krbtgt key is the single most sensitive secret in an Active Directory domain.

How is a golden ticket different from a silver ticket? A golden ticket is a forged TGT, made with the krbtgt key, and it grants the attacker the ability to request service tickets for anything. A silver ticket is a forged service ticket, made with a single service account's key, and it grants access only to that one service. A silver ticket is narrower but stealthier, because it never touches the domain controller.

Why can any user request a service ticket for any service? Kerberos issues a service ticket to any authenticated user who names a valid SPN, and the ticket is encrypted with that service account's key. This is by design, so services do not have to query the KDC on every access. The side effect is kerberoasting: an attacker requests tickets for service accounts and cracks them offline, so the strength of a service account's password directly determines how resistant it is.

Does Kerberos encrypt the data sent to a service? Kerberos authenticates the parties and can establish session keys, and applications can use those keys to protect their traffic. Whether the actual application data is encrypted depends on the service and protocol layered on top. Kerberos itself is an authentication protocol, and confidentiality of the payload is a separate concern handled by the application.

What is the PAC inside a ticket? The Privilege Attribute Certificate is a structure Microsoft adds to tickets carrying the user's identity, group memberships, and other authorization data. The service reads it to decide what the user may do without a separate lookup. Because authorization rides inside the ticket, tampering with the PAC has been a target of past attacks, and its integrity protection is part of why keeping domain controllers patched matters.

Is NTLM still used if Kerberos is the default? Yes, as a fallback. Windows uses NTLM when Kerberos cannot apply, such as authenticating to a host by IP address, where there is no name to build an SPN from. Attackers sometimes force this fallback because NTLM is easier to relay, so many hardening programs work to identify and reduce NTLM usage over time.

Kerberos is a clean, durable answer to authentication across an untrusted network, and it has held up for decades. The risks in a real deployment are almost never in the protocol itself. They are in the secrets it depends on and the domain controllers that run it. Understand the ticket flow, protect the keys that anchor it, and the rest of Active Directory security starts to make sense.

Related guides

• Kerberoasting Explained
• Golden Ticket Attack Explained
• Active Directory Security Basics
• Pass-the-Ticket Explained