If the trust relationship between a workstation and the primary domain failed, you can use the Test-ComputerSecureChannel PowerShell cmdlet to test and repair the secure channel between the computer and its Active Directory domain.

One of the most annoying messages many IT professionals have to deal with is the infamous Active Directory (AD) broken trust error message:

The trust relationship between this workstation and the primary domain failed

The trust relationship between this workstation and the primary domain failed

This error message seems to happen randomly for no apparent reason and leave you wondering why, all of a sudden, this computer has a broken trust relationship when it was working just fine yesterday.

In any case, a few different things can cause a broken trust relationship. Most likely, the password stored on the local computer has somehow gotten out of sync with the password AD has for that computer account.

A lot of the time, this error message only surfaces after an angry helpdesk call from a user who's unable to log in. Or the message may come from a server that somehow can't authenticate some service. Wouldn't it be nice if we could test for a broken trust relationship if that helpdesk call comes in or even proactively check for this problem? I'm glad you asked, because we can use the Test-ComputerSecureChannel PowerShell cmdlet!

By using the Test-ComputerSecureChannel cmdlet, we can get a simple true/false output showing whether the local computer can establish trust with the domain controller. By default, running Test-ComputerSecureChannel requires no parameters and returns either True or False. This command also has a Repair parameter to use. By passing the Repair parameter to the command, it will attempt to rebuild the channel that the NetLogon service uses.

Test-ComputerSecureChannel -Repair

This command works only on the local computer, but if PowerShell remoting is enabled on a remote computer, it's possible to perform it remotely as well. Since the computer in question may actually have a broken trust, Kerberos authentication might not work. So we'll have to default to a local credential instead.

Invoke-Command -ComputerName REMOTECOMPUTERHERE -ScriptBlock { Test-ComputerSecure Channel } -Credential (Get-Credential -UserName 'administrator' -Message 'User')

In the command above, I'm prompting the user for the local administrator password to the remote computer. After the user provides the password, Invoke-Command will attempt to connect and authenticate to the remote computer using this account. Even if this computer is in a domain, if the trust is broken, relying on Kerberos will fail every time. Luckily, we can fall back to using the remote computer's local accounts instead.

We can also use the same technique to repair the trust relationship by adding the Repair parameter.

This works for ad-hoc tests by the helpdesk, perhaps. But what if you're a system administrator and would like to get proactive? By using the AD PowerShell module, a loop, and the Test-ComputerSecureChannel command, you can easily check all computers in AD on a regular schedule and generate a report!

$localCredential = Get-Credential

@(Get-AdComputer -Filter *).foreach({

    $output = @{ ComputerName = $_.Name }

    if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
        } else {

        $trustStatus = Invoke-Command -ComputerName $_.Name -ScriptBlock { Test-ComputerSecureChannel } -Credential $localCredential
        $output.Status = $trustStatus



Running this returns an output that looks like this:

Subscribe to 4sysops newsletter!

ComputerName Status
------------ ------
COMPUTER1    Offline
COMPUTER3    False

Based on this information, we can then perform further analysis and troubleshooting. Perhaps we can use the Reset-ComputerMachinePassword function; perhaps we just have to disjoin and rejoin the computer to the domain manually. Either way, Test-ComputerSecureChannel arms you with the data you need to make those kinds of decisions.

  1. Leos Marek (Rank 4) 6 years ago

    Hi Adam,

    its not clear to me from the article if TestComputerSecureChannel Repair fixes the broken sec channel (if caused just by pwd sync) and if so is this done without reboot or its still required?



  2. Jason moore 6 years ago


    Thanks for this article. I am not very good with powershell but I still have to try this out. I am the help desk for a 2 year college and I get this a lot. I just did not know I could fix or identify it by using powershell. Thanks again!

  3. Ernst Jan Verbree 6 years ago

    If the computer in question had a local administrator account…  oh if only.  “\Weeps in extreme security measures.”

    • Brad Tostenson 6 years ago

      I would consider deploying LAPS

  4. Invoke-Command -ComputerName $ComputerName -ScriptBlock { Test-ComputerSecure Channel } -Credential (Get-Credential -UserName ‘administrator’ -Message ‘User’)

    i’m getting this error : A parameter cannot be found that matches parameter name ‘UserName’ when running on windows 7

    • Leos Marek (Rank 4) 6 years ago

      Get-credential Administrator

      would be enough I guess. Also I dont think Win7 pshell 2.0 supports -message parameter

    • D.G 2 years ago

      your meant to swap username with the one your asking ie Administrator

  5. Hani 6 years ago

    In my situation I managed to fix the issue on one of the hyper-V cluster nodes , I ran that under local admin account specify domain admin credentials to fix the broken trust channel. I have to reboot the node after that.

  6. Michael Mills 5 years ago

    I would like to script an automated solution that kicks off if the event log throws the tell-tale authentication log entry.
    I manage a lot of different sites.  I don’t want to save XML credentials on the local system, and I won’t have the ability to work with the script interactively if it is an auto-resolution script.

    Is there a way to take creds from a command line operator and just use those on the fly?  If so, I can securely add credentials to my side that will be used when needed.



    • A differnt option is using Dsmod or Netdom commands as described here: Testing and Resetting the Secure Channel

      Here an extract:

      Using a command-line interface

      You can use the dsmod.exe utility to reset a computer’s password. You will need to rejoin the computer to the domain after doing this.

      > dsmod computer  "<ComputerDN>" -reset

      Another option is to use the netdom.exe command, which can reset the computer so that you do not need to rejoin it to the domain.

      > netdom reset <ComputerName> /Domain <DomainName> /UserO <UserUPN> /PasswordO *

  7. Tom Kasmir 6 months ago

    Very nice. I see this is 6 yrs. old but maybe you get notified of new comments? My question is, how would you add another AD property to this output?
    Namely the PasswordLastSet property for each machine.

    I ask because we see trusts getting broken for some devices right at the time of their 30-day mandatory machine password reset. (The password reset itself succeeds, but then an immediate clock resync fails and causes the broken trust, so would like to track these in a report.)

Leave a reply

Your email address will not be published. Required fields are marked *


© 4sysops 2006 - 2023


Please ask IT administration questions in the forums. Any other messages are welcome.


Log in with your credentials


Forgot your details?

Create Account