Active Directory — Part 5 — Authentication & Kerberos

Introduction

So far, we have covered what Active Directory is, how domains and forests are structured, the role of Domain Controllers, and how users, groups, and OUs work. But there is a question sitting underneath all of it:

When you type your username and password at a Windows login screen, what actually happens?

How does the Domain Controller know it is really you? How does it grant access to a file server, printer, or application without asking you to log in again for every resource?

The answer is Kerberos, the authentication protocol that powers Active Directory.

What Is Authentication?

Authentication is the process of proving you are who you claim to be.

It is different from authorisation. Authentication confirms identity. Authorisation decides what that confirmed identity is allowed to access.

What Is Kerberos?

Kerberos is a network authentication protocol. It was originally developed at MIT in the 1980s as part of Project Athena, and Microsoft adopted Kerberos as the default authentication protocol for Active Directory starting with Windows 2000.

Before Kerberos, Windows environments relied heavily on NTLM. NTLM still exists today as a fallback, but Kerberos is stronger, more scalable, and supports mutual authentication.

The name Kerberos comes from Greek mythology. Kerberos, also known as Cerberus, is the three-headed guard dog. In Kerberos authentication, the three main parties are the client, the server, and the trusted third party called the Key Distribution Centre.

The Core Idea: Tickets

The fundamental idea behind Kerberos is tickets.

Instead of sending your password across the network every time you access a resource, Kerberos uses encrypted tickets as proof of identity. You authenticate once, receive a ticket, and then use that ticket to request access to services.

This is what allows single sign-on inside a domain. You log in once, then access file shares, printers, internal websites, and applications without typing your password again and again.

The Cinema Ticket Analogy

Think of Kerberos like going to the cinema.

First, you go to the ticket counter and prove who you are. The ticket counter checks your identity and gives you a ticket.

Then, when you reach the screen entrance, the usher does not ask for your ID again. They check the ticket. If the ticket is valid, you are allowed in.

If you need access to another screen, you go back to the same ticket office for another ticket. You do not have to prove everything from scratch again, because the system already knows you.

The Kerberos Players

When you log into a domain-joined machine and access a file server, several components are involved.

Step 1: AS-REQ

When you type your password and sign in, your workstation does not simply send your password to the Domain Controller.

Instead, it sends an AS-REQ, or Authentication Service Request. This request includes your username and encrypted proof that the workstation knows your password.

The KDC looks up your account, uses information from your stored password hash to validate the request, and checks that the timestamp is current. If everything matches, the KDC knows the request is legitimate.

Step 2: AS-REP and the TGT

If the AS-REQ is valid, the KDC returns an AS-REP. This response includes the most important object in Kerberos: the Ticket Granting Ticket, or TGT.

The TGT is a ticket that says, in effect: this user has been authenticated. It is encrypted so that only the KDC can read and validate it.

Your workstation stores the TGT in memory and uses it later when it needs access to services. In Active Directory, a TGT commonly has a default lifetime of 10 hours, depending on domain policy.

Step 3: TGS-REQ

Now imagine you try to access a file server. Your workstation does not yet have a ticket for that specific file server.

So it contacts the Ticket Granting Service on the KDC and sends a TGS-REQ. In simple terms, the workstation says: I want to access this file server, and here is my TGT to prove I have already authenticated.

The KDC decrypts and validates the TGT, confirms who you are, and checks the requested service.

Step 4: TGS-REP and the Service Ticket

The KDC then returns a TGS-REP containing a service ticket for the file server.

This service ticket is encrypted with the file server service account’s key, which means the file server can read it but your workstation cannot modify it.

The ticket contains your identity, group membership information, and a session key used for secure communication with that service.

Step 5: AP-REQ

Your workstation now presents the service ticket directly to the file server. This is called an AP-REQ.

The file server decrypts the ticket, reads your identity and group memberships, and then checks permissions on the requested resource.

This is the point where authentication ends and authorisation begins. Kerberos proves who you are. The file server decides what you are allowed to access.

The Full Flow at a Glance

[Client]  ─── AS-REQ  (encrypted timestamp / proof) ───▶ [KDC / DC]
[Client]  ◀── AS-REP  (TGT + session key) ───────────── [KDC / DC]

[Client]  ─── TGS-REQ (TGT + resource request) ───────▶ [KDC / DC]
[Client]  ◀── TGS-REP (service ticket) ──────────────── [KDC / DC]

[Client]  ─── AP-REQ  (service ticket) ───────────────▶ [File Server]
[Client]  ◀── Access decision / optional AP-REP ─────── [File Server]

The KDC and krbtgt

The KDC uses a special account called krbtgt. This account is used by the Kerberos service to sign and encrypt Ticket Granting Tickets.

The krbtgt account is one of the most sensitive accounts in an Active Directory domain. If an attacker obtains the krbtgt password hash, they can forge TGTs and impersonate users, including highly privileged users.

This is the basis of the Golden Ticket attack. After a suspected krbtgt compromise, the standard response is to reset the krbtgt password twice, with proper planning and enough time between resets.

Mutual Authentication

One of Kerberos’s strengths is mutual authentication. The server can verify the client, and the client can also verify that it is talking to the correct server.

This is an important improvement over older authentication methods because it helps reduce the risk of a malicious system pretending to be a legitimate service.

Time Sensitivity

Kerberos is time-sensitive. It uses timestamps to help prevent replay attacks.

In Windows domains, the default maximum tolerance for computer clock synchronization is 5 minutes. If the client and Domain Controller drift beyond the allowed tolerance, Kerberos authentication can fail.

SPN: Service Principal Name

For a service to participate properly in Kerberos authentication, it needs a Service Principal Name, or SPN.

An SPN is a unique identifier that maps a service instance to the account running that service. When a client requests a service ticket, it requests that ticket for a specific SPN.

If an SPN is missing, duplicated, or mapped to the wrong account, Kerberos may fail and the client may fall back to NTLM.

Kerberos vs NTLM

NTLM still exists in Windows environments, but it is older and weaker than Kerberos. It is commonly seen in workgroup scenarios, local account authentication, IP-address access, legacy applications, or cases where Kerberos cannot be used.

Why This Matters for Security

Understanding Kerberos is not just academic. It directly shapes how attackers move through networks and how defenders detect suspicious activity.

Pass-the-Ticket

Since Kerberos uses tickets, an attacker who steals a valid ticket from memory may be able to impersonate the user who owns that ticket without knowing the user’s password.

Defences include reducing unnecessary privileged logons, protecting administrator workstations, monitoring abnormal ticket usage, and limiting ticket exposure on high-risk systems.

Kerberoasting

Any domain user can request a service ticket for a service with an SPN. That ticket is encrypted using the service account’s key.

An attacker can request service tickets for high-value service accounts and attempt to crack them offline. This is called Kerberoasting.

AS-REP Roasting

If an account has the setting Do not require Kerberos pre-authentication enabled, an attacker may be able to request authentication material for that account without valid credentials.

The response can be taken offline and attacked with password-cracking tools. This setting should almost never be enabled.

Golden Ticket

A Golden Ticket attack happens when an attacker has the krbtgt hash and uses it to forge Ticket Granting Tickets.

This can allow long-term and highly privileged access to the domain. Responding to this type of compromise requires careful incident response planning, Domain Controller health checks, replication checks, and a controlled krbtgt reset process.

Quick Reference Summary

Final Thoughts

Kerberos is one of the most important pieces of Active Directory. It is what allows users to authenticate once and access resources across the domain without repeatedly sending credentials.

Once you understand TGTs, service tickets, the KDC, SPNs, and krbtgt, many AD authentication issues become easier to troubleshoot and many AD security risks become easier to understand.