FFoundationalActiveDirectory
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.
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.
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.
Microsoft · Official Microsoft reference for the Kerberos authentication protocol in Windows Server
IETF · The authoritative IETF specification for Kerberos V5 — the protocol standard that Windows Kerberos implements
Microsoft · Microsoft deep-dive into Kerberos protocol mechanics, including delegation and ticket exchange sequences
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.
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.
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.