Fix – Trust relationship between workstation and primary domain has failed
Today I thought I would do a quick write up about something that has been annoying me for ages and a few months ago I finally found the fix!
Setting the scene
Imagine you have some virtualised machines that you want to regularly want to revert back to their original state when you have finished using them, without having to go through the pain of re-imaging the machine, etc.
The solution to this would be to use snapshots or non-persistent disks (in VMware) or similar functionality in Hyper-V or whatever other virtualisation platform you are using.
Can you imagine a use case for this? If not, think about something like a packaging reference machine, or even a test machine to test new packages. When you finished, you don’t really want to re-image, etc, etc. What a waste of time when you can use the tools built into your virtualisation platform to take care of this in a few minutes.
So what is the problem?
If you haven’t used this kind of set-up before then you maybe wondering….what is the problem you can have with this config? It sounds perfect 🙂
Well the ONLY problem with this configuration is that if you consistently revert back to your snapshot, eventually after a period of time the next time you go to use the machine you will not be able to log-on as a domain account because the trust relationship between the workstation and the primary domain has failed.
Why does the trust relationship fail?
The reason why this happens is because because believe it or not machine accounts on a domain have their passwords changed regularly. If you are like me, you would be thinking… I didn’t even know machine accounts had passwords!
Well, they do and they change… every 30 days actually.
So you can start to see the problem now… if you snapshot (or non-persistent disk) has been configured more than 30 days ago, then when you revert to it, next time you use the machine, you will get the trust relationship failed error because the password on the domain and the password on the workstations are different.
The fix
The simple solution is… disable automatic machine account password changes.
To do this you need to complete the following:
- Run
regeditas administrator - Navigate to
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters - Modify the
DisablePasswordChangeentry in the right hand pane - Change the value of the entry from
0to1 - Click OK to save changes
- Sit back and enjoy your handy work
More Info?
If you want more info on this then check out this Microsoft knowledge base article >> How to disable automatic machine account password changes
Enjoy!
Luca
Hi it’s worth mentioning that you should only be doing this on computer objects that you are testing on and need to be able to roll back – if you stop the password from being changed then the it becomes more difficult to detect moribund computer accounts and of course the reason the password changes are so that someone cannot compromise your domain by using a brute force attack against the password. Granted it’s only a computer object but it’s still an additional risk and an attack surface that you do not need to expose.
Hi Lee, thanks very much for the comment, and I totally agree with you 100%. This solution is only for testing machines and really only virtual machines that you want to roll back to a previous snapshot or that you have set the disks to non-persistent, so that when the VM is powered off all the changes are lost. Luca
Hello guys,
Found your site and was hoping you could help me with the following situation :
I work for a large corporate and we use windows 2008 R2 and windows 7 enterprise as the client ( actuall harware with windows 7 on it, so no VM’s).
These users also get the exact same error Trust relationship between workstation and primary domain has failed.
My question is can i apply your fix on the local clients ? or is it not safe to do so ? if not do you perhaps have a solution ?
Many thanks
Marv
Hi Marv,
I wouldn’t advise that you use this solution on the client machines, not only because of potential security risks, but also because you will just be covering up a bigger problem which should actually be fixed.
Not knowing the details of your environment, I can only speculate… but I would say the reason why you are having this issue is most likely because of a time synchronisation issue between the clients and the domain controllers. Have a look at one of the workstations with the problem, and use the w32tm tool in command prompt to look for time sync issues. For more information in regards to w32tm >>> http://technet.microsoft.com/en-us/library/w32tm.aspx.
Hope this helps.
Thanks
Luca
http://social.technet.microsoft.com/wiki/contents/articles/9157.troubleshooting-ad-trust-relationship-between-workstation-and-primary-domain-failed.aspx
this article provide more information on this topic.
Thanks Xunyang