Share via

Join Host Guardian Servers to an existing bastion forest

  • Article

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:

  1. 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.
  2. 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.
  3. 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 deployment guide, 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.
Deployment options: #1: Guarded hosts in the production domain, HGS in a dedicated bastion forest (not in ESAE forest) #2: Guarded hosts in the production domain; HGS in the ESAE forest #3: Guarded hosts and HGS are in the ESAE forest
Infrastructure
  • Guarded Hyper-V Servers joined to the production domain;
  • HGS Servers deployed in a separate forest (default HGS deployment configuration per deployment guide)
  • HGS forest has a one-way trust with the production domain (covered in the deployment guide)
  • HGS Servers use a certificate from public CA or certificate from a CA independent from the production domainHGS PAWs in the HGS forest.
  • Guarded Hyper-V Servers joined to the production domain;
  • HGS Servers deployed in the ESAE forest
  • ESAE forest has a one-way trust with the production domain [In addition to the trust, ESAE forest fully managed the production forest] This is ESAE deployment guideline, orthogonal to HGS deployment
  • HGS Servers use a certificate from ESAE CA
  • Hyper-V Servers joined to the ESAE forest
  • HGS Servers deployed in the ESAE forest
  • HGS Servers use a certificate from ESAE CA
Admin model
  • Tier1Operators are local admins on the Hyper-V hosts
  • Tier1Operators use Tier 1 PAW to manage Hyper-V hosts
  • Tier1Operators do NOT have access to the VM workload
  • HGS servers managed by HGS DAs
  • HGS Admins are local admins on the HGS Servers
  • HGS Admins use dedicated HGS PAWs to manage HGS forest
  • HGS PAWs are joined to the HGS forest
  • Tier1Operators are local admins on the Hyper-V host
  • Tier1Operators use a Tier 1 PAW to manage Hyper-V Servers
  • Tier1Operators do NOT have access to the VM workload
  • HGS Admins are local admins on HGS Servers
  • HGS Admins use ESAE admin workstations to manage HGS Servers
  • HGS Admins use a smartcard to logon to the ESAE forest
  • ESAE GoldCard Admins manage the production DCs
  • ESAE GoldCard Admins use ESAE admin workstation.
  • ESAE forest is managed by  ESAE RedCard Admins
  • RedCard Admins are local admins on the Hyper-V host
  • Hyper-V Admins are local admins on the Hyper-V hosts
  • Hyper-V admins use ESAE admin workstation to manage Hyper-V Servers.
  • Hyper-V Admins do NOT have access to the VM workload
  • HGS Admins are local admins on HGS Servers
  • HGS Admins use ESAE admin workstations to manage HGS Servers
  • ESAE GoldCard Admins manage the production DCs.
  • ESAE GoldCard Admins use ESAE admin workstation.
  • ESAE forest is managed by  ESAE RedCard Admins
Residual Risk
  • Secure deployment of the bastion forest (default HGS deployment)
  • Secure operations (PAWs) of the bastion forest
  • RedCard Admins control HGS Admins AND Tier1Operators (allowing them access to the doors and keys)
  • HGS Admins have local administrator permissions on HGS Servers inside ESAE (can attack ESAE from within ESAE)
  • More users in ESAE
  • Increased attack surface for ESAE
  • RedCard Admins control HGS Admins AND Hyper-V Servers (allowing them access to the doors and keys)
  • Hyper-V Admins have local administrator permissions on Hyper-V Servers inside ESAE (can attack ESAE from within ESAE)
  • HGS Admins have local administrator permissions on HGS Servers inside ESAE (can attack ESAE from within ESAE)
  • Even more users in ESAE
  • Increased attack surface for ESAE
Recommendation order 1 2 2

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:

esae-ou

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: https://technet.microsoft.com/en-us/library/dn466519.aspxEnsures 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:

gpo

Setting up HGS

  1. 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;

  1. Configure HGS:

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 here)

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
  Install-ADServiceAccount 'HgsGMSA'
  • Initialize HGS:
 Initialize-HgsServer -UseExistingDomain -ClusterName HGSCluster -HgsServiceName HgsSvcs -JeaAdministratorsGroup HGSAdmin -JeaReviewersGroup HGSViewAdmin -ServiceAccount HGSgMSA @certParameters  -TrustTPM

After initialization, you can follow the deployment guide for further configuration of the guarded hosts.