[FIX] The Trust Relationship Between This Workstation And The Primary Domain Failed (Windows 7)

One of my client computers running Windows 7 suddenly refused to logon because of a trust failure. For some strange reason, the domain trust relationship between the Windows Server 2003 primary domain controller and Windows 7 client failed. All accounts -including the domain administrator’s one- are denied access, and logging in becomes impossible because domain trust relationship failed. The system keeps displaying the following message:

The trust relationship between this workstation and the primary domain failed

In Active Directory, trusts  are authentication pipelines. Once this pipeline fails, your sysadmin won’t be happy at all…

The trust relationship between this workstation and the primary domain failed

You no trust me?

Now my Windows 7 client is locked. I tried with the local Administrator account but it was disabled hence no way to leave and rejoin domain in order to re-establish the domain trust relationship. Looks like Microsoft needs to update their Support Center article

What to do if Trust relationship Failed? How To Fix Domain trust?

You don’t need to modify any domain and trust settings on your server, the fix is really silly! The solution is to unplug the network cable before booting, this will bypass the trust failure limitation. Once logged in, replug the network cable. Simple, isn’t it? Now you can easily leave the domain, reboot and then join again the domain. This will restore the failed workstation trust relationship between the client and the server and the user account will be working again 😀

UPDATE: It looks that this is not the safest solution to restore trust relationship. Please have a look at Marco Schirrmeister comment below as he explains 2 alternatives fixes to solve this problem in a cleaner way.

Have you encountered this problem before? How were you able to restore the trust relationship between the domain controller and the Windows client? Let me know if you have other solutions for this problem.

PS:I found the solution on this blog, and one of the readers was kind enough to share the quick fix for this problem.

18 thoughts on “[FIX] The Trust Relationship Between This Workstation And The Primary Domain Failed (Windows 7)

  1. ClimbGuy

    Worked great! Thank you for this tip! Saved me lot’s of work!

  2. David Killingsworth

    Thanks so much for this fix.

    I was able to fix a Windows 7 Professional desktop with these instructions. In my case the connection was wireless and I switch off the physical wireless card switch on the Dell laptop and login to windows with domain credentials.

    I then changed the local admin account password to something that I knew (didn’t know what it was before).

    Left the domain, rebooted and logged in with the local admin account, and re-joined the domain.

    Rebooted again and logged in with a domain account.

  3. Marco Schirrmeister

    There are so many articles for this error and almost all talk about leaving the domain and rejoining the domain.
    So does also Pete’s link above.

    Honestly, when people search the internet for this trust relationship error they are looking for a real solution, a way of fixing it without rejoining the machine to the domain.
    I’m sure everybody would think or try this way without searching it.

    But this is just not an option. If you have many machines with that error it would just take to long.
    Second, chances are high that if the user logs in after rejoin, that he gets a new profile.
    Then you would have to copy all his files from the old to the new profile.

    Long story short, you can fix it quickly in a 2 “online” ways.

    1. Fix the following attributes in the “Attribute Editor” tab, in case they are empty or not like on a working one.

    2. Reset the computer object in ADUC.

    3. login with a local admin account to the workstation and run the following
    netdom resetpwd /s:ActiveDirectoryServerName /ud:Domain\Username /pd:*

    4. Reboot and you should be good to go.

    Send way.
    Click on “Network ID” in “System Properties” (run sysdm.cpl) and run through the wizard.

    Both this methods are discussed on some pages on the internet.

  4. Anonymous

    You ROCK! Excellent post! I owe you!


  5. bibian

    pls explain 2 m the relationship between the following domain problem,users, tools and solution

  6. David

    Marco Schirrmeister you are a feakin genius! Your suggestion of going through the “Network ID” wizard worked like a charm after 2 hours of frustration and nearly resorting to a dis-join/re-join, which I was not at all inclined to do since the clients medical practice software relies entirely on the user account it was installed under and as you said, the chances are high that if the user logs in after rejoin, that he gets a new profile. It would have been another 2 hours reinstalling and configuring that software. Thank you ever so much for the info!

  7. Gavin

    Why not just log into the local machine, then remove and re-add the computer from the domain. The user account will not be affected. It takes just a couple of minutes and it can be done remotely.

  8. Victor

    Does this stop it from happening again? or prevent it from happening to other clients on the network.

  9. Dennis Kambalame

    Ohhhh this was a real pain for me i couldnt disjoin remotely however with a little perseverance it all worked out. First make sure your remote host can be reached and the firewall is down temporarily. Ask the user to install a third party remote tool such as vnc or team viewer but real vnc worked best and log on remotely (using VNC of course). Whilst on the client ensure you can ping the Domain Controller. Disjoin the PC from the domian and change the computer name as well as in some cases this is what got you in this pickle in the first place. Rejoin..the PC and everyone is now happy…

  10. Stephen Berry

    Hmmm! I’m currently working for a business in the San Francisco Bay Area where one customer has been encountering this issue for the last couple of days on her Laptop.

    It turns out that when she moves from one location to another (we have an open workspace environment) and “Locks” her computer prior to moving about to another location, her PC is unable to get past the “Trust Relationship Issue.”

    Or so, I thought.

    A little trial and error produced the following:

    1) Switched to Different User and had Customer Log-on.
    2) next rebooted the Laptop and the User was able to log on.

    3) User next put the Laptop back into “Lock” mode and the “Trust Relationship” Issue re-appeared.
    4) Went back to Switch User, but this time had the User select the Icon stating that they were “logged-on”
    5) User was able to log back in normally.

    Does anyone know why “Lock”ing the Computer would have a different response than “Sleep” Mode or “Switch User” when attempting to reconnect to the Network.

    F.Y.I: A little more information. Client has 4 domain controllers that are shared among several thousand employees.
    Moving about the office environment across several buildings exposes the users to each of these domains and also can effect the response time (however small) for the user to log back into the corporate environment.
    At first we thought that is was an issue with communication with the Domain Controllers, but I would quickly learn with individual that is not the case. The issue is isolated the how the OS “Lock”s the computer.

Leave a Reply

Your email address will not be published.