Share This Article
Updated on August 29, 2025
A Security Identifier (SID) serves as the fundamental building block of Windows security architecture. Every security principal—whether a user, group, or computer—receives a unique and immutable SID at creation time. Unlike account names that administrators can modify, SIDs remain constant throughout a security principal’s lifetime.
This immutability makes SIDs the cornerstone of Windows access control. When you assign permissions to a file or folder, the system stores the SID in the resource’s Access Control List (ACL), not the human-readable account name. This design ensures permissions persist even when account names change.
Understanding SIDs becomes critical when managing enterprise environments, troubleshooting access issues, or implementing security policies across Active Directory domains.
Definition and Core Concepts
A Security Identifier (SID) is a variable-length alphanumeric string that uniquely identifies every security principal within a Windows environment. The operating system generates this identifier when an account is created and uses it as the primary reference for all security operations.
What Makes a SID Unique
SIDs function as the definitive identity marker in Windows security. When you view permissions in Windows Explorer, you might see friendly names like “Domain Users” or “John Smith.” Behind the scenes, Windows stores and references the corresponding SIDs: S-1-5-21-3623811015-3361044348-30300820-513 for Domain Users or S-1-5-21-3623811015-3361044348-30300820-1001 for a specific user account.
This separation between display names and internal identifiers provides several advantages. Account names can be changed without affecting permissions. Deleted and recreated accounts with identical names receive new SIDs, preventing accidental permission inheritance. The system can also resolve access rights faster by comparing SIDs rather than performing string lookups on account names.
Structure and Components
Every SID follows a standardized format with distinct components that provide hierarchical information about the security principal’s origin and identity.
SID Format Breakdown
Consider this example SID: S-1-5-21-3623811015-3361044348-30300820-1001
Revision Level (S): The literal “S” indicates this is a SID. All Windows SIDs begin with this identifier.
Identifier Authority (1): The number “1” represents the NT Authority, which is the standard authority for Windows systems.
Security Authority (5): This value specifies the issuing authority. “5” indicates the NT Authority that manages local and domain accounts.
Domain/Computer Identifier (21-3623811015-3361044348-30300820): This 48-bit section uniquely identifies the domain or local computer’s Security Account Manager (SAM) database. The “21” indicates this is a domain or local computer SID, while the following three numbers create a unique identifier for that specific domain or machine.
Relative Identifier (1001): The RID is the final component that identifies the specific security principal within its domain or local system. This number is unique within the scope of its issuing authority.
RID Allocation Patterns
Windows follows specific patterns when assigning RIDs. Built-in accounts receive well-known RIDs: 500 for Administrator, 501 for Guest, 512 for Domain Admins. User accounts created in Active Directory typically start at RID 1000, while local computer accounts begin at RID 1001. Group accounts receive RIDs in different ranges depending on their scope and type.
How SIDs Work in Windows Security
SIDs operate at the core of every Windows security decision. When a user attempts to access a resource, the system performs a series of SID-based operations to determine access rights.
Permission Assignment Process
When an administrator assigns permissions to a user or group, Windows immediately translates the account name into its corresponding SID. The system then stores this SID in the resource’s Access Control List (ACL). This process ensures that permissions remain tied to the specific security principal regardless of name changes.
For example, if you grant “Read” permission to “JohnSmith” on a folder, Windows looks up JohnSmith’s SID and adds an Access Control Entry (ACE) containing that SID and the Read permission to the folder’s ACL. Even if JohnSmith’s account is later renamed to “[email protected],” the permissions remain intact because the SID hasn’t changed.
Authentication and Authorization Flow
The Windows authentication process revolves around SID resolution and token creation. When a user logs on, the Local Security Authority (LSA) validates their credentials and determines their SID. The system then constructs an access token containing the user’s SID plus the SIDs of all groups they belong to.
This access token becomes the user’s security context for their entire session. When they attempt to access any resource, Windows compares the SIDs in their access token against the SIDs in the resource’s ACL. If a match is found with appropriate permissions, access is granted.
Account Name Independence
The separation between account names and SIDs provides significant administrative flexibility. Administrators can rename accounts, restructure organizational units, or modify display names without affecting underlying permissions. This design also prevents security vulnerabilities that could arise if permissions were tied to easily-changed display names.
Key Features and Properties
SIDs possess several characteristics that make them effective for Windows security management.
Immutability and Permanence
A SID remains constant throughout a security principal’s lifetime. Windows never changes a SID after creation, even during domain migrations or account modifications. This permanence ensures that permissions, audit logs, and security policies maintain their integrity over time.
If an account is deleted and a new account is created with the same name, the new account receives a completely different SID. This prevents the new account from inheriting the old account’s permissions or security context.
Well-Known SIDs
Windows includes a set of predefined SIDs for common, built-in security principals. These Well-Known SIDs remain consistent across all Windows installations, enabling standardized security configurations.
Key Well-Known SIDs include:
- S-1-1-0: Everyone group
- S-1-5-32-544: Built-in Administrators group
- S-1-5-18: Local System account
- S-1-5-7: Anonymous Logon
- S-1-5-11: Authenticated Users
Domain-specific Well-Known SIDs follow predictable patterns. The domain Administrator account always has RID 500, while Domain Admins always has RID 512. This consistency simplifies cross-domain administration and security policy deployment.
SID History Attribute
Active Directory includes a SID History attribute (sIDHistory) that supports account migration scenarios. When migrating users from one domain to another, their original SIDs can be copied to the sIDHistory attribute of their new accounts. This allows users to retain access to resources in their original domain without requiring permission reassignment.
SID History proves valuable during domain consolidations, company acquisitions, or forest restructuring projects. Users can access resources in both their old and new domains during transition periods, reducing disruption and administrative overhead.
Troubleshooting and Security Considerations
SID-related issues can create significant security and administrative challenges in Windows environments.
Orphaned SIDs
When a security principal is deleted, its SID becomes “orphaned”—no longer associated with an active account. These orphaned SIDs can remain in Access Control Lists, appearing as unknown accounts when viewing permissions. While orphaned SIDs don’t grant access to anyone, they can clutter ACLs and make permission management more difficult.
Administrators should regularly audit and clean up orphaned SIDs to maintain clean permission structures. Tools like Microsoft’s Security Compliance Manager or third-party utilities can identify and remove these orphaned entries.
SID Filtering Security Feature
SID Filtering provides protection against certain trust-based attacks in multi-domain environments. When configured on a trust relationship, SID Filtering prevents a trusted domain from authenticating users with SIDs from outside its own domain authority.
This security measure mitigates “SID History injection” attacks, where malicious actors might attempt to add privileged SIDs to a user’s SID History attribute. By filtering out foreign SIDs, the trusting domain ensures that users can only authenticate with SIDs from expected sources.
SID Filtering is automatically enabled on external trusts but disabled on trusts within the same forest. Administrators must carefully consider the implications when modifying these default settings, as improper configuration can break legitimate cross-domain access scenarios.
Key Terms Reference
- Security Identifier (SID): The unique alphanumeric string that identifies a security principal in Windows environments.
- Relative Identifier (RID): The final numeric component of a SID that uniquely identifies a security principal within its domain or local system.
- Security Principal: Any entity that can be authenticated by Windows, including users, groups, computers, and services.
- Access Control List (ACL): A data structure containing Access Control Entries that define permissions for a resource, referenced by SIDs.
- Well-Known SID: A predefined SID for built-in Windows security principals that remains consistent across installations.
- SID History: An Active Directory attribute that stores previous SIDs from migrated accounts, enabling cross-domain resource access.
- SID Filtering: A security feature that restricts which SIDs can be used for authentication across domain trust relationships.
- Access Control Entry (ACE): An individual permission entry within an ACL that specifies what a particular SID can do with a resource.
- Security Account Manager (SAM): The local database that stores account information and SIDs for standalone computers and domain controllers.
