Hardening AD trusts and forest boundaries

Active Directory documentation and much of the tooling around it still talks about "domain security" as if a domain were an isolation boundary. It is not. Every domain controller in a forest holds a full, writable replica of the Schema and Configuration partitions, every domain trusts the forest root implicitly, and Enterprise Admins in the forest root domain has rights over every domain in the forest. Treating a child or resource domain as a security boundary and skimping on trust hardening is one of the most persistent design mistakes in AD estates, and it is exactly what lets an attacker who lands in a low-value domain pivot into the domain that actually matters.

This post covers how to inventory and harden the trusts inside and across your forests: trust types and transitivity, SID filtering and quarantine, selective authentication, and when a dedicated administrative forest or PAM trust is actually justified versus when the modern enterprise access model covers you already.

The forest is the boundary, not the domain

A few facts that should drive every trust decision:

• The Schema partition and Configuration partition replicate to every DC in the forest. A schema change or a malicious Configuration-partition object (for example, a rogue Group Policy container or a forged site link) affects all domains.
• Enterprise Admins and Schema Admins (forest root domain) have forest-wide rights, including the ability to modify the schema and add domains.
• Any domain controller compromise — in any domain — is a credible path to full forest compromise via replication abuse, schema tampering, or trust exploitation.

Practical consequence: if you need genuine isolation (a subsidiary that must not affect your core estate, an M&A acquisition of unknown hygiene, a regulatory requirement for separate administration), you need a separate forest with a carefully scoped trust, not a child domain in the same forest.

Trust types and transitivity, briefly

Forest trusts and external trusts are the ones that cross a real security boundary and deserve the controls below. Intra-forest trusts are already inside your blast radius; fix that with tiering (Tier 0 and privileged access) rather than trust settings.

Inventory existing trusts first

Before changing anything, know what you have:

Get-ADTrust -Filter * -Properties * |
  Select-Object Name, Direction, TrustType, ForestTransitive, SIDFilteringForestAware, SIDFilteringQuarantined, SelectiveAuthentication, IntraForest, DisallowTransivity |
  Format-Table -AutoSize

For each trust, also check with netdom:

netdom trust <TrustingDomain> /domain:<TrustedDomain> /verify
netdom query trust

Flag any trust where:

• SIDFilteringQuarantined is False on an external trust, or SIDFilteringForestAware is True on a forest trust (SID history allowed across it).
• SelectiveAuthentication is False on an external or forest trust with an untrusted or lower-tier partner.
• The trust direction is bidirectional when only one direction is actually needed — a one-way outgoing trust from the sensitive side eliminates an entire attack path.
• The trust is old, undocumented, or tied to a decommissioned partner domain. Stale trusts are common in environments that went through mergers, divestitures, or migrations and never cleaned up afterward.

SID filtering and quarantine

SID history (sIDHistory) exists to preserve access across domain migrations: a user moved from domain A to domain B keeps their old SIDs so existing ACLs still resolve. The same mechanism is the basis of SID history injection — if an attacker compromises domain A (or a DC in it) and that trust doesn't filter SID history, they can attach the SID of, say, Enterprise Admins in domain B to a principal in domain A and authenticate as if privileged in B.

SID filtering is on by default for forest trusts (SIDs that do not belong to the trusted forest are dropped) and, as quarantine, for external trusts created with modern Windows Server versions, but it is frequently relaxed during migrations (/quarantine:no or /enablesidhistory:yes) and never reverted. Verify and enforce it:

:: Enable quarantine (SID filtering) on an external trust
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /quarantine:yes /userD:<Admin> /passwordD:*

:: On a forest trust: explicitly disable SID history acceptance (only re-enable temporarily during a real migration)
netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /enablesidhistory:no

Verify programmatically:

Get-ADTrust -Filter {Name -eq "<TrustedDomainName>"} | Select-Object Name, ForestTransitive, SIDFilteringQuarantined, SIDFilteringForestAware

SIDFilteringQuarantined should be True on every external trust, and SIDFilteringForestAware should be False on every forest trust, unless you are in an active, time-boxed migration window where SID history is required — in which case treat that window as a high-risk period, monitor 4728/4732/4756 group membership events closely, and disable SID history acceptance again as soon as the migration completes.

Selective authentication

SID filtering controls what identity claims are honored. Selective authentication controls what resources trusted-domain principals can even attempt to reach. On a forest or external trust with selective authentication enabled, a principal from the trusted domain gets no access anywhere in the trusting domain until an administrator explicitly grants the "Allowed to Authenticate" permission on specific computer objects.

Enable it:

netdom trust <TrustingDomainName> /domain:<TrustedDomainName> /selectiveauth:yes

Then grant access only where needed, per computer object, via the Security tab → Allowed to Authenticate, or with dsacls:

dsacls "CN=<TargetComputer>,OU=Servers,DC=trusting,DC=example,DC=com" /G "TRUSTEDDOMAIN\SomeGroup:CA;Allowed to Authenticate"

This turns an open trust — where any authenticated user from the partner domain can attempt to log on anywhere — into an explicit allow-list. It is the single highest-value control on an external or forest trust and should be the default posture for any trust to a partner you do not fully control.

SID history abuse: what to watch for

Even with quarantine enabled, monitor for anomalies rather than assuming the control is bulletproof:

• Sudden appearance of sIDHistory values on accounts outside a known, scheduled migration.
• Golden ticket-style Kerberos tickets carrying SID history for privileged groups — these show up as anomalous PAC contents in detection tooling and Microsoft Defender for Identity alerts.
• Authentication events from a trusted domain against Tier 0 assets that fall outside the "Allowed to Authenticate" grants you configured.

See Auditing, logging, and detection for the event IDs and SACL configuration that make this visible.

When you actually need a Red Forest or PAM trust

Microsoft's original ESAE (Enhanced Security Admin Environment), popularly called the "Red Forest," used a dedicated, hardened administrative forest with a one-way PAM (Privileged Access Management) trust into the production forest, so Tier 0 credentials never touched production-forest-joined workstations. Microsoft retired ESAE as its mainstream recommendation in late 2020, with its privileged access strategy, in favor of the modern enterprise access model built on Azure AD / Microsoft Entra ID, Privileged Access Workstations, and Just-In-Time/Just-Enough-Administration — because a standalone admin forest is expensive to run, itself becomes a target, and doesn't address cloud identity attack paths at all.

Still consider a dedicated administrative forest or PAM trust when:

• You are air-gapped or cannot adopt a cloud identity control plane (regulatory, classified, or OT environments).
• You have a very large, multi-forest estate where a genuinely separate administrative trust boundary reduces cross-forest blast radius more effectively than tiering alone.
• You need a bridge during a long-running AD-to-cloud identity migration and want Tier 0 isolated in the interim.

For the majority of estates, invest first in Tier 0 and privileged access tiering, Privileged Access Workstations, and the trust hardening in this article — that closes most of the same attack paths ESAE targeted, at a fraction of the operational cost.

What this breaks

• Cross-forest or cross-domain access that relied on an open (non-selective) trust. Applications, file shares, or service accounts authenticating across the trust from the partner domain will fail until you explicitly grant "Allowed to Authenticate" on each target computer object. Inventory cross-trust access patterns (via 4624/4625 logon events filtered by source domain) before flipping selective authentication on in production.
• Migrations that depend on SID history will break if you disable enablesidhistory while a migration is still in flight. Only quarantine SID history after migration work in that trust relationship is fully complete.
• Legacy trusts to decommissioned or low-hygiene partner domains may simply need to be removed rather than hardened — netdom trust /remove is often the right answer once you confirm the trust has no active dependents.

Pair this with Domain controller hardening and Object & ACL security — trust hardening limits what a compromised partner domain can reach, but it doesn't substitute for hardening the DCs and objects on your side of the trust.