Find ACL's that don't match parent with AccessEnum

When data begins its life, the permissions are invariably set at one of the top two or three levels, Some examples of some types of data you wouldn’t want everyone to get their hands on in a given company might be…

X:\Payroll\Cost Centre 1\Salaries

X:\Human_Resources\Cost Centre 2\Disciplinaries

X:\Pensions\Cost Centre 3\Compulsory Redundancy Quotes

All users would have to have access to the top level share, then all users might still have access to the Human Resources, Payroll and Pensions folders too. There may or may not be a cost centre folder to aid the business in understanding what parts of what department are consuming the most storage space (for internal billing), then there will be the “parent” folders (top level in terms of the point where specific permissions are set) whereby only certain individuals in a global group will have access. ABE (Access Based Enumeration) might be enabled also, preventing users who don’t have access to certain folders from even seeing that the folder exists in the first place.

For the purposes of data migration and reporting, the IT department should have some kind of data admins global group that has full control from the top, all the way down. Backup admins will also need modify access in order to perform file recoveries back to their original locations.

Over time, chunks of data get moved about as a result of departmental “tidy ups” and restructuring. The effect this has on permissions is that when data is “copied” it inherits the security of the parent folders on the destination side, however when it is “moved” it takes its permissions with it – sort of. I say “sort-of” because although it takes the security ACE’s with it, it also takes the attribute that says those ACE’s were originally inherited from the parent.

I say “sort-of” because although it takes the security ACE’s with it, it also takes the attribute that says those ACE’s were originally inherited from the parent. And therein lies a problem for subsequent data migrations.

The effect this has, is to cause the folders on the migrated side (where a copy operation has been used) to subsequently re-inherit their permissions from their new parent. Only non inherited permissions and inheritance attributes are ever copied, so these permissions that were once inherited but can no longer be inherited are likened to “ghosts” and are lost during any kind of copy operation (data migration operation using emcopy/robocopy or some other method).

I’d like to use “orphans” to describe these children with no matching parent permissions but the term is already taken to describe SIDs in ACEs that no longer resolve to a group in AD (occurs when a folder is secured then the group subsequently deleted), so I’ve come up with “ghosts” to describe them. I can’t use “zombies” as that is taken to refer to a child process on a UNIX system that has completed execution but remains in the process table so until its parent process can read its exit status. “Ghosts” is quite apt as they are not tangible and vanish when you migrate the data.

Technically, the copy operation is correcting anomalies but in the real world, that means loss of access, or worse, open access, depending on the nature of the change of permissions on the new parent.

The best way to deal with these ghosts is at source, but you need to know about them first, in order to deal with them. Sysinternals accessenum GUI tool is a neat way to scan filesystems looking for children where the security differs from that of its parent. Be sure to set the options accordingly.