Windows Server 2016 delivering Secure IaaS Guarded Fabric

Overview

One of the primary objectives as a hoster is to provide secure, reliable and resilient virtualization services to your customers. While Hyper-V has a proven track record of delivering on all these values at hyper-scale, in datacenters globally, Windows Server 2016 takes this technology to the next level.

As one of the primary technology investment areas, Windows Server introduces an industry first for the security of the Virtualization platform, benefiting both the hoster and their tenant's.

Secure IaaS provides the ability to protect both our hypervisors hosts and its virtual machines from a virtual machine which maybe executing malicious software, while also protecting the virtual machine real estate form a compromised host, or suspicious fabric operator.

Fundamentally, irrespective of virtualization technologies, virtual machines are represented as file's that we need to protect from attacks to the host, the storage system, the network, or while been backed up.

As these files potentially encapsulate sensitive data, transferring them to other systems, either intentionally, accidentally or maliciously, they can be easily re-hosted exposing the assets value. Protecting this files is ever more relevant in today's ecosystems.

To help protect against compromised fabric, Windows Server 2016 Hyper-V introduces shielded VMs. A shielded VM is a generation 2 VM (supported on Windows Server 2012 and later) that has a virtual TPM, is encrypted using BitLocker and can only run on healthy and approved hosts in the fabric.

Shielded VMs and guarded fabric enable cloud service providers or enterprise private cloud administrators to provide a more secure environment for tenant VMs.

The following sections explain these capabilities and also enumerate considerations that the Hosting Service Provider (HSP) Operations Administrator has to keep in mind while implementing this offer.

Operational Overview

A guarded fabric consists of 'Host Guardian Service' (HGS), which is a Windows 2016 Server role that is installed on a secured cluster of bare-metal servers. This service can measure the health of a Hyper-V host and release keys to healthy Hyper-V hosts when powering-on or live migrating secured (otherwise known as shielded) VMs. Together, these two capabilities are fundamental to a shielded VM solution and are referred to as the Attestation service and Key Protection Service respectively.

The Attestation service ensures only trusted Hyper-V hosts can run shielded VMs while the Key Protection Service provides the keys necessary to power them on and to live migrate them to other guarded hosts.

The second element of a guarded fabric, are the Hyper-V hosts that are to be considered as a guarded host. When these hosts have been deemed healthy by Host Guardian Service Attestation Service our Shielded VMs can be powered-on and live migrated to any other Hyper-V host that has been attested as guarded. If the Shielded VM is hosted on a host that failed attestation it cannot be powered-on.

A Shielded VM, is a virtual machine that can only run on guarded hosts and is protected from inspection, tampering and theft from malicious fabric admins and host malware.

Operational Considerations

The technologies exposed within Windows Server 2016, can be used independently, or for a better together experience, they can be easily combined to deliver the Secure IaaS experience.

In this section we will take a closer look at the roles associated with each of the technologies, and how the solutions are implemented.

We have two administrative roles when working with Secure IaaS

  • The Fabric Administrator, is a cloud administrator that can manage virtual machines. In the context of a guarded fabric, a fabric administrator does not have access to shielded VMs, or the policies that determine which hosts shielded VMs can run on.
  • The Host Guardian Service Administrator, is a trusted administrator that has the authority to manage the policies and cryptographic material for guarded hosts, that is, hosts on which a shielded VM can run.

A guarded fabric consists of the following

  • Host Guardian Service (HGS) (typically, a cluster of 3 nodes)
  • 1 or more guarded hosts
  • A set of shielded virtual machines.

When a tenant creates shielded VMs that run on a guarded fabric, the Hyper-V hosts and the shielded VMs themselves are protected by the Host Guarded Service. With these new capabilities, Hosting Providers can offer new services running in slimmer environments with fewer attack vectors than are possible on the traditional Windows Server OS.

The diagram below shows how the Host Guardian Service uses attestation to ensure that only known, valid hosts can start the shielded VMs, and key protection to securely release the keys for shielded VMs.

Attestation modes

The HGS supports two different attestation modes for a guarded fabric:

TPM-trusted attestation (Hardware based)

Admin-trusted attestation (AD based)

TPM-trusted attestation is recommended because it offers stronger assurances, as explained in the following table, but it requires that your Hyper-V hosts have TPM 2.0. If you currently do not have TPM 2.0, you can use Admin-trusted attestation. If you decide to move to TPM-trusted attestation when you acquire new hardware, you can switch the attestation mode on the Host Guardian Service with little or no interruption to your fabric.

TPM-trusted attestation: Offers the strongest possible protections but also requires more configuration steps. Host hardware and firmware must include TPM 2.0 and UEFI 2.3.1 with secure boot enabled. Guarded hosts that can run shielded VMs are approved based on their TPM identity, measured boot sequence and code integrity policies so that you can ensure that these hosts are only running approved code.

Admin-trusted attestation: Intended to support existing host hardware where TPM 2.0 is not available. Requires fewer configuration steps and is compatible with commonplace server hardware. Guarded hosts that can run shielded VMs are approved by the Host Guardian Service based on membership in a designated Active Directory Domain Services (AD DS) security group.

Virtual Machine Workload Protection

Guarded fabrics are capable of running VMs in one of three possible ways.

Normal VM's: offering no protections above and beyond previous versions of Hyper-V

Encryption-supported VM's: whose protections can be configured by a fabric admin, these are intended for use where the fabric administrators are fully trusted, and are deployed to a guarded fabric to ensure VM disks are encrypted at-rest for compliance purposes. Fabric administrators can continue to use convenient management features, such VM console connections, PowerShell Direct, and other day-to-day management and troubleshooting tools.

Shielded VM's: whose protections are all switched on and cannot be disabled by a fabric admin, these are intended for use in fabrics where the data and state of the VM must be protected from both fabric administrators and untrusted software that might be running on the Hyper-V hosts. Shielded VMs will never permit a VM console connection whereas a fabric administrator can turn this protection on or off for encryption supported VMs.

The following summarizes the differences between encryption support and shielded VMs

Capability

Generation 2 Encryption

Generation 2 Shielded

Secure Boot

Yes, Required but Configurable

Yes, Required and Enforced

Virtual TPM

Yes, Required but Configurable

Yes, Required and Enforced

Encrypted VM State and Live Migration Traffic

Yes, Required but Configurable

Yes, Required and Enforced

Integration Component

Configurable by the fabric administrator

Data Exchange, PowerShell direct, are Disabled and cannot be enabled

Virtual Machine Connections (Console/PowerShell Direct/Devices)

On, and cannot be disabled

Disabled (cannot be enabled)

Serial Ports

Supported

Disabled (cannot be enabled)

Debugger Attach

Supported

Disabled (cannot be enabled)

Live Migration, Checkpoints, Replica, etc

Supported

Supported

When using microsegmentation for security you're able to reduce the attack surface within your network and limit what attackers can exploit. Using software-based segmentation as an overlay, on top of your current network, allows for a more flexible design with segmentation being used across the datacenter. This also allows for workload segmentation within layer 2 that would normally take a choke point to have filtered. Using segmentation that doesn't require static IP addresses allows for automation of security with the added benefit of allowing your architecture to continue being scalable and flexible.

Host Attestation Checks

The following checks are implemented as part of the Guardian Attestation checks:

  • BitLocker encrypted disks (OS disks and data disks): Shielded VMs use BitLocker to protect their disks. The BitLocker keys needed to boot the VM and decrypt the disks are protected by the shielded VM's virtual TPM using industry-proven technologies such as secure measured boot. While shielded VMs only automatically encrypt and protect the operating system disk, you can encrypt data drives attached to the shielded VM as well.
  • Deployment of new shielded VMs from "trusted" template disks/images. When deploying new shielded VMs, tenants can specify which template disks they trust. Shielded template disks have signatures that are computed at a point in time when their content is deemed trustworthy. The disk signatures are then stored in a signature catalog, which tenants securely provide to the fabric when creating shielded VMs. During provisioning of shielded VMs, the signature of the disk is computed again and compared to the trusted signatures in the catalog. If the signatures match, the shielded VM is deployed. If the signatures do not match, the shielded template disk is deemed untrustworthy and deployment fails.
  • Protection of passwords and other secrets when a shielded VM is created. When creating VMs, it is necessary to ensure that VM secrets, such as the trusted disk signatures, RDP certificates, and the password of the VM's local Administrator account, are not divulged to the fabric. These secrets are stored in an encrypted file called a shielding data file (a .PDK file), which is protected by tenant keys and uploaded to the fabric by the tenant. When a shielded VM is created, the tenant selects the shielding data to use which securely provides these secrets only to the trusted components within the guarded fabric.
  • Tenant control of where the VM can be started. Shielding data also contains a list of the guarded fabrics on which a particular shielded VM is permitted to run. This is useful, for example, in cases where a shielded VM typically resides in an on-premises private cloud but may need to be migrated to another (public or private) cloud for disaster recovery purposes. The target cloud or fabric must support shielded VMs and the shielded VM must permit that fabric to run it.

Shielding Data Files

The shielding data file, called a provisioning data (PDK) file is an encrypted file that a tenant or VM owner creates to protect important VM configuration information, such as the administrator password, RDP and other identity-related certificates, domain-join credentials, and so on. A fabric administrator uses the shielding data file when creating a shielded VM, but is unable to view or use the information contained in the file.

Among others, a shielding data files contain secrets such as:

  • Administrator credentials
  • An answer file (unattend.xml)
  • A security policy that determines whether VMs created using this shielding data are configured as shielded or encryption supported. Remember, VMs configured as shielded are protected from fabric admins whereas encryption supported VMs are not
  • An RDP certificate to secure remote desktop communication with the VM
  • A volume signature catalog that contains a list of trusted, signed template-disk signatures that a new VM is permitted to be created from
  • A Key Protector (or KP) that defines which guarded fabrics a shielded VM is authorized to run on

The shielding data file (PDK file) provides assurances that the VM will be created in the way the tenant intended. For example, when the tenant places an answer file (unattend.xml) in the shielding data file and delivers it to the hosting provider, the hosting provider cannot view or make changes to that answer file. Similarly, the hosting provider cannot substitute a different VHDX when creating the shielded VM, because the shielding data file contains the signatures of the trusted disks that shielded VMs can be created from.

Operational Steps

  1. VM is powered on.

    Before a guarded host can power on a shielded VM, it must first be affirmatively attested that it is healthy. To prove it is healthy, it must present a certificate of health to the Key Protection service (KPS). The certificate of health is obtained through the attestation process.

  2. Host requests attestation.

    The guarded host requests attestation. The mode of attestation is dictated by the Host Guardian Service:

    Admin-trusted attestation:

    Hyper-V host sends a Kerberos ticket, which identifies the security groups that the host is in. HGS validates that the host belongs to a security group that was configured earlier by the trusted HGS admin.

    With admin-trusted attestation, the health of the host is determined exclusively by its membership in a trusted security group.

    TPM-trusted attestation:

    Host sends information that includes:

  • TPM-identifying information (its endorsement key)
  • Information about processes that were started during the most recent boot sequence (the TCG log)
  • Information about the Code Integrity (CI) policy that was applied on the host

With TPM-trusted attestation, the host's boot measurements and code integrity policy determine its health.

Attestation happens when the host starts and every 8 hours thereafter. If for some reason a host doesn't have an attestation certificate when a VM tries to start, this also triggers attestation.

  1. Attestation succeeds (or fails).

    The attestation service uses the attestation mode to determine which checks it needs to make (group membership vs. boot measurements, and so on) in order to affirmatively (successfully) attest the host.

  2. Attestation certificate sent to host.

    Assuming attestation was successful, a health certificate is sent to the host and the host is considered "guarded" (authorized to run shielded VMs). The host uses the health certificate to authorize the Key Protection Service to securely release the keys needed to work with shielded VMs

  3. Host requests VM key.

    Guarded host do not have the keys needed to power on a shielded VM (VM01 in this case). To obtain the necessary keys, the guarded host must provide the following to KPS:

  • The current health certificate
  • An encrypted secret (a Key Protector or KP) that contains the keys necessary to power on VM01. The secret is encrypted using other keys that only KPS knows.
  1. Release of key.

    KPS examines the health certificate to determine its validity. The certificate must not have expired and KPS must trust the attestation service that issued it.

  2. Key is returned to host.

    If the health certificate is valid, KPS attempts to decrypt the secret and securely return the keys needed to power on the VM. Note that the keys are encrypted to the guarded host's VBS.

  3. Host powers on VM01.

Example Scenario

Contoso Inc. is looking to deliver secure IaaS services to its customer base, enabling new offerings for customers where data security and regulatory restrictions are of paramount importance.

The new offering will complement the existing IaaS options, by added two additional classes of protection, Encryption and Shielding.

The solution will support the following capabilities

  • Familiar IaaS Deployment experience
  • Protection Information will be provided by the tenant as an encrypted file
  • Tenant can select the protection level for their Virtual Machines
  • Existing Virtual Machines can be 'Protected'

Deployment configurations

The following configurations listed below will be deployed using Windows Server 2016 to provision the Secure IaaS example environment

  • Guardian Service Host
  • Hyper-V Host
  • Guest Workload

Lab Requirements

To successfully execute the scenarios in the next sections the following requirements needs to be met:

  • Virtual or Physical Servers; for High Availability, a 3-node physical cluster is recommended.
  • Windows Server 2016 Datacenter

Shielded Requirements

  • Ability to configure DNS forwarding between the fabric (host) domain and the HGS domain.
  • Admin-trusted attestation:
    • You will need to be able to configure Active Directory trusts between the fabric domain the HGS domain.
  • TPM Trusted Attestation:
    • Hosts must meet the following minimum hardware requirements:
      • IOMMU and Second Level Address Translation (SLAT)
      • TPM 2.0
      • UEFI 2.3.1 or later
      • Configured to boot using UEFI (not BIOS or "legacy" mode)
      • Secure boot enabled

    For TPM-trusted attestation, we recommend that you elect a "reference host" to represent each unique class of hardware configuration within your datacenter. You will use the reference host to capture the necessary information for TPM-trusted attestation.

A guarded fabric cannot contain a mix of admin- and TPM-trusted attestation. However, you can change from one attestation mode to the other. In other words, even though you must choose one mode for your initial deployment, you can change to the other mode later.

By default, when we set up HGS, it creates its own forest. However, you can choose to add HGS to an existing forest. The forest used by HGS is sensitive because its administrators have access to the keys that control shielded VMs. For this reason, we strongly recommend that HGS either create its own forest during initial installation, or use an existing bastion forest - one that is isolated from traditional fabric or CORP-forest administrators.

Deployment Stages

The process of deploying guarded fabric can be broken into 4 primary areas of focus

Hoster – IT Staff

Setup Guarded Fabric

Hoster – Fabric Admin

Create Fabric Artefact's

Tenant

Create Tenant Artefact's

Tenant

Deploy Shielded VM

Each focus area will be broken into a few distinct steps. For this document the installation, configuration and management of the solution will be completed purely tough the use of PowerShell.

Guarded Fabric however scales when utilized trough a management layer. Microsoft System Center Virtual Machine Manager 2016 is one such option, and maybe combined with Windows Azure Pack to deliver a seamless management experience, further solidifying the 4 main areas of focus to deliver a true secure self-service experience for the tenants of the portal.

Additional, Guarded Fabric has been publicly demonstrated during the Ignite 2016 conference to be manageable from the OpenStack platform, when Hyper-V 2016 and the Host fabric as outlined in this document are combined to the solution. More information on this configuration can be obtained online, or from https://www.cloudbase.it

The following is an outline of steps we will proceed to configure in the remainder of this section:

  • Setup Guarded Fabric
    • Prepare Fabric Certificate's
      • Use a PKI certificate and PFX file we already own, that is not backed by an HSM
      • Use a PKI certificate we already own, backed by a Hardware Security Module (HSM)
      • Use a self-signed PKI certificate
      • Configure a certificate for enabling HTTPS
    • Deploy Host Guardian Service
      • Add the HGS Role
      • Host Guardian Service Installation Considerations
      • Install and Initialize HGS to a new dedicated forest
      • Install and Initialize HGS in an existing bastion forest
      • Deploy additional HGS Instances for High Availability
      • Validate Host Guardian Service
    • Configure Host Guardian Service
      • Admin Trusted Attestation
        • Create a security group and place hosts in the group
      • TPM Trusted Attestation
        • Capture the TPM identifier (platform identifier or EKpub) for each host
        • Create and apply a Code Integrity policy
        • Capture the TPM baseline for each unique class of hardware
    • Configure Hyper-V hosts as Guarded
      • Add host information for Admin-trusted attestation
        • Configuring DNS forwarding and domain trust
        • Adding security group information to the HGS configuration
      • Add host information for TPM-trusted attestation
    • Validate Host Guardian Service Deployment
  • Create shielded VM fabric artifacts
    • Prepare template disks
    • Create shielded templates
  • Create shielded VM tenant artifacts
    • Obtain guardian keys from guarded fabric
    • Create owner keys to protect your Shielded VMs
    • Obtain volume signatures for trusted template disks
    • Create shielding data and upload to guarded fabric
  • Deploy and Manage Shielded VMs
    • Create new shielded VMs on guarded fabric

Setup Guarded Fabric

Prepare Fabric Certificates

You need to configure the Host Guardian Service with two certificates for encryption and signing purposes. There are three options, as shown in the following table. These options are mutually exclusive. Choose the one that applies to your environment:

  • Use a PKI certificate and PFX file we already own, that is not backed by an HSM
  • Use a PKI certificate we already own, backed by a Hardware Security Module (HSM)
  • Use a self-signed PKI certificate

Note : Regardless of how you create the certificates, they must support RSA 2048 bit keys and their key-usage policy (EKU) must permit digital signing and encryption.

HTTPS is not needed to secure communication between HGS and a Hyper-V host, but if you choose to enable HTTPS, you will need an additional certificate. The HTTPS certificate can be one that you already have, or you can create a new certificate that you will specify when initializing the HGS server.

Use a PKI certificate and PFX file we already own, that is not backed by an HSM

If you have obtained certificates from a trusted Public Key Infrastructure (PKI) environment and both the certificate and your organization permit the private keys to be exported to a PFX (personal information exchange) file, you are now able to conveniently add the PFX to any one node of the HGS cluster and have it automatically configured and replicated to all other nodes in the HGS cluster.

If you are unable to obtain a PFX or are unable to obtain one with the private key intact, you will need to install the certificates (including the private key) manually on each HGS node in your cluster according to your organization's certificate enrollment processes. Certificates that are added to HGS by thumbprint reference instead of a PFX file and password require additional action, as described in the following procedure.

To grant the HGS service access to the private keys of certificates added by thumbprint reference

  • Unlike other certificate-related tasks, you MUST repeat this process on each HGS node. Run CERTLM.MSC (which opens the Certificate Management Console for the local store).
  • Navigate to the signing certificate, right-click it, and then click All Tasks > Manage Private Keys.
  • In the Security dialog box, add the group managed service account (gMSA) for HGS to the list of accounts.
    • To do this, click Add and in the resulting dialog box, click Object Types, select Service Accounts, and click OK.
    • Under Enter the object names to select, type the account name - by default, HGSSVC - and click Check Names.
    • If you originally set up HGS in an existing domain, you'll type the name of the gMSA that you provided to the Initialize-HgsServer command.
  • Give the account Read access to the private keys for the certificate.
  • Repeat the process for the encryption certificate.

Use a PKI certificate we already own, backed by a Hardware Security Module (HSM)

If you plan to use certificates that reside in a Hardware Security Module (HSM), use the following high-level steps, which will vary according to your HSM vendor:

  • Install the HSM vendor's software to ensure that the HSM is visible to Windows.
  • Create two certificates within the HSM with RSA 2048 bit keys and key usage policies for signing and encryption purposes.
    • Create one encryption certificate within your HSM
    • Create one signing certificate within your HSM
  • Verify that the certificates are installed in the local machine's certificate store. If they have not been automatically installed, they must be added per the HSM vendor's guidance (note that the private key remains in the HSM as expected). As before, you can add the certificate to the local machine's certificate store on any one node of the HGS cluster and it will automatically be configured and replicated to all other nodes in the HGS cluster.
  • Finally, you must ensure that the group managed service account (gMSA) for HGS has been granted read access to the private keys for your certificate. By default, the gMSA account name is HGSSVC. If you originally set up HGS in an existing domain, the gMSA is the one that you provided to the Initialize-HgsServer command. The process for granting access varies between vendors, so please consult the user guide for your specific HSM for information on how to configure access for your HSM-backed certificate.

Use a self-signed PKI certificate

Warning: Creating self-signed certificates is not recommended outside of test/POC deployments. Use certificates that are issued by a trusted certificate authority if you are deploying in a production environment.

  • Open an elevated Windows PowerShell console and run the following command to specify the password to use when exporting the self-signed certificate. For password, substitute a password.

$certificatePassword = ConvertTo-SecureString -AsPlainText 'password' -Force

  • Create and export the signing certificate by running the following commands. For signing (after -DnsName) and for C:\signingCert, you can leave the names as shown or substitute your preferred names.

    $signingCert = New-SelfSignedCertificate -DnsName "signing.relecloud.com"

    Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath 'C:\signingCert.pfx

  • Create and export the encryption certificate by running the following commands. For encryption (after -DnsName) and for C:\encryptionCert, you can leave the names as shown or substitute your preferred names.

    $encryptionCert = New-SelfSignedCertificate -DnsName "encryption.relecloud.com"

    Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath 'C:\encryptionCert.pfx'

Configure a certificate for enabling HTTPS

If you choose to enable HTTPS on your HGS server, you must have or create an additional certificate.

To create a new certificate, run the following command. For HgsServiceName, choose a name that you will use as the distributed network name of your HGS server or HGS cluster.

$HttpsCertificate = New-SelfSignedCertificate -DnsName "HgsServiceName.$env:userdnsdomain" -CertStoreLocation Cert:\LocalMachine\My

After you have chosen or created a certificate to use for HTTPS, use a command like the following to export it.

Export-PfxCertificate -Cert $HttpsCertificate -Password $certificatePassword -FilePath 'c:\\HttpsCertificate.pfx'

Deploy Host Guardian Service

The steps in this section guide you through setting up your initial HGS node.

Add the HGS Role

Add the Host Guardian Service role by using Server Manager or by running the following command in an elevated Windows PowerShell console:

Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

Host Guardian Service Installation Considerations

After the role is added, the next step is to run the Install-HgsServer cmdlet to install the HGS. HGS is a critical component in a guarded fabric and is responsible for attesting to a Hyper-V host's health as well as releasing keys needed to work with shielded VMs. The HGS forest is sensitive because its administrators have access to the keys that control shielded VMs.

When you install HGS, the default installation will set up a new Active Directory forest for HGS and configure other dependencies. This option is recommended because the environment is self-contained and known to be secure when it is created.

There are no technical requirements that prevent installing HGS in an existing forest, but there are operational requirements and security-related best practices. Suitable forests are purposely built to serve one sensitive function, such as the forest used by Privileged Access Management for AD DS or an Enhanced Security Administrative Environment (ESAE) forest. Such forests are suitable and usually exhibit the following characteristics:

  • They have few admins
  • They are not general-purpose in nature
  • They have a low number of logons

General purpose forests are not suitable for use by the HGS, because the HGS needs to be isolated from fabric administrators.

Depending on your deployment scenario, follow the steps

  • Install HGS in its own new forest
  • Initialize HGS in an existing bastion forest.
  • Install and Initialize HGS to a new dedicatated forest

The following steps describe the process for deploying the Host Guardian Service using its own newly created Active Directory forest. Ensure that the HGS machine is not joined to a domain before performing these steps.

  • In an elevated Windows PowerShell console, run the following commands to install the Host Guardian Service and configure its domain. The password you specify here will only apply to the Directory Services Restore Mode password for Active Directory; it will not change the password you log in with.

    $adminPassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

    Install-HgsServer -HgsDomainName 'relecloud.com' -SafeModeAdministratorPassword $adminPassword -Restart

  • After the computer restarts, log in as the domain administrator using the same password you previously used as the local administrator (regardless of the password you specified in the previous step).

Note : During this step, you will determine the attestation mode that HGS will use, either Admin-trusted or TPM-trusted attestation, although you can change the mode later. With HGS in TPM-trusted mode, hosts that you configure as guarded hosts must have TPM 2.0, UEFI 2.3.1, and boot in UEFI mode (not BIOS or "legacy" mode).

  • Open an elevated Windows PowerShell console, and then run the following commands to initialize the HGS server with the encryption and signing certificates created earlier.

    For HgsServiceName, substitute a name of your choosing for the HGS cluster. This name is the distributed network name of the cluster. This name should not be fully qualified (e.g. enter "hgs" if you want the DNS to be configured as "hgs.relecloud.com").

    The syntax of the Initialize-HgsServer command will vary according to the type of certificate you chose in Specify the signing and encryption certificates that HGS will use and the desired attestation mode. Specifically:

  • If you have PFX files with private keys intact, use the following parameter set:

    -SigningCertificatePath <path to PFX>

    -SigningCertificatePassword <secureString>

    -EncryptionCertificatePath <path to PFX>

    -EncryptionCertificatePassword <secureString>

  • You also need to provide the certificate password you chose earlier to the initialize cmdlet as a secure string. Enter the following command if you have not already created a variable to hold it.

    $certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

  • If your certificates are in your local certificate store, regardless of whether their private keys are intact or HSM-backed, use the following parameter set:

    -SigningCertificateThumbprint <thumbprint>

    -EncryptionCertificateThumbprint <thumbprint>

  • Specify your attestation mode as follows:

    For Admin-trusted attestation, use: -TrustActiveDirectory

    For TPM-trusted attestation, use: -TrustTpm

Your final command syntax will resemble the following example:

Initialize-HgsServer -HgsServiceName '<HgsServiceName>' -SigningCertificatePath 'C:\signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:\encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]

Although HTTPS is not needed to secure communication between HGS and a Hyper-V host, if you want to enable HTTPS for HGS, instead of using the previous command syntax, see the next section.

Install and Initialize HGS in an existing bastion forest

The following steps describe the process for adding HGS to an existing forest, rather than using the default process of allowing HGS to create its own forest and domain.

Before you can add HGS to an existing forest, to set up the cluster you will need either prestaged cluster objects or, for the user who runs Initialize-HgsServer permissions that would are required to prestage the cluster objects.

  • On a computer in the fabric (host) domain: Create a new Group Managed Service Account (gMSA) that will be configured for use on the machines which will host the Host Guardian Service. You can create this group in Active Directory Users and Computers or by running the Active Directory PowerShell commands on a computer with the AD DS Remote Server Administration Tools (RSAT) installed.

    # A Key Distribution Service is required in order to create and use gMSAs.

    # The following command will create a new KDS 'Root Key' with a 10 hour life time.

    Add-KdsRootKey -EffectiveTime ((get-date).addhours(-10))

    $hgsServiceAccount = 'HostGuardianServices'

    # hostname of a secure node which will run the Guardian Services

    $hgsHostName = 'hgs01.mydomain.com'

    New-ADServiceAccount -Name $hgsServiceAccount -DNSHostName $hgsHostName

  • Next, we must establish two (2) Active Directory groups that you will use for Just Enough Administration (JEA). One group is for users who can perform HGS administration through JEA, and the other is for users who can only view HGS through JEA.

$jeaAdministratorsGroup = 'HGS Administrators Group'

$jeaReviewersGroup = 'HGS Administrators (Read Only) Group'

New-ADGroup -Name $GuardedGroupName -SamAccountName 'GuardedHosts' -GroupCategory Security -GroupScope Global

# hostname of a secure node which will run Shielded VMs

$guardedhost='guarded'

New-ADGroup -Name $jeaAdministratorsGroup -SamAccountName 'HGSAdmins' -GroupCategory Security -GroupScope Global

New-ADGroup -Name $jeaReviewersGroup -SamAccountName 'HGSAdminsRO' -GroupCategory Security -GroupScope Global

  • We have a number of options related to how we are going to ultimulty execute the Initialize-HgsServer command, each of which will use a differen set of parameters to complete the deployment in our existing forest. In addition you will need to provide the switch to identify which attestation mode you will be implementing:
    • For Admin-trusted attestation, use: -TrustActiveDirectory
    • For TPM-trusted attestation, use: -TrustTpm
  • If you want to enable HTTPS communication on the HGS server, you need to pass in the HTTPS certificate when initializing the HGS server.
    • The command switches -Http -Https -HttpsCertificatePath 'C:\HttpsCertificate.pfx' -HttpsCertificatePassword $certificatePassword should be included every time you initialize a HGS server in your environment.
  • Modify the following examples appending the above switches if you wish to enable this HTTPS communications layer.

If you have PFX files with private keys intact, use the following command syntax

$certificatePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

Initialize-HgsServer -UseExistingDomain '<DomainName>' -JeaAdministratorsGroup <AdministratorsGroupName> -JeaReviewersGroup <ReviewersGroupName> -ServiceAccount <gMSAforKPS> -ClusterName <ExistingClusterName> -HgsServiceName '<HgsServiceName>' -SigningCertificatePath 'C:\signingCert.pfx' -SigningCertificatePassword $certificatePassword -EncryptionCertificatePath 'C:\encryptionCert.pfx' -EncryptionCertificatePassword $certificatePassword [-TrustActiveDirectory | -TrustTPM]

Alternatively, If your certificates are in your local certificate store, regardless of whether their private keys are intact or HSM-backed, use the following command syntax

Initialize-HgsServer -UseExistingDomain '<DomainName>' -JeaAdministratorsGroup <AdministratorsGroupName> -JeaReviewersGroup <ReviewersGroupName> -ServiceAccount <gMSAforKPS> -ClusterName <ExistingClusterName> -HgsServiceName '<HgsServiceName>' -SigningCertificateThumbprint <thumbprint> -EncryptionCertificateThumbprint <thumbprint> [-TrustActiveDirectory | -TrustTPM]

Deploy additional HGS Instances for High Availability

In production environments, HGS should be set up in a high availability cluster to ensure that shielded VMs can be powered on even if an HGS node goes down. For test environments, secondary HGS nodes are not required.

The following steps will add an additional node to the HGS cluster that you previously set up. The computer should not be joined to any domain before you perform these steps.

Important:  If you used HSM-backed certificates, you will need to install the driver for your HSM on this machine and grant the machine access to the private keys of the encryption and signing certificates per your HSM manufacturer's instructions.

  • To add the Host Guardian Service role to the computer, run the following command in an elevated Windows PowerShell console:

    Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart

  • Configure at least one NIC on this machine to use the DNS server on your first HGS server for name resolution. This is necessary to enable the machine to resolve and join the HGS domain and cluster in the next step.
  • Install the Host Guardian Service by running the command below. Substitute the IP addresses and names as appropriate for your environment:

    $adSafeModePassword = ConvertTo-SecureString -AsPlainText '<password>' -Force

$cred = Get-Credential 'relecloud\Administrator'

Install-HgsServer -HgsDomainName 'relecloud.com' -HgsDomainCredential $cred -SafeModeAdministratorPassword $adSafeModePassword -Restart

Wait for the server to restart, then sign in with the HGS domain administrator credentials.

  • Run the commands below to finish adding the new node to the HGS cluster. Substitute the IP addresses and names as appropriate for your environment:

Important: 

For both PKI-issued and HSM-backed certificates, you must manually grant the HGS service access to the private keys of the certificate per the instructions in Use my own certificates with an HSM.

$cred = Get-Credential 'relecloud\Administrator'

Initialize-HgsServer -HgsServerIPAddress <IP address of first HGS Server>

Allow up to 10 minutes for the encryption and signing certificates from the first HGS server to replicate to this node.

Validate Host Guardian Service

Next, we need to validate that things are working as expected. To do so, run the following command in an elevated Windows PowerShell console:

Get-HgsTrace -RunDiagnostics

Because the HGS configuration does not yet contain information about the hosts that will be in the guarded fabric, the diagnostics will indicate that no hosts will be able to attest successfully yet. Ignore this result, and review the other information provided by the diagnostics.

It is important to run the diagnostics on each node in your HGS cluster.

Configure Host Guardian Service

Regardless of the attestation mode that you use, guarded hosts must be able to resolve the HGS cluster. Therefore, you (the fabric administrator) must set up a DNS forwarder from the fabric domain to the HGS domain. There are many ways to configure name resolution on the fabric domain. One way is to set up a conditional forwarder zone in DNS for the fabric. To set up this zone, run the following commands in an elevated Windows PowerShell console on a fabric DNS server.

Substitute the names and addresses in the Windows PowerShell syntax below as needed for your environment. Add master servers for the additional HGS nodes.

Note: Run the command on a fabric DNS server, not on an HGS server.

Add-DnsServerConditionalForwarderZone -Name <HGS domain name> -ReplicationScope "Forest" -MasterServers <IP addresses of HGS server>

With HGS set up and name resolution in place, it's time to capture information from the hosts that you will later provide to the HGS administrator, so that HGS will recognize those hosts. How you do this depends on which attestation mode you are using

Admin Trusted Attestation

Hyper-V hosts that will become guarded hosts using Admin-trusted attestation must meet the following prerequisites:

Hardware: One host is required for initial deployment. To test Hyper-V live migration for shielded VMs, you must have at least two hosts. For this attestation mode, hosts only need hardware capable of running Hyper-V in Windows Server 2016.

  • Operating system: Windows Server 2016 Datacenter edition

Important:  Ensure that you have installed the latest cumulative update before you deploy shielded virtual machines in production.

  • Role and features: Hyper-V role and the Host Guardian Hyper-V Support feature. The Host Guardian Hyper-V Support feature is necessary to let the Hyper-V host communicate with HGS to attest to its health and request keys for shielded VMs. This feature is only available on Datacenter editions of Windows Server 2016.

Warning:  The Host Guardian Hyper-V Support feature enables Virtualization-based protection of code integrity that may be incompatible with some devices. We strongly recommend testing this configuration in your lab before enabling this feature. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error). For more information, see Compatible hardware with Windows Server 2016 Virtualization-based protection of Code Integrity.

Create a security group and place hosts in the group

Admin-trusted attestation identifies legitimate hosts through a designated Active Directory security group. As a fabric administrator, you can use the following steps to create the security group and place hosts in that group.

  • On a computer in the fabric (host) domain: Create a new GLOBAL security group in the fabric domain to identify those hosts trusted to run shielded VMs. You can create this group in Active Directory Users and Computers or by running the Active Directory PowerShell commands on a computer with the AD DS Remote Server Administration Tools (RSAT) installed.

Warning: You must restart each host after adding them to this security group to update their group membership, unless using a group that the host was already a member of.

$GuardedGroupName='Guarded Hosts Group'

# hostname of a secure node which will run Shielded VMs

$guardedhost='guarded'

$guardedGroup = New-ADGroup -Name $GuardedGroupName -SamAccountName 'GuardedHosts' -GroupCategory Security -GroupScope Global

# $GroupMember should look similar to "CN=$cn, DC=$dc"

# ex: "CN=guarded,CN=Computers,DC=dev,DC=com"

Add-ADGroupMember -Identity $GuardedGroupName -Members $GroupMember

# $guardedGroup.sid.Value will be used as an Identifier when setting up the attestation for HGS

$guardedGroup.sid.Value

  • Obtain the security identifier (SID) of the security group that you created (so that you can provide it to the HGS administrator). To obtain the SID, use the following Windows PowerShell command in the fabric domain.

    Get-AdGroup 'Guarded Hosts'

  • Provide the SID to the HGS administrator so they can register the group with HGS as an Attestation Host Group.

TPM Trusted Attestation

Hyper-V hosts that will become guarded hosts using TPM-trusted attestation must meet the following prerequisites:

  • Hardware: One host is required for initial deployment. To test Hyper-V live migration for shielded VMs, you must have at least two hosts.

    For this attestation mode, hosts must have:

    • IOMMU and Second Level Address Translation (SLAT)
    • TPM 2.0
    • UEFI 2.3.1 or later
    • Configured to boot using UEFI (not BIOS or "legacy" mode)
    • Secure boot enabled

    For TPM-trusted attestation, we recommend that you elect a "reference host" to represent each unique class of hardware configuration within your datacenter. You will use the reference host to capture some of the necessary information for TPM-trusted attestation.

  • Operating system: Windows Server 2016 Datacenter edition

Important:  Ensure that you have installed the latest cumulative update before you deploy shielded virtual machines in production.

  • Role and features: Hyper-V role and the Host Guardian Hyper-V Support feature. The Host Guardian Hyper-V Support feature is necessary to let the Hyper-V host communicate with HGS to attest to its health and request keys for shielded VMs. This feature is only available on Datacenter editions of Windows Server 2016. If you are using the Nano Server installation option of Windows Server 2016, see Appendix A - Configure Nano server as TPM attested guarded host.

Warning:  The Host Guardian Hyper-V Support feature enables Virtualization-based protection of code integrity that may be incompatible with some devices. We strongly recommend testing this configuration in your lab before enabling this feature. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error). For more information, see Compatible hardware with Windows Server 2016 Virtualization-based protection of Code Integrity.

As the name implies, TPM-trusted attestation uses a TPM identifier (also called a platform identifier or endorsement key [EKpub]) to begin determining whether a host is authorized as "guarded." This mode of attestation uses secure boot and code integrity measurements to ensure that a given Hyper-V host is in a healthy state and is running only trusted code. In order for attestation to understand what is and is not healthy, you must capture the following information:

  • TPM identifier (EKpub) - unique to each Hyper-V host
  • TPM baseline (boot measurements) - applicable to all Hyper-V hosts that run on the same class of hardware
  • Code Integrity policies (a white list of allowed binaries) - applicable to all Hyper-V hosts that share both common hardware and software

We recommend that you elect a "reference host" to represent each unique class of hardware configuration within your datacenter. Then, as noted in the instructions below, you can use the reference host to capture the necessary information for TPM-trusted attestation. Note that item #1 in the list above must be obtained from each individual Hyper-V host.

Capture the TPM identifier (platform identifier or EKpub) for each host

Ensure the TPM on each host is ready for use - that is, the TPM is initialized and ownership obtained. You can check the status of the TPM by opening the TPM Management Console (tpm.msc) or by running Get-Tpm in an elevated Windows PowerShell window. If your TPM is not in the Ready state, you will need to initialize it and set its ownership. This can be done in the TPM Management Console or by running Initialize-Tpm.

  • More information about TPM management is available at Initialize and configure ownership of the TPM.
  • On each guarded host, run the following command in an elevated Windows PowerShell console to obtain its EKpub. For , substitute the unique host name with something suitable to identify this host - this can be its hostname or the name used by a fabric inventory service (if available). For convenience, name the output file using the host's name.

    (Get-PlatformIdentifier -Name '<HostName>').InnerXml | Out-file <Path><HostName>.xml -Encoding UTF8

  • Repeat the preceding steps for each host that will become a guarded host, being sure to give each XML file a unique name.
  • Provide the resulting XML files to the HGS administrator so they can register each host's TPM identifier with HGS.

Create and apply a Code Integrity policy

A Code Integrity policy helps ensure that only the executables you trust to run on a host are allowed to run. Malware and other executables outside the trusted executables are prevented from running.

Each guarded host must have a code integrity policy applied in order to run shielded VMs. You specify the exact code integrity policies you trust by adding them to HGS. Code integrity policies can be configured to enforce the policy, blocking any software that does not comply with the policy, or simply audit (log an event when software not defined in the policy is executed). It is recommended that you first create the CI policy in audit (logging) mode to see if it's missing anything, then enforce the policy when using the system to host production workloads. For more information about generating CI policies and the enforcement mode, see:

  • Planning and getting started on the Device Guard deployment process
  • Deploy Device Guard: deploy code integrity policies

Before you can use the New-CIPolicy cmdlet to generate a Code Integrity policy, you will need to decide the rule levels to use. For Server Core, we recommend a primary level of FilePublisher with fallback to Hash. This allows files with publishers to be updated without changing the CI policy. Addition of new files or modifications to files without publishers (which are measured with a hash) will require you to create a new CI policy matching the new system requirements. For Server with Desktop Experience, we recommend a primary level of Publisher with fallback to Hash. For more information about the available CI policy rule levels, see Deploy code integrity policies: policy rules and file rules and cmdlet help.

  • On the reference host, generate a new code integrity policy. The following commands create a policy at the FilePublisher level with fallback to Hash. It then converts the XML file to the binary file format Windows and HGS need to apply and measure the CI policy, respectively.

    New-CIPolicy -Level FilePublisher -Fallback Hash -FilePath 'C:\temp\HW1CodeIntegrity.xml' -UserPEs

    ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity.p7b'

Note: The above command creates a CI policy in audit mode only. It will not block unauthorized binaries from running on the host. You should not use such policies in production; use only enforced policies to ensure malware and other unintended programs are not running on your guarded hosts.

  • Keep your Code Integrity policy file (XML file) where you can easily find it. You will need to edit this file later to enforce the CI policy or merge in changes from future updates made to the system.
  • Now, apply the CI policy to your reference host. Each host may only have one CI policy applied at a given time. To apply a CI policy, perform the following steps:

    Copy the binary CI policy file (HW1CodeIntegrity.p7b) to the following location on your reference host (the filename must exactly match): C:\Windows\System32\CodeIntegrity\SIPolicy.p7b

    • Restart the host to apply the policy.
  • Test the code integrity policy by running a typical workload representative of your production environment on the reference machine. This may include running VMs, any fabric management agents, backup agents, or troubleshooting tools on the machine. Check if there are any code integrity violations and update your CI policy if necessary (see guidance in the Audit code integrity policies section of the Device Guard Deployment Guide).
  • Change your CI policy to enforced mode by running the following commands against your updated CI policy XML file.

    Set-RuleOption -FilePath 'C:\temp\HW1CodeIntegrity.xml' -Option 3 -Delete

    ConvertFrom-CIPolicy -XmlFilePath 'C:\temp\HW1CodeIntegrity.xml' -BinaryFilePath 'C:\temp\HW1CodeIntegrity_enforced.p7b'

  • Apply the CI policy to all of your hosts (with identical hardware and software configuration) using the following commands:

    Copy-Item -Path '<Path to HW1CodeIntegrity\_enforced.p7b>' -Destination 'C:\Windows\System32\CodeIntegrity\SIPolicy.p7b'

    Restart-Computer

Note: Be careful when applying CI policies to hosts and when updating any software on these machines. Any kernel mode drivers that are non-compliant with the CI Policy may prevent the machine from starting up. For best practices regarding CI policies, see Planning and getting started on the Device Guard deployment process and Deploy Device Guard: deploy code integrity policies.

  • Provide the binary file (in this example, HW1CodeIntegrity_enforced.p7b) to the HGS administrator so they can register the CI policy with HGS.

Capture the TPM baseline for each unique class of hardware

A TPM baseline is required for each unique class of hardware in your datacenter fabric. As before, we recommend that you use a "reference host" that represents each unique class of hardware configuration in your datacenter. You do not need to collect the baseline for each individual host in your environment.

  • On the reference host, make sure that the Hyper-V role and the Host Guardian Hyper-V Support feature are installed.

Warning: The Host Guardian Hyper-V Support feature enables Virtualization-based protection of code integrity that may be incompatible with some devices. We strongly recommend testing this configuration in your lab before enabling this feature. Failure to do so may result in unexpected failures up to and including data loss or a blue screen error (also called a stop error).

Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

  • To capture the baseline policy, run the following command in an elevated Windows PowerShell console.

    Get-HgsAttestationBaselinePolicy -Path 'HWConfig1.tcglog'

Note: You will need to use the -SkipValidation flag if the reference host does not have Secure Boot enabled, an IOMMU present, Virtualization Based Security enabled and running, or a code integrity policy applied. These validations are designed to make you aware of the minimum requirements of running a shielded VM on the host. Using the -SkipValidation flag does not change the output of the cmdlet; it merely silences the errors.

  • Provide the TPM baseline (TCGlog file) to the HGS administrator so they can register it as a trusted baseline.

Configure Hyper-V hosts as Guarded

After you have confirmed the HGS server configuration by running diagnostics, HGS is ready to accept information that will come from the fabric administrator. The information that is needed, and the steps for adding it to HGS, depend on the mode of attestation:

  • Add host information for Admin-trusted attestation
  • Add host information for TPM-trusted attestation, later in this topic.

Add host information for Admin-trusted attestation

The following two sections describe how to add configure necessary DNS forwarding, and add necessary host information to HGS for Admin-trusted attestation:

Configuring DNS forwarding and domain trust

For Admin-trusted attestation, use the following steps to set up necessary DNS forwarding from the HGS domain to the fabric domain, and to establish a one-way forest trust to the fabric domain. These steps are necessary because this attestation mode identifies legitimate hosts through a designated Active Directory security group in the fabric (host) domain. To allow HGS to locate the fabric domain's domain controllers and validate group membership, you must configure a DNS forwarder and establish a one-way forest trust to the fabric domain.

  • Configure a DNS forwarder that allows HGS to resolve resources located in the fabric (host) domain. There are many different ways to configure a DNS forwarder, and you can use any forwarder you choose. As one example, to create a conditional DNS forwarder zone, in the HGS domain, run the following command.

    Add-DnsServerConditionalForwarderZone -Name "fabrikam.com" -ReplicationScope "Forest" -MasterServers <DNSserverAddress1>, <DNSserverAddress2>

Note: To enable high availability and ensure resiliency against a DNS node failure, configure your forwarder to point to more than one DNS server in the fabric domain.

  • To create a one-way forest trust from the HGS domain to the fabric domain, use the Active Directory Domains and Trusts management console or run the following command in an elevated Command Prompt:

    netdom trust relecloud.com /domain:fabrikam.com /userD:fabrikam.com\Administrator /password:<password> /add

Adding security group information to the HGS configuration

For Admin-trusted attestation, the fabric administrator creates a security group, and places the intended guarded hosts into that group, as described in Create a security group and place hosts in the group. You, the HGS administrator, must obtain the SID of that security group from the fabric administrator. Then you can complete the following steps.

  • On an HGS server, run the following command to register the security group with HGS as an Attestation Host Group. You can re-run the command if necessary for additional Attestation Host groups.

    For GuardedHostGroup, provide a friendly name for the guarded host group in HGS - this is useful if you need to differentiate one Attestation Host group from another in different domains. This name does not need to match the Active Directory security group name but it does not support spaces or common punctuation other than hyphens.

    For SID, copy the SID as formatted in the output from the host domain (don't forget to wrap it in quotes).

    Add-HgsAttestationHostGroup -Name "<GuardedHostGroup>" -Identifier "<SID>"

  • To verify that the guarded host group was successfully added, run Get-HgsAttestationHostGroup. The friendly name of your group should appear.

This completes the process of configuring an HGS cluster for Admin-trusted attestation. The fabric administrator might need you to provide two URLs from HGS before the configuration can be completed for the hosts. To obtain these URLs, on an HGS server, run Get-HgsServer.

Add host information for TPM-trusted attestation

For TPM-trusted attestation, the fabric administrator captures three kinds of host information, each of which needs to be added to the HGS configuration:

  • A TPM identifier (EKpub) for each Hyper-V host
  • Code Integrity policies, a white list of allowed binaries for the Hyper-V hosts
  • A TPM baseline (boot measurements) that represents a set of Hyper-V hosts that run on the same class of hardware

The process that the fabric administrator uses is described in TPM-trusted attestation for a guarded fabric - capturing information required by HGS.

After the fabric administrator captures the information, you, the HGS administrator, can add it to the HGS configuration as described in the following procedure.

  • Obtain the XML files that contain the EKpub information and copy them to an HGS server. There will be one XML file per host. Then, in an elevated Windows PowerShell console on an HGS server, run the command below. Repeat the command for each of the XML files.

    Add-HgsAttestationTpmHost -Path <Path><Filename>.xml -Name <HostName> -Force

Note: The -Force flag is used here to bypass a validation of the EKcert of the host's TPM. Hosts using TPMs without an EKcert or with an EKcert issued by an authority your HGS server does not trust will throw an error without the use of -Force. For the highest level of security, do not use the -Force flag, so that you will be alerted to potentially untrustworthy TPMs.

  • Obtain the code integrity policy that the fabric administrator created for the hosts, in binary format (*.p7b). Copy it to an HGS server. Then run the following command.
    • For PolicyName, specify a name for the CI policy that describes the type of host it applies to. A best practice is to name it after the make/model of your machine and any special software configuration running on it.
    • For Path, specify the path and filename of the code integrity policy.

    Add-HgsAttestationCIPolicy -Path <Path> -Name '<PolicyName>'

  • Obtain the TCGlog file that the fabric administrator captured from a reference host. Copy the file to an HGS server. Then run the following command. Typically, you will name the policy after the class of hardware it represents (for example, "Manufacturer Model Revision").

    Add-HgsAttestationTpmPolicy -Path <Filename>.tcglog -Name '<PolicyName>'

This completes the process of configuring an HGS cluster for TPM-trusted attestation. The fabric administrator might need you to provide two URLs from HGS before the configuration can be completed for the hosts. To obtain these URLs, on an HGS server, run Get-HgsServer.

Validate Host Guardian Service Deployment

Now, we need to validate that things are working as expected, confirming that Hyper-V hosts can run as guarded hosts.

If the procedures for capturing information about the hosts and adding it to the HGS configuration have been completed successfully, attestation will succeed on the hosts.

Complete the following steps on at least one host that will run as a guarded host:

  • If you have not already installed the Hyper-V role and Host Guardian Hyper-V Support feature, install them with the following command:

    Install-WindowsFeature Hyper-V, HostGuardian -IncludeManagementTools -Restart

  • Configure the host's Key Protection and Attestation URLs:

    You can configure the Key Protection and Attestation URLs by executing the following command in an elevated Windows PowerShell console. For , use the FQDN of your HGS cluster (for example, hgs.relecloud.com, or ask the HGS administrator to run the Get-HgsServer cmdlet on the HGS server to retrieve the URLs).

    Set-HgsClientConfiguration -AttestationServerUrl 'http://<FQDN>/Attestation' -KeyProtectionServerUrl 'http://<FQDN>/KeyProtection'

Notes

If the HGS administrator enabled HTTPS on the HGS server (as described in the Initialize HGS server with an HTTPS Certificate section in the HGS server topic), when specifying the host's Key Protection and Attestation URLs, remember to begin the URLs with https:// rather than http://.

If the HGS administrator enabled HTTPS on the HGS server, and used a self-signed certificate, you will need to import the certificate into the Trusted Root Certificate Authorities store on every host. To do this, run the following command on each host machine:

Import-Certificate -FilePath "C:\temp\HttpsCertificate.cer" -CertStoreLocation Cert:\LocalMachine\Root

  • To initiate an attestation attempt on the host and view the attestation status, run the following command:

    Get-HgsClientConfiguration

    The output of the command indicates whether the host passed attestation and is now guarded. If IsHostGuarded does not return True, you can run the HGS diagnostics tool, Get-HgsTrace, to investigate. To run diagnostics, enter the following command in an elevated Windows PowerShell prompt on the host:

    Get-HgsTrace -RunDiagnostics -Detailed

Create shielded VM fabric artifacts

Prepare template disks

We must ensure that the disk meets the following BitLocker requirements:

  • Is formatted with the NTFS file system.
  • Does not use Dynamic Volume.
  • Has at least two partitions.
    • One partition must include the drive on which Windows is installed. This is the drive that BitLocker will encrypt.
    • The other partition is the active partition, which remains unencrypted so that the VM can be started.

New-VHDX -Path template.vhdx

Create shielded templates

Generate a self-signed certificate to sign the disk:

$certificate = New-SelfSignedCertificate -DnsName publisher.signingcertificate.com -CertStoreLocation $certStoreLocation -KeyExportPolicy Exportable

Create a signed disk template:

# $certificate is used to sign the template disk

# Specify a disk name and version

# .VHDX image is modified by embedding the .VSC file in it so making a copy of the image is recommended

$TemplatePath = 'C:\protected_template.vhdx'

$TemplateName = 'MyTemplate'

$Version = '1.1.1.1'

Copy template.vhdx $TemplatePath

Protect-ServerVHDX -Path $TemplatePath -TemplateName $TemplateName -Version $Version -Certificate $certificate

Note: For creating a signed disk template without Powershell, we can also use the Template Disk Wizard which is included with Windows Server 2016, and can be found at the following path C:\Windows\System32\TemplateDiskWizard.exe

Create shielded VM tenant artifacts

Obtain guardian keys from guarded fabric

The guardian key metadata can be accessed at the following URL http://$HGSDomain/KeyProtection/service/metadata/2014-07/metadata.xml, which we will reference to assist in the creation of the PDK file we require

$url="http://$HGSDomain/KeyProtection/service/metadata/2014-07/metadata.xml"

(New-Object System.Net.WebClient).DownloadFile($url, $GuardianMetadataPath)

New-HgsGuardian –Name $OwnerName -GenerateCertificates

Import-HgsGuardian -Path $GuardianMetadataPath -Name $GuardianName -AllowUntrustedRoot

Create owner keys to protect your Shielded VMs

Create a remote desktop certificate to log on to the Shielded VMs as a personal information file (.PFX) file.

# $rdpcertificate.thumbprint will be added in the unattended file

$rdpcertificate = New-SelfSignedCertificate -DnsName ts.examplerdpcertificate.com -CertStoreLocation $certStoreLocation -KeyExportPolicy Exportable

$rdpcertificatepassword = ConvertTo-SecureString -AsPlainText $rdpCertPasswd -Force

Export-PfxCertificate -Cert $rdpcertificate -Password $rdpcertificatepassword -FilePath $rdpPath

$rdpcertificate.thumbprint

Obtain volume signatures for trusted template disks

Extract the VSC file from the signed disk template:

$TemplatePath = 'C:\protected_template.vhdx'

$VSCPath = 'c:\vsc.vsc'

# The VSC file describes the template that the .PDK file can be applied to

Save-VolumeSignatureCatalog -TemplateDiskPath $signedTemplate -VolumeSignatureCatalogPath $VSCPath

Create shielding data and upload to guarded fabric

An Unattend.XML file containing the secret information to include in the Shielded VM is required when generating a PDK file. The RDP certificate thumbprint and password should be included in the unattended.

<unattend xmlns="urn:schemas-microsoft-com:unattend">

<servicing/>

<settings pass="specialize">

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<ComputerName>@@ComputerName@@</ComputerName>

<ProductKey>@@ProductKey@@</ProductKey>

</component>

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Deployment" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<RunSynchronous>

<RunSynchronousCommand wcm:action="add">

<Order>1</Order>

<!-- Update with your certificate password -->

<Path>certutil -p "Passw0rd" -importpfx %SYSTEMDRIVE%\temp\RDPCert.pfx</Path>

<WillReboot>OnRequest</WillReboot>

<Description>Import certificate</Description>

</RunSynchronousCommand>

<RunSynchronousCommand wcm:action="add">

<Description>If there is one, copy original setupcomplete.cmd to a unique file</Description>

<Order>2</Order>

<Path>cmd /C if exist {%WINDIR%\Setup\Scripts\SetupComplete.cmd} (copy %WINDIR%\Setup\Scripts\SetupComplete.cmd %WINDIR%\Setup\Scripts\SC3746EE82-EA9D-423E-B99F-510F9D7FF4F5.cmd /y)</Path>

</RunSynchronousCommand>

<RunSynchronousCommand wcm:action="add">

<Order>3</Order>

<Description>mkdir Scripts since Windows looks for SetupComplete.cmd in that dir. If the dir exists, it should be fine.</Description>

<Path>cmd.exe /C mkdir %WINDIR%\Setup\Scripts</Path>

</RunSynchronousCommand>

<RunSynchronousCommand wcm:action="add">

<Order>4</Order>

<Description>Put certificate configuration command in SetupComplete.cmd</Description>

<Path>cmd /C echo wmic /namespace:\\root\cimv2\TerminalServices PATH Win32_TSGeneralSetting Set SSLCertificateSHA1Hash="B0ECC19BF8397EE2661046334DB59F9E4ED0329F" >> %WINDIR%\Setup\Scripts\SetupComplete.cmd</Path>

</RunSynchronousCommand>

<RunSynchronousCommand wcm:action="add">

<Order>5</Order>

<Description>Put shutdown VM in SetupComplete.cmd</Description>

<Path>cmd /C echo shutdown /s /f >> %WINDIR%\Setup\Scripts\SetupComplete.cmd</Path>

<WillReboot>OnRequest</WillReboot>

</RunSynchronousCommand>

</RunSynchronous>

</component>

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-TerminalServices-LocalSessionManager" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<fDenyTSConnections>false</fDenyTSConnections>

</component>

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Networking-MPSSVC-Svc" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<FirewallGroups>

<!-- Allow RDP connections through the firewall -->

<FirewallGroup wcm:action="add" wcm:keyValue="RDGroup">

<Active>true</Active>

<Group>@FirewallAPI.dll,-28752</Group>

<Profile>all</Profile>

</FirewallGroup>

</FirewallGroups>

</component>

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-TerminalServices-RDP-WinStationExtensions" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<UserAuthentication>0</UserAuthentication>

</component>

</settings>

<settings pass="oobeSystem">

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-Shell-Setup" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<OOBE>

<HideEULAPage>true</HideEULAPage>

<SkipUserOOBE>true</SkipUserOOBE>

</OOBE>

<UserAccounts>

<AdministratorPassword>

<Value>Passw0rd</Value>

<PlainText>true</PlainText>

</AdministratorPassword>

</UserAccounts>

<TimeZone>@@TimeZone@@</TimeZone>

</component>

<component xmlns:wcm="http://schemas.microsoft.com/WMIConfig/2002/State" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" name="Microsoft-Windows-International-Core" processorArchitecture="amd64" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS">

<UserLocale>en-US</UserLocale>

<SystemLocale>en-US</SystemLocale>

<UILanguage>en-US</UILanguage>

<InputLocale>0409:00000409</InputLocale>

</component>

</settings>

</unattend>

Generate a pdk file:

$owner = Get-HgsGuardian -Name $OwnerName

$guardian = Get-HgsGuardian -Name $GuardianName

# Policy can be either EncryptionSupported or Shielded

Protect-ShieldingDataFile -ShieldingDataFilePath $PdkOutputPath -Owner $owner -VolumeIDQualifier (New-VolumeIdQualifier -VolumeSignatureCatalogFilePath $VscPath -VersionRule Equals) -WindowsUnattendFile $UnattendedPath -OtherFile $RdpCertPath -Guardian $guardian -Policy Shielded

Note: For creating a signed disk template without Powershell, we can also use the Template Disk Wizard which is included with Windows Server 2016, and can be found at the following path C:\Windows\System32\ShieldingDataFileWizard.exe

Deploy and Manage Shielded VMs

Create new shielded VMs on guarded fabric

Using Powershell, we can create our new Virtual Machine, and allocate the shielding data we just defined

$vm = New-VM -Name $VMName -Generation 2 -VHDPath $TemplateVhdxPath -SwitchName "external"

$pdk = Invoke-CimMethod -ClassName Msps_ProvisioningFileProcessor -Namespace root\msps -MethodName PopulateFromFile -Arguments @{FilePath=$pdkFilePath }

# the Key Protector contains the data regarding guarded hosts

# it's mandatory to pass a KeyProtector in order to enable the vtpm

$kp = $pdk.ProvisioningFile.KeyProtector

$vm | Set-VMKeyProtector -KeyProtector $kp

# If during generating the pdk, the Policy was set to Shielded then $isShielded is $True

$vm | Set-VMSecurityPolicy -Shielded $isShielded

$vm | Enable-VMTPM

# The unattended file can contain substitution strings for ComputerName, TimeZone, ProductKey.

# The corresponding values or SpecializationDataPairs must be specified and will be added to a .fsk file

New-ShieldedVMSpecializationDataFile -ShieldedVMSpecializationDataFilePath $fskFilePath `

-SpecializationDataPairs @{"@@ComputerName@@" = "MyNewComputer"; `

"@@TimeZone@@" = "Pacific Standard Time"}

Initialize-ShieldedVM -ShieldingDataFilePath $pdkFilePath -ShieldedVMSpecializationDataFilePath $fskFilePath -VirtualMachine $vm

If you check vm's settings, you'll see that the vm is shielded. The vm can be migrated on any host, but only the guarded ones will have access to vm's data.