"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

Group	Description	Notes
Account Operators	Members of this group can create, modify, and delete accounts for users, groups, and computers located in the Users or Computers containers and organizational units in the domain, except the Domain Controllers organizational unit. Members of this group do not have permission to modify the Administrators or the Domain Admins groups, nor do they have permission to modify the accounts for members of those groups. Members of this group can log on locally to domain controllers in the domain and shut them down. Because this group has significant power in the domain, add users with caution. Account Operators cannot, by default, modify membership of groups protected by AdminSDHolder.	Default user rights: Allow log on locally; Shut down the system. Builtin container Domain Local Security Group
Administrators	Members of this group have full control of all domain controllers in the domain. By default, the Domain Admins and Enterprise Admins groups are members of the Administrators group. The Administrator account is also a default member. Because this group has full control in the domain, add users with caution.	Default user rights: Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. Builtin Container Domain Local Security Group
Backup Operators	Members of this group can back up and restore all files on domain controllers in the domain, regardless of their own individual permissions on those files. Backup Operators can also log on to domain controllers and shut them down. This group has no default members. Because this group has significant power on domain controllers, add users with caution.	Default user rights: Back up files and directories; Allow log on locally; Restore files and directories; Shut down the system. Builtin Container Domain Local Security Group
Cert Publishers	Members of this group are permitted to publish certificates for users and computers to the directory. Typically, certification authority (CA) servers are placed into this group in each domain to which they may publish certificates.	Users Container Domain Local Security Group
Cryptographic Operators (Windows Vista SP1 and above)	FIPS 140-2 defines a “Crypto Officer” role, which is represented by the Cryptographic Operators group in Windows, first introduced in Windows Vista SP1. When the "System cryptography: Use FIPS compliant algorithms for encryption, hashing, and signing" security setting is configured in local or group policy objects, only members of the Cryptographic Operators group or the Administrators group can configure Cryptography Next Generation (CNG) settings by default. Specifically, Cryptographic Operators can edit the cryptographic settings in the IPsec policy of Windows Firewall with Advanced Security (WFAS)	Applicable only when FIPS-compliant encryption is enforced. Builtin Container Domain Local Security Group
Debugger Users	The presence of a Debugger Users group indicates that debugging tools have been installed on the system, whether via Visual Studio, SQL, Office or other applications that require and support a debugging environment. This group allows remote debugging access to remote machines. When this group exists at the domain level, it indicates that such an application has been installed on a domain controller. By default, the only member of the Debugger Users group is the Administrator who installed the application. Additionally, the Debugger Users group is only granted Launch and Access permissions to the Machine Debug Manager.	This is neither a built-in nor a default group, but when present in Active Directory, is cause for further investigation.
DHCP Administrators	Members of the DHCP Administrators group can view and modify any settings on the DHCP server. DHCP Administrators can create and delete scopes, add reservations, change option values, create superscopes, or perform any other task required to administer the DHCP server, including export or import of the DHCP server configuration and database. Members of the DHCP Administrators group do not have unlimited administrative rights. For example, if a DHCP server is also configured as a Domain Name System (DNS) server, a member of the DHCP Administrators group can view and modify the DHCP configuration but cannot modify DNS server configuration on the same computer. Because members of the DHCP Administrators group have rights on the local computer only, DHCP Administrators cannot authorize or unauthorize DHCP servers in Active Directory Domain Services (AD DS). Only members of the Domain Admins group can perform this task by default.	Users Container Domain Local Security Group
DHCP Users	Members of the DHCP Users group have read-only access to the server by using the DHCP Microsoft Management Console (MMC) snap-in, which allows them to view, but not to modify, server data, including DHCP server configuration, registry keys, DHCP log files, and the DHCP database. DHCP Users cannot create scopes, modify option values, create reservations or exclusion ranges, or modify the DHCP server configuration in any other way.	Users Container Domain Local Security Group
DnsAdmins	Members of this group have administrative access to the DNS Server service. This group has no default members.	Users Container Domain Local Security Group
DnsUpdateProxy	DNS clients who are permitted to perform dynamic updates on behalf of some other clients (such as DHCP servers performing registrations on behalf of clients that are incapable of performing dynamic DNS registrations).	Users Container Global Security Group
Domain Admins	Members of this group have full control of the domain. By default, this group is a member of the Administrators group on all domain controllers, all domain workstations, and all domain member servers at the time they are joined to the domain. By default, the Administrator account is a member of this group. Because the group has full control in the domain, add users with caution.	Default user rights: Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force a shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. Users Container Global Security Group
Domain Computers	This group contains all workstations and servers joined to the domain. By default, any computer account created becomes a member of this group automatically.	Users Container Global Security Group
Domain Controllers	This group contains all domain controllers in the domain.	Users Container Global Security Group
Domain Guests	Contains all domain guests. By default, the only member of this group is the built-in Guest account for the domain, which is disabled by default and does not receive the Authenticated User SID in its access token if it is enabled and used for logon.	Users Container Global Security Group
Domain Users	This group contains all domain users. By default, any user account created in the domain becomes a member of this group automatically. This group can be used to represent all users in the domain. For example, if you want all domain users to have access to a printer, you can assign permissions for the printer to this group (or add the Domain Users group to a local group, on the print server, that has permissions for the printer).	Users Container Global Security Group
Enterprise Admins (exists only in forest root domain)	Members of this group have full control of all domains in the forest. By default, this group is a member of the Administrators group on all domain controllers in the forest. By default, the Administrator account is a member of this group. Because this group has full control of the forest, add users with caution.	Access this computer from the network; Adjust memory quotas for a process; Back up files and directories; Bypass traverse checking; Change the system time; Create a pagefile; Debug programs; Enable computer and user accounts to be trusted for delegation; Force shutdown from a remote system; Increase scheduling priority; Load and unload device drivers; Allow log on locally; Manage auditing and security log; Modify firmware environment values; Profile single process; Profile system performance; Remove computer from docking station; Restore files and directories; Shut down the system; Take ownership of files or other objects. Users Container Universal Security Group unless domain/forest is Windows 2000 mixed, in which case it is a Global Security Group
Event Log Readers (Windows Server 2008 or later)	Members of this group can read all event logs from local machines when a local machine group is used, and from domain controllers when the domain group is used. This group is introduced at the domain level in Windows Server 2008 and can be used either to grant users the ability to read event logs, or to grant machines to read event logs, in the case of event subscriptions. For customization of event log read access, see: https://blogs.technet.com/b/janelewis/archive/2010/04/30/giving-non-administrators-permission-to-read-event-logs-windows-2003-and-windows-2008.aspx	Builtin Container Domain Local Security Group
Group Policy Creator Owners	Members in this group can create and modify group policy domain wide.	Users Container Global Security Group
Guests	By default, contains the Guest account for the domain (which is disabled by default) and the Domain Guests domain global group. Members of the Guests group have the same rights and permissions as Users do, with the exception of the built-in Guest account, which does not receive the Authenticated Users SID in its access token	Builtin Container Domain Local Security Group
Incoming Forest Trust Builders (exists only in forest root domain)	Members of this group can create one-way, incoming forest trusts to the forest root domain. For example, members of this group residing in Forest A can create a one-way, incoming forest trust from Forest B. This one-way, incoming forest trust allows users in Forest A to access resources located in Forest B. Members of this group are granted the permission Create Inbound Forest Trust on the forest root domain. This group has no default members.	Builtin Container Domain Local Security Group
Network Configuration Operators	Members of this group can make changes to TCP/IP settings and renew and release TCP/IP addresses on domain controllers in the domain. This group has no default members.	Builtin Container Domain Local Security Group
Performance Log Users	Members of this group can manage performance counters, logs and alerts on domain controllers in the domain, locally and from remote clients without being a member of the Administrators group.	Builtin Container Domain Local Security Group
Performance Monitor Users	Members of this group can access performance counter data on domain controllers locally and remotely without being members of the Administrators or Performance Log Users groups.	Builtin Container Domain Local Security Group
Pre-Windows 2000 Compatible Access	Members of this group have read access on all users and groups in the domain. This group is provided for backward compatibility for computers running Windows NT 4.0 and earlier. By default, the special identity Everyone is a member of this group. Add users to this group only if they are running Windows NT 4.0 or earlier.	Default user rights: Access this computer from the network; Bypass traverse checking. Builtin Container Domain Local Security Group
Print Operators	Members of this group can manage, create, share, and delete printers connected to domain controllers in the domain. They can also manage Active Directory printer objects in the domain. Members of this group can log on locally to domain controllers in the domain and shut them down. This group has no default members. Because members of this group can load and unload device drivers on all domain controllers in the domain, add users with caution.	Default user rights: Allow log on locally (to domain controllers); Shut down the system (domain controllers). Builtin Container Domain Local Security Group
RAS and IAS Servers	Servers in this group are permitted access to the remote access properties of users	Users Container Domain Local Security Group
Remote Desktop Users	Members of this group can remotely log on to domain controllers in the domain if granted the right to log on via Terminal Services. This group has no default members.	Builtin Container Domain Local Security Group
Replicator	This group supports directory replication functions and is used by the File Replication service on domain controllers in the domain. This group has no default members. Do not add users to this group.	Builtin Container Domain Local Security Group
Schema Admins (exists only in forest root domain)	Members of this group can modify the Active Directory schema. By default, the Administrator account is a member of this group. Because this group has significant power in the forest, add users with caution.	Users Container Universal Security Group
Server Operators	On domain controllers, members of this group can log on interactively, create and delete shared resources, start and stop some services, back up and restore files, format the hard disk, and shut down the computer. This group has no default members. Because this group has significant power on domain controllers, add users with caution.	Default user rights: Back up files and directories; Change the system time; Force shutdown from a remote system; Allow log on locally; Restore files and directories; Shut down the system. Builtin Container Domain Local Security Group
Users	Members of this group can perform most common tasks, such as running applications, using local and network printers, and locking the server. By default, the Domain Users group, Authenticated Users, and Interactive are members of this group. Therefore, any user account created in the domain becomes a member of this group.	Builtin Container Domain Local Security Group

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

Comments

• Anonymous
  January 01, 2003
  Ed- that's because Authenticated Users and Interactive Users are not "default" or "built-in" groups in AD- they're computed groups. You become a member of those groups by virtue of your activities- they are not manually populated. The groups I enumerated are the groups that can be found in the "Builtin" and "Users" containers in AD, and are groups that you can populate, or that are created as part of installing software on DCs or setting domain-wide configuration options.

• Anonymous
  June 23, 2011
  Notice Authenticated Users and Interactive Users weren't in the table.

• Anonymous
  October 08, 2014
  Nice article. Thanks

• Anonymous
  November 20, 2015
  I maintain a list of links I call "security stuff every Microsoft customer should know" that