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