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.
Contents:
- The Trust Relationship Between This Workstation and the Primary Domain Failed
- Repair Broken Trust Between Computer and Domain with PowerShell
- Machine (Computer) Account Password in Active Directory
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).
By default, Windows caches the credentials of the last ten domain users who have logged on to the computer locally. Therefore, if you unplug the network cable while logging on to the computer, you will be able to sign in using the cached domain user credentials.
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
Specify the credentials of the domain administrator or a user who has been delegated the permissions to manage computers in the AD.
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).
However, to update the domain Group Policy settings on the computer, it must be restarted.
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.
Even if the computer has been powered off for
more than 30 days, you can turn it on and it will authenticate to the DC normally using the old password. The local Netlogon service then changes the computer’s password in its local database and updates it in Active Directory.
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).
