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