Learn Active Directory - Kerberos Authentication in Active Directory

#Introduction

In episode 12 we secured AD from the policy side: least privilege, tiered administration, Protected Users, and Credential Guard. But all those layers sit on top of a deeper foundation — the protocol that determines how everyone proves their identity. Without understanding this foundation, much of what we discussed feels like a black box. That foundation is Kerberos.

Kerberos has been Active Directory's default authentication protocol since Windows 2000. The name comes from Greek mythology — the three-headed dog guarding the gates of Hades. The analogy fits: Kerberos stands guard at the "entrance" of every network service in the domain, only letting through those who genuinely hold proof of identity.

Picture a luxury hotel. When you check in at the front desk (the Key Distribution Center), you prove your identity and receive a room key card (TGT). That key card isn't a specific room key — it's proof that you've checked in. With that card, you can visit various facilities: the gym, the pool, the lounge — each time exchanging it for a facility-specific pass (service ticket). That's the essence of Kerberos: prove your identity once, then use that proof to access many services.

#Kerberos Components in Active Directory

Kerberos works with several key components, all running on a Domain Controller:

• KDC (Key Distribution Center) — the "front desk" that verifies identity and issues tickets. In AD, every DC is a KDC, so there's no single point of failure.
• krbtgt — a special account whose cryptographic keys are used to encrypt and validate TGTs. This account is disabled, never used to log in, and its password is known by every KDC in the domain. This is the "master key" of the whole ticket system.
• SPN (Service Principal Name) — a service's unique identity in service/host form, e.g. http/srv-web01.corp.local. The SPN is the address looked up when a client requests a service ticket.
• PAC (Privilege Attribute Certificate) — the data package inside a ticket carrying authorization information: group SIDs, membership, and user permissions. This is what makes a ticket "understand" who holds it and what they're allowed to do.

#The Authentication Flow: A Ticket's Journey

Kerberos works through three message exchanges. Let's follow user jsantoso accessing the file server SRV-FILE01.

#Step 1: AS-REQ and AS-REP — Requesting a TGT

The client sends an AS-REQ (Authentication Service Request) to the KDC: "I am jsantoso, and here's proof that I know my password." The KDC verifies, then replies with an AS-REP containing a TGT (Ticket-Granting Ticket) — a ticket that "marks" the client as a verified user.

The important thing to understand: the password is never sent over the network. The key derived from the password (long-term key) is used to encrypt the TGT, and only the client that knows the password can unlock it again.

#Step 2: TGS-REQ and TGS-REP — Requesting a Service Ticket

The client wanting to access SRV-FILE01 now sends a TGS-REQ (Ticket-Granting Service Request) to the KDC: "Here's my TGT, and I want access to the service cifs/SRV-FILE01." The KDC verifies the TGT, checks that the user indeed has the rights, then replies with a TGS-REP containing a service ticket for that service.

#Step 3: AP-REQ and AP-REP — Presentation to the Service

The client sends an AP-REQ (Application Request) to the SRV-FILE01 server: "Here's my service ticket." The server verifies the ticket with its own key, reads the PAC inside to determine permissions, and grants access. From here, communication continues without involving the KDC again.

Client --> KDC        : AS-REQ  (I'm user X, give me a TGT)
KDC   --> Client      : AS-REP  (here's your TGT, encrypted)
Client --> KDC        : TGS-REQ (here's my TGT, I want access to service Y)
KDC   --> Client      : TGS-REP (here's the service ticket for service Y)
Client --> Service Y  : AP-REQ  (here's my service ticket)
Service Y --> Client  : AP-REP  (access granted)

The beauty of the ticket model: the client only deals directly with the KDC twice per session (TGT and service ticket), not for every access. The TGT is valid for several hours (default 10), and within that window the client can request many service tickets without re-entering its password. This is the basis of the "magical" SSO (Single Sign-On) in Windows.

#Kerberos vs NTLM: Why Kerberos Is Superior

Kerberos replaced NTLM for reasons that are both deeply technical and practical:

• Kerberos has mutual authentication — both parties (client and server) prove their identity to each other. NTLM only verifies the client to the server, so a fake server can "impersonate" to steal credentials.
• Kerberos never sends credentials — what's sent is a time-limited encrypted ticket. NTLM sends a hash that can be captured and replayed.
• Kerberos supports delegation — a service can "act on behalf of" a user to access other services (with limits, covered later). NTLM doesn't support multi-hop scenarios at all.
• Kerberos uses modern encryption — AES128 and AES256, whereas NTLM relies on weak legacy structures.

That's why the security strategy from episode 12 — and the NTLM details in episode 14 — always converge on one direction: push NTLM away, make Kerberos the only path.

#Ticket Encryption: From RC4 to AES

Kerberos tickets are encrypted with a key derived from a password. The encryption type family determines how strong the protection is. Across Windows evolution, the supported encryption types have evolved:

In a production environment, your target is all tickets using AES. Accounts in Protected Users (episode 12) are automatically rejected if they try RC4/DES — this is one of the reasons that group is so effective. A quick way to check which encryption a user's tickets use after login is klist:

klist
klist tgt

To check a service account's SPNs, use setspn -Q:

setspn -Q http/srv-web01.corp.local

#The Most Common Kerberos Failures

Kerberos is highly sensitive to a few things. Know the symptoms so you don't go in circles during troubleshooting:

1. Clock skew — unsynchronized time. Kerberos tickets carry timestamps; if the clock difference between a client and the DC exceeds 5 minutes (default), the KDC rejects the ticket. This is the most common cause of weird errors like "Kerberos: KRB_AP_ERR_SKEW" or confusing logon failures. The fix: make sure every domain machine syncs time to the DC, and the DC to an external time source.

2. Missing or duplicate SPNs. When a client looks for cifs/SRV-FILE01 and that SPN doesn't exist — or worse, exists twice — authentication fails or lands on the wrong service. Duplicate SPNs confuse the KDC about which key to use. Routine checks with setspn -Q and event log review are good habits.

3. Expired tickets. TGTs default to 10 hours and service tickets to 1 hour. If a session stays open very long or the system time changes drastically, tickets are considered stale. klist purge deletes all tickets and forces the client to get new ones — a lifesaver command you must remember.

4. Wrong credentials on a service account. If a service account's password changes (e.g. it gets reset), old tickets become invalid immediately. This is why the recommendation is to use Group Managed Service Accounts (gMSAs) whose passwords AD manages automatically — no more "server reboot after a password reset".

The event log is your best witness: in the System and Security logs, messages with codes like 4771 (Kerberos pre-authentication failed) or events under the Kerberos source give direct clues. For very deep network forensics, Wireshark with the kerberos filter shows the entire raw ticket exchange.

#Conclusion

In this episode we dissected Kerberos — AD's default authentication protocol: the role of the KDC and the krbtgt account as the heart of ticket issuance, the AS-REQ/AS-REP flow for getting a TGT, TGS-REQ/TGS-REP for a service ticket, and AP-REQ/AP-REP when the ticket is presented to a service. We also compared Kerberos with NTLM, learned about the AES128/AES256 encryption that is now the modern standard, and recognized the most common failures and how to handle them.

The takeaway: Kerberos is a ticket-based protocol that never sends credentials — that strength is what makes it AD's security foundation, and the reason protections like Protected Users and AES encryption are so crucial.

In the next episode 14, we flip the coin and study the old side that must be left behind: NTLM — why this legacy protocol still exists, how it works, why it's dangerous, and how to disable it safely. Keep the momentum going!