The trust relationship between this workstation and the primary domain failed

Error message

Error “Trust Relationshitp between Workstation and Primary Domain failed”, is the most encountered message when you are dealing with Active directory domain services ( This question is asked in TechNet Forum frequently too 🙂 ). <!–more–>


Common causes

What are the common causes which generates this message on client systems?

There might be multiple reasons for this kind of behaviour. Below are listed a few of them:

  1. Single SID has been assigned to multiple computers.
  2. If the Secure Channel is Broken between Domain controller and workstations
  3. If there are no SPN or DNSHost Name mentioned in the computer account attributes
  4. Outdated NIC Drivers.

Troubleshooting steps

How to Troubleshoot this behaviour ?

Above I have mentioned most common causes for this kind of message on client systems. I will explain how to troubleshoot these below.

Single SID has been assigned to multiple computers.

In most of the scenarios, when a client system’s operating system is installed from a clone/snapshot/image then this result will be encountered. (As in case of cloning/snapshot/image Separate SID will not be assigned by default, They make use of the SID of the system from which the clone/snapshot/image is prepared. i.e Single SID on two machines). If this is the case, we will have to make use of sysprep tool to prepare the image/clone/snapshot which will assign separate SID to each machine.

Resolution

Refer Below links which explains how to use Sysprep to change the SID

http://www.techrepublic.com/blog/window-on-windows/how-do-i-change-the-sid-and-computer-name-of-a-cloned-virtual-machine/736  
http://www.brajkovic.info/windows-server-2008/windows-server-2008-r2/how-to-change-sid-on-windows-7-and-windows-server-2008-r2-using-sysprep/ 

The Machine SID Duplicate Myth (Why Sysprep matters).

http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx 

If the Secure Channel is Broken between Domain controller and workstations

When a Computer account is joined to the domain, Secure Channel password is stored with computer account in domain controller. By default this password will change every 30 days (This is an automatic process, no manual intervention is required). Upon starting the computer, Netlogon attempts to discover a DC for the domain in which its machine account exists. After locating the appropriate DC, the machine account password from the workstation is authenticated against the password on the DC.
If there are problems with system time, DNS configuration or other settings, secure channel’s password between Workstation and DCs may not synchronize with each other. 

A common cause of broken secure channel [machine account password] is that the secure channel password held by the domain member does not match that held by the AD. Often, this is caused by performing a Windows System Restore (or reverting to previous backup or snapshot) on the member machine, causing an old (previous) machine account password to be presented to the AD.

Resolution

Most simple resolution would be unjoin/disjoin the computer from the domain and rejoin the computer account back to the domain.
(this is a somewhat similar principle to performing a password reset for a user account)

Or.

You can go ahead and reset the computer account using netdom.exe tool (http://support.microsoft.com/kb/216393  )

netdom reset ‘machinename’ /domain:’domainname

Follow below link which explains typical symptoms when Secure channel broken

http://blogs.technet.com/b/asiasupp/archive/2007/01/18/typical-symptoms-when-secure-channel-is-broken.aspx  

If there is no SPN or DNSHost name mentioned on the Computer account attribtues

Service Principle name and DNSHost name has to been mentioned on each computer account in active directory, If they are missing they will result into “Trust Relationship” error message.

Resolution

To check the SPN and DNSHost name, do this on the domain controller.

1.start—>Run—–>Adsiedit.msc
2. Select Domain partition from the options
3.Go the computer account where computer object exists.
4. Right click on computer object——->Go to Properties———->Attributes Editior
5.Search for Service Principle name (SPN) name and check entry exists or not.(It consists of Service ClassHostPort andService Name )

Format – <service class>/<host>:<port>/<service name> 
The <service class> and <host> are required. But the <port> and <service name> are optional.

6. Check out for DNSHost attribute as well. Make sure it also exsists with an entry .

Format – Computername.Domainname.com (Eg – Y12345.contoso.com)

Outdated Drivers.

This cause is very rare. You can check the NIC Drivers from computer management on the Computer and update if they are old.

Hope this will clarify to understand why “Trust Relationship between Workstation and Primary Domain failed” occurs on client systems when users try to login to the computer with their Credentials.

——————————–

Next, we solve the problem by resetting the Computer password in Active Directory and on the Local machine, for this we use a PowerShell CMDlet called Reset-ComputerMachinePassword. Type in the following command:

Reset-ComputerMachinePassword -Server <Name of any domain controller> -Credential <domain admin account>

In my environment it looks like this:

PSMethod2

Hit Enter, you will then be prompted for the Domain Administrator accounts password

PSMethod3

Type in the password and hit OK. It will take between 2 to 10 seconds to complete Yoy will then, if everything works, see this:

PSMethod4

Yup, nothing overwelming like ‘Succeeded’ or OK…just the released prompt. It is a success though 🙂

Now, we have to do one more thing before order is restored completely, we have to reboot the server. If you don’t, you will still not be able to logon using the domain account.

Use PowerShell…

Reboot

Or the GUI if you prefer

Advertisements