Authentication & logon

Every access check this course covers later — every ACL, every token, every privilege — starts from one prior fact: at some point, Windows decided who is asking. This chapter is about that decision: how a credential becomes an authenticated identity Windows can attach to processes, threads, and eventually every request they make.

The pipeline, at a glance

1. Credentials are gathered. A credential provider — password, PIN, Windows Hello biometric, smart card — collects whatever proof of identity it's designed for, on the secure desktop described in Window stations & desktops.
2. An authentication package validates them. Windows doesn't hardcode "check the password" logic in one place; it delegates to a pluggable authentication package — Kerberos for domain scenarios, NTLM as a fallback and for local/legacy cases, or others — through a common interface (SSPI).
3. A logon session is created. On success, Windows creates a logon session: an internal record tying an authenticated identity to a point in time, with associated credential material cached for later use.
4. A token is produced. The logon session's result becomes an access token — the object every later security decision in this course actually consults. Access tokens is where that object is covered in full.

Why this is a pipeline, not a single check

Splitting logon into these stages is what lets Windows support wildly different authentication methods without touching anything downstream. A smart-card logon and a password logon produce the exact same kind of token at the end, consumed identically by every process and access check afterward — the entire difference between them is contained in step 1 and step 2. This is the same design principle as the layering discussed in System architecture: the layers above logon don't need to know or care how identity was proven, only that it was.

Authentication proves identity; it doesn't grant access

The most important distinction this chapter can leave you with: logon answers "who is this," not "what can they do." Successfully authenticating produces a token that represents an identity — whether that identity can then open a specific file, start a specific service, or write to a specific registry key is a completely separate decision, made later, by access checks against the Security Reference Monitor using that token plus the target object's security descriptor. A valid logon and a denied access are not a contradiction; they're two different, correctly-functioning parts of the system.

A worked example: signing in, then reaching a file share later

When you sign in at a domain-joined machine, the logon pipeline above runs once, produces a token, and — because Kerberos was used — also leaves reusable ticket material cached for that logon session. Later, when you open a file share on another server, Windows doesn't ask you to type your password again: it reuses the cached Kerberos ticket material from your original logon to authenticate to the new server transparently. That convenience is a direct, designed consequence of separating "prove identity once" from "use that proof repeatedly" — covered further in Kerberos, NTLM, and authentication packages.

A common mistake

Conflating authentication and authorization is extremely common, and it produces genuinely confusing troubleshooting if you don't separate them: "the user can log on but can't open the file" is not a contradiction requiring an exotic explanation — it's the pipeline working exactly as designed, with step 4 (a valid token) followed by a legitimate denial further down the stack, in Security descriptors & ACLs.

Where this connects

• Winlogon, LogonUI, and session sign-in covers the concrete, visible mechanics of steps 1–2 above.
• LSASS, SAM, and local security policy covers the process that actually hosts this pipeline's logic.
• Access tokens picks up exactly where step 4 leaves off.