AdminSDHolder

Folks,

Today is Day-0 of Microsoft's 30-day Active Directory Security School, which starts on May 22, 2017. Today, I'll answer the 2nd (here's the 1st) $100 B question I had asked them, which concerns AdminSDHolder, the root of organizational cyber security worldwide.

[The insight I have provided below is worth a proverbial $100 Billion, so in your own interest, you should read it in its entirety.]

AdminSDHolder

If you're Microsoft, or one of millions of Windows/Active Directory admins or cyber security pros worldwide, you know that at the heart, root & foundation of administrative/privileged access in Active Directory lies one Active Directory object - AdminSDHolder.

In the interest of brevity, I'll skip the details and provide a very brief background here. In essence, all default Active Directory accounts and groups that are considered to be administrative in nature by Active Directory are protected with a special protected locked-down access control list (ACL), which is the access control list of the AdminSDHolder object -

AdminSDHolder

It logically follows that anyone who can modify the permissions specified in the AdminSDHolder object's ACL can easily control and impact the security afforded to all default Active Directory administrative accounts and groups, such as Domain Admins, Enterprise Admins, Administrators, Backup Operators, etc., as well as the default Administrator account, and all such accounts.

In other words, anyone (e.g. a rogue or coerced insider, an intruder, APT etc. ) who could modify the permissions specified in the AdminSDHolder object's ACL could instantly obtain complete administrative control over the entire Active Directory forest!




A $ Billion Question -

So a $ Billion question begs itself, and all organizations operating on Active Directory must ideally have an exact answer today -

Q: "In our Active Directory domain(s), exactly who can modify the permissions specified in the AdminSDHolder object's ACL?"

(If you're thinking "That's easy; just perform a permissions audit using dsacls, PowerShell etc.", think again. Its not that simple.)

$100 Billion side-note: A few days ago, I had posed the same question to Microsoft here. They're likely not going to answer it, so to help Microsoft, as well as 1000s of organizations worldwide, I've answered the question below.

The Answer Illustrated

The answer is best illustrated with a walk-through example. In your own best interest, I highly recommend going through it.

Let us assume that a fictional publicly-held organization is required to identify (i.e. audit) exactly who can modify the security permissions protecting the AdminSDHolder object to demonstrate regulatory compliance, since that is what determines who controls the most powerful and prized privileged/administrative accounts in an Active Directory based IT infrastructure.

To try and answer this question, lets begin by diving right in and launching Active Directory Users and Computers to locate and view the ACL on the AdminSDHolder object -

A closer look reveals that this is a modified (i.e. non-default) AdminSDHolder ACL, in which access changes have been made, as evidenced, for example, by the presence of security permissions that are specified for numerous non-default domain security groups such as IT Contingency Support Team, IT Global Admins Team etc. -

Since this is no longer a default AdminSDHolder ACL, the resulting (effective) permissions/access granted to various individuals by the various permissions specified in the ACL may now differ (likely) substantially from those granted by the default ACL!



For instance, let us consider the impact of the Special security permissions specified for the IT Contingency Support Team -

The Special permissions specified for the IT Contingency Support Team include Allow Modify Permissions and All validated writes. Since it includes Modify Permissions it impacts our answer, so its worth taking a look at the membership of this group.




A closer look at the IT Contingency Support Team indicates that there is a another domain security group nested inside it -

Upon further expansion, one finds that the IT Contingency Support Team has as a member the IT Data Center Operations Team, which in turn has as member the IT Cloud DevOps Team, which in turn has 12 users that are members of that group -

In essence, this one single Special permission alone ends up indirectly (i.e. via 3 levels of nested group nesting) granting 12 individuals Modify Permissions on this ACL.

However, it should also be noted that there could also be one or more Deny permissions in the ACL that could similarly end up denying one or more of these 12 individuals the same Modify Permissions on this ACL, and thus it is not sufficient to merely analyze any one permission in isolation. *Further any such Deny permission may or may not end up negating the Allow, because the resulting access in this case would also depend on the nature (Explicit/Inherited) of both the Allow and Deny permissions.

* By default, the AdminSDHolder ACL is protected. However, since most Active Directory deployments have been around for years, it is possible that someone could have accidentally unchecked the Protected check-box, in which case it will inherit ACEs from the parent. As experts, we take every possible scenario into account. As such, this being an illustrative example applies to most objects in Active Directory (whose ACLs are unprotected) so in most cases, when making such determinations, inherited permissions will need to be taken into account.

As such, as seen above, there are many ACEs (access control entries) in the object's ACL (access control list), each one of which allows or denies a specific security principal (which could be a user, a computer, a security group, a well-known SID etc.) one of more specific Active Directory security permissions, and each one could either have been directly (explicitly) specified on the object, or may have been inherited via inheritance of permissions from the ACL in the object's parent.

In essence, the only way to answer this question is to accurately determine the new resulting (effective) permissions/access granted on this object, which involves collectively taking into account the entirety of all permissions specified to all security principals (users, groups well-known security principals etc.), in light of their permissions types (Allow/Deny) and nature (Explicit/Inherited), to ultimately identify all individuals who effectively possess Modify Permissions permissions on this object.

Specifically, not only will one have to correctly resolve allow vs deny conflicts taking into account the explicit vs inherited nature of each permission, but one will have to expand any and all relevant security group memberships, many of which could contain multiply nested groups (some of which may be circularly nested), and if needed also dynamically evaluate any specified well-known SIDs (e.g. Authenticated Users etc.) and of course, also analyze all relevant security permissions, i.e. in this case, not only those that allow/deny Modify Permissions but also those that allow/deny Full-Control, and of course do all this (each time) with 100% accuracy and no possibility of error.

(The astute mind will have already inferred by now, why this is not a matter of simply performing an audit of "Who has what permissions in Active Directory" or writing a simple (or for that matter even a very complicated) PowerShell script to do so.)

In summary, one needs to determine effective permissions/access granted on this Active Directory object, considering all the permissions, both allowed and denied, whether granted explicitly or inherited, to all the security principals specified in the ACL.

In short, what one needs to do is accurately determine Active Directory Effective Permissions.


In fact, Active Directory Effective Permissions are so important that Microsoft provides an entire tab for it in its native tooling -

To reiterate, the fact that along with Permissions, Auditing and Owner(ship), the fourth tab in Microsoft's native Active Directory management tooling is for Effective Permissions conveys just how important effective permissions are to Windows security.


Here's a closer look at the Effective Permissions Tab in Active Directory -

Active Directory Effective Permissions Tab

As important as it is, unfortunately the Active Directory Effective Permissions Tab provided in Microsoft's native Active Directory management tooling is (and has been so for 10+ years now) substantially inadequate for the following reasons -

1. It is not always 100% accurate, since it self-admittedly does not take all relevant factors into account

2. Most importantly, it can only determine an approximation of effective permissions granted, ONE user at a time

3. Finally, it cannot identify the underlying permissions that entitle a specific user to a specific effective permission

It is for these 3 reasons that it is unable to help organizations assess and lockdown effective permissions in Active Directory, and consequently, most organizations worldwide do not yet have a definitive answer to this and other profoundly vital questions.


(Apologies for the digression.) NOW, to continue on with the example...


Let us assume that the organization has a simple one domain Active Directory forest containing 5000 employee accounts and 10,000 computer accounts, one each for 10K domain-joined computers (e.g. laptops, mail, file, web and application servers.)

Since the Active Directory Effective Permissions Tab can only determine effective permissions ONE user at a time, the only way to definitively determine the identities of all individuals in the company who effectively have Modify Permissions permissions granted on the AdminSDHolder object would be to compile a list of each of these 5000 domain user accounts and 10,000 computer accounts, and then manually enter the identities of each of these accounts ONE BY ONE -

It should be clearly evident that such a process could be very laborious and easily take an excessively long time (i.e. a few days, if not weeks) and require substantial effort, each time the organization needed to make such a determination.

It is also worth noting that in the event that it is found that a user who is not supposed to have this effective permission granted does have it nonetheless, there is no way to easily know which underlying security permission in the ACL is entitling this user to this effective permission, and without that piece of intel, it would be very difficult to revoke this identified unauthorized access.


In essence, in reality, due to the shortcomings of the Effective Permissions Tab in Microsoft's Active Directory management tooling, and a general lack of awareness about the need, value and importance of determining effective permissions in Active Directory, today most organizations have NO idea as to EXACTLY who effectively has Modify Permissions permissions on the AdminSDHolder object, and thus likely have NO clue as to exactly who can control AdminSDHolder in their Active Directory.

By the way, virtually every method described in various forums on Microsoft TechNet on how to determine effective permissions in Active Directory and/or audit delegations, is technically substantially inaccurate, as is this dangerously inaccurate free tool.

Speaking of which, not a single other Microsoft tool such as dsacls, acldiag, etc. or for that matter any other 3rd party tool can accurately determine effective permissions in Active Directory. Some do offer Active Directory Permissions Audit Tools, but those are like baby-toys compared to an Active Directory Effective Permissions Audit Tool, because with them, you're still left to do a MOUNTAIN of work yourself to determine effective permissions, assuming you know how to do so accurately.)

In essence, even though there are 100s of cyber security companies in the world, including some big ones, not a single one of them offers an Active Directory Effective Permissions Audit Tool. Hmm... so much so for demonstrating thought leadership!



So, is there NO way for organizations to accurately and efficiently calculate effective permissions in Active Directory today?

In other words, is there NO way in which 20,000+ organizations worldwide that operate on Microsoft Active Directory, whose cumulative market cap handily exceeds $10 Trillion, can today find out exactly who controls the Keys to their Kingdom(s)?




Well, (thanks to the foresight of one individual, and a decade's work by one cyber security company,) there is ONE way...



Here's how business and government organizations worldwide, including Microsoft IT, can easily, efficiently and accurately determine exactly who has what effective permissions on not just AdminSDHolder but on any object in their Active Directory:

Open Gold Finger, select the Active Directory Effective Permissions Calculator, point it to AdminSDHolder, and click a button -

Gold Finger Active Directory Effective Permissions Calculator

Within a matter of seconds, Gold Finger will uniquely and accurately determine and reveal -

1. The complete set of all effective permissions granted on the object, including of course Modify Permissions

2. For each such effective permission, the complete set of all authenticatable security principals i.e. all domain (user, computer and service) accounts that have a specific effective permission granted on the object

&

3. For each such account, the exact underlying security permissions in the object's ACL that entitle this account to this specific effective permission.

Armed with such valuable intel, organizations can finally, and likely for the first time ever, not only instantly find out exactly who controls the Keys to their Kingdom, but also lock-down access to minimize the number of individuals who can currently do so.

(Incidentally, armed with the same intel, an intruder could also very quickly uncover and exploit the easiest possible path to the Keys to the Kingdom. That is why we only license Gold Finger to legitimate organizations and only for use in their AD domains.)

(In fact Gold Finger can also automatically determine effective permissions/access across an entire domain at a button's touch to exactly find out not only who has they Keys to the Kingdom, but also who has the keys to every door in the kingdom.)




Summary

In summary, considering the fact that 100% of all major recent cyber security breaches involved the misuse and compromise of just ONE Active Directory privileged user account, and the fact that the ACL on AdminSDHolder controls the security of all default administrative (i.e. privileged) accounts and groups in Active Directory, at the very least, every organization that operates on Active Directory today must know exactly who can control the permissions specified in AdminSDHolder's ACL.

The only other thing I will add is that I find it unbelievable that in over a decade, for whatever reason, Microsoft has not once educated its customers about the vital need and importance of determining effective permissions in their foundational Active Directory deployments. Not once! I wonder what that conveys about a company trying to woo the world to embrace its Cloud.

In their own best interest, every organization must strive to understand the profound importance of what I have shared above.

This stuff is paramount to organizational cyber security today.

Best wishes,
Sanjay



PS: The Answer

In short, the simple answer to this elemental yet profoundly vital cyber security question is -

To accurately determine exactly who can modify the security permissions specified in the AdminSDHolder object's ACL, organizations need to accurately determine Active Directory Effective Permissions granted on the object.

I could've easily just shared this one-line answer, but most folks worldwide wouldn't have gotten it, thus the example.

How to find out who can control/manage the AdminSDHolder object in Active Directory?

Folks,

As you may know, at Paramount Defenses, we lead and operate the world's largest community of Active Directory Security Professionals on LinkedIn, compromised of 2500+ individuals from 1000+ top organizations across 100+ countries worldwide.

(Our group is a sales-free and recruiter-free technical discussion group, and is completely free to join.)

Active Directory Domain Controllers

Earlier today, during one of our many technical discussions titled "What are the security implications of someone being able to modify the security descriptor protecting the domain root object in Active Directory", one of our valued members, Daniel Ulrichs raised a very good question (mentioned below) that merited its own discussion.

(Incidentally, on the question above, Daniel also recently publicly shared his thoughts on the question on his blog here.)



Q: Who can control the AdminSDHolder object in Active Directory?

Daniel's thoughtful inputs prompted our latest conversation which focuses on the question - "How to find out who can control AdminSDHolder i.e. who can change the ACL stamped on the AdminSDHolder object?"

As you may know, all accounts considered to have (unrestricted) administrative access in Active Directory are secured by a special protected ACL, which happens to be the ACL on the AdminSDHolder object.


This is one of the most important questions in cyber security today since it directly impacts privileged user access in Microsoft Active Directory deployments and thus profoundly impacts the foundational security of 85% of all organizations worldwide.

Needless to say, anyone who can control the security of the ACL on the AdminSDHolder object holds the "Keys to the Kingdom" because he/she can impact the security of every administrative account in Active Directory.

Today, ideally all organizations should, at all times, know exactly who can change the ACL on the AdminSDHolder.

Ideally, along the same lines, there are many such questions that all organizations must know the exact answers to at all times, but for now, we're focused on this one fundamental Active Directory security question because it is cardinal to cyber security.

I, of course know the answer to the question. I'm only asking this for the benefit of our group members. Should you wish to participate in this discussion, or explore numerous such discussions, you're welcome to join the group and the conversation.

To join, simply visit - http://www.linkedin.com/groups?gid=2006946

Best wishes,
Sanjay

How to Identify & Minimize Privileged Users/Accounts in Active Directory

Folks,

As former Microsoft Program Manager for Active Directory Security, I have shared helpful guidance below on how organizations can correctly and quickly search for and identify privileged users in their Active Directory in a simple 3-step process, and how they can minimize the number of privileged users in their Active Directory deployments, and adequately protect them.

But first, some quick background, below.

• Note 1: If you just want to skip to the technical details, here are direct links that provide step-by-step guidance on how to identify privileged users in Active Directory and how to minimize privileged users in Active Directory environments.


• Note 2: All information (images and content) in this blog entry, including specific guidance, is copyrighted.

White House Orders U.S. Federal Agencies to Minimize Number of Privileged Users

In light of the recent OPM data breach at the U.S. Federal Government, the White House has ordered all U.S. Federal agencies to "tighten policies and practices for privileged users, including minimizing the number of people in this category."

The White House issued this directive because in all likelihood, perpetrators first gained access to a non-privileged domain user account in OPM's Active Directory, then engaged in Active Directory Privilege Escalation to compromise an Active Directory privileged user account, and then used this Active Directory privileged account to gain access to millions of SF-85 & SF-86 forms.

In essence, if the compromise of a single privileged user account can cause such colossal damage, then in order to reduce the attack surface, it is only logical that the  #1 action organizations can take is to minimize the number of privileged user accounts.

However, before an organization can minimize privileged users, it needs to be able to correctly identify them, and accuracy is paramount, because, as the OPM breach has shown,  a perpetrator only needs to compromise one inadequately protected / vulnerable privileged account to inflict colossal damage.

Thus, the step-by-step guidance below is to help organizations correctly identify all privileged users in their Active Directory.




The Entire U.S. Federal Government runs on Active Directory

There are over 600 U.S Federal Agencies in the U.S. Government, and at the foundation of their cyber security lie their Active Directory deployments. For instance, the the U.S. Capitol, the CIA, FBI, DoD, DHS, DoT etc. all run on Active Directory.

Consequently, by privileged users, the White House is technically referring to Active Directory Administrative Accounts, because in Active Directory environments, all privileged users are stored in, managed in and protected by Active Directory.




Active Directory Privileged User Accounts - Holders of  the Proverbial "Keys to the Kingdom"

In Active Directory environments, all privileged accounts are stored in, protected by and managed in the Active Directory itself, and they get their system-wide access privileges by virtue of membership in various Active Directory Administrative Groups.

Thus, technically speaking, all members of all Active Directory Administrative Groups hold the proverbial "Keys to the Kingdom."

Examples of some default Active Directory Administrative Groups include the Administrators (Built-in Admins) group, the Enterprise Admins group, the Domain Admins group, the Server Operators Group, the Account Operators group etc.

Unfortunately, in so many organizations, there is still a misconception that the list of privileged users in Active Directory environments is restricted to those accounts that are members of the Enterprise Admins of the Domain Admins groups.

In reality, the Enterprise Admins and Domain Admins Groups are merely the Tip of the Iceberg.

The complete list of all groups in Active Directory that are privileged/administrative in nature, can be found in the Privileged Access Hierarchy section of the Active Directory Privileged Users reference.





How to Correctly Identify Privileged Users in Active Directory

It is of utmost importance to ensure that every single privileged user account in Active Directory is correctly identified, because as evidenced by the OPM hack, the compromise of a single privileged user account can result in colossal damage.

Complete step-by-step guidance on how to accomplish this objective (i.e. how to correctly identify privileged users in Active Directory) can be found here i.e. at how to identify privileged users in Active Directory. What follows is a shortened reproduction.

In order to correctly identify privileged users in Active Directory, an organization simply needs to identify all Active Directory accounts that fall under three levels of privileged access -

• Level 1 (Immediate Direct Access) - Each Active Directory domain account that is directly or indirectly a member of every group that is listed in (or falls under the criteria of) the Privileged Access Hierarchy

• Level 2 (Immediate Indirect Access) - Each Active Directory domain account that has - 
• i. Sufficient effective permissions to be able to modify the membership of every group that is listed in the Privileged Access Hierarchy.
• ii. Sufficient effective permissions to be able to modify the security permissions protecting every group that is listed in the Privileged Access Hierarchy.

• Level 3 (Non-immediate (30-seconds away) Indirect Access) - For each account identified in Levels 1 and 2 above, identify each Active Directory domain account that has -
• i. Sufficient effective permissions to be able to reset the account's password
• ii. Sufficient effective permissions to be able to set the Password-not-required flag. Alternatively, if smartcards are in use, uncheck the Smart card is required for interactive logon option.
• iii. Sufficient effective permissions to be able to modify the security permissions protecting the account.

Kindly note that it is imperative to ensure that every security group listed in the Privileged Access Hierarchy is taken into account AND that effective permissions are correctly determined on all involved Active Directory administrative accounts and groups.




Three Helpful Tools

As indicated above, it is extremely important to ensure that the list of all privileged users in Active Directory is correctly identified.

The steps outlined above are essential for correctly fulfilling this need. However, they do involve performing advanced analysis (e.g. complete nested group membership enumeration and true effective permissions determination) which can be time-consuming and prone to error when attempted manually on numerous objects.

(Note for advanced IT Pros: PowerShell scripts, LDAP searches based on admincount etc. are not going to be sufficient.)

However, with the right tools, the steps outlined above can be easily accomplished, within a matter of minutes, thus substantially reducing the amount of time and effort involved in the correct identification of privileged user accounts.

Here are three tools that can be very helpful in accomplishing the above steps -

1. Active Directory Group Membership Reporting Tool - Report #2 of this tool View the complete nested group membership of an Active Directory security group can help instantly enumerate the complete membership of any Active Directory group, including all privileged (i.e. administrative) security groups identified in the Privileged Access Hierarchy, as required for the adequate and complete fulfillment of Level 1 requirement above.

2. Active Directory Effective Permissions Calculator - Report #1 of this tool, Who has what Effective Permissions on an Active Directory object can help fulfill the effective permissions/access calculation/audit needs required for Level 2 (i and ii) and Level 3 (i, ii and iii) requirement above, one Active Directory object at a time, on every relevant Active Directory security group and account.

3. Active Directory Administrative Access and Delegation Audit Tool - Multiple reports of this tool can be used to instantly fulfill the effective permissions/access calculation/audit needs required for Level 2 (i and ii) and Level 3 (i, ii and iii) requirement above, on all Active Directory privileged and non-privileged accounts and groups in a single assessment and one mouse-click, in minutes.

In addition, you can always use Report #1 Who can reset my account's password and Report #2 Who can reset a colleague's password of this free tool to instantly identify exactly how many users can reset a specific user's password, including yours, and that of any colleague (e.g. a Domain Admin, an Enterprise Admin, the CIO etc.).




A Real-World Example on the Importance of Levels 2 and 3 Above

The importance of ensuring that all Level 2 and 3 accounts above are identified is perhaps best understood with an example.

Last week one of our Technical Specialists was assisting the Director of IT of a multi-billion dollar organization identify privileged users in their Active Directory deployment, upon their request.

Their chief Network Admin (i.e. an "Enterprise Admin") had reported that the organization only had 7 Enterprise Admin accounts.

However, when together we proceeded to determine effective permissions on the Enterprise Admin security group, we found that 35 additional individuals had the ability to change the membership of the Enterprise Admins group. In other words, the total number of individuals who had Enterprise Admin level access was actually 42 (7 + 35), not 7.

Similarly, when we determined effective permissions/access on that specific Network Admin's account (i.e. the one who was on the call and was an Enterprise Admin), we found that 47 individuals had sufficient effective permissions/access to be able to reset the password of that Network Admin's domain user account. In other words there were at least 47 additional individuals who could instantly (i.e. at the touch of a button) elevate their privilege to be that of an Enterprise Admin if they wanted to.

In this manner, we proceeded to follow the steps outlined above, enumerating all Level 1, 2and 3 users based on the Privilege Access Hierarchy and identified 227 individuals who effectively had privileged (system-wide administrative) access. In contrast, the total number of individuals based solely on the default administrative group memberships was 36.

Thus, by including Levels 1 and 2, they identified 191 additional privileged (system-wide administrative) users in their network.

In each case (group membership change and password reset), these individuals were already sufficiently privileged (i.e. had sufficient delegated administrative access in Active Directory) to be able to elevate their privilege to that of an Enterprise Admin, at a button's touch, i.e. they already had the effective access needed to perform these sensitive tasks.

This real-world example illustrates why it is not sufficient to merely enumerate the number of membership of default Active Directory administrative groups when trying to determine the number of individuals that have privileged access. It is very important, and in fact paramount to ensure that not just Level 1, but also Level 2 and 3 accounts are accurately identified.




A Quick Note on the Importance of Effective Permissions

In the process of identifying Level 2 and Level 3 accounts, you will most likely need to determine effective permissions/access on various accounts and groups, In this regard, I just wanted to add that the importance of determining effective permissions / effective access, and doing so accurately, cannot be overstated. Specifically, here are 3 important aspects to be aware of -

1. It is very important to know that there is a substantial difference between identifying "who has what permissions" and "who has what effective permissions". The two are NOT the same. There is a world of a difference between the two. Merely identifying "who has what permissions" is insufficient and is bound to provide inaccurate and misleading results.
   
   For example, consider a situation wherein a user John Doe, a helpdesk operator may be denied Reset Password permissions via an inherited ACE in the ACL of a Domain Admin's account.
   
   Now, just because there is a permission denying John Doe Reset Password, does not in fact mean that John Doe cannot in fact reset the Domain Admin's account's password. There could be another explicit permission allowing the Outsourced Contractors group All Extended Rights, and assume that the HQ Onsite Contractors is be a member of this group, and finally that John Doe is a member of the HQ Onsite Contractors group. In other words, in addition to there being a direct Deny (inherited) permission for John Doe, there is also an indirect Allow (explicit) permission that applies to John Doe. 
   
   As a result, because an explicit allow permission will always override an inherited deny permission, in effect, John Doe will in fact be able to reset the Domain Admin's password.
   
   As illustrated in this example, if you were merely looking at "Who has what permissions", you would falsely arrive at the conclusion that John Doe cannot reset the Domain Admin's account's password. However if you had been looking for "Who has what effective permissions", you would have rightly arrived at the conclusion that John Doe can in fact reset the Domain Admin's account's password. 

2. If you utilize a tool to determine effective permissions/access in Active Directory, it is of utmost importance to ensure that whatever tool you wish to utilize delivers accurate results and is trustworthy.
   
   Accuracy is paramount because a single inaccuracy can mean the difference between being secure and being vastly vulnerable. As recently brought to our attention by one of our customers, an example of one such tool that is substantially inaccurate can be found here.
   
   Trustworthiness is also very important, because you most likely wouldn't want software written in say Russia or China being run or deployed in your production environment. A few simple questions that you can ask to assess the trustworthiness of any such tool can be found here.



3. If you utilize a tool to determine effective permissions/access in Active Directory, you'll ideally want to use a tool that can accurately identify and reveal the list of all users that have a given effective permission/access combination, as opposed to a tool wherein you need to enter the identity of every user in your domain one user at a time to manually arrive at a list of all the users that have a given specific set of effective permissions on a given object, or on multiple objects. (If your organization has even 1,000 users and computers in its Active Directory forest, you wouldn't want to enter 1,000 names each time you need to determine effective permissions.)

How to Minimize Privileged Users in Active Directory and Adequately Protect Them.

With executive support and trustworthy guidance, organizations can minimize the number of privileged users in Active Directory.

 

To help organizations worldwide reduce the likelihood of a security breach involving the compromise and subsequent misuse of a privileged user account, as well as to help them mitigate the risk posed by Active Directory Privilege Escalation, at Paramount Defenses, we have provided trustworthy guidance on how to minimize privileged users in Active Directory environments, here.

 

 

Additional Information

To help organizations worldwide reduce the likelihood of a security breach involving the compromise and subsequent misuse of a privileged user account, we have also provided valuable information on the impact of compromise of a privileged user, on the attack surface that organizations need to defend, on the attack vectors that are commonly used by perpetrators, and on the various sources of threat, including insiders and APTs, as well as on Active Directory Security.

You are welcome to use this information towards evaluating and enhancing your organizations security posture. Start here.



Summary

As evidenced by the OPM breach, the compromise of a single privileged user account can result in colossal damage. In order to reduce risk, it is thus of utmost importance that organizations correctly identify all existing privileged users in their Active Directory, quickly minimize this number down to a bare minimum, and adequately protect them. The guidance provided above is designed to help organizations accomplish this objective quickly and reliably.


Should you have any questions or thoughts, feel free to leave a comment. I will do my best to answer them, time permitting.


Best wishes,
Sanjay

PS: Standard disclaimer: The use of any information provided above is subject to the disclaimer provided on this page.

PS2: Incidentally, if you liked this, I think you'll like this too.