Kerberos Fundamentals Explained
Kerberos is the default authentication protocol in Active Directory environments, which means it underpins login and resource access for the majority of enterprise networks running Windows. Understanding how it works is not optional background knowledge for anyone doing SOC analyst, penetration testing, or Active Directory security work. It is foundational.
The protocol has a reputation for being complex, and some of that reputation is deserved. But the core logic is elegant: instead of passing passwords around a network where they could be intercepted, Kerberos uses a ticket system. You prove who you are once, receive a ticket, and use that ticket to access resources without your password ever travelling across the network again.
This guide explains how that works, what each component does, and why the protocol matters from both a defensive and offensive security perspective.
Why Kerberos Exists
Before Kerberos, network authentication often involved sending credentials directly to each service a user wanted to access. Every resource request potentially exposed the password to eavesdropping. In an era where network traffic was not reliably encrypted, this was a serious problem.
Kerberos was developed at MIT in 1988 and named after the three-headed guard dog of Greek mythology. The name is fitting: Kerberos has three components that work together to authenticate users and services. Microsoft adopted it as the default authentication mechanism for Active Directory from Windows 2000 onwards, and it remains the standard today.
The core design principle is that passwords should never travel across the network. Instead, a trusted third party, the Key Distribution Center, mediates all authentication by issuing time-limited, encrypted tickets that prove identity without exposing credentials.
The Key Components
Before walking through how authentication works, it helps to understand the parts of the system.
| Component | Abbreviation | What it is | What it does |
|---|---|---|---|
| Key Distribution Center | KDC | The trusted third party that manages all authentication. In Active Directory, the KDC runs on the Domain Controller. | Issues tickets, stores secrets for all users and services, mediates every authentication request |
| Authentication Server | AS | A component of the KDC responsible for initial user authentication | Verifies the user's identity on first login and issues a Ticket Granting Ticket (TGT) |
| Ticket Granting Server | TGS | A component of the KDC responsible for issuing service access tickets | Accepts a TGT as proof of identity and issues Service Tickets for specific resources |
| Ticket Granting Ticket | TGT | An encrypted ticket issued to a user after successful initial authentication | Proves the user has already authenticated; used to request Service Tickets without re-entering credentials |
| Service Ticket | ST (or TGS ticket) | An encrypted ticket issued for access to a specific service | Presented to a service to prove the user is authenticated and authorised; encrypted with the service's secret key |
| Service Principal Name | SPN | A unique identifier for a service instance in Active Directory | Used to identify which service a user is requesting a ticket for; each service in AD has one or more SPNs |
| krbtgt account | krbtgt | A built-in service account in every Active Directory domain | Its password hash is used to encrypt all TGTs. Compromise of this account is the basis of Golden Ticket attacks. |
How Kerberos Authentication Works: Step by Step
The authentication process has three distinct exchanges. It helps to picture a user, Alice, trying to access a file server on a corporate network.
Step 1: AS Exchange — Proving Identity to the KDC
When Alice logs in to her workstation, her machine sends an authentication request to the KDC's Authentication Server. This request includes her username and a timestamp encrypted with a key derived from her password. She does not send her password.
The AS looks up Alice in the KDC database and retrieves the key derived from her password. It uses this to decrypt the timestamp. If decryption succeeds and the timestamp is current, the AS knows Alice has the correct password without ever seeing it.
The AS responds with two items: a session key for Alice to use when talking to the TGS, and a Ticket Granting Ticket (TGT). The TGT contains Alice's identity, her network address, a validity period (typically ten hours by default in Active Directory), and the session key - all encrypted with the krbtgt account's secret key. Alice cannot read or modify the TGT because she does not have the krbtgt key.
Alice stores the TGT in memory. From this point, she does not need to enter her password again for the duration of the ticket's validity.
Step 2: TGS Exchange - Requesting Access to a Service
When Alice wants to access the file server, her machine sends a request to the KDC's Ticket Granting Server. This request includes the TGT, an authenticator (her identity and a fresh timestamp, encrypted with the session key from Step 1), and the Service Principal Name (SPN) of the file server she wants to reach.
The TGS decrypts the TGT using the krbtgt key, extracts the session key, and uses it to decrypt the authenticator. It verifies that the identity in the authenticator matches the identity in the TGT, and that the timestamp is fresh (this prevents replay attacks). If everything checks out, the TGS issues a Service Ticket for the file server.
The Service Ticket contains Alice's identity and a new session key, encrypted with the file server's secret key. Alice cannot read this part. She also receives the new session key encrypted with her TGS session key, which she can read.
Step 3: AP Exchange - Authenticating to the Service
Alice presents the Service Ticket to the file server along with a new authenticator encrypted with the service session key. The file server decrypts the Service Ticket using its own secret key, extracts the session key, and uses it to decrypt the authenticator. The identity matches. Alice is granted access.
At no point did Alice's password travel across the network. The file server never contacted the KDC directly. Everything was mediated through encrypted tickets with limited lifetimes.
Why Kerberos Matters for Security Professionals
Understanding Kerberos matters for different reasons depending on your role.
For SOC analysts and defenders, Kerberos generates a rich set of event logs that reveal authentication behaviour across the domain. Windows Event IDs 4768 (TGT requested), 4769 (service ticket requested), 4771 (pre-authentication failed), and 4776 (NTLM authentication) are among the most significant for detecting abnormal activity. A spike in 4768 events from an unusual source, a high volume of 4769 requests for a specific SPN, or 4771 failures followed by a successful 4768 are all patterns that warrant investigation.
For penetration testers and red teamers, Kerberos is the source of some of Active Directory's most significant attack techniques. Understanding the protocol at a mechanistic level is what allows you to understand why these attacks work:
Kerberoasting exploits the TGS exchange. Because any authenticated user can request a Service Ticket for any SPN in the domain, and Service Tickets are encrypted with the service account's password hash, an attacker can request tickets for service accounts and attempt to crack the hash offline. Service accounts with weak passwords are particularly vulnerable.
AS-REP Roasting targets accounts with pre-authentication disabled. When pre-authentication is off, the KDC will issue a TGT to anyone who asks for one without requiring the encrypted timestamp. The TGT is encrypted with the user's password hash, which can be cracked offline.
Pass-the-Ticket involves stealing a valid TGT or Service Ticket from memory (using tools like Mimikatz) and using it from a different machine to impersonate the victim without knowing their password.
Golden Ticket attacks exploit the krbtgt account. If an attacker compromises the krbtgt password hash, they can forge arbitrary TGTs for any user in the domain, including domain administrators, with any validity period they choose. A Golden Ticket grants complete domain access and persists until the krbtgt password is rotated twice.
Silver Ticket attacks are more limited but stealthier. An attacker who compromises a service account's password hash can forge Service Tickets for that specific service, granting access without any interaction with the KDC and therefore generating no KDC logs.
The Time Dependency
One aspect of Kerberos that often surprises people is its strict time synchronisation requirement. The protocol uses timestamps in authenticators to prevent replay attacks: if an attacker captures a valid authenticator and replays it, the timestamp will be outside the acceptable tolerance window (five minutes by default in Active Directory) and the KDC will reject it.
This means all machines in a Kerberos realm must have their clocks synchronised. In Active Directory environments, this is managed through the Windows Time Service. A workstation that drifts more than five minutes from the Domain Controller's clock will fail Kerberos authentication entirely, producing errors that can be confusing without understanding this dependency.
Practise Kerberos in a Real Environment
Understanding Kerberos conceptually is the starting point. Applying that understanding in a live Active Directory environment, investigating Kerberos event logs, practising enumeration of SPNs, and working through the attack techniques that exploit the protocol in a safe lab is where the knowledge becomes genuinely useful.
TryHackMe's Active Directory content puts you inside real AD environments where you can practise both the defensive and offensive aspects of Kerberos, including Kerberoasting, AS-REP roasting, and Golden Ticket scenarios, in a guided and legally safe context.
