Kerberos is the authentication protocol sitting underneath almost every enterprise network you will ever be asked about. Every Active Directory domain uses it. Most Unix and Linux environments that do centralised authentication use it. If you understand how this ticket based system delivers single sign on without ever putting a password on the wire, a large slice of CISSP Domain 5 becomes straightforward, and so do the attacks built on top of it.
The protocol is named after Kerberos, the three headed dog of Greek myth that guards the gates of the underworld (Cerberus is the Latin spelling). The name is a design hint: three parties are involved in every exchange, the client, the service, and the trusted third party that vouches for both. Kerberos was developed at MIT in the 1980s as part of Project Athena, and the version in use today, Kerberos version 5, is defined in RFC 4120.
This guide walks the protocol from first principles: what it is, the components that make it work, the six step authentication flow the exam loves to test, and the security properties that flow from the design. It is the first article in the Kerberos attack chain series, and it is worth reading before the attack guides, because every one of those attacks is an abuse of a mechanism explained here.
What is Kerberos?
A network authentication protocol is a set of rules that lets systems verify who a user or service is before granting access to anything. Kerberos does this with tickets: short lived, encrypted credentials that prove you have already been authenticated, without requiring you to prove it again from scratch every time.
The core idea
Think of an airport. You show your passport once, at check in, to a party both you and the airline trust. From then on you carry a boarding pass. The gate agent does not re-examine your passport, they check the boarding pass, because it was issued by an authority they already trust and it expires at the end of the day.
Kerberos works the same way. You prove your identity once to a central authority, receive a credential that authority signed, and present that credential to every service you touch for the rest of your session. Your password never travels the network after the initial exchange, and services never need a copy of it.
The protocol operates inside a realm: a secure administrative boundary for authentication. Each realm manages its own users, services, and policies, and each has its own Key Distribution Center. Realm names are conventionally uppercase and usually mirror the organisation’s DNS domain, for example LEARNSECURITYMANAGEMENT.COM. Large organisations run multiple realms, and realms can be linked through cross realm trust so that a user authenticated in one realm can reach services in another.
Principals
Every user, service, or host that takes part in Kerberos authentication is identified by a unique name called a principal. A principal has up to three parts: the primary (a username or a service name), an optional instance (an admin role or a hostname), and the realm. A user might be [email protected], while a service could be host/appserver01.learnsecuritymanagement.com@LEARNSECURITYMANAGEMENT.COM.
In Active Directory the equivalent of the service principal is the Service Principal Name, or SPN, an attribute stamped on the account that runs a given service. Remember that term. Two of the three attacks later in this series depend entirely on being able to look up SPNs.
Key characteristics
Kerberos gives both sides of a conversation a way to prove who they are to each other, which is called mutual authentication. Rather than sending a password each time, it issues tickets built from shared secret keys known only to the account and the KDC.
Because the ticket does the work, you log in once and reuse tickets for the rest of the session: that is single sign on. Because passwords are not re-sent, network sniffing yields nothing usable. And because every ticket carries a lifetime and every request carries a timestamp, captured traffic cannot simply be replayed later.
CISSP Exam Note
Kerberos is a symmetric key protocol. Tickets, session keys, and authenticators are all protected with shared secret keys derived from account passwords. The only asymmetric element is the optional PKINIT extension used for smart card logon. If a question asks which cryptographic approach underpins Kerberos, the answer is symmetric, and the distractor is usually public key infrastructure.
The time synchronisation requirement
Kerberos leans heavily on timestamps to defeat replay attacks, so every system in the realm has to agree on what time it is. That is normally achieved with Network Time Protocol. If a host’s clock drifts beyond the configured tolerance, typically five minutes in Active Directory, authentication fails outright even when the credentials are perfect.
This is worth internalising because it is both a security feature and an availability risk. The same mechanism that blocks a replayed authenticator will also block a legitimate user whose laptop battery died and reset the clock.
The three components of Kerberos
Kerberos architecture rests on three components. Exam questions frequently probe the boundary between them, because the first two are separate concepts that are almost always implemented as one product.
Authentication Server (AS)
The Authentication Server handles your initial login. It holds the account database and verifies that you are who you claim to be, then issues a Ticket Granting Ticket (TGT).
It does this without ever receiving your password. When you log in, your workstation encrypts the current timestamp with a key derived from your password and sends it along with your username. The AS derives the same key from the password hash it already stores, decrypts the timestamp, and checks that it is current. Success proves you hold the correct password. This exchange is called pre-authentication.
CISSP Exam Note
Pre-authentication is a configurable setting, not a law of physics. Active Directory accounts can have it disabled, usually for compatibility with an old application. When it is off, anyone can request an AS-REP for that account and take the encrypted blob away to crack offline. That is the AS-REP roasting attack, and it is a close cousin of the Kerberoasting attack covered later in this series. Any account flagged “do not require Kerberos preauthentication” is a finding.
Ticket Granting Server (TGS)
The Ticket Granting Server issues service tickets once it has validated your TGT. When you want to reach a file server or a database, your machine presents the TGT and names the service it wants, and the TGS hands back a ticket for exactly that service. No password prompt is involved.
The amusement park analogy holds up well here. The TGT is your entry wristband, bought once at the gate. The TGS is the booth inside the park that swaps the wristband for a ride ticket, and only for rides your wristband entitles you to.
Key Distribution Center (KDC)
The Key Distribution Center is the system that houses both the AS and the TGS. They are distinct logical roles, but in practice they ship together. In Microsoft Active Directory, every domain controller is a KDC.
The KDC stores the long term keys, derived from passwords, for every principal in the realm. That makes it the single most sensitive system in the domain. Compromise it and an attacker can impersonate anyone. Lose it and nobody can log in at all. Organisations therefore deploy several domain controllers, each acting as a KDC, for redundancy.
CISSP Exam Note
Exam questions like to test the AS versus TGS distinction even though both live in the KDC. Fix the sequence in your head: the AS issues TGTs after initial authentication, the TGS issues service tickets for specific resources, and the KDC is the box that contains both.
| Component | Primary function | Key security role |
|---|---|---|
| Authentication Server (AS) | Verifies user credentials during initial login | Issues Ticket Granting Tickets after successful pre-authentication |
| Ticket Granting Server (TGS) | Validates TGTs and issues service tickets | Controls which network services a principal can reach |
| Key Distribution Center (KDC) | Houses both the AS and the TGS | Stores every long term key in the realm and anchors all trust |
How Kerberos authentication works
The goal of the exchange is simple: let a user reach a service on the network, a file server, a database, a web application, without sending a password each time. Six messages get you there. Exam questions test the sequence, the purpose of each message, and what breaks when one of them fails.
Step 1: Initial authentication request (AS-REQ)
When a user logs in, their workstation sends an Authentication Server Request to the AS inside the KDC. It carries the username and a timestamp encrypted with a key derived from the user’s password.
The timestamp is doing security work. It proves the request is current, so an attacker who captured an earlier AS-REQ cannot replay it. The password itself never crosses the network. The client proves knowledge of the password by successfully encrypting something with a key only that password can produce, which is what makes Kerberos safe on an untrusted network.
Step 2: TGT issuance (AS-REP)
If the AS decrypts the timestamp successfully, the user’s identity is confirmed. The AS then builds a Ticket Granting Ticket, encrypts it with the TGS secret key, and generates a session key for the client and TGS to share.
The client receives two things: the TGT, which it cannot read, and a copy of the session key encrypted with the user’s own key, which it can. From here on the TGT is proof of authentication, and no further password entry is required for the rest of the session.
TGT lifetime
In Active Directory a TGT lasts 10 hours by default and is renewable up to a maximum lifetime of 7 days without re-entering a password. That balance keeps users working through a shift while capping how long a stolen ticket stays useful. Hold on to the 10 hour figure: it becomes a detection signal when we look at forged tickets.
Step 3: Service ticket request (TGS-REQ)
When the user needs a specific service, the workstation presents the TGT to the Ticket Granting Server together with the name of the service it wants. It also sends an authenticator: a small message containing the username and the current time, encrypted with the client and TGS session key. The authenticator proves the client actually holds the session key rather than just a copied ticket.
None of this is visible to the user. Open a shared folder and the operating system silently requests a service ticket for that file server’s SPN using the TGT already in memory.
Step 4: Service ticket issuance (TGS-REP)
The TGS decrypts the TGT with its own secret key, checks the authenticator is valid and current, and then issues a service ticket encrypted with the target service’s secret key. Inside that ticket sit the user’s identity, authorisation data, and a fresh session key for the client and the service.
Because the ticket is encrypted with the service’s key, an attacker who intercepts it cannot read it or repurpose it for a different service. The client separately receives its own copy of the new session key, encrypted so only it can open it.
This step is where Kerberoasting lives. The TGS will encrypt a service ticket with the service account’s key for any authenticated user who asks, which turns a routine protocol message into crackable material.
Step 5: Service access (AP-REQ)
The client presents the service ticket to the target service alongside a new authenticator encrypted with the service session key. The service decrypts the ticket with its own secret key, reads the identity and authorisation data inside, and decides what access to grant.
The service checks several things at once. Is the ticket still within its validity window? Does the identity in the ticket match the identity in the authenticator? Is the authenticator’s timestamp current, and has this authenticator been seen before? If everything lines up, access is granted.
Notice what the service does not do by default: call back to the KDC. It trusts the ticket because it can decrypt it. That trust is exactly what Silver Ticket attacks exploit.
Step 6: Optional mutual authentication (AP-REP)
Kerberos can also run the proof in the other direction. If the application requests mutual authentication, the service replies with an AP-REP message encrypted using the shared session key.
When the client decrypts that message successfully, it knows it is talking to the genuine service and not an impostor, because only the real service holds the key needed to build the reply. This defends against a rogue server impersonating a legitimate one. It is optional, but it is the expected configuration in high security environments.
Authentication flow summary
- AS-REQ, client to AS: login request with encrypted timestamp
- AS-REP, AS to client: Ticket Granting Ticket plus session key
- TGS-REQ, client to TGS: TGT, service name, and authenticator
- TGS-REP, TGS to client: service ticket plus service session key
- AP-REQ, client to service: service ticket and authenticator
- AP-REP, service to client: optional mutual authentication response
CISSP Exam Note
Watch the clock. If a scenario describes authentication failing across a network despite correct passwords, and nothing has changed in the directory, check time synchronisation before anything else. Clock skew beyond the configured tolerance, usually five minutes, breaks Kerberos completely. It is the single most common Kerberos troubleshooting answer on the exam.
Security benefits of Kerberos
Kerberos is a substantial upgrade on the authentication methods it replaced. Understanding why explains both its dominance and its prominence in the exam syllabus.
No password transmission
Passwords never traverse the network after initial authentication, and even the initial exchange sends only an encrypted timestamp rather than the password itself. An attacker capturing traffic gets encrypted tickets that are useless without the corresponding keys. This is the property that made Kerberos viable on networks nobody trusted.
Mutual authentication
Both parties can prove their identity to each other, which closes the door on a rogue server harvesting credentials or data by pretending to be a legitimate one. In environments where service impersonation would be catastrophic, mutual authentication stops being optional in practice.
Replay attack prevention
Timestamps in tickets and authenticators stop captured authentication data being reused. Services also keep a short lived cache of recently seen authenticators, so an attacker replaying one inside the tolerance window is caught as a duplicate.
The trade off
Replay protection depends entirely on synchronised clocks. If NTP fails or a host is misconfigured, legitimate authentication requests get rejected and users cannot work. That is a direct availability impact created by a confidentiality control, and it is exactly the kind of tension the CISSP exam expects a manager to recognise.
Centralised credential management
The KDC is one place to store and manage credentials, which makes password policy enforcement, account disablement, and authentication auditing far simpler than managing credentials service by service. Disable an account at the KDC and every service in the realm is closed to it at once. A password change propagates immediately, with no synchronisation job to babysit.
Single sign on
Users authenticate once at the start of a session and reach multiple services without further prompts. That is a productivity gain, but it is also a security gain: people who are not typing passwords twenty times a day are less likely to write them down or choose something short.
The flip side is worth stating plainly. Single sign on concentrates risk. One compromised session now reaches everything the user could reach.
Support for strong cryptography
Modern Kerberos supports AES-256, and organisations can restrict which encryption types are acceptable. Legacy algorithms, in particular DES and RC4, should be disabled. RC4 in particular matters for this series: it is dramatically faster to crack offline, so leaving it enabled makes Kerberoasting far more productive for an attacker.
| Security feature | Threat mitigated | Mechanism |
|---|---|---|
| Password protection | Credential theft by network sniffing | Passwords never transmitted, only encrypted timestamps |
| Mutual authentication | Man in the middle and rogue services | Both parties prove identity, via the AP-REP message |
| Replay prevention | Reuse of captured authentication data | Timestamps plus authenticator caching detect duplicates |
| Session security | Session hijacking | A unique session key for each client and service pair |
| Ticket lifetimes | Value of a stolen ticket | Tickets expire after a configured period and must be renewed |
Where Kerberos breaks
Every security property above rests on one assumption: the secret keys stay secret. Kerberos has no way to tell a ticket forged with a stolen key from a ticket it issued itself, because the validation test is simply “does this decrypt correctly”. That assumption is the seam the entire attack chain runs along.
Three attacks matter for CISSP candidates, and each targets a different key:
- Golden Ticket attacks steal the key of the krbtgt account, the account whose key encrypts every TGT in the domain. With it an attacker forges TGTs for any identity, including ones that do not exist.
- Silver Ticket attacks steal a single service account key and forge service tickets for that one service, presenting them straight at step 5 and never touching the KDC.
- Kerberoasting does not steal a key at all. It asks the TGS politely for a service ticket at step 4, then attacks the encryption offline to recover the service account password.
Read them in that order and the differences stick, because each one attacks a step you have now seen in context.
Conclusion
Kerberos delivers scalable enterprise authentication through tickets, symmetric cryptography, and a trusted third party. It is the authentication protocol for Windows Active Directory and for most centralised Unix and Linux environments, which is why it carries so much weight in Domain 5.
The design removes passwords from the network, blocks replay through timestamp validation, and centralises credential management in the KDC. The costs are real and testable: clocks must stay synchronised, and the KDC becomes both a single point of failure for availability and the crown jewel for an attacker.
For the exam, be able to walk the six step flow, name what the AS, TGS, and KDC each do, explain why passwords are never transmitted, and reach for time synchronisation the moment a scenario describes unexplained authentication failures.
Reading about the flow gets you part of the way. Being asked about it under exam conditions, in a scenario that hides the protocol behind a business problem, is a different skill. The LSM CISSP practice tests are built from scenarios exactly like that, and Domain 5 is where most candidates discover the gap between recognising Kerberos and reasoning about it.
Quick reference for the CISSP exam
Kerberos is a network authentication protocol using symmetric key cryptography and time limited tickets to provide secure single sign on. It runs through a Key Distribution Center that contains both the Authentication Server and the Ticket Granting Server. See the Kerberos glossary entry for the one paragraph version.
Authentication flow
AS-REQ (login request), then AS-REP (TGT issued), then TGS-REQ (service ticket requested), then TGS-REP (service ticket issued), then AP-REQ (service accessed), then AP-REP (optional mutual authentication).
Key components
- Authentication Server (AS): verifies initial credentials and issues Ticket Granting Tickets
- Ticket Granting Server (TGS): validates TGTs and issues service specific tickets
- Key Distribution Center (KDC): houses both roles and stores every long term key in the realm
Core security features
- No password transmission: passwords never cross the network after initial authentication
- Mutual authentication: both client and service can verify each other, via AP-REP
- Replay prevention: timestamps and authenticator caching stop captured data being reused
- Single sign on: one authentication event unlocks many services
Critical requirements
- Time synchronisation: clocks within roughly five minutes, normally via NTP. If time sync fails, authentication fails.
- KDC security: compromise means an attacker can forge tickets for any principal in the realm. Unavailability means nobody authenticates at all.
Ticket details
- TGT: used to request service tickets, default lifetime 10 hours, renewable up to 7 days
- Service ticket: grants access to one specific service, cached on the client, bounded by the TGT lifetime
Implementation and standards
Kerberos version 5 is defined in RFC 4120. Active Directory uses domain controllers as KDCs for every Windows domain logon. Modern deployments should enforce AES-256 and disable DES and RC4.
Common exam mistakes
- Confusing the AS (issues TGTs) with the TGS (issues service tickets)
- Forgetting that mutual authentication through AP-REP is optional rather than automatic
- Missing the availability impact of a time synchronisation failure
- Overlooking cross realm trust as the mechanism for access between realms
- Describing Kerberos as a public key protocol
Exam focus: think like a manager
When a question asks for the primary risk or disadvantage of Kerberos, resist the urge to answer with cryptography. The managerial answer is that the KDC is a single point of failure. Prioritise availability and redundancy: multiple domain controllers, tested restoration, and monitoring. The technical detail about which cipher suite is enabled is a distractor in a question about business risk.