Active Directory Permission Coverage Expansion ​

GraphnAI detects a comprehensive set of Active Directory permission types — including delegation abuse paths, GMSA credential theft, and the complete DCSync permission set — automatically surfaced after each full sync.

Requires role: Operator or higher (to run sync and view analysis results); Viewer (to explore the graph) Related: Identity Graph — Data Model and Change Simulation | Risk Posture Dashboard | Bridge Configuration

Overview ​

Every permission an identity holds in Active Directory represents a potential attack path. GraphnAI reads the access control lists from your domain during sync and converts each permission grant into a visible edge in the identity graph. The more completely those permissions are mapped, the more accurately the platform reflects your real attack surface.

GraphnAI's detection set covers the following categories:

  1. Complete DCSync detection — The full set of Active Directory replication rights is tracked, including the supplementary GetChangesInFilteredSet right.
  2. Kerberos delegation abuse paths — Constrained delegation (AllowedToDelegate) and resource-based constrained delegation (AllowedToAct) are built as graph edges from the identity attributes that configure them.
  3. GMSA credential theft — Group Managed Service Account password readers are detected from the GMSA membership attribute and mapped as ReadGMSAPassword edges.
  4. Property write distinctions — WriteAccountRestrictions (write account control flags) and WriteGPLink (link a Group Policy Object to an OU) are detected as separate, named permissions.
  5. Self-enrollment distinction — The AddSelf permission (a user can add themselves to a group) is correctly distinguished from AddMember (a user can add anyone to a group).

No configuration is required. After a full sync completes, these edges appear automatically in the graph and in all analysis views.

Prerequisites ​

  • Role: Operator or Admin (to trigger a sync or view analysis)
  • Active Directory bridge: An Identity Bridge connected to your AD domain must be configured and reachable
  • Full sync: New permission types require a full sync — delta syncs will not produce them for identities not modified since the last full sync

What Gets Detected and Why It Matters ​

GetChangesInFilteredSet — Supplementary Replication Right ​

Edge type: GetChangesInFilteredSetSeverity: High Appears in: HasPermission edge on the Domain object

Active Directory's DCSync capability requires three replication rights working together: GetChanges, GetChangesAll, and GetChangesInFilteredSet. GraphnAI detects all three.

When an identity holds all three rights on a domain object, GraphnAI consolidates them into a single DCSync edge — the clearest possible signal that the identity can pull password hashes from a domain controller. If an identity holds GetChangesInFilteredSet without the other two, the right is still recorded as a GetChangesInFilteredSet permission entry on a HasPermission edge, flagged as High severity. This indicates partial replication capability and is worth reviewing even without the full DCSync combination.

Note: GetChangesInFilteredSet alone does not enable full DCSync. DCSync requires GetChanges + GetChangesAll. However, an identity with GetChangesInFilteredSet + GetChanges (but not GetChangesAll) can still perform partial directory replication.

WriteAccountRestrictions — Account Control Abuse ​

Edge type: WriteAccountRestrictionsSeverity: High Appears in: HasPermission edge on User or Computer objects

This permission allows an identity to write the User-Account-Restrictions property set on another object. In practice, this means the holder can:

  • Enable or disable the target account
  • Set or clear the "Account is sensitive and cannot be delegated" flag
  • Modify Kerberos pre-authentication requirements

An attacker with WriteAccountRestrictions on a privileged account can clear delegation restrictions, opening that account to impersonation attacks. On a computer object, this permission enables Resource-Based Constrained Delegation configuration, which is a known privilege escalation technique.

Edge type: WriteGPLinkSeverity: High Appears in: HasPermission edge on OrganizationalUnit or Domain objects

An identity with WriteGPLink on an OU or domain can link a Group Policy Object to that container. If an attacker controls a GPO (or can create one), linking it to an OU containing privileged accounts or domain controllers is a common lateral movement and persistence technique.

WriteGPLink findings are most impactful when the target is a high-value OU (containing Domain Controllers, for example) or the Domain object itself.

AddSelf — Self-Enrollment in Groups ​

Edge type: AddSelfSeverity: Medium Appears in: HasPermission edge on Group objects

When an Active Directory DACL entry uses the DS_SELF access mask on the member property, it means the trustee can add or remove only themselves from the group — not arbitrary users. This is semantically different from AddMember, which allows the trustee to add anyone.

An identity with only AddSelf on a privileged group can join that group themselves and inherit its permissions — which is still a meaningful finding — but cannot add others.

If you see both AddSelf and AddMember edges from different identities to the same group, the AddMember holder has broader administrative control over that group's membership.

AllowedToDelegate — Constrained Kerberos Delegation ​

Edge type: AllowedToDelegateSeverity: Medium Appears in: Separate edge (not inside HasPermission) between an identity and a target computer

Constrained Kerberos delegation lets a service account impersonate any authenticated user when connecting to a specific set of services. The set of allowed targets is stored in the msDS-AllowedToDelegateTo attribute as a list of Service Principal Names.

GraphnAI reads this attribute and builds an AllowedToDelegate edge from the identity to each target computer it is configured to impersonate. An attacker who compromises a service account with AllowedToDelegate to a Domain Controller, for example, can impersonate any domain user — including Domain Admins — against that DC.

AllowedToDelegate edges appear with Tier 2 (Constrained) fidelity, reflecting that they are derived from observed LDAP attribute data rather than theoretical ACL configuration.

Cross-domain delegation targets may not appear as edges if the target host is not in a synced domain. Unresolvable targets are silently omitted.

AllowedToAct — Resource-Based Constrained Delegation ​

Edge type: AllowedToActSeverity: Medium Appears in: Separate edge (not inside HasPermission) from an identity to a resource computer

Resource-Based Constrained Delegation (RBCD) works in the opposite direction from classic delegation. Instead of the delegating identity listing its allowed targets, the resource lists which identities are allowed to impersonate users when accessing it. This is stored in the msDS-AllowedToActOnBehalfOfOtherIdentity attribute on the resource computer.

An AllowedToAct edge reads: "Identity A is allowed to act on behalf of other users when accessing Resource B." If an attacker can write msDS-AllowedToActOnBehalfOfOtherIdentity on a resource they want to target (which requires WriteAccountRestrictions or GenericWrite on that computer), they can configure RBCD to enable impersonation.

Finding an unexpected AllowedToAct edge from a low-privilege identity to a sensitive server indicates either misconfiguration or a compromised RBCD configuration.

AllowedToAct edges appear with Tier 2 (Constrained) fidelity.

ReadGMSAPassword — GMSA Credential Theft ​

Edge type: ReadGMSAPasswordSeverity: High Appears in: HasPermission edge from an identity to a Group Managed Service Account (GMSA)

Group Managed Service Accounts automatically rotate their passwords. The list of principals permitted to retrieve the current password is stored in the msDS-GroupMSAMembership attribute on the GMSA object. Any principal that can retrieve this password can authenticate as the GMSA.

GraphnAI reads this attribute and builds a ReadGMSAPassword edge for each principal granted read access. Because GMSAs are often used for high-privilege automated processes (backup agents, scheduled tasks running as service administrators), a ReadGMSAPassword edge to a privileged GMSA is effectively a credential theft path.

ReadGMSAPassword edges appear with Tier 2 (Constrained) fidelity.

How to See These Permissions ​

Step 1: Trigger a Full Sync ​

These permission types are built from data collected during a full sync. Delta syncs update only changed objects and will not populate AllowedToDelegate, AllowedToAct, or ReadGMSAPassword edges for identities that have not been modified since the last full sync.

To trigger a full sync:

  1. Log in as an Operator or Admin
  2. Navigate to Bridges in the sidebar
  3. Select your Active Directory bridge
  4. Click Trigger Sync > Full Sync
  5. Wait for the sync to complete (the status badge changes from "Syncing" to "Synced")

Step 2: Explore Edges in the Graph ​

Once the sync completes, use the Graph Explorer to investigate permission types.

To find identities with delegation configured:

  1. Navigate to Graph Explorer
  2. Search for a known service account that has delegation configured in Active Directory
  3. In the edge list for that identity, look for AllowedToDelegate edges (shown as amber lines — Tier 2 fidelity)
  4. Click an edge to see the target computer

To find GMSA password readers:

  1. Search for a GMSA service account by name
  2. Look for inbound HasPermission edges that include ReadGMSAPassword in the permissions list
  3. The source node of each edge is a principal that can retrieve the GMSA's current password

To find identities with the WriteGPLink or WriteAccountRestrictions permissions:

  1. Search for an OU object or a computer
  2. Look for inbound HasPermission edges
  3. Click any HasPermission edge to expand the permissions list and see whether WriteGPLink or WriteAccountRestrictions are present

Step 3: Review the Risk Posture Dashboard ​

After the sync completes, the Risk Posture Dashboard recalculates. HasPermission edges containing high-severity permissions (WriteAccountRestrictions, WriteGPLink, ReadGMSAPassword) contribute to the Over-Permission score. AllowedToDelegate and AllowedToAct edges are counted individually in the over-permission analytics.

Navigate to Analysis > Risk Posture to see the updated scores.

How These Permissions Are Displayed ​

Permissions Inside HasPermission Edges ​

These permission types are grouped into consolidated HasPermission edges when multiple permissions exist between the same trustee and target:

PermissionSeverity
GetChangesInFilteredSetHigh
WriteAccountRestrictionsHigh
WriteGPLinkHigh
ReadGMSAPasswordHigh
AddSelfMedium

When a single HasPermission edge contains multiple permissions, its severity reflects the most dangerous permission in the set. The edge weight also increases with the number of permissions — an identity holding both WriteGPLink and WriteAccountRestrictions on the same target represents a more significant risk than either alone.

Delegation Edges as Separate Relationships ​

AllowedToDelegate and AllowedToAct appear as their own distinct edge types in the graph, separate from HasPermission. They are distinguished by:

  • Amber color — Tier 2 (Constrained) fidelity styling
  • Separate edge label — AllowedToDelegate or AllowedToAct, not consolidated
  • Different source data — These come from LDAP attributes, not from DACL security descriptors

You can toggle the display of these edge types on and off using the View menu in the Graph Explorer.

Fidelity Tiers ​

PermissionFidelity TierReason
GetChangesInFilteredSetTier 1 (Theoretical)Detected from DACL access control entries
WriteAccountRestrictionsTier 1 (Theoretical)Detected from DACL access control entries
WriteGPLinkTier 1 (Theoretical)Detected from DACL access control entries
AddSelfTier 1 (Theoretical)Detected from DACL access control entries
AllowedToDelegateTier 2 (Constrained)Detected from LDAP attribute — observed delegation configuration
AllowedToActTier 2 (Constrained)Detected from LDAP attribute — observed RBCD configuration
ReadGMSAPasswordTier 2 (Constrained)Detected from LDAP attribute — observed GMSA membership

Attack Path Scenarios ​

Understanding how these permissions chain together helps you prioritize findings.

Full DCSync Path ​

A complete DCSync capability requires an identity to have GetChanges, GetChangesAll, and optionally GetChangesInFilteredSet on a domain object. When the first two are present, GraphnAI collapses them into a single DCSync edge. If only GetChangesInFilteredSet is present alongside GetChanges (but not GetChangesAll), no DCSync edge is created — but the partial replication rights remain visible in the HasPermission edge.

If you see a DCSync edge from an unexpected identity to your domain object, treat it as a critical finding. That identity can extract all password hashes from your domain controller.

RBCD Privilege Escalation Chain ​

A common RBCD escalation pattern:

  1. Attacker compromises Identity A (low-privilege)
  2. Identity A has WriteAccountRestrictions (or GenericWrite) on Computer B
  3. Attacker writes msDS-AllowedToActOnBehalfOfOtherIdentity on Computer B, granting themselves delegation rights
  4. This creates an AllowedToAct edge from Identity A to Computer B
  5. Attacker impersonates a Domain Admin when accessing Computer B

In GraphnAI, this path looks like: HasPermission[WriteAccountRestrictions] from Identity A to Computer B, followed by an AllowedToAct edge once RBCD is configured.

GMSA Theft to Privileged Service ​

If a GMSA runs a high-privilege service (backup agent, scheduled task with Domain Admin rights), then any identity with ReadGMSAPassword on that GMSA can obtain its credentials and authenticate as the service.

Look for ReadGMSAPassword edges pointing to GMSAs that themselves have MemberOf edges into privileged groups or HasPermission edges on domain controllers.

An identity with WriteGPLink on an OU, combined with the ability to create or modify a GPO, can apply arbitrary computer configurations to all machines in that OU. Targets an attacker would prioritize include OUs containing Domain Controllers or servers running privileged services.

Troubleshooting ​

New edge types are not appearing after sync ​

Possible causes:

  • Delta sync was run instead of a full sync. Delta syncs process only objects changed since the last sync and may not re-read delegation or GMSA attributes. Run a full sync to ensure all attributes are collected.
  • Sync has not completed yet. The edge-building phase runs after all nodes are ingested. For large domains, this can take several minutes after the LDAP collection phase finishes. Check the bridge sync status at the Bridge detail page Sync History section.

Solution: Trigger a full sync and wait for the status to show "Synced" before checking the graph.

AllowedToDelegate edges are missing for a known delegation configuration ​

Possible causes:

  • Cross-domain delegation. If the delegation target (the SPN in msDS-AllowedToDelegateTo) references a host in a domain that is not synced by any configured bridge, the target computer cannot be resolved and the edge is omitted.
  • Non-standard SPN format. SPNs with unusual formats that cannot be parsed to extract a hostname are silently skipped.
  • Target computer not yet synced. If the target computer does not exist as an identity node in the graph, the edge cannot be created.

Solution:

  1. Confirm the target domain is configured as a bridge source at Bridges in the sidebar.
  2. Check that the target computer (by its DNS hostname) exists in the graph using the search bar.
  3. If the target is in a different domain, add a bridge for that domain.

I see AddSelf where I expected AddMember ​

Cause: This is correct behavior. Active Directory uses a different access mask (DS_SELF) when an identity is granted the right to add only themselves to a group — as opposed to DS_WRITE_PROP, which allows adding any member. GraphnAI distinguishes these as separate permission types.

If you have a compliance report that checks for AddMember on privileged groups, ensure your queries also check for AddSelf where appropriate.

ReadGMSAPassword edges are not appearing for a GMSA ​

Possible causes:

  • GMSA not collected. The bridge must be configured to collect GMSA (service account) objects. Confirm the object class filter in your bridge configuration includes msDS-GroupManagedServiceAccount objects.
  • Empty membership attribute. A GMSA with no msDS-GroupMSAMembership attribute (no principals are permitted to read the password) will produce no edges — this is correct behavior.
  • Trustee SID not resolved. If the principal listed in the GMSA membership attribute is from a foreign domain not synced by any bridge, its SID cannot be resolved to a graph node and the edge is omitted.

Solution:

  1. Search for the GMSA by name in the graph. If it does not appear, the bridge is not collecting that object.
  2. If the GMSA appears but has no ReadGMSAPassword inbound edges, confirm in Active Directory that msDS-GroupMSAMembership is populated on that object.
  3. If the trustee group is from a different domain, add a bridge for that domain.

Over-permission scores are higher than expected ​

Cause: High-severity permission types — particularly WriteAccountRestrictions, WriteGPLink, and ReadGMSAPassword — may exist widely in your environment. The over-permission analytics accurately reflects these.

Recommended action: Review the top findings in Analysis > Over-Permissions and use the Graph Explorer to investigate the most impactful identities. Not all high-severity permissions represent active risk — evaluate each in context.

Best Practices ​

  1. Run a full sync after initial setup. These edge types require a full collection pass. Schedule a full sync during your next maintenance window.
  2. Search for DCSync permission combinations. An unexpected DCSync edge to your domain object is your highest-priority finding. Check the Risk Posture Dashboard for DCSync indicators after the sync completes.
  3. Audit delegation configurations. Use the Graph Explorer to review AllowedToDelegate and AllowedToAct edges. Both constrained delegation and RBCD can be legitimate but are frequently misconfigured.
  4. Review GMSA access. Find each GMSA service account in the graph and check its inbound ReadGMSAPassword edges. Confirm that only the expected groups and computers appear as readers.
  5. Investigate WriteGPLink on Domain Controllers OUs. An identity with WriteGPLink on an OU containing Domain Controllers represents a high-risk finding. This path can be used to push malicious configurations to your most sensitive machines.
  6. Use change simulation to assess remediation impact. Before revoking a delegation or group membership, run a simulation in Analysis > Simulate to confirm you understand which paths would be removed.