Every now and then this particular issue creeps into the forums. A VM is reverted to a previous snapshot and domain membership is broken. Or a new VM is created using a base image that is domain joined. Or some other related scenario.
The first point to always remember is that a snapshot is a moment in time. When you revert to a snapshot you go back to that previous moment in time and all of the settings that were active at that point in time (as far as the OS in the VM is concerned).
This most commonly manifests itself with machines that are domain joined at the time the snapshot was taken, then the machine runs for a period of time, during this time the machine account password is changed. Thus when the VM is reverted to a previous snapshot the machine account password in the VM no longer matches the machine account password in Active Directory.
The machine is denied access to domain resources, but runs, it has a machine account in Active Directory. Nothing looks out of place until the access denied behavior is noticed either by users or through trolling Event Logs.
There is some good background information from the Directory Services blog about machine accounts and Active Directory that you can review here: Machine Account Password Process
There are two ways to deal with this situation:
- Un-join the VM form the domain, delete the computer account from AD, and then re-join the Domain.
- Prevent machine account password from changing prior to taking any snapshots: Disable machine account password changes
Keep in mind – the machine account passwords are designed to change silently in the background for a reason. To prevent an un-trusted, malicious machine from impersonating a trusted machine and thus gaining access to your domain. So don’t take changing this default behavior lightly. By modifying this default behavior you are making a conscious decision to increase risk and decrease security in your environment.
2 comments:
Please understand that I do not agree that machine account password changes should be disabled by default in virtualized environments.
This is a huge security risk as it opens the door to an untrusted machine account spoofing a trusted machine account and redices the overall security of the entire enterprise.
There are situations where these changes fit and there are situations where these changes do not fit.
In a previous life I did IT for a financial institution. We had IT audits once each year and that included hacking audits (both physical, social, and security) - it is very humbling to have a white hat hacker from an auditing company do through and comprimise your environment. And it is a far bigger learning experience to remidiate after such an audit.
Disabling machine account password changes has its place. And it works really well in test and development environments. However, in the enterprise is a totally different issue and should be considered for both its positive and negative impacts - and on an enterprise by enterprise basis.
Consiously reducing the security of your enterprise is a very serious thing that needs proper consideration.
Hi Brian. First I want to say that I love your work at the MS-forums ! You are a divine inspiration for me, and I hope that I will be an MVP for some day as you.
I also have a blog http://kristiannese.blogspot.com , but it`s in Norwegian, since there are not much tech-stuff available in that language. :-)
Early this year, we had the same behavior in our network, and had to do those steps in this blog. (re-joining the vm to domain and so on), but what caused the problem, was that the physical server who becamed a vm, was turned on by the UPS during a power failuer:) so we had 2 computers in our network with same name, IP + +. It took us almost a day to find out what was causing this behavior :) So now the physical server is placed in our stockroom, far from our datacenter.
Post a Comment