Active Directory Trusts: Types, Transitivity, and SID Filtering Architecture

What Are Active Directory Trusts?

In an enterprise network, security boundaries rarely stay contained within a single domain. Mergers, acquisitions, multi-tiered security tiers, and cross-departmental shared services demand that users in one administrative namespace access file servers, databases, and applications hosted in another. Active Directory trusts provide the formal infrastructure mechanisms that make cross-domain authentication possible.

Think of Active Directory trusts like bilateral border control agreements between sovereign countries. When Country A and Country B establish a travel agreement, Country B agrees to recognise the validity of passports issued by Country A’s customs authority. However, having a valid passport does not grant a visitor unconditional access to Country B’s private office buildings, bank vaults, or military bases. The visitor must still present their passport at each individual building security desk, which decides whether to unlock the door.

In Windows Server, establishing a trust does not grant permissions to any data. Instead, it creates a secure communication channel between the domain controllers of two domains, sharing a cryptographic secret (the trust password). When a user in Domain A requests a resource in Domain B, Domain B’s domain controllers rely on Domain A’s domain controllers to authenticate the user and certify their identity. Once identity is verified, Domain B’s resource servers evaluate their own local Discretionary Access Control Lists (DACLs) to determine authorisation.

Trust Direction vs Access Flow: The Mnemonic Rule

The single most frequent point of confusion for systems administrators configuring trusts is directionality. When configuring a one-way trust, administrators routinely point the trust arrow in the wrong direction, inadvertently locking out the exact users they intended to support.

The governing rule is straightforward: trust flows in the opposite direction of access.

Consider two domains: accounts.example.com (where the employees log in) and resources.example.com (where the file shares and line-of-business applications reside). If users in accounts need to access servers in resources, which domain must extend trust?

The resources domain is the one taking the risk. It must trust the domain controllers in accounts to accurately verify who their users are. Therefore, resources is the trusting domain, and accounts is the trusted domain.

[User: Alice]
      │
      │ 1. Access Flow (Alice requests File Share)
      ▼
┌───────────────────────────┐         Trust Relationship        ┌───────────────────────────┐
│       Account Domain      │ ◀──────────────────────────────── │      Resource Domain      │
│   (accounts.example.com)  │    2. Trust Flow (Trusting Party) │   (resources.example.com) │
│       Trusted Domain      │                                   │       Trusting Domain     │
└───────────────────────────┘                                   └───────────────────────────┘
                                   Incoming Trust to Accounts
                                   Outgoing Trust from Resources

When viewed from the Active Directory Domains and Trusts management snap-in (domain.msc):

Incoming Trust: From the perspective of accounts, the trust is incoming. Other domains trust this domain, allowing its accounts to authenticate elsewhere.

Outgoing Trust: From the perspective of resources, the trust is outgoing. This domain trusts external accounts from the partner domain to access its local assets.

Two-Way Trust: Both domains simultaneously act as trusting and trusted authorities. Accounts in either domain can access permitted resources in the other.

Trust Types Compared: Forest, External, Realm, and Shortcut

Active Directory supports six distinct trust types. Choosing the correct type depends on the forest functional levels, DNS topologies, and whether the trust must span an entire forest or remain restricted to individual domains.

Parent-Child and Tree-Root Trusts: These are created automatically by Active Directory when domains are stood up. They are always two-way and transitive, binding all domains in a single forest into a unified authentication matrix.

Forest Trusts: Created manually between the root domains of two separate forests (both running at Forest Functional Level Windows Server 2003 or higher). A forest trust is transitive across all child domains in both forests. It supports Kerberos cross-forest referrals, Name Suffix Routing, and Selective Authentication.

External Trusts: Created manually between an Active Directory domain and a domain in a foreign forest, or an older legacy NT 4.0 domain. External trusts are strictly non-transitive: authentications cannot jump from the trusted domain to any other domain in that forest.

Shortcut Trusts: When two child domains sit deep within an expansive forest hierarchy, Kerberos authentication requests must walk up the domain tree to the common ancestor and back down to the target child. A shortcut trust creates a direct geometric bridge between those two child domains, cutting latency and eliminating dependency on intermediate domain controllers.

Transitivity and Kerberos Ticket Routing

Transitivity defines whether a trust relationship can extend beyond the two partner domains that directly negotiated it.

If Domain A trusts Domain B, and Domain B trusts Domain C:

In a transitive relationship, Domain A implicitly trusts Domain C. A user in Domain C can request resources in Domain A without requiring an explicit trust link between A and C.

In a non-transitive relationship (such as an External Trust), the chain halts immediately. Domain A will flatly reject authentication tokens originating from Domain C.

How does Kerberos actually navigate these trust boundaries? Through a process known as Kerberos referral ticketing.

[Client in Domain C]
       │
       │ 1. Request TGS for File Server in Domain A
       ▼
[KDC in Domain C] ─── 2. Returns Inter-Realm TGT for Domain B ───▶ [Client in Domain C]
                                                                          │
       ┌──────────────────────────────────────────────────────────────────┘
       │ 3. Present Inter-Realm TGT to KDC in Domain B
       ▼
[KDC in Domain B] ─── 4. Returns Inter-Realm TGT for Domain A ───▶ [Client in Domain C]
                                                                          │
       ┌──────────────────────────────────────────────────────────────────┘
       │ 5. Present Inter-Realm TGT to KDC in Domain A
       ▼
[KDC in Domain A] ─── 6. Returns Service Ticket for File Server ──▶ [Client in Domain C]
                                                                          │
       ┌──────────────────────────────────────────────────────────────────┘
       │ 7. Access File Share with Session Key + Encrypted PAC
       ▼
[File Server in Domain A]

When the client asks its local Key Distribution Center (KDC) for a service ticket to a server in a remote domain, the local KDC checks its trust tables. Finding a trust path, it issues a referral ticket (an inter-realm Ticket Granting Ticket encrypted with the shared inter-domain trust key). The client presents this referral ticket to the intermediate KDC, which inspects it and issues another referral ticket targeting the final domain’s KDC. Finally, the target KDC issues the true Service Ticket (TGS).

SID Filtering and Quarantine Architecture

While Kerberos ticket referrals establish authentication paths, they introduce a profound security risk: SID History Injection.

When a user authenticates in Active Directory, the KDC bundles their identity details into the Privilege Attribute Certificate (PAC) inside the Kerberos ticket. The PAC contains the user’s primary Security Identifier (SID), all group SIDs they belong to, and an attribute named sIDHistory.

The sIDHistory attribute was designed to ease domain migrations. When an enterprise migrates a user account from an old domain to a new domain using the Active Directory Migration Tool (ADMT), the user receives a new SID. To prevent immediate access loss to existing file shares before permissions can be updated, ADMT copies the user’s old SID into their sIDHistory. Windows resource servers inspect both the primary SID and all SIDs in sIDHistory when determining access.

Now consider the threat model across an untrusted boundary. If Forest A establishes a trust with Forest B, an administrator (or an attacker who compromised a domain controller) in Forest A could edit an account and populate its sIDHistory with the Enterprise Admins SID (S-1-5-21-...-519) of Forest B. Without validation, when that user connected to a server in Forest B, Forest B’s servers would treat them as a forest root administrator!

SID Filtering (also termed Quarantine) is the security mechanism built into Windows Server to prevent this exact privilege escalation attack.

When an authentication ticket crosses a trust boundary, the receiving domain controller intercepts the PAC and applies filtering rules:

1. Domain SID Validation: The receiving DC checks whether every SID in the ticket matches the known, registered domain SID of the trusted partner domain. Any SID from an unexpected domain namespace is stripped.

2. Well-Known Privileged RID Purge: SIDs representing sensitive administrative authorities are systematically purged from cross-forest tickets, regardless of whether they appear in the primary group list or sIDHistory.

On External Trusts, SID filtering is controlled via the Quarantine setting:

When quarantine is enabled (/quarantine:yes), the trusting domain restricts authentication tokens strictly to the trusted domain’s primary SID, discarding all SID history. In modern Windows Server versions, quarantine is enabled by default on newly created external trusts.

On Forest Trusts, SID filtering is enabled natively by default. If a migration occurred and users genuinely require their migrated SID history to work across the forest boundary, administrators can selectively permit it using the /enablesidhistory:yes switch in netdom.

Forest-Wide vs Selective Authentication

When you create a forest or external trust, Active Directory prompts you to choose between two authentication security scopes:

1. Forest-Wide Authentication (Default): Any authenticated user in the trusted forest is granted automatic authentication access to all servers and workstations in the trusting forest. Users are placed into the local “Authenticated Users” group when they connect. Access control relies entirely on the NTFS permissions, share permissions, and local policies defined on each individual resource server.

2. Selective Authentication: Active Directory does not automatically authenticate incoming accounts. Instead, an explicit access check is enforced at the domain controller level before a ticket granting service (TGS) request is fulfilled.

Under Selective Authentication, a user from the trusted forest attempting to access a member server in the trusting forest receives an immediate “Access is denied” error unless that user (or a group they belong to) has been granted the Allowed to Authenticate permission on the Active Directory computer object representing that specific server.

This permission is an Active Directory extended right (ADS_RIGHT_ACTRL_DS_CONTROL_ACCESS). It allows enterprises to construct hardened demilitarised zones (DMZs) or contractor environments where external users can only communicate with a single isolated application server, without having the ability to query, scan, or authenticate to other internal servers or domain controllers.

# Grant an external security group "Allowed to Authenticate" on a specific server computer object
# 1. Open Active Directory Users and Computers (dsa.msc) with Advanced Features enabled
# 2. Locate the target Computer object -> Properties -> Security tab
# 3. Add the trusted domain user/group and check "Allowed to Authenticate"

Management Reference: PowerShell, Netdom, and Nltest

Managing and inspecting trusts in production requires a combination of the Active Directory PowerShell module for inspection and the battle-tested command-line tools netdom.exe and nltest.exe for channel testing and security configuration.

# Query all active trusts configured on the current domain
Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection, SelectiveAuthentication, IntraForest

# Retrieve full details for a specific trust relationship
Get-ADTrust -Identity "partner.net" -Properties * | Format-List Name, Target, TrustDirection, TrustType, SelectiveAuthentication, SIDFilteringQuarantined

# Test secure channel and discover the DC servicing the trust via nltest
nltest /sc_query:partner.net

# Verify trust authentication channel and force validation
nltest /sc_verify:partner.net

# Query all trusts visible to the local domain controller with transitivity flags
nltest /domain_trusts /v

# Enable SID Filtering (Quarantine) on an external trust using netdom
netdom trust trusting.example.com /Domain:trusted.partner.net /Quarantine:yes

# Check the current quarantine status of an external trust
netdom trust trusting.example.com /Domain:trusted.partner.net /Quarantine

# Disable SID History pass-through on a forest trust (default hardened state)
netdom trust trusting.example.com /Domain:trusted.partner.net /EnableSIDHistory:no

# Verify the shared trust secret password between both domains
netdom trust trusting.example.com /Domain:trusted.partner.net /Verify

# Reset the trust password without tearing down the trust configuration
netdom trust trusting.example.com /Domain:trusted.partner.net /Reset /UserO:admin@trusting.example.com /PasswordO:*

Troubleshooting Cheat Sheet & Common Error Codes

Trust failures manifest with cryptic error codes in Event Viewer or pop-up dialogues on end-user machines. The following cheat sheet maps common enterprise symptoms directly to their root causes and diagnostic remedies.

Final Thoughts

Active Directory trusts form the foundation of cross-boundary enterprise architecture. While standing up a basic two-way forest trust takes only minutes in the administrative wizard, operating it securely requires understanding the subtle boundaries of Kerberos ticket routing, transitivity propagation, and SID filtering.

By adhering to the directional rule (“trust flows opposite to access”), enforcing Selective Authentication on sensitive perimeter hosts, and keeping SID filtering quarantined by default, you ensure that external business units and partners obtain the exact access they need without exposing your forest root to privilege escalation vulnerabilities.