Establishing trust relationships between Active Directory domains is a common task for many system administrators. Trusts allow users in one domain to access resources in another domain. However, occasionally these trust relationships can become broken or stop functioning properly. Fixing broken trust relationships is critical to restore proper access between domains.
PowerShell provides a powerful toolset for diagnosing and repairing broken domain trusts. In this guide, we will explore the key PowerShell commands and techniques for identifying and resolving common domain trust issues.
Identifying Broken Trusts
The first step is to identify any broken or failing trust relationships. We can use the Get-ADTrust PowerShell cmdlet to list all existing domain trusts and their status:
Get-ADTrust
This will display all trusts along with properties like Direction, Source, Target, TrustType, and TrustAttributes. Key things to look for are trusts with a status of Broken or SID Filtering Disabled. Broken indicates the trust relationship is not functioning, while SID Filtering Disabled means inactive SIDs could spread between domains.
For example, a failing trust might display output like this:
SourceDomain : domainA.local TargetDomain : domainB.local TrustType : External TrustAttributes : BROKEN TrustDirection : Bidirectional WhenCreated : 7/1/2019 3:45:23 PM LastModified : 7/5/2019 2:15:36 PM
The Broken status clearly indicates this trust is not working properly and needs to be fixed. SID Filtering Disabled might display like this:
SourceDomain : domainA.local TargetDomain : domainB.local TrustType : External TrustAttributes : SID_FILTERING_DISABLED TrustDirection : Bidirectional WhenCreated : 7/1/2019 3:45:23 PM LastModified : 7/5/2019 2:15:36 PM
Here we can see a risk of SID history spreading between the domains which needs to be addressed.
Verifying DNS Configuration
One common cause of broken domain trusts is invalid or missing DNS records. Trusts rely on proper DNS configuration between the source and target domains. We can check for issues by reviewing the DNS records in each domain.
On domain controllers in the source domain, verify DNS records exist for the target domain’s domain controllers. For example:
Resolve-DnsName -Name dc1.targetdomain.local
This should resolve to an IP address for that DC. Do this check for each of the target domain’s DCs.
Similarly, on DCs in the target domain verify DNS records exist for the source domain’s DCs:
Resolve-DnsName -Name dc2.sourcedomain.local
If any name fails to resolve, it indicates a problem with DNS configuration needed for the trust. DNS issues can prevent authentication and proper routing between the domains. Fix any incorrect or missing records to restore connectivity.
Checking Site Link Configuration
Site link configuration in Active Directory determines how authentication traffic flows between domain controllers (DCs) in different domains. In complex environments, broken site links can disrupt trusts even when DNS is configured properly.
To check for issues, you can view the site links with Get-ADSiteLink. For example, to check links connecting the source and target domain:
Get-ADSiteLink -Filter {Cost -ne 0} | Where {$_.SiteList -Match "SourceSite" -and $_.SiteList -Match "TargetSite"}
This will display site links between the source and target domains. Review settings like Cost and Options:
- Cost should be appropriate for the network topology and latency
- Options should not have DisableConnection selected
Misconfigured site links can prevent proper DC replication and authentication between the domains. Update any incorrect site link settings to restore connectivity.
Force Replication
Broken trusts can also result from Active Directory replication failures between domains. We can manually initiate replication to see if that resolves any trust issues.
On a DC in the source domain, run:
repadmin /syncall /AdeB /e /P TargetdomainDCs
Replace TargetdomainDCs with the list of DCs in the target domain, using their full DNS names.
Then on a DC in the target domain run:
repadmin /syncall /AedB /e /P SourcedomainDCs
Here, substitute SourcedomainDCs with the source domain DCs.
This will trigger ad hoc replication between all DCs to sync any changes. Recheck trust status after replication completes. Force syncing can resolve issues caused by outdated or missing objects impacting the trust.
Time Synchronization
For domain trusts to establish successfully, the DCs in both domains must have their clocks synchronized to within 5 minutes of each other. Kerberos relies on proper time sync to generate and validate tickets.
Check time sync with the Get-Date PowerShell cmdlet. Run Get-Date on a DC in each domain, the DateTime should match within a few minutes or less. If time is off, synchronize to a common reliable time source. The simplest approach is pointing all DCs to external NTP pool servers.
You can point to external NTP with the w32tm command. For example:
w32tm /config /manualpeerlist:pool.ntp.org,0x8 /syncfromflags:manual
Run this on DCs in both domains, substituting your preferred NTP server pool. Then restart the Windows Time service and verify date/time sync between DCs.
Replication Latency
Extensive latency replicating changes between domains can also break trusts. Latency prevents objects like user accounts staying in sync between domains.
Use the repadmin /showrepl command to check replication latency between DCs:
repadmin /showrepl * TargetDC
Run this on a source domain DC substituting the DNS name of a DC in the target domain. Review output, latency should not exceed 15 minutes between any DCs:
Source DC Target DC Time Since Last Sync DC1.sourcedomain DC2.targetdomain 00:05:00
If latency is high, check network connectivity between sites. Optimize site links, increase bandwidth, or adjust replication schedules to restore timely replication.
Secure Channel Issues
Domain trusts rely on a secure channel for authentication between domains. This secure channel can break, preventing proper interdomain communication.
Check secure channel status with the Get-ADTrust cmdlet. Run this to retrieve the trust between domains:
Get-ADTrust -Filter {SourceDomain -eq "sourcedomain" -and TargetDomain -eq "targetdomain"}
In the output, verify that the TrustState attribute = Verified. If not, the secure channel needs to be reset. This is done with the Reset-ADTrust cmdlet:
Reset-ADTrust -Target "targetdomain" -Confirm:$false
Run this on a DC in the source domain to reset the trust with the target domain. Recheck status after reset completes, this should restore proper secure channel function.
System Time Validity
Extensive time differences between domains can trigger secure channel issues. If the current time is too far outside the accepted validity window, trusts may fail.
Check time validity with the Get-ADTrust cmdlet, using a filter to retrieve the trust:
Get-ADTrust -Filter {TargetDomain -eq "targetdomain"} | Select LastValidationTime
This displays the last validation time for the trust. If this date is too far in the past, it indicates the domains have significantly different system times currently. To resolve, synchronize time properly between all DCs as covered earlier.
Configuring SID Filtering
As mentioned earlier, SID filtering is a critical setting that prevents inactive SIDs from spreading between domains via the trust:
Get-ADTrust -Filter {TargetDomain -eq "targetdomain"} | Select SIDFilteringEnabled
This displays whether SID Filtering is enabled on the trust. It should be configured to $true to isolate SIDs properly. If disabled, use Set-ADTrust to enable it:
Set-ADTrust -Target "targetdomain" -SIDFilteringEnabled $true
With SID filtering enabled, any mismatched or inactive SIDs are blocked from crossing the trust boundary between domains.
External vs Forest Trusts
The type of trust can also play a role in issues. External domain trusts and forest trusts have important differences:
- External – One-way or two-way trust between domains in different forests
- Forest – Two-way transitive trust linking all domains in the forests
Problems establishing or validating external trusts point to issues between specific domains. Forest trust problems usually indicate wider forest-level concerns like schema mismatches.
You can see the trust type in Get-ADTrust output. If a forest trust is broken, focus on forest prep health, schema conflicts, and DNS configuration at the forest root level.
Checking Trust Authentication
Confirming proper authentication functionality across the trust is key. With the trust relationship established, accounts from the trusted domain should be able to authenticate in the trusting domain.
A simple test is running an NLTest command like:
nltest /dsgetdc:targetdomain /server:sourcedc /force
This sends an authentication request from a source domain controller to the target domain. If it returns successfully, it indicates basic access rights are working across the trust boundary.
You can also attempt to open a session as a user from the trusted domain, using runas with their credentials. This validates end-to-end authentication functionality:
runas /netonly /user:trustdomain\testuser cmd.exe
If authentication fails, focus troubleshooting on Kerberos infrastructure, SPNs, and delegation settings between the domains.
Recommended Trust Repair Steps
Based on the troubleshooting details covered, here is a summary checklist of steps to resolve common domain trust issues in PowerShell:
- Run Get-ADTrust and check status/attributes on all trusts
- Confirm DNS records are configured properly between domains
- Verify site link objects and settings are correct
- Force replication between DCs with repadmin
- Check time sync with Get-Date and enable external NTP
- Review replication latency and optimize where needed
- Reset secure channel on trusts with Reset-ADTrust
- Resolve any invalid validation time problems
- Enable SID filtering if disabled
- Test authentication across the trust boundary
Methodically working through these steps will identify and resolve the most common issues with domain trusts. The PowerShell commands provide detailed data for analysis. Restore healthy domain relationships by correcting any problems found.
Advanced Domain Trust Repair
For more advanced or persistent trust issues, additional PowerShell techniques can help resolve difficult problems:
Force Removal of Stale Objects
Stale objects, like user or computer accounts, can disrupt trusts even after proper cleanup. The Remove-StaleADObject cmdlet forcibly deletes these objects from the domain:
Remove-StaleADObject -Server sourcedc -SearchBase DC=domain,DC=local
This scours AD and removes any stale objects that may be interfering with the trust.
Manually Reset Secure Channel
Resetting the secure channel with Reset-ADTrust may fail if the trust is severely broken. You can manually reset by deleting and recreating the computer objects:
Remove-ADObject -Identity "CN=SOURCEDC,CN=Computers,DC=sourcedomain,DC=local" Remove-ADObject -Identity "CN=TARGETDC,CN=Computers,DC=targetdomain,DC=local"
This wipes the existing secure channel. Then trigger re-creation with:
Test-ComputerSecureChannel -Repair -Server sourcedc Test-ComputerSecureChannel -Repair -Server targetdc
This will establish a new secure channel with fresh computer objects.
Force Schema Sync
Schema mismatches between forests can sometimes break forest trusts. Initiate forced schema replication using:
repadmin /schema /aedsr:targetdcname /u:admindomain\username /pd:*
This pushes the schema from targetdc to the source domain, potentially resolving schema conflicts.
Rebuild Forest Root
As a last resort, completely rebuild the forest root domain to resolve persistent issues. This involves demoting the forest root DC and rebuilding it from scratch. All domains must be temporarily removed from the forest. This is complex but can clear problems if all else fails.
Conclusion
Maintaining healthy domain trust relationships in Active Directory is crucial for proper resource access and permissions between domains. Trusts can break or become compromised over time.
PowerShell provides powerful commands for managing trusts. Get-ADTrust, Reset-ADTrust, and other cmdlets expose detailed trust properties and allow resetting connections. This enables diagnosing and repairing broken trusts.
Focus troubleshooting on time sync, DNS, replication issues, and secure channel problems. Verify authentication functionality across trusts. Methodically address any discrepancies found. Apply advanced techniques like force resets if basic fixes are not sufficient.
With the proper administration approach using PowerShell, you can reliably maintain domain trust integrity and ensure proper cross-domain operations in your environment.
