SID Structure - What do these numbers all mean? 😣
SIDs generally use the following pattern:
(SID)-(revision level)-(identifier-authority)-(subauthority1)-(subauthority2)-(etc)
This results in a very long number that at first glance doesn't seem to make a lot of sense... So let's break it up and make it a bit easier to understand, shall we? There are small differences depending on the identifier authority, so I've included three examples:
SIDs always start with S-1. S standing for SID and 1 representing the revision level to date. Which has never been updated and so stays at 1. I'm sure Microsoft is just "future proofing" this 😉
- Azure: S-1-12-1-3468038844-1095076586-2538345371-2726767761
- Active Directory: S-1-5-21-1004336348-1177238915-682003330-512
- Local: S-1-5-32-1045337234-12924708993-5683276719-19000
The Identifier authority value is the beginning of a 48-bit string that identifies the authority (the computer or network) that created the SID. 5 being the NT Authority and 12 being Azure AD. The identifier authority is split into a further two parts; the domain identifier and sub-authorities:
- Azure: S-1-12-1-3468038844-1095076586-2538345371-2726767761
- Active Directory: S-1-5-21-1004336348-1177238915-682003330-512
- Local: S-1-5-32-1045337234-12924708993-5683276719-19000
The first part of the domain identifier which shows in what domain the SIDs were created in i.e.
- Azure: S-1-12-1-3468038844-1095076586-2538345371-2726767761
- Active Directory: S-1-5-21-1004336348-1177238915-682003330-512
- Local: S-1-5-32-1045337234-12924708993-5683276719-19000
- S-1-12-1 - AzureAD accounts
- S-1-5-21 - User (and domain joined) accounts
- S-1-5-32 - Builtin local groups
- Etc.
Moving on... the rest of the SID is broken down in sub-authorities starting with whether the user is standard, a guest, administrator, or part of some other group.
- Azure: S-1-12-1-3468038844-1095076586-2538345371-2726767761
- Active Directory: S-1-5-21-1004336348-1177238915-682003330-512
- Local: S-1-5-32-1045337234-12924708993-5683276719-19000
And finally the Relative ID (RID). In on-premise setups, the RID is issued by a domain controller with FSMO role RID Master.
- Azure: S-1-12-1-3468038844-1095076586-2538345371-2726767761
- Active Directory: S-1-5-21-1004336348-1177238915-682003330-512
- Local: S-1-5-32-1045337234-12924708993-5683276719-19000
We also have a category of "Well-known SIDs" that represent BUILTIN users and groups. For example:
- S-1-5-32-544 – Administrators group
- S-1-5-32-545 – Local Users
- S-1-5-32-555 – Remote Desktop Users group
- Etc.
What else? Oh yeah! The registry! 😄
As I wrote in Part 1 (and in other blog posts), I keep stressing how everything in Windows is essentially built on top of the registry. SIDs are no different. If you allow me to plagiarize myself, I wrote:
SIDs of Active Directory objects are stored in the ntds.dit database whereas local object SIDS in the local Security Account Manager (SAM) database in the HKEY_LOCAL_MACHINE\SAM\SAM registry key.
For obvious security reasons, you can't simply view the contents of the SAM key however it's not impossible to dump the contents and might be a fun write-up for a future post!
In fact, you can find the SIDs of a certain account, is from the system registry. By navigating to:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/CurrentVersion/ProfileList
Have a look at the screenshot above and compare the values to those in Part 1 and Part 2. Notice the similarities. It's having an interest in the workings of stuff like this that I've learned the most and I hope it will inspire you too.