In the previous post in this series, we looked at Virtualization-based Security and how it may benefit virtualized Domain Controllers. However, VMware vSphere 6.5 and newer versions of vSphere, offer one more feature to virtualized Domain Controllers that you might want to look into from both an Active Directory as a Virtualization Platform management point of view: VM Encryption.

About VM Encryption

VM Encryption is a security mechanism that allows certain virtual machines to run on trusted hosts only. Trusted hosts are defined through encryption keys obtained from a KMIP 1.1-compliant Key Management Server (KMS) through manually enrolled vCenter Servers.

Two types of keys are used for encryption.

1. A vCenter Server requests keys from the KMS. These keys are used as the key encryption key (KEK) and are AES-256 keys. vCenter Server stores only the ID of each KEK, but not the key itself.
2. ESXi uses the KEK to encrypt the internal keys. These keys are used as data encryption keys (DEKs) and are XTS-AES-256 keys. ESXi stores the encrypted internal keys on disk. ESXi does not store the KEK on disk.

If a host reboots, vCenter Server requests the KEK with the corresponding ID from the KMS and makes it available to ESXi. ESXi can then decrypt the internal keys as needed.

VM Encryption encrypts the VM configuration files. The virtual machine gains access to the configuration files when it boots through the KEK, if it’s running on a trusted ESXi host. The ESXi host gains access to the KEK through the DEK that it requests from the vCenter Server. It is only able to do this, if vCenter Server grants it access.

If a virtual machine cannot read its configuration files, it won’t be able to power on.

You cannot associate an encrypted virtual disk with a virtual machine that is not encrypted.

Benefits of using VM Encryption

The benefits of using VM Encryption for virtual Domain Controllers are threefold:

• The virtualized Domain Controllers that are protected with VM Encryption are only able to run on trusted hosts.
• The virtual disks of the virtualized Domain Controllers that are protected with VM Encryption cannot be reused as disks for another virtual machine.
• Only administrators that have the highest permissions in vSphere are able to manage and access the virtualized Domain Controllers that are protected with VM Encryption.

Basically, VM Encryption delivers on the promise of virtualization, without the need to worry about VMDKs getting stolen.

The Key Management Server (KMS) itself can be an on-premises virtual machine, but it can also be a hosted highly-available service off-premises

VM encryption and DC Cloning

Virtualized Domain Controllers that are protected with VM Encryption can be cloned towards Domain Controller cloning. The clone inherits the parent encryption state including keys. You can encrypt the full clone, re-encrypt the full clone to use new keys, or decrypt the full clone. However, for Domain Controller clones, it’s fastest to perform a shallow re-encrypt while the virtual machine is powered on.

Drawbacks and non-benefits of using VM Encryption

VM Encryption does not necessarily entail encryption of the virtual disk. VM Encryption does not automatically enable BitLocker Drive Encryption, either.

Backend storage features such as deduplication and compression might not be effective for encrypted virtual machines.

Not all backup solutions that use VMware vSphere Storage API – Data Protection (VADP) for virtual disk backup are supported, because VADP SAN backup solutions are not supported with encrypted virtual machines. Backup solutions that take backups from within the virtual machine, like Veeam’s Agent for Windows, will be able to make unencrypted backups. These backups of encrypted Domain Controllers should be stored with the same level of information security measures as the Domain Controllers themselves.

Getting Ready

To use the VM Encryption functionality, you’ll need to meet the following requirements:

• At least one ESXi host running VMware vSphere 6.5, or up
• vCenter Server version 6.5, or up, managing the ESXi host(s) above
• A KMIP 1.1-compliant Key Management Server (KMS) like Hytrust’s KeyControl

Configuring VM Encryption

Configuring VM Encryption for virtualized Domain Controllers consists of the following steps:

• Enabling Hytrust KeyControl;s KMIP Service
• Creating a Certificate Signing Request from vSphere
• Creating a user certificate for VM Encryption
• Establishing the trust between the KMS and vCenter

Enabling Hytrust KeyControl’s KMIP Service

First, we need to make sure Hytrust KeyControl acts as the Key Management Interoperability Protocol (KMIP) 1.1-compliant Key Management Server that we need. Perform the following steps:

• Sign in to the Hytrust KeyControl web console with an account that has Security Admin privileges (the secroot account has these permissions, by default).
• Click on KMIP in the top navigation bar.
• Click the State drop-down box and change it to ENABLED.
• Click the Protocol drop-down box and change it to Version 1.1.

• Save the settings by clicking the Apply button at the bottom of the screen.
  A modal screen appears asking to Overwrite all existing KMIP Server settings?
• Click the Proceed button in the modal screen.

You will notice a new alert confirming the KMIP server is now started.

Creating a Certificate Signing Request from vSphere

To build a certificate trust relationship, we’ll start with creating a certificate signing request (CSR) from vSphere. That way, when we create the certificate at the Key Management Server, we can use the information in the CSR to populate the values. Perform these steps:

Note:
For this walkthrough, vCenter 6.7 was used.

• Start the vSphere Web Client and sign in with an account that has administrator permissions.
• In the left navigation pane, select the vCenter Server (Appliance)
• In the main pane, from the tabs, click the Configure tab.
• In the main pane, in the navigation menu, select the Key Management Servers node.
• Click ADD.
  The Add Key Management Server modal screen appears.
• Specify to create a new cluster or to add the KMS host to an existing cluster.
• Specify the name, address and port of the KMS Server.
• Click the OK button at the bottom of the modal screen to add the server and close the modal screen.
  The Make vCenter Trust KMS modal screen appears.
• Click the Trust button to trust the certificate of the Key Management Server and close the modal screen.
  The KMS host is now added to the list of Key Management Servers in vCenter. You can see it in the main pane, but in the Connection Status column, it will issue a warning Not connected (trust not established).
• In the main pane, select the Key Management Server from the list.
• Click ESTABLISH TRUST and then select Make KMS
  Trust vCenter from the context menu.
• The Make KMS trust vCenter modal screen appears.

• On the Choose a method screen, select the New Certificate Signing Request (CSR) option to submit a vCenter-generated CSR to the KMS then upload the new KMS-signed certificate to vCenter.
• Click the Next button.
• On the Submit CSR to KMS screen, click the DOWNLOAD button at the bottom of the certificate request to download it as a *.pem file.
• Click the DONE button.

Creating a user certificate for VM Encryption

For the connection between the vCenter Server and the Hytrust KeyControl implementation, we’ll create a new user certificate in the following steps, while still sign in to the Hytrust KeyControl web console:

• In the Hytrust KeyControl web console, while still in the KMIP section of the console, switch to the Client Certificates tab.
• From the Actions menu, choose the Create Certificate option.
  The Create a New Client Certificate modal screen appears.
• Provide a meaningful certificate name, for instance the name of the vCenter Server.
• Specify the previously downloaded certificate signing request (CSR) as the CSR.
• Provide a password for the client certificate twice.
• Click the Create button at the bottom of the modal screen to create the client certificate and close the modal screen.
• Select the newly created certificate in the main pane.
• Click Actions again. This time, select Download Certificate from the menu.

You now download a client certificate in *.pem format in a zip file. Be sure to extract the certificates from the *.zip file before you continue.

Establishing the trust between the KMS and vCenter

Now, we can create the connection between the KMS and vCenter. Perform these steps to do so:

• Switch back to the vSphere Web Client.
  It should still be at the Key Management Servers part of the Configuration of the vCenter Server. If not, navigate back to it.
• Select the KMS Host from the list of Key Management Servers.
• In the main pane, select the Key Management Server from the list.
• Click ESTABLISH TRUST and then select Make vCenter Trust KMS from the context menu.
• Click the Trust button at the bottom of the modal screen.
• Click ESTABLISH TRUST again. This time select Upload Signed CSR Certificate from the context menu.
  The Upload Signed CSR Certificate modal screen opens.
• Click the UPLOAD A FILE button.
• Select the *.pem file you downloaded from the Hytrust KeyControl implementation and click Open.
• Click the UPLOAD button at the bottom of the Upload Signed CSR Certificate modal screen to use this certificate and close the modal screen.

The Key Management Server should now show the Connected status in the Connection Status column.

Repeat the above steps for every Key Management Server of a possible highly-available KMS cluster have been configured and trusted.

Encrypting a new virtual machine

The last step towards encrypted Domain Controllers is to create Domain Controllers as encrypted virtual machines. In the vSphere Web Client, take care of the following setting:

On the Select storage page of the New Virtual Machine wizard, select the Encrypt this virtual machine option.

Specify any other settings, for instance the right settings for Virtualization-based Security for the virtual machine, too.

Concluding

VM Encryption provides the level of assurance that Active Directory admins need from the virtualization platform that their virtualized Domain Controllers cannot be run outside of the trusted vCenter scope.

Further reading

Virtual Machine Encryption
Virtual Machine Encryption Best Practices
How to install HyTrust KeyControl 5.1 in vSphere 6.7
New steps to use HyTrust KMIP with vSAN Encryption

VMware vSphere 6.7 offers the ability to enable virtualization-based security (VBS) for virtual machines. Let’s find out what kind of protection this setting provides, what’s needed to get it going and how to configure a virtual Domain Controller to use it.

About Virtualization-based Security

Virtualization-based Security (VBS) uses virtualization features to create and isolate a secure region of memory from the normal Operating System. Windows Server can use this "virtual secure mode" to host a number of security solutions, providing them with greatly increased protection from vulnerabilities in the operating system, and preventing the use of malicious exploits which attempt to defeat protections.

Benefits of using Virtualization-based Security

Virtualization-based Security (VBS) uses the Windows hypervisor to create this virtual secure mode, and to enforce restrictions which protect vital system and Operating System resources, or to protect security assets such as authenticated user credentials.

With the increased protections offered by Virtualization-based Security, even if malware gains access to the Operating System’s kernel, the possible exploits can be greatly limited and contained because the hypervisor can prevent the malware from executing code or accessing platform secrets.

For Active Directory Domain Controllers, specifically, Virtualization-based Security offers:

Secure Boot

The Secure Boot feature in Windows Server 2016, and up, is designed to protect the virtual machine from malicious boot loaders. In traditional Basic Input/Output System (BIOS)-based systems, a rootkit may replace the Windows boot loader, remaining invisible and undetectable on the Domain Controller.

With Secure Boot, a virtual machine no longer boots with BIOS, but with Unified Extensible Firmware Interface (UEFI). UEFI checks the signature of the boot loader before launching, detecting any malware impersonating, replacing or tampering with the Windows boot loader.

Direct Memory Access (DMA) Protection

Direct Memory Access (DMA) attacks try to grab the memory of a running Operating System to gain access to BitLocker keys and other information from the memory. In vSphere, you can take advantage of an Input/Output Memory Management Unit (IOMMU) to connect a DMA-capable I/O bus to the main memory.

With IOMMU, memory of Windows Server 2016 installations, and  up, is protected from malicious devices that are attempting DMA attacks and faulty devices that are attempting errant memory transfers because a device cannot read or write to memory that has not been explicitly allocated (mapped or re-mapped) for it.

Hypervisor-enforced Code Integrity (HVCI)

Kernel-mode Code Integrity enforces kernel-mode memory protections by protecting the Code Integrity validation path with Virtualization-based Security. All drivers in the virtual machine must be compatible with virtualization-based protection of code integrity; otherwise, the virtual machine fails.

Code Integrity (CI) Policies

Historically, most malware has been unsigned. Simply by deploying code integrity policies, organizations can get immediately protection against unsigned malware. By using Code Integrity policies, an enterprise can also select exactly which binaries can run in both user mode and kernel mode. When completely enforced, it will only load specific applications or software with specific signatures.

Note:
Code Integrity policies are independent of Hypervisor-enforced Code Integrity (HVCI). However, when using CI policies without HVCI, the enforcement will not be as strong as when using CI Policies with HVCI.

Note:
Windows Server 2019 expands on the CI policies feature in Windows Server 2016 by offering built-in CI policies for robust yet quick deployment of Code Integrity.

Other features like Application Guard, Credential Guard and Windows Sandbox, operating in their separate memory spaces are features targeted towards Windows-based devices and are not applicable to Domain Controllers. Well… when you adhere to the rule of thumb not to browse the Internet and install all kinds of software on your Domain Controllers, that is.

Note:
Do not configure Credential Guard on Domain Controllers.

Getting Ready

For Virtualization-based Security (VBS) you’ll need to meet the following requirements:

• At least one ESXi host running VMware vSphere 6.7, or up, managed by vSphere
• At least one virtual machine running hardware version 14 (Compatible only with ESXi 6.7 and later), or up, configured with Virtualization Based Security. and installed with Windows Server 2016, or a later version of Windows Server in this virtualization state.

Note:
The Virtualization Base Security option enables CPU virtualization extensions, IOMMU, EFI firmware and Secure Boot.

Configuring Virtualization-based Security

Configuring Virtualization-based Security consists of three steps:

1. Configure the right virtual machine settings on vSphere 6.7
2. Configure the right security settings in the virtual Domain Controller
3. Install the Hyper-V feature on the virtual Domain Controller

Configure the right virtual machine settings

First, we need to create a virtual Domain Controller that meets the requirements.

ESXi 6.7

When creating a new virtual machine for a Domain Controller, on the 2 Select a name and guest OS page of the New virtual machine wizard, make sure as a Compatibility level you pick ESXi 6.7 virtual machine (or up), resulting in hardware version 14. Pick Microsoft Windows Server 2016 or later (64-bit) as the Gues OS version. Then, make sure you select the option Enable Windows Virtualization Based Security:

vSphere 6.7

In the vSphere Web Client, when creating a new virtual machine, take care of the following settings:

• On the Select compatibility page of the New Virtual Machine wizard, select ESXi 6.7 and later. The accompanying text below this settings will then indicate that This virtual machine uses hardware version 14, which provides the best performance and latest features available in ESXi 6.7.
• On the Select a guest OS page of the New Virtual Machine wizard, specify Microsoft Windows Server 2016 or later (64-bit) as the Guest OS Version and select the option Enable Windows Virtualization Based Security:

Configure the right security settings in the virtual Domain Controller

After installing Windows Server 2016, or up, on the new virtual Domain Controller and configuring it as a Domain Controller for (one of) your Active Directory domain(s), perform the following actions in the virtual machine or on any other domain-joined machine that has the Group Policy Management Console feature installed:

• Sign in with an account that has sufficient permissions in Active Directory to create Group Policy objects and link them to the Domain Controllers Organizational Unit (OU). Typically, a member of the Domain Admins group has these permissions.
• Open the Group Policy Managment console, by either:
  • Picking it from the Tools menu in Server Manager.
  • Selecting it in the Start Menu from the Windows Administrative Tools folder.
  • Clicking the Start button and typing gpmc.msc followed by a press of the Enter button on the keyboard.
  • right-clicking the Start button and typing gpmc.msc followed by a click on the OK button.
• The Group Policy Management window appears.
• In the left navigation pane, expand the forest node, then the Domains node, than your domain. Select the Domain Controllers Organizational Unit (OU).
• Right-click Domain Controllers and select the Create a GPO in this domain, and Link it here… menu option.
  The New GPO pop-up window appears.
• In the New GPO pop-up window, type a name for the Group Policy object.
• Click the OK button.
• In the left navigation pane, expand the Domain Controllers OU and select the newly created Group Policy object.
• Dismiss the Group Policy Management Console pop-up telling you that You have selected a link to a Group Policy Object (GPO). Except for changes to link properties, changes you make here are global to the GPO, and will impact all other locations where this GPO is linked. by clicking the OK button, if it pops up.
• Right-click the Group Policy object and select Edit… from the context menu.
  The Group Policy Management Editor window appears.
• In the left navigation pane of the Group Policy Management Editor window, expand the Computer Configuration node, then the Policies node, the Administrative Templates node, the System, and finally the Device Guard node.

• In the main pane, double-click the Turn on Virtualization Based Security group policy setting.
  The Turn on Virtalization Based Security window appears
• In the top part of the Group Policy setting, select the Enabled option.
• At the left Options: pane, select the following options:
  • For Virtualization Based Protection of Code Integrity:, select Enabled without lock from the drop-down list. As we are configuring Virtualization-based Security through Group Policy, we’d want Group Policy to be able to remove the settings remotely as well, if need be.
  • Enable the Require UEFI Memory Attributes Table option.
  • For Secure Launch Configuration:, select Enabled from the drop-down list.
• Click the OK button at the bottom of the Turn on Virtualization Based Security window to save the Group Policy settings and close the Turn on Virtualization Based Security window:

• Close the Group Policy Management Editor window.
• In the left navigation pane of the Group Policy Management window, right-click the Domain Controllers OU. Select Group Policy Update… from the context menu.
  The Force Group Policy update window appears.
• Click the Yes button to answer the question Are you sure you want to update policy for these computers?
  The Remote Group Policy update results window appears.
• Click the Close button to close the window.
• Close the Group Policy Management window.

Install the Hyper-V feature on the virtual Domain Controller

If you’ve managed the Group Policy settings from another machine than the virtualized Domain Controller running Windows Server 2016, or up, sign into the Domain Controller with an Active Directory account that has administrative privileges on the Domain Controller.

Run the following lines of Windows PowerShell in an elevated PowerShell window on each Domain Controller that you want enabled with Virtualization-based Security:

Install-WindowsFeature Hyper-V

Restart-Computer

Concluding

Virtualization-based Security offers benefits for virtualized Domain Controllers running Windows Server 2016, and up. It uses nested virtualization, where Microsoft Hyper-V offers the secure memory regions and vSphere offers the virtualization platform as it would do for any virtual machine.

Further reading

Virtualization-based Security (VBS)
Introducing support for Virtualization Based Security in vSphere 6.7
Overview of Device Guard in Windows Server 2016
Enabling Windows 10 Virtualization Based Security with vSphere 6.7