Keeping virtual Domain Controllers apart on trusted VMware vSphere hosts

Virtualizing Domain Controllers

Virtualizing Domain Controllers introduces risks that are not present when running non-virtualized Domain Controllers. Two of these problems –running Domain Controllers on hosts with the wrong time and running all Domain Controllers on the same host –can be addressed with one VMware vSphere feature: VM/Host Rules.

 

Additional challenges when running virtualized Domain Controllers

We’ve already addressed a couple of the challenges with running virtualized Domain Controllers in previous parts of this series; Sizing Domain Controllers correctly, Managing Active Directory Time Synchronization and taking into account the Active Directory Virtualization Safeguards with VM-GenerationID.

Time synchronization in large environments

However, taking care of proper time synchronization for VMware vSphere hosts is a big task in environments with hundreds of hosts. All it takes is one vSphere host that is incorrectly configured; When the Domain Controller with the Primary Domain Controller emulator (PDCe) Flexible Single Master Operations (FSMO) role lands on it, it can skew time in the entire Windows networking environment.

vSphere hosts may run all over the world and there is no time to check all hosts regularly for compliance with the time server settings on all of them. It doesn’t really matter when a Domain Controller in a subdomain somewhere has the wrong time for a little while, as it will synchronize its time back with the Domain Controller holding the PDCe FSMO role in the root domain after a short while after having been vMotioned, rebooted or have had its VMware Tools service restarted.

Domain Controllers running on the same host

You don’t want all Domain Controllers running on one host or be pinned to one vSphere host, either. When a host goes down, the Domain Controller on it goes down with it, strangling along DNS and LDAP in most environments. In a vSphere cluster with DRS, the Domain Controller will eventually be started up on a different host, but the damage may already be done by that time…

Also, when all Domain Controllers go down together with one vSphere host, you might have a hard time connecting with Single Sign-on to the vSphere Web Client, connecting to storage or even signing in, because a lot of services purposely get integrated with Active Directory. What services? Indeed, you might not even be able to locate them on the network because DNS will be absent in most networks, too…

 

What Active Directory needs

What admins need from virtualized Domain Controllers is:

  1. Secure placement on certain vSphere hosts with known good configuration.
  2. When an vSphere host goes into maintenance mode, we want virtualized Domain Controllers to move to an vSphere host with known good configuration, but without running any of the other Domain Controllers. Ideally we’d want n+1 hosts for n Domain Controllers, but for some implementations, like dedicated and separate Active Directory implementations, other values might make sense.
  3. Domain Controllers running on different vSphere hosts, so a defective host does not cause the unavailability of the entire Active Directory functionality.
  4. The least amount of administrative burden on admins for making sure Active Directory is always configured correctly according to the above rules of thumb.

The above can be achieved through VM/Host Groups and VM/Host Rules in VMware vSphere. You don’t really need a non-virtualized Domain Controller when you meet the requirements and implement VM/Host Rules correctly.

 

Getting ready

To set up the configuration, you’ll need:

  • VMware vSphere Enterprise Plus licenses to gain Distributed Resource Scheduler (DRS)
  • A VMware vSphere cluster with vMotion and DRS enabled, consisting of at least three vSphere hosts
  • An Active Directory domain with at least two virtualized Domain Controllers running on the above vSphere cluster

 

Configuring

To configure the VM/Host Rules, we first need to create the appropriate VM/Host groups.

We’ll create a VM/Host Group for the virtualized Domain Controllers that we won’t to be available and we’ll create a VM/Host Group for the vSphere Hosts that we want these Domain Controllers to land on:

  • Start the vSphere Web Client and sign in with an account that has administrator permissions on the cluster.
  • At the top of the left navigation bar, click on the Hosts and clusters icon.
  • In the left navigation menu, expand the nodes to get to the cluster and select it.
  • In the main pane, in the navigation menu, expand the Configuration node.
  • Select VM/Host Groups.

vSphereClusterVMHostGroups1

  • Click + Add… to add a VM/Host Group for the virtual Domain Controllers.
    The Create VM/Host Group modal screen appears.
  • Next to Name: type a name for the VM/Host Group, for instance Domain Controllers.
  • Click + Add… to add the virtualized Domain Controller in the cluster.
    The Add Group member screen appears.
  • Select the virtualized Domain Controllers.
  • Click OK when done.
    You’ll be back in the Create VM/Host Group modal screen:

vSphereClusterVMHostGroups2

  • Click the OK button to create the VM/Host Group.
  • Back in the VM/Host Groups menu, the VM/Host Group we created is now selected.
  • Now, click + Add… to add a VM/Host Group for the vSphere hosts we want to run these Domain Controllers.
  • Next to Name: type a name for the VM/Host Group, for instance Special Hosts.
  • Change the Type: from a VM Group to a Host Group.
  • Click + Add… to add the hosts you want to run the Domain Controllers.
  • Select the hosts.
  • Click OK.
  • Back in the Create VM/Host Group modal screen, click OK too.
  • In the vSphere Client, in the navigation menu for the cluster, click on VM/Host Rules, right below VM/Host Groups.
  • Click + Add… to add a VM/Host Rule.
  • Next to Name: type a name for the VM/Host Rule, for instance Run Domain Controllers on Selected Hosts.
  • Next to Type change the rule from Keep Virtual Machines together to Virtual Machines to Hosts.
  • Select Domain Controllers, Must run on hosts in group, and Special Hosts:

vSphereClusterVMHostGroups3

  • Click the OK button to create the rule.
    Now, Domain Controllers will be run only on the selected hosts and not on any other hosts in the cluster.
  • Click + Add… again, to create a second rule.
  • Next to Name: type a name for the VM/Host Rule, for instance Keep Domain Controllers apart.
  • Next to Type change the rule from Keep Virtual Machines together to Separate Virtual Machines.
  • Click + Add… to add the virtualized Domain Controllers.
    The Add Virtual Machine modal screen appears.
  • Select the virtualized Domain Controllers.
  • Click the OK button when done.
  • Click OK again, to add the second VM/Host Rule.
    Now, Domain Controllers will be kept separately on different vSphere hosts, but only on the selected hosts and not on any other hosts in the cluster.

vSphereClusterVMHostGroups4

  • Log out of the vSphere Web Client and close the browser.

 

Concluding

Virtualizing Domain Controller introduces additional risks in terms of integrity and availability. These risks can be easily and automatically mitigated by using VM/Host Rules. There is no need to keep a non-virtualized Domain Controller if your vSphere implementation is licensed with Enterprise Plus licenses.

All you need to do is regularly audit the time synchronization configuration on the selected vSphere hosts that run the virtualized Domain Controllers.

Further reading

Using VM-Host Affinity Rules
How to Configure VMware Affinity Rules for DRS and Storage DRS
Securing Domain Controllers Against Attack

Series Navigation

<< Protecting virtual Domain Controllers on vSphere with VM EncryptionThree ways to use Site Recovery Manager with virtualized Domain Controllers >>

leave your comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.