AD Troubleshooting: Trust Relationship between Workstation and 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 :) ).
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:
- 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.
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
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 resetpwd /server:DC_NAME /userd:USERNAME / password:PASSWORD
Follow below link which explains typical symptoms when Secure channel broken
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.
- start--->Run----->Adsiedit.msc
- Select Domain partition from the options
- Go the computer account where computer object exists.
- Right click on computer object------->Go to Properties---------->Attributes Editior
- Search for Service Principle name (SPN) name and check entry exists or not.(It consists of Service Class, Host, Port and Service Name )
- Format - <service class>/<host>:<port>/<service name>
- The <service class> and <host> are required. But the <port> and <service name> are optional.
- 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.
for more information can contact me in mohsen mottaghi