Active Directory — Part 9 — Trust Relationships

Introduction

Back in Part 2, we established the forest as Active Directory’s security boundary: a self-contained world with its own schema, its own Domain Controllers, its own identities. Everything since has happened inside that world.

But companies do not stay self-contained. Your company acquires another. A subsidiary runs its own forest. A partner needs access to one application. On day one of a merger, five hundred people from a directory you do not control need to reach file shares in yours.

Do you create five hundred duplicate accounts and force everyone to juggle two passwords? Before trusts, that was the reality. A trust relationship is the mechanism that makes it unnecessary.

What Is a Trust?

A trust is an agreement between two domains or forests that lets one side accept the other side’s authentication. When a trust exists, a Domain Controller in your domain can effectively say: I did not verify this user myself, but their Domain Controller did, and I trust their Domain Controller.

The crucial detail: a trust does not grant anyone access to anything. It only makes authentication possible across the boundary. Access still has to be granted the normal way — permissions, security groups, the AGDLP pattern from Part 4. A trust opens the door to the building’s reception desk, not to any office inside it.

The Two-Buildings Analogy

Think of two office buildings, each with its own reception desk issuing its own staff badges.

A trust is an agreement between the two receptions. If Building A trusts Building B, then A’s reception accepts badges issued by B — people from B can walk into A’s lobby. It does not work the other way around: A’s staff still cannot enter Building B unless B separately agrees to trust A.

And a badge only gets you through the lobby. Which meeting rooms you can book and which floors your badge unlocks is decided by Building A’s own facilities team — badge acceptance and room permissions are two different systems, exactly like authentication and authorisation.

Trust Direction: The Part Everyone Gets Backwards

Trust direction and access direction point opposite ways, and this trips up almost everyone at first.

If DomainA trusts DomainB, then DomainA is the trusting domain with the resources, DomainB is the trusted domain with the accounts — and it is B’s users who gain access to A’s resources. The trust points one way; the users flow the other.

One-way trust:

[DomainA]  ───── trusts ─────▶  [DomainB]
(resources)                     (accounts)

[DomainA]  ◀──── access ─────  [DomainB's users]

Two-way trust: both arrows exist in both directions.

A two-way trust is simply two one-way trusts in opposite directions: each side accepts the other’s users. Most trusts inside a forest are two-way; trusts between organisations are often deliberately one-way, because the sharing is one-sided.

Transitive or Not

A transitive trust extends through domains: if A trusts B and B trusts C, then A effectively trusts C. Inside a forest, all the automatic parent-child trusts are transitive — which is why any user in a forest can, in principle, authenticate to any domain in it.

A non-transitive trust is a strict point-to-point agreement between exactly two domains. Nothing flows through it. External trusts are non-transitive by design — you agreed to trust one specific domain, not everyone that domain happens to trust.

The Trust Types

How Authentication Crosses a Trust

Kerberos handles cross-domain access with referrals. When a user in the trusted forest requests access to a server in the trusting forest, their own KDC cannot issue a service ticket for a foreign service — instead it issues a referral ticket, vouching for the user to the other side. The user’s client presents that referral to a KDC in the resource forest, which then issues the actual service ticket.

The mechanics are the same ticket flow from Part 5, with one extra hop between ticket counters. And it depends entirely on each side being able to resolve the other’s DNS — which is why every trust conversation starts with the DNS work from Part 8.

A Real Scenario: Two Companies Merging

Contoso acquires Fabrikam. Both run their own single-domain forests. The integration project will eventually migrate Fabrikam’s users into Contoso’s forest, but that is a year away — and on day one, Fabrikam’s staff need Contoso’s file shares, intranet, and printers.

The pragmatic sequence looks like this. First, network and DNS: connect the two networks and create conditional forwarders in each forest for the other’s DNS zone. Second, create a one-way forest trust in which Contoso trusts Fabrikam — Fabrikam’s users can now be granted access to Contoso resources, but Contoso’s users get nothing in Fabrikam’s forest, keeping the exposure one-sided and small. Third, grant actual access: Contoso creates domain local groups on its resources and adds Fabrikam’s global groups to them — AGDLP from Part 4, now spanning two forests.

If the collaboration deepens — Fabrikam’s staff need to be reachable both ways — the trust becomes two-way. And when the migration finally happens, accounts move across with SID history so old permissions keep working, the trust carries the load during the transition, and it is decommissioned once the last account has moved.

Trusts and Security

A trust extends your attack surface to include a directory you do not control. If the trusted forest is compromised, the attacker holds accounts your forest accepts. Two safeguards matter.

SID filtering, enabled by default on forest and external trusts, strips foreign SIDs out of incoming authentication — blocking the classic attack where someone in the trusted forest injects your Domain Admins SID into their own token via SID history. Disabling it is occasionally necessary during migrations, and should be treated as temporary every time.

Selective authentication goes further: instead of letting every trusted user authenticate anywhere in your forest, each computer must explicitly grant “Allowed to Authenticate” before any trusted user can even attempt access to it. More administration, far smaller exposure — the right trade for low-trust relationships.

Scripts / Commands

Use the commands below to list existing trusts, verify their health, and inspect their properties. All are read-only except netdom trust with reset options.

# List all trusts for this domain
nltest /trusted_domains

# List trusts with type, direction, and transitivity
netdom query trust

# Verify a specific trust is healthy
netdom trust corp.example.com /domain:fabrikam.com /verify

# PowerShell: list trusts with full detail
Get-ADTrust -Filter * |
    Select-Object Name, Direction, ForestTransitive, SelectiveAuthentication, SIDFilteringForestAware

# PowerShell: check a specific trust
Get-ADTrust -Identity fabrikam.com

# Confirm DNS resolution of the other forest - the usual failure point
Resolve-DnsName fabrikam.com -Type NS

# Test authentication across the trust from the resource side
nltest /sc_verify:fabrikam.com

Troubleshooting Cheat Sheet

Quick Reference Summary

Final Thoughts

Trusts are Active Directory acknowledging that organisations are messy. Directories get built, companies merge, partners come and go — and identity has to bridge those boundaries without duplicating every account on both sides.

The discipline is in remembering what a trust is not. It is not access — that still has to be granted group by group. And it is not free — every trust is a statement that you accept another directory’s security posture as an input to your own. Create them deliberately, scope them tightly, and remove them when their reason has gone.