Forest, domain, OU, and container: Separating the organizational structure from the trust boundary

1. Core mechanism

Four names, three different questions

A forest is the highest-level AD DS scope for domains that share schema and configuration. A domain is both a directory partition and an account and replication management scope.

OU and container objects hold objects in the domain tree. An OU has a specific role in classification, Group Policy scope of management, and delegation design; a general container is not automatically an OU.

The DN shows placement; the trust boundary is different

The DN CN=Tunahan,OU=Muhasebe,DC=iyelabs,DC=example shows the object’s RDN and its path through the hierarchy. It helps define management and search scope.

Moving an object to another OU can change its organizational placement and the policy or ACE context it inherits, but an OU does not create forest-level isolation by itself.

Delegation is an ACL relationship

An OU DACL grants specific rights to specific trustee SIDs. ACE inheritance flags determine whether a right propagates to descendants; object and inherited-object GUIDs can narrow the applicable class or property context.

Effective control is determined by evaluating explicit and inherited ACEs against the target object and requested right. The “OU manager” label does not mean unlimited authorization over the forest or a DC.

The artifact compares broad and narrow scope

The first ACE grants Generic All to the RID 1105 trustee with container inheritance. The second object-specific ACE, for RID 1106, is intended to apply WRITE_DAC only within CI|IO scope to descendant OU objects.

This synthetic SDDL is not a production ACL. The parser only separates tokens; it does not calculate canonical ACE order, effective access, or a Windows round-trip result. These are explicit validation boundaries.

State and data flow

1. Within a forest’s shared schema/configuration, the object’s DN locates it in a domain naming context.
2. The OU or parent-container DACL grants specific rights to a principal.
3. Inheritance flags determine whether the right propagates to descendant objects.
4. Object-specific ACE can narrow the right to certain class/attribute coverage.
5. Effective control is evaluated from the trustee SID, explicit or inherited ACE, target object, and requested right.
6. An OU organizes the administrative layout; it does not create forest-level security isolation.

2. Exploitation

Broken trust assumption

Broken assumption: “A department OU is a security boundary by itself.” An OU defines administrative and policy scope; an overly broad or incorrectly inherited ACE can grant more control over descendant objects than intended.

Technical prerequisites

• An attacker or incorrectly structured group has an effective ACE on the OU or a parent container.
• The ACE rights mask (for example, GA, WD, WP, CC, or DC) covers the required inheritance scope and target object class.
• The target object does not block inheritance, or an explicit DACL does not otherwise neutralize the right.

Exploitation mechanism

A broad or incorrectly inherited ACE can grant the ability to create or delete objects, change attributes, or modify the DACL beneath the OU. The effect is limited by the ACE’s right, trustee, object type, inherited-object type, and inheritance depth. Control of an OU is not control of the forest or a DC, but it can seriously affect identity and computer objects within that OU. Because higher-privileged service administrators can change the OU ACL, an OU is not a forest security boundary.

Do not mistake an organizational boundary for a security boundary

Department names and OU paths provide layout to people; the attack surface determines the actual trustee and scope in the ACL.

A single wide ACE inherited from the upper container can cover a large number of bottom objects.

Read the right together with its scope

WRITE_DAC is not the same as Generic All; object-specific and inherit-only flags change where the effect begins.

Instead of summarizing an ACE as “permission exists,” explain the right, object GUID, inherited-object GUID, trustee SID, and target object together.

3. Defense & Detection

Telemetry scope

• Source host: the domain controller processing the change; channel Security.
• Enable Audit Directory Service Changes for Success.
• For 5136, verify that the relevant write access is covered by the appropriate SACL; the absence of an event cannot prove that auditing or the SACL was correctly configured.

Events and relevant fields

• 5136 Version 0: AD object change.
• Relevant fields: SubjectUserSid, SubjectUserName, SubjectDomainName, SubjectLogonId, DSName, DSType, ObjectDN, ObjectGUID, ObjectClass, AttributeLDAPDisplayName, AttributeSyntaxOID, AttributeValue, OperationType, and OpCorrelationID.
• AttributeLDAPDisplayName=nTSecurityDescriptor identifies the changed security descriptor; ObjectClass=organizationalUnit can identify an OU target.
• Value Deleted and Value Added records with the same OpCorrelationID can be linked; the event does not calculate the ACE’s effective access result by itself.

Separate the change from its impact

Event 5136 may report a change to the nTSecurityDescriptor attribute. Separate the old and new descriptors from the target-object context to determine which ACE grants which principal effective access.

OpCorrelationID helps link the deleted and added value records for one change; matching the change to an approved record remains necessary.

Convert SDDL into a scope table

For each ACE, keep type, flags, rights, object GUID, inherited-object GUID, and trustee in separate columns. This prevents a broad Generic All entry from hiding a narrower WRITE_DAC entry.

The parser does not make an effective-access decision. Deny and allow order, group membership, object state, and inheritance must also be evaluated.

Detection logic · XPath

*[System[(EventID=5136)]] and *[EventData[Data[@Name='AttributeLDAPDisplayName']='nTSecurityDescriptor']]

Query assumptions

• This is an unexecuted candidate filter for raw Windows Event Log XML field names.
• Narrow the OU scope further with an exact ObjectDN allowlist or a controlled DN-suffix rule.
• The record may be absent if Audit Directory Service Changes Success or the appropriate SACL is not configured.
• AttributeValue formatting was not verified in a lab for a specific build and configuration; the query relies only on the attribute name.

False positives

• Approved delegation-of-control changes and planned ACL maintenance.
• Provisioning automation and migration operations.
• Negative example: absence of 5136 cannot prove that auditing or the SACL is missing; presence of 5136 does not show the ACE’s effective access by itself.

Hardening

• Assign delegation directly to a managed group and limit the right and object-type scope.
• Review OU DACLs regularly, including explicit and inherited ACEs, trustee SIDs, and GUID coverage.
• Use a custom OU for objects that need management scope rather than relying on a default container; do not treat the OU as a security boundary.
• Evaluate isolation requirements against the forest/domain threat model and the privileges of service administrators.
• Compare audit changes with an approved change record; validate the SDDL through a Windows API round trip and on a controlled OU in a lab. These steps have not yet been performed.

Read the examples

D:(A;CI;GA;;;S-1-5-21-111111111-222222222-333333333-1105)(OA;CIIO;WD;;bf967aa5-0de6-11d0-a285-00aa003049e2;S-1-5-21-111111111-222222222-333333333-1106)

Two reality checks

Assumption: Creating a separate department OU in the organization chart provides security isolation.

In fact: An OU defines administrative classification, Group Policy, and delegation scope. Effective isolation depends on ACLs and broader architecture; an OU does not shield against forest-level service administrators.

Assumption: Delegating an OU means Full Control over every object beneath it.

In fact: The effect is limited by the ACE mask, trustee SID, inheritance flags, object and inherited-object GUIDs, and the target object’s inheritance state; some ACEs apply only to particular descendant classes.

Sources

• Microsoft · Understanding the Active Directory Logical Model
  Forest, Domain, and Organizational Units sections: shared structure and logical scopes.
• Microsoft · MS-GPOD glossary
  “forest”, “domain”, and “distinguished name (DN)” definitions and security/management boundary terminology.
• IETF · RFC 4512: LDAP Directory Information Models
  §2.1–2.3: directory information tree, naming, and the DN/RDN model.
• Microsoft · Organizational-Unit class
  Class definition and schemaIDGUID bf967aa5-0de6-11d0-a285-00aa003049e2.
• Microsoft · Delegating Administration by Using OU Objects
  Detailed delegation and inheritable rights with OU objects.
• Microsoft · Inheritance and Delegation of Administration
  ACE inheritance and the object-specific delegation model.
• Microsoft · ACE Strings
  ACE string syntax: type, flags, rights, object GUID, inherited-object GUID, and trustee.
• Microsoft · 5136(S): A directory service object was modified
  Event Description, Version 0 XML, field descriptions, SACL requirements, and Directory Service Changes requirements.