How to Configure a Forest Trust in Active Directory on Windows Server 2012 R2

A forest trust is a transitive trust between two Active Directory forests that enables seamless authentication and resource access across forest boundaries. Unlike external trusts (which connect individual domains), a forest trust extends to all domains in both forests, allowing any user in Forest A to potentially access resources in any domain in Forest B, subject to normal access control. Forest trusts are commonly used after mergers and acquisitions, in partner organisation scenarios, or in organisations that maintain separate production and development forests. This guide covers the complete forest trust configuration process on Windows Server 2012 R2, including DNS preparation, trust creation, and security hardening.

Prerequisites

Forest trusts require the following conditions to be met:

Both forests must have a forest functional level of Windows Server 2003 or higher. Enterprise Admin credentials are needed for both forests. Network connectivity must exist between the forest root domain controllers on ports 88 (Kerberos), 389 (LDAP), 3268 (Global Catalog), 135 and 49152-65535 (RPC), and 445 (SMB). DNS must be configured so each forest root domain can resolve names in the other forest. Only one forest trust can exist between any two forests.

Import-Module ActiveDirectory

# Verify forest functional level in your forest
(Get-ADForest).ForestMode

# Verify forest functional level in partner forest
Get-ADForest -Identity "partner.com" -Server "DC-PARTNER-01.partner.com" |
    Select-Object Name, ForestMode

Step 1 — Configure DNS Between Forests

DNS name resolution between forests must work in both directions before the trust can be established. Conditional forwarders are the recommended approach:

# In Contoso forest — add forwarder for partner.com domain
Add-DnsServerConditionalForwarderZone `
    -Name "partner.com" `
    -MasterServers @("10.50.0.10","10.50.0.11") `
    -ReplicationScope Forest `
    -PassThru

# Verify resolution of partner forest root domain
Resolve-DnsName "partner.com" -Type NS
Resolve-DnsName "DC-PARTNER-01.partner.com" -Type A

# Also add forwarder for child domains if they exist
Add-DnsServerConditionalForwarderZone `
    -Name "emea.partner.com" `
    -MasterServers @("10.50.10.10") `
    -ReplicationScope Forest

Perform the equivalent configuration in the partner forest, adding conditional forwarders pointing to contoso.com DNS servers.

Step 2 — Test Network Connectivity

# Test required port connectivity from Contoso DC to Partner DC
$targetDC = "DC-PARTNER-01.partner.com"
$ports = @(88, 389, 445, 3268, 135)
foreach ($port in $ports) {
    $result = Test-NetConnection -ComputerName $targetDC -Port $port
    Write-Host "Port $port : $($result.TcpTestSucceeded)"
}

Step 3 — Create the Forest Trust

Forest trusts must be created from the forest root domain in each forest. The trust can be created from either side first, then confirmed from the other side. Using the New-ADTrust cmdlet or the Active Directory Domains and Trusts console:

# Create the forest trust from Contoso's side
# This creates an inbound trust (partner users can access Contoso resources)
$partnerCredential = Get-Credential "partnerAdministrator"

New-ADTrust `
    -Name "partner.com" `
    -TrustType Forest `
    -Direction Bidirectional `
    -Source "DC=contoso,DC=com" `
    -Target "DC=partner,DC=com" `
    -Credential $partnerCredential `
    -SelectiveAuthentication $false

Alternatively, use the Active Directory Domains and Trusts MMC. Right-click the forest root domain, select Properties, click the Trusts tab, and click New Trust. The New Trust Wizard guides you through the forest trust creation and allows you to create both sides simultaneously if you have credentials for both forests.

Step 4 — Verify the Trust

# Verify trust from Contoso side
Get-ADTrust -Filter * | Where-Object {$_.Name -eq "partner.com"} |
    Select-Object Name, TrustType, TrustDirection, IsTransitive, ForestTransitive

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

# Test the trust (validate from both sides)
netdom verify partner.com /domain:contoso.com `
    /userd:contosoAdministrator /passwordd:* /verbose

# Verify secure channel
nltest /server:DC-LON-01 /sc_query:partner.com

Step 5 — Configure SID Filtering

Forest trusts have SID filtering disabled by default — users from the trusted forest can use SID History to obtain access in the trusting forest. For security, evaluate whether to enable SID filtering (forest quarantine). If the partner forest is external and not under your control, enabling SID filtering is strongly recommended:

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

# Enable forest-aware SID filtering
# This allows cross-forest group claims but blocks SID History
netdom trust contoso.com /domain:partner.com /enablesidhistory:No `
    /userd:contosoAdministrator /passwordd:*

# Enable full quarantine (blocks all SID History)
Set-ADTrust -Identity "partner.com" -SIDFilteringEnabled $true

Step 6 — Configure Authentication Scope

By default, forest trusts allow forest-wide authentication, meaning partner users can authenticate to any server in the trusting forest. For tighter control, enable selective authentication:

# Enable selective authentication
Set-ADTrust -Identity "partner.com" -SelectiveAuthentication $true

# Grant partner users permission to authenticate on specific servers
# On each target server's computer object in AD, grant "Allowed to Authenticate"
$targetServer = Get-ADComputer -Identity "FileServer01"
$partnerGroup = "S-1-5-21-PARTNERFOREST-GROUPSID"  # Replace with actual SID

# Use dsacls to grant permission
dsacls $targetServer.DistinguishedName /G "PARTNERPartnerUsers:CA;Allowed to Authenticate;computer"

Step 7 — Configure Suffix Routing

Suffix routing controls which UPN suffixes and SPNs from the trusted forest are honoured when routing Kerberos service ticket requests. Review and configure suffix routing to prevent namespace conflicts:

# View current name suffix routing
Get-ADTrust -Identity "partner.com" -Properties TLNExclusions, TLNInclusions |
    Select-Object Name, TLNExclusions, TLNInclusions

# Exclude a specific suffix from routing (if it conflicts with your namespace)
Set-ADTrust -Identity "partner.com" `
    -Add @{TLNExclusions = "conflicting.com"}

In the Active Directory Domains and Trusts console, right-click the trust and select Properties > Name Suffix Routing to view and manage suffix routing entries. Suffixes that conflict with your forest namespace should be excluded.

Granting Resource Access Across the Trust

# Add partner domain group to a local resource group
Add-ADGroupMember -Identity "FileShare-Finance-ReadOnly" `
    -Members "partnerPartnerFinanceTeam"

# Or directly in file share ACL via PowerShell
$acl = Get-Acl "D:FinanceShare"
$rule = New-Object System.Security.AccessControl.FileSystemAccessRule(
    "PARTNERPartnerFinanceTeam", "Read", "ContainerInherit,ObjectInherit",
    "None", "Allow"
)
$acl.AddAccessRule($rule)
Set-Acl "D:FinanceShare" $acl

Monitoring and Auditing the Forest Trust

# Monitor cross-forest authentication events
Get-WinEvent -LogName Security -FilterHashtable @{
    Id = @(4768, 4769)
    StartTime = (Get-Date).AddDays(-1)
} | Where-Object {$_.Message -like "*partner*"} |
    Select-Object TimeCreated, Id, Message | Format-List

Summary

Forest trusts on Windows Server 2012 R2 provide the most comprehensive inter-organisation access solution in Active Directory, extending transitive authentication across all domains in both forests. Successful configuration depends on proper DNS forwarder setup, verified network connectivity on all required ports, and careful security configuration including SID filtering and selective authentication. Always enable SID filtering for forest trusts involving external organisations. Selective authentication provides granular control over which specific servers in your forest are accessible to users from the trusted forest. Regular auditing of cross-forest authentication events ensures the trust is being used as intended and not being abused.