Group types, scope, nesting, and AGDLP: How does effective membership form?

1. Core mechanism

This lesson covers how groups become authorizations: the distinction between security and distribution groups, membership and nesting rules of Universal/Global/Domain Local scopes, the AGDLP pattern, and which group SIDs go into the access token at a logon instance. Components of SID and non-reuse at 03.03; The structure of the access token and the access check step are in 05.02; security descriptor/DACL/ACE read at 05.03; The allow/deny/inheritance evaluation is processed at 05.04. The focus here is on how membership is aggregated into the token before it becomes resource access.

Interfaces and specifications

• Group type: security group appears as principal in DACLs and carries permissions; distribution group is not security-enabled and cannot be DACLed (for email distribution only).
• Global groups accept accounts and global groups from their own domain. They can join same-domain global groups, same-forest universal groups and Domain Local groups in applicable trust contexts. Membership scope differs from permission scope.
• Domain Local groups accept same-domain Domain Local groups and accounts, global groups and universal groups from their own or appropriately trusted domains. Resource permissions are confined to their own domain. A universal group’s own membership scope remains its forest; that is separate from joining a Domain Local group in a trusted domain.
• Group scope · Universal: members are account, global and other universal groups from any domain in the forest; membership is maintained in the Global Catalog.
• AGDLP: Account → Global group → Domain Local group → Permission. Accounts are collected in global groups, global groups are nested in domain local groups that carry permissions, permission is given only to the domain local group.
• Effective membership: a token contains the user SID and applicable direct and indirect group SIDs resolved for that logon context. Presence and participation attributes are separate; the relevant groups in this fixture are security-enabled and enabled.
• SID examples: Domain Users is domain SID + RID 513; Built-in Users is S-1-5-32-545. These are common in standard domain-user logons, not guaranteed in every token. Check primaryGroupId, the token host, local-group membership and logon context.

Security group and distribution group are not the same thing

Active Directory recognizes two types of groups. Security group is used to bulk assign permissions and user rights; may appear as principal in a resource's DACL. Distribution group is for the email distribution list only and cannot be put in a DACL as it is not security-enabled, meaning it does not grant any file/object access.

This distinction is important in practice: some of the 'I added to the group but no access' cases are caused by mistaken use of distribution group. Authorization flows only through security-enabled groups; The remainder of this lesson focuses on the scope of security groups.

Three scopes: who can become a member, where it can be allowed

Group scope constrains two separate questions: who can join the group, and where can it receive permissions? A global group collects accounts and global groups from its own domain. It can nevertheless receive resource permissions in other domains under applicable forest/trust conditions. A membership boundary is not the same as a resource boundary.

A Domain Local group collects resource permissions within its own domain. It can contain same-domain Domain Local groups, with accounts, global groups and universal groups also possible under applicable trusted-domain conditions. Keep the two directions distinct: membership inside a universal group is confined to its own forest, while that group joining a Domain Local group in a trusted domain is a different nesting relationship. Global Catalog storage does not replace these rules.

These three scopes can be converted to each other, but conditionally: for example, a global group can be converted to universal if it is not a member of another global group; If a universal group does not contain another universal group, it can be converted to global. The lesson emphasizes which scope can become a member where, rather than the details of the transformation, because this is where the nesting rules come from.

AGDLP: separate role membership from resource permissions

AGDLP is a common group-design model: Account → Global group → Domain Local group → Permission. Accounts join role-based global groups; those groups join the Domain Local group selected for a resource; the resource’s DACL grants permission to that group. A role change becomes a membership change rather than an edit to individual-user entries on every resource.

This pattern scales because permission and identity are separated: the question 'who' is answered in global groups, the question 'what is accessed' in domain local groups. But the same mechanism also creates a trust surface: the domain local group is the actual access door to the resource, and each global/universal group nested within it indirectly distributes the key to that door. This is exactly the chain we follow throughout this lesson.

Our same-domain fixture has u.tunahan → GG-ProjectAtlas → DL-Atlas-Share-RW. The DL group has Change on the Atlas SMB share on FS01 and NTFS Modify on the example file beneath it. Neither DACL needs an entry naming the user; the applicable token can match the group ACE through the DL SID. Passing the share check does not alone establish the file-operation result: the NTFS DACL must also grant the requested right.

Effective membership is collected in access token

In this same-domain fixture, a fresh logon token can contain the user SID, the direct GG-ProjectAtlas SID and the nested DL-Atlas-Share-RW SID. Looking only at memberOf does not enumerate indirect membership or the primary group. An access check uses the relevant token’s SIDs and attributes rather than querying a live directory name list.

An important timing consequence follows: an access token is created during logon. When group membership changes, the token for an already open session is not updated automatically; updated membership appears when a new token is created. So when access still fails or continues after a change, inspect which membership the token carries.

State and data flow

1. The administrator adds the u.tunahan account to the GG-ProjectAtlas global group (role assignment).
2. GG-ProjectAtlas joins DL-Atlas-Share-RW in the same domain. Nesting itself is not a permission assignment.
3. The Atlas SMB share DACL has a Change ACE for DL-Atlas-Share-RW. The file’s NTFS Modify ACE is in a separate security descriptor.
4. This fixture’s fresh logon token collects the user, GG-ProjectAtlas and effective DL-Atlas-Share-RW SIDs. Host and logon context determine other applicable memberships.
5. The share check matches the token’s DL SID against the Change ACE. A file operation separately evaluates the NTFS DACL; share permission alone does not establish Modify access to the file.
6. Removing the user changes the directory chain; the old token remains. Service tickets derived from an old TGT and open resource sessions must also be examined separately.

2. Exploitation

Broken trust assumption

Broken assumption: Group nesting is just a matter of organizing convenience, and a user's access is the sum of the groups you see them directly in. In fact, the transitive SIDs in the token determine access; 'just one Global group' may connect several layers below to a security group with a meaningful permission in the target resource's DACL (typically a Domain Local permission group in AGDLP).

Technical prerequisites

• The actor can add a member to a group whose transitive nesting reaches a security-enabled group with meaningful rights in the target resource's DACL (typically a Domain Local permission group in AGDLP).
• The nesting chain actually reaches the target resource: a group SID in the token must carry a meaningful right in that resource's DACL.
• The affected principal creates a new access token that includes the updated group membership.
• An environment in which group membership changes are not tracked or nesting of high-value groups is not regularly reviewed.

Exploitation mechanism

Access checks use the flattened set of SIDs in the token, not names; that set contains direct and transitive group SIDs. So adding an account to a seemingly innocuous Global group can carry an access path into the account's token if that group reaches a security-enabled group with meaningful rights in the target resource's DACL through several nesting layers. In AGDLP, the permission group is typically Domain Local. Someone who can change group membership can indirectly distribute access through this chain; the effect depends on which groups they can modify, the transitive path, the target ACE, and creation of a new token for the principal. Preventive controls include limiting membership management to least privilege, reviewing nested membership of groups that carry resource rights, and monitoring changes.

Why 'Just a group' is misleading

Looking directly at a user's memberships in an administration panel does not indicate their effective reach. If, after several layers of nesting, a global group is linked to a security group with a meaningful right in the target resource's DACL, a seemingly casual addition to that global group can carry that access path through the transitive SID set. In AGDLP, this permission group is typically Domain Local. Evaluation should ask 'which SIDs are in this account's token, and which of them match rights in the target DACL?'

The second subtlety is whether the chain actually reaches the target resource. Not every nesting automatically means high impact; a security-enabled group SID in the token must carry a meaningful right in the target resource's DACL. Therefore, verify the scope and membership chain as well as the right in the target ACE.

3. Defense & Detection

Telemetry scope

• Group membership changes are recorded in the Audit Security Group Management subcategory; Events 4728/4729 (member added/removed) are generated for global groups, 4732/4733 for domain local groups, and 4756/4757 for universal groups.
• Adding a member to a domain local group (the resource's permission container in AGDLP) is recorded as 4732; The fields of this event give the added member (MemberSid) and the target group (TargetSid) separately, so that 'which principal went into which resource group' can be tracked.
• The access token's group snapshot is generated as 4627 (Group Membership) on the computer where the logon session is created, with Audit Group Membership Success and Audit Logon Success enabled; for an interactive logon this is the computer the user signed in to, while for a network logon it is the computer hosting the resource. 4627 is associated with the 4624 for the same logon and lists the token's group SIDs in GroupMembership.
• 4627 is only available on Windows Server 2016 / Windows 10 and above, and if the group list does not fit into a single event, multiple 4627s are generated (EventIdx/EventCountTotal fields indicate this).

Events and relevant fields

• 4732: MemberSid is the SID of the nested group (e.g. GG-ProjectAtlas); TargetSid is the SID of the domain local group (e.g. DL-Atlas-Share-RW); SubjectUserSid gives the principal who made the change and is correlated to 4624 with SubjectLogonId.
• 4627: TargetLogonId is matched with 4624 of the same logon; The GroupMembership field indicates the set of SIDs that go into the token (e.g. Domain Users 513, Built-in 32-545, and nested group SIDs).
• To prove the effect of a change, read 4732 (membership changed) together with the next 4624+4627 (token snapshot contains change); The logon moment between the two gives when the change becomes access.
• The 4728/4732/4756 distinction tells which scope has changed; In AGDLP, the resource risk is most concentrated on the domain local (4732) and universal (4756) side because the permission usually stops in these containers.

Read the change with snapshot

Evidence that a membership change entered a token and evidence of its effect on a resource are separate. Event 4732 (or 4728/4756 depending on scope) says 'membership changed'; a 4627 matched with the next relevant 4624 shows the GroupMembership SIDs in that logon's token. Whether that snapshot grants access to the target resource also depends on its relevant DACL ACE and the other access-check conditions.

This reading also reduces false alarms: if the change has been made but the affected user has not yet been re-logined, access is still tied to the old token. Snapshot 4627 evidences the difference between 'membership on paper' and 'effective membership in token'.

Detection logic · XPath

*[System[EventID=4732] and EventData[Data[@Name='TargetSid']='S-1-5-21-1002233445-2244556677-3366778899-3220']]

Query assumptions

• The expression selects 4732 additions to the membership of a particular high-value domain local group (here DL-Atlas-Share-RW, RID 3220) in a single Windows Event Log document; It does not perform multi-host correlation.
• Named-field selection only works if EventData/Data/@Name values ​​are flattened with TargetSid/MemberSid names; The domain mapping of the SIEM must be verified.
• It is generated on 4732 domain controllers and related servers; For the alarm to be meaningful, which group SIDs are 'high value' must be defined in advance with an inventory.
• The query was not run on a real DC or SIEM in this session; There is no threshold, no dataset, and no time window.

False positives

• Legitimate role assignments and adding members to groups during onboarding are expected and frequent; single 4732 does not indicate ill will.
• Identity management/automation tools can generate large numbers of 4732s by making bulk membership changes; These should be distinguished as benign baseline.
• Without context (who added it, the rights held by the target group, the privilege of the added principal) the event is a weak signal.
• The absence of event is not security; If the Audit Security Group Management subcategory is turned off, the change will not be saved at all.

Hardening

• Limit principals who can change group membership to least-privilege; Inventory and reduce who can change memberships, especially in domain local and universal groups that carry resources.
• Apply AGDLP discipline: grant permissions only to domain local groups, not directly to accounts or global groups; thus the 'gate to the source' remains in a single, controllable layer.
• Regularly review nested membership of high-value domain local/universal groups; Detect unexpected transitive chains (e.g. connecting a large global group to a privileged container).
• 4728/4732/4756 watch membership changes specifically for high value groups; Before applying the control, measure noise and impact in the pilot scope and prepare a return plan.

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-29T07:14:05.120043800Z"/><EventRecordID>482913</EventRecordID><Correlation/><Execution ProcessID="512" ThreadID="1180"/><Channel>Security</Channel><Computer>DC01.outreason.example</Computer><Security/></System><EventData><Data Name="MemberName">CN=GG-ProjectAtlas,OU=Groups,DC=outreason,DC=example</Data><Data Name="MemberSid">S-1-5-21-1002233445-2244556677-3366778899-3105</Data><Data Name="TargetUserName">DL-Atlas-Share-RW</Data><Data Name="TargetDomainName">OUTREASON</Data><Data Name="TargetSid">S-1-5-21-1002233445-2244556677-3366778899-3220</Data><Data Name="SubjectUserSid">S-1-5-21-1002233445-2244556677-3366778899-1106</Data><Data Name="SubjectUserName">busra</Data><Data Name="SubjectDomainName">OUTREASON</Data><Data Name="SubjectLogonId">0x3f8a1</Data><Data Name="PrivilegeList">-</Data></EventData></Event>

Two reality checks

Assumption: As soon as I add a user to a group, their access to their open session immediately changes.

In fact: A directory membership change does not rewrite an existing process token. Nor does just any new Kerberos ticket suffice: a service ticket derived from an old TGT may carry the older PAC/group snapshot. A TGT obtained or renewed with current group information is distinct from an existing process token or open resource session. Obtaining a ticket does not refresh the old token; a resource session may also need to be re-established. The corresponding 4624/4627 pair helps inspect the logon’s group snapshot on that host.

Assumption: Nesting only occurs between groups of the same species; A global group cannot be a member of a domain local group.

In fact: Global → Domain Local nesting underlies AGDLP. A Domain Local group can also contain other Domain Local groups in its own domain. Accounts, global groups and universal groups can be members under applicable trusted-domain conditions. “A universal group accepts members only from its own forest” differs from “a universal group can join a Domain Local group in a trusted domain.” Resource permissions still depend on the relevant token and resource DACL.

Sources

• Microsoft · Active Directory Security Groups
  Security vs distribution groups; Group scope tablosu (Universal/Global/Domain Local: possible members, can grant permissions, possible member of); security groups DACL'lerde listelenir
• Microsoft · Access tokens
  The access token contains the user and group SIDs; the token is created at logon and the access check uses this SID set
• Microsoft · Security identifiers
  Well-known SIDs: Domain Users (RID 513), built-in groups S-1-5-32 (e.g. Users 545); domain SID + RID structure
• Microsoft · 4732(S) A member was added to a security-enabled local group
  Event XML and EventData fields (MemberName, MemberSid, TargetUserName, TargetDomainName, TargetSid, Subject*); Audit Security Group Management subcategory; Version 0
• Microsoft · 4627(S) Group membership information
  Generated together with 4624; GroupMembership lists the token's group SIDs; requires Audit Group Membership + Audit Logon Success; minimum OS Windows Server 2016/Windows 10; EventIdx/EventCountTotal
• Microsoft · Audit Security Group Management
  The subcategory that group membership change events (4728/4729/4732/4733/4756/4757) depend on
• Microsoft · Audit Group Membership
  Audit Group Membership Success and Audit Logon requirements; event generated on the computer where the logon session is created; host location for interactive/network logons
• Microsoft · Nested Groups
  Native-mode Domain Local nesting and trusted-domain universal membership
• Microsoft · User Security Attributes
  primaryGroupId, memberOf, tokenGroups
• Microsoft · Group membership changes over VPN
  TGT and derived service ticket snapshot; existing resource sessions
• Microsoft · Remote effective permissions
  Share and file-system checks
• Microsoft · Grant-SmbShareAccess
  ShareAccessRight values Read, Change, Full