共用方式為

How Security Identifiers Work

  • 發行項

Applies To: Windows Server 2003, Windows Server 2003 R2, Windows Server 2003 with SP1, Windows Server 2003 with SP2

How Security Identifiers Work

In This Section

  • Security Identifier Architecture

  • Relative Identifier Allocation

  • Security Identifiers and Globally Unique Identifiers

  • Well-Known SIDs

Users refer to accounts by using the account name, but the operating system internally refers to accounts by 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 are never reused.

The system generates the 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 stored as an attribute of the User or Group object in Active Directory directory service.

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 created in one domain will never match the SID for an account or group created in any 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 Server 2003 domain leaves her job, an administrator deletes her 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 2003 operating system generates a new SID. The new SID does not match the old one; so none of the users 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, like a telephone number, and identify the SID-issuing authority (for example, the Windows Server 2003 operating system), the SID-issuing domain, and a particular security principal or group. The following figure illustrates the structure of a SID.

SID Structure

SID Structure

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

SID Components

Component Description

Revision

Indicates the version of the SID structure that is used in a particular SID. The structure used in all SIDs that are 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 NT, Windows 2000, or Windows Server 2003 account or group is 5 (NT Authority).

Subauthorities

Holds the most important information in a SID. 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 binary to string format by using standard notation:

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

In this notation, the components of a SID are as follows:

SID Components in String Format

Component Definition

S

Indicates that the string is a SID

R

Revision level

X

Identifier authority value

Y

A series of subauthority values, where n is the number of values

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 NT, Windows 2000, or Windows Server 2003 operating systems. 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: local either to a single computer; or in the case of domain controllers for a network domain, local to several computers that are acting as one. However, built-in accounts and groups do 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 is the SID for the Domain Admins group in the Contoso 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 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

Where 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 group that it creates on a stand-alone computer. The SAM on a stand-alone computer can simply keep track of 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 2003 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 Object-SID (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 just User and Group objects. Each object's GUID is stored in its Object-GUID (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's GUID produces results if the user has an account somewhere in the enterprise. In fact, searching for any object by Object-GUID might be the most reliable way of finding the object you want to locate. The values of other object properties can change, but the Object-GUID 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 Object-SID property. Before the new value is written to the property, the previous value is copied to another property of a User object, SID-History (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 Object-SID property and another value is added to the list of old SIDs in SID-History. When a user logs on and is successfully authenticated, the domain authentication service queries Active Directory for all the SIDs that are associated with the user — 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 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 SID-History, can allow or deny the user access.

If you allow or deny user’s access to a resource based on their jobs, you should allow or deny access to a group, not 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 SID-History 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, listed among the SIDs for the user's groups, and the user is granted or denied access based on the old SID.

The reason for using SIDs, and not GUIDs, is for backward compatibility. Windows NT uses SIDs to identify users and groups in ACLs on resources; so you do not have to change ACLs on your resources when you upgrade. In Windows 2000 and Windows Server 2003, ACLs continue to identify users and groups by SID, not GUID — even ACLs on resources in Active Directory. For example, a user gains access to a Group Policy object based on one of the user's SIDs, not on the GUID for the User object.

Well-Known SIDs

The values of certain SIDs are constant across all systems. They are created during installation of the operating system or domain and are called well-known SIDs because they identify generic users or generic groups. For example, well-known SIDs identify the following users and groups:

Everyone (S-1-1-0)

The generic group Everyone automatically includes everyone who uses the computer, even anonymous guests. The identifier authority value for this SID is 1 (World Authority). It has only one subauthority value, 0 (Null RID).

Creator Owner (S-1-3-0)

The generic user Creator Owner is a placeholder in an inheritable access control entry (ACE). When the ACE is inherited, the system replaces the SID for Creator Owner with the SID for the object's current owner. The identifier authority value for this SID is 3 (Creator Authority). It has only one subauthority value, 0 (Null RID).

Principal Self (S-1-5-10)

The generic user Principal Self is a placeholder in an ACE on a User, Group, or Computer object in Active Directory. When you grant permission to Principal Self, you grant it to the security principal represented by the object. During an access check, the operating system replaces the SID for Principal Self with the SID for the security principal represented by the object. The identifier authority for this SID is 5 (NT Authority). It has only one subauthority value, 10 (Self RID).

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

Universal Well-Known SID Value Identifies

Null SID

(S-1–0–0)

A group with no members. This is often used when a SID value is not known.

World

(S-1–1–0)

A group that includes all users.

Local

(S-1–2–0)

Users who log on to terminals that are locally (physically) connected to the system.

Creator Owner ID

(S-1–3–0)

A security identifier to be replaced by the security identifier of the user who created a new object. This SID is used in inheritable ACEs.

Creator Group ID

(S-1–3–1)

A security identifier to be replaced by the primary-group SID of the user who created a new object. Use this SID in inheritable ACEs.

The following table lists the predefined identifier authority constants. The first four values are used with universal well-known SIDs; the last value is used with well-known SIDs in Windows XP, Windows NT, Windows 2000, and Windows Server 2003 operating systems.

Predefined Identifier Authority Constants

Identifier Authority Value SID String Prefix

SECURITY_NULL_SID_AUTHORITY

0

S-1–0

SECURITY_WORLD_SID_AUTHORITY

1

S-1–1

SECURITY_LOCAL_SID_AUTHORITY

2

S-1–2

SECURITY_CREATOR_SID_AUTHORITY

3

S-1–3

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

Relative Identifier Authority Value Identifier Authority

SECURITY_NULL_RID

0

S-1–0

SECURITY_WORLD_RID

0

S-1–1

SECURITY_LOCAL_RID

0

S-1–2

SECURITY_CREATOR_OWNER_RID

0

S-1–3

SECURITY_CREATOR_GROUP_RID

1

S-1–3

The SECURITY_NT_AUTHORITY (S-1–5) predefined identifier authority produces SIDs that are not universal and are meaningful only in Windows XP, Windows NT, Windows 2000, and Windows Server 2003 installations. 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-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 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 logs on using a Remote Desktop connection, the user's access token also contains the Remote Interactive Logon SID.

S-1-5-5-X-Y

Logon Session

A 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 logged on 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 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 Web site. Strictly speaking, such access is not anonymous; 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 the account on when the service starts. As a result, the IIS “anonymous” user is a member of Authenticated Users while Anonymous Logon is not.

S-1-5-8

Proxy

Does not currently apply: this SID is not used in the Windows 2000 Server or Windows Server 2003 operating systems.

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 on a user, group, or computer object in Active Directory. When you grant permissions to Self, you grant them to the security principal represented by the object. During an access check, the operating system replaces the SID for Self with the SID for the security principal represented by the object.

S-1-5-11

Authenticated Users

A group that includes all users and computers whose identities 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 just the current domain.

S-1-5-12

Restricted

An identity used by a process that is executing in a restricted security context. In Windows XP and Windows Server 2003 operating systems, a software restriction policy can assign one of three security levels to executable code: unrestricted, restricted, or disallowed. When code executes 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 log on to a server with Terminal Services enabled: specifically, a server that is in Terminal Services version 4.0 application compatibility mode.

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-18

System (or LocalSystem)

An identity that is used locally by the operating system and by services configured to log on 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

LocalService

An identity 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 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 — both locally and on the network.

S-1-5-20

NetworkService

An identity 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 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 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 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 Everyone and Guests. 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 can be used to log on interactively. By default, the account is enabled on Windows XP and disabled on all editions of the Windows Server 2003 operating system. The Guest account does not require a password, but 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 whose members 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 that, 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 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, 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 Certificate 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 domain local 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.

The following RIDs are relative to each domain.

RIDs Relative to Each Domain

RID Identifies

DOMAIN_USER_RID_ADMIN

The administrative user account in a domain.

DOMAIN_USER_RID_GUEST

The guest-user account in a domain. Users who do not have an account can automatically log on to this account.

DOMAIN_GROUP_RID_ADMINS

The domain administrators' group. This account exists only on systems running Windows 2000 Server or Windows NT Server.

DOMAIN_GROUP_RID_USERS

A group containing all user accounts in a domain. All users are automatically added to this group.

DOMAIN_GROUP_RID_GUESTS

The guest-group account in a domain.

DOMAIN_GROUP_RID_COMPUTERS

The domain computers' group. All computers in the domain are members of this group.

DOMAIN_GROUP_RID_CONTROLLERS

The domain controllers' group. All Domain controllers in the domain are members of this group.

DOMAIN_GROUP_RID_CERT_ADMINS

The certificate publishers' group. Computers running Certificate Services are members of this group.

DOMAIN_GROUP_RID_SCHEMA_ADMINS

The schema administrators' group. Members of this group can modify the Active Directory schema.

DOMAIN_GROUP_RID_ENTERPRISE_ADMINS

The enterprise administrators' group. Members of this group have full access to all domains in the Active Directory forest. Enterprise administrators are responsible for forest-level operations such as adding or removing new domains.

DOMAIN_GROUP_RID_POLICY_ADMINS

The policy administrators' group.

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

RID Identifies

DOMAIN_ALIAS_RID_ADMINS

A local group that is used for administration of the domain.

DOMAIN_ALIAS_RID_USERS

A local group that represents all users in the domain.

DOMAIN_ALIAS_RID_GUESTS

A local group that represents guests of the domain.

DOMAIN_ALIAS_RID_POWER_USERS

A local group that is used to represent a user or set of users who expect to treat a system as if it were their personal computer rather than as a workstation for multiple users.

DOMAIN_ALIAS_RID_ACCOUNT_OPS

A local group that exists only on systems running Windows 2000 Server or Windows NT Server. This local group permits control over non-administrator accounts.

DOMAIN_ALIAS_RID_SYSTEM_OPS

A local group that exists only on systems running Windows 2000 Server or Windows NT Server. This local group performs system administrative functions, not including security functions. It establishes network shares, controls printers, unlocks workstations, and performs other operations.

DOMAIN_ALIAS_RID_PRINT_OPS

A local group that exists only on systems running Windows 2000 Server or Windows NT Server. This local group controls printers and print queues.

DOMAIN_ALIAS_RID_BACKUP_OPS

A local group that is used for controlling assignment of file backup-and-restoring user rights.

DOMAIN_ALIAS_RID_REPLICATOR

A local group responsible for copying security databases from the primary domain controller to the backup domain controllers. These accounts are used only by the system.

DOMAIN_ALIAS_RID_RAS_SERVERS

A local group that represents remote access and servers running Internet Authentication Service (IAS). This group permits access to various attributes of user objects.

DOMAIN_ALIAS_RID_PREW2KCOMPACCESS

A local group that exists only on systems running Windows 2000 Server and Windows Server 2003. This group provides access rights equal to anonymous access under Windows NT, which is Everyone access.