A customer had a file share, and they couldn’t figure out who has access to some of the files. They pulled the access control list (ACL), extracted the security IDs (SIDs), converted them from binary to string form, and the result was S-1-5-21-2127521184-1604012920-1887927527-72713. “Why didn’t the conversion work?”
This is a rather confusing question, because the conversion did work. You have the answer: It’s S-1-5-21-2127521184-1604012920-1887927527-72713.
After some back-and-forth we learned that what the customer really meant was “How can we take this SID and convert it to something semantically meaningful to humans, like a person’s name?”¹
Programmatically, you can use LsaLookupSids2 to ask the local system to find a friendly name for a SID. It will consult its local account database, the domain’s account database, and maybe some other stuff. But sometimes it just shrugs its shoulders and says, “Sorry, I can’t come up with a better name for this one.”
The customer was confused by the possibility of a SID with no known name. How can the security system work if it doesn’t know who a SID represents?
The security system doesn’t care who a SID represents. When somebody tries to access a resource, it looks for matches between that person’s SIDs and the SIDs in the ACL, and follows the instructions associated with those matches. For example, there may be an access control entry (ACE) that says “Allow S-1-5-21-2127521184-1604012920-1887927527-72713 to have read-only access.” The security system doesn’t know or care who S-1-5-21-2127521184-1604012920-1887927527-72713 is.
By analogy, suppose your IT department locks down your phone by pushing a list of phone numbers from whom it will accept calls. The phone doesn’t know the names of the callers, but it doesn’t need to know. It just takes every incoming phone call and sees if the number is on the “Allow” list. (This also avoids problems if somebody calls who happens to have the same name as a person on your allow list. Since the phone number doesn’t match, the call is not let through.) As a courtesy, your phone tries to find a name for the incoming call by looking in the phone’s contacts or maybe by contacting a service. But that is best effort, and sometimes you just get “Unknown caller”. Your phone doesn’t know who they are, but the phone doesn’t need to know who they are in order to make a block/allow decision.
You don’t know who this 555-1212 number is, but it’s on your Allow list. And you don’t know who this S-1-5-21-2127521184-1604012920-1887927527-72713 SID is, but it’s there on the file’s Allow list.
The customer said that they were using the Advanced Security Settings property sheet to look up the SIDs. That property sheet already uses LsaLookupSids2 to look up friendly names for every SID, if known. If something shows up in S-... format, then it means that the system couldn’t find a friendly name.
At this point, you need to follow the money backward. If you want to know who this 555-1212 number is, you can ask your IT administrator, since they are the ones who added that number to the Allow list. If you want to know who this S-1-5-21-2127521184-1604012920-1887927527-72713 SID is, you can ask the file share owner or the file owner who it is. Presumably whoever put it on the access control list knows who it is. Otherwise, why would they have added it?
¹ It’s not clear to me how they expected the manual algorithm to produce something semantically meaningful, since the manual algorithm consists of counting things and inserting dashes. Nowhere in the algorithm does a number like “72713” turn into a name like “Chris”.
We also have to remember that an SID may not even represent a user. Or a group.
It can be a "virtual" user, or a "virtual" group; an SID that is based on:
- the hash of the name of a scheduled task
- the hash of the name of a service
- the hash of the name of an application pool (AppPool) in IIS
In which case you'll never find a user account, because there is none.
I had to write a tool to translate all sorts of SID to some readable representation (a best-effort translation, of course), and these SIDs were obviously a pain point. My solution was to just enumerate all the relevant tasks/services/etc. and see if one matches the hash. But of course, there’s no guarantee one will.
In some cases this can happen even with local accounts. I have seen it on my computers, moving a drive from one computer to another. The files and directories show SSIDs that I do know they are mine. But, as they were assigned in a different computer, they aren’t in the local account database and don’t show names. It may happen with deleted local accounts too, but I haven’t tested it.
Yes, local accounts are created with a SID that is unique to the machine it was created on. Moving such drives to other machines would “invalidate” any local account that isn’t a well known SID.
What is really frustrating about the lack of mapping is when the account is removed. It is good security practice to remove user accounts when the user is no longer working. It is also good practice to keep your ACLs cleaned up. Unfortunately Windows requires that we do this mapping manually.
Let's ignore for a minute the fact that you should be using a group instead of a user for permissions. You have user X...
You want to access the details? Do not delete the user. Do not turn the pointer into a dangling one.
It is technically very difficult or impossible to remove deleted SSIDs from ACLs, and it could cause problems with auditing. Think about a multi-Terabyte drive with hundreds of thousands of directories and millions of files. Deleting an account would involve a transverse all the online partitions, fixing all affected ACLs. That would take tens of minutes or even several hours in slow drives or the filesystem is being accessed by other processes. And in the...
Another reason why I liked Novell's Directory Services and file system - it does have ACLs, but they always inherit, so you don't need to store a copy on every single object, just one at the top of the tree. (You can still change the rights at a point in the tree by specifying new ACL(s) for the entities whose rights have changed, plus you can disallow inheritance of some or all rights if you...
This is how the VAX/VMS RMS permissions worked. I was absolutely flabbergasted that there were any permissions systems that didn’t automatically work that way.
Does NDS and/or VAX/VMS support hard links? If a single file is in multiple directories that each have conflicting inheritable ACEs, which directory wins?
This is one reason why NT only inherits permissions at file creation time and why later changes to inheritable permissions need to propagate to child objects.
Agreed with word merchant.
The VAX way (I'm guessing) optimized for data storage size, in times when storage was expensive.
NTFS optimized for access check time.
The VAX way, you store less data on the disk, and it's faster to change inherited permissions. However, when you need to perform an access check, I'd imagine you wind up potentially needing to check in multiple areas to grab the data needed to perform the check.
The NTFS way, you only...
Does that mean VAX/VMS has to search towards its root directory (maybe not that far) every time a file’s ACL is needed? Presumably NTFS does not need to do this.
Windows supports hard links, meaning the same file node can appear under multiple different paths, and given a file node there generally isn't a way to say canonically "what's the path to this file". And if what this blog says is true (which it is on Linux, for both regular file permissions and SELinux contexts), ACLs apply to file nodes, not individual links, meaning there generally isn't a canonical parent directory from which a file...
>> It is technically very difficult or impossible to remove deleted SSIDs from ACLs
I never asked for Windows to clean up all the permissions of a SID. All I said was that when we look at the permissions for an object AND it has a SID for an account that is no longer valid then without a manual mapping there is no way to know what that account originally was. It would be nice if...
It does exist; there’s just not any APIs that get at it.
It is so much a thing the resurrect AD object tool didn’t have to ask for both name and SID but just one or the other and it would find the record and resurrect it.