Active Directory Trusts

Link to What Are Active Directory Trusts?What Are Active Directory Trusts?

Active Directory (AD) trusts are secure, logical relationships established between two domains or forests within Microsoft Active Directory environments. The fundamental purpose of a trust is to enable users in one administrative boundary to access resources in another, without duplicating user accounts or consolidating directories. Trusts define how authentication and authorization requests traverse domain or forest boundaries, making them essential for organizations with multi-domain or multi-forest architectures.

Consider a scenario where a company operates two separate AD forests after an acquisition. To allow a group in one forest to print to a shared printer hosted in the other, some mechanism must allow cross-forest authentication. This is where AD trusts come into play—they grant the necessary ability for credentials and authorization decisions to flow between otherwise isolated environments.

Link to Trust Directionality: One-Way vs Two-Way TrustsTrust Directionality: One-Way vs Two-Way Trusts

Directionality specifies the flow of authentication between two domains. Understanding trust direction is essential for defining which users can access which resources.

• One-Way Trust: In a one-way trust, Domain A trusts Domain B. This means users from Domain B can access resources in Domain A (if allowed by permissions), but the reverse is not true—Domain A’s users cannot access Domain B’s resources through this trust. For example, in a one-way trust from DomainA to DomainB, only users from DomainB may be authenticated to resources in DomainA.

• Two-Way Trust: Here, both domains trust each other equally. Users from either domain may be authenticated to resources in the other. Effectively, a two-way trust is the combination of two one-way trusts in opposite directions.

The direction has significant security and access implications. Carelessly assuming a one-way trust allows access both ways is a common misconfiguration that can lead to failed integrations or openings for lateral movement by attackers.

Link to Transitivity: Does Trust Extend Beyond Two Domains?Transitivity: Does Trust Extend Beyond Two Domains?

Transitivity defines whether a trust relationship is confined strictly to the two directly connected domains or if it extends indirectly through a chain of trusts.

• Transitive Trust: If DomainA trusts DomainB, and DomainB trusts DomainC, then DomainA automatically trusts DomainC. This propagation enables simplified resource sharing and authentication across multiple domains within a forest or between forests that have appropriate transitive trusts.

• Non-Transitive Trust: The trust link exists solely between the two specified domains. There is no implicit extension; if access is needed to further domains, additional trusts must be configured explicitly.

Transitivity is critical in large organizations. Within a single AD forest, all domains are linked by default two-way transitive trusts, allowing seamless cross-domain authentication and resource access (subject to permissions), but when connecting distinct forests or external domains, the trust's transitivity must be considered to ensure the correct level of access.

Link to Types of Active Directory TrustsTypes of Active Directory Trusts

Active Directory supports several distinct trust types, each with specific behaviors in terms of directionality, transitivity, and security boundaries.

• Parent-Child and Tree-Root Trusts are automatically created when domains are added within a forest. They are always two-way, transitive trusts.
• Forest Trusts are manually established between separate forests and are transitive across all domains in both forests.
• External Trusts are used when connecting to domains outside the forest—for legacy, migration, or organizational reasons. These are non-transitive by design.
• Shortcut Trusts are manually created to bypass the default trust path between distant domains in the same forest, optimizing authentication latency.
• Realm Trusts connect AD domains to Kerberos v5 realms in non-AD (such as UNIX) environments and can be configured for transitivity.

Link to Behind the Scenes: Authentication Flow and Trust PathBehind the Scenes: Authentication Flow and Trust Path

When a user tries to access a resource across domain boundaries, AD must determine how (and if) authentication should proceed. This is managed via the 'trust path.' Here’s how it works at a high level:

1. Trust Path Discovery: When a request arrives (e.g., access to a file share in DomainA by a user from DomainB), the domain controller hosting the resource computes a trust path to the user’s domain. It follows the chain of direct and transitive trusts configured.

2. Net Logon Secure Channel: The Net Logon service establishes a secure channel to the target domain’s controller, passing authentication requests and responses securely.

3. Credential Validation and Authorization: Credentials are validated through this path. Resource access is only granted if the trust allows authentication, and the user or group is explicitly permitted by resource ACLs.

For example, in a forest trust between ForestA and ForestB, a user from any domain in ForestB can access resources in ForestA (and vice versa, in a two-way trust), as long as permissions grant access and network prerequisites (DNS routing, name resolution, etc.) are satisfied.

Link to Security Considerations: Risks, Best Practices, and Selective AuthenticationSecurity Considerations: Risks, Best Practices, and Selective Authentication

While trusts are necessary for cross-boundary collaboration, misconfigured or excessively permissive trusts can dramatically increase lateral movement risk and expand the attack surface.

• Overly Broad Trusts: Establishing a forest or two-way trust exposes all domains to each other, which may be inappropriate between semi-autonomous business units or partners.

• Non-Transitive/External Trusts and Legacy Systems: External trusts are often required for legacy or non-AD domains but do not propagate, reducing the risk of unintended access propagation.

• Selective Authentication: To mitigate risk, especially in forest or external trusts, AD supports selective authentication. When enabled, only explicitly granted users or groups from the trusted domain are able to authenticate to machines in the trusting domain, regardless of trust direction. This sharply limits exposure even when a broad trust exists.

Operators should always favor least-privilege design: use transitive trusts only where necessary, consider one-way trusts for restricting directionality, and leverage selective authentication for granular control.

Link to Common Misconceptions About Active Directory TrustsCommon Misconceptions About Active Directory Trusts

• One-way trust is not bidirectional: Resource access only works from the trusted to the trusting domain, not both ways.
• Transitivity does not override permissions: Trust extends the authentication boundary, but access still requires explicit permission.
• Not all trusts are manual: Many intra-forest trusts (parent-child, tree-root) are automatic.
• Trusts impact service access as well as user logins: Service accounts are subject to the same trust and authentication flow as interactive users.
• Trust enables authentication, not authorization: Permissions (on resources like file shares) must also be granted for access to succeed.

Misunderstanding these facets can lead to failed integrations, excessive exposure, or unexpected access controls.

Link to Troubleshooting and Practical ConsiderationsTroubleshooting and Practical Considerations

Several practical points surface when managing or diagnosing trust relationships:

• Prerequisites for Trust Functionality: DNS name resolution, network reachability, and closely synchronized clocks (Kerberos is time-sensitive) are mandatory for working trust paths.
• Common Issues: Trust setup often fails due to DNS misconfiguration, firewall rules blocking required ports, or time synchronization problems.
• Evidence Gathering: Troubleshooting broken trusts involves verifying connectivity, validating trust existence (using AD tools), and checking security logs for failed logons or trust channel breakdowns.

Admins should always collect logs from both sides of the trust, review event viewer errors, and confirm network and DNS health before attempting to recreate trust objects.

Link to Summary Table: Trust Types at a GlanceSummary Table: Trust Types at a Glance

Sources

• Microsoft Learn: How trust relationships work for forests in Active Directory

Link to SourcesSources

• learn.microsoft.com — concepts-forest-trust