Windows domains, part 3: Kerberos and NTLM — how Windows actually proves who you are

Part 3from the Windows domains series · 6 parts in all

Forests and transitive trusts only pay off if the authentication protocol is worth trusting transitively. This part is the protocol deep-dive: NTLM, the NT-era scheme that refuses to die, and Kerberos, the MIT-derived design AD bet on in 2000.

NTLM: prove you know the secret, without sending it

NTLM is a three-message challenge/response. The server sends a random challenge; the client responds with a hash of the challenge keyed by the user's password material; the server (or the DC, via pass-through) checks it. NTLMv1 was cryptographically weak — response blocks that could be attacked piecewise — so NTLMv2 added a client nonce and an HMAC over more context, and that is what "NTLM" means in practice today. Its core flaw is structural: every service the user touches must reach the DC to validate the response, and the protocol offers no server authentication — which is exactly the gap NTLM relay attacks (including the 2020 Zerologon episode's cousin family) keep demonstrating.

Kerberos: tickets instead of passwords

Kerberos splits proof-of-identity from access. At logon, the client runs an AS exchange with the DC's KDC and receives a TGT — encrypted to the KRBTGT account's key, usable for the domain's lifetime (default 10 hours). To call a service, the client shows the TGT and receives a service ticket encrypted with the target service account's key. No password material ever touches the server; the DC only participates at ticket issuance; and the whole thing is mutual — the service proves itself too. The linchpin identity detail is the SPN: the service class/host pair (e.g. cifs/fs01.maplecart.local) that tells the KDC which key to encrypt the ticket with. Broken SPNs are why "it works by FQDN but not by IP" is a permanent helpdesk classic — and note the fallback that makes it work anyway: IP access silently drops to NTLM.

:: kerberos in action on a domain-joined workstation
klist                  :: your TGT and every cached service ticket
klist get cifs/fs01    :: fetch or renew a service ticket for the file share
setspn -L FS01         :: the SPNs the machine account owns
whoami /user           :: the SID - what both Kerberos tickets and NTLM tokens carry

:: where NTLM still answers instead: access by IP, missing SPN, workgroup
:: member, or the classic double-hop (a service calling onward on your behalf)

Delegation: the double-hop tax

A web server that authenticates the user can act as the user locally, but its outbound call to a database is a second hop the user never made — Kerberos by default does not forward credentials. The honest fixes, in order of preference: constrained delegation (the service may present delegated tickets only to named services), protocol transition (Kerberos in, any inbound accepted out, still constrained), and CredSSP or explicit credentials as last resorts. Every "works interactively, fails as a service" bug report traces back to this paragraph.

Part 4 walks the feature arc the forest gained from Server 2008 R2 through 2019 — recycle bins, roving read-only DCs, managed service passwords, and the hardening years.