What is Kerberos? Authentication Protocol Explained

⚡ What is Kerberos?

Kerberos is a network authentication protocol that uses encrypted tickets to prove identity without transmitting passwords over the network. It is the default authentication protocol for Windows Active Directory domains. Kerberos runs on TCP/UDP port 88 and relies on a trusted third party — the Key Distribution Centre (KDC) — to issue tickets that grant access to services. Because tickets are time-stamped, Kerberos requires all systems to have clocks synchronised within 5 minutes — which is why NTP is critical in domain environments.

Why Kerberos exists — the problem it solves

Before Kerberos, authentication often meant sending a password across the network every time a user accessed a resource. That password could be intercepted and replayed by an attacker. Kerberos solves this with a fundamentally different model: you prove your identity once to a trusted third party, and they give you a ticket. You then present that ticket to each service you want to access — your actual password never travels to the service at all.

It's the digital equivalent of showing your passport at a border once to get an entry stamp, then using that stamp to enter venues — you don't show your passport to every venue, just the stamp they can verify without contacting the border agency.

The three Kerberos components

Component	What it is	Role
KDC	Key Distribution Centre	The trusted third party — runs on the Domain Controller in Active Directory. Contains two services: the AS and the TGS.
AS	Authentication Service	The part of the KDC that verifies the user's initial credentials and issues a TGT (Ticket-Granting Ticket).
TGS	Ticket-Granting Service	The part of the KDC that accepts a TGT and issues service tickets for specific resources (file servers, email, web apps).
TGT	Ticket-Granting Ticket	The "master ticket" issued after successful login. Presented to the TGS to request access to individual services. Valid for a limited time (10 hours by default in AD).
Service Ticket	Session Ticket / ST	A ticket for a specific service. Presented directly to the service (file server, etc.) to prove identity. The service can verify it without contacting the KDC.
Realm	Kerberos domain	The administrative boundary for Kerberos — maps to a Windows domain in Active Directory (e.g. COMPANY.COM).

How Kerberos authentication works — step by step

The full Kerberos flow involves six message exchanges across three parties. This sequence is tested on Security+ — understand each step and what it proves:

AS-REQ — User requests a TGT

The user's client sends an Authentication Service Request to the KDC. It includes the username and a timestamp encrypted with the user's password hash. The password itself is never sent.

AS-REP — KDC issues the TGT

The KDC verifies the request by decrypting the timestamp using the stored password hash. If valid, it returns a TGT encrypted with the KDC's secret key (krbtgt account hash). The client stores this TGT in memory.

TGS-REQ — User requests a service ticket

When the user needs to access a resource (e.g. a file server), their client sends a Ticket-Granting Service Request to the KDC, presenting the TGT and the name of the target service.

TGS-REP — KDC issues a service ticket

The KDC decrypts the TGT (only it can, since it holds the krbtgt key), verifies it's valid, and issues a service ticket encrypted with the target service's secret key. The client stores this ticket.

AP-REQ — User presents service ticket

The client sends the service ticket directly to the file server (or other target service). The file server decrypts it using its own key — no contact with the KDC needed at this point.

AP-REP — Service grants access

The service verifies the ticket is valid and not expired, confirms the user identity it contains, and grants access. The user's password was never transmitted to the service at any point.

⚡ The key insight the exam tests

Kerberos is built on mutual trust without sharing passwords. The user proves identity to the KDC once. Services trust tickets issued by the KDC without ever seeing the user's password. The KDC never has to be contacted for every resource access — just once per service per session.

Port 88 — TCP and UDP. The KDC listens on 88. This is one of the most tested Kerberos facts alongside the 5-minute clock skew rule.

The 5-minute clock skew rule

Every Kerberos ticket contains a timestamp. The KDC and all clients must have clocks synchronised within 5 minutes of each other. If the clock skew exceeds this threshold, the KDC rejects the ticket as potentially replayed — an attacker could theoretically capture a ticket and reuse it later, so the time window limits this risk.

📌 Why this matters — the NTP connection

This is exactly why NTP is critical in Active Directory environments. If a domain-joined machine's clock drifts more than 5 minutes from the Domain Controller (which runs the KDC), all Kerberos authentication fails for that machine — users cannot log in, cannot access shared drives, cannot authenticate to any domain service.

The most common cause is a VM that was suspended and resumed with a stale clock, or a machine that couldn't reach its NTP source. The fix is always: correct the clock first, then re-authenticate.

Exam scenario: "Users on a workstation suddenly cannot log into the domain. No network changes were made. The most likely cause?" → Clock skew — the workstation's clock has drifted beyond the 5-minute Kerberos tolerance.

Kerberos attacks — Security+ exam targets

Kerberos attacks are high-frequency Security+ content. The exam expects you to recognise each attack by name, understand the mechanism, and know the defence. These attacks target different stages of the Kerberos ticket chain:

Ticket theft attack

Pass-the-Ticket (PtT)

An attacker steals a valid Kerberos ticket from memory (using tools like Mimikatz) and uses it to authenticate as the victim — without knowing their password. Since the ticket is already encrypted and valid, the KDC accepts it. The attacker effectively impersonates the victim for the ticket's remaining lifetime.

Defence: Credential Guard (isolates LSASS in a virtualised environment), short ticket lifetimes, monitoring for anomalous ticket usage from unexpected IPs, and privileged access workstations (PAWs).

Forged TGT attack

Golden Ticket Attack

If an attacker compromises the krbtgt account hash (the KDC's master key), they can forge completely valid TGTs for any user — including domain admins — with any expiry date, even after the real account is deleted or disabled. A Golden Ticket gives persistent, unrestricted domain access and is extremely difficult to detect because the tickets appear legitimate to every service.

Defence: Reset the krbtgt account password twice (to invalidate all existing TGTs), monitor for tickets with abnormal lifetimes or group memberships, and implement tiered administration to protect Domain Controller access.

Forged service ticket

Silver Ticket Attack

If an attacker compromises a service account's password hash (rather than the krbtgt hash), they can forge service tickets for that specific service without contacting the KDC at all. More limited scope than a Golden Ticket (one service only) but harder to detect because it generates no KDC traffic.

Defence: Use strong, long, randomly generated service account passwords. Enable Privileged Attribute Certificate (PAC) validation so services verify tickets with the KDC.

Credential attack

Kerberoasting

Any authenticated domain user can request service tickets for any service with a Service Principal Name (SPN) registered. The service ticket is encrypted with the service account's password hash. An attacker requests these tickets, extracts them, and cracks the encryption offline — no account lockout, no noise, no need for elevated privileges. Weak service account passwords are trivially cracked this way.

Defence: Use strong, long passwords (25+ characters) for service accounts — or better, use Managed Service Accounts (MSAs) which have 240-character auto-rotating passwords that are practically uncrackable. Audit SPNs regularly.

Pre-auth bypass

AS-REP Roasting

For accounts that have Kerberos pre-authentication disabled, an attacker can request a TGT without proving identity first. The KDC responds with an AS-REP containing data encrypted with the user's password hash, which the attacker can extract and crack offline — similar to Kerberoasting but targeting user accounts instead of service accounts.

Defence: Ensure Kerberos pre-authentication is enabled on all accounts (it's enabled by default — only disable for specific legacy application compatibility requirements). Monitor for AS-REP requests from accounts with pre-auth disabled.

Kerberos quick reference

Kerberos exam reference — cold recall facts

Protocol:     Kerberos
Port:          TCP/UDP 88
Used by:       Active Directory (default domain auth protocol)

KDC:           Key Distribution Centre — runs on Domain Controller
AS:            Authentication Service — issues TGT after login
TGS:           Ticket-Granting Service — issues service tickets
TGT:           Ticket-Granting Ticket — master ticket, valid 10hrs (default)
krbtgt:        The KDC's master account — its hash signs all TGTs

Clock skew:    5 minutes maximum — enforced to prevent ticket replay
NTP:           Required — clocks must be synced for Kerberos to work

Attacks:
  Pass-the-Ticket   Stolen ticket used to impersonate user
  Golden Ticket     Forged TGT from compromised krbtgt hash
  Silver Ticket     Forged service ticket from compromised service hash
  Kerberoasting     Offline cracking of service ticket encryption
  AS-REP Roasting   Offline cracking when pre-auth is disabled

Exam scenarios

💬 "Which authentication protocol does Active Directory use by default for domain logins?" → Kerberos — runs on TCP/UDP port 88, uses the KDC on the Domain Controller

💬 "A user's workstation cannot authenticate to the domain after being offline for several days. No network changes were made. What is the most likely cause?" → Kerberos clock skew — the workstation's clock has drifted beyond 5 minutes from the Domain Controller. Sync time with NTP and re-authenticate.

💬 "An attacker extracts Kerberos tickets from memory using Mimikatz and uses them to access resources without knowing any passwords. What is this attack?" → Pass-the-Ticket (PtT)

💬 "An attacker compromises the krbtgt account hash and uses it to create forged tickets that grant domain admin access for any user. What is this attack?" → Golden Ticket attack — requires resetting the krbtgt password twice to remediate

💬 "An attacker requests service tickets for all SPN-registered service accounts and cracks them offline. No account lockouts occur. What is this attack?" → Kerberoasting — use Managed Service Accounts with long auto-rotating passwords to defend

💬 "What is the initial ticket issued by the Kerberos Authentication Service after a user provides valid credentials?" → TGT — Ticket-Granting Ticket, used to request individual service tickets without re-entering credentials

💬 "An organisation wants to prevent Kerberos ticket theft from memory. Which Windows feature should be enabled?" → Credential Guard — isolates LSASS in a virtualisation-based security environment, preventing Mimikatz-style ticket extraction

💬 "Which Kerberos attack exploits accounts that have pre-authentication disabled?" → AS-REP Roasting — the KDC returns encrypted data without verifying identity first, which can be cracked offline

Studying for Security+?

The SY0-701 study guide, Dion Training practice exams, and Professor Messer's free course.

See Security+ Resources →

What is Kerberos?