Local Administrator, Domain Admin, and Enterprise Admin: Separating authority scopes

1. Core mechanism

The decision is made when performing access control on a machine: the group SIDs in the token are compared with the permissions of the target resource. The boundary of this lesson is the SID, scope, and nesting chain of the three management identities; The access check mechanic itself is in 05.01, the delegation ACEs are in 05.05, the AdminSDHolder/SDProp that protects these IDs is in 05.06. The question here is not 'what can this group do?', but 'where and how does this group settle and gain authority?'

Interfaces and specifications

• Administrators (Builtin Local): SID S-1-5-32-544; a local SAM group on a member host, but a directory group in AD’s CN=Builtin container on a DC. On a domain controller, members have full access to the DC and unrestricted administrative access to the domain.
• Domain Admins: SID S-1-5-21-<domain>-512; global group; specific to its domain and nested by default into that domain’s Builtin Administrators group and the local Administrators groups of domain-joined computers.
• Enterprise Admins: SID S-1-5-21-<forest-root>-519; It is found only in the forest root domain; It is added to the Administrators group of each domain in the forest; Its scope is forest-wide.
• Membership change events (Audit Security Group Management): 4732 (member added) / 4733 (member removed) for local group; 4728/4729 for global group; for universal group 4756/4757.
• Group scope types: Domain Local, Global and Universal; The RID and group scope of a SID determine which domain/forest boundary the membership is valid for.

Three identities, three different borders

Although their names are similar, these three groups live in different borders. On member servers and workstations, Administrators is a machine-specific group in the local SAM, so two hosts can have different members. On a DC, the same S-1-5-32-544 SID identifies the Builtin Local Administrators group in AD’s Builtin container. Domain Admins belong to a single domain and are recognized throughout that domain. Enterprise Admins, on the other hand, are located only in the root domain of the forest and cover the entire forest.

This boundary difference appears in the SID structure. Administrators carry a built-in SID that is the same on all Windows installations: S-1-5-32-544. Domain Admins and Enterprise Admins are named with a domain-specific SID prefix (S-1-5-21-<domain identifier>) and a fixed RID (512 and 519); That is, each domain has its own Domain Admins SID, but the RID is always 512.

It is a critical detail that Enterprise Admins are only in the root domain. This group with RID 519 is not found locally in a subdomain; Its forest-wide power comes from being present in the root domain and added to each domain's Administrators group.

Power comes from nesting

What makes a group powerful is not its name, but which groups it is placed in. Domain Admins are powerful domain-wide because each machine that joins the domain adds Domain Admins to its local Administrators group upon installation. In other words, the Domain Admins member becomes an administrator not because permission is granted directly to each machine, but because it is within the Administrators of each machine.

Enterprise Admins is a default member of each domain’s Builtin Administrators group, which grants broad directory/DC administration. This is not a nesting path into every member computer’s local Administrators group. Those machine-local memberships are separate; distinguish direct scope from the potential impact of forest-level administration.

To evaluate an administrative membership path, inspect security-enabled groups, compatible scopes and enabled SIDs in the actual access token. Directory nesting alone is not proof of successful authorization. Existing tokens are snapshots and do not automatically change when membership is removed.

Domain controller is a special case

On a member server, Administrators grants full authority only on that machine. A DC has no separate SAM account domain; its account and group information is stored in Active Directory. Therefore, the DC’s S-1-5-32-544 Builtin Administrators group is not a local SAM group: it is the Builtin Local group in the directory. Microsoft documents that its members have full access to domain controllers and unrestricted administrative access to the domain.

By default, Domain Admins is a member of the domain’s Builtin Administrators group and the local Administrators group on every domain-joined computer, including DCs. This is why Domain Admins has domain-wide administrative power. Builtin Administrators membership is not the same SID or group identity as Domain Admins; however, the extensive rights granted to it on a DC make its potential impact service-administrator level.

In the example, a service account is added to Builtin\Administrators (S-1-5-32-544) on a DC. This targets the Builtin Local group in AD rather than a separate SAM group; it grants very high access to DCs and the domain administration surface. Event 4732 records the membership change but does not by itself enumerate every operation the account can perform on every directory object.

Scope types and SID reading

AD DS group scope determines where membership is valid. In addition to Domain Local, Global, and Universal, groups in the Builtin container use the immutable Builtin Local scope. Domain Admins is a Global group: its members come from its own domain but can be used throughout the entire domain (and wherever it is added). Enterprise Admins can have Universal scope in a forest whose root domain is not in mixed mode and Global scope in a forest whose root domain is in legacy mixed mode; verify the group’s actual groupType. Administrators is a Builtin Local group in the BUILTIN domain; on a member host it is tied to the machine SAM, while on a DC it is in the directory’s Builtin container.

Reading the SID confirms this distinction. SIDs starting with S-1-5-32, such as S-1-5-32-544, belong to the built-in domain and are the same on all systems. SIDs such as S-1-5-21-...-512 / -519 are linked to a domain ID; The RID part (512, 519) tells you exactly which built-in management role the group has.

Therefore, when reading the SID list in a token, both the structure of the SID (built-in or domain-specific) and its RID are important. The same 'Administrators' tag may correspond to different SIDs; The SID determines the decision, not the name on the screen. Ticket/PAC renewal and service-token refresh are separate: replacing a ticket does not rewrite an existing service token or close an application session.

State and data flow

1. Each domain has its own Domain Admins group (RID 512). Enterprise Admins (RID 519) exists only in the forest root domain; their SID prefixes and scopes differ.
2. Domain Admins is nested by default into the domain’s Builtin Administrators group and the local Administrators groups of domain-joined computers; a DC’s Administrators group is the Builtin Local group in AD.
3. Enterprise Admins at the forest root are added to the Administrators group of each domain in the forest; thus carries forest-wide management authority.
4. A fresh token includes applicable enabled security-group SIDs from scope-compatible membership paths. A nested distribution-group path is not an authorization-SID grant, even if it affects protected-account enumeration.
5. The example adds a service account to the domain’s Builtin Administrators group. Event 4732 records TargetSid=S-1-5-32-544 and the added MemberSid on a DC, under applicable auditing.
6. Compare the directory change with a newly created token. Event 4732 records membership change; it does not prove that an existing process token gained the SID or that a resource operation succeeded.
7. In the audit, the actual set of administrators on a machine is found by disentangling the direct members plus members of nested groups such as Domain/Enterprise Admins.
8. Removing membership changes the directory. Existing process tokens do not change retroactively; tickets and open service sessions have separate lifetimes. Reassess fresh tokens against current membership and handle active sessions separately when revocation must be immediate.

2. Exploitation

Broken trust assumption

The broken assumption is: 'Whoever is in a machine's Administrators group are the administrators; Just looking at the list is enough.' In reality, group membership is transitive: within the Administrators group there may be Domain Admins, and within Domain Admins there may be other groups or users. The direct member list is just the visible end of the actual admin set; The real authority is reserved in the nested membership chain.

Technical prerequisites

• In order to add members to the target group, write permissions are required on that group; For example, adding to Domain Admins already requires authority at the Domain Admins level (or equivalent delegation). So this is not an upgrade, but mostly an extension/permanence of the acquired authority.
• Adding to Local Administrators requires local administrator authority on the target machine; This is a narrower prerequisite than domain level authority, but if that machine is a DC the effect rises to the domain level.
• To abuse pass-through membership: it is enough to control any link in the chain (e.g. a group nested in Domain Admins); It is not necessary to be a direct member of the top group.
• The Enterprise Admins effect requires access to the forest root domain; Intervening from the subdomain to the EA group of the root domain requires a separate authority that exceeds the domain limit.

Exploitation mechanism

Gaining authority often comes not from the most visible place (direct membership in the top group) but from a less monitored link in the chain. If the Administrators group contains Domain Admins, and Domain Admins perhaps contains another business group, anyone who controls that subgroup is effectively an administrator on all machines; whereas Domain Admins' direct member list may look clean. The same pattern is repeated at the forest level with Enterprise Admins: because a single group in the root domain resides in each domain's Administrators, a path to that group becomes forest-wide access. The essence of the mechanism is not a new vulnerability; The intended behavior of group scope and nesting is overlooked by looking directly at the member list in the audit. The protocol works as expected; The wrong thing to do is to answer the question 'who is the manager' without solving transitive membership.

Why nested membership hides

Another group can be placed inside a security group. This makes management easier but harder to audit: While the Domain Admins' direct member list may be short and familiar, a group within a group within it may be tying a casual user to the top.

That's why the attack surface looks at the weakest link in the chain, not the group at the top. Controlling a business group with loose ownership/permissions nested within Domain Admins gives the same result as being a member of Domain Admins directly, but attracts much less attention.

That's why the real director set is always calculated transitively, that is, by resolving all nesting. The 'Effective members' account can be much larger than the direct members list and that's where the real risk lies.

Scope difference scales impact

Adding to Local Administrators affects a single machine (unless that machine is a DC). Being added to Domain Admins affects every machine in the domain. Being added to Enterprise Admins affects every domain in the forest. The same 'add a member to a group' process scales from a machine to a forest, depending on which group it is.

This difference in scale explains why the same event (member added) has very different significance. Adding to local Administrators with 4732 and adding to Domain/Enterprise Admins (4728/4756) are technically similar records, but their domains are very different.

Enterprise Admins are especially dangerous because they are at the top of the forest trust limit. Forest is the safety margin itself; Controlling EA means controlling not a single domain, but the entire network of trust relationships.

Where is it limited?

This is not a vulnerability exploit, but a trap on the visibility side of the designed authorization model. Adding members to groups still requires authorization; The issue is not unauthorized access, but the concealment of existing authority with nested membership and misreading its true scope.

The local Administrators scope is truly local: being in the Administrators of a member server does not grant automatic authorization on another machine. Domain/Enterprise Admins' broad influence comes from default additions to local groups; In an environment with these additions removed, the scope is reduced.

Since Enterprise Admins exists only in the root domain, the effects of EA and Domain Admins may practically overlap in a single-domain forest that is not multi-domain. The model shows the real separation in multi-domain forests.

3. Defense & Detection

Telemetry scope

• The Audit Security Group Management subcategory generates events for adding/removing members to security groups; 4732/4733 for local group, 4728/4729 for global group, 4756/4757 for universal group.
• A local Administrators change is recorded as 4732; a global-group addition as 4728; and a universal-group addition as 4756. Enterprise Admins is Universal in a forest whose root domain is not in mixed mode, so expect 4756; in a forest whose root domain is in legacy mixed mode it can be Global, in which case use 4728. Choose the event from the actual scope, not the group name.
• These events are generated at the location of the target group; Changes in domain groups are saved in the domain controller, and changes in local machine groups are saved in the relevant machine.
• Events alone are not enough to see the real ruling group; Periodically, the nested membership of groups is resolved and compared directly to the member list.
• Membership changes to privileged groups are read with the adminCount/AdminSDHolder signals at 05.06; Protecting an account usually follows such a membership change.

Events and relevant fields

• 4732 / TargetUserName and TargetSid: changing group. For Local Administrators, TargetSid is S-1-5-32-544 and TargetDomainName is Builtin; This ensures that the event is the built-in local administrator group.
• 4732 / MemberName and MemberSid: MemberName is a distinguished name for applicable domain accounts or “-” for cases described by the event schema; MemberSid is the added principal’s SID. Do not infer a SID-valued MemberName without a version-specific event sample.
• 4732 / SubjectUserName and SubjectUserSid: principal who made the change. On privileged group changes, this field is compared to the expected administrator set.
• 4732 / SubjectLogonId: local identifier of the session that made the change; used for association with other events in the same session.
• 4728 records additions to global groups and 4756 additions to universal groups. Domain Admins is Global and uses 4728; Enterprise Admins is Universal in a forest whose root domain is not in mixed mode and uses 4756, but can be Global in a legacy mixed-mode configuration and then uses 4728. Verify the exact field list against the Windows event schema in use.
• Group scope/RID: The structure of the TargetSid (built-in S-1-5-32-544 vs domain S-1-5-21-...-512/-519) determines which management layer the event belongs to and directs prioritization.

Why is the direct list misleading?

The 'members' tab of a group only shows direct members. However, real authority is transitive: a group that becomes a direct member binds its own members to that authority. So 'Who's at Domain Admins?' The correct answer to the question is the effective member list calculated by solving all nesting.

This distinction is the most frequently overlooked point in auditing. While the direct list looks clean, two levels deep a casual user may be tied to the top. The attacker targets exactly this invisible ring.

In practice, the correct approach is to read group membership as a tree: each member group is also opened and users at the bottom are listed as 'real administrators'. This list is the main target of monitoring and restriction.

SID and RID decide

The question of which SID corresponds to the 'Administrators' label on the screen is important. The built-in local group is S-1-5-32-544 and is the same on all systems; Domain-specific management groups are in the format S-1-5-21-<domain>-512 (Domain Admins) and -519 (Enterprise Admins).

In event and token analysis, the decision is always made on the SID, not the name. The name can be localized or changed; SID and RID are fixed. So in an event like 4732, the TargetSid field is the actual data that makes sure which management layer is affected.

In our case, TargetSid is S-1-5-32-544 and TargetDomainName is Builtin; This ensures that the change is in the local Administrators group of the machine/DC. When the same analysis is repeated for RID 512/519, it is seen that the effect increases to the domain/forest scale.

Detection logic · Sigma

title: Membership additions - local Administrators and all global or universal groups
id: 2c9f5d3b-7a41-4e88-9f0c-1b6e2a4d8c73
status: experimental
description: >
  Broad membership-change inventory. The local branch targets built-in
  Administrators; the domain branch includes ordinary global and universal
  security groups. This is not a privileged-domain-group filter.
logsource:
  product: windows
  service: security
detection:
  local_admins:
    EventID: 4732
    TargetSid: 'S-1-5-32-544'
  domain_additions:
    EventID:
      - 4728
      - 4756
  condition: local_admins or domain_additions
fields:
  - TargetUserName
  - TargetSid
  - MemberName
  - MemberSid
  - SubjectUserName
falsepositives:
  - Expected business-group provisioning
  - Approved administrative membership changes
level: low

Query assumptions

• 4732/4728/4756 are only generated if the Audit Security Group Management subcategory is enabled for Success; If it is off, the rule sees nothing.
• Only local_admins targets a specific group SID. domain_additions includes every collected4728/4756, including ordinary business groups; EventID does not establish privilege.
• For privileged-domain-group review, compare the target group with an environment-maintained SID inventory, including privileged nesting paths. A name or event scope alone is not that inventory. The current rule intentionally does not perform this comparison.
• The exact field list of events 4728/4756 has not been verified in detail from the primary Microsoft documentation; The rule targets these events at the EventID level and does not perform field-based fine filtering. Field names must be validated against the schema of the version used before production.
• MemberName can come in the form of a DN or SID; MemberSid is a more stable field to identify the added account.
• This rule has not been run on a real SIEM; event meaning and 4732 fields are based on the primary source, 4728/4756 field details are not validated and should be validated against the schema of the version used.

False positives

• Normal business-group membership additions are expected in the broad domain branch; a match is not an incident.
• Planned admin on-boarding: adding a new admin to the privileged group produces this record and is an expected change.
• Expected group membership changes of provisioning/automation accounts.
• Short-term, justified addition of a service account to local Administrators (e.g. an installation window).
• Negative example: If Audit Security Group Management is turned off, membership change produces no events; No alarm does not mean 'no change'. The rule is a layer of visibility, it is not a substitute for a periodic audit that resolves actual membership.

Hardening

• Periodically resolve the membership of privileged groups (Administrators, Domain Admins, Enterprise Admins) in a nested manner and compare them directly with the member list; the actual master set is often larger than the direct list.
• Keep Domain Admins and Enterprise Admins membership to a minimum and normally leave Enterprise Admins blank; EA should only be temporarily filled for forest-scale, truly necessary operations.
• Control groups nested in privileged groups; A business group within Domain Admins effectively makes anyone who controls that group a Domain Admin. Simplify nesting.
• Enable the Audit Security Group Management (Success) subcategory on domain controllers and critical member servers; Without 4732/4728/4756 membership changes will not appear.
• Prioritize by SID: Domain groups carrying TargetSid S-1-5-32-544 (local Administrators, especially on DC) and RID 512/519 are the highest priority monitoring targets.
• Verification step: add a test service account to Builtin\Administrators, see that event 4732 is generated in DC with TargetSid=S-1-5-32-544, MemberSid=<account>; Then add it to Domain Admins and compare what 4728 is generated and note the domain differences.

Read the examples

<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event"><System><Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-a5ba-3e3b0328c30d}"/><EventID>4732</EventID><Version>0</Version><Level>0</Level><Task>13826</Task><Opcode>0</Opcode><Keywords>0x8020000000000000</Keywords><TimeCreated SystemTime="2026-09-29T08:14:07.552117Z"/><EventRecordID>884213</EventRecordID><Correlation/><Execution ProcessID="712" ThreadID="4020"/><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><EventData><Data Name="MemberName">CN=svc-backup,OU=Service Accounts,DC=outreason,DC=example</Data><Data Name="MemberSid">S-1-5-21-1470163944-2039885437-3358247602-5110</Data><Data Name="TargetUserName">Administrators</Data><Data Name="TargetDomainName">Builtin</Data><Data Name="TargetSid">S-1-5-32-544</Data><Data Name="SubjectUserSid">S-1-5-21-1470163944-2039885437-3358247602-500</Data><Data Name="SubjectUserName">Administrator</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x3e7</Data><Data Name="PrivilegeList">-</Data></EventData></Event>

Two reality checks

Assumption: Just looking at the member list of a machine's Administrators group is enough to see all administrators on that machine.

In fact: Group membership is transitive. The Administrators group typically includes Domain Admins; Domain Admins may also include other groups or users. So the direct member list is just the visible end of the real director set; effective (nested resolved) membership is often much larger and the real risk lies in these invisible rings.

Assumption: Local Administrators, Domain Admins and Enterprise Admins are different names for the same thing; they all mean 'manager'.

In fact: The three groups have different scopes and SIDs. On member hosts, Administrators is a machine-specific built-in group (S-1-5-32-544); on DCs, the same SID identifies AD’s Builtin Local Administrators group. Domain Admins is a global group for one domain (RID 512), nested into that domain’s Builtin Administrators group and each joined computer’s local Administrators group. Enterprise Admins exists only in the forest root (RID 519) and is added to each domain’s Administrators group. Builtin Administrators on a DC has very high domain-administration impact, but it is not the same group identity as Domain Admins.

Sources

• Microsoft · Security identifiers (well-known SIDs)
  Built-in Administrators S-1-5-32-544; Domain Admins S-1-5-21-<domain>-512; Enterprise Admins S-1-5-21-<root domain>-519 and RID/scope explanations.
• Microsoft · Active Directory security groups (Domain Admins / Enterprise Admins / Administrators)
  Domain Admins is Global and is added to each machine's Administrators; Enterprise Admins exists only in the forest root and is added to each domain's Administrators; Administrators has built-in local scope.; Administrators: S-1-5-32-544, Builtin Local, CN=Builtin; when hosted on a domain controller, members have unrestricted access to the domain and full access to domain controllers.
• Microsoft · 4732(S) A member was added to a security-enabled local group
  Subcategory Audit Security Group Management; Task 13826; Version 0; EventData fields MemberName, MemberSid, TargetUserName, TargetDomainName, TargetSid, SubjectUserName, SubjectUserSid, SubjectLogonId, PrivilegeList.
• Microsoft Open Specifications · MS-ADTS Enterprise Administrators group
  Enterprise Admins exists only in the forest root; its groupType is Universal when the root domain is not mixed-mode and Global when it is mixed-mode.
• Microsoft · Audit Security Group Management
  Event families: local 4732/4733, global 4728/4729, universal 4756/4757.
• Microsoft Win32 · Built-in and Account Domains
  Member computer SAM stores built-in/account domains; domain controllers have neither built-in nor account domains and use AD DS rather than a separate SAM database.
• SigmaHQ · Sigma rules specification
  Detection maps/lists, condition, field mapping and level; no backend conversion/runtime validation