Learn Kerberos - Active Directory Kerberos

#Introduction

In episode 17 you saw how LDAP becomes the home of identity — and at the end of that episode we mentioned that Active Directory can act as a KDC. This episode opens that side completely: Active Directory uses Kerberos as its default authentication protocol, and understanding how AD "wraps" Kerberos is the key to mastering identity in the Windows world.

Why does this matter? Because almost every event in AD — user login, file share access, application authentication via SPNEGO, even delegation — runs on top of Kerberos. If you manage Linux servers, you will definitely meet AD in episode 19 too. And all the terms that often go viral in the security world — golden ticket, silver ticket, Kerberoasting — are exploits of how AD implements the protocol you've been learning since episode 2.

#Main Discussion

#An AD Domain Is a Kerberos Realm

The first concept to internalize: an AD domain is a Kerberos realm. When you create the EXAMPLE.COM domain, AD automatically creates a Kerberos realm with the same name. The NETBIOS name like EXAMPLE is still used for the EXAMPLE\User login format, but the full Kerberos identity is always user@EXAMPLE.COM.

Above that realm stand the components you already know from episode 2:

• Every Domain Controller (DC) is a KDC. The KDC service runs as part of the lsass.exe process on every DC in the domain. There's no separate "master" KDC concept like in MIT Kerberos — every DC can independently serve AS_REQ and TGS_REQ.
• The krbtgt account is the realm's TGT key. In the AD database there's a user account named krbtgt whose password is never used for login. The hash of that account's password is the encryption key for all TGTs in the realm. This is analogous to the master key on the MIT KDC you created in episode 5, but stored as a user object in AD.
• DC discovery via DNS. Clients find the nearest DC with an SRV record query in the special _msdcs zone. This is the same principle as the SRV records you created in episode 4, just with a different namespace:

dig +short _kerberos._tcp.dc._msdcs.example.com SRV

Each SRV answer contains a DC name and priority — the client picks the nearest one and automatically switches to another DC when one doesn't respond. This is why AD survives a single DC failure without complicated HA.

#The Authentication Flow: The Same Three Steps, with PAC

At the protocol level, the AD authentication flow is identical to what you learned in episode 3:

1. AS_REQ / AS_REP — the client sends a username; the DC (acting as AS) replies with a TGT encrypted with the krbtgt key plus a session key encrypted with the user's key.
2. TGS_REQ / TGS_REP — the client exchanges the TGT for a service ticket to an SPN (e.g. cifs/fileserver01.example.com).
3. AP_REQ / AP_REP — the client presents the service ticket to the target server; the server verifies and grants access.

The difference from MIT Kerberos lies in one extra layer: every ticket issued by AD carries a PAC (Privilege Attribute Certificate).

#PAC: Group Membership That Travels Inside the Ticket

The PAC is a Microsoft data structure documented in MS-PAC and inserted as the authorization-data field inside the ticket. Its contents include:

• The user's SID and the SID of the domain where the user lives.
• A list of the user's group membership SIDs — this is why AD group membership "travels along" in every ticket.
• Logon information: login time, domain controller, and other attributes used by authorization systems.

Why does AD bother carrying this inside the ticket? The answer is efficiency. When a user accesses a file server, the server doesn't need to open a connection to the DC to ask "which groups does this user belong to?" — the answer is already available and signed inside the ticket. The server only needs to verify the PAC's two signatures: one signed with the service's own key, and one signed with the DC's key. Because the PAC is signed by the KDC, the server can trust that the group memberships inside are valid without asking anywhere. This is what makes AD file shares feel instant even on congested networks.

#SPN and Service Tickets in AD

Service tickets in AD aren't aimed at an abstract "hostname" — they target a Service Principal Name (SPN) — the servicePrincipalName attribute attached to a computer or user object. The format is exactly what you know from episode 7: service/hostname, e.g. cifs/fileserver01.example.com or HTTP/webapp01.example.com.

Some important things you should know:

• Every computer object automatically gets the host/<FQDN> and restrictedKrbHost/<FQDN> SPNs — equivalent to the host principal you created for a Linux server in episode 7.
• Additional service SPNs (e.g. cifs or HTTP) are registered explicitly, usually automatically by a service running with a domain account, or manually via setspn.
• When a client requests a ticket to cifs/fileserver01, the TGS looks up that SPN in the AD database, takes the service key from the associated account's password, then issues the service ticket. If the SPN isn't found or is duplicated, the process fails — a topic we'll dissect much deeper in episode 20.

#Ports and Encryption Used by AD

Kerberos in AD runs on the same ports as the standard:

Regarding encryption types, AD has a long story. For compatibility, old Windows still relies on RC4-HMAC — a legacy from the NT 4.0 era that survives because a single old machine can force the whole domain to lower its encryption standard. Modern implementations already support AES128-CTS-HMAC-SHA1-96 and AES256-CTS-HMAC-SHA1-96, and Windows Server 2019 and later add SHA-2 based enctypes like AES256-CTS-HMAC-SHA384-192. The allowed encryption is managed via GPO under Security Options: Network security: Configure encryption types allowed for Kerberos — disabling RC4 and DES will be covered thoroughly in episode 21.

#Kerberos Policy in GPO

AD's default ticket lifetimes are managed via the Kerberos policy under Account Policies:

These numbers aren't decorations — they determine the attack window. A 10-hour TGT means a stolen credential stays useful for a full day, and the 5-minute clock tolerance is the same boundary as the MIT Kerberos default you configured in episode 6.

#Golden Ticket: When the Realm Key Leaks

This is the part that most often keeps AD administrators awake at night. Because all TGTs are encrypted with the krbtgt key, anyone who manages to extract the password hash of the krbtgt account can forge a TGT for any user — including a user who never existed in the domain. This is the golden ticket: a "golden" ticket that opens the whole realm without needing a real password.

The impact is far worse than stealing one user's password:

• A golden ticket is valid for whatever lifetime its creator sets — potentially years if the lifetime is deliberately set large.
• Changing the victim user's password doesn't stop the attack, because the forged key belongs to the realm, not the user.
• The attack only needs one-time admin access to a DC, or access to an ntds.dit backup together with the SYSTEM hive.

The main mitigation you must memorize: if krbtgt is suspected of leaking, reset the krbtgt account's password twice in a row (with a pause between resets so replication completes) to kill the old hash permanently. Detection and monitoring of this attack will be covered in episode 22, and full hardening in episode 21.

#Quick Practice: Inspecting Tickets and SPNs on Windows

To see the active Kerberos tickets in a Windows session, run klist:

View active Kerberos tickets on Windows

klist

And to check the SPNs registered on an account or computer, use setspn -L fileserver01:

Check the SPNs owned by a computer

setspn -L fileserver01

If you want to confirm which DC is currently being used, Get-ADDomainController -Discover -ServiceName Kerberos tells you the nearest DC — useful when diagnosing why authentication is slow or failing.

#Conclusion

In episode 18 you mapped Active Directory as the world's most widely deployed Kerberos implementation. We covered the domain as a realm, the DC as a KDC, the krbtgt account as the TGT key, the AS/TGS/AP flow with the extra PAC carrying group membership, SPNs as service identity, ports and encryption (from RC4 to AES 256), lifetime policy via GPO, and the golden ticket consequences of a krbtgt compromise.

Key points to take with you:

• AD and Kerberos are inseparable: domain = realm, DC = KDC, krbtgt = realm master key.
• The PAC (MS-PAC) makes group membership ride inside the ticket, signed by the KDC so services trust it.
• SPNs are the target of service tickets; SPN problems mean authentication problems (covered in episode 20).
• KDC on ports 88/tcp and 88/udp; modern AES 256 encryption, the RC4 legacy should be disabled.
• A krbtgt compromise = a golden ticket; a double reset is the mandatory cure when a leak is suspected.

In the next episode, episode 19, we connect this world to the Linux world: Linux Clients with Active Directory — making Linux servers full citizens of an AD domain via realmd and SSSD, configuring Kerberos authentication from AD, up to the login flow and troubleshooting when a join fails. See you there!