Well-known principals
A well-known principal is a principal whose SID is fixed by the system rather than allocated when an account is created. Some name a single specific entity (SYSTEM, Anonymous). Some name a category (Everyone, Authenticated Users). Some are placeholders that get rewritten during inheritance (CREATOR OWNER). All of them have the same purpose: they let you write ACEs that target a role without naming a specific user.
You will recognise the common ones quickly; the full catalog exists so you can look up the rest when they appear in an audit log or an ACE.
How to read the catalog #
Each well-known SID has a fixed numeric value, a conventional name, and a defined behaviour during access checks. Some of them are not real principals at all — they are placeholders or labels that the access check treats specially. Where that distinction matters, it is called out.
The catalog is organised by SID authority, because that is how the SIDs are structured and how you will tend to recognise them.
Universal SIDs (S-1-0, S-1-1, S-1-2, S-1-3) #
These authorities are defined globally — not tied to any specific machine or domain — and exist for cross-system meaning.
| SID | Name | Behaviour |
|---|---|---|
S-1-0-0 | Nobody | Matches nothing. Used to write an ACE that can never apply, usually as a deliberate placeholder. |
S-1-1-0 | Everyone | Matches every token, including Anonymous. The broadest possible grant. |
S-1-2-0 | Local | Matches any token created by a local logon (not a network logon). |
S-1-2-1 | Console Logon | Matches a token created by a physical or console session. |
S-1-3-0 | Creator Owner | Placeholder. Inheritable ACEs containing this SID are rewritten to the new object's owner SID when the child is created. Does not match anything at access-check time. |
S-1-3-1 | Creator Group | Placeholder. Same as Creator Owner but for the primary group. |
S-1-3-4 | Owner Rights | Special. When present in a DACL, it suppresses the implicit READ_CONTROL and WRITE_DAC grants that the owner would otherwise receive. See Ownership and implicit rights. |
The placeholder SIDs (S-1-3-0 and S-1-3-1) are the trickiest. They never grant or deny anything at access-check time. Their job is to make inheritable ACEs portable across owners — you write an ACE that grants WRITE to Creator Owner, and when a child object is created, that ACE is rewritten to grant WRITE to whoever owns the child.
NT Authority SIDs (S-1-5) #
This is the largest group of well-known SIDs and where most of the principals you will use day-to-day live.
Logon classifiers #
| SID | Name | Behaviour |
|---|---|---|
S-1-5-2 | Network | Matches a token created by a network logon. |
S-1-5-4 | Interactive | Matches a token created by an interactive logon (console, RDP, SSH). |
S-1-5-6 | Service | Matches a token created for a service. |
S-1-5-7 | Anonymous | The user SID for tokens at the Anonymous impersonation level. |
S-1-5-11 | Authenticated Users | Matches every successfully authenticated token. Excludes Anonymous. |
The pair S-1-1-0 (Everyone) and S-1-5-11 (Authenticated Users) is the most common distinction worth getting right. Everyone includes Anonymous; Authenticated Users excludes it. Anything reachable by Anonymous is reachable by an unauthenticated network peer, which is almost never what you want.
System actors #
| SID | Name | Behaviour |
|---|---|---|
S-1-5-18 | Local System (SYSTEM) | The kernel and TCB services run as SYSTEM. The most privileged identity on the local machine. |
S-1-5-19 | Local Service | Built-in service account with reduced privileges. |
S-1-5-20 | Network Service | Built-in service account that can authenticate outward to remote machines. |
Built-in aliases #
The sub-authority 32 under NT Authority is the "BUILTIN" domain, which holds aliases for common administrative roles. The full alias list includes a few dozen entries; the ones you will see most often:
| SID | Name |
|---|---|
S-1-5-32-544 | BUILTIN\Administrators |
S-1-5-32-545 | BUILTIN\Users |
S-1-5-32-546 | BUILTIN\Guests |
S-1-5-32-551 | BUILTIN\Backup Operators |
Logon sessions and domains #
| Pattern | Meaning |
|---|---|
S-1-5-5-X-Y | A specific logon session. X and Y are derived from the session's LUID. Always carried in the token of any thread belonging to that session. |
S-1-5-21-DA1-DA2-DA3-RID | A principal in a specific domain. DA1-DA2-DA3 identifies the domain; RID identifies the principal within it. |
S-1-5-21-DA1-DA2-DA3-500 | The Administrator account of that domain (RID 500 is reserved). |
S-1-5-21-DA1-DA2-DA3-512 | Domain Admins. |
S-1-5-21-DA1-DA2-DA3-513 | Domain Users. |
S-1-5-21-DA1-DA2-DA3-515 | Domain Computers — the machine accounts in the domain. |
The full set of reserved RIDs under S-1-5-21-* follows administrative convention. Domain-specific principals (your actual users) get RIDs allocated above 1000.
Service SIDs #
A SID derived from a service's name, used to grant a service ACL entries independent of the account it runs under.
| Pattern | Meaning |
|---|---|
S-1-5-80-h1-h2-h3-h4-h5 | A service SID. The five hash values come from the SHA-1 of the UTF-16LE uppercased service name, split into five little-endian 32-bit integers. |
Service SIDs let you say "grant the loregd service read access to this file" without saying "grant SYSTEM read access" or "grant a specific user read access" — both of which would be too broad.
Mandatory integrity labels (S-1-16) #
These are not principals. They are labels carried in a token's integrity level field and in an object's mandatory label ACE.
| SID | Level |
|---|---|
S-1-16-0 | Untrusted |
S-1-16-4096 | Low |
S-1-16-8192 | Medium |
S-1-16-12288 | High |
S-1-16-16384 | System |
These five are the standard, well-known levels. The level is really the SID's single sub-authority as an unsigned integer, compared numerically, so any S-1-16-<n> with exactly one sub-authority is valid — non-standard values such as medium-plus (S-1-16-8448) and protected (S-1-16-20480) appear for Windows interop.
Integrity levels are a vertical axis on top of identity. A user at Medium integrity and the same user at High integrity have the same SID but different integrity labels. See Mandatory integrity control for how the levels interact with access checks.
Process trust labels (S-1-19) #
Like integrity labels, these are not principals. They label processes by signing trust for Process integrity protection.
| Pattern | Meaning |
|---|---|
S-1-19-T-L | PIP trust label. T is the PIP type (0 None, 512 Protected, 1024 Isolated). L is the trust level within that type. |
Common combinations:
| SID | Trust meaning |
|---|---|
S-1-19-0-0 | No PIP protection. Default for unsigned processes. |
S-1-19-512-1024 | Protected, Authenticode. Third-party signed binaries. |
S-1-19-512-2048 | Protected, App. Peios-distributed applications. |
S-1-19-512-4096 | Protected, Peios. Core Peios components. |
S-1-19-512-8192 | Protected, PeiosTcb. Trusted computing base. |
Confinement and capability SIDs (S-1-15) #
These are used by Confinement to label sandboxed applications and the capabilities they have been granted.
Confinement domains #
| SID | Name |
|---|---|
S-1-15-2-1 | ALL_APPLICATION_PACKAGES — matches every confined application in normal confinement mode. |
S-1-15-2-2 | ALL_RESTRICTED_APPLICATION_PACKAGES — matches confined applications in both normal and strict modes. |
Well-known capabilities #
| SID | Capability |
|---|---|
S-1-15-3-1 | internetClient — outbound network. |
S-1-15-3-2 | internetClientServer — inbound and outbound network. |
S-1-15-3-3 | privateNetworkClientServer — LAN/private network. |
S-1-15-3-8 | enterpriseAuthentication — domain credential access. |
S-1-15-3-9 | sharedUserCertificates — certificate store access. |
S-1-15-3-10 | removableStorage — removable media access. |
Derived capability SIDs #
For application-defined capabilities beyond the well-known set, the SID is derived from the capability name:
| Pattern | Meaning |
|---|---|
S-1-15-3-h1-h2-h3-h4-h5-h6-h7-h8 | A derived capability SID. The eight values come from the SHA-256 of the capability name. The same name always produces the same SID. |
Special placeholder SIDs #
A few SIDs never appear as a real principal but are recognised by the access check.
| SID | Name | How it is used |
|---|---|---|
S-1-3-0 | Creator Owner | Substituted at inheritance time. |
S-1-3-1 | Creator Group | Substituted at inheritance time. |
S-1-3-4 | Owner Rights | Suppresses owner implicit rights when present in a DACL. |
S-1-5-10 | Principal Self | A placeholder for "the principal this object is about". The access check substitutes the caller-supplied self_sid parameter for this SID at evaluation time. Used in directory-style objects where an ACE says "the user can modify their own properties". |
These are the cases where a SID in an ACE does not literally mean "match a token whose user SID is this value". They are special-cased by the access check.
Which ones to use in practice #
The catalog above is comprehensive. In practice, day-to-day administrative work touches a much smaller set:
BUILTIN\AdministratorsandSYSTEMfor default protective DACLs.Authenticated Usersfor "any logged-in user should be able to read this".Everyoneonly when you actually mean "including unauthenticated network peers".Creator Ownerin inheritable ACEs that should follow the owner of a child object.Owner Rightswhen you want to suppress the owner's default grants on a sensitive object.- Specific user/group SIDs allocated by the directory (the
S-1-5-21-...-RIDform) for everyone else.
The remaining well-known SIDs — service SIDs, capability SIDs, integrity labels, PIP labels — show up in specialised contexts that have their own topics in these docs.
Where to go next #
For the attributes a token carries beyond fixed identity — the other input to attribute-based access rules — read Claims on a token.
For the exact numeric values in machine-readable form, see the Well-known SIDs reference.