First published on TECHNET on Mar 07, 2017
Shielded VM prevents unauthorized access from the host. To achieve this security assurance, there must be a role separation between the fabric admins (who manage the Guarded Hosts) and the HGS admins (who manage the Host Guardian Servers). By default, when you install the first HGS server, it will create its own forest, this will prevent a single user account (i.e. domain admin account) having full control of both the guarded hosts and the host guardian servers.
If you already have an existing bastion forest, and want to join the Host Guardian servers to it, you need to consider how you can separate the roles between fabric admins and HGS admins. In a simple analogy, fabric admins have access to the door of a container where shielded VMs live, and HGS admins have access to the key opens that door. If one single account can access to both the key and the door, he can access the shielded VM, this breaks the shielded VM security assurance goal.
In working with some customers who have deployed
ESAE (Enhanced Security Administrative Environment) forest
, I learnt the steps on how you can deploy HGS in the ESAE forest, and like to share the details in this blog post.
A few things to consider before deployment:
- In this blog post, I will use ESAE forest as an example. The steps are applicable to join HGS to any existing bastion forest. The security risks need to be evaluated, especially around fabric admin and HGS admin role separation.
- Specific to ESAE forest, because the RedCard admin (domain admin of the ESAE forest) will have full control over the production domain, the usage of RedCard admin privilege should be highly restricted and protected as this account holds both the key and has access to the door.
- There are three deployment options. Thanks to Andrej Budja who has created the following nice table to put the options into comparison. If you choose option #1, you can follow the
, published TechNet to deploy HGS. The guide provides detailed instructions from planning to the actual steps of
setting HGS servers
, which will create its own forest. If you choose option #2 or #3, the guide has a reference to
Initialize HGS in an existing bastion forest
, and lists the requirements before adding HGS to the existing forest. This blogpost provides the details on what and how to create those objects to deploy HGS in ESAE environment; I did not cover the host deployment in ESAE forest, because it should follow the ESAE guide to deploy servers in ESAE.
Prepare the ESAE environment
The example used in this blogpost is based on the default ESAE environment offered by Microsoft. Here is a screenshot of the OU structure:
These objects must be created before you configure the Host Guardian service:
|Account type||Account name||Placed in OU||Description|
|User||HGSAdmin||Red Card Admin||The account to manage HGS servers.|
|Security Group – Global||HGSAdmins||Groups||Members of this group are full admins of the Host Guardian (HGS) servers and services. Ensure HGSAdmin is a member of this group.|
|Security Group – Global||HGSViewAdmins||Groups||Members of this group can view all the configurations of Host Guardian (HGS) services, but do not have permission to change any configurations. HGSAdmin should be a member of this group.|
|Security Group – Domain Local||HGSgMSAUsers||Groups||Members of this group are HGS server cluster nodes which are part of the same HGS cluster, so they can use the same gMSA account to access the KPS service.|
|Organizational Unit||HGS Servers||Servers||This will contain all the HGS related computer objects. Ensure to add the HGSAdmins to have full control of the OU, and HGSViewAdmins to have read access to the OU.|
|Computer||HGSSvr||HGS Servers|| HGS server computer object account, must be a member of HGSgMSAUsers group. The object name must match the HGS server name in order to allow the HGS server joining to the domain.|
Ensures the HGSAdmins has full control on the object.
|Computer||HGSCluster||HGS Servers||HGS ClusterEnsures the HGSAdmins has full control on the object.|
|Computer||HGSSvcs||HGS Servers|| HGS VCO (Both HGSCluster and HGSSvcs are pre-stage per this article:|
Ensures the HGSAdmins has full control on the object.
|msDS-Group ManagedServiceAccount||HGSgMSA||Service Accounts||HGS servers use this account to access the KPS service across HGS nodes.You can use the script below to create this account|
[snippet slug=creategmsa line_numbers=false lang=bsh]
In addition, you should not use domain admin account for HGS server management. You should use the account in the HGSAdmins security group, and create a group policy to add HGSAdmins to each of the HGS server local administrator group:
Setting up HGS
Joining the ESAE domain
Logon the HGS server using a local administrator first and join the HGS server to ESAE domain:
Add-Computer -DomainName CTM.Contoso.com -Credential (Get-Credential)
Restart the computer;
Logon the HGS server using the HGSAdmin account (which should be a member of the machine local administrator group)
- Install HGS feature:
Install-WindowsFeature -Name HostGuardianServiceRole -IncludeManagementTools -Restart
- Specify the signing and encryption certificates that HGS will use (you can find more details
For testing, I used self-signed certs:
$certificatePassword = ConvertTo-SecureString -AsPlainText ‘<password>’ –Force
$signingCert = New-SelfSignedCertificate -DnsName “signing.relecloud.com”
Export-PfxCertificate -Cert $signingCert -Password $certificatePassword -FilePath ‘C:signingCert.pfx’
$encryptionCert = New-SelfSignedCertificate -DnsName “encryption.relecloud.com”
Export-PfxCertificate -Cert $encryptionCert -Password $certificatePassword -FilePath ‘C:encryptionCert.pfx’
- Add Service account
Initialize-HgsServer -UseExistingDomain -ClusterName HGSCluster -HgsServiceName HgsSvcs -JeaAdministratorsGroup HGSAdmin -JeaReviewersGroup HGSViewAdmin -ServiceAccount HGSgMSA @certParameters -TrustTPM
After initialization, you can follow the
for further configuration of the guarded hosts.