Windows Security Principals, Objects, Access Control, and NTFS Permissions

1.1 Security Principals (Users, Groups, Computers)

Security Principals are entities in Windows that authentication systems recognize and assign permissions and rights to. Each principal has a unique Security Identifier (SID). The main types are:

• User Accounts: Represent people or service identities.

  • Local User Accounts: Stored and managed in the local Security Account Manager (SAM) database on a specific machine. Their scope is limited to that machine.
  • Domain User Accounts: Stored and managed in Active Directory Domain Services (AD DS). Authenticated by a Domain Controller (DC), they can access resources across the domain or forest, based on permissions.

• Group Accounts: Collections of other principals (users, computers, other groups) that simplify managing permissions and rights.

  • Security Groups: Used in Access Control Lists (ACLs) to grant or deny permissions.
  • Distribution Groups: Primarily for email lists (like in Microsoft Exchange); cannot assign permissions in ACLs.

  • Group Scopes (in AD DS): Control membership and usability:

    • Domain Local: Can contain members (users, global groups, universal groups) from any domain in the forest, plus other domain local groups from the same domain. Mainly used to grant permissions to resources within its own domain.
    • Global: Can contain members (users, computers, other global groups) only from its own domain. Can be granted permissions in any domain in the forest or trusting domains. Often aggregates users with similar roles within a domain.
    • Universal: Can contain members (users, global groups, universal groups) from any domain in the forest. Can be granted permissions anywhere in the forest. Membership is replicated to the Global Catalog (GC), increasing replication traffic. Best for stable, small groups representing forest-wide roles.
  • Local Groups (Machine Local): Defined in the local SAM database. Can contain local users, domain users, domain global groups, and domain universal groups. Used to grant permissions only to resources on the local machine.

Choosing the right group type and scope is vital for building scalable and manageable access control in Active Directory. It involves balancing administration, control granularity, and replication load. Wrong scope choices can limit permission assignments or cause overly large access tokens due to extensive Universal group membership replicated via the GC.

• Computer Accounts: Represent devices like workstations and servers in a domain (managed in AD DS) or standalone machines (local SAM). Used for machine authentication (e.g., accessing network resources, applying machine-targeted Group Policies) and secure communication between machines.

1.2 Security Identifiers (SIDs)

A Security Identifier (SID) is a unique, fixed, variable-length value assigned by the Local Security Authority (LSA) or a Domain Controller's LSA to identify a security principal or logon session. It includes a revision level, a 48-bit identifier authority value, and several 32-bit subauthority values, ending with a Relative Identifier (RID) that's unique within the issuing authority's domain (either the machine SAM or the AD domain).

The uniqueness and permanence of SIDs ensure Windows access control integrity. Once assigned, a SID is never reused, even if the principal is deleted and recreated with the same name. This prevents accidental permission inheritance. The $SIDHistory$ attribute in AD DS lets migrated objects keep old SIDs, ensuring continued resource access during transitions, but it complicates access token evaluation because the token contains multiple user/group SIDs.

Well-Known SIDs are predefined constants representing generic users or groups across all Windows systems. Examples include:

• $S-1-1-0$ (Everyone)
• $S-1-5-18$ (Local System)
• $S-1-5-32-544$ (Administrators - local built-in group)

1.3 Objects

In Windows security, an object is any system entity whose access is controlled via a Security Descriptor. Objects represent system resources, such as:

• File system objects (Files, directories)
• Registry keys
• Printers
• Services
• Processes and Threads
• Kernel synchronization objects (Events, mutexes, semaphores, timers)
• Section objects (file mappings, shared memory)
• Network shares
• Active Directory objects (Users, groups, OUs, GPOs, sites, subnets)
• Windows Management Instrumentation (WMI) namespaces and objects
• Device objects

A securable object must have a Security Descriptor. This allows the system's Security Reference Monitor (SRM) to perform authorization checks when principals try to access it. The kernel's Object Manager manages kernel objects and calls the SRM for access validation.

1.4 Security Descriptors (SD)

A Security Descriptor (SD) is a data structure ($SECURITY_DESCRIPTOR$) linked to each securable object, holding its security settings. The SD defines who can do what to the object and which actions should be audited. SDs are stored with the object's metadata (e.g., in the NTFS Master File Table or $Secure stream for files) or managed by the component responsible for the object type (e.g., Registry, AD DS).

Key components of an SD:

• Owner SID: The SID of the principal owning the object. The owner usually has implicit rights to read and change the object's Discretionary Access Control List (DACL), giving them control over permissions. Ownership can typically be taken by administrators or those with the SeTakeOwnershipPrivilege.
• Primary Group SID: Mainly for POSIX compatibility; generally not used in standard Win32 access control.
• Discretionary Access Control List (DACL): Contains Access Control Entries (ACEs) specifying which principals (users/groups) are allowed or denied specific access rights. It's "discretionary" because the object's owner controls it. A NULL DACL means access checks are bypassed (often effectively granting access). An empty DACL denies all access.
• System Access Control List (SACL): Contains ACEs specifying which access attempts (by whom, for what rights, success/failure) should trigger audit records in the Security Event Log. Accessing or changing the SACL requires the $ACCESS_SYSTEM_SECURITY$ right, usually granted via the SeSecurityPrivilege.

The SECURITY_DESCRIPTOR also has Control Flags that define attributes like ACE inheritance rules for child objects and whether the SD is in self-relative (single memory block) or absolute (pointers) format. Separating DACL and SACL allows distinct management of access control (by owners/delegates) and audit policy (by security administrators).

1.5 Access Control Lists (ACLs) & Access Control Entries (ACEs)

An Access Control List (ACL) is an ordered list of Access Control Entries (ACEs). Both DACLs and SACLs are ACLs.

An Access Control Entry (ACE) is the basic unit within an ACL. Each ACE identifies a trustee (a SID for a user, group, computer, or session) and specifies an access mask defining the permissions being allowed, denied, or audited for that trustee.

Key ACE characteristics:

• ACE Types: Common types are:

  • ACCESS_ALLOWED_ACE_TYPE: Grants specified access rights.
  • ACCESS_DENIED_ACE_TYPE: Explicitly denies specified access rights.
  • SYSTEM_AUDIT_ACE_TYPE: Specifies access attempts to be audited.
  • Object-Specific ACEs (e.g., ACCESS_ALLOWED_OBJECT_ACE_TYPE): Used mainly in AD DS for permissions on specific object classes or attributes.
• Access Mask: A 32-bit value where bits represent access rights. Includes generic rights (e.g., GENERIC_READ), standard rights (e.g., DELETE, READ_CONTROL, WRITE_DAC, WRITE_OWNER), and object-specific rights (e.g., file rights like FILE_READ_DATA, FILE_WRITE_DATA).

• Inheritance Flags: Control how an ACE on a container (like a directory) propagates to child objects:

  • OBJECT_INHERIT_ACE (OI): Inherited by child non-container objects.
  • CONTAINER_INHERIT_ACE (CI): Inherited by child container objects.
  • INHERIT_ONLY_ACE (IO): Applies only to inheriting children, not the object itself.
  • NO_PROPAGATE_INHERIT_ACE (NP): Inherited only by immediate children; prevents further propagation.

For DACLs, ACE order is crucial. Windows enforces canonical order for predictable evaluation:

1. Explicit Deny ACEs
2. Explicit Allow ACEs
3. Inherited Deny ACEs
4. Inherited Allow ACEs

The SeAccessCheck function processes ACEs sequentially, relying on this order. Deny ACEs take precedence over Allow ACEs, and explicit ACEs take precedence over inherited ones. Non-canonical DACLs can cause unpredictable access decisions. Permission tools usually enforce canonical order automatically.

1.6 NTFS Permissions

NTFS permissions are the specific way Windows access control (SDs, ACLs, ACEs) applies to files and directories on NTFS volumes. They aren't a separate system, but specific access rights defined in the access masks of ACEs within the Security Descriptors of file system objects.

NTFS uses basic permissions (Read, Write, Read & Execute, Modify, Full Control) in UIs like Windows Explorer. These map to combinations of specific (Advanced) NTFS access rights:

• FILE_LIST_DIRECTORY / FILE_READ_DATA
• FILE_ADD_FILE / FILE_WRITE_DATA
• FILE_ADD_SUBDIRECTORY / FILE_APPEND_DATA
• FILE_TRAVERSE / FILE_EXECUTE
• DELETE
• READ_CONTROL
• WRITE_DAC
• WRITE_OWNER
• FILE_READ_ATTRIBUTES, FILE_WRITE_ATTRIBUTES
• FILE_READ_EA, FILE_WRITE_EA

Permission inheritance, controlled by flags (OI, CI, IO, NP) in parent ACEs and object SD control flags, allows permissions on containers to automatically apply to new child objects. This simplifies management but can create complex effective permissions. Evaluation follows canonical order: explicit overrides inherited, Deny overrides Allow at the same level.

1.7 Access Tokens

An Access Token (TOKEN) is a kernel object created by the Local Security Authority (LSA - lsass.exe) after successful user authentication. It holds the user's security context for the logon session and is attached to processes created in that session. Threads usually inherit the process token but can use their own impersonation tokens.

The Access Token contains info used by the SRM for access checks:

• User's SID: The primary identifier.
• Group SIDs: All groups the user belongs to (including transitive memberships and $SIDHistory$).
• Privileges: Assigned rights (e.g., SeShutdownPrivilege, SeBackupPrivilege).
• Default DACL: For objects created without a specific SD.
• Primary Group SID: For POSIX compatibility.
• Token Source: Who created the token.
• Authentication ID (AUTHID/Logon ID): Links token to a logon session.
• Token Type: Primary or Impersonation.
• Impersonation Level: If applicable (Anonymous, Identification, Impersonation, Delegation).
• Other attributes: Integrity level, session ID, flags.

The Access Token acts as the principal's credentials for authorization checks. The SRM compares the SIDs and privileges in the token against the object's SD. This avoids repeated authentication or lookups. Because the token contains the full context at logon, changes (like group membership) usually require logging off and back on to get a new token.

Two main token types:

• Primary Token: For a process's default security context. Generated at logon.
• Impersonation Token: For a thread, allowing temporary use of another security context (e.g., a client accessing a server). Limited by impersonation level.

1.8 Core Components Interaction

How these components work together for Windows authentication and authorization:

1. Authentication: User logs on (e.g., via winlogon.exe). Credentials go to LSA (lsass.exe). LSA uses an Authentication Package (e.g., Kerberos, MSV1_0) to verify against the authority (SAM or Active Directory).
2. Token Generation: If authentication succeeds, LSA gathers user SID, group SIDs, and privileges. LSA builds an Access Token (TOKEN) with this context.
3. Process Creation: The user's first process (e.g., explorer.exe) gets the new Primary Access Token. Subsequent processes inherit it.
4. Object Access Attempt: A thread tries an operation on a securable object (e.g., CreateFileW), specifying desired access rights.
5. Access Check: The kernel's Object Manager calls the Security Reference Monitor (SRM). SRM gets the thread's token and the object's Security Descriptor.
6. Authorization Decision: SRM runs the access check (SeAccessCheck), comparing token SIDs to DACL ACEs, checking privileges, considering requested rights, and following canonical order (Deny before Allow, explicit before inherited).
7. Result: SRM grants or denies access. Granted access allows the operation (e.g., returns a file handle). Denied access returns an error (e.g., $STATUS_ACCESS_DENIED$), usually seen as "Access Denied".

This shows separation: LSA handles authentication, SRM/Object Manager handle authorization using the token (identity) and SD (policy). The token links authentication to authorization.

2.1 Core Security Architecture & Components

2.1.1 Involved Components

Local Security Authority (LSA - lsass.exe): The core user-mode security process (%SystemRoot%\System32\lsass.exe). Manages authentication via Authentication Packages (*.dll like kerberos.dll, msv1_0.dll), creates Access Tokens, manages LSA Policy (including LSA Secrets), interacts with SAM and NetLogon. Hosts Security Support Providers (SSPs) via SSPI. On DCs, also hosts KDC and AD DS components. A prime target for credential theft.

Security Account Manager (SAM): Service managing the local principal database (SAM file). Implemented by SamSrv.dll within lsass.exe. Provides APIs for LSA to validate local credentials.

Active Directory Domain Services (AD DS): On Domain Controllers (DCs). Core logic (Directory System Agent - DSA, ntdsa.dll) runs in lsass.exe, manages the NTDS.dit database. Stores domain principals, attributes (SIDs, memberships, $SIDHistory$), AD object SDs ($nTSecurityDescriptor$), and Group Policy.

Kerberos Key Distribution Center (KDC): Service on all DCs (kdcsvc.dll in lsass.exe). Includes Authentication Service (AS - issues TGTs) and Ticket-Granting Service (TGS - issues Service Tickets). Authenticates principals using secrets from AD DS.

NetLogon Service: (netlogon.dll, usually in lsass.exe). Manages secure RPC channel to DCs, DC discovery, pass-through authentication, and secure password changes.

Security Reference Monitor (SRM): Kernel executive component (ntoskrnl.exe). Enforces access control and auditing. Includes functions like SeAccessCheck, privilege checks (SePrivilegeCheck), and manages kernel TOKEN objects. Compares token SIDs/privileges against object SDs.

Object Manager: Kernel executive component (ntoskrnl.exe). Manages kernel object lifecycle and namespace. Calls SRM for access validation before granting object handles (via ObOpenObject* functions). Associates SDs with objects.

2.1.2 Storage Mechanisms

• SAM Database (%SystemRoot%\System32\config\SAM): Registry hive storing local users, groups, hashed passwords, and potentially cached domain credentials. Access strictly via LSA/SAM APIs. Protected by system ACLs and related to the System Key (SYSKEY).
• Active Directory Database (NTDS.dit): Default: %SystemRoot%\NTDS on DCs. Extensible Storage Engine (ESE) database holding all domain objects and attributes (SIDs, groups, hashed passwords, Kerberos keys, nTSecurityDescriptor). Accessed via LDAP by DSA (in lsass.exe).

• Registry: Contains security configurations:

  • HKLM\SECURITY: Pointers to SAM, stores LSA Secrets (e.g., service account passwords). Highly protected.
  • HKLM\SYSTEM\CurrentControlSet\Control\Lsa: Settings for LSA, auth packages, security providers.
  • HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProfileList: Maps user SIDs to profile paths.
  • HKLM\SYSTEM\CurrentControlSet\Services: Service configuration, including security context (service account).

• Group Policy Objects (GPOs): Consists of two parts:

  • Group Policy Container (GPC): AD DS object with GPO metadata.
  • Group Policy Template (GPT): Files in SYSVOL share (\\\SYSVOL\\Policies\{GPO_GUID}). Contains actual policy settings (.pol files, .inf templates, scripts). GPOs define settings like password policies, user rights, audit policies, ACLs, applied by clients.

2.1.3 Primary Protocols

Kerberos (RFC 4120): Default authentication in AD DS. Uses UDP/TCP port 88 for client-KDC communication. Uses tickets (TGT, Service Tickets) for strong mutual authentication. Authorization data (SIDs) usually in the Privilege Attribute Certificate (PAC) inside Service Tickets.

NTLMv2: Challenge/response protocol for local logons, workgroups, or Kerberos fallback. Handled by msv1_0.dll. Less secure than Kerberos, vulnerable to relay attacks.

LDAP (Lightweight Directory Access Protocol): For querying/modifying Active Directory. Clients use LDAP (TCP/UDP 389) or LDAPS (TCP 636) to talk to DCs. Global Catalog uses ports 3268 (LDAP) and 3269 (LDAPS).

Secure RPC (Remote Procedure Call): For inter-process communication, often administrative/infrastructure tasks. Used by LSA RPC, SAMRPC, NetLogon RPC, DRS RPC (AD replication). Runs over named pipes (via SMB) or TCP, using Kerberos or NTLM (via SPNEGO) for security.

SMB/CIFS (Server Message Block / Common Internet File System): For remote file shares/named pipes (TCP 445). Requires authentication (Kerberos or NTLM via SPNEGO). Server-side enforces access control via SRM/file system using client's context against object's SD.

2.2 Logon Process & Access Token Creation

2.2.1 Logon Sequence (Focus: Kerberos Interactive Domain Logon)

1. Secure Attention Sequence (SAS): User presses Ctrl+Alt+Del; winlogon.exe shows secure logon desktop.
2. Credential Acquisition: User enters credentials via a Credential Provider.
3. LSA Invocation: winlogon.exe calls LsaLogonUser, passing credentials to lsass.exe.
4. Authentication Package Selection: LSA selects kerberos.dll for domain logon.
5. AS Exchange (TGT Request): Kerberos package sends AS-REQ (username, realm, timestamp encrypted with user key derived from password) to KDC (port 88).
6. KDC Validation & AS-REP: KDC AS verifies request using user's key from AD DS. If valid, generates TGT session key & TGT (encrypted with krbtgt key). Sends AS-REP (session key encrypted with user key, encrypted TGT) back.
7. Client TGT Processing: Client decrypts session key part using derived user key, stores TGT and TGT session key in LSA cache.
8. TGS Exchange (Service Ticket Request): Client sends TGS-REQ for local machine HOST SPN, includes TGT and authenticator (encrypted with TGT session key), to KDC TGS.
9. KDC Validation & TGS-REP: KDC TGS validates TGT and authenticator. Retrieves user auth data (SIDs) from AD DS, embeds in PAC (signed by KDC). Creates Service Ticket (encrypted with machine key, includes PAC). Generates service session key. Sends TGS-REP (encrypted service ticket, service session key encrypted with TGT session key) back.
10. Client Service Ticket Processing: Client decrypts service session key, stores Service Ticket (with PAC) and service session key in cache.
11. LSA Authorization Data Extraction: Kerberos package provides user identity and SIDs (from PAC) to LSA. LSA may validate PAC.
12. Local Policy Integration: LSA checks local policy for additional group memberships and User Rights (Privileges).
13. Access Token Construction: LSA builds the TOKEN kernel object with User SID, all Group SIDs, Privileges, etc.
14. Logon Session Creation: LSA creates Logon Session (with unique LUID) and links the Primary Access Token.
15. Shell Launch: LSA returns token handle to winlogon.exe, which launches user shell (explorer.exe via userinit.exe) with the token.

Network Logon (e.g., SMB) uses a similar TGS exchange for the target service's SPN (e.g., CIFS/ServerName). NTLMv2 uses a 3-message challenge-response sequence.

2.2.2 Key Processes, Services, Drivers

Processes: winlogon.exe, lsass.exe, services.exe, svchost.exe.

Services: LSA, KDC, NetLogon, SAM.

Drivers: ksecdd.sys, cng.sys, Auth Package DLLs (kerberos.dll, msv1_0.dll), netlogon.sys, network stack.

2.2.3 Access Token Structure (In Memory - TOKEN Object)

The kernel TOKEN object includes:

• AuthenticationId: Logon session LUID.
• TokenId: Unique token instance LUID.
• TokenType: Primary or Impersonation.
• ImpersonationLevel: Level allowed (Anonymous, Identification, Impersonation, Delegation).
• User: User SID_AND_ATTRIBUTES.
• Groups: Array of enabled Group SID_AND_ATTRIBUTES (domain, local, logon, $SIDHistory$). Attributes include deny-only status.
• Privileges: Array of assigned LUID_AND_ATTRIBUTES. Attributes indicate enabled status.
• DefaultOwnerIndex / DefaultDacl: Defaults for new objects.
• PrimaryGroup: For POSIX.
• TokenSource: Creator identifier.
• SessionId: Terminal Services/RDP session ID.
• Security Attributes: Integrity Level SID, etc.

Resolved group memberships in the token optimize access checks but can cause token bloat.

2.3 Access Check Algorithm (Security Reference Monitor - SRM)

2.3.1 SeAccessCheck Process Detail (Kernel Function)

The SeAccessCheck kernel function performs authorization. Key steps:

Inputs: Subject's TOKEN, desired ACCESS_MASK, object's SECURITY_DESCRIPTOR, optional OBJECT_TYPE_LIST, GENERIC_MAPPING.

1. Map Generic Rights: Translate generic rights (GENERIC_READ, etc.) to specific rights using GENERIC_MAPPING. Handle MAXIMUM_ALLOWED.
2. Check System Security Access: If ACCESS_SYSTEM_SECURITY requested, check for enabled SeSecurityPrivilege in token.
3. Check Write Owner Access: If WRITE_OWNER requested, check for enabled SeTakeOwnershipPrivilege. Check if token User SID matches SD Owner SID (implies READ_CONTROL, WRITE_DAC).
4. Check Write DAC Access: If WRITE_DAC requested, check if token User SID matches SD Owner SID (implicitly granted). Otherwise, requires explicit ACE.
5. DACL Processing (Canonical Order): Iterate through ACEs, maintaining GrantedAccessMask and RemainingDesiredMask.
   1. Explicit Deny: If ACE SID matches enabled token SID, remove denied rights from RemainingDesiredMask. If mask becomes zero, deny access.
   2. Explicit Allow: If ACE SID matches enabled token SID, add granted rights to GrantedAccessMask, remove from RemainingDesiredMask. If mask becomes zero, may grant access early.
   3. Inherited Deny/Allow: If needed, process inherited ACEs similarly.
6. Privilege Check Overrides: Check for privileges like SeBackupPrivilege (read), SeRestorePrivilege (write), SeTakeOwnershipPrivilege (take ownership), SeSecurityPrivilege (SACL access). Add corresponding rights to GrantedAccessMask if privilege enabled, potentially overriding DACL denial.
7. Final Comparison & Result: Compare final GrantedAccessMask to original DesiredAccessMask. If all requested bits granted, return TRUE. Otherwise, return FALSE with appropriate status code (e.g., STATUS_ACCESS_DENIED, STATUS_PRIVILEGE_NOT_HELD).

Canonical DACL order is essential for deterministic results (Deny before Allow, explicit before inherited). Privileges are controlled exceptions.

2.3.2 Key Kernel Components

ntoskrnl.exe: Hosts SRM (Se*) and Object Manager (Ob*).

Object-Specific Resource Monitors: Subsystems like File System Drivers (ntfs.sys), Configuration Manager (registry), win32k.sys (UI), ntdsa.dll (AD) provide SDs and interact with SRM.

2.4 Access Check Failure Scenarios & Error Codes Table

Understanding access failures involves mapping scenarios to error codes and potential event logs (if auditing is enabled).

ERROR_ACCESS_DENIED (5) requires deeper analysis, often using effective permissions tools or detailed auditing (Event ID 4656). ERROR_PRIVILEGE_NOT_HELD (1314) indicates missing User Rights.

2.5 NTFS Permissions Deep Dive

2.5.1 Generic vs. Specific Permission Mapping

NTFS permissions use specific file system rights. Basic Permissions in UIs map to combinations of Specific (Advanced) permissions.

Understanding this mapping helps apply least privilege. Fine-grained control may require setting specific permissions directly.

2.5.2 Inheritance Rules & Evaluation Precedence

NTFS inheritance allows parent ACEs to apply to children, controlled by ACE flags:

• OBJECT_INHERIT_ACE (OI): Inherited by files.
• CONTAINER_INHERIT_ACE (CI): Inherited by subdirectories.
• INHERIT_ONLY_ACE (IO): Applies only to children, not self.
• NO_PROPAGATE_INHERIT_ACE (NP): Inherited by immediate children only.

When an object is created, inheritable ACEs from the parent are copied to the child's SD, marked as inherited (INHERITED_ACE flag), and flags adjusted. Evaluation follows canonical order (Explicit Deny > Explicit Allow > Inherited Deny > Inherited Allow), with Deny overriding Allow.

2.5.3 Effective Permissions Calculation Process

Determining a user's effective permissions involves:

1. Gather Subject Context: User SID, all relevant Group SIDs, enabled Privileges from Access Token.
2. Retrieve Object Security: Get target file/folder's SD (Owner, DACL).
3. Identify Applicable ACEs: Find all ACEs in DACL matching token SIDs. Categorize as Explicit Deny, Explicit Allow, Inherited Deny, Inherited Allow.
4. Apply Precedence Rules: Simulate evaluation based on canonical order. Deny bits override Allow bits.
5. Factor in Ownership/Privileges: Add implicit rights from ownership (READ_CONTROL, WRITE_DAC) and overrides from enabled privileges (SeBackupPrivilege, etc.).
6. Result: The final computed access mask is the effective permission. Tools like the "Effective Access" tab automate this.

Complexity arises from multiple groups, inheritance, and deny ACEs.

2.5.4 On-Disk Storage (NTFS)

NTFS stores SDs efficiently:

• MFT Record: Contains attributes for each file/directory.
• $STANDARD_INFORMATION Attribute: Holds Owner SID, flags.
• $SECURITY_DESCRIPTOR Attribute: Holds security info.
• Resident Storage: Small SDs stored directly in the MFT record.
• Non-Resident Storage ($Secure::$SDS Stream): Large or shared SDs stored in the global $Secure::$SDS stream. The MFT attribute contains a reference (Security ID/hash+offset) to the data in $Secure::$SDS. This deduplication saves space and improves cache use.

Relevant for performance and forensics. Corruption here causes major access issues.

2.6 Modifying Security Descriptors (Permissions & Ownership)

2.6.1 Technical Sequence

Changing permissions (DACL), audit settings (SACL), or owner:

1. User Action & Tool: User uses tool (Explorer, icacls.exe, PowerShell) to request SD change.
2. Win32 API Call: Tool calls SetNamedSecurityInfoW or SetSecurityInfo, specifying object, what to change, and new SD data.
3. API Layer Processing (advapi32.dll): Validates parameters, determines local/remote.
4. RPC for Remote Objects: If remote, marshals parameters, calls RPC on target server (e.g., Server service) using caller's security context.
5. Server-Side (or Local Kernel) Processing:
   • Server receives request, impersonates client if remote.
   • Access Check: Invokes SRM (SeSetSecurityObject) to check if caller's token has required rights on current SD:
     • Modify DACL: Needs WRITE_DAC or Ownership.
     • Modify SACL: Needs ACCESS_SYSTEM_SECURITY (via SeSecurityPrivilege).
     • Change Owner: Needs WRITE_OWNER or SeTakeOwnershipPrivilege (or SeRestorePrivilege).
   • If check fails, return error (e.g., STATUS_ACCESS_DENIED).
   • Object Security Update: If check succeeds, SRM/Object Manager tells subsystem to update SD:
     • NTFS: Modifies $SECURITY_DESCRIPTOR attribute or $Secure::$SDS stream via NTFS transaction.
     • Registry: Configuration Manager updates key's SD in memory/hive file.
     • AD: DSA modifies nTSecurityDescriptor attribute in NTDS.dit.
   • Inheritance Propagation: If inheritable ACEs changed, kernel/subsystem may start background task to recursively update child SDs (with access checks).
6. Return Status: Success/failure code returned to application.

2.6.2 Required Permissions/Privileges Summary

• Modify DACL: WRITE_DAC or Ownership.
• Modify SACL: ACCESS_SYSTEM_SECURITY (via SeSecurityPrivilege).
• Take Ownership: SeTakeOwnershipPrivilege.
• Set Owner (arbitrary): WRITE_OWNER or admin privileges (SeRestorePrivilege).

2.6.3 Key Involved Components

• Client App (Explorer, icacls.exe, etc.)
• Win32 APIs (advapi32.dll, kernel32.dll)
• RPC Components
• Server Service (if remote)
• LSA (privilege checks)
• SRM (access check)
• Subsystem Drivers/Managers (ntfs.sys, Config Mgr, ntdsa.dll)

Modifying security is itself a privileged, controlled operation.

2.7 Summary of Involved Processes, Drivers, Services, Files, Memory Structures

Windows security relies on coordination between user-mode and kernel-mode components:

This highlights the central roles of lsass.exe and ntoskrnl.exe, the importance of storage like SAM, NTDS.dit, and NTFS metadata, and the reliance on protocols like Kerberos and RPC. System security depends on the integrity and interaction of these components.