Tthe trust relationship between this workstation and primary domain failed

Quick Fix

Log on locally as a local administrator. In the Network tool of Control Panel, select Change and enter a Workgroup name, leaving the domain. Restart the computer and log on locally as a local administrator.

Rejoin domain again.

Why this happens?

The underlying problem when you see this error is that the machine you are trying to access can no longer communicate securely with the Active Directory domain to which it is joined.  The machine’s private secret is not set to the same value store in the domain controller.  You can think of this secret as a password but really it’s some bits of cryptographic data called a Kerberos keytab stored in the local security authority.  When you try to access this machine using a domain account, it fails to verify the Kerberos ticket you receive from Active Directory against the private secret that it stores locally.

I think you can also come across this error if for some reason the system time on the machine is out of sync with the system time on the domain controller. This solution also fixes that problem.

This problem can be caused by various circumstances, but I most commonly run into it when I reset a virtual machine to a system snapshot that I made months or even years before.  When the machine is reset, it is missing all of the automatic password changes that it executed against the domain controller during the intervening months.  The password changes are required to maintain the security integrity of the domain.

Possible Causes

Found some useful suggestions on the internet what is causing this issue. I haven’t implemented them yet, so use at your own risk. I just wanted to pass along.

1. Some people believe that there is an issue with an imaging process, creating duplicate SIDs. Sysinternals used to have a tool called “NewSID” but it was retired a couple of years ago. Here’s a blog post on it:
http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

2. Others believe the issue may be a corrupt group policy that is being applied. Testing this would of course be extremely time consuming. However, there may be an easy fix for the computers when a problem actually occurs.
a. GPEdit.msc
b. Computer Configuration  Windows Settings  Security Settings  Local Policies  Security Options
c. “Network Security: Configure encryption types allowed for Kerberos”
d. Check all of the boxes and reboot
Your mileage of course may vary.

3. One possible solution is making sure the “Provider Order” in network settings is set to “Microsoft Networks.” Here is a blog post on it:
http://dailyadminlife.wordpress.com/2011/08/05/the-trust-relationship-between-this-workstation-and-the-primary-domain-failed

4. Some people have been able to successfully re-enable the trust without leaving and rejoining the domain by running the “Join a Domain or Workgroup wizard.” I know this won’t fix the root cause, but it may keep it from happening again and it is an easier fix than having to rebuild local profiles.
http://windows.microsoft.com/en-IN/windows7/What-happened-to-the-Network-Identification-Wizard
NOTE: You may need to unplug the machines from the network to use the cached credentials first.

5. Symantec and other anti-virus solutions may be the problem, but obviously this creates its own security issues if you have to disable them.

6. You can disable the machine account passwords as instructed per your Microsoft ticket. Most people believe that removing the passwords won’t be a huge security risk, but it will however remove one layer of protection from the equation.

Hope you fixed it!

I hope this is helpful.  This problem comes up every few months for me and my colleagues, so I wanted to document it for my own use. It is difficult to find when you just search for the error you get in the login window.

Leave a Reply

Your email address will not be published. Required fields are marked *

For prompt technical support, please use our forum IntoFPV.com. I check blog comments weekly.