FFoundationalActive Directory

Kerberos Authentication

Foundationsbeginner12 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

Hook

You already know Active Directory does not send your plaintext password across the network every time you log in. It is tempting to assume that just means the password gets encrypted before it travels, and a domain controller checks it on the other end. That is not what happens. After the very first exchange, your password never gets sent again in any form, encrypted or otherwise, and a file server on the far side of the domain still trusts your identity without ever asking for it.

Predict

If your password itself never crosses the network again, what exactly is your machine handing the file server every time you open a share?

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

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.

Diagram

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.

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.

Real-world context

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, connect the specific vulnerability back to this model instead of just naming an attack and moving on. Naming an attack is not the same as explaining it: a stakeholder needs to hear which ticket was targeted and why, in plain terms, before a finding like Kerberoasting means anything to them.

Communication

Interview answer

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, 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 instead.

The service decrypts that ticket and reads the user's identity and group memberships to make its own authorization decision. The password itself never crosses the network at any point in this exchange. From an attacker's perspective though, the encrypted tickets become the target instead: obtain or crack the key that protects a ticket, and you can forge one yourself to impersonate that user.

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?

Next up

The opening question resolves here: what your machine hands the file server is the ticket itself, a credential the KDC encrypted with a secret key, never the password in any form. The server trusts it because only the KDC could have produced it. But Kerberos is not the only authentication protocol running in your AD environment: Active Directory still falls back to NTLM in specific situations, and NTLM protects its shared secret in a completely different way. The next lesson, NTLM Authentication, opens with that difference: if NTLM also avoids sending the password itself, why does it have such a weaker security reputation than Kerberos?

Study Kit

Quick Reference

Test Your Understanding

Reinforce Key Concepts

Further Reading

Lesson 2 of 64 to go
Next upNTLM Authentication