Kerberos is an authentication protocol used to verify the identity of users and services on a network — most notably as the authentication backbone of Microsoft Active Directory, where it handles the process of logging a user in and letting them access resources across an entire enterprise network without repeatedly typing a password.
Kerberos takes its name from Cerberus, the three-headed dog of Greek mythology that guards the entrance to the underworld — Kerberos conducts three challenges to grant access to a resource.
The problem Kerberos solves
In an enterprise network, a user might need to access dozens of different servers and services throughout the day — file shares, email, internal websites, databases. Two obvious but flawed approaches to handling this are:
- Send the password to every service directly. This means the password travels across the network repeatedly, and every single service needs to be trusted to handle it securely — a large attack surface, and a single compromised service could expose the user’s actual password.
- Make the user log in separately to every service. Secure, but extremely impractical at scale, and would encourage users to pick weak, easily-remembered passwords just to cope with typing them so often.
Kerberos instead lets a user prove their identity once, and then use a system of temporary, limited-purpose tickets to access whatever they need afterwards — without their actual password ever being sent to any of those individual services.
This approach is commonly called single sign-on.
Kerberos authentication
Kerberos authentication involves three roles:
- The client: The user (or a device/service acting on their behalf) trying to access something.
- The service: The resource the client wants to access — a file server, a database, an internal website.
- The Key Distribution Center (KDC): A trusted third party (in an Active Directory environment, this role is performed by the Domain Controller) that both the client and the service trust, and which issues the tickets that make the whole process work.
The KDC itself is made up of two logical components: the Authentication Server (AS), which handles the initial login, and the Ticket Granting Server (TGS), which issues tickets for individual services afterwards.
How Kerberos authentication works
At a conceptual level, the process happens in two main stages.
Stage 1: Initial login
- The user logs in to their workstation, and their client software sends a request to the Authentication Server (AS), proving who they are (typically by encrypting a timestamp with a key derived from their password).
- The AS checks this against what it knows about the user (it doesn’t need the user’s actual password sent to it — it can perform this check because it already holds the same key, derived the same way, in its own database). This is the 1st challenge
- If successful, the AS issues the client a Ticket Granting Ticket (TGT) — a time-limited credential that proves the user has already authenticated, without needing to send their password again.
This TGT is the key benefit of the whole system: from this point on, for the lifetime of the ticket (commonly around 10 hours in a default Active Directory configuration), the user doesn’t need to re-enter their password to access other resources on the network.
Stage 2: Accessing a specific service
Whenever the user then wants to access a particular service — say, a file server — a further, separate exchange happens automatically, invisibly to the user:
- The client presents its TGT to the Ticket Granting Server (TGS), along with a request specifying which service it wants to access.
- The TGS verifies the TGT is valid and issues a service ticket — a new, separate ticket specific to that one service. This is the 2nd challenge.
- The client presents this service ticket directly to the service it wants to access.
- The service verifies the ticket is genuine (it can do this because the ticket was encrypted using a key the service itself shares with the KDC) and grants access. This is the 3rd challenge
This means a fresh, narrowly-scoped ticket is issued for every individual service a user accesses — a compromised service ticket for a file server can’t be reused to access, say, an email server, since each ticket is only valid for the specific service it was issued for.
Mutual authentication
An important property of Kerberos is that it’s mutual — it isn’t just the client proving its identity to the service. As part of the ticket exchange, the service can also prove its own identity back to the client, confirming the client really is talking to the genuine service, and not an imposter that’s somehow inserted itself into the conversation. This is a meaningful improvement over protocols where only the client authenticates, since it also helps protect against certain Man in the Middle style attacks.
Why ticket lifetimes matter
Kerberos tickets are deliberately time-limited rather than permanent. This matters for two related reasons:
- Limiting the window of misuse. If a ticket is ever stolen, it’s only useful to an attacker until it expires, rather than indefinitely.
- Dependence on accurate time. Because the whole system relies on timestamps to detect stolen or replayed tickets, all devices involved need to agree closely on the current time. Kerberos typically requires clocks to be within around 5 minutes of each other by default — if a device’s clock drifts too far out of sync, Kerberos authentication will start failing even with entirely correct credentials. This is a good demonstration of why something as seemingly minor as accurate time synchronisation (via NTP) has real security and operational consequences.
Kerberos and security
Kerberos is widely regarded as a strong authentication protocol, but its central role in enterprise networks — particularly Active Directory — has made it a heavily studied target for attackers.
Kerberoasting is one of the best-known attacks against Kerberos. Any authenticated user can legitimately request a service ticket for any service on the network, and part of that ticket is encrypted using a key derived from the service account’s own password. An attacker can request these tickets for high-privilege service accounts, then take that encrypted portion away and attempt to crack it offline, with no further interaction with the network required, and often no obvious signs of an attack in progress. Service accounts with weak passwords are especially vulnerable, since offline cracking removes the usual protections (like account lockout policies) that would normally slow down a live password-guessing attempt.
Pass-the-ticket attacks involve an attacker stealing a valid Kerberos ticket directly from a compromised machine’s memory, and reusing it to impersonate that user elsewhere on the network — without ever needing to know the user’s actual password at all.
Golden Ticket attacks are a particularly severe escalation of this idea. If an attacker manages to compromise the KDC’s own master key (called the Ticket Granting Ticket (krbtgt ) account’s password hash in Active Directory), they can forge their own Ticket Granting Tickets from scratch, for any user, with any level of privilege, and with a validity period of their choosing — effectively granting themselves unlimited, long-term access across the entire domain. Recovering from a confirmed Golden Ticket attack typically requires resetting the krbtgt account’s password (twice, in fact, due to how Active Directory retains old passwords briefly for compatibility).
Silver Ticket attacks work on a similar principle to Golden Ticket attacks, but are narrower in scope and, as a result, considerably harder to detect.
Rather than compromising the KDC’s own master key, an attacker only needs the password hash of a single service account — the same type of account targeted by Kerberoasting. With that hash, the attacker can forge a valid service ticket for that one specific service, without ever contacting the KDC at all. Because a real Ticket Granting Server is never involved in creating the forged ticket, there’s no corresponding TGS request for defenders to notice — a Golden Ticket attack at least generates some (unusual) traffic to the KDC, whereas a Silver Ticket attack can leave almost no trace on the domain controller itself.
The trade-off for the attacker is scope: a Silver Ticket only grants access to the one service whose account hash was compromised, rather than the domain-wide access a Golden Ticket provides. In practice, this still makes it a serious threat where that one service happens to be something high-value, such as a file server holding sensitive data.
Because of risks like these, common Kerberos hardening steps include enforcing strong, regularly rotated passwords on service accounts specifically (since these are the accounts targeted by Kerberoasting), closely monitoring for unusual patterns of service ticket requests, and keeping the krbtgt account’s password rotated periodically as a standard precaution.