[How To Find Your Security Identifier (SID) In Windows 10
Pamula Harrison
A security identifier is used to uniquely identify a security principal or security group. Security principals can represent any entity that can be authenticated by the operating system, such as a user account, a computer account, or a thread or process that runs in the security context of a user or computer account.
Each account or group, or each process that runs in the security context of the account, has a unique SID that's issued by an authority, such as a Windows domain controller. The SID is stored in a security database. The system generates the SID that identifies a particular account or group at the time the account or group is created. When a SID has been used as the unique identifier for a user or group, it can never be used again to identify another user or group.
Each time a user signs in, the system creates an access token for that user. The access token contains the user's SID, user rights, and the SIDs for any groups the user belongs to. This token provides the security context for whatever actions the user performs on that computer.
In addition to the uniquely created domain-specific SIDs that are assigned to specific users and groups, there are well-known SIDs that identify generic groups and generic users. For example, the Everyone and World SIDs identify a group that includes all users. Well-known SIDs have values that remain constant across all operating systems.
SIDs are a fundamental building block of the Windows security model. They work with specific components of the authorization and access control technologies in the security infrastructure of the Windows Server operating systems. This helps protect access to network resources and provides a more secure computing environment.
Users refer to accounts by the account name, but the operating system internally refers to accounts and processes that run in the security context of the account by using their SIDs. For domain accounts, the SID of a security principal is created by concatenating the SID of the domain with a relative identifier (RID) for the account. SIDs are unique within their scope (domain or local), and they're never reused.
The operating system generates a SID that identifies a particular account or group at the time the account or group is created. The SID for a local account or group is generated by the Local Security Authority (LSA) on the computer, and it's stored with other account information in a secure area of the registry. The SID for a domain account or group is generated by the domain security authority, and it's stored as an attribute of the User or Group object in Active Directory Domain Services.
For every local account and group, the SID is unique for the computer where it was created. No two accounts or groups on the computer ever share the same SID. Likewise, for every domain account and group, the SID is unique within an enterprise. This means that the SID for an account or group that's created in one domain will never match the SID for an account or group created in any other domain in the enterprise.
SIDs always remain unique. Security authorities never issue the same SID twice, and they never reuse SIDs for deleted accounts. For example, if a user with a user account in a Windows domain leaves their job, an administrator deletes their Active Directory account, including the SID that identifies the account. If they later return to a different job at the same company, an administrator creates a new account, and the Windows Server operating system generates a new SID. The new SID doesn't match the old one, so none of the user's access from their old account is transferred to the new account. Both their accounts represent two different security principals.
The SID's most important information is contained in the series of subauthority values. The first part of the series (-Y1-Y2-Yn-1) is the domain identifier. This element of the SID becomes significant in an enterprise with several domains, because the domain identifier differentiates SIDs that are issued by one domain from SIDs that are issued by all other domains in the enterprise. No two domains in an enterprise share the same domain identifier.
The last item in the series of subauthority values (-Yn) is the relative identifier. It distinguishes one account or group from all other accounts and groups in the domain. No two accounts or groups in any domain share the same relative identifier.
SIDs for built-in accounts and groups always have the same domain identifier value, 32. This value identifies the domain, Builtin, which exists on every computer that's running a version of the Windows Server operating system. It's never necessary to distinguish one computer's built-in accounts and groups from another computer's built-in accounts and groups, because they're local in scope. They're local to a single computer or, in the case of domain controllers for a network domain, they're local to several computers that are acting as one.
Built-in accounts and groups need to be distinguished from one another within the scope of the Builtin domain. Therefore, the SID for each account and group has a unique relative identifier. A relative identifier value of 544 is unique to the built-in Administrators group. No other account or group in the Builtin domain has a SID with a final value of 544.
In another example, consider the SID for the global group, Domain Admins. Every domain in an enterprise has a Domain Admins group, and the SID for each group is different. The following example represents the SID for the Domain Admins group in the Contoso, Ltd. domain (Contoso\Domain Admins):
The SID for Contoso\Domain Admins is distinguished from the SIDs for other Domain Admins groups in the same enterprise by its domain identifier: 21-1004336348-1177238915-682003330. No other domain in the enterprise uses this value as its domain identifier. The SID for Contoso\Domain Admins is distinguished from the SIDs for other accounts and groups that are created in the Contoso domain by its relative identifier, 512. No other account or group in the domain has a SID with a final value of 512.
When accounts and groups are stored in an account database that's managed by a local Security Accounts Manager (SAM), it's fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a standalone computer. The SAM on a standalone computer can track the relative identifier values that it has used before and make sure that it never uses them again.
In a network domain, however, generating unique relative identifiers is a more complex process. Windows Server network domains can have several domain controllers. Each domain controller stores Active Directory account information. This means that, in a network domain, there are as many copies of the account database as there are domain controllers. In addition, every copy of the account database is a master copy.
New accounts and groups can be created on any domain controller. Changes that are made to Active Directory on one domain controller are replicated to all other domain controllers in the domain. The process of replicating changes in one master copy of the account database to all other master copies is called a multimaster operation.
The process of generating unique relative identifiers is a single-master operation. One domain controller is assigned the role of RID master, and it allocates a sequence of relative identifiers to each domain controller in the domain. When a new domain account or group is created in one domain controller's replica of Active Directory, it's assigned a SID. The relative identifier for the new SID is taken from the domain controller's allocation of relative identifiers. When its supply of relative identifiers begins to run low, the domain controller requests another block from the RID master.
Each domain controller uses each value in a block of relative identifiers only once. The RID master allocates each block of relative identifier values only once. This process assures that every account and group created in the domain has a unique relative identifier.
When a new domain user or group account is created, Active Directory stores the account's SID in the ObjectSID property of a User or Group object. It also assigns the new object a globally unique identifier (GUID), which is a 128-bit value that's unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that's created by Active Directory and not only in User and Group objects. Each object's GUID is stored in its ObjectGUID property.
Active Directory uses GUIDs internally to identify objects. For example, the GUID is one of an object's properties that's published in the global catalog. Searching the global catalog for a User object GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by ObjectGUID might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the ObjectGUID property never changes. When an object is assigned a GUID, it keeps that value for life.
If a user moves from one domain to another, the user gets a new SID. The SID for a group object doesn't change, because groups stay in the domain where they were created. However, if people move, their accounts can move with them. If an employee moves from North America to Europe, but stays in the same company, an administrator for the enterprise can move the employee's User object from, for example, Contoso\NoAm to Contoso\Europe. If the administrator does this, the User object for the account needs a new SID. The domain identifier portion of a SID that's issued in NoAm is unique to NoAm, so the SID for the user's account in Europe has a different domain identifier. The relative identifier portion of a SID is unique relative to the domain, so if the domain changes, the relative identifier also changes.
When a User object moves from one domain to another, a new SID must be generated for the user account and stored in the ObjectSID property. Before the new value is written to the property, the previous value is copied to another property of a User object, SIDHistory. This property can hold multiple values. Each time a User object moves to another domain, a new SID is generated and stored in the ObjectSID property, and another value is added to the list of old SIDs in SIDHistory. When a user signs in and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user, including the user's current SID, the user's old SIDs, and the SIDs for the user's groups. All these SIDs are returned to the authentication client, and they're included in the user's access token. When the user tries to gain access to a resource, any one of the SIDs in the access token (including one of the SIDs in SIDHistory), can allow or deny the user access.
795a8134c1