Hubbry Logo
Security IdentifierSecurity IdentifierMain
Open search
Security Identifier
Community hub
Security Identifier
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Contribute something
Security Identifier
Security Identifier
Security Identifier
View on Wikipedia
from Wikipedia

Security Identifier (SID) is a unique, immutable identifier of a user account, user group, or other security principal in the Windows NT family of operating systems. A security principal has a single SID for life (in a given Windows domain), and all properties of the principal, including its name, are associated with the SID. This design allows a principal to be renamed (for example, from "Jane Smith" to "Jane Jones") without affecting the security attributes of objects that refer to the principal.

Overview

[edit]

Windows grants privileges and access to resources based on access control lists (ACLs). Each entry on the list defines one SID and a set of permissions for that SID. When a user logs into a PC, Windows generates an access token that contains the user SID, the group SIDs to which the user account belongs, and the user privilege level. When a user requests access to a resource, its ACL is checked against the user's access token to permit or deny particular action on a particular object.

Structure

[edit]

The human-readable representation of a SID is a string that starts with "S-" and consists of several dash-separated numbers. For example, "S-1-5-21-3623811015-3361044348-30300820-1013" could be a user account's SID. The following table explains the components of this example SID.

Anatomy of a SID
Component Example Explanation
Header S Identifies the string as a SID
Revision level 1 The version number of the SID specification. As of 2025, "1" is the only valid number.
Authority 5 See below
Subauthorities 21-3623811015-3361044348-30300820 In this example, "21" indicates a "domain" subauthority. The following 96-bit ID is a domain identifier.
Relative ID (RID) 1013 Uniquely identifies the principal within its subauthority group. In the context of domain accounts (which is the focus of our example), RIDs greater than 1000 indicate an admin-defined principal (as opposed to a predefined, built-in, or special-purpose generic principal).

Originally, SIDs were supposed to allow arbitrarily deep nesting, with each level allowed to create sub-authorities underneath itself. However, that goal was abandoned early in Windows NT development, when it was decided that it would be too unmanageable in practice; by then, however, the SID format had already been finalized and was in heavy use in the Windows code.[1]

Identifier authority

[edit]

Identifier authorities are formally defined as six-byte (48-bit) quantities. The identifier authority is expressed in decimal if its value is less than 232, otherwise in hexadecimal.[2][3] However, while this is the behavior formally defined by Microsoft, and implemented by the relevant Windows APIs (e.g. RtlConvertSidToUnicodeString),[3] hexadecimal identifier authorities appear to have never been used in practice. All known values fit in the least significant byte, and the other 5 bytes are always zero. Identifier authorities are stored in big-endian format, even on little-endian CPU architectures.

Valid identifier authority values[4][5]
Authority Formal name First introduced Notes
0 Null Authority e.g., "Nobody" (S-1-0-0)
1 World Authority e.g., well-known groups such as "Everyone". (S-1-1-0)
2 Local Authority e.g., flag SIDs like "CONSOLE LOGON"
3 Creator Authority
4 Non-unique Authority
5 NT Authority Managed by the NT security subsystem. There are many sub-authorities such as "BUILTIN" and every Active Directory Domain
6[6][7] Site Server Authority Windows XP
7[6][7] Internet Site Authority Windows XP
8[6][7][8] Exchange Authority Windows XP
9[7][9][10] Resource Manager Authority Windows Server 2003
10[6] Passport Authority
11[11] Microsoft Account Authority Windows 8
12 Azure Active Directory Windows 10
15[12][13][14] App Package Authority (Capability SIDs) Windows Server 2012 All capability SIDs begin at S-1-15-3. By design, a capability SID does not resolve to a friendly name. The most commonly used capability SID is S-1-15-3-1024-1065365936-1281604716-3511738428-1654721687-432734479-3232135806-4053264122-3456934681
16[15] Mandatory Label Authority Windows Vista Used as part of Mandatory Integrity Control
17[16] Scoped Policy ID Authority
18[16] Authentication Authority
19[17] Process Trust Authority

Subauthority

[edit]
S-1-5 subauthority values[12][18][5]
Decimal Name First introduced Format and purpose
8[5] Proxy Windows Server 2003 S-1-5-8 is the SID of the "SECURITY_NT_AUTHORITY" proxy.[5]
18 LocalSystem Windows NT 3.1 S-1-5-18 is the SID of the LocalSystem account on all Windows machines.
19 LocalService S-1-5-19 is the SID of the LocalService account on all Windows machines.
20 NetworkService S-1-5-20 is the SID of the NetworkService account on all Windows machines.
21 Domain S-1-5-21-<Domain ID>-<RID>, where <Domain ID> is in the form of <32-bit>-<32-bit>-<32-bit>. See below for details.
32 Users Windows 7 S-1-5-32-<RID>. Example: S-1-5-32-544 (the built-in Administrators group).

The resulting SID pertains a predefined, special-purpose user group, and is valid on all Windows machines. RID could only be one the predefined ones.

64 Authentication S-1-5-64-<RID>, where <RID> is one of the following:
  • 10: NTLM
  • 14: SChannel
  • 21: Digest
80 NT Service Windows Vista S-1-5-80-<RID>, where <RID> is a service identifier. "0" (zero) is reserved for the ALL SERVICES group (hence, S-1-5-80-0's fully qualified name is NT SERVICE\ALL SERVICES).
82 IIS AppPool Windows 7
83-0 Virtual Machines Windows 7 S-1-5-83-0 is the SID of the "NT VIRTUAL MACHINE\Virtual Machines" group, which maintains a list of all Hyper-V virtual machines.
83-1 Virtual machine Windows 7 S-1-5-83-1-<ID1>-<ID2>-<ID3>-<ID4>.

The resulting SID pertains a Hyper-V virtual machine.

90[5] Windows Manager Windows 7 S-1-5-90-0 is the SID of the "Windows Manager Group", a built-in group that maintains all virtual accounts of the Desktop Windows Manager (DWM).

S-1-5-90-0-<RID>, where <RID> is a number, is the SID format of a DWM virtual account. For example, S-1-5-90-0-1 pertains DWM-1.

96 User-Mode Driver Framework Windows 7 S-1-5-96-0-<RID>, where <RID> is a number, is the SID format of a User-Mode Driver Framework (UMDF) virtual account. For example, S-1-5-96-0-1 pertains UMDF-1. The User-mode Font Driver Host (fontdrvhost.exe) runs in the context of a UMDF account.

Domain SIDs

[edit]

SIDs that start with "S-1-5-21" are noticeably longer than most other SIDs (with the notable exception of service SIDs). Their general format is: S-1-5-21-<Domain ID>-<RID>, where <Domain ID> is in the form of <32-bit>-<32-bit>-<32-bit>.

The Domain ID uniquely identifies a Windows domain. The RID specifies a principal (user account, group account, or computer account) within that domain.

If the RID portion is greater than 1000, the resulting SID pertains an admin-defined user account, user group, or computer account, e.g., S-1-5-21-3361044348-303008203623811015-1001. The name of this account could be anything, e.g., Domain.local\JaneDoe.

If the RID portion is smaller than 1000, the resulting SID pertains a predefined (built-in) user account or user group. For example, RID 500 identifies the controversial "Administrator" user account while RID 512 pertains the "Domain Admins" group.

Machine SIDs

[edit]

Machine SIDs are variety of domain SIDs (S-1-5-21) with a 96-bit domain ID (a machine is considered its own local domain) but no RID. Their general format is: S-1-5-21-<Machine ID>, where <Machine ID> is in the form of <32-bit>-<32-bit>-<32-bit>.

The machine SID is stored in the SECURITY hive of the Windows Registry, more specifically at HKEY_LOCAL_MACHINE\SECURITY\SAM\Domains\Account. This key has two values: F and V. The latter is a raw binary value that has the machine SID embedded within it at the end of its data (last 96 bits).[19] (Some sources[example needed] state that it is stored in the SAM hive instead.) A backup is located at SECURITY\Policy\PolAcDmS\@.[citation needed]

NewSID ensures that this SID is in a standard NT 4.0 format (3 32-bit subauthorities preceded by three 32-bit authority fields). Next, NewSID generates a new random SID for the computer. NewSID's generation takes great pains to create a truly random 96-bit value, which replaces the 96-bits of the 3 subauthority values that make up a computer SID.

— NewSID readme[20]

The machine SID is stored in a raw-bytes form in the registry. To convert it into the more common numeric form, one interprets it as three, little endian, 32-bit integers, converts them to decimal, and add hyphens between them.

Example of decoding machine SID
Raw form (hexadecimal representation) 2E,43,AC,40,C0,85,38,5D,07,E5,3B,2B
Split the bytes into 3 groups of four octets 2E,43,AC,40 - C0,85,38,5D - 07,E5,3B,2B
Reverse the order of bytes in each group 40,AC,43,2E - 5D,38,85,C0 - 2B,3B,E5,07
Convert each group into decimal 1085031214 - 1563985344 - 725345543
Add the machine SID prefix S-1-5-21-1085031214-1563985344-725345543

Service SIDs

[edit]

Service SIDs are a feature of service isolation, introduced in Windows Vista and Windows Server 2008.[21] Any service with the "unrestricted" SID-type property will have a service-specific SID added to the access token of the service host process, allowing permissions for a single service to be managed without necessitating the creation of service accounts.

Each service SID is a local, machine-level SID that has the general form of S-1-5-80-<Service ID>. To generate <Service ID>, Windows copies the service name (in UTF-16 encoding), converts all characters to uppercase, and calculates the SHA-1 digest of said uppercase name. This digest becomes the <Service ID>. The sc.exe command can be used to generate this special SID value; for example, given the "dnscache" service: 

C:\>sc query

NAME: dnscache
SERVICE SID: S-1-5-80-859482183-879914841-863379149-1145462774-2388618682

Therefore, the "dnscache" service can be referred to as either NT SERVICE\dnscache or S-1-5-80-859482183-879914841-863379149-1145462774-2388618682. Since a Service SID is determined exclusively by the service name, the value of the SID for a given service is always the same across all machines wherever the service runs.

Duplicated SIDs

[edit]

A common method of mass-producing Windows PCs is to install Windows on a template machine, and duplicate its disk sector by sector to other identical machines. As a result, these mass-produced machines are identical in every respect, including their SIDs.[20]

Microsoft engineer Mark Russinovich is the creator of a utility called NewSID, the purpose of which is to solve "The SID Duplication Problem."[20] Microsoft has retired the utility on November 2, 2009, because, Mark and the Windows security team have concluded that duplicate SIDs do not pose any problem whatsoever.[22]

See also

[edit]

Footnotes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Security Identifier

View on Grokipedia
from Grokipedia
A Security Identifier (SID) is a unique, immutable alphanumeric string used in Windows operating systems to identify security principals, such as user accounts, groups, computer accounts, and processes, enabling the system to enforce and . SIDs are issued by a security authority, such as a local Security Accounts Manager (SAM) database or a in , and are stored in binary format within security tokens or directories like the Windows registry. Unlike user names, which can change, SIDs remain constant throughout the lifetime of a security principal, ensuring reliable identification even if accounts are renamed or migrated across domains.

Historical Development

Security Identifiers were introduced in , released in 1993, as a core component of the operating system's advanced model designed to support secure multi-user and networked environments. The structure of a SID consists of a revision level, an identifier authority value, and a variable number of subauthority values, typically represented in string format as S-R-I-S1-S2-...-Sn. For domain-based SIDs, the domain portion uniquely identifies the security authority, while the relative identifier (RID)—ranging from 0 to 2,147,483,647 and managed by a domain's RID master—distinguishes the principal within that domain and is never reused to prevent conflicts. Local SIDs, used on standalone systems, follow a similar format but reference the local machine's authority, such as S-1-5-21 for machine-specific accounts. In the Windows security model, play a central role in by being embedded in access tokens generated during user logon, which the system references to grant or deny permissions to resources like files, registry keys, and services based on lists (ACLs). Well-known SIDs, which are predefined and consistent across all Windows installations, represent common entities without relying on specific domains; examples include S-1-1-0 for the "Everyone" group, S-1-5-32-544 for the built-in Administrators group, and S-1-5-18 for the Local System account. This design supports scalability in enterprise environments, where SIDs facilitate secure delegation and auditing while minimizing the risk of identifier collisions in distributed systems.

Introduction

Definition and Purpose

A security identifier (SID) is a unique, variable-length value used in Windows NT-based operating systems to identify principals, such as users, groups, and services. Issued by an authority like a local authority or , a SID serves as the definitive mechanism to distinguish these entities within the model, ensuring that each principal has a persistent and non-reusable identifier. The primary purposes of include enabling by specifying permissions in resource settings, facilitating processes during user logon, and providing unique identification that remains consistent across domains and machines. Unlike user account names, which can change over time or be duplicated in different contexts, SIDs are immutable and scoped to their issuing authority, prioritizing enforcement over human-readable display. This distinction allows SIDs to function reliably in security descriptors, where they trustees without reliance on transient naming conventions. In binary format, a SID consists of a revision byte, a subauthority count byte, an identifier authority (typically 6 bytes), and a variable array of subauthority values (each 4 bytes), forming a compact structure for efficient storage and comparison. Within the broader Windows architecture, SIDs integrate with access tokens—which contain the SID of the authenticated user and associated groups—and access control lists (ACLs), where they define allowable operations on securable objects, thereby enforcing the overall framework.

Historical Development

Security Identifiers (SIDs) were introduced with as a core component of the new NT security model, designed to provide unique and immutable identifiers for security principals such as users, groups, and accounts. The NT model's adoption of SIDs enabled more scalable in multi-user environments, emphasizing immutability to prevent reuse of deleted account identifiers and reduce security risks. The SID structure was formalized in the to include a revision number, identifier authority, and up to 15 subauthority values, ensuring consistent representation across systems. (2000) further evolved SIDs through integration with , introducing domain-specific SIDs for enterprise-wide management and the SID History attribute to preserve previous SIDs during domain migrations, facilitating seamless transitions without re-permissioning resources. This enhancement addressed the challenges of upgrading from NT domains to , allowing migrated accounts to retain access to legacy resources via the SID History list. Later versions built on this foundation to support modern security needs. Windows Vista and Server 2008 (2007) introduced service SIDs to enable service isolation, assigning unique identifiers to services for granular control over network access and resource restrictions without relying on shared user accounts. In Windows 10 and later (2015 onward), capability SIDs were added to represent app-specific permissions, such as access to documents or location services, providing unforgeable tokens that enhance security in the Universal Windows Platform ecosystem. The overarching design rationale for has been to create domain-independent identifiers that avoid dependence on changeable elements like usernames or relative IDs, supporting large-scale enterprise while maintaining through features like SID History. This evolution reflects Microsoft's ongoing efforts to balance scalability, , and migration ease in Windows operating systems.

SID Composition

Core Components

The Security Identifier (SID) is a variable-length structure in the Windows operating system, designed to uniquely identify security principals such as users, groups, or services. Its format ensures hierarchical uniqueness across different authorities and scopes, with a total length determined by the number of subauthorities included. The SID begins with a 1-byte revision number field, which specifies the SID structure version and is always set to 1 (0x01) for all current Windows implementations. Immediately following is a 1-byte subauthority count field, an unsigned integer value ranging from 0 to 15 (though 0 is a degenerate case rarely used in practice) that indicates the number of subauthority values present in the structure. These initial two fields form a fixed 2-byte header. The next component is the 6-byte identifier authority field, a fixed-size array of bytes that distinguishes the issuing authority responsible for generating the SID; for example, the NT Authority is represented by the byte sequence {0x00, 0x00, 0x00, 0x00, 0x00, 0x05}. This field is typically zero-padded in the first five bytes, with the authority value in the sixth byte for standard Windows SIDs. Following the identifier authority is the variable-length subauthority , consisting of up to 15 entries, each a 4-byte (32-bit) unsigned known as a relative identifier (RID). These values form a hierarchical path that narrows down the identification of , with earlier entries often representing domain or authority-specific components and later ones providing finer granularity. The 's length is exactly the value specified in the subauthority count field, making the total SID size 8 bytes plus 4 bytes per subauthority (up to a maximum of 68 bytes). Within the subauthority array, the Relative Identifier (RID) is specifically the final 4-byte value, which uniquely identifies the security principal relative to the preceding subauthorities and the issuing authority's scope, such as a user account within a domain. For clarity, the binary layout of a SID can be summarized in the following table:
FieldSize (bytes)Description
Revision1Version number (always 1 for current SIDs).
Subauthority Count1Number of subauthority values (0-15).
Identifier Authority6Issuing authority identifier (e.g., {0,0,0,0,0,5} for NT Authority).
Subauthority Array4 × countArray of 32-bit RIDs forming the hierarchical path; last is the RID.
This structure is reflected in the human-readable string representation of a SID, formatted as S-R-I-S1-S2-...-Sn (where S is the revision, R is the subauthority count, I is the identifier authority, and S1 to Sn are the subauthority values including the RID), such as S-1-5-21-1234567890-1234567890-1234567890-1001 for a domain user account.

Identifier Authority

The identifier field in a Security Identifier (SID) serves as the top-level component that specifies the issuing entity or domain , thereby ensuring the global uniqueness of the SID across different systems and contexts. This 48-bit value, typically represented as a small in the portion of the SID format (e.g., S-1-*), distinguishes between various categories of principals, such as built-in accounts, universal groups, or domain-specific entities, preventing identifier collisions in Windows operations. Common predefined values for the identifier authority include 1, which corresponds to the World Authority and is used for universal like S-1-1-0 representing the "Everyone" group applicable to all users; 5, known as the NT , which prefixes SIDs for Windows-specific built-in accounts and groups, such as S-1-5-32 for the Builtin domain; and 6, the Non-Unique Authority, employed for relative or domain-relative identifiers where uniqueness is maintained through prefixing with a domain SID rather than global allocation. These values interact with subsequent subauthority fields to form complete SIDs; for instance, under authority 5, subauthorities like 32 denote well-known built-in domains, while 21 indicates machine or domain-specific RIDs that are non-unique outside their issuing domain. The allocation of identifier authority values has been centrally managed by since the inception of the Windows NT security model to promote and avoid overlaps between different SID issuers. Reserved ranges, such as those below 32 for well-known authorities, are predefined in Microsoft's protocol specifications to guarantee consistent interpretation across operating systems, with no provision for third-party assignment to maintain integrity.

Subauthority Values

The subauthorities in a form a of up to 15 32-bit unsigned integers (DWORDs), with the exact number specified by the SubAuthorityCount field in the SID structure. These values follow the and provide the hierarchical specificity needed to distinguish individual principals within that authority's . The first subauthority typically indicates the domain or group type, such as 21 for domain-issued SIDs or 32 for built-in local groups, while subsequent values build the , culminating in the last subauthority, known as the Relative Identifier (RID). In domain SIDs, the subauthorities encode a multi-level hierarchy where the initial values (after the first) represent a unique domain identifier—often a 96-bit random number split across three 32-bit subauthorities—followed by the RID for the specific object. This structure ensures global uniqueness by nesting the principal's identifier within its issuing domain's context, preventing collisions across different authorities. Relative Identifiers (RIDs) are allocated from predefined ranges to maintain consistency and avoid overlap. Well-known RIDs, reserved for predefined accounts and groups, occupy the range 0 through 999; for example, RID 500 denotes the built-in Administrator account, while 544 identifies the local Administrators group. User-assigned RIDs, used for custom accounts and groups in domains, begin at 1000 and are dynamically allocated in blocks by the domain's RID master to domain controllers, ensuring sequential and unique assignment within the domain. Special cases include null RIDs, which have a value of 0 and are used for generic or placeholder groups that do not represent specific principals, such as the Null SID (S-1-0-0) indicating no security context or the World SID (S-1-1-0) encompassing all users. These null values simplify for broad categories without requiring individual identification. The number of subauthorities directly influences the SID's overall and complexity, as each additional 32-bit value extends the binary structure and the corresponding string representation (e.g., S-R-I-Y1-Y2-...-Yn). SIDs typically have 1 to 15 subauthorities in practice, with algorithms extracting the domain portion from all but the final value to reconstruct the efficiently.

SID Categories

Well-Known SIDs

Well-known security identifiers () are predefined values that represent generic users, groups, and logon types, applicable universally across all Windows installations. These feature fixed structures, with many falling under the NT Authority (prefix S-1-5), ensuring their values remain constant and independent of local machine or domain configurations. This design promotes consistency in security modeling, allowing the operating system to reference standard principals without variability introduced by environment-specific factors. These are hardcoded directly into the Windows kernel and subsystems, serving as foundational elements for bootstrap security. They enable the assignment of permissions to essential system resources, such as core files, registry keys, and services, during system initialization and runtime operations. By using immutable identifiers, Windows avoids dependencies on dynamically generated SIDs, reducing risks in access control and simplifying policy enforcement across diverse deployments. The relative identifier (RID), encoded as the final subauthority value in the SID structure, uniquely distinguishes each well-known principal within its authority. Below is a table of major well-known , focusing on those with fixed RIDs under key authorities like NT (5) and (1), along with their purposes. These examples illustrate common system accounts, logon sessions, and built-in groups used in .
SIDRIDPurpose
S-1-1-00Everyone (World): Represents a group encompassing all users, including anonymous and authenticated, for broad permission grants.
S-1-5-11Dialup: Identifies users who log on via dial-up connections, used in legacy network access controls.
S-1-5-22Network: Denotes users authenticating over a network, excluding interactive or local logons, for remote access policies.
S-1-5-33Batch: Covers logons through batch queue facilities, such as scheduled tasks, to restrict automated processes.
S-1-5-44Interactive Users (logged-on users): Represents users who log on interactively at the console, fixed across all Windows systems; used in SDDL as "IU" or directly in tools like subinacl to avoid name resolution issues. Distinguishes local interactive sessions.
S-1-5-66Service: Groups all principals logging on as services, enabling secure execution of background processes.
S-1-5-77Anonymous Logon: Represents unauthenticated or null sessions, often denied access to sensitive resources by default.
S-1-5-1111Authenticated Users: Includes all users who have successfully authenticated, excluding guests and anonymous, for post-login permissions.
S-1-5-1818: A high-privilege account used by the operating for core functions, equivalent to full administrative control.
S-1-5-1919Local Service: A low-privilege service account for local, non-networked operations, limiting exposure in case of .
S-1-5-2020: Similar to Local Service but for network-accessible operations, using the machine account for authentication.
S-1-5-32-544544Administrators (Built-in): The local Administrators group, granting full control to members for management tasks.
These SIDs' fixed nature, as defined by the relative identifier in the subauthority, ensures they can be programmatically generated and compared using Windows APIs like CreateWellKnownSid, facilitating reliable security implementations.

Domain and Machine SIDs

Domain SIDs are security identifiers issued by Active Directory domain controllers to uniquely identify users, groups, and other security principals within a specific domain. They follow the format S-1-5-21-domain_identifier-RID, where the domain identifier consists of a random 96-bit value (represented as three 32-bit subauthorities, such as 21-1004336348-1177238915-682003330) that is unique to each domain, and the relative identifier (RID) is a unique value assigned to the principal within that domain. This structure ensures that domain SIDs are authoritative across the enterprise, facilitating consistent identification in networked environments. Machine serve as the local equivalent for security principals on individual computers, whether standalone or joined to a domain. They share a similar format, S-1-5-21-machine_identifier-RID, but use a machine-specific random prefix generated during operating system installation to distinguish local accounts and groups. RIDs for these SIDs are allocated sequentially within the local subauthority space, typically starting from 1000 for user accounts. The generation process for domain SIDs begins with a creating a unique random domain identifier upon domain establishment, after which RIDs are assigned by the domain's RID master role holder as new principals are created. In contrast, machine SIDs are produced by the Local Security Authority (LSA) subsystem at setup time, using a randomly generated 96-bit prefix to ensure per-machine uniqueness without reliance on network . A key difference lies in their scope: domain SIDs enable cross-machine trust by allowing security principals to be recognized and authorized seamlessly across all domain-joined systems, supporting centralized management in networked setups. Machine SIDs, however, isolate to the local computer, preventing local principals from being directly accessible or trusted on other machines and thus maintaining separation in standalone configurations.

Service and Capability SIDs

Service SIDs, also known as per-service , are security identifiers designed to provide isolation for Windows services by assigning each service a unique identity that enables least-privilege access to system resources. These SIDs follow the format S-1-5-80 followed by five 32-bit values derived from a cryptographic hash of the service's binary name, ensuring uniqueness without relying on shared accounts like . Introduced in and , this mechanism allows services to authenticate and access resources directly under their own SID, reducing the attack surface by avoiding the need for elevated or shared credentials. The prefix S-1-5-80 identifies the NT Service authority, with S-1-5-80-0 specifically representing the "All Services" group that encompasses all configured service processes on the system. For example, the Database Engine service uses a per-service SID in the form NT Service\MSSQL$<instance_name>, which translates to an S-1-5-80-based identifier unique to the instance, granting it only the permissions necessary for database operations such as file access and network communication. Similarly, (IIS) application pools employ virtual accounts with SIDs generated from the pool name, prefixed by NT Service, to isolate web applications and prevent one pool from accessing another's resources. This approach facilitates service isolation, where access control lists (ACLs) on files, registry keys, or other objects can explicitly reference the service SID to enforce granular permissions without exposing broader system accounts. Capability SIDs extend this isolation model to modern applications, particularly those in app containers, by representing specific permissions or "capabilities" such as access to the , pictures , or removable storage. These SIDs use the prefix S-1-15-3, where 15 denotes the App Package Authority and 3 indicates a capability subauthority, followed by hashed values (often SHA-256 derivatives) tied to the capability declaration in the app's manifest. Introduced in and , capability SIDs enable apps to request and receive only the minimal set of rights needed, avoiding the use of overly permissive well-known SIDs and enhancing in sandboxed environments like (UWP) apps packaged as AppX files. For instance, an app requiring network access might include the capability SID for "internetClient," formatted as S-1-15-3 with subauthorities representing the well-known constant SECURITY_CAPABILITY_INTERNET_CLIENT (0x00000001), which is then added to the app's upon declaration and verification during installation. In practice, capability SIDs are derived from the app package's identity and manifest, ensuring that permissions are scoped to the specific AppX package and cannot be shared across unrelated apps, thereby mitigating risks from malicious or compromised software. These SIDs do not resolve to human-readable names by design, maintaining their immutability and preventing enumeration attacks, while functions like DeriveCapabilitySidsFromName allow developers to generate and validate them programmatically for custom capabilities. By integrating with app container security boundaries, capability SIDs support a declarative model where apps declare needs in their package, and the enforces access at runtime, promoting secure-by-default development for , network, and device interactions.

Applications in Security

Access Control Lists

Access control lists (ACLs) are integral to the Windows security model, serving as mechanisms to define permissions on securable objects such as files, registry keys, and processes. An ACL consists of a sequence of access control entries (), where each specifies security permissions for a particular identified by a security identifier (SID). There are two primary types of ACLs: the discretionary ACL (DACL), which governs access rights by allowing or denying operations, and the system ACL (SACL), which controls auditing of access attempts. In a DACL, each ACE references a SID to designate the trustee—such as a user account, group, or logon session—and associates it with an access that enumerates specific , including read, write, execute, or full control. For instance, an access-allowed ACE grants permissions to the trustee's SID, while an access-denied ACE explicitly revokes them, with the system evaluating ACEs in order until access is fully resolved. Similarly, in an SACL, ACEs use SIDs to specify which trustees' actions should trigger events, such as success or failure logs for file modifications. This SID-based structure ensures precise attribution of permissions and audits to principals without relying on transient names. A practical example is a file's DACL granting full control to the built-in Administrators group, whose well-known SID is S-1-5-32-544. This would include the SID S-1-5-32-544 paired with an access mask enabling read, write, delete, and execute operations, allowing any member of the group to manage the file comprehensively. In contrast, an SACL might audit write attempts by the same SID to log administrative changes for compliance purposes. The distinction between discretionary and system ACLs lies in their management and scope: DACLs are modifiable by the object's owner, enabling user-defined access policies tied to for flexible control, whereas SACLs are typically administered by system administrators to enforce auditing without altering access. This separation allows to support both owner-centric permissions in DACLs and system-wide monitoring in SACLs, enhancing granularity on securable objects.

Authentication and Authorization

During the process in Windows, when a user logs on, the Local Security Authority Subsystem Service (LSASS) verifies the provided credentials against a security database and constructs an to represent the user's security context. This token encapsulates the user's primary Security Identifier (SID), which uniquely identifies the individual account, along with SIDs for all groups to which the user belongs, and any associated privileges derived from those memberships. The primary SID is typically composed of the domain SID followed by a relative identifier (RID) specific to the user, while group SIDs include both domain-local and domain-global groups, ensuring the token reflects the full scope of the user's permissions. Privileges, such as the right to back up files or log on interactively, are also populated into the token based on policy settings and group affiliations. Once the is created, it is attached to the user's initial and inherited by subsequent threads and child processes, serving as the basis for runtime authorization decisions throughout the session. In the authorization phase, the Windows security subsystem compares the SIDs within the access token against the SIDs listed in an object's (ACL) to evaluate access requests. If a matching SID grants the requested permissions—such as read, write, or execute—the access is allowed; otherwise, it is denied, enforcing without requiring repeated . This SID-based comparison occurs dynamically for each protected resource, like files, registry keys, or processes, ensuring efficient and secure enforcement of policies. In scenarios involving trusts between domains or forests, SID filtering is applied to mitigate risks by stripping unauthorized from incoming access tokens. This mechanism, enabled by default on external trusts since , removes SIDs originating from outside the trusting domain to prevent malicious of privileges, such as a compromised account injecting high-privilege SIDs from another domain. The filtering process examines the token's SID history and group memberships, retaining only those verifiable within the trust boundary, and logs the action via event ID 4675 for auditing purposes. Administrators can selectively disable SID filtering using tools like Netdom, but this is generally discouraged due to heightened vulnerability. For example, consider a user logging on to a domain-joined in the "Contoso" domain (with domain SID S-1-5-21-1004336348-1177238915-682003330); LSASS would generate a token containing the user's primary SID (e.g., S-1-5-21-1004336348-1177238915-682003330-1001), supplemented by group SIDs like S-1-5-21-1004336348-1177238915-682003330-513 for Domain Users and any additional groups such as Domain Admins (S-1-5-21-1004336348-1177238915-682003330-512). This token enables the user to access domain resources, such as shared folders, where ACLs reference these for permission grants.

SID Resolution Processes

SID resolution processes in Windows involve translating between security identifiers (SIDs) and account names to facilitate security operations across local and domain environments. These processes are primarily handled by the Local Security Authority (LSA) subsystem, which provides APIs for bidirectional lookups. The key functions are LookupAccountName, which converts an account name to a SID, and LookupAccountSid, which performs the reverse by retrieving an account name from a SID. For local resolution, the LSA queries the Security Accounts Manager (SAM) database on the local machine, which stores information for built-in and local user accounts. Well-known SIDs, such as those for Everyone (S-1-1-0) or Local System (S-1-5-18), are resolved directly from predefined structures without database access. In domain environments, resolution extends to Active Directory (AD) via LDAP queries to domain controllers; the process first checks the primary domain, then trusted domains, and may involve the global catalog for forest-wide SIDs, including those in SID history attributes. If the account name is fully qualified (e.g., DOMAIN\username) or in UPN format (e.g., [email protected]), the lookup targets the specified domain directly. To optimize performance and reduce network traffic, the LSA maintains an in-memory cache of successfully resolved SID-name pairs on domain member workstations and servers. This cache, with a default size of 4,096 entries in and later, stores entries in valid, stale, or expired states, with a time-to-live (TTL) of 7 days (10,080 minutes) and a 10-minute refresh extension. Domain controllers do not use this cache, relying instead on direct access. Negative caching for unresolved isolated names (up to 8,000 entries) has a 2-hour TTL to prevent repeated failed queries. Cache size can be adjusted via the LsaLookupCacheMaxSize registry value, and setting it to 0 disables caching entirely. Error handling in SID resolution returns specific Windows error codes via GetLastError when lookups fail. Common issues include ERROR_NONE_MAPPED (1332), indicating no account matches the SID or name, often due to deleted or non-existent principals. Buffer-related errors like ERROR_INSUFFICIENT_BUFFER (122) occur if output buffers are too small. For orphaned —those from deleted users or groups that persist in access control lists (ACLs)—resolution attempts fail with ERROR_NONE_MAPPED, as the SID no longer maps to an active account in SAM or . In , however, decisions rely on direct binary SID comparisons between the caller's and the object's ACL, bypassing name resolution; thus, orphaned SIDs in ACLs do not grant or deny access to any current principal but can complicate auditing and management by appearing as unresolved entries. Resolved SIDs from these processes are incorporated into access tokens during to represent user and group identities for subsequent checks.

Management and Challenges

SID Generation and Uniqueness

Security Identifiers (SIDs) are generated during the creation of user accounts, groups, or machines, combining a fixed or randomly generated prefix with a relative identifier (RID) to ensure uniqueness within their scope. For domain-based SIDs, the domain SID serves as the prefix, which is established at domain creation and consists of the revision level (S-1), authority (5 for NT Authority), and three 32-bit subauthority values generated randomly to provide a for the domain. This domain SID is then concatenated with an RID assigned sequentially from the domain's RID pool. Local machine SIDs, used for standalone or non-domain-joined systems, follow a similar structure but are generated by the Local Security Authority (LSA) subsystem during operating system installation, incorporating random subauthority values unique to that machine installation. Uniqueness is guaranteed through centralized RID allocation managed by the RID Master (FSMO) role in domains. Domain controllers request blocks of RIDs from the RID Master, typically in increments of 500, drawn from a global pool ranging from 1,000 to 2,147,483,647 for security principals like users and groups. Each domain controller maintains its own local pool from this block and assigns RIDs sequentially without overlap, ensuring no duplicate SIDs within the domain. For local accounts on standalone machines, the Security Accounts Manager (SAM) database handles RID assignment sequentially from a similar starting range, with the machine SID prefix preventing collisions across systems. Machine SIDs are inherently unique per installation due to the random generation process by the LSA. Policies enforce strict non-reuse of to maintain security integrity; once an SID is assigned to an account or group and subsequently deleted, it is not recycled or reassigned, even if the account is recreated. RID recycling is disabled by default in both and SAM to prevent potential vulnerabilities from lingering permissions. In cases of RID pool exhaustion, administrative intervention is required, such as raising the pool ceiling, but this does not involve reusing prior RIDs. For managing SID uniqueness in deployment scenarios, such as imaging multiple machines, the NewSID utility was historically used to generate and apply a new machine SID post-cloning, but it has been deprecated and is no longer recommended or supported by due to untested compatibility with various deployment methods. Instead, the modern standard is to use with the /generalize option during image preparation, which removes the existing machine SID and other system-specific data, allowing a new unique SID to be generated automatically by the LSA upon the first boot of each deployed instance.

Duplication Risks and Mitigation

Duplication of Security Identifiers (SIDs) in Windows environments poses significant security and operational challenges, primarily arising when system uniqueness is not properly maintained during deployment or recovery processes. Common causes include cloning virtual machines (VMs) or physical systems without executing , which fails to regenerate the machine SID, leading to identical identifiers across instances. Manual attempts to copy SIDs, such as through unauthorized tools or scripts, can also introduce duplicates, though this is rare and unsupported. Additionally, improper backup restores—where a single image is deployed to multiple machines without generalization—exacerbate the issue by propagating the original SID. The impacts of SID duplication are multifaceted, often manifesting as authentication disruptions that hinder network operations. In domain-joined scenarios, duplicate SIDs can trigger Kerberos and authentication failures, resulting in repeated credential prompts, denied access to shared resources, and inability to establish Remote Desktop sessions. These issues have become more pronounced following security updates released in 2024 and 2025 that enforce stricter SID validation. This may escalate to privilege elevation risks, where one machine inadvertently gains unauthorized access to another's resources due to overlapping identities, or cause outright logon denials across affected systems. Operationally, failover clustering can fail with "access denied" errors, and event logs may record Event ID 6167 indicating partial machine ID mismatches. Detection of duplicate SIDs typically involves querying individual machines and () for overlaps. The PsGetSid tool can retrieve the machine SID on a local system by running it without parameters, allowing administrators to compare outputs across devices for matches. In environments, Ntdsutil provides a structured approach: after launching ntdsutil and entering security account management mode, the check duplicate sid command scans for and lists duplicate SIDs in the SAM database or directory. queries, such as using PowerShell's Get-ADComputer with select name, SID, further aid in identifying overlaps by exporting and analyzing SID attributes for multiple objects. Mitigation strategies emphasize proactive and reactive measures to restore uniqueness. For existing duplicates on domain-joined systems, the recommended Microsoft-supported approach is to disjoin the computer from the domain, delete the corresponding computer account in if necessary, and rejoin the domain to generate a new machine SID. Alternatively, rebuild the system from a properly generalized image using . In cases of duplicate SIDs within the directory (e.g., for user or group objects), use Ntdsutil's cleanup duplicate sid command to remove the redundant objects. Best practices include always running with the /generalize option before or to ensure SID regeneration, combined with unique machine naming conventions to facilitate tracking and prevent deployment errors. For ongoing prevention, organizations should audit deployment processes and avoid direct disk copies, opting instead for supported tools.

Migration and Translation

In environments, the SIDHistory attribute serves as a multivalued property on user and group objects, storing previous security identifiers from source domains to preserve access rights during migrations without requiring immediate updates to existing lists (ACLs). When a security principal is migrated to a new domain, generates a new primary SID for the object while appending the original SID—and potentially others from prior domains—to the SIDHistory attribute, enabling the principal to impersonate its former identity for legacy resource access. This mechanism ensures continuity of permissions on file shares, printers, and other secured objects that reference the old , avoiding disruptions in multi-domain or inter-forest scenarios. During trust configurations between forests, SID translation mechanisms determine how , including those in SIDHistory, are handled across boundaries to balance security and access needs. By default, trusts employ selective SID filtering, which strips foreign (including SIDHistory entries) from tokens to prevent unauthorized elevation of privileges from trusted domains, such as an attacker in one forest exploiting administrative to access resources in another. Administrators can configure full pass-through by disabling SID filtering on the trusting side using tools like the Netdom trust command, allowing SIDHistory to propagate fully for seamless resource access, though this increases risks like cross-forest and is recommended only in highly controlled environments with additional safeguards. The Migration Tool (ADMT), provided by , facilitates bulk migrations of users, groups, and computers while preserving SIDHistory to maintain ACL continuity. During inter-forest or intra-forest migrations, ADMT populates the SIDHistory attribute on target objects by default when the "Migrate SID history from source domain" option is selected in the User Migration Wizard, ensuring that migrated principals retain permissions on source-domain resources without manual ACL reconfiguration. For scripted or automated processes, ADMT supports command-line switches like /SidHistory in conjunction with password export servers to enable SID preservation, though successful operation requires trusts, schema compatibility, and the Password Export Server service for credential migration. Managing SIDHistory introduces challenges, particularly around quota limits and maintenance, as the attribute can accumulate multiple entries over repeated migrations, inflating the size of Kerberos tickets and access tokens. Active Directory imposes a practical limit of approximately 1,024 per token (including primary SID, group memberships, and SIDHistory entries), beyond which authentication failures occur due to token overflow, potentially locking out users in environments with deep nesting or frequent migrations. To mitigate this, administrators must periodically clean up obsolete from SIDHistory after re-ACLing resources to the new primary , using tools like the Dsacls command, scripts with the module, or third-party utilities such as SUBINACL to identify and remove unused entries without disrupting active permissions. Failure to perform timely cleanup can lead to degradation and increased to denial-of-service attacks exploiting token bloat.

References

  1. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
  2. https://download.microsoft.com/download/5/0/1/501ED102-E53F-4CE0-AA6B-B0F93629DDC6/Windows/%5BMS-SECO%5D.pdf
  3. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers#sid-architecture
  4. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers#how-sids-work
  5. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers#well-known-sids
  6. https://learn.microsoft.com/en-us/windows/win32/secauthz/security-identifiers
  7. https://learn.microsoft.com/en-us/windows-hardware/drivers/ifs/security-identifier
  8. https://learn.microsoft.com/en-us/windows/win32/api/winnt/ns-winnt-sid
  9. https://learn.microsoft.com/en-us/windows/win32/ad/using-dsaddsidhistory
  10. https://learn.microsoft.com/en-us/windows/win32/services/service-changes-for-windows-vista
  11. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/78eb9013-1c3a-4970-ad1f-2b1dad588a25
  12. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/f992ad60-0fe4-4b87-9fed-beb478836861
  13. https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/ns-ntifs-_sid
  14. https://learn.microsoft.com/en-us/windows/win32/secauthz/sid-components
  15. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/c92a27b1-c772-4fa7-a432-15df5f1b66a1
  16. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/c6ce4275-3d90-4890-ab3a-514745e4637e
  17. https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids
  18. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-dtyp/81d92bba-d22b-4a8c-908a-554ab29148ab
  19. https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-azod/ecc7dfba-77e1-4e03-ab99-114b349c7164
  20. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers#rid-allocation
  21. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-r2-and-2012/dn743661(v=ws.11)
  22. https://learn.microsoft.com/en-us/sql/database-engine/configure-windows/configure-windows-service-accounts-and-permissions?view=sql-server-ver17
  23. https://learn.microsoft.com/en-us/iis/manage/configuring-security/application-pool-identities
  24. https://learn.microsoft.com/en-us/windows/win32/secauthz/capability-sid-constants
  25. https://learn.microsoft.com/en-us/windows/win32/secauthz/implementing-an-appcontainer
  26. https://learn.microsoft.com/en-us/troubleshoot/windows-server/windows-security/sids-not-resolve-into-friendly-names
  27. https://learn.microsoft.com/en-us/windows/win32/api/securitybaseapi/nf-securitybaseapi-derivecapabilitysidsfromname
  28. https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-components
  29. https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-lists
  30. https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control-entries
  31. https://learn.microsoft.com/en-us/windows/win32/secauthz/authorization-structures
  32. https://learn.microsoft.com/en-us/windows/win32/secauthz/trustees
  33. https://learn.microsoft.com/en-us/windows/win32/secauthz/access-tokens
  34. https://learn.microsoft.com/en-us/windows/win32/secauthz/access-control
  35. https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-10/security/threat-protection/auditing/event-4675
  36. https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-lookupaccountnamea
  37. https://learn.microsoft.com/en-us/windows/win32/api/winbase/nf-winbase-lookupaccountsida
  38. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/lsa-lookup-performance-counters
  39. https://learn.microsoft.com/en-us/windows-hardware/drivers/driversecurity/windows-security-model
  40. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/managing-rid-issuance
  41. https://learn.microsoft.com/en-us/sysinternals/downloads/newsid
  42. https://learn.microsoft.com/en-us/windows-hardware/manufacture/desktop/sysprep--generalize--a-windows-installation?view=windows-11
  43. https://learn.microsoft.com/en-us/troubleshoot/windows-server/setup-upgrade-and-drivers/windows-installations-disk-duplication
  44. https://support.microsoft.com/en-us/topic/kerberos-and-ntlm-authentication-failures-due-to-duplicate-sids-76f7394d-c460-4882-9ed1-d27e0960f949
  45. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/ntdsutil-find-clean-duplicate-security-identifiers
  46. https://learn.microsoft.com/en-us/windows/win32/adschema/a-sidhistory
  47. https://learn.microsoft.com/en-us/entra/identity/domain-services/concepts-forest-trust
  48. https://adsecurity.org/?p=282
  49. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/inter-forest-sidhistory-migration-with-admt
  50. https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/support-policy-and-known-issues-for-admt
  51. https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/plan/active-directory-domain-services-maximum-limits
  52. https://serverfault.com/questions/198163/how-to-clean-up-orphaned-sids-in-aces-in-ad
Add your contribution
Related Hubs
Contribute something
User Avatar
No comments yet.