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.
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.
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:
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.
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.
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’ local Administrators group is where local privilege is granted (and Domain Admins are members of all domain-joined machines’ local Administrators groups by default).
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.
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.
The table below provides some general information about Built-in and Default groups in Active Directory
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.
Domain Local Security Group
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.
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.
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.
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.
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.
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.
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.
Members of this group have administrative access to the DNS Server service. This group has no default members.
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).
Global Security Group
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.
This group contains all workstations and servers joined to the domain. By default, any computer account created becomes a member of this group automatically.
This group contains all domain controllers in the domain.
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.
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).
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.
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: http://blogs.technet.com/b/janelewis/archive/2010/04/30/giving-non-administrators-permission-to-read-event-logs-windows-2003-and-windows-2008.aspx
Group Policy Creator Owners
Members in this group can create and modify group policy domain wide.
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
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.
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.
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.
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.
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.
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).
RAS and IAS Servers
Servers in this group are permitted access to the remote access properties of users
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.
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.
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.
Universal Security Group
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.
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.
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.
Notice Authenticated Users and Interactive Users weren't in the table.
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.
Nice article. Thanks