Windows 2000 LSA Local Account Authentication

In Microsoft Windows 2000, the Local Security Authority (LSA) serves as the central security subsystem responsible for verifying user identities, enforcing local security policies, and generating security access tokens. During a local account logon, the LSA coordinates between user interface components, authentication protocols, and the local account database to determine whether a user is granted access to the operating system.

The Authentication Architecture

Local authentication in Windows 2000 relies on the interaction between several core components managed by the Local Security Authority Subsystem Service (lsass.exe):

  • Winlogon and GINA: The Winlogon process and the default Graphical Identification and Authentication DLL (msgina.dll) capture user credentials entered at the logon screen.
  • Local Security Authority (LSA): The protected subsystem that manages the authentication flow, invokes authentication packages, and enforces system security policies.
  • MSV1_0 Authentication Package: The default authentication protocol module used by Windows 2000 for local logons.
  • Security Accounts Manager (SAM): The database that securely stores local user accounts, group memberships, and cryptographic password hashes.

The Step-by-Step Local Authentication Process

  1. Credential Capture and Dispatch: When a user initiates a logon via the secure attention sequence (Ctrl+Alt+Del), Winlogon and GINA capture the username, password, and local computer name. Winlogon immediately hands these credentials over to the LSA via a secure inter-process call.

  2. Selecting the Authentication Package: Upon receiving the logon request, the LSA determines the context of the request. For accounts residing on the local machine rather than an Active Directory domain, the LSA routes the credentials to the MSV1_0 authentication package.

  3. Validation Against the SAM: The MSV1_0 package converts the supplied cleartext password into cryptographic hashes (LAN Manager and NTLM hashes) and queries the local SAM database. The SAM checks:

    • Whether the account exists in the local database.
    • If the submitted password hash matches the stored hash.
    • Account restrictions such as account expiration, account lockouts, disabled status, or logon hour limitations.

  4. Access Token Generation: If the SAM successfully validates the credentials, it returns the user’s Security Identifier (SID), group SIDs, and assigned privileges back to MSV1_0, which returns them to the LSA. The LSA then constructs an Access Token. This token defines the user's complete security context for the duration of the session.

  5. Session Initialization: The LSA hands the newly created access token back to Winlogon. Winlogon then launches the user interface shell (typically explorer.exe) using this access token, ensuring that any process started by the user inherits their specific rights and permissions.

Auditing and Policy Enforcement

In addition to handling the credential handshake, the LSA consults the Local Security Policy to enforce rules specific to the local machine, such as the "Log on locally" user right. If this permission is absent, the LSA terminates the logon attempt even if the password is valid. Finally, the LSA logs the success or failure of the logon attempt into the Windows Security Event Log, provided that logon auditing is enabled on the system.