Windows Authentication Systems ( Pending)
Windows authentication systems
Windows separates credential collection, authentication, account storage, and
authorization. These components are related, but they are not interchangeable.
Core flow
flowchart LR User[User or service] --> CP[Credential provider or application] CP --> LSA[LSA / LSASS] LSA --> Local[SAM: local account validation] LSA --> Domain[Domain controller: AD DS account validation] Domain --> KDC[Kerberos KDC] LSA --> Token[Local access token after successful logon] LSA --> Cache[Session material: protocol-dependent credentials and tickets]
| Component | What it holds or does | Boundary that matters |
|---|---|---|
| Credential provider | Collects and serializes sign-in material | Collection is separate from validation. |
LSA / lsass.exe | Enforces local security policy and coordinates authentication packages | Active sessions can leave protocol-dependent credential material in memory. Credential Guard can isolate supported secrets in LSAIso.exe. |
| SAM | Local accounts and password verifiers | Used for local validation; it does not store plaintext account passwords. |
Active Directory (NTDS.dit) | Domain principals, attributes, and password-derived verifier/key material | Kerberos tickets are issued by the KDC and cached for sessions; AD is not a ticket warehouse. |
| Access token | SIDs, privileges, integrity level, and other authorization context | Created after logon and associated with processes/threads; it is not stored as an AD credential. |
| Credential Manager | User-saved credentials for supported applications and destinations | Stored under the user profile and protected for that user. |
| Windows LAPS | Rotates and backs up a managed local administrator or DSRM password | AD storage can be ACL-protected cleartext or encrypted when Windows LAPS prerequisites and encryption policy are enabled. |
| Group Policy Preferences passwords | Retired cpassword mechanism | Historical exposure; Microsoft removed the ability to create new password-bearing preferences in 2014. |
Local and domain validation
- A local account is validated against the SAM on that computer.
- A domain account is normally validated by a domain controller using Kerberos
or NTLM, selected through the Negotiate security package. - Successful authentication produces an access token for authorization on the
local system. Authentication evidence and an authorization token serve
different purposes. - Offline domain logon can use cached domain logon information when a domain
controller is unavailable; this cache is separate from the SAM password
verifier for a local account.
Credential protection changes the memory model
Older descriptions often say that LSASS holds every secret directly. With
Credential Guard enabled, supported Kerberos, NTLM, and Credential Manager
secrets are isolated by virtualization-based security in LSAIso.exe, with
LSASS communicating through RPC. Credential Guard has documented protection
limits, so record the actual host configuration before drawing conclusions
from a memory acquisition.
Detailed notes
Operational credential-access procedures belong in the authorized RTO shelf;
this note describes platform architecture and defensive validation boundaries.