Security Identifiers (SIDs) and how to understand them [Part 2]

Welcome to Part 2 of a planned four-part series!
Part 2: Security Identifiers (SIDs) and how to understand them (you’re reading this it now!)
Part 3: Converting Azure Object IDs in Azure into Security Identifiers (SIDs)
Part 4: Security Identifiers (SIDs) and User Rights Management
In Part 1 we discussed what Security Identifiers (SIDs) are; what they’re used for and how to query them.
Here in Part 2, we discuss how to dissect SIDs.

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-112-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. 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-121-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-13468038844-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-13468038844-1095076586-25383453712726767761
  • 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.
For a full list of Well-known SIDS, check out the documentation here.

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

We can already find the accounts registered on the Windows PC, in addition to their corresponding identifiers.

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.

What else redux? Oh yeah! Azure! 🤔

So now we have a fairly solid understanding of SIDs and how Windows uses them.
But I’m a cloud guy 🥱” you yawn. C’mon. I already wrote in Part 1 why it’s important for you to know this stuff. So Part 3 is going to focus on how to find Azure Object IDs and convert them to SIDs in order to make your life as a sysadmin easier. 

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.