Kerberos

a ticket-based authentication system, uses tickets instead of credentials, so instead of sending your password around the network, it gives you tickets that prove who you are. Provides mutual authentication (both sides verify each other)

Kerberos has been the default authentication protocol for domain accounts since Windows 2000.

Kerberos Authentication Process

AD runs a Key Distribution Center (KDC), which has two logical services

  • Authentication Service (AS)
  • Ticket Granting Service (TGS).

And the krbtgt which is a special account in Active Directory used by the KDC to sign and encrypt TGTs

1) AS-REQ / AS-REP

When you type your password and hit Enter on a domain-joined machine:

Your machine hashes your password locally (NTLM hash), derives an encryption key from it, and sends an AS-REQ (Authentication Service Request) to the KDC on port 88. The request contains your username in plaintext and a timestamp encrypted with your password hash.

The KDC then looks up your account in AD, grabs its copy of your password hash from the ntds.dit database, tries to decrypt the timestamp, and checks if it’s within 5 minutes (which is the Kerberos clock skew tolerance and this is why time sync matters so much in AD).

If it matches, the KDC issues an AS-REP (Authentication Service Reply) containing two things:

  • A session key encrypted with your password hash (so only you can decrypt it)
  • The Ticket Granting Ticket (TGT) a blob encrypted with the krbtgt account’s hash, which you cannot read. It contains your identity, group memberships, and that same session key.

Your machine decrypts the session key. The TGT sits in LSASS memory (on Windows, visible via klist a command-line tool that shows your Kerberos tickets). It’s valid for 10 hours by default, renewable for 7 days.

What Kerberoasting exploits: If you request a service ticket for an SPN registered to a domain user account, the KDC encrypts it with that account’s hash, and you can take it offline and crack it.

2) TGS-REQ / TGS-REP

You open \\fileserver\share. Your machine needs a ticket for the file server. It doesn’t ask for your password again:

Your machine sends a TGS-REQ to the KDC containing:

  • Ticket-Granting Ticket (TGT): The ticket obtained during the initial AS-REQ/AS-REP phase, which is encrypted with the krbtgt account key.
  • Authenticator: A message containing the client’s identity (username) and a timestamp, encrypted with the session key derived from the TGT.
  • Service Principal Name (SPN): The identifier of the specific network service or resource the client wants to access

The KDC decrypts the TGT using krbtgt’s hash, extracts the session key, uses it to decrypt the authenticator, verifies the timestamp, and confirms you are who you say you are.

The KDC issues a service ticket (TGS-REP) containing:

  • A new service session key encrypted with the original session key (so you can read it)
  • The actual service ticket encrypted with the file server’s machine account hash, you cannot read this blob, only the file server can

3) AP-REQ / AP-REP

Your machine connects to the file server and sends an AP-REQ (REQ Application Request) with:

  • The service ticket (still encrypted, which you just carried from the KDC)
  • A new authenticator encrypted with the service session key

The file server uses its own machine account password hash (stored locally and in AD) to decrypt the service ticket. Inside it finds: your identity, your PAC (Privilege Attribute Certificate, your group memberships, used for authorization), and the service session key.

The file server uses the service session key to decrypt your authenticator and verify the timestamp.

If requested, the server sends an AP-REP back, a mutual authentication confirmation. This is how your client knows it’s talking to the real file server and not an impersonator.

The KDC is never involved in Phase 3. The file server validates everything locally. This is Kerberos’s biggest architectural feature, and its biggest weakness (pass-the-ticket attacks work because the service can’t distinguish a stolen ticket from a legitimate one).

The AD-specific pieces

The PAC (Privilege Attribute Certificate) is embedded inside every ticket. It lists your SIDs, your user SID and every group SID you belong to. The file server reads this to decide what you can access without phoning home to AD. This is why adding someone to a group doesn’t take effect until they get a new TGT (log out and back in, or klist purge + gpupdate).

Pre-authentication is on by default, that’s the encrypted timestamp in Phase 1. If it’s disabled on an account (AS-REP Roasting target), the KDC will hand back an AS-REP without verifying identity first, and the encrypted portion can be cracked offline.

The 5-minute clock skew is enforced on every ticket validation. AD environments that don’t sync time via NTP will see authentication failures that look completely random — the KDC rejects the timestamp as a replay attack.

Port 88 UDP/TCP If a client can’t reach the DC on 88, it silently falls back to NTLM. That fallback is why you sometimes see NTLM in environments that are “Kerberos only”, firewall rules or split-brain DNS pointing at the wrong DC.