How to Discover Stealthy Admins in Active Directory

Folks,

Today, I wanted to take a few minutes to share how organizations worldwide can discover stealthy admins in Active Directory.

This is part II of the post - How to Discover Stealthy Admins in Active Directory.




A Quick Intro

Lately Active Directory Security seems to have been getting a lot of attention from traditional network security / hacking / cyber security folks, both, on the good side and the not-so-good side. Many of them may be relatively new to the subject of Active Directory Security, and most of them seem to be primarily interested in identifying privileged users in Active Directory.

Interestingly, perhaps because they may be new to this ocean of a subject, they may have started referring to delegated admins in Active Directory as Stealthy Admins, perhaps because they may not be aware of the concept of access provisioning and administrative delegation in Active Directory, even though both these concepts have been around for 17 years now.

If you want to know what I think of the term Stealthy Admins, you can read my last post on this topic ;-)

Anyway, to help these folks, and anyone else who might be interested in discovering "Stealthy Admins in Active Directory", I thought I'd help them understand what it actually takes to correctly make this determination in Active Directory deployments.






A Quick Primer

It is no secret that in IT infrastructures that are powered by Microsoft Windows Server, the proverbial "Keys to the Kingdom" lie in Active Directory. Specifically, the most powerful administrative/privileged domain security groups (e.g. Domain Admins), as well as the domain user accounts of all their members are all stored, protected and managed in Active Directory.

Now, if you were to ask a novice for advice on how to identify privileged users in an Active Directory, he/she will most likely tell you that all you would have to do is identify all those domain security groups that Microsoft says are privileged in nature, and then enumerate the complete membership of these domain security groups, and that's it i.e. you should be done!

Interestingly, would you be surprised if I shared with you that a majority of all organizations worldwide, when asked to furnish a list of privileged users in their Active Directory deployments (to demonstrate regulatory compliance that is), do exactly this!

In reality, if you follow the advice above, you would have merely uncovered the Tip of the Iceberg, because in reality, in most organizations, there exist a FAR greater number of privileged users than do the members of the default AD admin groups.






A Quick Question

To understand where Stealthy Admins come from in Active Directory, let us ask ourselves a quick very simple question.

Assumption: For illustrative purposes, let us assume for a moment, that there is only one default administrative/privileged group in Active Directory - the Domain Admins security group.

Here's the Domain Admins group, and the question is below -

As you can see above, there are only 2 members in the Domain Admins group.

The Question - Based on the above, can we assume that this organization only has 2 privileged users in their Active Directory? i.e. there are only 2 accounts that possess privileged access in this Active Directory - 1) the default Administrator account, and 2) the domain user account of the user Steve Ballmer, as that is what the membership of the Domain Admins group indicates?

Side Note: Would you be surprised if I told that (considering the assumption we've made above) most organizations would just report this as the number or privileged users in Active Directory?!

To answer this question, let us consider the following.




Consider This

Consider the impact of someone being able to perform the following administrative tasks in Active Directory -

1. Change the membership of the Domain Admins group


2. Reset the password of the domain user account of a member of the Domain Admins group


3. Change the permissions on the Domain Admins group, or on the account of any of its members


4. Change the ownership of the Domain Admins group, or on the account of any of its members

The above is most certainly not an exhaustive list of such administrative tasks, but merely a handful of such administrative tasks that can be enacted on Active Directory content, by anyone that has sufficient effective access to be able to do so.

Note: At this point, to advanced users, AdminSDHolder may come to mind. I would encourage them to read this advanced post on AdminSDHolder, and if you want to know how little even Microsoft seems to know, this one too.

Specifically, consider this -

Although in the illustrative example above, the Domain Admins group only has 2 members, shouldn't everyone who can change its membership also be considered a Domain Admin? After all, anyone who could do so could easily and instantly add his/her own account, or that of anyone he/she likes, to the group, as well as take the existing members out of the group!

Similarly, in the illustrative example above, although we only have 2 accounts that are members of the Domain Admins group, shouldn't everyone who can reset the password of any of these accounts also be considered a Domain Admin? After all, anyone who could do so could easily reset the password of these admin accounts, and instantly logon as them!

By the same token, anyone that can change the permissions or the ownership of any one of these default administrative groups or accounts should also be considered to be a privileged user possessing the same level of privilege, because he/she could easily modify the permissions on these objects to grant themselves or anyone else the same level of administrative privilege!




The Answer (to the Question)

In light of what we just considered above, hopefully it should now be clear that to accurately identify privileged users in Active Directory, in addition to enumerating the members of the default administrative/privileged security groups in Active Directory, at the very least, we should also be determining and including exactly -

1. Who can change the membership of every single domain security group (as well as any domain security groups nested in it) in Active Directory that is considered administrative/privileged in nature? 


2. Who can reset the password of every single domain user account that is a member of a domain security group that is considered to be administrative/privileged in nature?


3. Who can modify the security permissions and/or the ownership of every single domain security group and domain user account that is considered to be administrative/privileged in nature?

It must be noted that the keyword here is "at the very least." I say so because there could additionally easily be a specific domain user account or a domain security group that may not be a member of any default privileged group in Active Directory yet be directly be granted access in Active Directory that is tantamount to possessing privileged access in Active Directory!


Now, in case you're wondering - "But how does someone get the ability to change group memberships, reset passwords, etc?!"






Delegation of Administration in Active Directory

This brings us to one of the most powerful, capable, valuable and frequently-used features/strengths of Active Directory - Administrative Delegation. Delegation of administration is a capability that lets organizations distribute and delegate administrative authority for various aspects of identity and access management amongst a large group of IT personnel.

Its premise is simple - since it may be infeasible for a handful of highly privileged Domain Admins to manage thousands of objects in AD, wouldn't it be helpful if organizations could delegate/distribute administrative authority for identity and access management tasks amongst a larger group of IT personnel, who need not posses Domain Admin equivalent privileges!

Delegation of administration lets organizations delegate administrative authority in Active Directory and do so with precision -

In fact, over the last 17 years, there possibly might have been billions of administrative delegations / access provisioning(s) done in Active Directory domains, across Active Directory deployments worldwide.

Incidentally, I only know this because I happened to have authored Microsoft's 400-page whitepaper on the subject back in 2004 titled "Best Practices for Delegating Administration in Active Directory". The appendices of that whitepaper in itself were a treasure trove of knowledge on the subject. Amazingly, that whitepaper's nowhere to be found on microsoft.com these days!

Now, this is a very complicated subject (considering that it required a 400-page whitepaper to cover) so I'm not going to go into too many details here. Instead, I just wanted to share with you how IT personnel end up getting sufficient privileges in Active Directory so as to be able to enact common administrative tasks such as group membership changes, password resets etc.

The short of it is that when a task is delegated to a specific security principal, such as a domain security group, the security permissions required to perform the technical LDAP operation that corresponds to that task on a given type of object, are provisioned in Active Directory, thereby enabling all members of that group to be able to enact that task.

For example, when a domain security group such as IT Operations Support Level 1 is delegated the administrative task "Modify the membership of a group" in a specific organizational unit (OU), the following security permissions are added to the ACL of every domain security group in that OU -  { Allow   IT Operations Support Level 2    Write-Property   Member }

Similarly, when a domain security group such as IT Operations Support Level 2 is delegated the administrative task "Reset user passwords" in a specific OU, the following security permissions are added to the ACL of every domain user account in that OU -  { Allow   IT Operations Support Level 3    Extended Right   Reset Password (User-Force-Change-Password) }

By the same token, when a domain security group such as IT Contractors is to be denied the ability to enact a specific admin task, such as "Reset user passwords" in a specific OU, the following security permissions are added to the ACL of every domain user account in that OU -  { Deny   IT Contractors    Extended Right   Reset Password (User-Force-Change-Password) }

Note: The above is a highly simplified description of how this all works. Of course, there are many subtle yet vital details such as precedence orders which govern which security permissions (amongst numerous allows and denies) eventually prevail, and what access a user actually (i.e. effectively) ends up getting. More on that here. 

Aha! It is all such domain user accounts for whom access may either have been delegated or provisioned on these default admins groups and accounts, and numerous other objects, that are being referred to by these novices as "Stealthy Admins" !



Okay, with this boring theory out of the way, let's find out how to correctly
identify these Stealthy Accounts in Active Directory, shall we?! ...






How to Correctly Discover Stealthy Admins in Active Directory

If you know the subject well, then you know that in order to correctly determine stealthy admins in Active Directory, you need the ability to be able to determine effective permissions / effective access in Active Directory.

If you don't know the subject well enough, then perhaps you may (errantly) believe that simply performing an Active Directory permissions audit to find out "Who has what permissions in Active Directory" would be sufficient. However, you'd be wrong.

Here's why -

If by "Stealthy Admins" one is referring to individuals who possess the ability to enact administrative tasks such as being able to change a domain security group's membership or reset a domain user account's password, or modify the permissions or ownership on an Active Directory object, then the only correct way to identify the identities of all such individuals who can enact these administrative tasks, is to accurately determine effective permissions / effective access on Active Directory objects.

I am not going to be spending any more time helping the world understand what Active Directory Effective Permissions are and why they're so important, so if you want to know more about them, you can read this post, which I highly recommend reading.


Okay, that said, let me actually show this to you, and to do so,
lets continue with that question we asked above...


So, here's the ACL (access control list) protecting the Domain Admins security group -

We have already seen above that is has only 2 members. However, what we should also be wanting to know is exactly how many individuals can enact the administrative task of "changing the group membership" of the Domain Admins group.

As seen above, there are many ACEs in the ACL of the Domain Admins group, each one allowing or denying a specific security principal (user, group, well-known SID or a foreign security principal) various specific Active Directory security permissions.

Now, technically, to find out who can change the group's membership, what we need to do is find out exactly who has sufficient Write Property - Member effective permissions, which is what's needed to be able to modify the Member attribute of this object.


That said, let me show you the only way that I know how to accurately do so -


I launch this tool, use its inbuilt search utility to find and point the tool to the Domain Admins group, and click a button -

In a matter of seconds, the tool accurately determines the complete set of effective permissions that are granted on this Active Directory object, and shows me the results in a most intuitive manner.

Note: At this point, to some, Microsoft' Effective Permissions Tab may come to mind. To find out why it is not only inaccurate but also substantially inadequate, you'll want to read this. To others this tool may come to mind - allow me to share with you that that tool is dangerously inaccurate, even though its developers may not know it. For those to whom tools like dsacls, acldiag, or any one of various Active Directory Permissions Analyzers come to mind, you'll want to read this to learn about why not a single one of them can get the job done.

As can be seen in the snapshot above, we have just identified that although the Domain Admins security group itself has only 2 members in it, there are in fact 11 individuals who can change its membership, including one sneaky persistent bad guy!

From just that one report, the actual number of privileged users just increased by 500%  i.e. went from 2 to 11!

Similarly, the tool can show exactly who has sufficient Modify Permissions and Modify Owner effective permissions on this Active Directory object, and to determine the actual number of privileged users, you'll want to include their identities as well.

Now, because that tool is a Active Directory effective permissions calculator (and in fact the world's only accurate one), it is primarily designed for Active Directory admins and Active Directory security professionals, and thus it determines and delivers its results in terms of effective permissions. However, there might be many individuals, such as IT Auditors, IT Managers, Cyber Security Risk Assessors and others in similar roles who may not be experts in Active Directory Security, and thus may not know technical details such as effective permissions to task mappings etc., yet may have a need to make such determinations.

For all such individuals, we built this tool to help them make the same exact determination -

In contrast to the previous tool, this tool's inbuilt intelligence can not just determine effective permissions, it can additionally also determine effective access in Active Directory, and as a result, it can show you who can actually do what in Active Directory, in plain English i.e. in terms of administrative tasks, eliminating the need for you to know anything at all about Active Directory.

As seen in the snapshot above, this tool's results too indicate that there are a total of 11 individuals who can enact the administrative task of being able to change the membership of the Domain Admins group!


In this manner, within a matter of seconds, today everyone can find out exactly who can enact administrative tasks such as being able to modify a privileged security group's membership, and thus uncover "stealthy admins" in Active Directory!



Now, let me show you another example -


Let us assume that a user, say a Jeff  Bezos, is the only member of the Enterprise Admins group in Active Directory.

Since he is a member of the Enterprise Admins group, he is obviously considered a privileged user.

Now, hopefully you'll agree that since he is a privileged user, anyone who can reset his password should also be considered to be a privileged user since he/she is merely one mouse-click away from becoming an Enterprise Admin, so shouldn't we also be determining exactly who can reset his password?!

Note: Now, in case his account might be Smartcard-enabled, all you'd have to do is find out who can turn off the "Smartcard required for logon" requirement AS WELL AS reset his password, and that much should suffice!

So, let's find out exactly who can reset this Jeff Bezos' password, shall we -

We click a button, have a sip of coffee, and lo and behold, we've just uncovered that a total of 30 individuals have sufficient effective permissions / effective access on his domain user account, so as to be able to reset Jeff Bezos's password!

Think about it - even though in this fictional organization, there was only 1 Enterprise Admin i.e. only 1 user who was a member of the Enterprise Admins group, we just discovered that there are 30 individuals who can reset his password (whenever they want) and thus be him whenever they want!  






How to Audit Specific Stealthy Access in Active Directory

Again, if by "Stealthy Admins" / "Stealthy Access", they're referring to "Delegated Admins" / "Delegated Access", then here are step-by-step directions on how folks worldwide can audit for specific stealthy access in Active Directory -

1. How to Correctly Audit Who can Create User Accounts in Active Directory


2. How to Correctly Audit Who can Change Group Memberships in Active Directory


3. How to Correctly Audit Who can Delete Organizational Units in Active Directory


4. How to Correctly Audit Who can Reset Passwords in Active Directory


5. How to Correctly Audit Who can Change Service Connection Points in Active Directory

While you're on the subject, you may also want to find out how to correctly perform an Active Directory Privileged User Audit.






Scaling It Up!

Now, let's assume that you have thousands of domain user accounts, domain security groups, domain computer accounts, organizational units, service connection points etc. etc. in your Active Directory.

Technically speaking, if you truly want to uncover all "Stealthy Admins" in Active Directory, wouldn't you want to know exactly who can reset the passwords of all the domain user accounts in Active Directory, who can change the membership of all the domain security groups in your Active Directory, who can change the security permissions protecting all Active Directory objects in the domain etc. etc. For example, how about knowing exactly who can reset the CEO's domain user account's password?

Well, if the answer is YES, then you're basically looking at determining effective permissions on thousands of objects in your Active Directory. Now, even if you had the capability to determine effective permissions / access on a single Active Directory by clicking just one button, you'd still have to click a button thousands of times.

That doesn't sound like too much, fun does it, not to mention that it could take weeks to do so. Of course, if you don't even have the capability to determine effective permissions one object at a time, you could easily be looking at months, if not years to make these determinations.

Well, wouldn't it be nice if someone could make this as easy as touching a button?

You know, something like this -

If you can click a button, now you can immediately and of course accurately uncover every single "Stealthy Admin" in your Active Directory, whether you have a few hundred or a few hundred thousand objects in your Active Directory.

For a complete list of all the administrative tasks that you can audit with this tool, please click here.

To novices that might sound easy; if you want to know how difficult this is, you'll want to find an Active Directory security expert, one who has spent years on Active Directory Security, and has thousands of hours of experience in trying to determine effective permissions on various Active Directory objects, and perhaps he/she could help you appreciate just how difficult this is.

Those who truly understand Active Directory Security know that building such a tool is on par with scaling Mount Everest. Then there are some who claim to offer free tooling that could help identify stealthy admins in Active Directory ;-)  Little do they realize that in doing so, they may actually be showing the world just how little they may seem to know about Active Directory Security.





Summary

In today's post, I wanted to help folks understand that what some may refer to as "Stealthy Admins", are merely either delegated admins in Active Directory or IT personnel for whom various levels of access may have been provisioned in Active Directory.

Having said that, I also wanted to show you how to identify these delegated admins, which in line with the title of the post, perhaps we could play along and continue to call "Stealthy Admins in Active Directory."

I also wanted to share with the simple fact that in order to discover stealthy admins in Active Directory, what we need to do is to be able to accurately determine effective permissions on Active Directory objects.

Oh, and I also wanted to convey that when organizations audit privileged users in Active Directory, it is not sufficient to merely include the members of the default Active Directory administrative groups. You also need to include the identities of all such users who possess sufficient effective access in Active Directory so as to be able to modify the memberships of these groups, reset the passwords of all their members, change the security permissions protecting these groups and accounts etc.

If you want to know how to do this correctly, you'll want to read - How to correctly identify privileged users in Active Directory.

Finally, I wanted to demonstrate all of this with two simple illustrative examples, one involving identifying who can change the membership of the Domain Admins group, and one involving identifying who can reset the password of an Enterprise Admin.

That's all for today. Next post onwards, we'll get back on track and
proceed to finish Active Directory Security School for Microsoft.

Best wishes,
Sanjay 

How to Discover Stealthy Admins in Active Directory (Part I)

Folks,

Today I'd like to touch upon a very interesting topic i.e. how to identify / scan for / discover stealthy admins in Active Directory.

This post is not Part II of  How To Identify & Thwart Sneaky Persistence in Active Directory; that will follow shortly.

Stealthy Admins in Active Directory

Recently, there's been a lot of attention being given to what are being called "Stealthy Admins in Active Directory!"

Stealthy Admins in Active Directory

This concept of Stealthy Admins is along the lines of "Sneaky Persistence in Active Directory" and it deserves a befitting note.




First, An Apology !

[Begin Humor -

Folks, maybe I owe the whole world an apology, and here's what I owe it for -

For years, I've been trying to help the world understand that there exist in Active Directory deployments worldwide, 1000s of excessive / unauthorized privileges (i.e. security permissions), the existence of which endangers organizational cyber security.

To convey this fact, I've used all the right terminology, whether it be "effective permissions" , "effective access", "delegated access", "privilege escalation paths" etc. yet I doubt that most organizations worldwide get the depth of what I'm talking about.

Then come along a few new-comers to the field of Active Directory Security, and since they are just beginning to scratch the surface of Active Directory Security, they're likely amazed to know that there's (so much) more to administrative access in Active Directory than merely the members of the default Active Directory administrative groups (e.g. Domain Admins etc.), and perhaps because they may not be familiar with the notion of "Delegation of Administration" in Active Directory (and/or may not have read the 400-page whitepaper that I wrote on the subject for Microsoft way back in 2004,) they start referring to this stuff as "Stealthy Admins in Active Directory", and lo and behold, suddenly the whole world starts to understand this stuff!

How incredibly dumb must I be to not have figured that all I had to do is call this "Stealthy Admins in Active Directory!" ;-)

-- End of Humor ]


The answer - "Not at all dumb." In fact, anyone that's referring to these delegated administrative accounts as "Stealthy Admins" is merely demonstrating to the whole world how little they actually seem to know about the subject of Active Directory security!

Here's why - If you actually know Active Directory Security, then you likely know about its most capable feature, Delegation of Administration, and if you do, then you undoubtedly know that there are a LOT many more individuals who possess varying levels of admin/privileged access in Active Directory than just the members of the default admin groups in Active Directory.

Specifically, the fact that there might exist administrators in Active Directory (, other than members of the default administrative groups in Active Directory,) who may be able to enact various administrative tasks on default administrative accounts and groups and elsewhere in Active Directory, should come as NO surprise to those who understand Active Directory Security.

The fact that this "Stealthy Admins in Active Directory" misnomer is becoming so popular merely shows that not only those talking about it, but also those embracing it, may not seem to know much about Active Directory Security, and that's worrisome.

I can assure you that if you were to ask some of the best folks in Active Directory and Active Directory Security, such as Stuart Kwan, Joe Richards, Guido Grillenmeier, Micky Balladelli, Jan De Clerq, Andreas Luther and SO many others, they'll all likely agree with me, and laugh at this concept of "Stealthy Admins in Active Directory" introduced by a few folks new to the subject.




Likely Origins

Active Directory has been around for almost two decades, and at thousands of organizations worldwide, administrative authority for enacting administrative tasks such as password resets, group membership changes, account creations and deletions etc. have been delegated MILLIONS OF TIMES by thousands of IT personnel, and in fact, today there likely exist millions of individuals that possess varying levels of delegated administrative access in Active Directory deployments worldwide!

In other words, most organizations are intimately familiar with the concept of delegated access in Active Directory!

If that's the case, then it must be asked as to where this comical phrase "Stealthy Admins in AD" came from?

Here's the most likely answer -

Over the last few years, there's been a substantial increase in the focus on cyber security, and thus also on ways to obtain privileged access in Windows environments, and a large number of traditional "network security" hackers and cyber security professionals appear to have finally realized that at the very heart of cyber security in Windows Server based IT infrastructures lies the Active Directory, so they've started studying Active Directory security with a keen interest, and when you approach this subject from the outside-in (, as opposed to from the inside-out (i.e. you start with AD first)), then of course, the whole concept of administrative delegation is something you may not be aware of, and so of course, when you realize that there's a lot more to administrative access in AD than the mere members of the default administrative groups, you're likely to think of that indirect access as "stealthy access", whereas in fact to those familiar with the subject, that's just Active Directory Security 101!

In short, if you're new to the subject, you're likely going to be a bit surprised that there are actually (a LOT) many more folks that possess admin/privileged access in Active Directory than just the members of the default admin groups in Active Directory, and these to you might appear to be "Stealthy Admins!"




Speaking of Which

No matter what you call it, the fact remains that in virtually every Active Directory deployment in the world, there are far more individuals that possess varying levels of administrative access in Active Directory than the mere members of the default administrative groups, and it is imperative that not only must all those who hold such access in Active Directory be accurately identified, but also that if it is determined that the level of access that they hold is tantamount to unrestricted privileged access, then they must be rightly classified as "privileged users in Active Directory."

For example, consider the Domain Admins group. It may very well be that at an organization, there are only a handful of individuals that are members of this privileged access group in Active Directory. However, it is not sufficient to merely consider the group's membership. One must also accurately determine exactly how many individuals (and exactly who they are,) can enact the administrative task of being able to change the membership of the Domain Admins group. The reason this is so very important, and in fact paramount, is that because anyone who can change the membership of this group can add anyone else to the group and/or remove any existing member from the group!

Similarly, consider the default Administrator account in Active Directory, or for that matter the domain user account of any and every privileged user in Active Directory. Organizations must know at all times exactly who can enact the administrative task of being able to reset the password of each one of these domain user accounts. The reason this too is so very important, and in fact paramount, is that because anyone who can reset the password of any one of these accounts can instantly login as that account, and of course, if he/she can do so, he/she now 0wns your entire Kingdom!

In fact, it is not just group membership changes and password resets that can be used to gain administrative/privileged access in Active Directory. Any individual who enact the task of being able to modify the ownership or the permissions protecting any one of numerous direct and indirect administrative accounts and groups and/or certain objects in Active Directory, is just one step away from being a highly privileged user in Active Directory, and thus must be considered to be equally privileged.

In days to come, I'll shed some light on the various administrative tasks that one can perform in Active Directory to gain/escalate privileged access in Active Directory. That blog post will be Part II of this post. If you need to know right away, you can read this.




The Key to it All

There are some who albeit new to the subject may have at least realized that those who can enact administrative tasks such as password resets, group membership changes etc. also in effect possess the equivalent of privileged access in Active Directory.

Some of them may also claim to offer free tooling that can help organizations identify "Stealthy Admins in Active Directory."

As former Microsoft Program Manager for Active Directory Security, I can almost state with a high degree of confidence that these folks too may be making the classic mistake of mistaking "Who has what permissions in Active Directory" for "Who has what effective permissions in Active Directory", and thus their tooling too (just like this tool and Bloodhound) might also very likely be substantially and dangerously inaccurate, and thus may be delivering vastly incomplete or inaccurate data, reliance upon which could put in jeopardy the security of any organization relying on that data.

To help all such folks, allow me to share that the key to being able to accurately figure out who can enact which administrative tasks in Active Directory lies in being able to accurately determine effective permissions / effective access in Active Directory.

Let me repeat that - the Key to identifying privileged users in Active Directory lies in Active Directory Effective Permissions.

For instance, consider the ACL protecting a domain user account in Active Directory. Just because there exists an ACE in the ACL of this Active Directory object granting a security group, say Group X, to which a user John Doe might belong, say "Allow Group X Reset Password" permissions, it does NOT imply that that specific user John Doe might actually be able to reset that account's password, as there could easily be one or more ACEs, such as a "Deny Group Y All Extended Rights" that could effectively negate the allow access granted by the first ACE, if John Doe were also directly or indirectly a member of Group Y.

I say it could because ultimately it all depends on numerous factors, such as to begin with, which ACE is explicit in nature and which one is inherited, which one allows access and which one denies access, what combination of permissions are they allowing/denying, whether or not they actually apply to the object etc. etc. Further, there could easily be hundreds of ACEs in that (and in each) Active Directory object's ACL, and it is absolutely possible that each one could potentially impact the access granted/denied by each other one!

Those who know the subject well know that the what I've shared above is a super highly simplified example of Active Directory effective permissions are, so perhaps I should share a few helpful pointers to help illustrate this subtle yet profound difference.

Here's some recommended reading to help understand the subtle but profound difference between "Who has what permissions in Active Directory" and "Who has what effective permissions in Active Directory" - Active Directory Effective Permissions

Lastly, for those who truly want to understand this paramount subject, may I recommend reading the patent that governs the accurate determination of who actually has what effective access in Active Directory - United States Patent # 8429708.



As to how to actually discover stealthy admins in Active Directory,
that will follow in part II of this blog post, in a few days.



That's all for now.

The next post (within 5 days) will be Part II of  How To Identify & Thwart Sneaky Persistence in Active Directory.

Thanks,
Sanjay