"Admin Free" Active Directory and Windows, Part 1- Understanding Privileged Groups in AD

Admin-Free Active Directory

If You Haven't Been Hacked, You May Not Be Looking Closely Enough

Clearly, I am not the most conscientious blogger, as can be observed by the lack of any posting regularity here. This is in part due to the fact that for the past few years, the team on which I work has been busy helping compromised customers respond to a specific class of attacks known as Advanced Persistent Threat (APT) attacks. Because there is much debate in the security community about what is or is not an APT, one of our sibling teams has coined a more general term to describe a broader classification of attacks, which is Determined Human Adversaries (DHA). Regardless of whether we're talking about APTs or DHAs, however, the important part is this: compromise has become the norm rather than the exception. The report to which I just linked is consistent with what we've been seeing in our work- even companies who thought they were "bulletproof" have discovered that perception and reality can be quite different. Something that is specific to the attacks with which my team primarily deals is that these attacks focus not on destruction, but on exfiltration of an organization's intellectual property (IP). There are additional types of attackers out there, however, and their interests may be very different, whether they be monetary theft, denial of service, defacement or destruction of the computing environment. In the end, it doesn't really matter what motivates the attackers who may have targeted you- what matters is how easily they can penetrate and compromise your environment, and how deep and broad the compromise is.

So, now that that small bit of background is out of the way, on to the important bits. As I said, my team has been working with one compromised organization after another, and if there is a single factor that has been the tipping point between a breach that can be contained and a breach that takes over the entire environment, it is how tightly the company has locked down privileged accounts in their environments. This is by no means the only factor in the severity of a compromise, but in one customer after another, what we've seen is that it is via control of the most privileged accounts that attackers have succeeded in wholesale compromise rather than picking around the edges with piecemeal success.

Where to Begin?

Since the inception of Active Directory, I have been a proponent of having no Domain Admins (DAs), no Enterprise Admins (EAs) and no Built-in Administrators (BA)- that's right, zero admins. I said this long before I joined Microsoft as a full-time employee (FTE), and I haven't changed my mind in the years that I've been an FTE. It has always been possible to design and deploy an Active Directory implementation with privileges delegated to various groups and accounts and no use of the "canned" privileged AD groups that I just mentioned (DA/EA/Admins). However, it has also been fairly tedious to build and difficult to maintain without additional tooling.

In hopes of helping companies to significantly increase the security of their infrastructures, I am now attempting to post a series of posts on the subject of "admin free" Active Directory, and if I manage to keep this exercise rolling, I'll then attempt to address admin-free Windows, as well. There's obviously a lot more than just Windows at play in most environments, but Active Directory is ubiquitous, so that's where I'm starting. In this first post, I'm keeping it pretty simple and will provide some basic information about the most privileged groups in Active Directory, including the depth and breadth of their privilege. I have found that the differences between each of these groups are often misunderstood, and the first step in addressing the problem is understanding the problem. What I'm posting below is text that I have written and given to a number of customers in the past, usually as part of an Active Directory Security Assessment (ADSA), which is an assessment built by our team over the past several years.

Built-in Privileged Accounts and Groups

Active Directory (as a product) is designed in a manner that is intended to facilitate delegation of administration and the principle of least privilege in assigning rights and permissions. “Regular” users who have accounts in an Active Directory domain are, by default, able to read much of what is stored in the directory, but are able to change only a very limited set of data in the directory. Users who require additional privilege can be granted membership in various “privileged” groups that are built into the directory so that they may perform specific tasks related to their roles, but cannot perform tasks that are not relevant to their duties.

Within AD, there are three built-in groups that are the highest privilege groups in the directory- Enterprise Admins, Domain Admins and Administrators. The following describes the default configuration and capabilities of each of these groups:

Highest-Privilege Groups in Active Directory

Enterprise Admins

Enterprise Admins is a group that exists only in the forest root domain, and by default, it is a member of the Built-in Administrators group in all domains in the forest. The built-in Administrator account in the forest root domain is the only default member of the Enterprise Admins group. Enterprise Admins are granted rights and permissions that allow them to effect forest-wide changes, meaning changes that affect all domains in the forest, such as adding or removing domains, establishing forest trusts, or raising forest functional levels. In a properly designed and implemented delegation model, Enterprise Admin membership is required only when first constructing the forest or when making certain forest-wide changes.

Domain Admins

Each domain in a forest has its own Domain Admins group, which is a member of that domain’s Built-in Administrators group as well as a member of the local Administrators group on every machine that is joined to the domain. The only default member of the Domain Admins group for a domain is the built-in Administrator account for that domain. Domain Admins are “all-powerful” within their domains, while Enterprise Admins have forest-wide privilege. In a properly designed and implemented delegation model, Domain Admin membership should be required only in “break glass” scenarios, meaning situations in which an account with high levels of privilege on every machine in the domain is needed. While native Active Directory delegation mechanisms do allow delegation to the extent that it is possible to use Domain Admin accounts only in emergency scenarios, constructing an effective delegation model can be time-consuming and many organizations leverage third-party tools to expedite the process.

Administrators

The third group, Administrators, is the domain local group into which Domain Admins and Enterprise Admins are nested, and it is this group that is granted many of the direct rights and permissions in the directory and on domain controllers. However, the Administrators group for a domain does not have any privileges to member servers or to workstations- membership in the machines’ localAdministrators group is where local privilege is granted (and Domain Admins are members of all domain-joined machines’ local Administrators groups by default).

Note:

While these are the default configurations of these privileged groups, the reality is that a member of any one of the three groups may manipulate the directory to gain membership in any of the other groups. In some cases, it is trivial to achieve, while in others it is more difficult, but from the perspective of potential privilege, all three groups should be considered effectively equivalent.

Schema Admins

A fourth highly-privileged group, Schema Admins, exists only in the forest root domain (by default) and has only that domain’s built-in Administrator account as a default member, similar to the Enterprise Admins group. The Schema Admins group is intended to be populated only occasionally (when modification of the Active Directory schema is required), and temporarily.

Built-in and Default Groups in Active Directory

The table below provides some general information about Built-in and Default groups in Active Directory

I think that's enough for now. Stay tuned for further information, and rest assured, this isn't the only topic area of concern when we're talking about these kinds of attacks. If I manage to plow through my "admin free" series, the next series is going to talk about all those legacy systems and applications in your environment. If you could eliminate legacy systems and software and implement appropriate role-based access controls (RBAC) so that you have an admin-free environment, you could reduce your attack surface by a significant percentage.

As always, anything in this blog is my opinion, based on my experiences. You should not take what I write as being representative of Microsoft policy, recommendation or best practice, because I don't have the authority to define any of those things. What I do have, however, is experience and opinion, and nothing I say should contradict any Microsoft recommendations- I just build on top of them. And remember- I'm a security nerd, so you may read some of what I write and think that it's overkill. That's absolutely your prerogative.

Thanks,

Laura