Forgotten privileged groups: Operators, DnsAdmins and other quiet paths to domain admin
Privileged account reviews often stop at Domain Admins. Yet several built-in groups, inherited from the early days of Windows NT, provide direct paths to controlling domain controllers. They are rarely monitored and sometimes generously populated.
Why these groups are a problem
The "Operators" groups were designed to delegate operational tasks without handing over full control. In practice, their rights on domain controllers are enough to gain full control. They are protected by AdminSDHolder, which confirms that Microsoft itself considers them sensitive.
Group by group
| Group | Why it is dangerous |
|---|---|
| Account Operators | Creates and modifies most unprotected users and groups, and can log on locally to domain controllers by default. |
| Server Operators | Logs on to domain controllers, manages services, backs up and restores files: changing a service that runs as SYSTEM is enough. |
| Backup Operators | The backup privilege allows reading any file, including a domain controller's NTDS database and registry hives. |
| Print Operators | Logs on to domain controllers and manages printer drivers, historically linked to driver loading. |
| DnsAdmins | Can configure the DNS service, which runs as SYSTEM on DNS-hosting domain controllers; a plugin setting allows code to be loaded into it. |
| Schema Admins | Modifies the forest schema, a rare and largely irreversible operation. |
| Enterprise Admins | Full control over every domain in the forest. |
| Group Policy Creator Owners | Creates GPOs and owns them; combined with a link right, that becomes an attack path. |
The target: empty groups
The common recommendation, reflected in Microsoft's AD hardening guidance, is to keep Account Operators, Server Operators, Backup Operators and Print Operators empty. The related tasks are delegated granularly on OUs or through dedicated tools. Schema Admins and Enterprise Admins should only be populated during a planned change, then emptied again.
DnsAdmins is a special case: treat it as a tier 0 group, limited to a few dedicated admin accounts. The same logic applies to backup accounts: the agent backing up domain controllers needs high privileges, so it must be protected as a tier 0 account.
Common trap. Nested membership. An "IT-Infra" group that is a member of Server Operators makes all its members, and the members of its subgroups, able to administer domain controllers. Always check recursive membership.
'Account Operators','Server Operators','Backup Operators',
'Print Operators','DnsAdmins','Schema Admins','Enterprise Admins',
'Group Policy Creator Owners' | ForEach-Object {
$g = $_
Get-ADGroupMember -Identity $g -Recursive |
Select-Object @{n='Group';e={$g}}, SamAccountName, objectClass
}
Monitoring changes
Any addition to one of these groups should raise an alert: events 4728, 4732 and 4756 depending on the group scope. A legitimate addition is rare and planned; an unexpected one is a strong signal.
What an audit checks
- Recursive membership of every privileged built-in group.
- Orphaned accounts whose
adminCountis still 1. - Alerts on changes to these groups.
- A written justification for every remaining member.