Role of Security ID in Windows 2000 Authorization

In Microsoft Windows 2000, the Security Identifier (SID) serves as the core foundation for access control and object authorization. This article explains what a SID is, how it is encapsulated within access tokens during user authentication, and how the operating system evaluates SIDs against Access Control Lists (ACLs) to grant or deny access to system resources.

What Is a Security Identifier (SID)?

A Security Identifier is a unique, variable-length alphanumeric value assigned to every security principal—such as users, global groups, local groups, and computers—created in the local Security Accounts Manager (SAM) or Active Directory.

Windows 2000 identifies accounts strictly by their SIDs rather than their usernames. Even if a user account is renamed, its SID remains unchanged, ensuring that all assigned resource permissions persist. Conversely, if an account is deleted and a new one is created with the identical username, the new account receives a distinct SID and will not inherit any of the previous account's permissions.

The Role of the SID in the Access Token

When a user logs on to a Windows 2000 system, the authentication process creates an access token. The access token contains:

  • The user's primary SID.
  • The SIDs of all groups to which the user belongs (including nested groups).
  • The user's assigned privileges.

Whenever that user launches a process or requests access to a resource, the process runs under the context of this access token, presenting the collected SIDs on behalf of the user.

SIDs and the Authorization Process

Windows 2000 secures resources—such as files, folders, registry keys, and Active Directory objects—using a Security Descriptor attached to each object. A key component of the Security Descriptor is the Discretionary Access Control List (DACL), which contains individual Access Control Entries (ACEs).

When a process attempts to access an object, the Windows 2000 Security Reference Monitor (SRM) performs the authorization check using the following steps:

  1. Token Extraction: The SRM extracts the user SID and group SIDs from the requesting process's access token.
  2. DACL Evaluation: The SRM reads the object's DACL sequentially, examining each ACE. Each ACE specifies an access type (Allow or Deny), the permissions involved (e.g., Read, Write, Delete), and a target SID.
  3. SID Matching: The SRM compares the SIDs in the access token against the SID listed in each ACE.
  4. Permission Resolution:
    • If a matching "Access Denied" ACE is found for any SID present in the token, the requested access is immediately denied.
    • If matching "Access Allowed" ACEs provide all the requested permissions without encountering an explicit deny, the SRM grants access.
    • If the end of the DACL is reached without satisfying all requested rights, access is denied.

Through this mechanism, the Security ID guarantees that object authorization in Windows 2000 remains consistent, persistent, and tamper-resistant across both local systems and distributed Active Directory environments.