Domain Trusts

ActiveDirectoryFoundationsintermediate14 min

Domain trusts define how authentication and access flow between domains and forests in Active Directory. This lesson explains what trusts are, why they exist, how they change the scope of both legitimate access and potential compromise, and how to explain trust relationships clearly in interviews.

This lesson builds on

Theory

Core Idea

A trust in Active Directory is a relationship between two domains that allows users in one domain to authenticate to resources in the other. Trusts exist because organizations often have more than one domain — separate divisions, acquired companies, or partner organizations — and need a way for users to access resources across domain boundaries without maintaining separate accounts in every domain. The trust relationship tells the domain controllers in each domain to accept authentication requests that originate from the trusted domain.

Without a trust, a user in Domain A has no way to authenticate to anything in Domain B. With a trust, the authentication infrastructure bridges the gap. Trusts have three key properties: direction, transitivity, and type — which way authentication flows, whether the trust extends through intermediate domains, and what kind of relationship the trust represents.

Mental Model

Think of trusts as bridges between separate territories. Each domain is its own territory with its own gates and guards (domain controllers). By default, there is no way for someone from one territory to enter another. A trust builds a bridge and tells the guards on the receiving side to accept credentials issued by the other territory's authorities.

The direction of the trust determines which way people can cross: a one-way trust lets users from the trusted domain access resources in the trusting domain, but not the reverse. A two-way trust lets users cross in both directions. Transitivity determines whether the bridge extends through intermediate stops: if Domain A trusts Domain B and Domain B trusts Domain C, a transitive trust means Domain A also trusts Domain C; a non-transitive trust means it does not.

Trusts expand the blast radius of a compromise. If Domain A trusts Domain B and an attacker compromises Domain B, the trust may give them a path into Domain A — depending on the trust type, the permissions configured across the boundary, and whether SID filtering is enforced.

Why It Matters

Trusts determine the boundaries of an Active Directory environment. A single-domain AD has a simple boundary, but most enterprise environments have multiple domains, often in multiple forests, connected by trust relationships that allow users in one domain to access resources in another.

If you cannot explain how trusts work, you cannot reason about whether a compromise in one domain can reach another, which is one of the most critical questions in any multi-domain assessment. Understanding trust direction, transitivity, and the distinction between intra-forest and inter-forest trusts is foundational knowledge that directly shapes how you scope attacks and explain cross-domain risk.

Key Concepts

Trust direction — a trust has a direction: the trusting domain allows access from the trusted domain; in a one-way trust A→B, users in B can access resources in A, but not the reverse; two-way trusts allow access in both directions
Transitivity — a transitive trust extends through chains: if A trusts B and B trusts C, then A implicitly trusts C; all intra-forest trusts are transitive by default; external (inter-forest shortcut) trusts are non-transitive by default
Intra-forest trusts — automatically created between all domains in the same forest; two-way, transitive, and implicit; this is why compromising any domain in a forest typically provides a path to every other domain in that forest
Inter-forest trusts — manually created between domains in different forests; can be one-way or two-way; non-transitive by default; the forest is the trust boundary, and inter-forest trusts are more restrictive than intra-forest ones
SID filtering — a security mechanism on inter-forest trusts that strips foreign SIDs from authentication tokens crossing the trust boundary; prevents an attacker in one forest from injecting privileged SIDs (like Enterprise Admins) to gain access in the other forest; enabled by default on inter-forest trusts, not on intra-forest trusts
Parent-child trusts — automatically created when a child domain is added to an existing domain tree; two-way, transitive; these are the default intra-forest trusts that connect every domain in a forest into a single trust fabric
Authentication flow versus authorization — a trust allows authentication across the boundary (proving identity), but authorization (what the authenticated user can access) is still controlled by the resource domain's permissions; a trust does not automatically grant access to anything

Common Misunderstandings

Thinking trust direction is intuitive. The naming convention is confusing: in a one-way trust where Domain A trusts Domain B, it is users in Domain B who gain access to resources in Domain A. The direction of access flows opposite to what the word 'trusts' suggests. Drawing the arrow as 'authentication flows from B to A' helps clarify this.
Assuming a trust grants access to everything. A trust enables authentication across the boundary, but it does not grant permissions. A user from Domain B who authenticates to Domain A via a trust can only access resources where they (or their groups) have been explicitly granted permissions. Without permissions in the resource domain, the trust provides nothing except the ability to authenticate.
Treating all trusts as equal risk. Intra-forest trusts (parent-child, tree-root) are two-way, transitive, and do not have SID filtering enabled. This means compromising one domain in a forest almost always provides a path to every other domain. Inter-forest trusts are more restrictive: non-transitive by default and SID-filtered by default. The risk profile is fundamentally different.
Not understanding that the forest is the real security boundary. Many people assume the domain is the security boundary, but domains within the same forest share a schema, a configuration partition, and transitive two-way trusts without SID filtering. The Enterprise Admins group in the forest root domain has administrative access to every domain in the forest. The domain is an administrative boundary; the forest is the security boundary.
Ignoring trust relationships during assessments. In multi-domain environments, enumerating trusts early tells you the scope of the environment, whether cross-domain paths exist, and whether the compromise of your current domain has implications beyond its boundary. Skipping trust enumeration means you may miss the most impactful paths.

In Real Engagements

In real assessments, trust relationships determine how far a compromise can reach. When you compromise a child domain, the intra-forest trust (two-way, transitive, no SID filtering) typically means you have a path to the forest root domain — and from there, to every domain in the forest. This is why 'domain compromise' in a multi-domain forest often translates to 'forest compromise.'

When you encounter inter-forest trusts, the situation is more nuanced: SID filtering prevents direct SID injection attacks, but users from the trusted forest may still have explicit permissions in the trusting forest that an attacker can exploit. Explaining trust relationships to clients is critical: they need to understand that their 'separate' domains within the same forest are not security-isolated, and that a trust to a partner organization's forest creates a potential lateral path that both organizations need to manage. The most common misconception you will address is the belief that having separate domains provides security separation. Within a forest, it does not.

Communication

How to Explain It in an Interview

Domain trusts are relationships that allow users in one domain to authenticate to resources in another, bridging what would otherwise be completely separate authentication boundaries. Trusts have direction (one-way or two-way), transitivity (whether the trust extends through chains), and type (intra-forest, inter-forest, external).

The most important thing to understand is the difference between intra-forest and inter-forest trusts. Intra-forest trusts are automatic, two-way, transitive, and do not have SID filtering — which means compromising one domain in a forest almost always provides a path to every other domain.The forest is the real security boundary, not the domain. Inter-forest trusts are more restrictive: non-transitive by default and SID-filtered, which limits cross-forest privilege escalation.

But users from one forest may still have explicit permissions in the other, so the trust still expands the attack surface. When I enumerate trusts during an assessment, I am mapping the boundaries: where can this compromise reach, and what stands in the way.

Likely Follow-Up Questions

What is the difference between a one-way and a two-way trust, and which direction does access actually flow?
Why is the forest the security boundary rather than the domain?
What is SID filtering, and why does its presence or absence on a trust matter?
If you compromise a child domain in a multi-domain forest, what does that typically mean for the parent domain?
How would you explain to a client that their separate domains within the same forest do not provide security isolation?

Study Kit