We’ve all had it happen. It can happen anywhere – your Windows 7 Home computer, your work computer, even a Windows 2008 Server! You sit down at your workstation, type in your username and password, and boom!

The trust relationship between this workstation and the primary domain failed.

The trust relationship between this workstation and the primary domain failed.
What does that even mean? And now what do I do?

Well, not to fear. As long as you can log onto the computer using your local admin account (you do have one of those, right?) you can correct the problem.

To make a long story short, the underlying issue here is that the workstation can’t communicate securely with your Active Directory domain. Usually it happens when you try to access the workstation using a domain account. Windows fails to verify the Kerberos ticket you receive from AD with the private credentials Windows stores locally; however, there are other causes. Microsoft generally lists this one as the most common, along with rolling back a virtual machine to an old snapshot (which breaks the chain of cached credentials on the local machine).

The most-used method to correct this error is to log onto the workstation using the local, non-Domain administrative account that you should have set up on the machine as part of best practices. (If you don’t do that now, and rely solely on domain network authentication, well, I highly suggest you implement procedures to do so, for just such circumstances as these.) If you can’t get into the workstation that way, you can always try unplugging the machine from the network and then logging in using a domain account and the old password for the account.

Once you successfully log onto the machine, there are several ways to correct this problem – the simplest, and the one that Microsoft kb2771040 suggests, is to remove the computer from the domain by adding it to a local workgroup, rebooting it, then rejoining the domain. However, for this to work, you have to be actually on the domain network – not off-site.

What if you’re in a different state from your home office, for example? You can’t rejoin the domain from offsite, and who wants to drive several hours for a 5-minute fix? Or maybe you just don’t want to go through all the add/remove domain steps?

The easiest way to fix this is to use the NETDOM.EXE tool. Unfortunately, it doesn’t come packaged with Windows 7. Here is what you need to do to install it:

  1. Install the Remote Server Administration Tools (RSAT).
  2. Go to Control Panel -> Programs and Features -> Turn Windows features on or off
  3. In the directory view, go to Remote Server Administration Tools -> Role Administration Tools -> AD DS and AD LDS Tools and select AD DS Tools.
  4. Click OK.

Once you have RSAT installed, go ahead and connect to your domain – either via hardwire, wifi, or VPN if you are offsite. You have to be connected to your Active Directory Domain somehow in order for this command to work – I connected via VPN and it worked fine.

Open a command prompt window (make sure to right-click and choose Run as Administrator). Enter the following command:

netdom.exe resetpwd /s:DOMAINSVR /ud:DOMAIN\USERNAME /pd:*

  • Replace DOMAINSVR with the name of a domain controller in the joined domain.
  • Replace DOMAIN\USERNAME with an account with the rights to change the computer password – generally a domain admin account.

Your output should look something like this (insert the correct server and user):

netdom.exe resetpwd output

Note that it will ask you for that domain user’s password, so have that handy.

Once you reboot your computer, you should be set to log on – without that pesky “The Trust Relationship has Failed” message.

Note: This has been confirmed as working on Windows 7 (all versions) and Windows Server 2008 and 2008 R2. However, before trying this on a Windows Server Domain Controller, please see Microsoft’s Knowledge Base Article kb325850, as there are extra steps to be completed.

Like this post? Share it!