In the good old days of Windows NT, the permission model used was static permissions. This model does not have inheritence and thus, most permissions are applied explicitly. In the old school, you are taught that permissions are always applied to DENY first, then ALLOW. Now, when we moved to NTFS 5.0 with Windows 2000/2003 with dynamic permissions (with inheritence model), we would assume that this would apply and in general, it would.
This assumption came back and haunted us this week, when we discovered that users in a group which have modify rights explicitly permissioned, could still access a folder despite have full deny access inherited on it. We could not believe our eyes when we saw it happened, not matter how many times we checked the permissions.
The issue with dynamic permission is that DENY access still has priority over ALLOW access, however, explicit permissions is given priority over inherited permissions!
This is mentioned in technet article: How Security Descriptors and Access Control Lists Work
Under the section “Order of ACEs in a DACL”
The preferred order of ACEs in a DACL is called the “canonical” order. For Windows 2000 and Windows Server 2003, the canonical order is the following:
All explicit ACEs are placed in a group before any inherited ACEs. Within the group of explicit ACEs, access-denied ACEs are placed before access-allowed ACEs. Inherited ACEs are placed in the order in which they are inherited. ACEs that are inherited from the child object’s parent come first, then ACEs inherited from the grandparent, and so on up the tree of objects.
… The canonical order ensures that an explicit access-denied ACE is enforced regardless of any explicit access-allowed ACE. This means that the object’s owner can define permissions that allow access to a group of users, such as Everyone, but deny access to a subset of the group, such as Marketing. If the object’s ACEs are in canonical order, the ACE that denies Marketing comes before the ACE that allows Everyone. During an access check, the operating system steps through the ACEs in the order in which they appear in the object’s DACL, so that the deny ACE is processed before the allow ACE. As a result, users who are members of the Marketing group are denied access. Everyone else is allowed access to the object.
The canonical order also ensures that all explicit ACEs are processed before any inherited ACE. This is consistent with the concept of discretionaryaccess control: access to a child object is at the discretion of the child’s owner, not the parent’s owner. The owner of a child object can define permissions directly on the child that modify the effects of inherited permissions. For example, suppose a parent object has an inheritable ACE that denies access to Marketing. And suppose the owner of a child object defines an explicit ACE that allows access to a subset of Marketing — let’s say a user named Bob. If the child object’s ACEs are in canonical order, the explicit ACE that allows Bob access comes before any inherited ACE, including the inherited ACE that denies access to Marketing. During an access check, the operating system reaches the ACE that allows Bob access before it gets to the ACE that denies access to Marketing. As a result, Bob is allowed access to the object even though he is a member of the Marketing group…
In summary, here is how permissions take priority:
- Explicit Deny
- Explicit Allow
- Inherited Deny
- Inherited Allow
Unfortunately, this is one of the least mentioned technical article and Internet search only reveals 3-4 articles talking about it.
Fortunately, most firms don’t have this problem because most permissioning models applied are those with ALLOW access only. Users who don’t need access to a folder will not get access, simply as that. The problem only comes when stringent rules comes about like an audit or compliance requirement to ensure that one business group does not have accidental access to another business group and DENY access needs to be applied.
I hope this article will increase the profile of the inheritence model adopted by Windows 2000/2003 and help some administrators steer out of trouble.
Salt * Wet * Bytes 