Repair the domain trust relationship with Test-ComputerSecureChannel

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.

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.

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!

Running this returns an output that looks like this:

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.

Join the 4sysops PowerShell group!

Your question was not answered? Ask in the forum!

7+
avataravataravataravatar
Share
9 Comments
  1. Hi Adam,

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

    Thanks

    L

    2+

  2. Jason moore 3 years ago

    Adam,

    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!

    1+

  3. Ernst Jan Verbree 3 years ago

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

    4+

    • Brad Tostenson 2 years ago

      I would consider deploying LAPS

      4+

  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

    1+

    • Get-credential Administrator

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

      2+
      avatar
  5. Hani 3 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.

    1+

  6. Michael Mills 2 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.

    Thanks,

    ]<

    1+

    • 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.

      " -reset[/crayon]
      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.

      /Domain <DomainName> /UserO <UserUPN> /PasswordO *[/crayon]

      0

Leave a reply

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

*

© 4sysops 2006 - 2020

CONTACT US

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

Sending

Log in with your credentials

or    

Forgot your details?

Create Account