Kerberos, NTLM, and authentication packages

LSASS, SAM, and local security policy described LSASS as coordinating pluggable authentication packages rather than hardcoding one protocol. This chapter is about the two packages you'll encounter constantly in practice — Kerberos and NTLM — and the framework (SSPI) that lets applications use either without caring which one is actually running underneath.

SSPI: one interface, multiple protocol engines

Applications and services that need to authenticate a connection — a file share, an RPC call, a database connection — generally don't implement authentication logic themselves. They call into SSPI (Security Support Provider Interface), a common API surface that any registered security support provider can implement. This is the same layering principle as almost everything else in this course: the application code stays the same regardless of which specific package ends up handling the exchange, which is exactly what makes it possible for Windows to change the preferred protocol over time (as it has, moving from NTLM-primary to Kerberos-primary) without breaking applications written against SSPI.

Kerberos: the preferred protocol for domain environments

For domain-joined machines, Kerberos is the preferred authentication protocol, and it works fundamentally differently from a simple password check: rather than proving identity fresh to every single server you talk to, you authenticate once to a trusted third party (a domain controller acting as the Key Distribution Center) and receive a ticket — cryptographically signed proof of your identity, with a limited lifetime, that you can then present to any server that trusts the same KDC.

This ticket-based design is precisely why, once you're signed in on a domain, accessing a second, third, and tenth server generally doesn't prompt you for credentials again: each of those servers can validate your existing ticket (or request a service-specific ticket derived from it) without you re-authenticating from scratch, and without your password ever having to be sent to each individual server you talk to.

NTLM: still present, for compatibility and fallback

NTLM predates Kerberos in Windows and remains important for cases Kerberos doesn't cleanly cover: non-domain (workgroup) machines, authentication against a server by IP address rather than name (which can prevent Kerberos's ticket mechanism from working correctly), certain legacy applications, and various fallback scenarios where a Kerberos ticket simply isn't available. NTLM uses a challenge-response exchange instead of tickets — no third-party KDC is consulted; the server itself (or a domain controller it consults on the fly) validates the response directly.

Why the distinction matters beyond trivia

Kerberos and NTLM aren't interchangeable labels for "Windows authentication" — they imply genuinely different flows, different caching behavior, and different trust assumptions, with real operational consequences: NTLM's challenge-response pattern has well-known relay and cracking weaknesses that Kerberos's ticket model was specifically designed to avoid; Kerberos tickets have defined lifetimes and are tied to time synchronization between client and KDC in a way NTLM simply isn't; and diagnosing "why did this connection authenticate the way it did" often comes down to exactly which package actually got selected, which isn't always what an administrator expects or intends.

A worked example: accessing a domain resource by IP address

A user signed in on a domain, accessing a file share by hostname, will typically authenticate via Kerberos without a visible prompt. The same user accessing the same server by raw IP address may silently fall back to NTLM instead — because Kerberos's ticket request depends on a Service Principal Name lookup that's normally tied to the server's registered hostname, and an IP address doesn't resolve to that lookup the same way. The user experience (no visible prompt either way) hides a real difference in which protocol, and which security properties, actually applied.

A common mistake

Assuming "the user signed in successfully" tells you which protocol was used, or that the two protocols are roughly equivalent with different names, glosses over meaningful security and operational differences. Which package actually ran for a given connection is directly observable (via event logs, or tools built for exactly this purpose) and is often the actual answer to "why is this behaving differently than I expected."

Where this connects

• CNG, Schannel & crypto plumbing covers the cryptographic primitives Kerberos, and TLS-protected authentication more generally, actually rely on underneath.
• Access tokens is what a successful authentication of either kind ultimately produces.