Windows SID Structure Explained

Windows never actually checks permissions against a username — every access control decision underneath the friendly names you see in the UI is made against a Security Identifier, a structured value that uniquely and permanently identifies a user, group, computer, or built-in role. This post covers what each part of a SID actually means, why that structure explains several genuinely confusing Windows behaviors, and how well-known SIDs fit into it.

Anatomy of a SID

S-1-5-21-3623811015-3361044348-30300820-1013
| |  |  \_____________________________/  |
S REV AUTH        DOMAIN IDENTIFIER      RID

S is a literal prefix marking the string as a SID. Revision is always 1 for every SID in current use — the format hasn't needed a revision bump since Windows NT. The identifier authority — almost always 5, meaning "NT Authority" — identifies the broad issuing authority. Everything after that is a variable-length sequence of sub-authorities, and the final one is specifically called the RID (Relative Identifier) — the part that's unique to one specific principal within everything the earlier components identify.

The domain identifier is randomly generated, once

For a domain account, the middle sub-authorities (three 32-bit values, shown above as 3623811015-3361044348-30300820) together form that specific domain's unique identifier, generated once when the domain was created and never changing afterward — not even if the domain is later renamed. Every account, group, and computer in that domain shares this exact prefix; only the final RID differs between them. This is exactly why a SID from one domain looks similar in shape but is numerically completely different from a SID in any other domain, including another domain in the same forest.

RIDs are never reused

The RID counter for a domain only ever increases — deleting an account doesn't free up its RID for reuse, and a newly created account (even one with the exact same username as a deleted one) always gets a brand-new RID. This explains a specific, genuinely surprising Windows behavior: deleting and recreating an account named jsmith does not restore any of the old account's permissions or group memberships, even though the username looks identical, because every permission grant was actually recorded against the old SID's RID, and the new account has a different one entirely. The display name was always just a label; the real identity was the number underneath it the whole time.

Well-known SIDs: fixed values that mean the same thing everywhere

Some SIDs aren't tied to any specific domain at all — they represent universal concepts Windows defines the same way on every installation:

S-1-1-0    Everyone
S-1-5-18   NT AUTHORITY\SYSTEM
S-1-5-19   NT AUTHORITY\LOCAL SERVICE
S-1-5-20   NT AUTHORITY\NETWORK SERVICE

Others are well-known specifically as a RID, meaningful only in combination with a particular kind of prefix. S-1-5-32-544 is always BUILTIN\Administrators — S-1-5-32 identifies the local BUILTIN authority, shared by every Windows installation, with RID 544 specifically meaning the built-in Administrators group within it. Domain-relative well-known RIDs work the same way but against a domain's own identifier instead: <domain SID>-512 is always that domain's Domain Admins group, -500 its built-in Administrator account, and -502 its krbtgt account (the special account Kerberos itself uses internally, and a frequent target in real-world Golden Ticket attacks specifically because compromising it gives an attacker the key material needed to forge tickets for the whole domain).

Why this matters beyond trivia

Recognizing SID structure has real practical value beyond satisfying curiosity: a security audit log entry showing a raw SID instead of a resolved name (common when a machine can't currently reach the domain controller that would resolve it) is still fully readable once you know what each segment means — you can tell at a glance whether it's referencing a well-known built-in role, a specific domain's Domain Admins group, or an ordinary user account, without needing the resolution to succeed first.

Where SIDs actually get checked: the security descriptor

Every securable object in Windows — a file, a registry key, an AD object — carries a security descriptor containing a DACL (Discretionary Access Control List), which is simply an ordered list of ACEs (Access Control Entries), each one pairing a SID with a specific permission grant or denial. When Windows evaluates whether an access attempt is allowed, it walks that list comparing the requester's SID (and the SIDs of every group in their token) against each ACE in order — which is the actual mechanism underneath every permission dialog Windows ever shows you, always operating on SIDs, with usernames resolved only for display.

SID history: carrying an old identity into a new domain

Migrating a user from one domain to another normally means they get an entirely new SID in the new domain — which would instantly break every permission grant tied to their old one, exactly like the delete-and-recreate scenario above. The sidHistory attribute solves this deliberately: a migration tool can add the user's old SID to their new account's sidHistory, and Windows includes both the current SID and every historical one in the access token, so existing permissions granted to the old SID keep working without needing to be reassigned. This is also a well-known attack technique when abused — injecting a high-privilege SID (like a Domain Admins SID) into an attacker-controlled account's sidHistory across a trust relationship, which is exactly why sidHistory is specifically checked and cleaned up during real-world incident response after a suspected domain compromise.

Common mistakes

• Assuming a recreated account inherits its old permissions. It gets a brand-new SID with a different RID; every prior grant was tied to the SID, not the name.
• Treating a bare RID number as meaningful on its own. 512 only means Domain Admins in the specific context of a domain SID prefix — the same number elsewhere means nothing special.
• Confusing a local machine's SID with its domain's SID. A domain-joined computer has both, and they identify completely separate scopes of accounts and groups.

FAQ

Try it yourself

SID Decoder breaks down any SID into its components and recognizes well-known SIDs and RIDs, entirely in your browser.