How to Configure Domain Trusts in Active Directory on Windows Server 2012 R2

Active Directory domain trusts establish security relationships between domains, enabling users in one domain to access resources in another. Trusts are fundamental to multi-domain and multi-forest Active Directory environments, mergers and acquisitions, and partner organisation access scenarios. Windows Server 2012 R2 supports several trust types including parent-child trusts (created automatically within a forest), tree-root trusts (between forest roots), external trusts (between domains in different forests), forest trusts (between entire forests), realm trusts (for non-Windows Kerberos realms), and shortcut trusts (to reduce authentication paths). This guide covers configuring domain trusts on Windows Server 2012 R2.

Prerequisites

Creating trusts requires membership in the Domain Admins group of both domains involved in the trust (or Enterprise Admins for forest-wide trusts). Network connectivity must exist between domain controllers in both domains on the required ports: TCP/UDP 88 (Kerberos), TCP/UDP 135 (RPC Endpoint Mapper), TCP 389 (LDAP), TCP/UDP 445 (SMB), TCP 3268 (GC), and dynamic RPC ports (49152-65535). DNS must be configured to resolve names in both domains. The ActiveDirectory module must be available.

Import-Module ActiveDirectory

# Verify network connectivity to the partner domain controller
Test-NetConnection -ComputerName "DC-PARTNER-01.partner.com" -Port 389
Test-NetConnection -ComputerName "DC-PARTNER-01.partner.com" -Port 88

Understanding Trust Direction and Transitivity

Trust direction is confusing for many administrators. A trust is described from the trusting domain’s perspective: if Domain A trusts Domain B, then users in Domain B can access resources in Domain A. Domain A is the trusting domain; Domain B is the trusted domain. A one-way trust allows access in only one direction. A two-way trust (bidirectional) allows access in both directions and consists of two one-way trusts. Transitive trusts extend trust relationships automatically — if A trusts B and B trusts C, then A implicitly trusts C. Forest trusts are transitive within the forests but not outside them. External trusts are non-transitive.

Configuring DNS for Trust Resolution

Before creating the trust, configure DNS so each domain can resolve the other’s names. Options include conditional forwarders, stub zones, or secondary zones:

# Add a conditional forwarder for the partner domain
Add-DnsServerConditionalForwarderZone `
    -Name "partner.com" `
    -MasterServers "192.168.50.10","192.168.50.11" `
    -ReplicationScope Domain `
    -PassThru

# Verify resolution
Resolve-DnsName "DC-PARTNER-01.partner.com" -Type A
Resolve-DnsName "partner.com" -Type SOA

Creating an External Trust via PowerShell

An external trust connects a domain in your forest to a domain in a different forest. It is non-transitive and can be one-way or two-way:

# Create a one-way external trust
# (Contoso trusts Partner — Partner users can access Contoso resources)
$trustCredential = Get-Credential "partnerAdministrator"

New-ADTrust `
    -Name "partner.com" `
    -TrustType External `
    -Direction Inbound `
    -TrustingDomain "contoso.com" `
    -TrustedDomain "partner.com" `
    -Source "DC=contoso,DC=com" `
    -Target "DC=partner,DC=com" `
    -Credential $trustCredential
# Create a two-way external trust
New-ADTrust `
    -Name "partner.com" `
    -TrustType External `
    -Direction Bidirectional `
    -Source "DC=contoso,DC=com" `
    -Target "DC=partner,DC=com" `
    -Credential (Get-Credential "partnerAdministrator")

Creating a Shortcut Trust

Within a large forest with multiple domains, authentication can require traversing multiple trust relationships to find a common ancestor domain. Shortcut trusts create a direct trust between two child domains, reducing authentication latency. Shortcut trusts are transitive:

# Create a shortcut trust between two child domains in the same forest
New-ADTrust `
    -Name "emea.contoso.com" `
    -TrustType Cross-link `
    -Direction Bidirectional `
    -Source "DC=americas,DC=contoso,DC=com" `
    -Target "DC=emea,DC=contoso,DC=com"

Verifying Trust Configuration

# List all trusts configured for a domain
Get-ADTrust -Filter * | Select-Object Name, TrustType, TrustDirection, IntraForest, IsTransitive

# Verify trust using netdom
netdom query trust /domain:contoso.com

# Test trust authentication
nltest /server:DC-LON-01 /sc_query:partner.com

# Verify trust from both sides
netdom verify partner.com /domain:contoso.com /userd:contosoAdministrator /passwordd:*

Configuring SID Filtering

SID filtering (also called Quarantine mode) prevents users in a trusted domain from using SID History to gain elevated access in the trusting domain. It is enabled by default for external trusts and disabled for forest trusts. SID filtering is a critical security control that should be enabled unless you specifically need SID History to work across the trust (e.g., during a migration):

# Check SID filtering status
Get-ADTrust -Identity "partner.com" | Select-Object Name, SIDFilteringEnabled

# Enable SID filtering on an existing trust
Set-ADTrust -Identity "partner.com" -SIDFilteringEnabled $true

# Disable SID filtering (migration scenario only)
netdom trust contoso.com /domain:partner.com /quarantine:No /userd:contosoAdministrator /passwordd:*

Configuring Selective Authentication

Selective authentication restricts which resources in the trusting domain can be accessed by users from the trusted domain. With forest-wide authentication (the default), users from the trusted domain can attempt to authenticate to any resource in the trusting domain, subject to normal access controls. With selective authentication, users can only access resources on servers that have been explicitly granted the “Allowed to authenticate” permission for those users:

# Enable selective authentication on a trust
netdom trust contoso.com /domain:partner.com /SelectiveAuth:Yes `
    /userd:contosoAdministrator /passwordd:*

# Grant a user from the trusted domain permission to authenticate to a specific server
# On the target server's computer account in AD, grant the trusted user the
# "Allowed to Authenticate" extended right
$computerAccount = Get-ADComputer -Identity "FileServer01"
$partnerUser = New-Object System.Security.Principal.NTAccount("PARTNER","SalesUser")
$sid = $partnerUser.Translate([System.Security.Principal.SecurityIdentifier])

$acl = Get-Acl "AD:$($computerAccount.DistinguishedName)"
$rule = New-Object System.DirectoryServices.ActiveDirectoryAccessRule(
    $sid,
    [System.DirectoryServices.ActiveDirectoryRights]::ExtendedRight,
    [System.Security.AccessControl.AccessControlType]::Allow,
    [GUID]"68B1D179-0D15-4D4F-AB71-46152E79A7BC"  # Allowed to Authenticate
)
$acl.AddAccessRule($rule)
Set-Acl "AD:$($computerAccount.DistinguishedName)" $acl

Removing a Trust

# Remove a trust (must be done from both sides for a two-way trust)
Remove-ADTrust -Identity "partner.com" -Confirm:$false

# Use netdom for removal from partner domain side
netdom trust contoso.com /domain:partner.com /remove `
    /userd:partnerAdministrator /passwordd:*

Summary

Domain trusts in Active Directory on Windows Server 2012 R2 provide the mechanism for cross-domain and cross-forest resource access. Successful trust configuration requires DNS resolution between domains, network connectivity on required ports, and administrative credentials in both domains. Security considerations include keeping SID filtering enabled to prevent SID History abuse, using selective authentication for fine-grained control over which resources are accessible, and regularly auditing trust usage. Shortcut trusts within a forest can significantly reduce authentication latency in large multi-domain forests, improving logon performance for users who frequently access resources across domain boundaries.