Active Directory in Hyper-V environments, Part 5

Designing and implementing a virtual environment on top of Hyper-V can be challenging. In the first four parts of this series I looked at the design choices and management actions regarding Active Directory in Hyper-V environments. Jorge made some interesting points as well, but one Active Directory best practice still remains to be tackled:

Physically secure all domain controllers in a locked room.

In this part I’ll look into the possible ways of securing virtual Domain Controllers running on top of Hyper-V, besides the apparent open doors written by John Gilham:

  1. Using NTFS rights and auditing on the virtual host
  2. Using Encryption File System (EFS) on the virtual host
  3. Using BitLocker Drive Encryption
  4. Using syskey.exe


NTFS rights

To secure files on a server one would normally look at NTFS rights. For Hyper-V security the same approach is valid, but one should know which accounts to give access to what data.

Let’s first look at the data. Two pieces of information define virtual machines on a Hyper-V virtual host:

  • Configuration Information
    This information contains the rights management within the Hyper-V Manager and contains information on each virtual machine. The files in this location are small. The configuration files are typically stored in:C:\Program Files\Microsoft\Windows\Hyper-V
  • VM configuration and hard disks
    Virtual hard disks contain the information stored on the hard disks within the virtual machine. Snapshots are virtual hard disks that are used as differencing disks when  you use the snapshot functionality in Hyper-V. Virtual hard disks and snapshots are stored in the same folder. These are big files. This folder is typically located at:C:\Users\Public\Documents\Hyper-V\Virtual Hard Disks

As a security measure you should move the default location where the above information is stored to another location. This can be done in the Hyper-V Management Microsoft Management Console (MMC).

In a Hyper-V environment the following accounts should be given access to the above locations:


Location Account NTFS Rights
AdministratorsSYSTEM Full Control
(This folder, subfolders, and files)
Full Control
(This folder, subfolders, and files)
VM Hard disks
AdministratorsSYSTEMCREATOR OWNER Full Control
(This folder, subfolders, and files)
Full Control
(This folder, subfolders, and files)
Full Control
(Subfolders and files only)


All other accounts should be given as limited NTFS rights as possible.

The above NTFS rights of course need to be audited. For this use the following high level steps:

  1. Log in as an administrator on the hyper-V virtual host.
  2. Right click on the location where either the Hyper-V configuration information or the VM hard disks are stored and right-click the folder. Select Properties.
  3. Click the Security tab, and then click the Advanced button.
  4. Click the Auditing tab.
  5. Click the Add button to make the Select User, Computer, or Group dialog box display. Add the administrators group and SYSTEM account.
  6. The Auditing Entry dialog box displays. Specify the type of access you want to audit using this dialog box. Next to the access right, select Failed, and then click OK.
  7. Click OK to close the Properties dialog box

Also, be sure to check your auditing settings afterwards…


Encryption File System (EFS)

Back in the Virtual Server 2005 days Microsoft advised to use the Encryption File System (EFS) to secure virtual hard disks on the disk of the virtual host. While this meant the performance of the virtual machine would diminish with roughly 5%, it was a good security measure. This practice was dropped by Microsoft for Hyper-V, quoting Mert Biyiklis blog:

Microsoft specifically advices not to use Encryption File System (EFS) with Hyper-V.

Hyper-V does not support the use of storage media if EFS has been used to encrypt virtual hard disks. More information can be found here.


BitLocker Drive Encryption

BitLocker Drive Encryption can be used to encrypt the contents of the entire hard disk of a Windows installation, except certain boot files, stored on a dedicated boot partition. This feature is currently available in some versions of Windows Vista and Windows 7 and of course in Windows Server 2008 and Windows Server 2008 R2.

BitLocker is an excellent method to encrypt virtual machines, but only from the virtual host itself. Quoting the Hyper-V security guide:

Use BitLocker Drive Encryption in the Hyper-V management operating system only. Do not run BitLocker Drive Encryption within a virtual machine. BitLocker Drive Encryption is not supported within virtual machines.

To enable BitLocker Drive Encryption on a virtual host, make sure to read the post by Jesper Johansson on enabling BitLocker on an existing computer. It involves creating a separate primary partition, making it bootable, booting from it and then turning encryption on. Once you’ve succesfully encrypted your system drive, you can encrypt any other partitions or volumes on which you’ve stored your configuration information and/or virtual hard disk files.

A further note should also be picked up from Microsoft Knowledgebase article 947302 regarding using BitLocker Drive Encryption in Failover Clustering scenarios:

Volumes that are encrypted by BitLocker are not supported in a clustered environment in Windows Server 2008.

This means you can’t encrypt volumes, containing highly available virtual hard disks in a Hyper-V Failover clustered environment…



The System Key Utility (syskey.exe) is used in old skool (non-virtualized) situations to secure account data on disk. On non-Domain Controllers the passwords in the Security Account Management (SAM) database are further encrypted. On Domain Controllers the passwords in Active Directory data are further encrypted, using stronger encryption algorithms beyond the default algorithms.

Syskey uses an encryption key. This key can either:

  • be stored on disk (server generated, default)
  • be a system boot password (configured by the administrator)
  • be stored on a floppy and needed at boot time (server generated)

Inside the Virtual Domain Controller

Using one of the first two options inside your virtual Domain Controllers results in a situation that isn’t really useable from a security point of view. Remote Server Management and automated Patch Management will need extra procedures, where an admin on a remote location might need to have the password or floppy to reboot the machine when needed.

Syskey on disk

When using the System Key Utility (syskey.exe) with a server generated password on a virtualized Domain Controller disk it becomes harder to retrieve passwords from the Active Directory, when it’s turned off. However, the virtual disk can be taken from a virtual host and brought online on any other Hyper-V environment. One of the most commonly used attack vectors can’t be stopped using this System Key Utility scenario.

Syskey floppy

Hyper-V can’t work with hardware floppies, so the floppy needs to be virtualized and optionally inserted. A virtual floppy can be used, but needs to be stored on the virtual host and needs to be inserted using the Hyper-V Manager. Both require an administrative role being given to someone you might not want to give it to. Storing it besides the virtual hard disk then again is simply security by obscurity.

Syskey password

A boot password is a good security measure, when implemented correctly. Since a virtual Domain Controller can present its password screen at boot time, only procedures needs to be in order to facilitate remote server management and patch management.

The challenge using the System Key Utility (syskey.exe) inside your virtual Domain Controller is now evident. When used properly it can add an additional layer of security. If used improperly it results in hassle and weaknesses.

On the virtual host

Using the System Key Utility (syskey.exe) inside your virtual host doesn’t offer the multitude of options.

Syskey floppy

The floppy drive option requires an administrator at a remote location to have the floppy or leaving the floppy in the virtual host itself.

Syskey password

The boot password requires an administrator at a remote location to know the boot password. Unless you’re using advanced remoting hardware and software like iLO, DRAC, etc you won’t be able to remotely access the boot screen. Adding another person to your inner circle of trust most often results in scenarios you’d want to avoid with these kinds of persons.

Syskey on disk

The server generated password on disk is something you could implement, though. The scenario doesn’t require local access to the virtual host(s), while adding at least a layer of defense against network attacks.



It should be imperative you should not let unauthorized, incapable and unknown persons anywhere near your domain controllers. Implementing this best practice in a Hyper-V environment though isn’t as easy as it seems.

To secure Active Directory Domain Controllers in a Hyper-V environment, use the following techniques:


Security Measure

Virtual Host

Virtual Guest
(Domain Controller)

NTFS rights and auditing



Encryption File System (EFS)



BitLocker Drive Encryption

(Unless clustered)


System Key Utility (syskey.exe)

(Disk based)

(Disk, password based)


*  A default installation of Active Directory on a Windows Server further restricts user rights
on the file system and the registry, compared to a default Windows Server installation.

Further reading

Active Directory Best practices
VDI Security – Using Encryption to Protect Virtual Machine Resources
Download details: Hyper-V Security Guide
Hyper-V Step-by-Step Guide: Hyper-V and Failover Clustering
Virtual PC Guy's WebLog : Whitepaper: Hyper-V and BitLocker
[DOC] Windows Server 2008 Hyper-V and BitLocker Drive Encryption
Windows BitLocker Drive Encryption Step-by-Step Guide
Hyper-V Security Best Practice: Use BitLocker
BitLocker and Hyper-v
Volumes that are encrypted by BitLocker are not supported in a clustered environment
Q. Does Hyper-V support Windows BitLocker Drive Encryption running … – Windows IT Pro
Planning for Hyper-V Security
How to use the SysKey utility to secure the Windows Security Accounts Manager database
Windows NT System Key Permits Strong Encryption of the SAM
Cracking Syskey and the SAM on Windows XP, 2000 and NT 4 using Open Source Tools   What happens when syskey is installed, and how to get rid of it
Protecting the SAM with Syskey

Series Navigation

<< Active Directory in Hyper-V environments, Part 4Active Directory in Hyper-V environments, Part 6 >>

leave your comment

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