A: The goal of any AD administrative delegation model is to ensure that delegated administrators can't gain sufficient rights to elevate their own privileges to those of a full administrator, such as a domain or enterprise administrator. Delegated administrators should only be granted the fewest privileges possible to perform the administrative tasks they've been delegated to do—no more, no less. If the role of a helpdesk operator is to reset users' passwords, there's no need to give this group full control over an Organizational Unit (OU) containing all user accounts, allowing them to allow the helpdesk operator to make many other changes to user accounts and other objects in the same OU as well. This is commonly referred to as the principle of least privilege, and it's a general security best practice.

The AD access control model allows you to implement most administrative roles in such a way that no AD privilege elevation is possible, but there are certain roles where this can't be guaranteed because of the AD and Windows OS security model. Enterprise Admins, Schema Admins, Domain Admins, and Administrators for example are highly privileged groups, whose members have complete control over the forest or the domain in which they reside.

But there are also other default AD groups that give accounts the capability for an elevation-of-privilege attack against AD. Although this would have to be performed via a malicious act, either intentionally or not (for example by leveraging a virus), members of a group such as Server Operators can elevate their privileges fairly easily to become Administrators of a domain controller (DC), the whole domain, or the whole forest. Members of the Server Operators group can log on locally to DCs and perform critical tasks such as backup and restore of the DC. More importantly, they have sufficient privileges to change and install new binaries on a DC, which allows them to inject code to the DC that's executed with higher privileges than the Server Operators group has itself. Such code could add the user to a more highly privileged group. Since the members of the Account Operators group control the membership of the Server Operators group, the same risk applies to these users.

That is why it is a best practice to differentiate between two types of administrators for any AD administrative delegation model:

  • Service Administrators

—        Members of groups that grant sufficient rights to allow physical access to DCs, perform configuration changes to the AD (e.g., security, replication changes), have administrative rights over any DC, or can manage any Group Policy that affects DCs (these are domain- or site-level GPOs) are considered service administrators.

—        Members of the Active Directory groups listed in the table below are considered service administrators by default.







Active Directory Group Name












Default Administrative Scope












Enterprise Admins












Forest












Schema Admins












Forest












Administrators












Domain












Domain Admins












Domain












Server Operators












Domain












Account Operators












Domain












Backup Operators












Domain












Printer Operators












Domain






—        Members of custom groups that grant similar permissions to those named above (for example, full control of an AD site, which allows site-level group policy management), must also be considered service administrators.

  • Data Administrators

—        Members of custom-defined groups that are only granted permissions to control objects within certain OUs and that have no permission to directly administer a domain controller are considered data administrators. These custom-defined groups include the groups created for computer and user administration within an OU, group-membership management, or the management of specific member servers.

Any service administrator in an AD forest must be highly trusted by the company that owns the forest. A company must consciously accept the risk for the potential of an elevation-of-privilege attack and should implement appropriate means to audit the activity of service administrators. Also, the groups that grant service administration privileges should be tightly controlled and monitored so that changes do not go unnoticed. Ideally, AD service administration should completely controlled by only using the following default administration groups: Enterprise Admins, Schema Admins, Domain Admins and Administrators. But overall, the usage of service administrator groups should always be avoided and instead be implemented at the OU level via separate custom-defined data administrator groups.