With the responses to our article series on virtualized domain controllers, it seemed natural to tackle another related topic. Unfortunately, it’s a little too common for administrators to try to solve the physical vs. virtual dilemma by installing the domain controller role and the Hyper-V role in the same physical instance of Windows Server. This is not good practice for a number of reasons.
I try to avoid using “never” or “always” when it comes to the technology world, but this is one situation where I think it’s appropriate. There’s probably never a great reason to have your Hyper-V hosts also be domain controllers. If you must have a physical domain controller, use some other computer. If you’re concerned about virtual domain controllers, read our series (linked in the intro paragraph). Now, let’s explore why such dual-purpose machines are a bad idea:
1. Domain Security
There’s always a concern that someone might compromise your hypervisor. If that happens, the attacker gains control over your virtual machines. That’s bad. If your hypervisor is also your domain controller, that means the attacker now controls your entire domain as well. That’s really bad.
Next, you might be asking, “If the attacker has compromised the hypervisor, then does it make a difference whether the domain controller co-resides on the parent partition versus being a guest on that system?” The answer is, yes, it does matter. Compromising the hypervisor is bad, there’s no question. But it’s also a bit limited. Hypervisors are built around the idea of partition isolation and many of those rules apply to the hypervisor as well. So, compromising upward from the guest to the hypervisor does not immediately mean easy access into other guests. Could it be done? Of course. Has it been done? Not that anyone knows of. To go around speculating on it is to wander into FUD territory. If you’re concerned, put your domain controller on a separate, physical unit. What I would do is keep externally facing (think public web servers) on separate Hyper-V hosts from critical guests, such as domain controllers.
A simpler way to phrase this concern is that it increases the attack surface for both of these roles. If an attacker knows the name of your system and can target Hyper-V or domain services, s/he gets the other in the deal.
2. No Support from Microsoft — or Almost Anyone Else
Microsoft only supports a handful of roles alongside Hyper-V, and domain services isn’t one of them. Some people think, “Well, so what? I never call Microsoft PSS anyway.” That doesn’t matter. The people that you’re likely to ask help of probably do. If they don’t, the people they look to probably do. The point is, the real experts out there don’t do this. Because they don’t do this, they don’t know the answers to questions about it. If you run into a problem, the only people you’re going to be able to talk to on the subject are also people who went against the grain. The community at large will largely shrug at your questions and go on to something else. Who ya gonna call?
3. Performance Impacts
When domain services are installed, one of the first things they do at boot up is disable all disk write caches. ALL disk write caches. If your domain controller is also your hypervisor, that means that all your VMs will lose write cache capabilities. Hello, needlessly long I/O queues.
The other side is that the hypervisor is prone to sacrificing itself for the needs of its guests whenever there is contention. If your system isn’t heavily laden, that might not be a big deal. Otherwise, your domain services may not be as responsive as you’d like. One thing that the hypervisor is not always great about is cutting up memory. If another process is able to get its hands on some, it can reserve it indefinitely in a way that keeps Hyper-V from assigning it to guests. Processes of that kind typically take a chunk of whatever available memory is on the system. Since we’re talking about a system running a hypervisor, that’s probably quite a lot. Conversely, putting it in a virtual machine gives you direct control over the maximum amount of memory it can possibly consume. The largest domain I ever managed had about 400 users, and I was able to DM virtualized 2008 R2 domain controllers below 768 MB RAM during normal daily operations. Would it have done the same had I installed domain services directly in the management operating system of machines with 128 GB of RAM? I don’t know (see #2).
4. Zero Licensing Benefit
One reason I’ve heard is that people don’t want to buy another license to cover domain services running in the guest. Well, if you run any service in a Windows hypervisor that provides services beyond virtual machine operation and maintenance, the management operating system must be fully licensed, meaning that you forfeit one of your Windows Server guest virtualization rights just by enabling domain services. So whether you run domain services in the hypervisor or as a guest, the licensing requirement is identical.
5. System Hardening Becomes Questionable
When you make a computer into a domain controller, computer-level security ceases to exist. This has some far-reaching consequences that a lot of people don’t think about.
First, there is no longer a local security accounts manager (SAM) or related database. So, there’s no such thing as a local account. In the series on virtualizing domain controllers, I pointed out that if your domain is damaged, you could still log on locally. Well, if your hypervisor is also a domain controller, that’s no longer an option. The “Hyper-V Administrators” group is created on machines with the Hyper-V role installed, but what happens when you do this on a domain controller (I don’t know, see #2). What I do know is that if it is created, it’s not local. It can’t be, because there’s no SAM.
One thing that systems administrators have done since time immemorial for local security is to add regular domain accounts to the local administrators group. This way, you can allow someone to destroy their computer without wrecking the domain. If you’re in a somewhat higher security context, you can do the same thing with your own accounts. For example, I have my own personal domain account that is an admin on my desktop. I have another domain account with high privileges and permissions. I use secondary logon (AKA Run As) for domain management. Guess what? You can’t really make that distinction on a domain controller, because there is no SAM (am I repeating myself?)
Group Policy is also a big concern. All domain controllers must exist in the default Domain Controllers OU or your domain will have problems. That means that if you want to apply any policies to your DC/Hyper-V system, you must apply them on that OU.
6. Backup and Recovery Becomes Messy
Active Directory backups can be done by protecting the System State on a domain controller. This is pretty basic information. But, when you start installing other invasive, critical services, the face of System State changes. Importantly, you don’t have many options for backing up the System State in a granular manner. You cannot restore one without affecting everything else that participates in System State. What happens if you need to perform an authoritative restore of domain services to two weeks ago? How does that affect Hyper-V when it’s installed with domain services? I don’t know (see #2). Maybe you think you can avoid this problem by just restoring the specific Active Directory database files and skipping the larger System State. This might be true, but it’s certainly not the supported way. It’s also not worth the risk.
The other thing I dislike about this is that it now forces you to back up the management operating system (because backups are not optional). Normally, I only worry about backing up virtual machines, because I can reinstall Hyper-V from scratch and have virtual machines operational in no more time than it would take to run a bare metal restore. Since I’m the PowerShell type, I can save the initial configuration of a Hyper-V host in a quick little .PS1 file instead of a big backup file, and go from new install to ready-to-run in very short order. But, if I’ve got domain services on there, now I need to come up with a backup. If I were to create a backup of a Hyper-V host, I’d be looking for the schedule option named “Every now and again”, because hardly anything ever changes at that level that I really worry about. In practice, I just care about backing up the virtual machines and their related files. But, if I throw domain services on there, now I have to care about backing up the management operating system.
7. DC Portability is Gone
Hey, it’s time to retire this physical host. Let’s just use Shared Nothing Live Migration to flip the domain controller over to the new host!
Oh, wait. The host is the domain controller. Darn. Add a couple more hours to the migration for configuration and testing of domain services.
Summary
It may be tempting to answer the virtual vs. physical domain controller question by just making your Hyper-V host a domain controller. Please, don’t do it.
More in this category
About the Author
Eric Siron
