Join Host Guardian Servers to an existing bastion forest

This post has been republished via RSS; it originally appeared at: Data Center Security articles.

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:

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:



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.aspx 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

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.