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:\.