- Create a certificate-signed RDP shortcut via Group Policy - Fri, Aug 9 2019
- Monitor web server uptime with a PowerShell script - Tue, Aug 6 2019
- How to build a PowerShell inventory script for Windows Servers - Fri, Aug 2 2019
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
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
}
[pscustomobject]$output
})Running this returns an output that looks like this:
Subscribe to 4sysops newsletter!
ComputerName Status ------------ ------ COMPUTER1 Offline COMPUTER2 True COMPUTER3 False COMPUTER4 True
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.
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
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!
If the computer in question had a local administrator account… oh if only. “\Weeps in extreme security measures.”
I would consider deploying LAPS
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
Get-credential Administrator
would be enough I guess. Also I dont think Win7 pshell 2.0 supports -message parameter
your meant to swap username with the one your asking ie Administrator
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.
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,
]<
A differnt option is using Dsmod or Netdom commands as described here: Testing and Resetting the Secure Channel
Here an extract:
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.)