Welcome to Part 1 of a planned four-part series!
Well, it grants permissions to files or folders. The same permissions affect and grants (or denies) access to system registry keys.
“But how does Windows know what permissions to grant?” You, my imaginary conversational partner, continue to ask.
Oh! You want the long answer! OK then.
“And why do I, an Azure cloud native, care?” Woah, woah. Slow down there. First we’ll go over what SIDs are, how they are used and why you (the cloud native) should care.
Windows uses an objects’ Security Identifier (SIDs) which are unique identifiers that represent created objects either locally or in an Active Directory domain i.e.
- Security Objects
So SIDs are used instead of “friendly names” (i.e. a username) to control access to resources e.g.
- Network shared folders
- Registry keys
- File system objects (NTFS permissions)
You can think of SIDs as Active Directory object attributes 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!
As an aside, if you try looking up a friendly name and instead can only find the SID, that means your Domain Controller can’t resolve the SID due to the corresponding object having been deleted. It’s like the opposite of the “It’s always DNS” meme i.e. its not the resolving the record that’s wrong, it’s the actual source of the record that’s missing.
How and Where to Find SIDs
While in an elevated CMD or Powershell prompt, here is what I tend to use
- whoami – which queries the domain
wmic useraccount get name,sid – if you just want the device level SIDs Get-WmiObject – if you just want the device level SIDs
- Get-CimInstance – if you just want the device level SIDs
Start by opening up an elevated CMD prompt:
The first query we’re going to try running is to find the current logged in domain user:
Once it has been executed, the system will show us the SID of the user running the command:
Why does Windows use SIDs rather than friendly names? And why you should too!
A common low-hanging fruit method for “enhancing” security through obfuscation is renaming BUILTIN administrator users and groups e.g. renaming Administrators to ImportantUsers. Or whatever. I’m not a huge fan of security through obfuscation as the actors you’re trying to make things harder for already know about stuff like this.
But this serves as a good example of my next point. Even if you rename a principal, the SID will stay the same. It is a constant that you can not alter or change without having to really, really want to put in the effort. And even then you’ll be limited to the underlying pattern. So rename away! Windows will still know what you’re trying to call!
But let’s say you’ve made a group policy that references the friendly name and not the SID. For example, granting local administrator device privileges to a particular security group. What then? Well, in this case your Domain Controller may not be able to resolve the friendly name because it doesn’t exist!
Also because of localization!
That’s right, my anglophile friends. As weird as it is (and trust me, it IS for me also!) some users prefer having localized versions of Windows installed which means things like friendly names are translated (read: “localized”) into their filthy non-ISO languages. Note: I do not speak on behalf of ISO standards. As filthy as they may be.
Take a look at this fresh Danish Windows VM I just spun up for this purpose. The standardly friendly named “Remote Desktop Users” group has been bastardized into “Brugere af Fjerneskrivbord“.