Skip to Content

How do I fix domain trust relationship in PowerShell?

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:


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 
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 /,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:

  1. Run Get-ADTrust and check status/attributes on all trusts
  2. Confirm DNS records are configured properly between domains
  3. Verify site link objects and settings are correct
  4. Force replication between DCs with repadmin
  5. Check time sync with Get-Date and enable external NTP
  6. Review replication latency and optimize where needed
  7. Reset secure channel on trusts with Reset-ADTrust
  8. Resolve any invalid validation time problems
  9. Enable SID filtering if disabled
  10. 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.


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.