LSASS, SAM, and local security policy

Authentication & logon described a pipeline: gather credentials, validate them, produce a token. This chapter is about the process that owns the validation step and the security policy underneath it: LSASS (Local Security Authority Subsystem Service).

What LSASS actually is

LSASS hosts the LSA (Local Security Authority) — the broader security logic responsible for local security policy, authentication package coordination, and logon session management — not merely "the thing that checks passwords." Concretely, LSASS:

• Hosts and coordinates authentication packages (Kerberos, NTLM, and authentication packages covers these), routing a logon attempt to whichever package is appropriate for the scenario.
• Consults the SAM (Security Accounts Manager) database for local, machine-specific accounts — the accounts that exist on this machine specifically, as opposed to a domain's accounts.
• Enforces local security policy: password requirements, account lockout behavior, audit policy, and privilege assignment (which accounts and groups hold which privileges, from Privileges (Se*)).
• Manages logon sessions — the internal records, created once per successful authentication, that later token creation and credential caching build on.

Why LSASS is such a sensitive process

Because LSASS is where authentication decisions get made and, in the course of doing so, handles credential material — including, for interactive logons using certain authentication configurations, cached data that can be reconstructed into usable credentials — it has historically been one of the highest-value targets for attackers who've already gained a foothold on a machine and want to escalate or move laterally to other systems. This is exactly why modern Windows offers Protected Process Light (PPL) for LSASS: a mode where even code running as SYSTEM is prevented from opening arbitrary handles into LSASS's memory, specifically to close off a whole class of credential-dumping techniques that otherwise rely on nothing more than sufficient local privilege — the full mechanism behind that protection is covered in Protected Processes & PPL.

SAM: the local, machine-specific store

The SAM database holds account records for identities that exist only on this machine — a local administrator account created during setup, for instance, as opposed to a domain account whose authoritative record lives on a domain controller. When you sign in with a local account, LSASS consults SAM directly rather than reaching out to any network authority; the entire decision is made using data that exists on that one machine. This is exactly the mechanism behind the everyday observation that a laptop can authenticate a local account while completely disconnected from any network.

A worked example: why local and domain sign-in feel identical but aren't

From the user's point of view, typing a password at LogonUI looks the same whether the account is local or domain-joined. Underneath, LSASS is making a genuinely different decision in each case: for a local account, it validates directly against SAM; for a domain account, it routes the request through the Kerberos (or, in fallback and legacy scenarios, NTLM) authentication package, which in turn talks to a domain controller. Both paths converge on the same end result — a token, built the same way — but the identity source and the trust chain behind it are entirely different.

A common mistake

Thinking of LSASS as narrowly "the password checker" undersells both its actual scope (security policy enforcement, session management, package coordination) and its actual risk profile (a process whose compromise can expose credential material for every recently-authenticated identity on the machine, not just the current one). Its protection level (PPL or not) is a meaningful, checkable security posture question on any real Windows machine, not an obscure implementation detail.

Where this connects

• Kerberos, NTLM, and authentication packages covers the pluggable protocol engines LSASS hosts and coordinates.
• Winlogon, LogonUI, and session sign-in covers how a credential actually reaches LSASS in the first place.
• Protected Processes & PPL covers the mechanism behind LSASS's own process protection in full.