AD root level ACL query.

Question

I have been doing some research into security permissions in Active Directory, and I’ve been using a tool called AD ACL Scanner: https://github.com/canix1/ADACLScanner/releases/tag/6.2

I’m not sure if this is a tool you have used previously in security reviews, but it basically has a number of options & filters before you run a scan. One of which is to ‘exclude all built-in security principals’ (which I enabled before executing a scan of our domain). Secondly you can ‘filter by severity’, which I have done, to just flag up the critical issues.

One thing it’s flagged as a ‘critical’ risk is a group which doesn’t appear to be a Microsoft/AD default, has full control over the domain. It lists two entries in the HTML report it generates, one applies to ‘This object and all child objects’, and another applies to ‘computer’. Another entry of strange members also is listed as a critical vulnerability, has full control, which applies to ‘user’.

I’ve verified the results in AD users and computers, I’ve right clicked on the root of the domain > properties > security and it does have a tick in full control for this strange group, in the allow column, as well as a tick in every other permission in the list in the allow column.

It’s even more confusing as if you click the domain admins group in the ACL for the root of the domain, even that does not have full control. Enterprise admins does however.
My concern is this group with full control over the domain has actual user accounts in it, who do work in ICT, but not at a senior level enough to warrant domain admin type access. e.g. they aren't also members of the domain admins group. With what I have described above, does this sound like an oversight in the security design of our AD?

With full control (even if they are not a direct member of domain admins), what kind of problems could these users cause? Can you provide some examples?

Answer 1

Hello,

Thank you so much for posting here.

As for AD ACL Scanner, it is a third party tool and we have not used this tool previously. According to our description, there is a group which has full control over the domain. It is suggested that we need to figure out what this group is, what the user accounts in this group are, how this group gets the full control permission and do this group need this permission.

The domain admins group and Enterprise admins group have the permission as shown below. As mentioned, the domain admins group does not have full control permission. If this group has full control permission, there might be security issue. We could remove the permission of this group if we are sure that this group does not need this full control permission.

For any question, please feel free to contact us.

Best regards,
Hannah Xiong

Answer 2

@crib bar

since the support person here did not directly answer your question (which would have been best phrased without any reference to a third party tool), no, it is not commonly accepted best practice to allow some random group of users FULL CONTROL to the root of your domain.

The previous answer kind of alluded to the fact that Enterprise Admins is the only default group with this right. So, if you extrapolate from there, these users effectively have Enterprise Admin rights to the domain. This is probably not what would have been intended for these users. And even if it was, they should have been added to the actual Enterprise Admins group, not been directly assigned in the ACLs.

However, no-one should permanently be a member of Enterprise Admins in general. A domain admin can add themselves or other accounts to Enterprise Admins. This should only be done for specific tasks that will have an impact on the entire forest. Once the task is complete, the account should be removed from Enterprise Admins.

So, yes, these staff can now intercept all the passwords in the domain, make off with the security database, and basically hose the entire domain or any object or system or data within it at a slip of the finger. Good luck finding out what the intended permissions for them actually were. I've seen this sort of thing done when the real intention was that some support staff be given the right to create user accounts. And even if you delegate the rights to create and manage users, that kind of thing should be targeted to specific OUs, not at the domain root.