Kerberos Authentication Explained

Kerberos is a network authentication protocol that lets clients and services prove their identities to each other over an untrusted network without ever transmitting passwords. It relies on a trusted third party, the key distribution center, and time-limited tickets encrypted with symmetric keys. Widely used inside enterprise networks and central to Windows domain authentication, Kerberos provides strong mutual authentication and a form of single sign-on that avoids repeatedly sending secrets across the wire.

The Core Components

Kerberos organizes authentication around a few well-defined parties operating within a realm, an administrative boundary that groups users and services.

• Key Distribution Center (KDC): the trusted server at the center of every exchange. It is split into two logical services.
• Authentication Server (AS): the part of the KDC that verifies the user's initial identity and issues a ticket-granting ticket.
• Ticket Granting Service (TGS): the part of the KDC that issues service tickets for specific resources.
• Principal: any uniquely named entity, a user or a service, that the KDC knows.

The KDC shares a long-term secret key with every principal, derived from the user's password or a service's key. These keys never travel the network; they are used to encrypt and decrypt tickets, which is the foundation of the protocol's security.

Tickets and the Two-Step Exchange

The defining feature of Kerberos is that a user authenticates once to obtain a ticket-granting ticket (TGT), then reuses that TGT to request many service tickets without re-entering a password. This two-stage design is what delivers single sign-on within a realm.

Step One: Getting a Ticket-Granting Ticket

1. The client sends an authentication request to the AS, naming the user principal.
2. The AS looks up the user's long-term key and generates a session key.
3. The AS returns two items: a TGT encrypted with the TGS's secret key, and a session key encrypted with the user's long-term key.
4. The client decrypts the session key using the key derived from the user's password. Success proves the user knows the password, without that password ever crossing the network.

A refinement called pre-authentication requires the client to first encrypt a timestamp with its key, proving knowledge of the password before the AS issues anything. This blocks attackers from freely requesting material to crack offline.

Step Two: Getting a Service Ticket

When the user wants to reach a specific service, such as a file server:

1. The client sends the TGS the TGT plus an authenticator, a timestamp encrypted with the TGS session key.
2. The TGS decrypts the TGT, recovers the session key, and validates the authenticator.
3. The TGS issues a service ticket encrypted with the target service's secret key, along with a new client-service session key.
4. The client presents the service ticket to the service, which decrypts it with its own key and trusts its contents.

The following sketch summarizes the whole exchange:

Client --(1) AS-REQ ------------------->  AS  (KDC)
Client <--(2) TGT + session key --------  AS
Client --(3) TGS-REQ: TGT + auth ------>  TGS (KDC)
Client <--(4) service ticket -----------  TGS
Client --(5) service ticket + auth ---->  Service
Client <--(6) optional mutual auth -----  Service

Why Passwords Never Cross the Wire

The security of Kerberos rests on symmetric cryptography and the fact that possessing the right key is what proves identity. Because the AS encrypts the session key with the key derived from the user's password, only a client that can reproduce that password-derived key can decrypt it. The password itself is never sent, and an eavesdropper capturing the exchange gains only ciphertext.

Authenticators stop replay attacks. Each authenticator contains a fresh timestamp encrypted with a session key. The receiving service checks that the timestamp is within a small tolerance and has not been seen before, so a captured ticket cannot be replayed later. This dependence on timestamps is why Kerberos requires reasonably synchronized clocks across the realm; excessive clock skew causes authentication to fail.

Kerberos can also provide mutual authentication: the service can encrypt the client's timestamp with the shared session key and return it, proving to the client that the service genuinely holds its own secret key and is not an impostor.

Common Attacks and Defenses

Because Kerberos is central to enterprise networks, its weaknesses are heavily studied, and understanding them is important for defenders.

• Kerberoasting: an attacker requests service tickets for accounts and cracks them offline to recover weak service passwords. Defenses include long, random service account passwords and managed service accounts.
• Pass-the-ticket: stolen tickets from a compromised host are reused elsewhere. Limiting local administrator access and protecting memory reduces exposure.
• Golden ticket: if the KDC's own account key is stolen, an attacker can forge arbitrary TGTs. Guarding that key and rotating it is critical.
• AS-REP roasting: accounts with pre-authentication disabled leak crackable material, so pre-authentication should stay enabled.

Strong passwords, tight privilege boundaries, and monitoring for anomalous ticket requests are the practical countermeasures. Pairing Kerberos with multi-factor authentication at initial login and strong protection of domain controllers further hardens the environment.

Kerberos Alongside Other Methods

Kerberos excels at seamless authentication inside a managed network but does not natively span the open web, where token-based federation dominates. Many organizations bridge the two, using Kerberos internally and federating outward with SAML or OpenID Connect. In high-assurance settings it complements certificate-based authentication, which can bootstrap the initial Kerberos exchange using smart cards.

Key Takeaways

• Kerberos authenticates clients and services over untrusted networks without sending passwords, using symmetric keys.
• A user authenticates once for a ticket-granting ticket, then obtains service tickets for individual resources.
• The KDC, split into the authentication server and ticket granting service, is the trusted party that issues encrypted tickets.
• Timestamped authenticators prevent replay, which is why synchronized clocks across the realm are required.
• Kerberoasting, pass-the-ticket, and golden-ticket attacks are the key threats, countered by strong keys, least privilege, and monitoring.