Today, virtualization has taken over in just about every aspect of server architecture. For the most part organization look to virtualize just about any and every kind of server resource as long as there is no underlying reason to run it on bare metal hardware. A type of server resource that has always been shrouded in differing opinions when it come to virtualization is the domain controller.
Table of Contents
- Domain Controllers – To Virtualize or Not Virtualize?
- Hyper-V Cluster – Required for Production Environments
- Prevent Time Skew with Virtualized Domain Controllers
- Snapshots and USN Rollback conditions
- Virtualized Domain Controller Security Concerns
- Concluding Thoughts
Especially in earlier versions of Hyper-V where there was a “chicken and egg” scenario that could develop where you could not start Hyper-V host resources when domain controllers were down, there has been definite push back from running virtualized domain controllers.
- Does this situation still exist with Microsoft Hyper-V?
- What considerations need to be made with Microsoft Hyper-V when it comes to virtualized domain controllers?
Let’s take a look at Virtualizing Domain Controllers in Microsoft Hyper-V.
Domain Controllers – To Virtualize or Not Virtualize?
Much of the anxiety of virtualizing domain controllers comes from earlier versions of Windows Server where Failover Clusters (the technology that Hyper-V Clusters are built on) required that Active Directory be available for the Failover Cluster service to start. With this dependency, you can see the critical flaw in the architecture of running all your domain controllers in this type of environment.
If the Hyper-V Cluster went down for any reason, taking down all the domain controllers, your environment would be in the “chicken and egg” scenario mentioned in the outset. Without the availability of the Active Directory domain, the Hyper-V cluster could not start. Without the Hyper-V cluster starting, the domain controllers would not be available.
It is easy to see how this would be a bad situation to be in with virtualized domain controllers on a Hyper-V platform. However, with the introduction of Windows Server 2012, Microsoft removed the dependency for Active Directory to be available for the Failover Cluster service to start. This way, production Hyper-V clusters running production workloads, including domain controllers, would be able to start the Failover Cluster service. This would allow Hyper-V administrators to get the Hyper-V cluster backup and running and then be able to power on virtual domain controllers.
Read more information about the removed Active Directory dependency for Failover Clustering to start here: https://blogs.technet.microsoft.com/wincat/2012/08/29/windows-server-2012-failover-cluster-enhanced-integration-with-active-directory-ad/
Hyper-V Cluster – Required for Production Environments
As with any technology in production, you do not want to have a single point of failure with hardware. Never run a single Hyper-V host for running production workloads. This will lead to data loss at some point in the future. Imagine running your entire domain with multiple domain controllers on a single Hyper-V host. This is something that any sane Hyper-V administrator would never do, however, it illustrates the point. If you had all domain controllers on a single Hyper-V host and the host went down, the Active Directory domain would be taken offline as well, no doubt leading to serious infrastructure problems.
Running a Hyper-V cluster is not simply a production requirement for Active Directory, but for all other production resources running on top of Hyper-V. Hyper-V clusters allow taking advantage of the high availability mechanisms built into Hyper-V with the automatic restart of virtual machines running on a failed host to be automatically restarted on a good host left in the cluster.
Additionally, it is a very good idea to run virtualized domain controllers with anti-affinity rules in the Hyper-V cluster so that all domain controllers are not backed by the same host in the cluster. This ensures that any failed host would not take down all the domain controllers in the Active Directory environment even for a short period of time until the high availability mechanisms kick in.
There is a great PowerShell script on the Technet Gallery that shortcuts setting up the Anti-affinity classes to easily configure the Anti-affinity rules that can be used for virtual machines such as for virtual domain controllers.
Take a look at the script here: https://gallery.technet.microsoft.com/Configuring-Anti-Affinity-b61d0ae4
Prevent Time Skew with Virtualized Domain Controllers
Domain controllers are typically the ultimate time source in a Windows Domain. Virtualized guest operating systems can potentially inherit time skew from the Hyper-V host. It is therefore recommended to disable time synchronization from the Hyper-V host on a virtualized domain controller. To do that, go through the following steps:
- Launch Hyper-V Manager
- Select the Virtualized Domain Controller
- Click Settings
- Click Integration services
- Clear the Time Synchronization option
- Restart the Virtualized Domain Controller
To configure an authoritative time server from an external source, Microsoft has a really good KB that shows how to configure an external source for the authoritative time.
https://support.microsoft.com/en-us/help/816042/how-to-configure-an-authoritative-time-server-in-windows-server
Snapshots and USN Rollback conditions
When virtualized domain controllers started to be utilized in production environments, there were many cases of administrators who were bit by the USN rollback with virtualized domain controllers when they mistakenly attempted to use “snapshots” on domain controllers. When snapshots were reverted, the domain controller entered a “USN rollback” condition and replication essentially breaks at that point.
What is a USN rollback?
Active Directory uses an Update Sequence Number or USN to track changes to its copy of the Active Directory database. The version of the database is tracked by an Invocation ID. When domain controllers communicate with one another for replication they reference these numbers to track which objects have been changed and need to be replicated. When a domain controller snapshot is restored, the domain controller is unaware of what just happened aside from a time shift. The domain controller will be able to communicate normally with clients and the other DCs, however, it will increment old USN numbers and use old invocation IDs. When other domain controllers connect to this DC with the reverted snapshot, they will see the old USN and Invocation IDs and will think all the changes have already been replicated. This will cause replication to fail.
In Hyper-V 2012 and later, a VM-Generation ID attribute (msDS-GenerationID) has been introduced that allows the hypervisor and the Integration services within the domain controller to track the IDs and prevent a USN rollback from occurring. An interesting note here, VMware also introduced support for this with vSphere 5.0 update 2 and vSphere 5.1.
With the introduction of the new attributed and a better understanding of the USN and Invocation ID, Hyper-V administrators can fairly confidently virtualize domain controllers without the added problems that can be introduced by USN rollback conditions. This functionality is only available however with Hyper-V 2012 and Windows Server 2012 domain controllers and higher.
Virtualized Domain Controller Security Concerns
There have been security concerns by many over virtualizing domain controllers. Many have cited that an attacker can gain access to and control a virtualized domain controller more easily than a physical domain controller or leverage another guest operating system running on the Hyper-V host to more effectively attack a DC.
Are these concerns real?
Let’s level set for just a moment.
Security is always a concern and any organization should make sure all environments are secured as much as possible. A skilled attacker can wreak havoc on a network whether resources are virtualized or physical. It is crucial that organizations always follow security best practices as a basic standard line of defense. This would include highly restricted network access and strong passwords and password policies.
Additionally, according to Microsoft’s resource, Securing Domain Controllers Against Attack, it is recommended that virtual domain controllers be run on separate physical hosts than other virtual machines. If System Center Virtual Machine Manager is used, you can delegate administration for the physical hosts on which the domain controller virtual machines reside and the domain controllers themselves to authorized administrators. Storage of virtual DCs should be separated as well for best security separation. In branch locations, consider using RODCs instead of writable domain controllers in addition to BitLocker encryption on hosts on which virtual DCs run.
Concluding Thoughts
As with any architectural decision, it is up to the organization and their specific business requirements and use cases to decide the best means to house resources. Virtualizing domain controllers however is a safe and supported practice from Microsoft for provisioning domain controllers.
Hyper-V provides great built in features and functionality to allow organizations to safely host their virtual domain controllers in a hypervisor platform. This includes failover clustering without domain requirements, time management, new attributes to alleviate concerns over USN rollbacks as well as security features that can be implemented to secure virtualized domain controller environments.
By always following Microsoft’s best practice recommendations, organizations, can successfully and safely implement domain controllers in Windows Server Hyper-V.
Related Posts:
Microsoft Azure Administrator: AZ-104: Microsoft Azure AD Join – Part 8
Follow our Twitter and Facebook feeds for new releases, updates, insightful posts and more.
