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–>
There might be multiple reasons for this kind of behaviour. Below are listed a few of them:
- Single SID has been assigned to multiple computers.
- If the Secure Channel is Broken between Domain controller and workstations
- If there are no SPN or DNSHost Name mentioned in the computer account attributes
- Outdated NIC Drivers.
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.
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.
Refer Below links which explains how to use Sysprep to change the SID
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.
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)
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
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.
To check the SPN and DNSHost name, do this on the domain controller.
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 Class, Host, Port 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)
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:
Hit Enter, you will then be prompted for the Domain Administrator accounts password
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:
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.
Or the GUI if you prefer