Security Identifiers Technical Overview

Applies To: Windows 7, Windows 8.1, Windows Server 2008 R2, Windows Server 2012 R2, Windows Server 2012, Windows 8

This topic for the IT professional describes security identifiers and how they work in regards to accounts and groups in the Windows operating system.

What are security identifiers?

A security identifier (SID) 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 process running in the security context of the account, has a unique SID that is issued by an authority, such as a Windows domain controller. It 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.

The content in this topic applies to computers that are running the supported versions of the Windows operating system as designated in the Applies To list at the beginning of this topic.

In this topic

• How security identifiers work

• Security identifier architecture

• Relative identifier allocation

• Security identifiers and globally unique identifiers

• Well-known SIDs

• Changes in security identifier’s functionality

How security identifiers work

Users refer to accounts by using 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 security identifiers (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 are 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 is 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 is 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 is 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 her job, an administrator deletes her Active Directory account, including the SID that identifies the account. If she later returns 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 does not match the old one; so none of the user’s access from her old account is transferred to the new account. Her two accounts represent two completely different security principals.

Security identifier architecture

A security identifier is a data structure in binary format that contains a variable number of values. The first values in the structure contain information about the SID structure. The remaining values are arranged in a hierarchy (similar to a telephone number), and they identify the SID-issuing authority (for example, the Windows Server 2012 operating system), the SID-issuing domain, and a particular security principal or group. The following image illustrates the structure of a SID.

SID structure

The individual values of a SID are described in the following table.

SID components

Component	Description
Revision	Indicates the version of the SID structure that is used in a particular SID. Note The structure used in all SIDs that were created by a Windows Server 2003 operating system and earlier versions is revision level 1.
Identifier authority	Identifies the highest level of authority that can issue SIDs for a particular type of security principal. For example, the identifier authority value in the SID for the Everyone group is 1 (World Authority). The identifier authority value in the SID for a specific Windows Server account or group is 5 (NT Authority).
Subauthorities	Holds the most important information in a SID, which is contained in a series of one or more subauthority values. All values up to, but not including, the last value in the series collectively identify a domain in an enterprise. This part of the series is called the domain identifier. The last value in the series, which is called the relative identifier (RID), identifies a particular account or group relative to a domain.

The components of a SID are easier to visualize when SIDs are converted from a binary to a string format by using standard notation:

S-R-X-Y1-Y2-Yn-1-Yn

In this notation, the components of a SID are represented as shown in the following table.

SID components in string format

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.

For example, the SID for the built-in Administrators group is represented in standardized SID notation as the following string:

S-1-5-32-544

This SID has four components:

• A revision level (1)

• An identifier authority value (5, NT Authority)

• A domain identifier (32, Builtin)

• A relative identifier (544, Administrators)

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 is running a version of the Windows Server operating system. It is never necessary to distinguish one computer's built-in accounts and groups from another computer's built-in accounts and groups because they are local in scope. They are local to a single computer, or in the case of domain controllers for a network domain, they are 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):

S-1-5-21-1004336348-1177238915-682003330-512

The SID for Contoso\Domain Admins has:

• A revision level (1)

• An identifier authority (5, NT Authority)

• A domain identifier (21-1004336348-1177238915-682003330, Contoso)

• A relative identifier (512, 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.

Relative identifier allocation

When accounts and groups are stored in an account database that is managed by a local Security Accounts Manager (SAM), it is fairly easy for the system to generate a unique relative identifier for each account and in a group that it creates on a stand-alone computer. The SAM on a stand-alone 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 to this, 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 relative identifier (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 is 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.

Security identifiers and globally unique identifiers

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 is unique not only in the enterprise, but also across the world. GUIDs are assigned to every object that is created by Active Directory, not only 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 is 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 does not 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 is 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 are 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.

If you allow or deny users’ access to a resource based on their jobs, you should allow or deny access to a group, not to an individual. That way, when users change jobs or move to other departments, you can easily adjust their access by removing them from certain groups and adding them to others.

However, if you allow or deny an individual user access to resources, you probably want that user's access to remain the same no matter how many times the user's account domain changes. The SIDHistory property makes this possible. When a user changes domains, there is no need to change the access control list (ACL) on any resource. If an ACL has the user's old SID, but not the new one, the old SID is still in the user's access token. It is listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.

Well-known SIDs

The values of certain SIDs are constant across all systems. They are created when the operating system or domain is installed. They are called well-known SIDs because they identify generic users or generic groups.

There are universal well-known SIDs that are meaningful on all secure systems that use this security model, including operating systems other than Windows. In addition, there are well-known SIDs that are meaningful only on Windows operating systems.

The following table lists the universal well-known SIDs.

Universal well-known SIDs

The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs, and the last value is used with well-known SIDs in Windows operating systems designated in the Applies To list.

Predefined identifier authority constants

The following RID values are used with universal well-known SIDs. The Identifier authority column shows the prefix of the identifier authority with which you can combine the RID to create a universal well-known SID.

RID values used with universal well-known SIDs

The SECURITY_NT_AUTHORITY (S-1–5) predefined identifier authority produces SIDs that are not universal and are meaningful only in installations of the Windows operating systems that are designated in the Applies To list at the beginning of this topic. The following table lists the well-known SIDs.

Well-known security identifiers

SID	Display Name	Description
S-1-5-1	Dialup	A group that includes all users who are logged on to the system by means of a dial-up connection.
S-1-5-113	Local account	You can use this SID when restricting network logon to local accounts instead of “administrator” or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named. Introduced in Windows Server 2012 R2.
S-1-5-114	Local account and member of Administrators group	You can use this SID when restricting network logon to local accounts instead of “administrator” or equivalent. This SID can be effective in blocking network logon for local users and groups by account type regardless of what they are actually named. Introduced in Windows Server 2012 R2.
S-1-5-2	Network	A group that includes all users who are logged on by means of a network connection. Access tokens for interactive users do not contain the Network SID.
S-1-5-3	Batch	A group that includes all users who have logged on by means of a batch queue facility, such as task scheduler jobs.
S-1-5-4	Interactive	A group that includes all users who log on interactively. A user can start an interactive logon session by logging on directly at the keyboard, by opening a Remote Desktop Services connection from a remote computer, or by using a remote shell such as Telnet. In each case, the user's access token contains the Interactive SID. If the user signs in by using a Remote Desktop Services connection, the user's access token also contains the Remote Interactive Logon SID.
S-1-5-5-X-Y	Logon Session	The X and Y values for these SIDs uniquely identify a particular logon session.
S-1-5-6	Service	A group that includes all security principals that have signed in as a service.
S-1-5-7	Anonymous Logon	A user who has connected to the computer without supplying a user name and password. The Anonymous Logon identity is different from the identity that is used by Internet Information Services (IIS) for anonymous web access. IIS uses an actual account—by default, IUSR_ComputerName, for anonymous access to resources on a website. Strictly speaking, such access is not anonymous because the security principal is known even though unidentified people are using the account. IUSR_ComputerName (or whatever you name the account) has a password, and IIS logs on the account when the service starts. As a result, the IIS “anonymous” user is a member of Authenticated Users but Anonymous Logon is not.
S-1-5-8	Proxy	Does not currently apply: this SID is not used.
S-1-5-9	Enterprise Domain Controllers	A group that includes all domain controllers in a forest of domains.
S-1-5-10	Self	A placeholder in an ACE for a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant them to the security principal that is represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal that is represented by the object.
S-1-5-11	Authenticated Users	A group that includes all users and computers with identities that have been authenticated. Authenticated Users does not include Guest even if the Guest account has a password. Note This group includes authenticated security principals from any trusted domain, not only the current domain.
S-1-5-12	Restricted Code	An identity that is used by a process that is running in a restricted security context. In Windows and Windows Server operating systems, a software restriction policy can assign one of three security levels to code: unrestricted, restricted, or disallowed. When code runs at the restricted security level, the Restricted SID is added to the user's access token.
S-1-5-13	Terminal Server User	A group that includes all users who sign in to a server with Remote Desktop Services enabled.
S-1-5-14	Remote Interactive Logon	A group that includes all users who log on to the computer by using a remote desktop connection. This group is a subset of the Interactive group. Access tokens that contain the Remote Interactive Logon SID also contain the Interactive SID.
S-1-5-15	This Organization	A group that includes all users from the same organization. Only included with Active Directory accounts and only added by a domain controller.
S-1-5-17	IIS_USRS	An account that is used by the default Internet Information Services (IIS) user.
S-1-5-18	System (or LocalSystem)	An identity that is used locally by the operating system and by services that are configured to sign in as LocalSystem. System is a hidden member of Administrators. That is, any process running as System has the SID for the built-in Administrators group in its access token. When a process that is running locally as System accesses network resources, it does so by using the computer's domain identity. Its access token on the remote computer includes the SID for the local computer's domain account plus SIDs for security groups that the computer is a member of, such as Domain Computers and Authenticated Users.
S-1-5-19	NT Authority (LocalService)	An identity that is used by services that are local to the computer, have no need for extensive local access, and do not need authenticated network access. Services that run as LocalService access local resources as ordinary users, and they access network resources as anonymous users. As a result, a service that runs as LocalService has significantly less authority than a service that runs as LocalSystem—locally and on the network.
S-1-5-20	Network Service	An identity that is used by services that have no need for extensive local access but do need authenticated network access. Services running as NetworkService access local resources as ordinary users and access network resources by using the computer's identity. As a result, a service that runs as NetworkService has the same network access as a service that runs as LocalSystem, but it has significantly reduced local access.
S-1-5-domain-500	Administrator	A user account for the system administrator. Every computer has a local Administrator account and every domain has a domain Administrator account. The Administrator account is the first account created during operating system installation. The account cannot be deleted, disabled, or locked out, but it can be renamed. By default, the Administrator account is a member of the Administrators group, and it cannot be removed from that group.
S-1-5-domain-501	Guest	A user account for people who do not have individual accounts. Every computer has a local Guest account, and every domain has a domain Guest account. By default, Guest is a member of the Everyone and the Guests groups. The domain Guest account is also a member of the Domain Guests and Domain Users groups. Unlike Anonymous Logon, Guest is a real account, and it can be used to log on interactively. By default, the account is enabled in Windows client operating systems that are designated in the Applies To list, and disabled in Windows Server operating systems that are designated in the Applies To list. The Guest account does not require a password, but it can have one.
S-1-5-domain-502	krbtgt	A user account that is used by the Key Distribution Center (KDC) service. The account exists only on domain controllers.
S-1-5-domain-512	Domain Admins	A global group with members that are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined the domain, including domain controllers. Domain Admins is the default owner of any object that is created in the domain’s Active Directory by any member of the group. If members of the group create other objects, such as files, the default owner is the Administrators group.
S-1-5-domain-513	Domain Users	A global group that includes all users in a domain. When you create a new User object in Active Directory, the user is automatically added to this group.
S-1-5-domain-514	Domain Guests	A global group, which by default, has only one member: the domain’s built-in Guest account.
S-1-5-domain-515	Domain Computers	A global group that includes all computers that have joined the domain, excluding domain controllers.
S-1-5-domain-516	Domain Controllers	A global group that includes all domain controllers in the domain. New domain controllers are added to this group automatically.
S-1-5-domain-517	Cert Publishers	A global group that includes all computers that host an enterprise certification authority. Cert Publishers are authorized to publish certificates for User objects in Active Directory.
S-1-5-root domain-518	Schema Admins	A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode. The Schema Admins group is authorized to make schema changes in Active Directory. By default, the only member of the group is the Administrator account for the forest root domain.
S-1-5-root domain-519	Enterprise Admins	A group that exists only in the forest root domain. It is a universal group if the domain is in native mode, and it is a global group if the domain is in mixed mode. The Enterprise Admins group is authorized to make changes to the forest infrastructure, such as adding child domains, configuring sites, authorizing DHCP servers, and installing enterprise certification authorities. By default, the only member of Enterprise Admins is the Administrator account for the forest root domain. The group is a default member of every Domain Admins group in the forest.
S-1-5-domain-520	Group Policy Creator Owners	A global group that is authorized to create new Group Policy Objects in Active Directory. By default, the only member of the group is Administrator. Objects that are created by members of Group Policy Creator Owners are owned by the individual user who creates them. In this way, the Group Policy Creator Owners group is unlike other administrative groups (such as Administrators and Domain Admins). Objects that are created by members of these groups are owned by the group rather than by the individual.
S-1-5-domain-553	RAS and IAS Servers	A local domain group. By default, this group has no members. Computers that are running the Routing and Remote Access service are added to the group automatically. Members of this group have access to certain properties of User objects, such as Read Account Restrictions, Read Logon Information, and Read Remote Access Information.
S-1-5-32-544	Administrators	A built-in group. After the initial installation of the operating system, the only member of the group is the Administrator account. When a computer joins a domain, the Domain Admins group is added to the Administrators group. When a server becomes a domain controller, the Enterprise Admins group also is added to the Administrators group.
Users	S-1-5-32-545	A built-in group. After the initial installation of the operating system, the only member is the Authenticated Users group.
S-1-5-32-546	Guests	A built-in group. By default, the only member is the Guest account. The Guests group allows occasional or one-time users to log on with limited privileges to a computer's built-in Guest account.
S-1-5-32-547	Power Users	A built-in group. By default, the group has no members. Power users can create local users and groups; modify and delete accounts that they have created; and remove users from the Power Users, Users, and Guests groups. Power users also can install programs; create, manage, and delete local printers; and create and delete file shares.
S-1-5-32-548	Account Operators	A built-in group that exists only on domain controllers. By default, the group has no members. By default, Account Operators have permission to create, modify, and delete accounts for users, groups, and computers in all containers and organizational units of Active Directory except the Builtin container and the Domain Controllers OU. Account Operators do not have permission to modify the Administrators and Domain Admins groups, nor do they have permission to modify the accounts for members of those groups.
S-1-5-32-549	Server Operators	Description: A built-in group that exists only on domain controllers. By default, the group has no members. Server Operators can log on to a server interactively; create and delete network shares; start and stop services; back up and restore files; format the hard disk of the computer; and shut down the computer.
S-1-5-32-550	Print Operators	A built-in group that exists only on domain controllers. By default, the only member is the Domain Users group. Print Operators can manage printers and document queues.
S-1-5-32-551	Backup Operators	A built-in group. By default, the group has no members. Backup Operators can back up and restore all files on a computer, regardless of the permissions that protect those files. Backup Operators also can log on to the computer and shut it down.
S-1-5-32-552	Replicators	A built-in group that is used by the File Replication service on domain controllers. By default, the group has no members. Do not add users to this group.
S-1-5-64-10	NTLM Authentication	A SID that is used when the NTLM authentication package authenticated the client
S-1-5-64-14	SChannel Authentication	A SID that is used when the SChannel authentication package authenticated the client.
S-1-5-64-21	Digest Authentication	A SID that is used when the Digest authentication package authenticated the client.
S-1-5-80	NT Service	A SID that is used as an NT Service account prefix.
S-1-5-80-0	All Services	A group that includes all service processes that are configured on the system. Membership is controlled by the operating system. SID S-1-5-80-0 equals NT SERVICES\ALL SERVICES. This SID was introduced in Windows Server 2008 R2.
S-1-5-83-0	NT VIRTUAL MACHINE\Virtual Machines	A built-in group. The group is created when the Hyper-V role is installed. Membership in the group is maintained by the Hyper-V Management Service (VMMS). This group requires the "Create Symbolic Links" right (SeCreateSymbolicLinkPrivilege), and also the "Log on as a Service" right (SeServiceLogonRight). This SID was introduced in Windows Server 2012.
S-1-16-0	Untrusted Mandatory Level	A SID that represents an untrusted integrity level.
S-1-16-4096	Low Mandatory Level	A SID that represents a low integrity level.
S-1-16-8192	Medium Mandatory Level	This SID represents a medium integrity level.
S-1-16-8448	Medium Plus Mandatory Level	A SID that represents a medium plus integrity level.
S-1-16-12288	High Mandatory Level	A SID that represents a high integrity level.
S-1-16-16384	System Mandatory Level	A SID that represents a system integrity level.
S-1-16-20480	Protected Process Mandatory Level	A SID that represents a protected-process integrity level.
S-1-16-28672	Secure Process Mandatory Level	A SID that represents a secure process integrity level.

The following RIDs are relative to each domain.

RIDs relative to each domain

The following table provides examples of domain-relative RIDs that are used to form well-known SIDs for local groups.

Examples of RIDs for local groups

Changes in security identifier’s functionality

The following table describes changes in SID implementation in the Windows operating systems that are designated in the Applies To list.

See also

Access Control Overview