Reading an Active Directory environment

Think of Active Directory as an organization’s identity directory, not a list of passwords. It records users, computers, groups, and relationships that many services use when making access decisions. A useful security review starts by understanding that structure.

Enumeration means identifying objects and relationships within a defined scope. In this lesson, the goal is a defensible inventory: what exists, who owns it, what depends on it, and which questions remain unanswered.

Learn the objects before drawing arrows

A user account represents an identity. A computer account also has an identity; it is not just a hostname. Security groups collect identities so administrators can assign access more consistently. Groups can contain other groups, so indirect membership matters.

An organizational unit, or OU, is a container for organization, delegated administration, and Group Policy scope. Moving an account into an OU does not itself add that account to a security group or grant access to a file share. Keep “located in,” “member of,” and “allowed to change” as different relationships.

Read permission is its own permission

LDAP is one protocol used to access directory information. A successful authenticated query does not imply unrestricted access. Object permissions and attribute protection influence what the requesting identity may read or change.

Some directory information is intentionally readable by ordinary authenticated users because applications need it. Other information requires more restricted access. Similarly, basic rootDSE metadata can be available anonymously without exposing all user objects. Evaluate the actual data and intended policy, rather than treating every response as a vulnerability.

Transport protection is another question. Protecting a connection’s confidentiality or integrity does not determine which directory objects the account may access.

A map needs more than one source

A directory export can show group membership, but it may not include a server’s local groups, application roles, active sessions, or cloud permissions. An organizational chart is not a complete access-control model.

Suppose a fictional group is named Finance Editors. That name suggests a purpose; it does not prove which files members can edit. You need the relevant resource permissions and a responsible owner. If the export contains no owner, record “owner not recorded in this source,” not “nobody owns it.”

Collection can also be incomplete because the search covered only one domain or container, omitted attributes, encountered access restrictions, or used stale data. Replicated directory information may briefly differ between domain controllers. Record the source and collection time.

Turn observations into evidence

For each important relationship, record four things: the object’s stable identity, the observed relationship, the account and source used to observe it, and the time. Prefer a narrow inventory that answers an approved question over unnecessary copies of personal information.

Separate an observation from an inference. “The account is a member of this group” is an observation supported by an export. “It can modify the payroll service” is a further conclusion requiring evidence of the service’s access controls.

Make the inventory maintainable

A useful directory map identifies owners, intended access, exceptions, and review dates. It helps defenders retire stale accounts, explain nested groups, and reduce unnecessary privileges without breaking legitimate work.

The next lesson uses this map to reason about access paths. Its first rule follows directly from this one: an arrow is only as trustworthy as the evidence and conditions behind it.