unboundcompute/security-agent-skills/auditing-directory-sync-trust

Auditing directory sync trust: a bulk feed reshapes identity, so validate what it says before you apply it

Directory synchronization keeps an application's users, groups, and privileges in step with an external source, an LDAP directory, an HR system, an identity provider, another directory, by importing that source's records in bulk on a schedule or on events. That makes the sync feed a firehose of identity changes the application applies largely without a human in the loop, so whatever the source says about who is an admin, who belongs to which group, and which account is which becomes internal truth. When the application trusts source attributes it never validates, a group membership, a department, an is-admin-like flag, an email, then whoever can influence those attributes at the source sets internal privilege. When the sync connector authenticates with a broad or long-lived credential, that credential can read and reshape the entire directory. When an external group name is allowed to map onto a privileged internal group, an attacker who controls a source group name escalates. When accounts are created or matched by a spoofable key like email or external id, an attacker record merges into an existing identity. And when a deletion or suspension in the source does not propagate, departed users linger with access. The audit treats the feed as untrusted input, checks that every attribute that sets privilege or identity is validated, and confirms the connector is scoped and deletions propagate. You audit this by feeding shaped source records and watching what internal state they create.

When to use

• An external directory feed (LDAP, HR system, identity provider, or cross-directory sync) drives internal

account, group, and privilege state in bulk.

• The sync may trust source attributes (group, department, admin flag, email) to set privilege or tenancy

without validation, or map an external group onto a privileged internal one.

• Accounts may be matched by a spoofable key, the connector credential may be broad, or source deletions may not

propagate.

Scope check

Test directory sync trust only against directories and applications you own or are authorized to assess, on non-production tenants. Feeding records and triggering syncs changes real identity state in bulk, so use test directories and tenants and never create, merge, elevate, or delete identities that are not yours. If you can't name the authorization, stop.

The loop

1. Establish which source attributes set internal state and what the connector may do first. Name every

source attribute the sync trusts to set privilege, group, or tenancy, how accounts are matched between source and application, what the connector credential can read and write, and how source deletions are meant to propagate. This is the false-positive killer: a sync that validates every privilege-setting attribute, matches accounts on a non-spoofable key, runs under a scoped connector credential, and propagates deletions is behaving correctly. Name the intended trust, then feed shaped records.

1. Test attribute-to-privilege mapping. Feed source records carrying various group, department, and

admin-like attributes and confirm each maps to exactly the intended internal privilege. Attempt a source attribute that should map to an ordinary role and check it cannot set an admin or elevated internal group. A sync that trusts an unvalidated source attribute to set privilege lets whoever controls that attribute escalate.

1. Test group name mapping and collision. Examine how external group names map to internal groups. Try a

source group whose name collides with or maps onto a privileged internal group, and confirm the mapping is an explicit allowlist, not a name match. An external group allowed to land on a privileged internal group is an escalation for anyone who can name a source group.

1. Test account matching and merging. Determine the key the sync uses to match a source record to an existing

internal account (email, external id, username). Feed a record with a spoofable key that collides with an existing identity and confirm it does not merge an attacker record into that account. Matching on a spoofable key lets a crafted source record take over an existing internal identity.

1. Test connector scope and deletion propagation. Examine the connector credential: whether it is scoped to

the objects the sync needs or can read and reshape the whole directory, and whether it rotates. Then delete and suspend a user in the source and confirm the change propagates so the internal account is disabled and its access revoked. A broad connector credential is a directory-wide compromise, and a deletion that does not propagate leaves a departed user active.

1. Confirm and record. Confirm on a test tenant by elevating an internal account through an unvalidated

source attribute, mapping an external group onto a privileged internal one, merging an attacker record into an existing identity, or keeping a user active after a source deletion, without touching real identities. Kill the lead if the sync validates every privilege-setting attribute, matches on a non-spoofable key, maps groups by explicit allowlist, runs under a scoped credential, and propagates deletions. Record the attacker-influenced source record, the over-privileged, merged, or lingering internal account, and the unvalidated attribute mapping or spoofable match key.

Where directory sync trust leaks

• Unvalidated privilege-setting attributes. A source group, department, or admin-like flag trusted to set

internal privilege lets whoever influences that attribute escalate in bulk.

• External-to-privileged group mapping. An external group name allowed to map onto a privileged internal

group escalates for anyone who can name a source group.

• Spoofable match keys. Matching source records to internal accounts by email or external id lets a crafted

record merge into and take over an existing identity.

• Broad connector credential. A sync connector that can read and reshape the whole directory is a

directory-wide credential whose compromise reshapes all identity.

• Deletions that do not propagate. A source deletion or suspension the sync does not apply leaves a departed

user active internally with standing access.

Worked example (a confirm and a kill)

Confirm. An application syncs from an external directory and creates or updates internal group membership

directly from the source group names, matching accounts by email, under a connector credential with full

directory read-write. On a test tenant, a source record whose group name matches the internal administrators

group grants admin, and a record with an existing user's email merges into that user's account, because the

sync trusts the group name and matches on email. Confirmed privilege escalation and account merge via

unvalidated group mapping and spoofable match key, high, remediation = map external groups to internal ones

by an explicit allowlist that never reaches privileged groups, match accounts on a non-spoofable key, validate

privilege-setting attributes, and scope the connector credential.

Kill. The sync validates every attribute that sets privilege, maps external groups to internal ones only

through an explicit allowlist with privileged groups unreachable, matches accounts on a non-spoofable stable

key so no email collision merges identities, runs under a connector credential scoped to the synced objects and

rotated, and propagates source deletions so a removed user is disabled. A crafted group name does not escalate,

a spoofed email does not merge, and a deleted source user goes inactive. Killed, kill_reason = "the sync

validates privilege-setting attributes, maps groups by allowlist, matches on a non-spoofable key, runs under a

scoped credential, and propagates deletions; no shaped source record over-privileges, merges, or lingers."

Rationalizations to reject

• "The directory is authoritative." → Authoritative is not the same as validated; confirm the application

checks each privilege-setting attribute rather than applying whatever the feed asserts.

• "Group names come from the source." → A source group name an attacker can set must not map onto a privileged

internal group; use an explicit allowlist, not a name match.

• "We match users by email." → Email is spoofable in a source record; match on a stable non-spoofable key or an

attacker record merges into an existing account.

• "The connector needs access to sync." → It needs access to the synced objects, not the whole directory; a

broad connector credential is a directory-wide compromise waiting to happen.

• "Deletions sync eventually." → Confirm a source deletion actually disables the internal account and revokes

access; a deletion that does not propagate leaves a departed user active.

Executing this in practice

You need which source attributes set internal privilege and tenancy, how external groups map to internal ones, the key used to match accounts, what the connector credential can do, and how deletions propagate. On a test tenant, feed shaped source records with crafted groups, spoofed match keys, and source deletions, and watch the internal state each produces. Reading the sync mapping and connector configuration shows the intended trust; an over-privileged, merged, or lingering internal account from a shaped record shows whether it holds.

Related

• auditing-scim-provisioning-trust - the push-provisioning counterpart; SCIM and directory sync both trust an

external source to shape internal identity, and both hinge on attribute-to-privilege mapping.

• auditing-jit-provisioning-and-role-mapping - the at-login counterpart; the same attribute-to-role validation

applies whether identity is synced in bulk or provisioned at login.

• auditing-multi-tenant-isolation - the tenant scoping a sync must respect; a feed that crosses tenants is that

skill's boundary applied to synchronization.

• hunting-iam-privilege-escalation-paths - a group over-granted by sync is an escalation edge that skill traces

onward from the internal account it creates.

• FINDING-SCHEMA.md - source = the attacker-influenced source record, sink = the

over-privileged, merged, or lingering internal account, evidence = the unvalidated attribute mapping or spoofable match key.