Kerberos Authentication

ActiveDirectoryFoundationsbeginner12 min

Kerberos is the default authentication protocol in Active Directory. This lesson covers how it works at a level that supports clear technical communication, explains why its design matters for both security and attack surface, and prepares you to discuss Kerberos confidently in interviews and with stakeholders.

This lesson builds on

Active Directory Structure

Theory

Core Idea

Kerberos is a ticket-based authentication protocol that solves two problems at once: it centralizes identity management so that individual services do not need to store every user's password, and it allows users to prove their identity without transmitting passwords over the network.

Instead of passwords, Kerberos uses encrypted tickets issued by a trusted third party (the Key Distribution Center) to broker trust between users and services. The user authenticates once to the KDC, receives a time-limited identity ticket, and then uses that ticket to request access to specific services without re-entering credentials.

Mental Model

Think of Kerberos as a three-party trust system, similar to using a government-issued ID at an airport. You prove your identity once at the check-in counter (the KDC), and receive a boarding pass (a ticket). You then present that boarding pass at the gate (the service) without having to re-prove your identity from scratch. The gate agent trusts the boarding pass because only the airline (the KDC) could have issued it, and it is tamper-protected.

In Kerberos, tickets play the role of these boarding passes. The Key Distribution Center is the only entity that knows everyone's credentials. It issues encrypted tickets that carry user information, and those tickets are protected by encryption keys that only the intended recipient can decrypt. The user never sees the contents of their own tickets, just as a passenger cannot rewrite their boarding pass.

Why It Matters

Kerberos is the authentication backbone of every Active Directory environment. If you cannot explain how Kerberos works, you cannot credibly explain most AD attacks. Techniques like Kerberoasting, AS-REP Roasting, golden tickets, and delegation abuse all depend on specific properties of the Kerberos protocol. Weak understanding here produces vague, unconvincing explanations of everything downstream.

Key Concepts

Key Distribution Center (KDC) — the centralized authentication authority, typically the domain controller, that issues all Kerberos tickets and knows every account's secret key
Ticket Granting Ticket (TGT) — the initial identity ticket a user receives after authenticating to the KDC; encrypted with the KDC's own secret key so the user cannot read or modify it; valid for a limited time (typically 10 hours)
Ticket Granting Service (TGS) ticket — a service-specific ticket the KDC issues when a user presents a valid TGT; encrypted with the target service's secret key so only that service can read it
Three-phase flow — (1) AS exchange: user proves identity, receives TGT; (2) TGS exchange: user presents TGT, receives service ticket; (3) AP exchange: user presents service ticket to the target service
Encryption-based trust — tickets are protected by secret keys derived from account passwords; the TGT is encrypted with the KDC's key, the TGS ticket is encrypted with the service account's key; this is why compromising those keys is so impactful
No passwords on the wire — Kerberos was designed so that user passwords are never transmitted across the network, reducing exposure to interception compared to older protocols like NTLM

Common Misunderstandings

Confusing authentication with authorization. Kerberos proves who you are, but it does not decide what you are allowed to do. Authorization decisions happen at the service level, based on the user information inside the ticket. When someone says 'Kerberos grants access,' they are conflating two separate steps.
Assuming Kerberos eliminates credential abuse. Kerberos avoids sending passwords over the network, but the tickets themselves become high-value targets. If an attacker obtains or forges a ticket, they can impersonate users without ever knowing the password. The security model shifts from protecting passwords to protecting tickets and the keys that encrypt them.
Treating tickets as opaque magic. Tickets are not mysterious tokens. A TGT is encrypted with the KDC's key, a TGS ticket is encrypted with the service's key. Understanding which key protects which ticket is the foundation for understanding every Kerberos attack. If you know the key, you can forge the ticket.
Thinking Kerberos is only relevant to defenders. Attackers need to understand Kerberos just as deeply. Every Kerberos attack targets a specific design property: Kerberoasting targets the fact that service tickets are encrypted with service account passwords; AS-REP Roasting targets disabled pre-authentication; golden tickets target the KDC's master key.

In Real Engagements

In a real AD environment, Kerberos is happening constantly in the background. Every time a user logs in, accesses a file share, opens a SharePoint site, or connects to a database, Kerberos tickets are being requested and presented. During an assessment, understanding Kerberos means you can reason about what is happening when you see AS-REQ and TGS-REQ traffic, why certain service accounts are high-value targets, and why the krbtgt account is the most sensitive account in the domain.

When explaining findings to a client, you will need to connect specific vulnerabilities back to the Kerberos model. Saying 'we performed Kerberoasting' means nothing to a stakeholder unless you can explain that it works because service tickets are encrypted with the service account's password, and weak passwords make those tickets crackable.

Communication

How to Explain It in an Interview

Kerberos is the default authentication protocol in Active Directory. It works as a ticket-based system where a trusted third party, the Key Distribution Center, brokers authentication between users and services. The user authenticates once to the KDC and receives a Ticket Granting Ticket, which is encrypted with the KDC's own key so the user cannot tamper with it. When the user needs to access a service, they present the TGT to the KDC and receive a service-specific ticket encrypted with that service's key.

The service decrypts the ticket and reads the user's identity and group memberships to make an authorization decision. The key security property is that passwords never cross the network. But from an attacker's perspective, the encrypted tickets themselves become targets, because if you can obtain or crack the key that protects a ticket, you can forge your own.

Likely Follow-Up Questions

What is the difference between a TGT and a TGS ticket, and why does it matter from a security perspective?
If Kerberos avoids sending passwords over the network, how do attacks like Kerberoasting still work?
What happens if the krbtgt account's password is compromised?
How does Kerberos handle authorization, or does it?
Why does Active Directory still support NTLM alongside Kerberos?

Study Kit