No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>


To have a better experience, please upgrade your IE browser.


0x404033C7 VDI issue VMs loosed their trust relationship with the domain

Publication Date:  2015-05-26 Views:  1703 Downloads:  21
Issue Description

VMs appeared to have lost their trust relationship with the domain.

Customer description bellow:

It did not seem possible to log onto the VM as a local admin to reconnect it to the domain as you would with a physical PC (it would only try to log into the domain)

The only way they have found is to delete the VM and make another one. But this is a bit impractical as there are a lot of VMs affected.

VMs appeared to have lost their trust relationship with the domain.


Let me share with you what I found rewarding this VM’s loose trust relationship accounts. 

Every domain computer has an AD computer account with an automatically generated password. Computer account passwords are used to establish secure channel communications between members and domain controllers and, within the domain, between the domain controllers themselves. Once it is established, the secure channel is used to transmit sensitive information that is necessary for making authentication and authorization decisions. The domain computer attempts to change its computer account password as specified by the setting for Domain Member: Maximum age for machine account password, which by default is every 30 days.

It is important to understand that this process is purely client-driven. A machine password does not expire in AD. Even if a machine never changes it the domain controllers will not complain about that as long as the presented password matches the copy stored in AD.

Now what happens if a machine is reset to a snapshot? The machine will then use the locally stored password that was valid at the time when the snapshot was created, although it might have changed it in the meantime. No matter how old the snapshot is: if the password stored in the snapshot does not match the current AD stored password then the machine's trust relationship is broken, and the machine has "dropped off the domain".
So let’s imagine the following scenario for a virtual machine:
1. The VM is joined to the domain. A computer password gets automatically generated and used to create the secure communication channel with the domain controller is established. The domain computer has a trust relationship with the domain controller.
2. A snapshot of the VM is created.
3. The VM is used, and eventually, the computer password gets changed after 30+ days, according to the default security policy. The new password is written in the differential file, after the snapshot.
4. The VM is reverted to previous snapshot: The differential file is deleted, and the VM will use its previous password when booting in the domain. The secure communication channel cannot be established anymore, and the trust relationship is lost.
One can attenuate this problem by raising the Maximum age for machine account password to something like 60 days (Registry, local policies, or GPO). Another radical workaround would be to enable the Disable Machine Account Password Change, what I don’t recommend because this would introduce an big security threat.

Another solution is a patch from Windows which you will find bellow:

The Managed Service Account (MSA) renews its password one time every 30 days. After MSA renews its password, the system starts to report NetLogon 3210 events, and the security channel connection to the domain controller is disrupted.

And Microsoft provided the KB2958122 to fix this.  So we would like to check whether this KB has been installed, could you please check whether the KB2958122 is in contained in the output of command “systeminfo”  ?
If no, we need install this KB for all the VM (it will be better to update the template).

Please see the attched pictures.