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:

   S-1-5-21-3472219541-3377705288-1674522210-1005   full   allow   container_inherit+object_inherit
   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
   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
   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


   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
   Group: S-1-5-21-1041401143-703221828-2223641765-513
   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
   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:\.

, , , ,

13 Responses to Finding and Removing Orphaned SIDs in File Permissions, or: Busting the Ghosts Built Into Windows 7

  1. Ole Kristian September 21, 2012 at 08:53 #

    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?

    • Helge September 21, 2012 at 11:19 #

      Removing orphaned SIDs is for the orderly – I am not aware of any problems.

      • Andy Duncan February 9, 2018 at 18:24 #

        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!)

    • ceez March 17, 2016 at 22:05 #

      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.

  2. John May 29, 2013 at 14:30 #

    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.

  3. Malcolm September 21, 2013 at 19:15 #

    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 and 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?

  4. zoocey October 26, 2013 at 02:31 #

    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.

    • Helge Klein October 29, 2013 at 10:38 #

      Don’t worry about an object’s primary group. It’s not used, anyway.

  5. Frank December 22, 2013 at 15:39 #

    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,


    • Mark Rauen October 26, 2015 at 18:43 #

      Same here Frank! I want to know how to link them back to an account rather than remove them.

  6. David August 21, 2015 at 17:45 #

    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


    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

    • Mick December 8, 2017 at 10:37 #

      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.

  7. Vasili August 4, 2017 at 14:00 #

    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)

    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)

Leave a Reply