Forest and domain boundaries: Administrative separation and security isolation

1. Core mechanism

This lesson distinguishes the data and administrative scope of a domain from that of a forest. OU delegation, a separate domain and a separate forest do not provide the same degree of security isolation.

Interfaces and specifications

• Domain naming context: contains domain principals, the policy base and domain-local administration scope.
• Forest: shares schema, configuration and the forest-wide trust/control plane.
• Enterprise Admins and Schema Admins: forest-wide privileged groups located in the forest-root domain.
• Global Catalog: holds partial attribute sets for forest objects and connects domains for discovery.
• OU delegation: grants administrative scope within a domain without creating a domain/forest security boundary.
• Separate forest: has separate schema/configuration and a separate privileged control plane; adding a trust requires a separate access-path decision.

A domain is useful, but does not provide full isolation

A domain has its own naming context, domain policy and three domain-level FSMO roles. It provides meaningful scope for replication and administrative delegation.

Domains in the same forest share schema and configuration, and forest-wide administration can affect child domains. A separate domain therefore does not promise isolation from a hostile forest administrator.

A forest is the broadest AD DS security boundary

Domains in a forest are automatically connected by transitive trusts within the same identity ecosystem. Schema and configuration changes have forest-wide scope.

Service autonomy, service isolation and data isolation are different goals. Microsoft’s forest design models distinguish organizational, resource and restricted-access forests according to these needs.

A trust opens a path that needs its own controls

Creating a separate forest does not establish cross-forest resource access. A configured trust can support an authentication path. Resource authorization remains a separate decision, alongside trust-boundary controls such as SID filtering and selective authentication.

For restricted access, creating no trust is often the strongest decision. If a trust is needed, explicitly document its direction, scope and Allowed-to-Authenticate surface.

State and data flow

1. Classify the need: administrative delegation, service autonomy or isolation from a hostile administrator.
2. If administrative delegation is sufficient, consider OU/domain boundaries within the forest.
3. If isolation from forest-wide administration is required, establish a separate forest control plane.
4. If cross-forest access is not required, create no trust; otherwise evaluate only the required direction.
5. Limit access separately through resource authorization, SID filtering and selective authentication.

2. Exploitation

Broken trust assumption

Assume an attacker controls the forest-wide privileged control plane, or takes advantage of a design that incorrectly treats a separate domain as an independent security boundary.

Technical prerequisites

• The critical workload is kept in the same forest.
• The forest root and forest-wide groups are not protected as strongly as the child domain.

Exploitation mechanism

Forest-wide privileges can undermine assumptions about child-domain isolation through shared schema/configuration and the trust control plane. This does not automatically authorize access to every resource, but authority over the forest control plane can permit changes beyond domain-local delegation boundaries.

Choosing the wrong boundary leaves lasting risk

An OU or child domain can separate administrative teams operationally, but the teams remain subject to forest-wide authority. A threat model involving a malicious or compromised forest administrator needs a forest boundary.

A separate forest still needs dependency review: shared privileged workstations, backup credentials or broad bidirectional trusts can connect the control planes again.

3. Defense & Detection

Telemetry scope

• Classify the intended security boundary for each workload as OU, domain or forest.
• Review forest-root privileged groups and schema/configuration ACLs separately.
• Inventory cross-forest trusts by direction, transitivity, SID filtering and authentication scope.
• Review shared secrets and privileged-access, backup and monitoring dependencies between separate forests.

Events and relevant fields

• This lesson does not treat a single Windows Event ID as proof of isolation. Review the design together with ACL and trust state.

Test the boundary claim against its dependencies

Two forests can still share an administrator account, backup operator or hypervisor control plane. These dependencies weaken practical isolation and belong on the boundary diagram.

A foreign-forest SID in a resource ACL does not prove that access works. Trust direction and authentication scope must be evaluated separately before the resource decision.

Detection logic · Sigma

title: Forest Boundary Privileged Group Change Review
logsource:
  product: windows
  service: security
detection:
  selection:
    EventID:
      - 4728
      - 4729
      - 4756
      - 4757
  condition: selection

Query assumptions

• The rule collects group-membership change candidates only; environment-specific enrichment identifies which groups have forest-wide scope.
• It has not been run against a live dataset, and no detection rate is claimed.

False positives

• Approved break-glass access or role rotation can produce legitimate membership changes.
• Seeing no group changes does not prove that forest-root ACLs are secure.

Hardening

• Protect forest-root administration with at least the assurance applied to child-domain administration.
• Use a separate forest and privileged-access plane when isolation from a hostile administrator is required.
• Evaluate cross-forest trusts only in the required direction, with selective authentication, rather than choosing bidirectional trust by default.
• Keep the no-trust option as an explicit security control for restricted data.

Read the examples

O:BAG:BAD:(A;;GR;;;S-1-5-21-1987654321-1234567890-2468013579-4101)

Two reality checks

Assumption: Creating a separate domain isolates it from forest administrators.

In fact: Domains in the same forest share schema/configuration and a forest-wide privileged control plane. A separate domain provides administration and replication scope, not full isolation from a hostile forest administrator.

Assumption: Creating a separate forest removes every possible trust or access path between the two environments.

In fact: A separate forest provides an independent control plane, but trusts, shared privileged infrastructure and configured access can connect the environments again. Evaluate isolation together with those dependencies.

Sources

• Microsoft · Understanding the Active Directory Logical Model
  Forest/domain shared logical structure, schema/configuration, domain partitioning, and same-forest trusts.
• Microsoft · Service Administrator Scope of Authority
  Forest service-administrator access across all forest data/services and the separate-forest boundary for groups that cannot accept this risk.
• Microsoft · Forest Design Models
  Organizational, resource, and restricted-access forest models; separate accounts/workstations; optional separate physical network.
• Microsoft · How AccessCheck Works
  Requested access is evaluated against the caller token and object DACL.
• Microsoft Open Specifications · SID Filtering and Claims Transformation
  Trust-boundary-specific SID filtering behavior.
• Microsoft · Allowed-To-Authenticate extended right
  The control access right limits who can authenticate to a particular computer or service; forest selective-authentication behavior is configuration-specific.
• Microsoft · Audit Security Group Management
  4728/4729 global and 4756/4757 universal security-group membership event families.