If you’re a Windows system administrator or involved in Windows security or permissions management in any way at your organization, I can pretty much guarantee you’ve had broken Windows permissions at one point or another. “Broken” can mean a lot of different things, of course, since there are a variety of ways NTFS permissions can break.
In a previous post about levels of data protection, I talked a bit about how even though permissions may be mechanically correct—they’re working as they should from an authentication point of view—they may be broken since they’re not providing proper authorization. If you’ve got a folder open to the Everyone group, for instance, you’ve got a folder whose permissions are probably considered broken. But authorization failures aren’t what I’m interested in for this post. Rather, let’s talk about when Windows folder permissions are mechanically broken, meaning that NTFS “inheritance” is not functioning correctly.
In general, a Windows folder can be in one of 3 inheritance states—the first is that it simply inherits all permissions from its parent, so its ACL is exactly the same as its parent folder. The second is that the folder inherits all entries from its parent, but it has additional permissions applied to it. Varonis calls these folders “unique.” In both of these cases permissions changes made on the parent will be applied to the child. The third state is when inheritance is broken, or turned off—Microsoft (and Varonis) call these folders “protected.” Folders that are protected do not inherit permissions from their parents, and changes made to the parent folder permissions will not affect its ACL. Typical Windows administration tools don’t provide a lot of visibility into which folders have inheritance turned off or unique permissions applied, and this is one of the main reasons organizations don’t often know that data is accessible by too many people.
What’s makes things more difficult is that sometimes inheritance can be broken. Either the child folder has not properly inherited permissions that it should have (so an Access Control Entry (ACE) is missing from the ACL) or it is inheriting permissions that are not applied to the parent (it has an extra ACE on its ACL). Either way, mayhem occurs—IT thinks folders are restricted when they’re not, or thinks they’re accessible when they’re not. When mayhem does occur, to find and fix the culprit means analyzing every ACL in the affected branch of the hierarchy.
Broken ACL’s can occur for several reasons. Some automated copy programs have been known to produce unexpected results. Home-grown scripts can also produce these issues. Another inconsistency can be caused when someone simply moves a file or folder from one folder on a volume to another folder on the same volume with different permissions. When a file or folder is moved intra-volume, it is really just being renamed in the file allocation table and its permissions do not change. When a file or folder is moved inter-volume (from one volume to another) it inherits the permissions of its new parent.
Thankfully, we now have the technology to find and fix these kinds of problems. Varonis DatAdvantage collects a complete map of Windows permissions along with the users and groups from Active Directory and can easily produce a report detailing everywhere a folder exists with a broken ACL or other inconsistent set of permissions. Now, this helps fix the mechanically broken permissions, but we still need to talk about permissions that are working like they’re supposed to but are still letting way too many people in. Stay tuned.
 (unless set to not propagate to all descendant folders)