1.7 Forest and Domain Trust Relationships

Forest and Domain Trusts

A trust is the plumbing that lets a user account in one directory be recognised by a resource in another. Mergers and acquisitions, subsidiary forests kept deliberately separate, and Microsoft Entra Domain Services resource forests all raise the same three questions the exam tests repeatedly: which type of trust, in which direction, and with which security controls.

---

1. Active Directory Trust Architecture: Types and Directions

Trust relationships establish communication channels between separate Active Directory domains or forests, allowing security principals (users) in an account domain to be authenticated and authorized to access resources in a resource domain.

+-----------------------------------------------------------------------------+
|                       ACTIVE DIRECTORY TRUST TYPOLOGY                       |
|                                                                             |
|   TRUST TYPE      SCOPE                  TRANSITIVITY    COMMON SCENARIOS   |
|   --------------+----------------------+---------------+--------------------|
|   Forest Trust  | Between two Forest   | Transitive    | M&A, enterprise    |
|                 | Root domains         |               | forest integration |
|   External      | Between domains in   | Non-transitive| Legacy NT4, isolated|
|                 | different forests    |               | single-domain link |
|   Shortcut      | Between domains in   | Transitive    | Optimizes Kerberos |
|                 | same forest / forest |               | path in deep trees |
|   Realm         | AD DS domain to non- | Transitive or | UNIX / Linux MIT   |
|                 | Windows Kerberos     | Non-transitive| Kerberos realms    |
+-----------------------------------------------------------------------------+

+-----------------------------------------------------------------------------+
|                        THE TRUST DIRECTION AXIOM                            |
|                                                                             |
|   [TRUSTING DOMAIN] (Resource Domain) ===(Trust Arrow)===> [TRUSTED DOMAIN] |
|   - Contains File Shares, Apps, VMs                         (User Domain)   |
|   - TRUSTS the user domain's authentication                 - Contains Users|
|                                                                             |
|   * ACCESS FLOW: Users flow OPPOSITE to the Trust Arrow (Trusted -> Trusting)|
+-----------------------------------------------------------------------------+

[!IMPORTANT] The Trust Direction Golden Rule: The Trusting Domain is the Resource Domain (where servers, shares, and applications reside). The Trusted Domain is the Account Domain (where user accounts reside). The direction of trust points from Trusting to Trusted, but the flow of user access is the exact opposite—from Trusted (users) to Trusting (resources).

---

2. Trust Security: Selective Authentication & SID Filtering

When establishing cross-forest trusts, identity administrators must implement defense-in-depth security controls to prevent unauthorized lateral movement and privilege escalation.

+-----------------------------------------------------------------------------+
|                 SELECTIVE AUTHENTICATION VS FOREST-WIDE AUTH                |
|                                                                             |
|   [FOREST-WIDE AUTHENTICATION]                                              |
|   - Default setting for intra-forest domains and trusted partners           |
|   - Any user in the trusted forest can authenticate to any server           |
|   - Access is governed purely by standard NTFS/share ACLs                   |
|                                                                             |
|   [SELECTIVE AUTHENTICATION] (High Security Boundary)                       |
|   - Authentication requests across the trust are blocked by default         |
|   - Users in the trusted forest CANNOT authenticate to a resource server    |
|     unless explicitly granted the 'Allowed to Authenticate' permission on   |
|     the specific computer object in Active Directory Users and Computers    |
+-----------------------------------------------------------------------------+

1. Selective Authentication Implementation

When configuring a Forest Trust across organizational boundaries (e.g., between two independent enterprise subsidiaries), select Selective Authentication. When enabled:

• Kerberos tickets presented by users from the foreign forest are validated at the domain boundary.
• The domain controller checks if the user has been explicitly granted the Allowed to Authenticate permission on the target computer object's discretionary access control list (DACL).
• If the permission is not granted, the user receives an Access Denied error before any application or service code executes.

2. SID Filtering (Quarantine) Mechanics

• The Elevation Vulnerability: When a user logs on across a trust, their Kerberos Privilege Attribute Certificate (PAC) contains a list of their group SIDs. A malicious administrator in a trusted external forest could inject well-known administrative SIDs (e.g., S-1-5-21-...-512 Domain Admins) into a user's PAC, attempting to gain instant administrative rights in the trusting forest.
• SID Filtering Defense: SID Filtering (enabled by default on all external and forest trusts) strips out all foreign, non-authoritative SIDs from the Kerberos ticket at the trust boundary.
• Management Command:

  :: Enable SID filtering (quarantine) on a trust relationship
  netdom trust TrustingDomain.com /domain:TrustedDomain.com /quarantine:yes
  

---

3. Trusts Inside a Forest Are Automatic

Nothing in the previous sections applies to the trusts you never create. When a child domain is added to an existing domain, Active Directory automatically builds a parent-child trust; when a second domain tree is added to a forest, it builds a tree-root trust. Both are two-way and transitive, and both are created and maintained by the system — you cannot delete them without removing the domain. Transitivity across the forest is exactly why a user in sales.eu.contoso.com can be granted rights on a server in corp.contoso.com with no administrator ever touching Active Directory Domains and Trusts.

The trust you do create inside a forest is the shortcut trust, and it exists purely for performance. Kerberos referrals normally walk the domain tree upward to the forest root and back down again; in a deep or wide forest that can be several referral hops. A shortcut trust between two heavily interoperating leaf domains short-circuits that path. It can be one-way (referrals accelerate in one direction only) or two-way.

[!IMPORTANT] The transitivity trap. A forest trust is transitive inside the two forests it joins — every domain in Forest A can reach every domain in Forest B. It is not transitive between forest trusts. If Contoso trusts Fabrikam and Fabrikam trusts Northwind, Contoso does not trust Northwind. A third forest requires a third explicit trust.

4. Creating, Validating and Troubleshooting a Trust

There is no New-ADTrust cmdlet. Trusts are created in the Active Directory Domains and Trusts console, with netdom trust, or programmatically through the .NET System.DirectoryServices.ActiveDirectory classes. The ActiveDirectory PowerShell module can read trusts with Get-ADTrust — a distinction worth remembering, because an exam item that offers New-ADTrust as an answer is offering a cmdlet that does not exist.

:: Create a two-way forest trust (run from a Domain Admin context in the local forest root)
netdom trust corp.contoso.com /domain:corp.fabrikam.com /twoway /transitive:yes /add ^
    /userD:FABRIKAM\Administrator /passwordD:*

:: Validate an existing trust in both directions and reset the trust password if needed
netdom trust corp.contoso.com /domain:corp.fabrikam.com /verify /verbose
netdom trust corp.contoso.com /domain:corp.fabrikam.com /resetOneSide /userD:...

:: Enumerate every trust the local domain knows about
nltest /domain_trusts /all_trusts /v

# Read trust objects, their direction and whether SID filtering (quarantine) is on
Get-ADTrust -Filter * |
    Format-Table Name,Direction,ForestTransitive,IntraForest,SIDFilteringForestAware,SelectiveAuthentication

Name resolution is the usual failure point. Before a trust can be created, each forest must be able to resolve the other's domain names and locate its domain controllers. The supported options are a conditional forwarder in each forest pointing at the other's DNS servers, a secondary or stub zone, or a shared root DNS infrastructure. A trust creation wizard that fails with "the specified domain either does not exist or could not be contacted" is nearly always a DNS problem, not a credential problem.

Firewall requirements are broader than administrators expect, because trust traffic is ordinary directory and authentication traffic: DNS on TCP/UDP 53, Kerberos on TCP/UDP 88, LDAP on TCP/UDP 389 (and 636 for LDAPS), SMB on TCP 445, the RPC endpoint mapper on TCP 135, and the dynamic RPC range TCP 49152–65535.

Name Suffix Routing and SID History

Two forest-trust-only features round out the picture:

• Name suffix routing controls which UPN suffixes are routed across the forest trust. If Fabrikam also owns the fabrikam-eu.com suffix, that suffix must be enabled on the trust before users signing in with it can be authenticated by Contoso. Suffixes that collide with a suffix the local forest already owns are disabled automatically and cannot be enabled — a genuine constraint during mergers where both companies claim the same namespace.
• SID history carries a migrated user's former SID so that existing ACLs keep working after an Active Directory Migration Tool (ADMT) migration. SID filtering strips exactly those foreign SIDs, so during an active migration the trust must have quarantine disabled (netdom trust ... /quarantine:no) for SID history to be honoured — and it should be re-enabled the moment ACL re-permissioning is complete.

:: Enable selective authentication on an existing forest trust
netdom trust corp.contoso.com /domain:corp.fabrikam.com /SelectiveAUTH:yes

:: Review and enable a UPN suffix routed across a forest trust
netdom trust corp.contoso.com /domain:corp.fabrikam.com /NameSuffixes