Trust Relationship Between This Workstation and the Primary Domain Failed – Troubleshooting Active Directory

In a corporate environment that runs Windows-based computers, the network directory service normally used is called an Active Directory Domain. When you have an Active Directory Domain, you have a grouping of networked computer systems that share a common directory database and trust relationships with one another. The “trust relationship” is what is important here, as it’s what ties all of the computers together within the domain and allows them to communicate with one another securely. This is why when you try to log into a Windows machine that is a part of an Active Directory, your computer will first try to establish a “trust relationship” with the domain controller. So, what happens when you see an error message stating that the “trust relationship between this workstation and the primary domain failed”?

Since the directory database contains information about all of the network resources that are on the corporate intranet, including user accounts, security information, and group policies, if the trust relationship between a workstation and the primary domain fails, then the workstation will not be able to access the above-listed resources, causing significant disruptions for users and IT staff alike. As such, network administrators need to understand why trust relationships fail to avoid disruptions and how to go about repairing them when they do. 

What causes the trust relationship between this workstation and the primary domain failed error?

While there can be a few different reasons for why you receive the “trust relationship between this workstation and the primary domain failed” error, the most common cause that network administrators see is a password mismatch between the local computer and the one that is stored in the Active Directory (AD). When these two passwords are out of sync, you will receive the trust relationship failed error, as noted above. 

How do passwords become mismatched?

When a computer is joined to the Active Directory, a separate computer account is created, and a password is set. This computer account password is used to authenticate the computer within the domain and to establish a trusted connection with the domain controller. Unlike user passwords, computer account passwords are only valid for 30-days by default and are set and changed automatically. If and when it changes, and the local computer password isn’t changed to match, then you end up with a password mismatch, and the result is the  “the trust relationship between this workstation and the primary domain failed” error message. Typically, the computer will prompt you to update your password, avoiding the issue altogether. However, here are several scenarios where a password mismatch may occur:

• The computer account has been reset.
  While managing computers and other objects using the Active Directory Users and Computers (ADUC) tool, it’s possible the server administrator has reset your computer’s server account, either by mistake or to solve an unrelated issue.
• The computer account has been disabled.
  Similar to the above, your computer’s server account may have been disabled for maintenance or for being inactive.
• After restoring a backup.
  If you had to restore a backup after a system wipe, it might have restored a previously expired password as well.
• Duplicate computer names in AD.
  If a new computer account has been added to the server, the name of the computer may match your name. In this case, the domain server will deny access to one or both users as it will not be able to differentiate the two from each other. This is similar to when you try to save a duplicate file on your computer, and the system demands that you either change the file name or replace the original entirely.
• The system time is incorrect. (Rare)
  If your computer has been set not to update the date and time automatically, then the domain server may read this as an error and deny access. This issue is easily solved by simply setting your system to update the date and time in your system settings automatically.

How to fix the “trust relationship between this workstation and the primary domain failed” error

You can resolve this issue in several ways, and typically you will have to re-authenticate the computer account’s access to the domain server. As such, you may need to work with your domain server’s administrator on a number of steps. Before going through these steps, make sure to verify the following:

• Your domain credentials are correct.
  Having incorrect credentials or even an incorrect server address is a simple and easily fixable mistake. Trying to connect to the wrong server or having incorrect login information are both common scenarios.
• Your computer’s name is unique.
  As discussed earlier, two computers with the same name are like two identical files being saved to the same computer: one, or both, will be forced to change or replace the other.
• Your computer’s IP address is unique.
  As it is with computer names, duplicate IP addresses will yield the same result.

Once you’ve established that none of these is the issue, you can proceed with these five methods for fixing the “trust relationship between this workstation and the primary domain failed” error.

1. Reconnect the computer’s server account to the domain

1. On the client computer, log out of the user account and back in using the local administrator’s account.
2. Open File Explorer by pressing the Windows key on your keyboard and typing “File Explorer” in the search bar.
3. Locate This PC in the list on the left-hand side of the window and right-click on it. In the menu that appears, click on Properties.

4. In the new window, locate Advanced System Settings and left-click on it. This will open the System Properties window.
5. Click on the tab labeled Computer Name, then click on the Change button.

6. In the new window, ensure there is a checkmark beside the Workgroup option, located under the Member Of heading. Type in a workgroup name, then click the OK button.

7. You will be prompted for a username and password. Input a username and password with the necessary permissions to remove the computer from the domain server, such as the local administrator’s.
8. Click the OK button, then restart your computer when prompted.
9. Repeat steps 1 through 6, but instead of placing a checkmark beside Workgroup, place one beside Domain under the same heading.
10. Type in the name of the domain, click the OK button, then type in the same username and password as was used in step 7.
11. Click the OK button again, then restart the computer as prompted. Once the computer has successfully restarted, you should be able to log in with the local user account again.

2. Re-establish server trust using Windows PowerShell

1. Start by holding down the Windows key and tapping the X key. The menu that appears is called the Power User Menu.
2. Once the menu appears, tap the A key on your keyboard in order to open Windows PowerShell in admin mode.

3. In PowerShell, type in the following command:
   $credential = Get-Credential
   Then hit the Enter key.
4. You should be prompted for a username and password. Type in the local administrator’s credentials, then click the OK button.
5. In PowerShell again, type in the following command:
   Reset-ComputerMachinePassword -Credential $credential
   Then hit the Enter key.
6. Wait for the command to finish running, then exit PowerShell and restart your computer. Once the computer has successfully restarted, you should be able to log in with the local user account again.

3. Use Credential Manager to add a Windows credential

1. On the client computer, log out of the user account and back in using the local administrator’s account.
2. Hold down the Windows key and tap the R key on your keyboard to open the Run dialogue box.
3. Type in “Control Panel,” then hit the Enter key.

4. In the window that appears, click on User Accounts, then click on Credential Manager.

5. Left-click on the Windows Credentials button, then Add a Windows Credential at the top-right of the list.

6. In the new dialogue box, type in the address or network location of the server you need access to. Click the OK button.

7. Restart the computer. Once the computer has successfully restarted, you should be able to log in with the local user account again.

4. Reset the computer’s server account

1. On the client computer, log out of the user account and back in using the local administrator’s account.
2. Hold down the Windows key and tap the R key on your keyboard to open the Run dialogue box.

3. Type in “dsa.msc”, then hit the Enter key. This should open the Active Directory User and Computers (ADUC) console tool.
4. In the ADUC tool, locate the server’s domain name, then double-click it to expand it.
5. Click on the option labeled Computer, then right-click the computer account experiencing the error located in the list on the right.
6. Select Reset Account from the menu, then click the Yes button to confirm.
7. Restart the computer and attempt to log in to the local user account. You should be prompted to change your password and update it with the server, allowing you to log in normally again.

5. Remove and repair corrupted configuration caches

1. On the client computer, log out of the user account and back in using the local administrator’s account.
2. Hold down the Windows key and tap the R key on your keyboard to open the Run dialogue box.
3. Type in “%allusersprofile%”, then press the Enter key. This should open File Explorer in the All Users Profile folder.
4. In this folder, open Microsoft, Sharepoint, then Config[GUID].
5. Identify and delete all XML files in this folder.
6. Locate a file called cache.ini, then rename it to cache.ini1. Close File Explorer.
7. Hit the Windows key, then type in “Services” and hit the Enter key.

8. In the Services app, locate Sharepoint Timer Service in the list, right-click on it and choose Restart from the menu.
9. Restart the computer. Once the computer has successfully restarted, you should be able to log in with the local user account again.

Conclusion

If you’re still having trouble after following these steps, it’s likely that there is a more serious issue at play and you may want to reach out to a more experienced network administrator for some further guidance. With that being said, trust relationship errors are usually relatively easy to fix as long as you have access to the local administrator account on the affected machine. 

report this ad

Hopefully, this article has provided you with the information you need in order to get your machine up and running again. Let us know in the comments below if this blog post helped you out.