Finding and Removing Orphaned SIDs in File Permissions, or: Busting the Ghosts Built Into Windows 7
Due to a lack of visibility permission cleanup is performed far less frequently than it could, and probably should. As a result, ghost ACEs (permissions from deleted accounts) linger in the dark corners of the file system, threatening the unsuspecting admin with the horrors of unresolvable SIDs.
One way to increase visibility is to replace Windows’ horrible ACL Editor (the non-resizable always-too-small window that pops up when you try to take a peek at a file’s permissions) with something nicer. Another way is for people who like to get their hands dirty on the command line: SetACL, the free permissions management tool, just got new capabilities that greatly facilitate the hunt for ghost ACEs.
Ghost Hunt
To have some fun while explaining how this works I am not going to do it on a file server you know nothing about but analyze a plain Windows 7 installation. Let’s see if we can find any ghosts in the default permissions!
The command we need is simple enough:
SetACL -on C:\ -ot file -actn list -lst oo:y;f:tab -rec cont
Issued from an elevated command prompt this instructs SetACL to read the permissions of every single folder on drive C: but print only those permissions where it finds SIDs that cannot be resolved to account names – in other words ghost ACEs. On my machine the resulting output looks like this:
C:\$Recycle.Bin\S-1-5-21-3472219541-3377705288-1674522210-1005
DACL(protected):
S-1-5-21-3472219541-3377705288-1674522210-1005 full allow container_inherit+object_inherit
C:\ProgramData\Microsoft\eHome\SharedSBE
DACL(not_protected+auto_inherited):
S-1-5-80-2913099195-3001839937-1914692661-1563395363-459793767 change+FILE_DELETE_CHILD allow no_inheritance
S-1-5-80-2913099195-3001839937-1914692661-1563395363-459793767 change+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only
C:\ProgramData\Microsoft\Network\Connections
DACL(protected+auto_inherited):
S-1-5-80-3906544942-1489856346-3706913989-164347954-1900376235 full allow no_inheritance
S-1-5-80-3906544942-1489856346-3706913989-164347954-1900376235 full allow container_inherit+object_inherit+inherit_only
C:\Users\Public\Recorded TV
DACL(not_protected+auto_inherited):
S-1-5-80-2913099195-3001839937-1914692661-1563395363-459793767 change+FILE_DELETE_CHILD allow no_inheritance
S-1-5-80-2913099195-3001839937-1914692661-1563395363-459793767 change+FILE_DELETE_CHILD allow container_inherit+object_inherit+inherit_only
The first entry is the recycle bin of a deleted user account, but the others? Two different SIDs from different domains that are unknown to my machine (which, by the way, has never been a domain member). Since these two SIDs are part of the permissions of directories managed by the operating system my guess is that some developer at Microsoft used internal SIDs in his code.
Our first experiment was already pretty rewarding, but what if we go a step further? In its default configuration SetACL processes only the DACL when listing permissions, but it is well capable of dealing with SACL, owner and even primary group, too. So let’s rerun the command but this time looking for ghost SIDs in the object owners and SACLs:
SetACL -on C:\ -ot file -actn list -lst oo:y;f:tab;w:o,s -rec cont
Output:
C:\$Recycle.Bin\S-1-5-21-3472219541-3377705288-1674522210-1005
Owner: S-1-5-21-3472219541-3377705288-1674522210-1005
Nothing much new here – the fact that the deleted user was the owner of his recycle bin directory does not come as a surprise. So let’s try something more obscure and scan each directory’s primary group (in case you do not know what that is: read this):
SetACL -on C:\ -ot file -actn list -lst oo:y;f:tab;w:g -rec cont
Wow, the output of that won’t stop. To keep this article from overflowing your browser I had to cut it off:
C:\Program Files\Common Files\Microsoft Shared\Triedit
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\Program Files\Common Files\SpeechEngines\Microsoft\TTS20\de-DE
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\Program Files\Microsoft Games\Chess\de-DE
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\Program Files\Microsoft Games\FreeCell\de-DE
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\ProgramData\Microsoft\Assistance\Client\1.0\de-DE
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\ProgramData\Microsoft\eHome
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\Accessories\Tablet PC
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\ProgramData\Microsoft\Windows NT\MSFax\VirtualInbox
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\Users\Default\AppData\Roaming\Media Center Programs
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\Users\Public\Recorded TV
Group: S-1-5-21-1041401143-703221828-2223641765-513
C:\Windows\assembly\GAC_32\AuditPolicyGPManagedStubs.Interop
Group: S-1-5-21-1041401143-703221828-2223641765-513
[...]
This SID is everywhere! While we cannot say which domain it is from (other than that it is probably internal to Microsoft), we notice that the RID is always similar – and quite well-known: 513 stands for Domain Users. Interestingly, running this command on Server 2008 R2 and a different Windows 7 computer yields similar results – but a different domain SID.
Busting the Ghosts
I would not recommend doing it for drive C:\
, but after searching your file server for ghost ACEs you probably want to remove them. SetACL has a command for that:
SetACL -on D:\ -ot file -actn delorphanedsids
That gets rid of any ACEs with orphaned SIDs on drive D:\
.
16 Comments
Thanks for another great article!
I have been cleaning up orphaned SIDs from my file server, because I like it clean and tidy. But other than that, why should we do it? Have you experienced any problems related to this?
Removing orphaned SIDs is for the orderly – I am not aware of any problems.
Having all kinds of issues as a result of it. File server is currently on its 3rd domain with 20 years of users and domain information including it’s prior membership in a Linux managed Microsoft domain. After relocating to new hardware and the new domain the old SID’s still wanted to be the owners and it was actually a struggle to get control of the files from the old SID’s. Every then and again the old SID’s will rear their ugly little heads and bite me on the ass again by denying access to a user or a group, or even System access. Thankfully I found your site and software as it is a problem solver for me at least! FYI, it has thrown a few errors out but I’ve managed to work around them. WIll do a complete restructure of the permissions this weekend on the file server.
Thanks for a great product and all I’ve used is the demo! (Will get a PO started for a purchase!)
Yes, if you don’t clean up your orphaned SIDs before using Robocopy from a data drive with deep folder structure (more than 255 chars long file paths or more than 260 chars long folders) the ACL copy will fail. Dell Secure Copy has an option to remove the orphaned SIDs during the copy so this is not a problem. Robocopy=free; Secure Copy=$$$. Just my 2 cents.
I found out the hard way that if you run this remotely, it will kill permissions assigned to local accounts. i.e. Administrators.
If, because ot the number of machines/shares/folders/etc. being processed you need to use a script, you MUST use psexec or some other way to run it from the target machine.
Now I need to find a way to restore the permissions.
I noticed something a bit odd about some of those SIDs.
They begin S-1-5-80- … a domain SID would start S-1-5-21-.
It turns out, after some searching, that SIDs beginning S-1-5-80 are in fact a new type of SID I’d never heard of: Service Specific SIDs.
See http://winzerofaqs.blogspot.co.uk/2009/04/unknown-sid-s-1-5-80-xxxxx.html and http://blogs.msdn.com/b/cjacks/archive/2008/08/29/what-is-the-trustedinstaller-entity-you-see-in-windows-vista.aspx?Redirected=true for more information on these.
Removing those S-1-5-80- SIDs could *really* muck things up; perhaps SetACL/SetACL Studio should find a way to resolve them back to known services and not consider them orphaned?
I admit SetACL is a little over my head but how would one remove/change in bulk orphaned directory primary groups. In my testing delorphanedsids did not do this.
Don’t worry about an object’s primary group. It’s not used, anyway.
Hello Helge (a.o),
Although I’m not to lazy to explore the options SetACL has, i would like to know if one can use it to change the orphaned Fileowner to an other valid SID.
Kind regards,
Frank
Same here Frank! I want to know how to link them back to an account rather than remove them.
Hello and thanks for the utility and this article.
Seems that in trying to migrate stuff from an XP machine to a Win10 machine, via backup/restore with Acronis, I have ended up with lots of files/folders that seem to be carrying security descriptors not appropriate to the new machine. They all have:
CREATOR OWNER with no permissions set at all
and
Account Unknown S-1-5-21-583907252-573735546-1417001333-1003 with no permissions set.
Try as I might, using your utility and suggested command line “SetACL -on D:\ -ot file -actn delorphanedsids” (these are all on drive D:) nothing seems to change. I am running this from an elevated command shell.
Any suggestions? Thanks
I’ve just done the same thing, XP to WIN10 migration. My transfer process was a bit different as I used Partition Wizard on the XP machine to copy my data partition to a spare disk which I then disconnected and plugged into the WIN10 machine where I again used PW to copy it to a new drive.
I ended up with the same “Account Unknown S-1-5-21- ….” entry in the ACLs for everything I had transferred but this account had Full access to all the files.
First I created a partition backup using PW so I could restore my data partition in case I screwed it up.
I tried using – actn delorphanedsids as you did but it didn’t remove the entries.
Then I read a bit more and found the following command which DID remove all the unwanted ACEs:
SetACL.exe -on B:\ -ot file -actn trustee -trst “n1:S-1-5-21-1060284298-343818398-839522115-1003;ta:remtrst” -rec cont_obj
I realise that these entreis do not do any harm and there is no need to remove them, but I like to keep things clean.
Helge (and others),
We have an issue removing orphan SID’s from our NAS Server (also on local Windows drive).
The issue that the current path have disabled inheritance but after running the setacl command to remove the orphan SID’s.
It will not only remove the id’s but also enable inheritance which is not wanted.
Any idea to untouch inheritance when removing orphan SID’s?
D:\Temp>icacls \\servername\share\folder1\folder2
\\servername\share\folder1\folder2 S-1-5-21-1326131322-1829978501-250757269-1224972:(I)(OI)(IO)(M)
S-1-5-21-1326131322-1829978501-250757269-1224972:(I)(CI)(M)
BUILTIN\Administrators:(I)(OI)(IO)(F)
BUILTIN\Administrators:(I)(CI)(F)
domain\DataAdmins:(I)(OI)(IO)(M)
domain\DataAdmins:(I)(CI)(M)
S-1-5-21-1326131322-1829978501-250757269-1224973:(I)(OI)(IO)(RX)
S-1-5-21-1326131322-1829978501-250757269-1224973:(I)(CI)(RX)
D:\Temp>setacl -on \\servername\share\folder1\folder2 -ot file -actn delorphanedsids -rec cont_obj
Processing ACL of:
Processing ACL of:
Processing ACL of:
Processing ACL of:
D:\Temp>icacls \\servername\share\folder1\folder2
\\servername\share\folder1\folder2 BUILTIN\Administrators:(I)(OI)(IO)(F)
BUILTIN\Administrators:(I)(CI)(F)
domain\folder1-group:(I)(OI)(IO)(RX)
domain\folder1-group:(I)(CI)(RX)
domain\DataAdmins:(I)(OI)(IO)(M)
domain\DataAdmins:(I)(CI)(M)
All I can say is be SUPER-CAREFUL using this methodology! Many times, a “Ghost SID” will be just a SID from a remote domain; and so, from one context, it may appear to be a “Ghost SID” and yet, from the context of the “remote domain,” for example, it would appear as normal access/ownership; for example, with “domain trusts” between 2 domains. Once you remove what you thought was just a Ghost SID, then you’ve impacted access from that remote domain to the local resources in your current domain. If done carefully, it should not be an issue; and cross-domain Ghost SIDs should be rare; but, having said that, if you do deal with multiple domains and related trusts; please use utmost caution with tools like SetACL.
Thanks Helge for the great article!
I did a:
SetACL -on [drive letter]:\ -ot file -actn delorphanedsids
…on my C, D, and F drives.
Afterwards, if I now do a:
SetACL -on [drive letter]:\ -ot file -actn list -lst oo:y;f:tab -rec cont
…SetACL still lists lots of files on the different drives. Is that an outcome to be expected?
Memo to me and all who have looked for it.
-rec cont
ensures that the clean-up is done in all folders of driveD:\
.or as in my case on a share:
Thank you for the tool.
PS: It would be nice if the log files were emptied with every call or e.g. max. 14MB in size (rolling log file).