Applies To: Windows Server 2016
A shielding data file (also called a provisioning data file or 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. This topic provides information about how to create a shielding data file. Before you can create the file, you must either obtain a template disk from your hosting service provider, or create a template disk as described in Shielded VMs for tenants - Creating a template disk (optional).
To understand how this topic fits in the overall process of deploying shielded VMs, see Tenant configuration steps for shielded VMs.
For a list and a diagram of the contents of a shielding data file, see What is shielding data and why is it necessary?.
The steps in this section should be completed on a tenant machine running Windows Server 2016. That machine must not be part of a guarded fabric (that is, should not be configured to use an HGS cluster).
To prepare to create a shielding data file, take the following steps:
Then you can create the shielding data file:
Since tenants are only able to connect to their shielded VMs using Remote Desktop Connection or other remote management tools, it is important to ensure that tenants can verify they are connecting to the right endpoint. That is, to ensure that there is not a "man in the middle" intercepting the connection and recording the user's keystrokes, which may reveal important information such as an administrator password.
One way to verify you are connecting to the intended server is to install and configure a certificate for Remote Desktop Services to present when you initiate a connection. The client machine connecting to the server will check whether it trusts the certificate and show a warning if it does not. Generally, to ensure the connecting client trusts the certificate, RDP certificates are issued from the tenant's PKI. More information about Using certificates in Remote Desktop Services can be found on TechNet.
When selecting an RDP certificate to include in your shielding data file, be sure to use a wildcard certificate. One shielding data file may be used to create an unlimited number of VMs. Since each VM will share the same certificate, a wildcard certificate ensures the certificate will be valid regardless of the VM's hostname.
If you are evaluating shielded VMs and are not yet ready to request a certificate from your certificate authority, you can create a self-signed certificate on the tenant machine by running the following Windows PowerShell command (where contoso.com is the tenant's domain):
$rdpCertificate = New-SelfSignedCertificate -DnsName '\*.contoso.com'
$password = ConvertTo-SecureString -AsPlainText 'Password1' -Force
Export-PfxCertificate -Cert $RdpCertificate -FilePath .\rdpCert.pfx -Password $password
Since the signed template disk in VMM is generalized, tenants are required to provide an answer file to specialize their shielded VMs during the provisioning process. The answer file (often called the unattend file) can configure the VM for its intended role - that is, it can install Windows features, register the RDP certificate created in the previous step, and perform other custom actions. It will also supply required information for Windows setup including the default administrator's password and product key.
For information about obtaining and using the New-ShieldingDataAnswerFile function to generate an answer file (Unattend.xml file) for creating shielded VMs, see Generate an answer file by using the New-ShieldingDataAnswerFile function. Using the function, you can more easily generate an answer file that reflects choices such as the following:
Answer files used in shielding data files will be used on every VM created using that shielding data file. Therefore, you should make sure that you do not hard code any VM-specific information into the answer file. VMM supports some substitution strings (see the table below) in the unattend file to handle specialization values that may change from VM to VM. You are not required to use these; however, if they are present VMM will take advantage of them.
When creating an unattend.xml file for shielded VMs, keep in mind the following restrictions:
The unattend file must result in the VM being turned off after it has been configured. This is to allow VMM to know when it should report to the tenant that the VM finished provisioning and is ready for use. VMM will automatically power the VM back on once it detects it has been turned off during provisioning.
It is strongly recommended that you configure an RDP certificate to ensure you are connecting to the right VM and not another machine configured for a man-in-the-middle attack.
Be sure to enable RDP and the corresponding firewall rule so you can access the VM after it has been configured. You cannot use the VMM console to access shielded VMs, so you will need RDP to connect to your VM. If you prefer to manage your systems with Windows PowerShell remoting, ensure WinRM is enabled, too.
The only substitution strings supported in shielded VM unattend files are the following:
| Replaceable Element | Substitution String |
|---|---|
| ComputerName | @ComputerName@ |
| TimeZone | @TimeZone@ |
| ProductKey | @ProductKey@ |
| IPAddr4-1 | @IP4Addr-1@ |
| IPAddr6-1 | @IP6Addr-1@ |
| MACAddr-1 | @MACAddr-1@ |
| Prefix-1-1 | @Prefix-1-1@ |
| NextHop-1-1 | @NextHop-1-1@ |
| Prefix-1-2 | @Prefix-1-2@ |
| NextHop-1-2 | @NextHop-1-2@ |
When using substitution strings, it is important to ensure that the strings will be populated during the VM provisioning process. If a string such as @ProductKey@ is not supplied at deployment time, leaving the
Also, note that the networking-related substitution strings towards the end of the table are only used if you are leveraging VMM Static IP Address Pools. Your hosting service provider should be able to tell you if these substitution strings are required. For more information about static IP addresses in VMM templates, see the following in the VMM documentation:
Finally, it is important to note that the shielded VM deployment process will only encrypt the OS drive. If you deploy a shielded VM with one or more data drives, it is strongly recommended that you add an unattend command or Group Policy setting in the tenant domain to automatically encrypt the data drives.
Shielding data files also contain information about the template disks a tenant trusts. Tenants acquire the disk signatures from trusted template disks in the form of a volume signature catalog (VSC) file. These signatures are then validated when a new VM is deployed. If none of the signatures in the shielding data file match the template disk trying to be deployed with the VM (i.e. it was modified or swapped with a different, potentially malicious disk), the provisioning process will fail.
While the VSC ensures that a disk has not been tampered with, it is still important for the tenant to trust the disk in the first place. If you are the tenant and the template disk is provided by your hoster, it is important to deploy a test VM using that template disk and run your own tools (antivirus, vulnerability scanners, and so on) to validate the disk is, in fact, in a state that you trust.
There are two ways to acquire the VSC of a template disk:
The hoster (or tenant, if the tenant has access to VMM) uses the VMM PowerShell cmdlets to save the VSC and gives it to the tenant. This can be performed on any machine with the VMM console installed and configured to manage the hosting fabric's VMM environment. The PowerShell cmdlets to save the VSC are:
$disk = Get-SCVirtualHardDisk -Name "templateDisk.vhdx"
$vsc = Get-SCVolumeSignatureCatalog -VirtualHardDisk $disk
$vsc.WriteToFile(".\templateDisk.vsc")
The tenant has access to the template disk file. This may be the case if the tenant creates their own template disk which is uploaded to a hosting service provider or if the tenant can download the hoster's template disk. In this case, without VMM in the picture, the tenant would run the following cmdlet (installed with the Shielded VM Tools feature, part of Remote Server Administration Tools):
Save-VolumeSignatureCatalog -TemplateDiskPath templateDisk.vhdx -VolumeSignatureCatalogPath templateDisk.vsc
The last component in the shielding data file relates to the owner and guardians of a VM. Guardians are used to designate both the owner of a shielded VM and the guarded fabrics on which it is authorized to run.
To authorize a hosting fabric to run a shielded VM, you must obtain the guardian metadata from the hosting service provider's Host Guardian Service. Often, the hosting service provider will provide you with this metadata through their management tools. In an enterprise scenario, you may have direct access to obtain the metadata yourself.
You or your hosting service provider can obtain the guardian metadata from HGS by performing one of the following actions:
Obtain the guardian metadata directly from HGS by running the following Windows PowerShell command, or browsing to the website and saving the XML file that is displayed:
Invoke-WebRequest 'http://hgs.relecloud.com/KeyProtection/service/metadata/201 4-07/metadata.xml' -OutFile .\RelecloudGuardian.xml
Obtain the guardian metadata from VMM using the VMM PowerShell cmdlets:
$relecloudmetadata = Get-SCGuardianConfiguration
$relecloudmetadata.InnerXml | Out-File .\RelecloudGuardian.xml -Encoding UTF8
Obtain the guardian metadata files for each guarded fabric you wish to authorize your shielded VMs to run on before continuing.
Run the Shielding Data File wizard to create a shielding data (PDK) file. Here, you'll add the RDP certificate, unattend file, volume signature catalogs, owner guardian and the downloaded guardian metadata obtained in the preceding step.
Install Remote Server Administration Tools > Feature Administration Tools > Shielded VM Tools on your machine using Server Manager or the following Windows PowerShell command:
Install-WindowsFeature RSAT-Shielded-VM-Tools
Open the Shielding Data File Wizard from the Administrator Tools section on your Start menu or by running the following executable C:\Windows\System32\ShieldingDataFileWizard.exe.
On the first page, use the second file selection box to choose a location and file name for your shielding data file. Normally, you would name a shielding data file after the entity who owns any VMs created with that shielding data (for example, HR, IT, Finance) and the workload role it is running (for example, file server, web server, or anything else configured by the unattend file). Leave the radio button set to Shielding data for Shielded templates.
In the Shielding Data File Wizard you will notice the two options below:
Additionally, you must choose whether VMs created using this shielding data file will be truly shielded or configured in "encryption supported" mode. For more information about these two options, see What are the types of virtual machines that a guarded fabric can run?.
Pay careful attention to the next step as it defines the owner of your shielded VMs and which fabrics your shielded VMs will be authorized to run on.
Possession of owner guardian is required in order to later change an existing shielded VM from Shielded to Encryption Supported or vice-versa.
Your goal in this step is two-fold:
Create or select an owner guardian that represents you as the VM owner
Import the guardian that you downloaded from the hosting provider's (or your own) Host Guardian Service in the preceding step
To designate an existing owner guardian, select the appropriate guardian from the drop down menu. Only guardians installed on your local machine with the private keys intact will show up in this list. You can also create your own owner guardian by selecting Manage Local Guardians in the lower right corner and clicking Create and completing the wizard.
Next, we import the guardian metadata downloaded earlier again using the Owner and Guardians page. Select Manage Local Guardians from the lower right corner. Use the Import feature to import the guardian metadata file. Click OK once you have imported or added all of the necessary guardians. As a best practice, name guardians after the hosting service provider or enterprise datacenter they represent. Finally, select all the guardians that represent the datacenters in which your shielded VM is authorized to run. You do not need to select the owner guardian again. Click Next once finished.
On the Volume ID Qualifiers page, click Add to authorize a signed template disk in your shielding data file. When you select a VSC in the dialog box, it will show you information about that disk's name, version, and the certificate that was used to sign it. Repeat this process for each template disk you wish to authorize.
On the Specialization Values page, click Browse to select your unattend.xml file that will be used to specialize your VMs.
Use the Add button at the bottom to add any additional files to the PDK that are needed during the specialization process. For example, if your unattend file is installing an RDP certificate onto the VM (as described in Generate an answer file by using the New-ShieldingDataAnswerFile function), you should add the RDPCert.pfx file referenced in the unattend file here. Note that any files you specify here will automatically be copied to C:\temp\ on the VM that is created. Your unattend file should expect the files to be in that folder when referencing them by path.
Review your selections on the next page, and then click Generate.
Close the wizard after it has completed.