How Active Directory Security Permissions Control Privileged Access

Folks,

Hello. I hope this finds you doing well. This post is Day-5 of Active Directory Security for Cyber Security Experts.


In today's post, I wanted to make the essence of Active Directory Security super simple for everyone to understand, because this is necessary before we dive into analyzing the many specific examples in the accompanying demo VM.



Active Directory Security, Distilled

Perhaps the best way to understand Active Directory is by distilling it down to ten simple points -

1. Every thing inside Active Directory is an Active Directory object


2. Every object in Active Directory is protected by an access control list (ACL)
3. Every ACL protecting every object contains zero or more access control entries (ACEs)
4. Every ACE allows or denies one or more security permissions for a specific security principal (SP)
5. Every security principal (account, group, well-known/F SP) is uniquely identified by its security identifier (SID)
6. Every account has an access token that contains its SID and the SIDs of all security groups* to which it belongs


7. Every security permission specified in an ACE is either explicit (set on the object) or inherited (from the parent)
8. Every security permission is either a standard Active Directory permission, an extended right or a validate write


9. Every ACE in the ACL is placed in accordance with a precedence order that governs how ACEs impact the resulting (i.e. effective) access for a user, which is:  Explicit Deny > Explicit Allow > Inherited Deny > Inherited Allow


10. When a user requests access to an AD object, the system performs an access check that examines the ACEs in the object's ACL to determine a) whether or not any SID in the requestor's access token is denied any of the requested access in any of the ACEs in the ACL, and b) whether or not one or more ACEs in the ACL allow all of the requested access rights, and the outcome of this access check governs whether or not the requested access is granted.
    
    Consequently, the actual (i.e. effective) access that a user has on an AD object is determined by the impact of all ACEs in its ACL that allow or deny some form of access for the user, or for any group* to which the user belongs.

Active Directory Security Permissions

If everything in Active Directory is an AD object protected by an ACL in which lie ACEs that grant various Active Directory security permissions, then we must possess a very good understanding of these Active Directory security permissions.

There are thirteen types of Active Directory Security Permissions -

1. Read Control (RC) - These permissions control who can read security permissions specified in AD object ACLs.


2. List Child (LC) - These permissions control who can view the child objects of a specific object in AD.


3. List Object (LO) - These permissions only come into play in a special mode in Active Directory called the List Object mode, and in that mode they provide more granular control on who can view individual child objects of an object.


4. Read Property (RP) - These permissions control who can read the properties of an AD object. The Object Type field can be used to specify that they only control read access to a specific property (or a property set) on the object.


5. Write Property (WP) - These permissions control who can modify the properties of an object. The Object Type field can be used to specify that they only control write access to a specific property (or a property set) on the object.


6. Create Child (CC) - These permissions control who can create an object under an object in AD. The Object Type field can be used to specify that they only control the creation of objects of a specified object class e.g. user.


7. Standard Delete (SD) - These permissions controls who can delete an object via a standard delete operation.


8. Delete Child (DC) - These permissions control who can delete child objects of an object. The Object Type field can be used to specify that they only control the deletion of objects of a specified object class e.g. user.


9. Delete Tree (DT) - These permissions control who can delete a tree of objects in AD via a delete-tree operation.


10. Modify Permissions (WD) - These permissions control who can modify permissions protecting an AD object


11. Modify Owner (WO) - These permissions* control who can modify the owner of an AD object


12. Extended Right (CR) - These permissions control who can enact special operations in AD. The Object Type field can be used to specify that they only control a specific special operation on an object (e.g. Reset Password etc.)


13. Validated Write (SW) - These permissions control who can enact certain special writes (that require validation) on certain AD objects. The Object Type field can be used to specify that they only control a specific validated write on an object.


SDDL: The two-letter abbreviations (e.g. RC, LC, LO, RP, WP, CC, SD, DC, DT, WD, WO, CR and SW) that follow the names of these various permissions are the SDDL mnemonics used to specify these permissions.

The above is a simplified explanation of AD security permissions. For details, please refer to Microsoft's documentation.

Once you have a good understanding of these thirteen Active Directory Security Permissions and how they work, it is easy and straightforward to understand how they impact and govern exactly who has what privileged access in Active Directory.



How Active Directory Security Permissions
Control Privileged Access in Active Directory

In light of the above, every privileged action that can be enacted in Active Directory boils down to a user requesting, and the resulting access check permitting, the ability to perform a simple modify operation on an Active Directory object.

Here are the Top-10 administrative (i.e. privileged) tasks in Active Directory AND the modify access they involve -

1. Create a user account - Requires "Create Child User-object" effective permissions on target object


2. Enable an account - Requires "Write Property userAccountControl attribute" effective permissions on user object


3. Reset an account's password - Requires "Extended Right Reset-password" effective permissions on user object


4. Change a group membership - Requires "Write Property member attribute" effective permissions on group object


5. Change a user's membership - Requires "Write Property member attribute" effective permissions on group object


6. Modify an object's ACL - Requires "Modify Permissions" effective permissions on target object


7. Link a GPO to an OU - Requires "Write Property gpLink attribute" effective permissions on OU object


8. Change a computer's DNS name: Requires "Validated Write Change DNS Host Name" on computer object


9. Delete an Organizational Unit (OU) - Requires "Standard-Delete" effective permissions on OU object, or "Delete-Child" effective permissions on parent* object, or "Delete Tree" effective permissions on any ancestor object


10. Replicate secrets from domain - Requires two extended rights, "Extended Right Get Replication Changes" and "Extended Right Get Replication Changes All" effective permissions on the domain root object

In short, enacting a privileged action in Active Directory requires a specific type of access on specific target AD objects, and anyone who has sufficient required effective permissions on these target objects can enact these privileged actions.

Thus, once you know exactly which security permissions entitle a user to a specific privileged action in AD, you can find out exactly who was what privileged access where and how in AD, by determining who has those effective permissions.



Top-10 Examples of Privileged Access in Active Directory

Here are ten simple, common examples of administrative tasks that require/involve privileged access in Active Directory, and as we have seen above, it is Active Directory security permissions that control exactly who can enact these tasks -

1. Create a new domain user account for legitimate or nefarious use


2. Delete an existing account or group, or an OU containing thousands of accounts and groups


3. Enable a currently disabled domain user account, or unexpired an expired domain user account


4. Reset a domain user account's password, such as that of the CEO or the default Administrator account


5. Modify a domain security group's membership, such as that of the all-powerful Domain Admins security group


6. Modify security permissions on an AD object, such as on the domain root, an OU or the AdminSDHolder object


7. Link a group policy (GPO) to an OU, for legitimate or nefarious (e.g. unleashing ransomware domain-wide) use


8. Modify a domain-joined computer's account in AD, such as by setting it to be Trusted for Unconstrained Delegation


9. Modify the keywords associated with a critical service connection point, such as one used to integrate with Azure.


10.  Replicate secrets from Active Directory (the enactment of which is almost always for nefarious reasons)

Thus, as you can, virtually every privileged action that somone could enact in any Active Directory deployment worldwide, is controlled and governed by the various Active Directory security permissions that reside in Active Directory object ACLs.



Specifically, if you connect the three dots above (i.e. the three aspects of AD Security described above), then you'll know that ALL privileged access in Active Directory is governed by "who has what effective permissions in Active Directory" because multiple ACEs in an object's ACL could impact whether or not the access requested by a user is granted.




Summary

That'll be all for today. Today, I just wanted to share with you three essential technical aspects of Active Directory Security that today govern and control exactly who has what privileged access at 85% of all organizations across the world today.

Speaking of which, did you know that for years IT professionals at organizations have errantly believed that to find out who has what privileged access in Active Directory, they just need to analyze permissions in Active Directory, whereas in reality, it is not "who has what permissions in Active Directory" but in fact "who has what effective permissions in Active Directory" that governs who has what privileged access in Active Directory.

Consequently, today most organizations do not even possess the means to audit effective permissions in Active Directory; they only possess the means (tools) to find out "who has what permissions" which is vastly insufficient and mostly futile, and as a result, most of them have no idea as to exactly who has what privileged access in their Active Directory today.



That's it for now. There's only one more theory lesson remaining before we can dive into over a dozen exciting examples that exist in the accompanying demo VM, and in the next lesson i.e. Day 6's lesson, I will cover that theory lesson by shedding light into the most important technical aspect of Active Security - Active Directory Effective Permissions.


Best wishes,
Sanjay.



PS: Answers to the 3 simple questions I had asked in my previous post -

• Number of ACEs domain-wide: 177396 (excluding objects in the System container.)
• Number of members in Domain Admins security group: 13
• Number of ACEs that directly/indirectly impact Write Property Member in ACL of the Domain Admins group: 9*
• Amount of time it took me to make these determinations: Less than 1 minute (each.)