If a trust relationship between a Windows workstation and an Active Directory domain is broken, the computer won’t be able to establish a secure channel with the domain controller, and domain users will not be able to authenticate to that computer. In this article, we will look at the root causes of why Windows machines can fall off the AD domain and a simple way to restore a trust relationship between a computer and a domain without reboot.
The Trust Relationship Between This Workstation and the Primary Domain Failed
If a computer is not in a trust relationship with a domain, you will get an error when you try to log on to that computer as a domain user:
The trust relationship between this workstation and the primary domain failed.
The error may also look like this:
The security database on the server does not have a computer account for this workstation trust relationship.
Repair Broken Trust Between Computer and Domain with PowerShell
Typically, administrators in this situation simply remove the computer from the domain and rejoin it to AD. This method works well but requires a lot of time and several computer restarts. It’s much faster and easier to restore the trust relationship between the workstation and the domain using PowerShell (without rejoining the domain or restarting the computer).
To restore trust between the machine and the domain, you need to log on to the computer locally using any account with local administrator privileges. This can be a local user with administrator permissions, or the built-in Windows administrator (if you don’t know your local administrator password, you can reset it).
To log on to the computer as a local user, enter the local user name on the sign-in screen in the format: .\localuser
. The dot at the beginning of the name indicates that the local account database should be used.
Open an elevated PowerShell console and check to see if the computer is in a trust relationship with the AD domain:
Test-ComputerSecureChannel –Verbose
The computer cannot establish trust with the domain if the computer’s local password and the domain password do not match and the command will return:
False – The Secure channel between the local computer and the domain woshub.com is broken.
To force restore the trust relationship between the current workstation and the domain, run the following command:
Test-ComputerSecureChannel -Repair -Credential woshub\administrator -Verbose
If the computer can connect to the DC and set a new password for its account, thereby restoring trust with AD, a message will be displayed:
True. The secure channel between the local computer and the domain woshub.loc was successfully repaired.
Check that trust has been successfully restored. Run Test-ComputerSecureChannel
again to make sure it returns:
True. The Secure channel between the local computer and the domain woshub.com is in good condition.
Log off the local user and sign in to the computer as a domain user (no reboot required).
You can also use this command to force reset and sync your computer’s password.:
Reset-ComputerMachinePassword -Server mun-dc01.woshub.com -Credential woshub\administrator
mun-dc01.woshub.com
– is the name of the closest DC.
In some cases, the trust repair command may return an error:
The attempt to repair the secure channel between the local computer and the domain woshub.loc has failed.
In this case, you need to check that the domain can be connected from the computer, that this computer account exists in the domain, that it is not disabled, and that you have the permissions to manage it. To find out the name of your computer, use the hostname command. Open the Active Directory Users and Computers snap-in (dsa.msc
) and find the account for this computer. In this example, it is disabled. Re-enable it.
Machine (Computer) Account Password in Active Directory
Why is it possible for the trust relationship between a computer and a domain to fail?
When a computer is joined to an Active Directory domain, a separate computer account is created for it. Each computer in the domain has its own password, which is used to authenticate to the domain and establish a trusted connection with the domain controller. By default, this password changes automatically every 30 days and is stored locally on the computer (under the registry key HKLM\SECURITY\Policy\Secrets\$machine.ACC
) and in the AD. The frequency of computer password changes is set by the Domain member: Maximum machine account password age GPO option.
Unlike user passwords, the computer password doesn’t expire. The computer, not the domain controller, initiates the password change.
If the hash of the password that the computer sends to the domain controller doesn’t match the computer’s account password in the AD, it won’t be able to establish a secure connection to the DC and will return a trust relationship error.
The most common reasons that cause the failed trust relationship error:
- A computer has been restored from an old restore point or a snapshot (if it is a virtual machine) that was created before the computer’s password was changed in AD. This means that the machine password in the snapshot differs from the AD computer object password. Before taking a snapshot, it is recommended that you force a computer in the domain to change its password using the command:
nltest.exe /sc_change_pwd:woshub.loc
- The computer has been cloned without using the Sysprep tool;
- A new computer object with the same name has been created in AD, or someone has reset the computer account in the domain using the ADUC console (
dsa.msc
); - The computer account in the domain has been disabled by the administrator (for example, during a regular procedure of disabling inactive AD objects);
- If the local system time on your computer is incorrect or Windows time synchronization has failed.
For test VMs that need to be frequently restored from snapshots or restore points, you can use the GPO parameter to disable regular password changes (Domain member: Disable machine account password changes in Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options).
11 comments
Amazing!!
Many thanks
Question: If I cannot login the computer (virtual machine), how to ?
I also have local admin credential, but when I try to login, it always say wrong username or password.
Question: If I cannot login the computer (virtual machine), how to do “Open the elevated PowerShell console and using Test-ComputerSecureChannel cmdlet make sure if the local computer password matches the password stored in AD.” ?
I also have local admin credential, but when I try to login, it always say wrong username or password.
If you are logged into the computer local user, check the workstation interrelationship with the command:
Test-ComputerSecureChannel -Server DCName
When signing in using administraitor is says trust is broken
When signing in using local administrator is says disalbled check with your administrator
Have situation where all domain computers and servers have a broken relation to the domain. Also “ping” results in general failure.
Attempting to repair as advised here fails.
This was a result of my amateur attempt to heighten security by imposing strict group policies and firewall rules. Unfortunately, I have not been able to reestablish no matter how I go back. Have followed all available instructions regarding DNS, firewall etc but after several days still to no avail. Any suggestions?
For some reason it helped to switch network on servers from fixed IP address to DHCP, restart and then go back to fixed IP. On PCs it was enough to switch from WiFi to network cable or vice versa. Apparently the network settings needed to be freshened up, and all the standard attempts to do so had not worked. Anyways, back on track 🙂
It looks like your network connection profile on clients has been reset to Private. Your actions help switch it back to domainprofile.
You probably need to start by undoing the changes you made. If all changes are made through the domain GPO, simply unlink them from the OUs.
Thanks for your replies. I got all but one computers back on track. The last one is running Windows 11. As nothing else worked I tried to delete it in Active Directory and DNS hoping that I would be able to rejoin the computer to the domain. That is not the case. The computer seems to be locked in the belief that it is a domain member although it will not connect to the domain. I cannot rename the computer either. Can work on the computer using a local account, but obviously no access to network folders etc. Wonder how I can get this one back into the domain?
Try resetting any changes made to the device by the domain GPO.
Clear Domain-Applied Group Policy Settings in Windows