Windows 2000 Access Tokens in Process Creation

In Microsoft Windows 2000, the Security Access Token is the core operating system structure that defines the security context of every executing process and thread. During process creation, this token establishes the identity, group memberships, and administrative privileges that the new process possesses throughout its lifecycle. It dictates the security boundaries of the new process, determining precisely which system resources the process can access and what system-level actions it is authorized to perform.

The Fundamentals of an Access Token

An access token acts as a digital credential assigned to a user session upon a successful authentication by the Local Security Authority Subsystem Service (LSASS). The token contains critical security data, including:

  • The user's Security Identifier (SID).
  • SIDs for all security groups the user belongs to.
  • A list of specific user privileges (such as SeBackupPrivilege or SeShutdownPrivilege).
  • A default Discretionary Access Control List (DACL) applied to any securable objects the process creates.
  • The primary group SID and token source information.
  • Restricted SIDs, which Windows 2000 introduced to limit permissions for specific tasks.

Default Token Inheritance via CreateProcess

When a typical application spawns a child process using the CreateProcess API, the child process does not generate a new security token from scratch. Instead, the Windows 2000 kernel creates a duplicate of the parent process's primary access token and assigns it to the child.

This inheritance mechanism ensures that the child process operates strictly within the security boundaries of the parent. If a standard user launches an application, any secondary processes spawned by that application inherit identical rights and limitations. The child process cannot elevate its own permissions beyond what the parent’s primary token allows.

Explicit Token Assignment via CreateProcessAsUser

Windows 2000 supports scenarios where a process must be created under a different security context, commonly utilized by system services such as Winlogon or the Task Scheduler. This is handled via the CreateProcessAsUser API.

In this workflow, the calling process explicitly supplies an access token to attach to the new process:

  1. Privilege Validation: The calling process must possess specific, high-level privileges: SeAssignPrimaryTokenPrivilege and SeIncreaseQuotaPrivilege.
  2. Token Association: The operating system assigns the provided token as the primary token of the new process rather than duplicating the caller's token.
  3. Session Isolation: This allows administrative services running under the LocalSystem account to spawn interactive desktop applications under the logged-on user's restricted access token.

Restricted Tokens in Windows 2000

Windows 2000 introduced the ability to create "restricted tokens" using the CreateRestrictedToken function. During process creation, a parent process can strip privileges, mark SIDs as "deny-only," or append a list of restricting SIDs before handing the token to the child process. This feature was an early sandboxing mechanism, allowing developers to execute untrusted code with fewer rights than the user running the process normally held.

Access Checks and Object Creation

Once process creation completes, the Security Reference Monitor (SRM) uses the assigned primary token whenever the process attempts to open a handle to a securable object (such as files, registry keys, or synchronization primitives). The SRM compares the SIDs and privileges stored inside the token against the Access Control Entries (ACEs) within the target object's DACL, either granting or denying access before any operation executes.