Windows 2000 Security Subsystem Architecture

The Windows 2000 Security Subsystem provides a robust framework for authentication, access control, and auditing across standalone systems and distributed Active Directory environments. This article breaks down the primary user-mode and kernel-mode components that comprise the Microsoft Windows 2000 security architecture, outlining their respective roles and how they coordinate to enforce security policies and protect system resources.

Architectural Model Overview

The Windows 2000 security architecture is split between User Mode and Kernel Mode. User-mode components handle user interaction, policy definitions, credential processing, and authentication requests. The kernel-mode component acts as the ultimate gatekeeper, directly enforcing access control checks on protected system objects.

User-Mode Components

The user-mode layer encompasses several interconnected services, dynamic link libraries (DLLs), and databases that manage logon requests and authenticate identities.

1. Winlogon and GINA

  • Winlogon (winlogon.exe): A specialized user-mode process responsible for managing interactive logon and logoff sessions. It responds to the secure attention sequence (SAS)—typically Ctrl + Alt + Delete—to guarantee that the logon screen cannot be spoofed by malicious software.
  • Graphical Identification and Authentication (GINA): A dynamic link library (default is msgina.dll) loaded by Winlogon to obtain user credentials (username, password, domain) from the interactive interface.

2. Local Security Authority Subsystem Service (LSASS)

Operating as lsass.exe, LSASS hosts the security engine for user mode. It manages authentication protocols, handles local security policies, and coordinates token generation. Key sub-components inside or directly managed by LSASS include:

  • Local Security Authority (LSA): The central module within LSASS that:
    • Generates user Access Tokens containing the user's Security Identifier (SID), group SIDs, and granted privileges.
    • Enforces the Local Security Policy (audit settings, user rights assignments).
    • Directs audit events generated by the system to the Event Log.
  • Security Support Provider Interface (SSPI): An abstraction layer that decouples application-layer protocols (such as RPC, HTTP, or SMB) from underlying authentication mechanisms. Applications call the SSPI to request authentication without needing internal knowledge of the specific protocol used.
  • Security Support Providers (SSPs) / Authentication Packages:
    • Kerberos v5: The primary, default authentication protocol for domain-joined machines in Windows 2000. It relies on ticket-granting services provided by Active Directory domain controllers.
    • NTLM (NT LAN Manager): Retained for backward compatibility with Windows NT 4.0, down-level clients, and local machine logons.
    • Schannel (Secure Channel): Provides public key-based authentication supporting SSL/TLS protocols.

3. Account Databases

Depending on the role of the machine, credentials and security policies are stored in one of two repositories:

  • Security Accounts Manager (SAM): A local database used on standalone workstations and member servers to store local user accounts, local groups, and password hashes.
  • Active Directory (AD): The enterprise directory service implemented on Windows 2000 Domain Controllers (ntds.dit). It stores enterprise-wide accounts, group memberships, and Kerberos keys.

4. Net Logon Service (netlogon.dll)

Manages the secure communication channel between a Windows 2000 workstation or member server and a Domain Controller. It handles NTLM passthrough authentication and helps locate domain controllers for logon verification.

Kernel-Mode Components

Kernel-mode security is represented by a single, critical component integrated into the Windows 2000 Executive (ntoskrnl.exe).

Security Reference Monitor (SRM)

The Security Reference Monitor is the kernel-level authority responsible for:

  • Access Validation: When a thread attempts to open an object (files, registry keys, semaphores, processes), the SRM compares the thread's Access Token against the Discretionary Access Control List (DACL) in the target object's Security Descriptor.
  • Privilege Checking: Ensures a process or thread possesses the necessary system privileges (e.g., SeBackupPrivilege) before allowing sensitive system-level actions.
  • Audit Generation: Compares object access attempts against the object's System Access Control List (SACL) and passes resulting audit records back to the LSA for writing to the Security Event Log.

Component Interaction: The Authentication and Access Cycle

  1. Logon Initiation: The user presses Ctrl + Alt + Delete. Winlogon invokes the GINA DLL to prompt for credentials.
  2. Credential Hand-off: Winlogon sends the credentials to LSASS.
  3. Authentication: LSASS selects the proper authentication package via SSPI (Kerberos for domain environments, NTLM for local accounts). The credentials are confirmed against Active Directory or the local SAM.
  4. Token Creation: The LSA creates an Access Token populated with the user's SIDs, group memberships, and assigned privileges, returning it to Winlogon.
  5. Session Launch: Winlogon starts the Windows shell (such as explorer.exe) and attaches the Access Token to the process. Child processes inherit this token.
  6. Object Access Verification: When an application attempts to access a protected object, the kernel's Object Manager calls the Security Reference Monitor (SRM). The SRM compares the Access Token to the object's Security Descriptor, either granting or denying access and generating an audit trail if configured.