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.)

Day 4 - Active Directory Security Permissions, Tooling AND a Challenge

Folks,

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


TODAY, we'll begin by 1) re-visiting a simple fact, 2) putting your arsenal together and 3) YOUR first challenge.





Active Directory Security Permissions - The Keys to Every Door in the Kingdom

If you're into IT or cyber security, then you likely already know this ONE simple technical fact which is worth reiterating -

1. 85% of all organizations worldwide operate on Microsoft Active Directory - From Microsoft to Amazon, and from the White House to the entire U.S. Government, every relevant organization in the world operates on Active Directory.


2. 100% of everything in Active Directory is an AD object protected by an ACL - From the Domain Admins group to the domain root object, to every employee's (e.g. CEO, CISO etc.) account and computer, to every security group (e.g. All Employees, Executives etc.) used to lockdown access to every IT asset in the organization (i.e. all files, folders, Exchange mailboxes, databases, apps, portals etc.), literally everything is an object in Active Directory.


3. It is the complete set of Active Directory security permissions that exist in the ACL (access control list) of every Active Directory object that collectively govern exactly who can do what on that Active Directory object.

If you connect the above three dots, you'll arrive at the conclusion that at the end of the day, it is Active Directory security permissions that ultimately protect and govern the security of virtually every IT asset in every organization worldwide.

In short, not just the "Keys to the Kingdom", the "Keys to Every Door in the Kingdom" lie in AD Security Permissions.




Three Technical Pointers

Given the paramount importance that Active Directory Security permissions play in organizational cyber security today, in order to gain proficiency in Active Directory Security, one must know Active Directory Security permissions well.

So, here are a few technical pointers that I recommend we all go through to learn more about them -

1. Active Directory Security Permissions (here), How Access Checks work (here) & Order of ACEs in a DACL (here)


2. Best Practices for Delegating Administration in AD, Appendix C: Active Directory Security Permissions (See * below)


3. Best Practices for Delegating Administration in AD, Chapter 2: How Delegation Works in Active Directory (" * below)

• * Note: The content referenced in 2 and 3 above was part of a 400 page whitepaper I had written while I was at Microsoft, titled "Best Practices for Delegating Administration in Active Directory". For reasons best known to Microsoft, it was removed from its Technet Site. Fortunately, you can still access it if you know where to find it. The only place it is available is as a part of "Windows Server 2003 Retired Content", which is a massive 150 MB PDF file which you can still download from here. To locate this content in that download, install Adobe PDF Reader (needed to open the massive 150 MB PDF), open the PDF and search for my name in it (Page: 8186.)

Please take a few moments to review and learn from these simple yet vital technical pointers. I apologize that there is no good content online from Microsoft to share with you - not sure why Microsoft has pulled so much important content. :-(


Finally, if you have more time and truly want to gain a deep understanding of how access control, access checks, access assessment etc. all work in Active Directory, you can review this authoritative patent on the subject, which today is cited by Microsoft, Palantir, CyberArk, Quest, Amazon, Vmware, IBM and other notable companies.





Active Directory Permissions Analysis Tooling

Over the next day thirty days, I am going to be issuing ten challenges, each one motivated by the desire to teach you something specific and valuable, and each one involving and requiring you to analyze permissions in Active Directory.

So, please feel free to put together your own arsenal of tools so you can accept these ten simple, educative challenges.

Further, to help you put this together, here's a list of just about every tool that I know of that can help organizations analyze Active Directory Security Permissions today, listed in alphabetical order by name of the tool to ensure objectivity -

1. Acldiag (Microsoft)
2. Aclight (CyberArk)
3. Active Directory ACL Analyzer (Paramount Defenses)
4. Active Directory ACL Exporter (Paramount Defenses)
5. Active Directory Effective Permissions Calculator (Paramount Defenses)
6. Active Directory Effective Access Auditor (Paramount Defenses)
7. Active Directory Permissions Analyzer (Paramount Defenses)
8. Active Directory Permissions Reporting Tool (ManageEngine)
9. Active Directory Privileged Access Auditor (Paramount Defenses)
10. AD ACL Scanner (Robin Granberg ?)
11. AD Permissions Reporter (CJWDev)
12. BeyondTrust Auditor (BeyondTrust)
13. Bloodhound (SpectreOps)
14. Dsacls (Microsoft)
15. Effective Permissions Reporting Tool (Netwrix)
16. Enterprise Reporter for Active Directory (Quest)
17. Hyena (Systemtools)
18. LepideAuditor (Lepide)
19. Permissions Analyzer for Active Directory (SolarWinds)
20. PowerShell for Active Directory (Microsoft)
21. Stealthaudit Active Directory Permissions Analyzer (Stealthbits)

• Note: The mere mention of any 3rd party tool above is not and should not be considered an endorsement.

The only tools that you cannot currently (i.e. yet) have in your arsenal are those developed by Paramount Defenses.

You're welcome to use any other tools to fulfill the various challenges I'll be sharing soon. If your organization currently uses a particular tool, I recommend using it to see if it can help you get the answers to these upcoming challenges.




Your First Challenge

Your first challenge is a very simple challenge, and I expect each one of you to be able to easily fulfill this challenge.

Using any tool(s) of your choice that are in your Active Directory security arsenal, please analyze the security permissions in the Active Directory Security Lab VM that I have shared, and simply answer the following three simple questions -

1. Exactly how many security permissions (ACEs) are there domain-wide in the corp.local domain?


2. Exactly how many members does the Domain Admins security group have? 


3. Exactly how many security permissions in the ACL protecting the the Domain Admins security group directly or indirectly impact "Write Property - Member" permissions ?

• These are really simple warm-up questions. Your answer can be as simple as >   1) 100,000     2) 5     3) 4

The answer to question 1 helps determine how large the attack surface is. The answer to question 2 is (sadly) the (mere) extent to which many organizations go to to audit privileged access in Active Directory, and the answer to question 3 begins to scratch the surface when trying to determine who actually has what privileged access in an Active Directory.

You can answer these three simple questions below in a comment, or answer them in my LinkedIn post for today's lesson.




The Importance of Exactness

In Active Directory Security, exactness is very important. In fact, it is paramount because it only takes ONE compromised, malicious or coerced Active Directory privileged user to completely own, compromise and destroy the entire organization.

Here's proof - did you know that almost all major recent cyber security breaches, including JP Morgan, Target, Sony Hack, Snowden, the OPM Breach, Anthem, Avast, the United Nations and others all involved the compromise and misuse of just ONE Active Directory privileged user account.

Perhaps the best way to think of it is this - ask yourself if you would board a flight if I told you that the Metal Detector at the airport was not entirely accurate; you know, one that could do the job with about 75% accuracy (leaving a 25% chance that an explosive device or a firearm could make it past the security checkpoint and on to the plane you're going to be on.)

I know I wouldn't. Would you?   (If you care, don't accept approximate answers ; demand and expect exact answers.)




That's All for Today

Today's simple challenge is intended to lay the foundation for the next ten challenges, and the level of difficulty will only increase with each challenge, so I encourage everyone to accept and embrace this and all following challenges.

By the way, I decided to start simple because there are many folks who are tuned in, and for some of whom, even simple ACL analysis may be a first-time experience. So, to experts who may find these simple challenges simple, please wait for the next challenge, and no matter how advanced you are in Active Directory Security, you will have a worthy challenge :-)

That's it for today. I'll post Day-5 on July 04, and in it, I'll share the answers, including how I make these determinations, AND I'll share your next challenge, which clearly and directly impacts every organization's foundational cyber security today.

I look forward to your answers - answering these 3 questions shouldn't take more than 10 minutes.

Best wishes,
Sanjay.