How Windows 2000 Processes Nested Group Access Checks

In Microsoft Windows 2000, nested group membership allows administrators to place groups inside other groups to streamline role-based authorization across domains. During an access check, the operating system does not traverse the group hierarchy in real time; instead, it resolves all transitive, nested memberships at the time of logon or resource connection to build an access token containing a complete list of Security Identifiers (SIDs). The Security Reference Monitor (SRM) then compares these pre-compiled SIDs against the target object's Discretionary Access Control List (DACL) to grant or deny access.

Group Scopes and Nesting Rules

Windows 2000 introduced Active Directory, which supports three primary group scopes, provided the domain runs in Native Mode:

  • Global Groups: Can contain user accounts and other Global groups from the same domain.
  • Universal Groups: Can contain accounts, Global groups, and other Universal groups from any domain in the forest.
  • Domain Local Groups: Can contain accounts, Global groups, and Universal groups from any domain, as well as other Domain Local groups from the same domain.

This structure allows the implementation of the AGDLP (Account -> Global -> Domain Local -> Permission) or AGUDLP (Account -> Global -> Universal -> Domain Local -> Permission) strategies.

Token Creation and Recursive Group Expansion

The processing of nested memberships begins well before a user attempts to open a file or access a secured resource.

  1. Authentication: When a user logs on, the authentication service (Kerberos v5 or NTLM) verifies credentials.
  2. Recursive SID Gathering: The Key Distribution Center (KDC) or the Local Security Authority (LSA) queries Active Directory to identify every group to which the user belongs directly.
  3. Transitive Evaluation: The system recursively evaluates the memberOf attributes to find parent groups. If User A belongs to Global Group B, and Global Group B is a member of Universal Group C, the SIDs for both Group B and Group C are retrieved.
  4. Local Group Evaluation: When connecting to a resource on a remote server, the resource server's local LSA queries its local directory to identify any Domain Local groups that contain the user's domain-level SIDs.
  5. Access Token Construction: The operating system consolidates the user's primary SID, direct group SIDs, and all indirectly inherited (nested) SIDs into a single, flat array inside the user's access token.

The Security Reference Monitor Access Check

Once the access token is populated, the actual access check performed by the Security Reference Monitor (SRM) is straightforward and efficient:

  1. Request Initiation: The user requests access (e.g., Read, Write) to an object protected by a Security Descriptor.
  2. DACL Parsing: The SRM reads the Access Control Entries (ACEs) within the object’s DACL sequentially, from top to bottom.
  3. SID Matching: The SRM compares the SID in each ACE against the list of SIDs stored in the user's access token. Because the token was flattened during generation, the SRM treats SIDs derived from nested groups identically to direct group SIDs.
  4. Evaluation Logic:
    • If an Access-Denied ACE matches any SID in the token for the requested access rights, access is immediately denied.
    • If an Access-Allowed ACE matches a SID in the token, the requested permissions are accumulated.
    • Once all requested permissions are satisfied, the SRM stops evaluating and grants access.
    • If the end of the DACL is reached and any requested permission remains ungranted, access is denied.

By resolving nested group hierarchies during token creation rather than at the moment of resource evaluation, Windows 2000 minimizes directory lookup overhead and ensures consistent performance during access checks.