Sign up ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

A client of ours has a DC that will be located in an insecure location. RODCs and separate domains/forests are not permitted by management.

All the servers will be located on a VMWare ESX server.

I'm interested in VMWare, Windows, AD configurations and settings that will protect a Windows 2008R2 or newer DC from compromise.

One example configuration that might help is to use

  • Bitlocker encryption
  • Any VMWare TPM-based solutions
  • Removing NTLM hashes (which are easier to crack) from AD.
  • Etc.
share|improve this question
Why are RODCs not permitted? –  EEAA Jun 20 '14 at 15:37
Who controls the ESX host-- your Customer or some hosting provider? –  Evan Anderson Jun 20 '14 at 15:37
We control the ESX host. Why aren't they permitted? Because the company has had an organizational history of DC issues, poor AD replication, and other issues they blamed the RODC. The overworked short staff is preventing me from proposing RODCs with a corresponding test & monitor procedure guide that would fix the issue. (They don't want anything else to test or monitor) –  LamonteCristo Jun 21 '14 at 12:19

3 Answers 3

This is pretty much exactly what the RODC was designed for - situations where the server might be physically compromised.

Gaining physical access to an RODC will give an attacker a good bit of insight into your domain and its structure, as well as password hashes of users that have explicitly been set to have their password replicated to the RODC.

However, this is much better than a regular DC, where physical access means the attacker can easily gain control of the domain with no additional credentials; one-way replication on the RODC ensures that an attacker can't send malicious changes into your AD.

RODC is the solution you're looking for, and you should make that case to management.

share|improve this answer
I suspect that sooner or later someone will learn how to force-promote an RODC to a PDC. Just because it can't be done now ... –  joshudson Jun 20 '14 at 21:12
@joshudson Well, the trick of it is that the one-way nature of the replication is enforced by the other DCs, not the RODC itself; nothing done on the RODC should be able to change that. But, of course, if a domain admin's password hash was replicated to the RODC, that gives the attacker means to get at the other DCs as well. –  Shane Madden Jun 20 '14 at 22:11
If it can validate passwords it can erroneously validate the domain admin password good enough to fool everybody but another DC. If it can hand out kerberos tickets it might even fool the PDC. –  joshudson Jun 21 '14 at 22:06
@joshudson See here. The RODC uses a different krbtgt account and password than the KDC on a writable domain controller uses when it signs or encrypts ticket-granting ticket (TGT) requests. This provides cryptographic isolation between KDCs in different branches, which prevents a compromised RODC from issuing service tickets to resources in other branches or a hub site. I'm not saying that these protection mechanisms are bulletproof, but MS definitely thought of these things when they were building the feature. –  Shane Madden Jun 21 '14 at 22:21

Speaking as someone who was once forced to put a server (not a DC, fortunately) in an unairconditioned closet with the door tied open, a hole in the ceiling through which one could see sky, and foot traffic walking by, I'm curious as to how insecure the location is. If they can hoist your server onto a shoulder and walk out in the middle of the day, there's not a lot you can do.

It looks like you're wanting suggestions like Spencer's--and those are all good--but I think that, rather than a technical solution, you need to either convince management to use a RODC or convince management to put the DC somewhere more secure. Perhaps this presentation from DefCon 21 will help:

So You Think Your Domain Controller is Secure?


Domain Controllers are the crown jewels of an organization. Once they fall, everything in the domain falls . Organizations go to great lengths to secure their domain controllers, however they often fail to properly secure the software used to manage these servers.

This presentation will cover unconventional methods for gaining domain admin by abusing commonly used management software that organizations deploy and use.

Justin Hendricks works on the Office 365 security team where he is involved in red teaming, penetration testing, security research, code review and tool development.

share|improve this answer

I would tend to agree with Shane, this is exactly why RODC exists. What is managements reasoning to prohibit the usage of a RODC? It's just such a bad idea to put the brains of your organization in an insecure location.

As for BitLocker, its a good idea, but it doesn't look like its supported. I would suggest using TrueCrypt FDE (Full Disk Encryption) inside the VM. This replaces the boot-loader and forces you to enter a password in order to boot.

What other services is this server going to run? I would definitely suggest using some sort of log collection service and audit alerts that you see fit. Maybe logon attempts?

The other consideration is how do you protect the actual ESX host, because as far as I know, there is no way to actually access the VMs from the ESX host's console. So, if the disk is encrypted, its like an attacker is on your network and only has the same visibility to your PDC. Which means probably different VLans and only certain ports opened.

share|improve this answer
BitLocker is unsupported on VM's, but there are articles describing how it can be used. However, it would much better to a RODC. It would be a strange choice to not allow RODC's and to allow an unsupported method of running VM's. On the TrueCrypt suggestion, that is almost certain to be unsupported by Microsoft. –  John Auld Jun 20 '14 at 16:44
Great article, looks like the way to go if doing FDE. I suggested TrueCrypt due to the TPM issue on VMs, but with the ability to enable BitLocker with only a password this seems like the easier method. –  Spencer5051 Jun 20 '14 at 17:09
"WARNING: Using TrueCrypt is not secure as it may contain unfixed security issues" (TrueCrypt project web site) –  the-wabbit Jun 20 '14 at 18:53
It is most likely the TrueCrypt warning is coerced by NSA and not real. –  joshudson Jun 20 '14 at 21:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.