Lesson: Understanding Active Directory Domain Services (AD DS) Trust Types

Introduction: Why Trust Matters in Active Directory

In the landscape of enterprise identity management, Active Directory Domain Services (AD DS) serves as the backbone for authentication and authorization. As organizations grow, merge, or restructure, they often find themselves managing multiple domain environments. To allow users in one domain to access resources in another, administrators must establish a formal relationship known as a "Trust." Without these trust relationships, users would be forced to maintain separate credentials for every individual domain they need to access, leading to administrative nightmares and significant security gaps.

Understanding AD DS trust types is not just a technical requirement for passing certification exams; it is a fundamental skill for managing secure and functional corporate networks. A well-designed trust architecture allows for the central management of identities while providing the flexibility required for business operations. Conversely, a poorly configured trust relationship can lead to security vulnerabilities, such as privilege escalation or unauthorized access to sensitive data across domain boundaries.

In this lesson, we will explore the various types of trusts available in AD DS, the mechanics of how they function, and the scenarios where each type is most appropriate. By the end of this module, you will be able to architect, implement, and troubleshoot trust relationships with confidence, ensuring that your organization’s identity infrastructure remains both secure and efficient.

The Core Concept: How Trusts Work

At its simplest level, a trust relationship is a logical link between two domains. When Domain A trusts Domain B, it means that Domain A recognizes the authentication requests coming from Domain B. If a user in Domain B attempts to log in to a workstation in Domain A, the domain controller in Domain A will communicate with the domain controller in Domain B to verify the user’s identity.

This verification process relies on the Kerberos authentication protocol. When a user logs in, they receive a Ticket Granting Ticket (TGT). If that user tries to access a resource in a trusted domain, the TGT is used to request a referral ticket from the local domain controller, which then points the user to the trusted domain’s Key Distribution Center (KDC). This mechanism ensures that authentication remains secure without requiring the user to send their password across the network to the resource domain.

Callout: Trust Directionality It is vital to understand the concept of directionality. A trust can be one-way or two-way. In a one-way trust, Domain A trusts Domain B, meaning users from B can access resources in A, but users from A cannot access resources in B. In a two-way trust, both domains trust each other, allowing for bidirectional resource access. Directionality is the most common point of confusion for new administrators, so always visualize the "flow" of trust as the flow of authentication requests.

Categorizing AD DS Trust Types

Active Directory provides several distinct types of trusts, each designed to solve specific organizational challenges. Understanding these categories is essential for choosing the right tool for the job.

1. Parent-Child Trusts

This is the most common type of trust, created automatically when you add a new child domain to an existing domain tree. These trusts are transitive, meaning that if Domain A trusts Domain B, and Domain B trusts Domain C, then Domain A automatically trusts Domain C. These trusts are always two-way and exist by default within a forest.

2. Tree-Root Trusts

When you add a new domain tree to an existing forest, a tree-root trust is created between the new tree root and the forest root. Like parent-child trusts, these are transitive, two-way trusts that allow for seamless authentication across the entire forest structure.

3. External Trusts

External trusts are used to connect two domains that reside in different forests. Unlike the previous types, external trusts are non-transitive. This means that if Domain A (Forest 1) trusts Domain B (Forest 2), that trust does not extend to any other domains within Forest 2. You must manually create individual external trusts for every domain in the external forest that requires access.

4. Forest Trusts

Forest trusts are the preferred method for connecting two separate Active Directory forests. They are transitive at the forest level, meaning that if you create a forest trust between Forest A and Forest B, all domains in Forest A will trust all domains in Forest B. This significantly reduces the administrative burden compared to managing multiple individual external trusts.

5. Shortcut Trusts

Shortcut trusts are specifically designed to improve performance. In a large forest with a deep hierarchy, authentication requests may have to travel up the tree to the root and back down to the target domain. A shortcut trust creates a direct "shortcut" between two domains in the same forest that are not parent-child, reducing the number of hops required for authentication.

6. Realm Trusts

Realm trusts are used to connect an AD DS forest to a non-Windows environment, such as a Kerberos version 5 realm (e.g., MIT Kerberos or an LDAP-based identity provider). These are essential for organizations that operate in heterogeneous environments where Windows and Linux/Unix systems must coexist and share authentication.

Comparison Table: Trust Types at a Glance

Implementing Trusts: Step-by-Step

Implementing a trust requires administrative access to both domains (or the appropriate permissions to modify domain objects). While the GUI (Active Directory Domains and Trusts) is the most common method, PowerShell is increasingly the industry standard for consistency and automation.

Scenario: Creating a Forest Trust using PowerShell

Before creating a forest trust, ensure that DNS name resolution is working perfectly between the two forests. You must have a conditional forwarder or a stub zone configured in each forest so that the domain controllers can resolve the names of the domain controllers in the other forest.

1. Verify DNS: From a domain controller, attempt to ping the FQDN of a domain controller in the target forest.
2. Open PowerShell as Administrator.
3. Execute the Trust Creation Command:

# Establish a forest trust between ForestA.local and ForestB.local
New-ADTrust -Name "ForestB.local" `
            -SourceForest "ForestA.local" `
            -TargetForest "ForestB.local" `
            -Direction Bidirectional `
            -TrustType Forest `
            -AccessCredential (Get-Credential)

Explanation of the command:

• -Name: The DNS name of the target forest.
• -Direction Bidirectional: Sets the trust to be two-way.
• -TrustType Forest: Specifies that this is a forest-level trust.
• -AccessCredential: Prompts for credentials with administrative rights in the target forest to ensure the trust is created on both sides simultaneously.

Warning: The DNS Prerequisite The most frequent cause of trust creation failure is not a lack of administrative privilege, but a failure in DNS resolution. If your domain controllers cannot resolve the SRV records of the remote domain, the trust creation will fail. Always verify that your DNS forwarders are correctly pointing to the other side’s DNS servers before attempting to create the trust.

Managing Trust Attributes: Selective vs. Forest-Wide Authentication

Once a trust is established, you must decide how authentication is handled. By default, "Forest-wide authentication" is often selected, meaning any user from the trusted domain can authenticate to any resource in the trusting domain. While convenient, this is a security risk in many environments.

Selective Authentication

Selective authentication allows you to restrict which users from the trusted domain can authenticate to specific servers in the trusting domain. You do this by granting the "Allowed to authenticate" permission on the computer objects (servers) in the trusting domain to specific users or groups from the trusted domain.

SID Filtering and Quarantine

When you create a trust between forests, AD DS automatically enables SID filtering. This is a security feature that prevents users in the trusted forest from injecting malicious Security Identifiers (SIDs) into their authentication tokens. If you are merging two forests and you need to migrate users, you might need to disable SID filtering temporarily (using netdom trust), but this should be done with extreme caution.

Best Practices for Trust Management

Managing trusts is a balance between connectivity and security. Follow these best practices to maintain a healthy environment:

• Principle of Least Privilege: Always use the most restrictive trust type possible. If you only need to access one domain in a remote forest, use an external trust rather than a forest trust.
• Documentation: Maintain a map of your trust relationships. In a large organization, it is easy to forget why an old external trust exists. Document the purpose, the stakeholders, and the expiration (if applicable) for every trust.
• Regular Audits: Periodically review your trusts using Get-ADTrust in PowerShell. Look for trusts that are no longer in use and remove them to reduce the attack surface.
• Monitor DNS: Since DNS is the heartbeat of Active Directory, ensure that your DNS health is monitored. A failure in DNS will manifest as an "authentication issue," leading many admins to troubleshoot the trust itself when the problem is actually the name resolution.
• Use Active Directory Domains and Trusts: For complex troubleshooting, the GUI tool is invaluable because it provides a clear visual interface for verifying the state of the trust and identifying where communication is breaking down.

Callout: The "Trust Account" When you create a trust, Active Directory actually creates a special "Trust Account" (a computer object with a random password) in the domain database. These passwords are rotated automatically by the domain controllers. If you ever have a situation where a trust "breaks" for no apparent reason, it is often because the trust password synchronization has failed. You can reset this using the netdom resetpwd command, but do so only after verifying that there isn't a deeper communication issue.

Common Pitfalls and Troubleshooting

Even with careful planning, trusts can fail. Here are the most common issues administrators encounter:

1. Time Synchronization Issues

Kerberos, the protocol that powers AD DS authentication, is highly sensitive to time. If the clocks on the domain controllers of the two forests are more than five minutes apart, authentication will fail. Always ensure that your forest roots are synchronized with a reliable external NTP source.

2. Firewall Restrictions

Trusts require specific ports to be open between domain controllers. If you have a firewall between your forests, you must allow traffic on:

• TCP/UDP 88 (Kerberos)
• TCP/UDP 389 (LDAP)
• TCP/UDP 445 (SMB)
• TCP/UDP 135 (RPC)
• Ephemeral ports (often a large range, which can be restricted by configuring static RPC ports on your domain controllers).

3. Stale Trusts

Organizations often leave "legacy" trusts in place after a project or a merger is complete. These are significant security risks. If an attacker compromises a domain in a trusted forest, they can potentially use that trust to move laterally into your primary environment. If a trust is not actively being used, delete it.

4. Incorrect UPN Suffixes

If you are using custom UPN (User Principal Name) suffixes, ensure that the suffixes are registered and reachable. If a user logs in with [email protected], the domain must know how to route that request. If the trust isn't aware of the UPN suffix routing, authentication will fail.

Practical Example: Troubleshooting a Broken Trust

Imagine a scenario where users in Domain B can no longer access a file server in Domain A. The trust is still showing as "Active" in the console. How do you troubleshoot this?

1. Verify Connectivity: Run Test-NetConnection -ComputerName DC-DomainA -Port 445 from a DC in Domain B to ensure SMB traffic is flowing.
2. Check Trust Status: Run Get-ADTrust -Identity "DomainA.local". Look for any errors in the output.
3. Check the Event Logs: Look at the "System" log on your Domain Controllers. Filter for "Source: NETLOGON" and "Event ID: 5719" or "5806." These events will tell you exactly why the secure channel is failing.
4. Validate the Secure Channel: Use the command nltest /sc_verify:DomainA.local. This forces the local DC to perform a "ping" test against the remote domain's DC to verify the secure channel.

If nltest returns an error, the trust password may be out of sync. You can attempt a repair using: nltest /sc_reset:DomainA.local

Advanced Topic: SID Filtering and Security

Security is the primary reason why we have trust types. When you trust another forest, you are essentially saying "I trust the administrators of that forest to authenticate their users correctly." However, what happens if an administrator in the trusted forest is malicious?

SID Filtering is the safeguard. When a user is authenticated, their token contains their own SID and the SIDs of every group they belong to. If a user in a trusted forest tries to add a "Domain Admin" SID from your forest into their token, SID filtering will detect this mismatch and strip that SID from the token before it reaches your resources.

Note: Never disable SID filtering unless you have a very specific, well-documented reason, such as migrating objects between forests using the Active Directory Migration Tool (ADMT). If you must disable it, do so only for the duration of the migration, and enable it immediately afterward.

Integrating Non-Windows Systems: Realm Trusts

As mentioned earlier, Realm Trusts are the bridge between AD DS and other Kerberos-based systems. A common example is integrating a Linux-based web application that uses MIT Kerberos for authentication with your Active Directory forest.

To create a realm trust, you must first ensure that the Kerberos realm name (which is case-sensitive) is correctly configured in your AD environment. You will then use the New-ADTrust cmdlet with the -TrustType Realm parameter.

New-ADTrust -Name "linux-auth.corp" `
            -Direction Outbound `
            -TrustType Realm `
            -SourceForest "YourDomain.local" `
            -TargetForest "linux-auth.corp"

Once this trust is created, you must map the users in the Linux realm to the appropriate objects in AD. This often involves using "Identity Mapping" services or mapping the users to local accounts on the servers. It is a more complex setup than standard domain trusts, but it is the standard way to achieve a single-sign-on (SSO) experience in a mixed environment.

Summary of Key Takeaways

By now, you should have a solid grasp of how trusts function and how to manage them effectively. Here are the core points to remember:

1. Trusts are Logical Links: They define the path for authentication requests between domains. They are not physical connections, but they rely entirely on underlying network connectivity (specifically DNS and open firewall ports).
2. Type Matters: Always choose the simplest trust type that meets your requirements. Parent-child and tree-root trusts are for internal hierarchy; forest and external trusts are for connecting separate organizations.
3. Transitivity is Key: Understand that forest and tree-root trusts are transitive, meaning they extend the trust relationship to all domains in the forest. This is powerful but requires careful planning to avoid accidental over-provisioning of access.
4. DNS is the Foundation: You cannot have a functioning trust without perfect DNS resolution. Always verify that your domain controllers can resolve the SRV records of the remote domain before configuring the trust.
5. Security is Non-Negotiable: Use SID filtering to protect your forest from malicious token modification. Never disable security features for convenience; document every exception you make.
6. Automation and PowerShell: Move away from manual GUI configuration as soon as you are comfortable. PowerShell provides a repeatable, auditable way to manage trusts, which is critical for maintaining long-term security and consistency.
7. Maintenance: Regularly audit your trusts. An unused trust is a security vulnerability. If a business unit closes or a partner organization contract ends, remove the trust immediately.

By following these principles, you will be able to build and maintain an identity infrastructure that is not only functional but also resilient against the evolving threats in the modern digital landscape. Managing AD DS trusts is about enabling the business to collaborate while ensuring that the "keys to the kingdom" remain firmly under your control.

Frequently Asked Questions (FAQ)

Q: Can I have both a forest trust and an external trust to the same domain? A: Yes, but it is redundant and adds unnecessary complexity to your environment. If you have a forest trust, it already includes all domains in that forest. Adding an external trust to a specific domain within that forest serves no purpose and makes troubleshooting harder.

Q: What happens if I delete a trust? A: Deleting a trust immediately breaks the authentication path between the two domains. Users will no longer be able to access resources in the other domain. Before deleting a trust, always ensure that there are no active dependencies, such as shared file servers or legacy applications, relying on that relationship.

Q: Why do my trust creation attempts fail even when I have domain admin rights? A: It is almost always a DNS issue or a network connectivity issue (firewall). Use nltest and dcdiag to verify that your domain controller can "see" the remote domain controller over the necessary ports.

Q: Is there a limit to how many trusts I can have? A: While there is no hard numerical limit, every trust adds overhead to the authentication process and increases the complexity of your environment. A "hub-and-spoke" model is generally preferred over a "mesh" model to keep the number of trusts manageable.

Q: Should I use shortcut trusts to solve all my performance issues? A: No. Shortcut trusts are only for very large, complex forests. If you are experiencing performance issues, first check your network latency, DNS resolution times, and the health of your domain controllers. A shortcut trust will not fix a slow network.