In this article, I have cover everything about Active Directory (AD) Trusts — why they are created, the different types of AD Trusts with examples, their purposes, requirements, and the step-by-step process to create them.
Why Do We Create Active Directory Trusts?
Creating an Active Directory (AD) trust allows two or more AD domains or forests to securely share resources and authenticate users across boundaries. Below are the reasons why AD trusts are created or need:
Main Reasons to Create an AD Trust:
- Cross-Domain/Forest Authentication:
- Users in one domain or forest can access resources (like files, applications, printers) in another without needing separate credentials.
- Resource Sharing across Organizations:
- In mergers, acquisitions, or partnerships, organizations can connect their separate AD environments without fully integrating them.
- Security and Access Control:
- Trusts allow fine-grained control over which users can access what resources, while still keeping domain boundaries intact.
- Delegation of Administrative Control:
- Administrators in one domain can manage access to resources in another without having full control over it.
- Support for Complex Organizational Structures:
- Large enterprises with multiple domains (e.g., by department or geography) use trusts to allow seamless access across those domains.
AD Trust types with example :
To understand the various AD trust types, I will use two root domains: lab.com and test.com. These domains represent two separate Active Directory forests and are ideal for demonstrating cross-forest and intra-forest trust relationships.
1. Parent-Child Trust
- Scope: Within the same forest
- Creation: Automatically created when a child domain is added
- Direction: Two-way (both domains trust each other)
- Transitivity: Transitive (trust flows through the hierarchy)
- Use Case: Enforces a natural hierarchy and trust inheritance.
Example:
- When a child domain, sales.lab.com, is added to lab.com, a parent-child trust is automatically created:
- lab.com ↔ sales.lab.com
- Because the trust is transitive, if sales.lab.com trusts hr.lab.com, then lab.com also trusts hr.lab.com.
2. Tree-Root Trust
- Scope: Between different domain trees in the same forest
- Creation: Automatically created when a new root domain tree is added to the same forest
- Direction: Two-way
- Transitivity: Transitive
- Use Case: Allows multiple domain trees in a forest to trust each other.
Example:
- If you add a second domain tree, dev.test.local, to the same forest as lab.com, a tree-root trust is created:
- lab.com ↔ dev.test.local
- Both domains trust each other, and their child domains will also trust each other due to transitivity.
Note: This applies only when lab.com and test.com are in the same forest. If they are in separate forests, a Forest Trust is needed (see below).
3. External Trust
- Scope: Between domains in different forests
- Creation: Manual
- Direction: One-way or Two-way (admin-defined)
- Transitivity: Non-transitive
- Use Case: Allows selective sharing of resources between domains in different forests without a full trust.
Example:
- You want lab.com to allow access for users in an old domain, legacy.test.com, but without trusting the entire forest:
- lab.com ↔ legacy.test.com
- This trust is limited and does not extend to other domains within the test.com forest or its child domains.
4. Forest Trust
- Scope: Between two separate AD forests
- Creation: Manual
- Direction: One-way or Two-way
- Transitivity: Transitive (only at the root domain level)
- Use Case: Allows users from one forest to access resources in another forest.
Example:
- lab.com is the root domain of Forest A, and test.com is the root domain of Forest B. A two-way forest trust is created:
- lab.com ↔ test.com
- This allows users from both forests to access shared resources, but transitivity is only valid within each forest and must be explicitly allowed.
Security Option: You can enable Selective Authentication to restrict which users from test.com can access resources in lab.com.
5. Realm Trust
- Scope: Between an AD domain and a non-Windows Kerberos realm
- Creation: Manual
- Direction: One-way or Two-way
- Transitivity: Can be transitive or non-transitive
- Use Case: Enables authentication between Windows AD and non-Windows systems (e.g., Linux).
Example:
- If lab.com has some Linux servers using MIT Kerberos for authentication and you want Windows users to access those systems:
- lab.com ↔ UNIX-REALM.ORG
- This trust allows secure Kerberos-based authentication between Windows AD and non-Windows (Linux) systems.
Summary of Trust Types
| Trust Type | Scope | Transitive | Direction | Example |
| Parent-Child | Same forest | Yes | Two-way | lab.com ↔ sales.lab.com |
| Tree-Root | Same forest | Yes | Two-way | lab.com ↔ dev.test.local |
| External | Different forests | No | One/Two-way | lab.com ↔ legacy.test.com |
| Forest | Different forests | Yes (root only) | One/Two-way | lab.com ↔ test.com |
| Realm | AD ↔ Kerberos realm | Yes/No | One/Two-way | lab.com ↔ UNIX-REALM.ORG |
Additional Trust Types
- Shortcut Trust:
- A shortcut trust is manually created within a forest between two domains to improve authentication performance. It is transitive.
- Cross-Link Trust:
- A cross-link trust is a specific type of shortcut trust between domains in different trees but within the same forest. This is not always listed separately.
Trust Configuration Options
While the above are the primary trust types, there are important configurations to consider when establishing any AD trust:
- Transitive vs. Non-Transitive: Determines whether the trust extends to other domains in the trust chain.
- One-Way vs. Two-Way: Defines which domain trusts the other.
- Selective Authentication: Provides fine-grained access control for trust relationships.
- SID Filtering: Helps prevent security risks by blocking potentially dangerous SID filtering.
- Federated Trusts (e.g., Azure AD): Hybrid environments may use federated trusts that differ from traditional AD trusts but are important for cloud integration.
Establishing a Two-Way Forest Trust Between Lab.com and test.com
| Forest | Root Domain | Purpose |
| Forest A | lab.com | Resource Domain |
| Forest B | test.com | User Domain (or vice versa) |
Goal: Create a two-way forest trust so users in one forest can access resources in the other.
Requirements Checklist
- Functional Levels: Both forests must be at Windows Server 2003 Forest Functional Level or higher.
- Verify with PowerShell:
Get-ADForest | Select-Object ForestMode - DNS Name Resolution: Both forests must resolve the FQDN of the other.
- Use Conditional Forwarders, Secondary DNS Zones, or Hosts files (for test environments).
- Network Connectivity: Ensure that Domain Controllers can communicate using necessary ports (Kerberos, LDAP, SMB, etc.).
- Administrative Privileges: Ensure you have Domain Admin or Enterprise Admin credentials in both forests.
Network Connectivity
- Domain Controllers must be able to talk to each other on:
- TCP/UDP 53 (DNS)
- TCP 88 (Kerberos)
- TCP 389/UDP 389 (LDAP)
- TCP 445 (SMB)
- TCP 135 (RPC Endpoint Mapper)
- Dynamic RPC Ports (TCP 49152–65535 by default)
Steps to create the Forest trust between lab.com and test.com
Conclusion
Creating a trusted relationship (Forest Trust) between two separate companies or systems like lab.com and test.com helps them work together easily and share important resources (like files, services, etc.). When this relationship is properly set up, people can safely and reliably access one system from the other.