Directory authorization maps expose the real breach surface

At a glance

What this is: NHI Mgmt Group's analysis, drawing on Unosecur's blog post: DHS directory group data shows how authorization maps can be reconstructed from read access to users, groups, and internal roles.

Why it matters: IAM and identity teams need to treat directory enumeration as an access-control issue because read scope can expose sensitive role structure, tooling reach, and investigative targets without credential theft.

👉 Read Unosecur's analysis of the DHS Icepick leak and directory authorization risk

Context

A directory is not just an address book. In identity governance terms, it is often the authoritative map of who belongs to which groups, which groups unlock which tools, and which identities can see sensitive structure. When that map is readable too broadly, the problem is not only disclosure. It is that the organisation has exposed the control surface that decides access in the first place.

The DHS Icepick leak is a useful case because the sensitive material is not limited to contact details. The group memberships, reporting lines and tool-related associations are what make the dataset operationally useful to an attacker or investigator. That is exactly the kind of exposure that makes authorisation models matter across human, non-human and delegated access paths.

Key questions

Q: What should teams do first when directory group data is exposed?

A: First, contain the exposure by revoking or narrowing directory read access, rotating any exposed secrets tied to the directory integration, and identifying which group names, membership lists, and role mappings were readable. Directory data often reveals privilege structure, so teams should also review recent access logs and validate whether any accounts or service principals had excessive directory permissions.

Q: How should teams limit read access to identity directories?

A: Limit directory read access with least privilege, scoped roles, and separate administrative accounts, and only grant directory listing rights to identities that genuinely need them. Use RBAC or ABAC to restrict who can read group objects, membership, and metadata, and review those permissions regularly to remove standing access that is no longer needed.

Q: When should directory group names be treated as sensitive information?

A: Directory group names should be treated as sensitive whenever they disclose business function, privileged access, security tooling, incident response, finance, payroll, or other high-value roles. Names can reveal internal structure and target sets for attackers, so they should be protected like metadata that helps map access paths, not as harmless labels.

Technical breakdown

Why directory group data is an authorization graph

Directories usually store more than identities. They also store the relationship data that applications use to decide access, including group membership, reporting structure and tool-linked roles. In practice, that makes a directory a graph of permissions, not just a list of accounts. When a read path can enumerate users and groups in bulk, an attacker does not need to steal passwords to learn how access is structured. They can infer who reaches what, which roles are sensitive, and where the organisation has concentrated privilege. See the Authorisation Models Guide.

Practical implication: Treat directory enumeration as exposure of the authorization model itself, not merely of directory metadata.

Why read access can become a breach primitive

Many identity ecosystems assume read access is low risk because it is required for synchronisation, provisioning and application lookup. That assumption fails when the same read permission can pull the full user-group graph from a central identity source. The result is a breach primitive: a single authorised query path that reveals the structure of the environment at scale. Even when no passwords are taken, the exposed graph supports targeting, privilege mapping and follow-on compromise across connected systems.

Practical implication: Separate necessary synchronisation access from broad directory read permissions and review every integration that can enumerate identities.

Why directory exposures are hard to contain after disclosure

Once group names, tool associations and reporting relationships are exposed, the damage is not reversible in the same way as a credential leak. You can rotate a token, but you cannot unpublish the role structure that has already been copied, indexed or correlated elsewhere. That is why directory exposure often produces lasting reconnaissance value even when the original access path is closed. The issue is not persistence inside the directory alone. It is persistence in the adversary's understanding of the environment.

Practical implication: Assume exposed directory structure remains useful after containment and adjust incident scoping accordingly.

Threat narrative

Attacker objective: The attacker aims to reconstruct the organisation's authorization structure so they can target privileged identities and connected tools more effectively.

1. Entry occurs through a directory read path that can enumerate users and groups without needing password theft or interactive login.
2. Credential access is not the main event here, because the exposed asset is the authorization structure itself rather than a secret used to authenticate.
3. Impact follows when the leaked group graph reveals sensitive roles, tool access and reporting relationships that support targeting and follow-on compromise.

NHI Mgmt Group analysis

Directory exposure is authorization exposure: when a directory reveals group membership, reporting lines and tool-linked roles, it exposes the logic that governs access, not just personal data. That makes the directory itself part of the control plane, because an observer can infer who is privileged, how work is segmented and where access is concentrated. Practitioners should treat readable group structure as a governance object, not a harmless directory attribute.

Read access is the overlooked breach primitive: many identity programmes focus on login protection while leaving enumeration paths broad enough to expose the entire user-group graph. That is a governance gap, not a logging gap. If the identity layer can be queried at scale by service accounts, integrations or over-scoped admin paths, the resulting disclosure can be operationally equivalent to a breach of the access model itself.

Least privilege for directories is usually under-scoped: teams often apply least privilege to application entitlements but not to the identities that can read identity data. That is where the control breaks down. A directory read scope that was designed for synchronisation can become an organisation-wide reconnaissance channel when the actor can enumerate every group and relationship. Practitioners should reclassify directory read rights as sensitive access, not default plumbing.

Renaming and segmentation are governance controls, not cosmetics: when group names encode operations, sensitive tooling or investigative functions, the naming scheme itself leaks context to anyone who can read the directory. That turns metadata hygiene into access governance. The practical implication is that identity teams need to reduce the sensitivity of what directories reveal, not just who can sign in.

Authorization models fail when their map is public: authorisation models assume the policy surface is known to defenders but not broadly exposed to observers. Once the map is leaked, the model still functions, but it no longer stays private enough to protect targeting, segmentation or response planning. The implication is that identity governance must account for the confidentiality of the authorization structure itself.

What this signals

Identity directory visibility is now a governance issue, not just an admin concern: organisations that centralise identity data but leave broad read rights in place create a reusable reconnaissance layer. The practical shift is to treat directory readers as privileged identities and review them with the same seriousness as write-capable admins.

Authorization-map leakage changes how incidents should be scoped: once group structure is exposed, responders should assume an attacker may already understand which tools, teams and roles matter most. That means response planning has to account for leaked structure, not only for leaked secrets or compromised sessions.

Metadata hygiene matters because naming can expose capability: if a directory reveals which groups map to operations or privileged tooling, then the naming scheme itself becomes an identity risk. Teams should think about how much of the control model remains visible to anyone with read access.

For practitioners

• Inventory directory-read identities List every API token, service account and integration that can read users, groups or memberships in your identity provider, then assign a named owner to each one.
• Remove unnecessary directory read scope Strip directory enumeration rights from any integration that does not need full visibility into users and groups for its function.
• Reduce sensitive naming in groups Rename groups that expose operation names, case names or privileged tooling so that directory readers cannot infer sensitive functions from the label alone.
• Alert on bulk group enumeration Detect large reads of users or groups from a single identity, especially when the account has never previously performed directory enumeration.
• Review directory access as sensitive access Include directory read paths in privileged access reviews and incident scoping because they can reveal the structure of the environment even without credential theft.

Key takeaways

• A readable directory can expose the organisation's authorization logic even when no credentials are stolen.
• Group membership, reporting lines and tool associations are enough to create lasting reconnaissance value for an adversary.
• Directory read rights and group naming need to be governed as sensitive access controls, not treated as routine plumbing.

Related NHI Mgmt Group resources: Authorisation Models Guide · AI Agent Authorisation Guide · Data Breach Notification Checklist · Data Breach Statistics Guide

Key terms

• Authorization Graph: An authorization graph is the network of identities, resources, roles, and inheritance rules that determine access decisions. In practice, it must stay consistent with the application's structure or it becomes a source of drift, exceptions, and maintenance overhead.
• Directory Enumeration: Directory enumeration is the act of reading and exploring Active Directory objects to discover accounts, groups, servers, and relationships. Attackers use it to map attack paths and identify privilege targets. Detection depends on separating legitimate browsing from reconnaissance, which is difficult when logs are noisy or incomplete.
• Directory Read Scope: Directory read scope is the set of directory objects, attributes, and membership data that an account can view. It is usually controlled through directory permissions, roles, or API scopes, and a broader scope increases exposure of group structure, user relationships, and privileged identity details.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.

What's in the full article

Unosecur's full blog post covers the operational detail this post intentionally leaves for the source:

• The exact identity-provider visibility patterns the vendor maps across Okta, Entra ID and Active Directory
• Graph-based access-path visualisations used to prioritise identities with excessive or dormant privileges
• The vendor's run-time visibility workflow for human, non-human and AI agent identities across connected environments
• The incident-response scoping context that follows leaked directory structure and access-path data

👉 Unosecur's full post covers the directory-read exposure pattern, access-path scoping and response context.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.