If you have ever worked in a lab environment for any time period, VMware snapshots are a great feature to leverage for quick rollback and testing. As most of you already know, snapshots allow you to have a “picture” of a virtual machine (including even memory) at a particular point in time. If you keep snapshots on a server/workstation for any number of days and need to rollback, you may run into domain trust relationship issues after reverting the snapshot. In this post, we will see how you can effectively prevent domain trust relationship failed with snapshots in a lab.
What Causes Trust Relationship Failed Issues?
By design, a server/workstation that is joined to a Windows 2000 domain and higher, domain joined nodes will reset their computer password with the domain every 30 days.
This is behavior that happens in the background. You do not have to proactively perform this operation as it is carried out by the machine itself with the domain controller.
Now, think about the situation of running a snapshot on a server/workstation in a lab environment. If you create a snapshot for rollback purposes on a server and run on that snapshot for a period of 30 days or more, in the meantime, the server will change its password with the domain. Then, if you choose to rollback to the snapshot, you are essentially going back in time to the server thinking its password with the domain is the old password, unaware of the new password that has been issued with the domain.
After reverting the snapshot back in time and trying to login to your workstation/server, you will see the infamous: The trust relationship between this workstation and the primary domain failed.
It is easy to see the circumstances that lead up to the trust relationship being broken in a lab environment where you may be leveraging snapshots for various testing. Is there a way to prevent this behavior in a lab/testing environment?
Prevent Domain Trust Relationship Failed with Snapshots
In case you are not aware, up until looking into this, like me, you may not know there is actually a Group Policy setting that can be used to prevent the resetting of computer passwords in the domain.
The policy setting:
- Domain controller: Refuse machine account password changes
You can also use a registry setting on your domain controllers for this purpose. The registry key that can be set on your domain controllers:
- HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameter
- DWORD – RefusePasswordChange
- Create and set the value to 1
When the setting is configured on a domain controller, it will still receive the password change requests from the domain-joined server/workstation, however, as the name implies, it will refuse to reset the password. This will leave the domain join intact basically forever with the same password.
Disclaimer
Do not use this in production environments. This can present a huge security risk for an attacker to compromise your environment. This should only be considered with lab/dev/test environments.
Read fully the Microsoft explanation and implications of this setting here:
Rolling Out Refuse Password Change
You can easily roll out the RefusePasswordChange DWORD value with a simple registry file like below and sneakernet this to your DCs.
- Windows Registry Editor Version 5.00
- [HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters]
- "RefusePasswordChange"=dword:00000001
Use Ansible to Roll Out Refuse Password Change
For those that may want to automate this across a lab environment with many DCs, you can easily use something like Ansible to do the trick. You can create the registry key above with the following YAML code in an Ansible playboook:
- ---
- - win_regedit:
- path: HKLM:\SYSTEM\CurrentControlSet\Services\Netlogon\Parameters
- name: RefusePasswordChange
- data: 1
- type: dword
Final Thoughts
If you are like me and want to Prevent Domain Trust Relationship Failed with Snapshots in a Lab, you can easily do this with the referenced registry key or group policy setting for your domain controllers.
Lab environments present special challenges to infrastructure since often, they are rinse and repeat environments that require leveraging snapshots and other non-production mechanisms.
0 Comments