Active Directory Domain Trusts: Direction, Transitivity, SID Filtering, and Blast Radius

1. Introduction

Domain and forest trusts let users in one domain access resources in another without a second set of credentials. They are essential for mergers, multi-region operations and B2B collaboration — but a trust is, by definition, a hole in a security boundary. Many organisations treat the forest as the true security boundary, yet misconfigured trusts (missing SID filtering, over-broad transitivity, unnecessary trusts to lower-trust forests) let an attacker who compromises one domain pivot into another. Understanding trust direction, transitivity and SID filtering is what turns “we have a trust” into “we understand our real blast radius”.

2. How It Works

Trusts establish authentication relationships between domains/forests:

• Parent/child & tree-root trusts: created automatically within a forest; two-way and transitive.
• Forest trust: between two forest root domains; can be one- or two-way, transitive across the forests.
• External trust: to a single domain (often in another forest or a legacy domain); non-transitive.
• Realm trust: to a non-Windows Kerberos realm.

Trust DIRECTION (who trusts whom):
  A --trusts--> B   means users in B can be granted access to resources in A
  (trust arrow points from the resource/trusting domain to the trusted domain)

Two-way = both directions.  Transitive = trust "flows through" (A trusts B, B trusts C => A trusts C).
Non-transitive = only the two named domains.

SID filtering is the key control: when a user from a trusted domain presents a token, the trusting domain can filter out SIDs that do not belong to the trusted domain (particularly high-privilege SIDs and SID history), preventing a forged token from claiming privileges it should not have. Selective authentication further requires that users be explicitly granted the “Allowed to authenticate” right on specific resources, rather than being able to authenticate broadly.

3. The Security Problem

Risks include: (1) Disabled or weak SID filtering — a compromised trusted domain can inject SIDs (via SID history) to claim privileges in the trusting domain, potentially escalating across the trust. (2) Over-broad transitivity — a trust to one partner can indirectly expose you to everything they trust. (3) Unnecessary or forgotten trusts to low-assurance or defunct domains. (4) Two-way trusts where one-way would suffice, doubling exposure. The forest — not the domain — is the security boundary precisely because intra-forest trusts are automatic and transitive; a compromise of any domain can threaten the forest root without strong tiering.

4. How Attackers Abuse It

Concept: After compromising one domain, an attacker enumerates trusts to map reachable domains, then looks for trusts where SID filtering is not enforced to forge a token that includes privileged SIDs from the trusting domain (a cross-domain/forest escalation concept). Even without forging, a two-way transitive trust may simply grant enough access to move laterally into partner resources. Trust enumeration is an early recon step because it defines how far a foothold can spread.

In an authorized assessment, the team enumerates trusts and validates SID-filtering posture in a lab to report which trusts widen the blast radius and how to constrain them — not to attack a partner organisation.

5. How to Detect / Enumerate & Audit It

Command

Get-ADTrust -Filter * | Select-Object Name, Direction, TrustType, ForestTransitive, IntraForest, SIDFilteringForestAware, SelectiveAuthentication

What it does: Lists every trust with its direction, type, transitivity and the key security flags (SID filtering awareness and selective authentication).

What to look for: Two-way trusts that could be one-way, transitive external/forest trusts, and especially trusts where SID filtering is not enforced or selective authentication is off.

Defensive use: Produces the authoritative trust inventory with the exact settings you must justify or fix.

Command

nltest /domain_trusts /v

What it does: Enumerates trusted domains from the client side, including trust flags and whether each is direct or via the forest.

What to look for: Unexpected trusted domains, trusts to defunct partners, or trust attributes indicating broad transitivity.

Defensive use: Cross-checks the AD view and works even where RSAT is limited; useful in incident response.

Command

Get-ADForest | Select-Object Name, RootDomain, Domains, GlobalCatalogs; Get-ADDomain | Select-Object DNSRoot, ParentDomain, ChildDomains

What it does: Shows the forest and domain structure — the internal (automatic, transitive) trust fabric.

What to look for: The full set of domains that implicitly trust each other; each child domain is a potential path toward the forest root if tiering is weak.

Defensive use: Establishes the internal blast radius that intra-forest trusts create.

Command

netdom trust corp.local /d:partner.example /verify

What it does: Verifies a specific trust relationship and its secure channel.

What to look for: Trusts that fail verification (stale/broken) — candidates for removal — and confirmation of direction.

Defensive use: Confirms which trusts are live and helps retire ones no longer needed.

6. How to Audit the Environment

• Inventory every trust; for each, document business justification, direction, transitivity and SID-filtering/selective-auth status.
• Confirm SID filtering is enforced on external and forest trusts (quarantine as appropriate).
• Identify two-way trusts that could be one-way and transitive trusts that could be scoped.
• Remove trusts to defunct or low-assurance domains.
• Check for SID history on accounts, which interacts with cross-domain privilege claims.
• Verify tiered administration so a child-domain compromise cannot trivially reach the forest root.

7. How to Fix / Harden It

• Enforce SID filtering / quarantine on external and forest trusts (it is on by default for newer trusts; verify legacy ones).
• Enable selective authentication on partner trusts so access is explicitly granted per resource.
• Prefer one-way trusts where only one side needs access.
• Remove unnecessary and stale trusts.
• Clean up unnecessary SID history.
• Treat the forest as the security boundary; separate sensitive assets into their own forest if trust cannot be sufficiently constrained.

8. Detection & Monitoring

• Event ID 4706/4707 (a new trust was created / a trust was removed) — alert on any trust change; these should be rare and change-controlled.
• Event ID 4716/4717/4718 (trusted domain information modified / auth policy changes) — watch for SID-filtering or selective-auth downgrades.
• Event ID 4769/4768 for cross-realm ticket requests (referrals) from unusual sources.
• Behavioural: authentication from a trusted domain to sensitive resources that have no business relationship with that domain.

9. MITRE ATT&CK Mapping

Technique	ID
Domain Trust Discovery	T1482
Steal or Forge Kerberos Tickets: Golden Ticket (cross-domain via SID history)	T1558.001
Valid Accounts: Domain Accounts	T1078.002
Account Manipulation: SID-History Injection	T1134.005

10. Practical Lab

In an isolated multi-forest lab:

1. Create an external or forest trust between two lab forests and enumerate it with Get-ADTrust and nltest /domain_trusts /v.
2. Toggle SID filtering and selective authentication and observe the flag changes in Get-ADTrust output.
3. Grant “Allowed to authenticate” on a specific resource and confirm selective auth restricts access as expected.
4. Enable auditing and observe Events 4706/4716 when creating or modifying the trust.
5. Verify and then remove the trust with netdom trust ... /verify, confirming Event 4707 on removal.

11. Key Takeaways

• A trust is a deliberate hole in a boundary — inventory and justify every one, with direction and transitivity documented.
• Enforce SID filtering and consider selective authentication on external/forest trusts.
• Prefer one-way trusts; remove stale ones; clean up SID history.
• The forest, not the domain, is the security boundary — isolate crown jewels accordingly.
• Alert on trust creation/modification events (4706/4716/4717) as high-severity, rare changes.

Continue learning: Active Directory security

This guide is part of our Active Directory Security series. Related guides:

• DNS and Active Directory: SRV Records, Dynamic Updates, and Spoofing Risks
• Active Directory ACLs and Attack Paths: How Small Permissions Become Domain Admin
• Group Policy Security: SYSVOL, GPO Permissions, and the cpassword Legacy