Once the most common problems that plague Windows system administrators are trusted, Active Directory computers seemingly fall off the domain. The infamous “the trust relationship between this workstation and the primary domain failed” error is all too common.
Not a reader? Watch this related video tutorial!In this guide, you’re going to learn every trick I’ve come across in my 20+ years managing Active Directory and how to automate it with PowerShell.
“The trust relationship between this workstation and the primary domain failed” Error Message
When an AD domain no longer trusts a computer, chances are it’s because the password the local computer has does not match the password stored in Active Directory.
![The Trust Relationship Between This Workstation and the Primary Domain Failed](https://adamtheautomator.com/wp-content/uploads/2019/08/trust-relationship-failed.png)
The two passwords must be in sync for AD to trust a computer. If they aren’t in sync, you will receive the infamous error message “the trust relationship between this workstation and the primary domain failed“.
Unfortunately, there has never been a single solution that myself and other sysadmins have found that works 100% of the time. That’s why I wrote this guide.
This guide is intended to be a single repository for every, single way to fix this issue once and for all and to automate the process with PowerShell.
Active Directory Computer Account Passwords
When a new computer is added to Active Directory, a computer account is created with a password. That password is valid for 30 days, by default. After 30 days, it automatically changes. If it changes and the client password does not, you will get the “the trust relationship between this workstation and the primary domain failed” error message.
Viewing Existing Policies
You can view the domain-wide policy by opening up the Group Policy Management Console (GPMC). Inside the GPMC, click on the Default Domain Policy, and navigating to Computer Configuration –> Windows Settings –> Security Settings > Local Policies > Security Options.
Once in Security Options, look for the policy called Domain member: Maximum machine account password age.
![Computer Account Password Age Policy](https://adamtheautomator.com/wp-content/uploads/2019/08/image-10.png)
On an AD joined computer, open up regedit and navigate to the HKLM\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters registry key and find at the MaximumPasswordAge value as shown below.
![Local Computer Account Password Age Registry Value](https://adamtheautomator.com/wp-content/uploads/2019/08/image-11.png)
While you’re in there, you can disable the local computer from changing the password at all by setting the DisablePasswordChange value to 1.
When the computer account changes, both the local computer and AD computer account should change their passwords together. AD knows the current one and the previous one in case they become out of sync for a brief period.
The Computer Account Password Change Process
When things are normally working, using the Netlogon Windows service, the computer initiates a password change automatically. This happens during a computer reboot or when the computer object needs to authenticate to AD.
Using the Netlogon Windows service, the local computer initiates a password change sequence. The computer first initiates a password change on a domain controller. If that is successful, it then attempts to change the local password to match within the HKLM\SECURITY\Policy\Secrets<hostname>.ACC registry key.
Normally this process works great even if the computer is shut off or offline for longer than 30 days because the local computer initiates a password change.
However, a problem occurs when:
- the computer changes the AD computer account but is unable to change the local password
- the computer is reimaged without running Sysprep
- the OS is reinstalled and is attempting to authenticate with the old, enabled, AD computer account
- …and more?
If any of the above happens, you will see that “the trust relationship between this workstation and the primary domain failed” error message.
Verifying the Problem
Once you know the problem exists, how do you replicate it or at least have a method to determine which computers have the problem? You could try to interactively log into each computer but that’s not scalable and I don’t want to get up from my desk!
Let’s build a script we can run both locally and remotely to determine which computers in the domain have this problem to eradicate the “trust relationship between this workstation and the primary domain has failed” error message for good.
First of all, since you’re assuming domain authentication isn’t working, you’ll need to know a local user account in the administrators group. I hope you know your local administrator password!
nltest (Command-Line Tool)
nltest is an old-school command-line tool that will test a trust relationship for a computer. This tool is installed when you install RSAT or is available directly on a domain controller.
You can verify a trust relationship on a computer when logged on the computer by running:
> nltest /sc_verify:<your domain FQDN>
WARNING: This method isn’t recommended because nltest only works in the user context in which it was launched. If the computer has a broken trust and you’re logged in as a local user, it will attempt to connect to the domain using the local user’s credentials. This results in an access denied error.
netdom (Command-Line Tool)
netdom is another command-line tool you can use to verify a trust relationship. This tool is also installed when you install RSAT or is available directly on a domain controller.
You can verify a trust using netdom verify
by providing:
- the name of the computer name to verify
- FQDN of the domain
- username to authenticate the request
- password of the user account
Below is an example:
> netdom verify MYCOMPUTER /Domain:domain.local /UserO:abertram /PasswordO:*
By providing the value of *
to the PasswordO
parameter, netdom will prompt for the password.
Test-ComputerSecureChannel (PowerShell)
One of the best ways to solve the “the trust relationship between this workstation and the primary domain has failed” problem is to use the Test-ComputerSecureChannel
cmdlet. This PowerShell cmdlet comes with Windows 10 and is easier to use.
The Test-ComputerSecureChannel
cmdlet works locally on a Windows 10 computer. When logged into the computer interactively, open up a PowerShell console and run Test-ComputerSecureChannel
without any parameters. It will return either True or False depending on if the trust is valid.
PS51> Test-ComputerSecureChannel
True
You may also specify a particular domain controller to confirm the passwords are in sync by using the Server
parameter.
PS51> Test-ComputerSecureChannel -Server 'DC.domain.local'
False
This cmdlet is straightforward to use and has a Repair
option but we’ll save a demonstration of that for the fixing section.
If you know the local administrator password of those computers you’d like to check and PowerShell Remoting is enabled on them, you can also use the Invoke-Command
cmdlet. By using the Invoke-Command
cmdlet, you can remotely run Test-ComputerSecureChannel
on one or many computers at once.
PS51> Invoke-Command -ComputerName PC1, PC2, PC3 -ScriptBlock { Test-ComputerSecureChannel }
Checking Trust Relationships in Bulk
Now that you know how to remotely check a trust relationship, here’s a code snippet you can use to check all of your AD computers! In this script, I’m first testing to ensure the computer is online. If not, it will return Offline. If so, it will run Test-ComputerSecureChannel
on each computer and either return True or False.
$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
})
Knowing and understanding the problem is the first step but how do you fix it? You now know that you need to get the computer account stored on the local computer the same as the computer account stored in AD.
There are many different “solutions” out there for the “the trust relationship between this workstation and the primary domain failed” problem. These solutions can be performed via the GUI, via PowerShell, or via old-school command-line tools.
- Reset the computer account password in AD
- Resetting the local computer account password
- Unjoin and rejoin the Windows computer
- Remove the computer account completely and rejoin the Windows computer
That’s a lot of options! In this guide, we’re going to focus on fixing this problem with PowerShell and command-line tools (for completeness). If you aren’t already using PowerShell, you should!
Fixing the Problem: Resetting Computer Passwords
netdom (Command-Line Tool)
A trust can be repaired and the “the trust relationship between this workstation and the primary domain failed” error message can be eliminated by using the old-school netdom command-line tool. If you’re logged into the computer locally as an administrative user, you can run netdom resetpwd to initiate the password reset sequence as shown below.
In this example:
- DC is the name of the domain controller
- abertram is the name of the Active Directory user account with rights to reset the computer account
- * is a placeholder for the user account password which will prompt for the password.
> netdom resetpwd /s:DC /ud:abertram /pd:*
Reset-ComputerMachinePassword (PowerShell)
One of the best ways to fix a trust relationship is by using the Reset-ComputerMachinePassword
cmdlet. This cmdlet is run on the local computer and will initiate a password reset sequence. Its syntax couldn’t be simpler.
PS51> Reset-ComputerMachinePassword
If you’d like to specify a particular DC to reset, you can specify it using the Server
parameter along with an option credential (it will default to the local user).
The below example will prompt for an AD username and password and attempt to reset the password on the local computer and the DC domain controller.
PS51> Reset-ComputerMachinePassword -Server DC -Credential (Get-Credential)
This can also be run remotely by using Invoke-Command
if PowerShell Remoting is available on the computer. Below, I’m obtaining the username and password for the local administrator account on the computer. I’m also obtaining the credential that has rights to reset this computer’s AD account password. I’m then passing $domainCredential
into the remote session using the $using
construct.
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
PS51> Invoke-Command -Computername MYCOMPUTER -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }
Note that this also works even if the computer account has been removed from Active Directory. Create a computer account with the same name and
Reset-ComputerMachinePassword
will ensure the password is synced up.
Resetting Local Computer Account Passwords in Bulk
Want to take care of that “the trust relationship between this workstation and the primary domain failed” error across lots of computers at once? No problem. Using a handy foreach loop, we can run Reset-ComputerMachinePassword
in bulk too.
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
@(Get-AdComputer -Filter *).foreach({
$output = @{ ComputerName = $_.Name }
if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
} else {
$pwChangeOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Reset-ComputerMachinePassword -Server DC -Credential $using:domainCredential }
$output.PasswordChangeOutput = $pwChangeOutput
}
[pscustomobject]$output
})
Test-ComputerSecureChannel -Repair (PowerShell)
Another way to initiate the password change process is to run Test-ComputerSecureChannel
but this time use the Repair
option. From what I can tell, this process is identical to using Reset-ComputerMachinePassword
. On a the computer console use the Repair
parameter and the Credential
parameter.
PS51> Test-ComputerSecureChannel -Repair -Credential (Get-Credential)
Be sure to always use the Credential
parameter here. If you don’t, similar with the nltest utility, it will attempt to use the local account and won’t work.
Repair Trust Relationships in Bulk
Drop this command into the handy foreach loop we’ve been using and Bob’s your uncle!
$localAdminCredential = Get-Credential
$domainCredential = Get-Credential
@(Get-AdComputer -Filter *).foreach({
$output = @{ ComputerName = $_.Name }
if (-not (Test-Connection -ComputerName $_.Name -Quiet -Count 1)) { $output.Status = 'Offline'
} else {
$repairOutput = Invoke-Command -Computername $_.Name -Credential $localAdminCredential -ScriptBlock { Test-ComputerSecureChannel -Repair -Credential $using:domainCredential }
$output.RepairOutput = $repairOutput
}
[pscustomobject]$output
})
Fixing the Problem: Rejoining the Domain
If resetting the computer account passwords don’t work for you, there’s always the nuclear option. You can rejoin a computer to the Active Directory domain. Although not necessary all the time, there have been times I’ve had to use this approach.
Note that I’ve heard some reports that an disjoin isn’t necessary. You may be able to get away by just forcing a new join. YMMV.
You could:
- log onto the computer via a local administrative account
- go to System Properties
- click on Change
- set it to a workgroup
- reboot
- set it back to the domain
Notice how I mention could. Don’t do this. It’s a waste of your time when you can automate it with PowerShell.
There are two ways I’ve found that you can use PowerShell to unjoin a domain and use PowerShell to join a domain.
Using CIM
You can join a domain with PowerShell (and unjoin it) using the Win32_ComputerSystem CIM class. This class has two methods that allow you to unjoin and join a computer to a domain called UnJoinDomainOrWorkgroup()
and JoinDomainOrWorkGroup
.
Since this is CIM, you can run this just as easily remotely as you can locally. Since I assume you’d prefer to run this remotely from the comfort of your desk, here’s a code snippet that does just that.
“the trust relationship between this workstation and the primary domain failed” error be gone!
$computername = 'PITA'
$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'
$invCimParams = @{
MethodName = 'UnjoinDomainOrWorkGroup'
Arguments = @{ FUnjoinOptions=0;Username="Administrator";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams
Notice the FUnjoinOptions
parameter above. I’ve chosen to specify 4 here. This performs the default behavior when unjoining a computer manually. This option disables the computer account in Active Directory (if it can find one). If you’d rather not have this behavior, you can use option 0 here.
Once the computer is unjoined, you can then rejoin the domain using the JoinDomainOrWorkGroup()
method.
$computername = 'PITA'
$instance = Get-CimInstance -ComputerName $computername -ClassName 'Win32_ComputerSystem'
$invCimParams = @{
MethodName = 'JoinDomainOrWorkGroup'
Arguments = @{ FJoinOptions=3;Name=mydomain.local;Username="mydomain\domainuser";Password="mypassword" }
}
$instance | Invoke-CimMethod @invCimParams
Notice the FJoinOptions
parameter above. I’ve chosen to specify 3 here. This performs the default behavior when joining a computer manually. This option creates an AD computer account. You can find a few other options like adding to a specific OU via the JoinDomainOrWorkgroup documentation.
TIP: You can also unjoin and rejoin many computers at once via this method by specifying multiple computers via the
ComputerName
parameter onGet-CimInstance
.
Using the Remove-Computer and Add-Computer Cmdlets
You can also use built-in PowerShell cmdlets to unjoin and join a computer to a domain with PowerShell. You can use the Remove-Computer
and Add-Computer
cmdlets.
To unjoin a computer with PowerShell, log onto the computer console and use the Remove-Computer
cmdlet. Provide the domain credential with permissions to unjoin the computer. You can also specify the Restart
parameter to force a restart after the unjoin and Force
to not prompt for confirmation.
PS51> Remove-Computer -UnjoinDomaincredential (Get-Credential) -Restart -Force
Once the computer has been rebooted, you can then use the Add-Computer
cmdlet to join the computer to the domain with PowerShell. You can use the Add-Computer
cmdlet remotely by providing the ComputerName
parameter. You’ll also use local user credentials to make the connection and the domain credential to authenticate to the domain.
When it comes back up, here’s hoping you no longer get the “the trust relationship between this workstation and the primary domain failed” error message.
$localCredential = Get-Credential
$domainCredential = Get-Credential
Add-Computer -ComputerName PITA -LocalCredential $localCredential -DomainName domain.local -Credential $domainCredential -Restart -Force
Automagical Domain Unjoin and Rejoin
Because I had to do this process way too many times, I built a PowerShell script that does everything for you. If you provide it the name of the computer, it will:
- Unjoin the computer
- Reboot and wait to come back up
- Join the computer
- Reboot and wait to come back up
You can try out this script via GitHub.
Summary
You should now have a full understanding of the problem and multiple solutions to the infamous “The trust relationship between this workstation and the primary domain failed” error message. I hope this guide provided you with some insights and allowed you to come up with some solutions of your own to the problem of computers falling of the domain!
Further Reading
Be sure to check out some other related posts!