Pitfalls in Reporting Delegated Access in Active Directory

Most IT administrators encounter a simple but very serious pitfall when trying to report delegated access in Active Directory –

They often mistakenly assume that a user / group effectively has the permissions displayed in an Active Directory ACL, and proceed to generate and provide factually inaccurate reports when documenting administrative access delegations.

In reality however, entitled access differs markedly from displayed permissions, because in order to correctly (i.e. accurately) determine whether or not a user is effectively entitled to a specific permission on an Active Directory object, one needs to simulate a real access check. The following example illustrates this subtle but vital difference by analyzing the ACL above.

Example

Consider the ACL shown above, and let's assume that we wish to determine who all can reset the CEO's password –

1. ACE #5 in the ACL allows the Reset Password extended right to the Help Desk Tier I security group.
   
   Most IT administrators would simply list the group's membership and assume that all its members have the right to reset the CEO's password. Many might even stop the verification process here and assume this to be reliable data.
   
   This however is an inaccurate and thus factually wrong determination. To understand why it is so, see point 2.
   
   
2. ACE #2 denies the Reset Password extended right to the Outsourced Password Reset Admins security group.
   
   This ACE has the effect of denying all the members of this group the ability to reset the CEO's password. Effectively, any user that belongs to the Help Desk Tier I group that also belongs to the Outsourced Password Reset Admins group, will NOT be able to reset the CEO's password. This fact is only ascertained when ACE #2 is also analyzed.
   
   
3. Similarly, there could be an ACE in the ACL that grants some security group Full Control permissions. In that event, all members of the group would also be entitled to resetting the CEO's password since they have full control on the object.
   
   This is why IT admins need to take every ACE in the ACL into account to accurately determine who really has what access on the object, and do so in a manner identical to how Active Directory performs a real access check.
   
   
4. Speaking of pitfalls, note that the Deny ACE above would only override the Allow ACE if the Deny ACE were an explicit ACE (as opposed to an inherited ACE.) Additionally, it would also have to be one that Applies To this class of object.
   
   This is just one of many technical aspects that impacts the outcome of an IT administrators attempts to report access delegated on an Active Directory object. IT admins must consider all such aspects when reporting delegated access.

Please do NOT rely simply on looking at ACEs in ACLs and errantly making incorrect assumptions to arrive at false conclusions when reporting delegated access. Doing so exposes you to serious risk and leaves you vulnerable to compromise.