Introduction to Active Directory Trust Relationships

Active Directory trust relationships allow users in one domain or forest to access resources in another domain or forest. Trusts are directional—a trust between Domain A and Domain B means users in Domain A can authenticate to Domain B (or vice versa, depending on direction). Windows Server 2019 supports several trust types: forest trusts, external trusts, realm trusts, and shortcut trusts. Proper trust configuration enables collaboration between separate AD environments while maintaining security boundaries. This tutorial covers creating, managing, and securing each trust type.

Trust Terminology

Understanding trust direction is essential. A one-way trust between two domains has a trusting domain (which contains the resources) and a trusted domain (which contains the accounts). Users from the trusted domain can access resources in the trusting domain. A two-way trust is bidirectional—both domains trust each other. Transitive trusts extend automatically through a chain—if A trusts B and B trusts C, then A trusts C. Non-transitive trusts do not extend.

Trust Types Overview

Forest trusts are transitive and connect two forest root domains, providing access between all domains in both forests. External trusts are non-transitive and connect to a domain in a different forest or a Windows NT 4.0 domain. Realm trusts connect an AD domain to a non-Windows Kerberos realm such as a Linux MIT Kerberos domain. Shortcut trusts optimize authentication paths between domains in the same forest when the tree path is long, reducing authentication latency.

Creating a Forest Trust

Forest trusts require both forests to be at forest functional level Windows Server 2003 or higher. DNS must be configured so both forests can resolve each other’s names. Create the trust using the Active Directory Domains and Trusts console or PowerShell. Both sides of the trust must be created—you can create both sides in one operation if you have admin credentials for both forests.

netdom trust yourdomain.com /domain:partnerdomain.com `
    /add /twoway `
    /UserD:administrator /PasswordD:* `
    /UserO:administrator /PasswordO:*

Using Active Directory Domains and Trusts GUI (domain.msc): right-click your domain, select Properties, Trusts tab, click New Trust, and follow the wizard. Specify the partner forest’s DNS name, select Forest Trust type, choose two-way direction, and provide credentials for both sides.

domain.msc

Creating an External Trust with PowerShell

Use the New-ADTrust cmdlet to create trust relationships from PowerShell. An external trust to a domain in another forest (non-transitive) is created as follows. The -TrustType External parameter creates a non-transitive external trust.

$trustCredential = Get-Credential -Message "Credentials for partner domain"
Add-ADTrust `
    -Name "partnerdomain.com" `
    -TrustDirection Bidirectional `
    -TrustType External `
    -Source "yourdomain.com" `
    -Credential $trustCredential

Configuring Selective Authentication

By default, a forest trust allows any user in the trusted forest to attempt authentication against resources in the trusting forest (subject to NTFS and share permissions). Selective Authentication restricts this so only explicitly permitted users can authenticate across the trust. This provides much tighter control over cross-forest resource access.

Enable selective authentication on a trust using netdom or by modifying trust properties in Active Directory Domains and Trusts. After enabling, you must grant the “Allowed to Authenticate” permission on each resource server to the specific users or groups from the trusted domain who should have access.

netdom trust yourdomain.com /domain:partnerdomain.com `
    /SelectiveAuth:yes

Then grant the “Allowed to Authenticate” right on a resource server:

dsacls "CN=FILESERVER01,OU=Computers,DC=yourdomain,DC=com" `
    /G "PARTNERDOMAINPartnerUsers:CA;Allowed to Authenticate"

Verifying a Trust

After creating a trust, verify it works correctly. The netdom trust command with /verify checks that the secure channel between the domains is functioning.

netdom trust yourdomain.com /domain:partnerdomain.com /verify

Use Get-ADTrust to view all trusts configured on the domain:

Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection, IsTransitive

Enabling SID Filtering

SID Filtering (also called SID History Quarantine) prevents users in a trusted domain from using SID History to gain elevated privileges in the trusting domain. SID Filtering is enabled by default on external trusts but disabled by default on forest trusts. For forest trusts with untrusted organizations, enable SID Filtering.

netdom trust yourdomain.com /domain:partnerdomain.com `
    /quarantine:yes

View current SID filtering status:

netdom trust yourdomain.com /domain:partnerdomain.com /quarantine

Creating a Shortcut Trust

In a large forest with many domains, the Kerberos authentication path follows the domain tree hierarchy. Users in a child domain accessing resources in another child domain in a different tree traverse up to the forest root and back down, creating latency. A shortcut trust creates a direct trust between two domains in the same forest, bypassing the tree path.

netdom trust childA.yourdomain.com `
    /domain:childB.partnerforest.com `
    /add /twoway /type:shortcut

Removing a Trust

Remove a trust when the business relationship ends. Both sides of the trust should be removed. Remove the trust from your domain first, then from the partner domain.

netdom trust yourdomain.com /domain:partnerdomain.com `
    /remove /twoway `
    /UserD:administrator /PasswordD:*

Troubleshooting Trust Issues

Common trust problems include DNS resolution failures between forests, time skew (Kerberos requires clocks within 5 minutes), firewall blocking required ports, and secure channel failures. Use these diagnostic commands:

# Check DNS resolution
Resolve-DnsName partnerdomain.com -Type SOA
Resolve-DnsName _kerberos._tcp.partnerdomain.com -Type SRV

# Check time synchronization
w32tm /monitor /computers:DC01.partnerdomain.com

# Test the trust secure channel
Test-ComputerSecureChannel -Server DC01.yourdomain.com

# Netlogon test
nltest /sc_verify:partnerdomain.com

Required Firewall Ports for Trusts

Forest and external trusts require specific ports to be open between forests. These include TCP/UDP 88 (Kerberos), TCP/UDP 135 (RPC Endpoint Mapper), TCP/UDP 389 (LDAP), TCP 636 (LDAPS), TCP/UDP 445 (SMB/CIFS), TCP/UDP 464 (Kerberos password change), TCP 49152-65535 (RPC dynamic ports), and TCP/UDP 53 (DNS). Configure these ports in your perimeter firewall if the trusting and trusted domains communicate across network segments.

netsh advfirewall firewall add rule name="AD Trust Kerberos TCP" `
    protocol=TCP localport=88 dir=in action=allow

netsh advfirewall firewall add rule name="AD Trust LDAP TCP" `
    protocol=TCP localport=389 dir=in action=allow

Conclusion

Active Directory trust relationships enable resource sharing across organizational boundaries while maintaining separate administrative domains. Windows Server 2019 provides robust trust management through the GUI, netdom, and PowerShell. Always use Selective Authentication for external organizations to limit exposure, enable SID Filtering for untrusted forests, and verify trusts after creation and periodically during operation. Document all trust relationships, their purpose, expiration dates (if applicable), and contact information for the partner organization’s administrators.