Kerberos and Windows Authentication

Every Linux admin has met Kerberos, usually at the moment it breaks SSH and they discover that the GSSAPI auth they enabled depends on a ticket they do not have. The MIT Kerberos you half-learned and the Kerberos inside Active Directory are the same protocol — AD’s domain controllers are Kerberos KDCs, as the fundamentals post laid out. What makes the Windows version worth a dedicated treatment is not the protocol mechanics, which are classic and elegant, but the attacks — a whole taxonomy of credential abuse that exploits exactly how AD implements tickets, and that every defender needs to recognize on sight because they are the bread and butter of every real-world domain compromise.

This post walks the protocol first, because you cannot understand the attacks without it, then the attacks, because understanding the protocol without knowing how it is abused leaves you defending the wrong things.

Why NTLM still exists, and why that matters

Before Kerberos, Windows authenticated with NTLM — a challenge-response scheme where the server (or a DC) proves you know your password hash without sending the password. NTLM is old, cryptographically weak by modern standards, and Microsoft has spent fifteen years trying to kill it. It persists anyway, and the reasons are exactly the reasons it is dangerous.

NTLM works when Kerberos cannot: connecting to a resource by IP address instead of name (no SPN to request a ticket for), across certain trust configurations, in workgroup (non-domain) scenarios, and in a long tail of legacy applications that simply never learned Kerberos. Because it must remain available as a fallback, an attacker can often force NTLM — downgrade an authentication to the weaker protocol — and then attack it. The single most important NTLM fact for a defender: NTLM authentication uses the password hash directly as the secret, which means the hash is password-equivalent. Steal the hash and you do not need to crack it; you can authenticate with it as-is. That property is the foundation of pass-the-hash, below, and it is why NTLM’s persistence is not a cosmetic legacy concern but an active part of the attack surface. Windows 11 24H2 and Server 2025 are pushing NTLM toward deprecation with new controls to audit and block it, but “deprecated” and “gone” are very different states, and NTLM will be answerable in most environments for years.

Kerberos: the protocol, walked

Kerberos replaces “send proof of your password to every service” with “prove yourself once to a trusted third party, then present tickets.” The trusted third party is the KDC (Key Distribution Center), which in AD is every domain controller. The genius of the design is that the KDC vouches for you cryptographically so that services never see your password and the KDC never has to be contacted again for the life of a ticket.

There are three parties and two phases:

   CLIENT                         KDC (Domain Controller)            SERVICE
     |                                  |                               |
     |   1. AS-REQ (I am alice,         |                               |
     |      here's proof: timestamp     |                               |
     |      encrypted with my pw hash)  |                               |
     |--------------------------------->|                               |
     |                                  | verifies, then issues:        |
     |   2. AS-REP: a TGT               |                               |
     |      (encrypted with KRBTGT's    |                               |
     |       key — alice can't read it) |                               |
     |      + a session key             |                               |
     |<---------------------------------|                               |
     |                                  |                               |
     |   3. TGS-REQ (here's my TGT,     |                               |
     |      I want a ticket for         |                               |
     |      service HTTP/web01)         |                               |
     |--------------------------------->|                               |
     |                                  | validates TGT, issues:        |
     |   4. TGS-REP: a SERVICE TICKET   |                               |
     |      (encrypted with the         |                               |
     |       SERVICE account's key)     |                               |
     |<---------------------------------|                               |
     |                                                                  |
     |   5. AP-REQ: present the service ticket to web01                 |
     |---------------------------------------------------------------->|
     |                                  service decrypts it with ITS    |
     |                                  own key, trusts the contents,   |
     |                                  grants access. KDC not involved.|

Phase one, authentication (AS): the client proves its identity to the KDC (by encrypting a timestamp with a key derived from its password — this is pre-authentication) and receives a Ticket-Granting Ticket (TGT). The TGT is encrypted with the secret key of a special account named KRBTGT — the account whose key signs every TGT in the domain. The client cannot read its own TGT; it just holds it and presents it back later.

Phase two, authorization (TGS): when the client wants to reach a service, it presents its TGT to the KDC and asks for a service ticket for that specific service. The KDC validates the TGT and issues a service ticket encrypted with the target service account’s key. The client presents this to the service; the service decrypts it with its own key, sees the KDC’s vouching, and grants access without ever contacting the KDC. That last property — services validate tickets offline using their own key — is what makes Kerberos scale, and, as we will see, it is exactly what silver tickets abuse.

Two structural facts to hold onto, because every attack hangs off one of them:

1. The KRBTGT key signs all TGTs. Whoever knows the KRBTGT hash can forge a TGT for anyone. That is the golden ticket.
2. Each service account’s key signs its own service tickets, validated offline. Whoever knows a service account’s hash can forge service tickets for that service. That is the silver ticket. And service tickets are encrypted with the service account’s key, so anyone who can request one can take it away and crack it offline. That is Kerberoasting.

Also note the dependency the fundamentals post warned about: every step is timestamped, and the KDC rejects tickets with more than ~5 minutes of clock skew. Kerberos requires synchronized time. A machine with a bad clock cannot authenticate, and the failure looks like everything except a clock problem.

SPNs: how a service is named

A Service Principal Name (SPN) is the identifier a client uses to ask for a service ticket — HTTP/web01.contoso.com, MSSQLSvc/db01.contoso.com:1433, CIFS/fileserver. Each SPN is registered against the AD account that runs the service, so the KDC knows whose key to encrypt the service ticket with. The chain is: client wants to talk to a host’s service → looks up the SPN → asks KDC for a ticket for that SPN → KDC finds the account holding that SPN → encrypts the ticket with that account’s key.

SPNs matter for two reasons. Operationally, a duplicate or missing SPN is a classic Kerberos failure — if the SPN is not registered, or registered on two accounts, the client silently falls back to NTLM or fails, and “Kerberos isn’t working for this service” is very often “the SPN is wrong.” For security, SPNs are the enumeration target: any authenticated user can query AD for all accounts that have SPNs registered, which is to say, a list of every service account whose tickets can be requested and cracked. That query is the first step of Kerberoasting.

Delegation: necessary, and dangerous

Sometimes a service needs to act as the user toward a second service — a web server that must query a database on the user’s behalf, carrying the user’s identity through. Kerberos delegation allows this, and it comes in three flavors of increasing safety:

Unconstrained delegation is a five-alarm fire and a top finding in any AD assessment. A server trusted for unconstrained delegation receives and caches the TGT of every user who authenticates to it. Compromise that server and you harvest TGTs — including, if you can lure or coerce a domain admin or a DC to authenticate to it, the keys to the kingdom. Constrained and resource-based delegation exist precisely to bound this, and the modern recommendation is to eliminate unconstrained delegation entirely and prefer RBCD where delegation is genuinely needed. If you audit one thing in an inherited domain, audit which accounts are trusted for unconstrained delegation.

The attacks every defender must recognize

Now the protocol pays off. Each of these maps directly to a structural fact above, and together they form the standard kill chain of a domain compromise. The typical path strings them together: phish a foothold → harvest hashes → pass-the-hash laterally → enumerate and Kerberoast a service account → crack it → silver/pass-the-ticket to escalate → reach a DC, steal KRBTGT → golden ticket for permanent persistence.

Kerberoasting

The most common and most practical. Because any authenticated user can (1) enumerate accounts with SPNs and (2) request a service ticket for any of them, and because that ticket is encrypted with the service account’s password-derived key, an attacker requests tickets for service accounts and cracks them offline. No special privileges, no contact with the targeted service, nothing that looks abnormal — just normal Kerberos traffic. The crack succeeds when the service account has a weak, human-set password, which service accounts notoriously do (set once in 2014, never rotated, “Summer2014!”).

The defense is entirely about the password and the cipher: service accounts must have long, random passwords so offline cracking fails, and tickets must use AES rather than RC4, because RC4-encrypted tickets crack far faster. This is why Group Managed Service Accounts (gMSA) and the newer Delegated Managed Service Accounts (dMSA) matter — their passwords are 120+ characters, random, and rotated automatically by AD, making the cracked-offline path computationally hopeless. The 2025/2026 RC4 deprecation in Windows Server 2025 (RC4 off by default for new domains) directly attacks Kerberoasting’s economics. Detection watches for anomalous volumes of service-ticket requests (event ID 4769), especially requests for RC4 tickets.

1
2
3
4

# Defender's audit: which service accounts are Kerberoastable, and how strong?
Get-ADUser -Filter {ServicePrincipalName -like "*"} -Properties ServicePrincipalName, PasswordLastSet, msDS-SupportedEncryptionTypes |
  Select-Object Name, PasswordLastSet, ServicePrincipalName
# Old PasswordLastSet + RC4 support = a Kerberoasting waiting to happen.

Pass-the-Hash (PtH)

This one is NTLM’s gift, not Kerberos’s. Because NTLM uses the password hash as the authentication secret, an attacker who steals a hash (from a machine’s memory, the SAM, or LSASS) can authenticate as that user without ever cracking it — the hash is password-equivalent. PtH is how attackers move laterally: dump hashes on machine A, use a local admin’s hash to authenticate to machine B, repeat. The defenses are about not having reusable hashes lying around: do not reuse local admin passwords across machines (Microsoft’s LAPS randomizes them per-machine), limit where privileged accounts log in (so their hashes are never cached on a workstation an attacker controls), and enable Credential Guard to protect LSASS. Tiered administration — admins never log into lower-tier machines with high-tier credentials — exists specifically to deny PtH its fuel.

Pass-the-Ticket (PtT)

The Kerberos analogue: instead of stealing a hash, steal an actual Kerberos ticket (a TGT or service ticket) from a machine’s memory and inject it into the attacker’s own session to impersonate the user for the ticket’s lifetime. Stealing a TGT is especially valuable — it lets the attacker request service tickets for anything the user can reach. PtT is harder to prevent outright (a valid ticket is a valid ticket) and is mostly fought by protecting credential memory (Credential Guard), keeping ticket lifetimes short, and detecting anomalies — a ticket used from a machine or IP it was not issued for.

Silver Tickets

Recall that a service validates its own service tickets offline, using only its own account key, never asking the KDC. So an attacker who knows a service account’s hash can forge service tickets for that service directly — a “silver ticket” — and the service will accept them, because it has no way to check with the KDC. The forged ticket can claim any group memberships the attacker likes. Silver tickets are stealthier than golden tickets because they never touch a DC. The defense flows from the cause: protect service account keys (strong/managed passwords, again gMSA/dMSA), and enable PAC validation where feasible so the service does a back-check with the KDC rather than trusting the ticket blindly.

Golden Tickets

The endgame. The KRBTGT account’s key signs every TGT in the domain. An attacker who obtains the KRBTGT hash — which requires already having compromised the domain (typically domain-admin or DC access, via the steps above) — can forge a TGT for any user, with any group memberships, with an arbitrary lifetime. This is a “golden ticket,” and it is persistence, not initial access: it lets the attacker re-enter as any identity, including a fabricated domain admin, even after passwords are reset — because the only thing that invalidates existing golden tickets is changing the KRBTGT password twice (twice, because AD keeps the current and previous key, so a single change leaves forged tickets valid against the retained old key). Discovering a golden ticket means the domain is fully compromised and the standard remediation is the painful double-KRBTGT-reset plus a full credential-rotation incident. Detection is hard by design (a forged TGT looks legitimate); the realistic posture is preventing KRBTGT compromise in the first place by protecting domain admin and DC access ruthlessly.

What Windows Server 2025 changes

The 2025/2026 cycle is the most security-relevant Kerberos update in years, and most of it directly targets the attacks above:

• RC4 disabled by default for new Server 2025 AD installs (rolling out through early 2026). RC4’s weak, fast-to-crack encryption is what makes Kerberoasting economical; AES-only raises the cost dramatically. Existing domains keep RC4 for backward compatibility unless you turn it off, so this protects greenfield builds first.
• AES enforcement guidance: configure every service account for AES (128/256) and — the easily-missed step — change the password after switching the encryption type, or the account keeps a crackable RC4-derived key and remains Kerberoastable.
• Delegated Managed Service Accounts (dMSA): the successor to gMSA, with automatic, machine-bound credential management that closes the weak-service-account-password hole driving Kerberoasting and silver tickets.
• NTLM deprecation controls: new auditing and blocking of NTLM, chipping at the pass-the-hash and downgrade attack surface — though NTLM’s long tail means this is a multi-year transition, not a switch.

The throughline of Microsoft’s 2025 work is the recognition that the dangerous defaults — RC4, weak service-account passwords, NTLM fallback — were the attacker’s best friends, and that secure-by-default for new domains is the only durable fix. A greenfield Server 2025 forest is in materially better shape against this entire attack taxonomy than a domain carried forward from 2012.

The defender’s summary

Pulling the protocol and the attacks together into what to actually do:

• Kill RC4, deploy AES, and rotate service-account passwords after the switch — this single change undercuts Kerberoasting and silver tickets at once.
• Use gMSA/dMSA for service accounts so passwords are long, random, and auto-rotated, making offline cracking pointless.
• Eliminate unconstrained delegation; prefer resource-based constrained delegation where delegation is genuinely required.
• Deny reusable credentials: LAPS for unique local admin passwords, tiered administration so privileged hashes never land on low-trust machines, Credential Guard to protect LSASS.
• Protect KRBTGT and DC access above all — golden tickets are unpreventable once KRBTGT leaks, so the only real defense is never letting the domain be compromised to that depth.
• Watch the logs: 4768/4769 for ticket anomalies, RC4 ticket requests, abnormal service-ticket volumes, and tickets used from unexpected sources.
• Monitor and constrain NTLM as a path to retiring it, since its hash-equivalence is what makes pass-the-hash work.

None of these is exotic; they are the difference between a domain where a single phished laptop leads to full compromise in an afternoon and one where the attacker hits a wall at every escalation step. Kerberos itself is sound — the attacks are not breaks in the cryptography but abuses of how AD configures and trusts it, which is exactly why the defenses are configuration and operational discipline rather than patches. Understand the protocol, recognize the attack names when they show up in an alert, and you are equipped to defend the system that, like it or not, anchors the identity of nearly every enterprise — including the Linux machines you will join to it in the next post.

Sources and further reading

• MITRE ATT&CK — Steal or Forge Kerberos Tickets: Golden Ticket (T1558.001)
• Microsoft Security Blog — guidance to help mitigate Kerberoasting
• Netwrix — Kerberoasting attack: detection and prevention
• Optiv — Kerberos tickets: vulnerabilities and solutions
• StationX — Golden Ticket attack explained
• Cymulate — Pass-the-Ticket attack: detection and prevention

This is the third post in the Windows Server and Active Directory series. Next: PowerShell for Administrators — the automation language behind every command in this series.