FFoundationalActive Directory
Security Identifiers and Security Principals
Every Windows permission check ultimately compares security identifiers, not names. This lesson explains what security principals are, how SIDs uniquely and permanently identify them, and why well-known SIDs and the RID structure let you resolve a principal's real role even after it has been renamed.
Why it matters
Every permission decision in Active Directory ultimately resolves to a comparison between two identifiers, not two names. Before you can explain why an access list grants or denies an action, you need to understand who or what is actually being checked. Security principals and the SIDs that identify them are that foundation. Skip this layer and a statement like "this group can reset that account's password" stays abstract, because you cannot say with confidence who the account actually is, whether that identity is durable, or why an attacker would bother chasing it. SIDs matter well beyond permissions too: they underpin how Windows tracks identity across renames, how testers distinguish real administrators from renamed decoys, and how techniques like SID history abuse can quietly grant privileges that group membership alone would never reveal.
Key Concepts
- Security principal — any entity Windows can authenticate and grant rights to: user accounts, computer accounts, service accounts, and security groups, not just interactive human logins
- Security Identifier (SID) — a unique value Windows assigns to every security principal at creation; it never changes for that principal's lifetime and is never reused, even after the principal is deleted
- RID (Relative Identifier) — the final component of a SID; a number unique within the issuing authority (typically a domain) that distinguishes one principal from every other principal that authority has created
- Well-known SID — a SID that identifies the same principal on every Windows installation because the operating system itself is the issuing authority, for example S-1-1-0 for Everyone or S-1-5-18 for Local System
- Well-known RID — a RID value with a fixed meaning inside any domain, for example 500 for the built-in Administrator or 512 for Domain Admins; the domain-specific prefix in front of it still makes the full SID unique per environment
- sIDHistory attribute — an attribute that lets a principal carry additional SIDs beyond its own, granting the access associated with a prior identity; the mechanism that SID-history-based attacks abuse
Theory
Core idea
A security principal is any entity that Windows can authenticate and hold accountable. That includes human user accounts, but it also includes security groups, computer accounts, and service accounts. Anything the operating system can identify individually is a principal, not just people who log in interactively.
Windows does not track principals by name internally. Every principal is assigned a security identifier (SID), a value that never changes for the life of that principal and is never reused, even after the principal is deleted. A SID looks like S-1-5-21-2753864161-1776656122-2845895175-1001. The structure is not arbitrary: the leading segments identify the issuing authority (in this example, a specific domain), and the final segment is the relative identifier, or RID, the number that is unique within that authority. The RID is what distinguishes one principal from every other principal the same authority has created.
Some SIDs are well-known: they represent the same principal on every Windows installation regardless of domain, because the operating system itself, not a specific domain, is the issuing authority. S-1-1-0 is always Everyone. S-1-5-18 is always the Local System account. Other identifiers are well-known only in their RID: inside any domain, RID 500 is always the built-in Administrator account, and RID 512 is always Domain Admins, but the domain-identifier portion in front of that RID differs from domain to domain, so the full SID stays unique to each environment.
Mental model
Think of a SID the way you would think of a national identification number rather than a legal name. A person can legally change their name, but their ID number stays fixed, and every record that actually matters is filed against the number, not the name. Rename a Windows user account and the SID underneath it does not move: every permission, every group membership, every audit log entry still points to the same unchanging identifier.
This is also why deleting an account and recreating one with the identical username restores nothing. The new account gets a fresh SID from the operating system, so despite sharing a name with the old one, it is a completely different principal as far as Windows is concerned. None of the old account's group memberships or permissions carry over, because none of them were ever attached to the name in the first place.
The domain-identifier-plus-RID structure works like a company ID scheme: the first part of the number identifies which office issued it, the domain, and the second part identifies the specific employee within that office, the RID. Two different offices can both issue employee number 1001 without any conflict, because the office code in front makes each full ID globally unique. That is exactly how two different AD domains can each have their own Domain Admins group at RID 512 without colliding: the domain SID that prefixes each one keeps them distinct.
Common misunderstandings
- Treating a SID as equivalent to a username. A username is a label a human reads. The SID is what Windows actually checks. Two accounts can share a display name at different points in time and still be entirely different principals, because their SIDs differ.
- Assuming only user accounts are security principals. Computer accounts, service accounts, and security groups are all principals with their own SIDs. A computer joining a domain gets an account and a SID just like a user does, which is part of why computer accounts can hold group memberships and become targets in their own right.
- Confusing a well-known SID with a well-known RID.
S-1-1-0is identical on every Windows machine because the operating system itself issues it. RID 500 is well-known only as a number: the domain prefix in front of it differs in every domain, so the full SID for "the Administrator account" is still unique to each environment even though the RID is predictable. - Believing that renaming an account changes its identity. Renaming the built-in Administrator account is a common hardening step, but it does nothing to the SID, and RID 500 still marks it as the true administrator. Anyone resolving accounts by SID rather than display name can find it regardless of what it has been renamed to.
Real-world context
During enumeration, experienced testers do not trust display names, because defenders routinely rename the built-in Administrator account as a hardening step. Instead they resolve accounts by SID and look specifically for RID 500, since that number identifies the real built-in administrator no matter what label it currently carries. The same logic applies to Domain Admins at RID 512: a group's display name can be changed, but the well-known RID still gives away its actual role.
A quick way to see this structure directly is the whoami /user command:
C:\>whoami /user
USER INFORMATION
----------------
User Name SID
========================= ============================================
corp\jsmith S-1-5-21-2753864161-1776656122-2845895175-1105The domain portion, S-1-5-21-2753864161-1776656122-2845895175, is shared by every principal in that domain. Only the trailing RID, 1105 here, changes from one account to the next.
This layer also matters when you write up findings for a client. Saying "the attacker reached Domain Admins" only holds up under scrutiny if you can tie it back to the actual SID a tool captured, since display names can be renamed, duplicated across domains, or simply misleading. The SID is the fact that does not move once an account has been created. It is also why the sIDHistory attribute is treated as sensitive: it lets an account carry additional SIDs beyond its own, effectively granting it the access of a prior identity, which is exactly what SID-history-based attacks abuse to smuggle in privileges that a plain look at group membership would never expose.
Communication
Interview answer
A security principal is anything Windows can authenticate and grant rights to: users, groups, computers, and service accounts. Windows never actually tracks identity by name, it tracks identity by SID, a unique value assigned when the principal is created and never reused afterward. A SID's structure encodes an issuing authority followed by a relative identifier, or RID, that is unique within that authority, which is why domain SID plus RID 500 always points to the real built-in Administrator regardless of what it has been renamed to.
Some SIDs, like S-1-1-0 for Everyone, are well-known everywhere because the operating system itself issues them. Others are well-known only as RIDs, like 512 for Domain Admins, because the domain-specific prefix still varies per environment. That distinction matters practically: it is what lets you resolve a renamed admin account during enumeration, and it is why the sIDHistory attribute is dangerous, since it lets one account inherit the SID, and therefore the access, of an entirely different principal.
Follow-up questions
- Why does renaming the built-in Administrator account not actually change its security identity?
- If two accounts in different domains both sit at RID 512, why are they not the same principal?
- What happens to an account's existing permissions if it is deleted and a new account is created with the same username?
- Why is a computer account considered a security principal, and what does that make possible?
- How does the sIDHistory attribute let an account carry more access than its group memberships alone would suggest?
