How to generate TLS certificates for a highly available Remote Desktop Gateway Farm

Introduction

In this blog post, I am going to show you how to generate, import, test, and troubleshoot a properly created Transport Layer Security (TLS) certificate for a Remote Desktop Gateway (RD Gateway) farm.

Secure management of your Amazon Elastic Compute Cloud (Amazon EC2) instances for Microsoft Windows Server is a top priority for any security-minded cloud or system administrator. One way to securely manage your instances is to use a highly available farm of RD Gateway. However, generating a proper certificate for secure TLS-based communication is not always straightforward.

I will detail the attributes of a proper TLS certificate for a highly available farm of RD Gateway, walk you through how to deploy the certificate and then show you how to test the farm following the certificate deployment.

Solution overview

The proposed architecture is depicted in Figure 1:

Figure 1: Architecture diagram of a highly available RD Gateway farm on AWS

Amazon Web Services (AWS) recommends using the AWS Launch Wizard for Remote Desktop Gateway to deploy such infrastructure. AWS Launch Wizard simplifies the process of deploying, configuring, and sizing Windows Server workloads running RD Gateway on AWS, adhering to the AWS Well-Architected Framework. AWS Launch Wizard deployments highlight best practices for high availability, fault tolerance, and security.

Prerequisites

RD Gateway certificate requirements

An AWS load balancer will be deployed as a part of this solution. You will use a DNS name assigned to this load balancer as your RD Gateway address when you’re setting up your RDP connection. All client-gateway communication is secured by TLS, so this DNS name should be covered by either the Common Name (CN) or Subject Alternative Name (SAN) field of the computer certificate installed on each RD Gateway node. Wildcard certificates (certificates covering the whole namespace using *, like *. <mydomain>.com) are also accepted.

To generate the RD Gateway certificate, you have two options:

• Public Certificate Authority (CA): This is the more common use case as RD Gateways are typically public-facing over the internet. In this case, you won’t be able to generate a certificate that has the load balancer endpoint DNS name directly in its attributes. This is because you won’t have authority over the “amazonaws.com” domain, which is used to generate the load balancer DNS name. Here is what you can do instead:
  • Create a CNAME record in a DNS zone that you own and have it point to the DNS name of the load balancer.
  • Request a certificate that covers that CNAME record. You can do this because you have authority over the CNAME zone.

• Private Certificate Authority (CA) or a self-signed certificate: In this case, you can either put the load balancer DNS name directly in the cert fields or follow the same CNAME-based process, as discussed earlier. The Certificate Authority you use for this step needs to be trusted by the client workstations that will connect to this RD Gateway farm to manage your Amazon EC2 instances. Refer to your client operating system documentation to learn how to add a CA trust chain to the OS configuration.

AWS recommends following the CNAME approach, regardless of the CA type, because it will give you more flexibility if you need to make architectural changes to this solution later.

NOTE: Technically, you can put the load balancer’s public IP address in the certificate, but hardcoding IP addresses in any configuration is a bad operational practice that AWS strongly discourages.

NOTE: If your certificate has the Enhanced Key Usage extension, make sure that “Server Authentication” or “Remote Desktop Authentication” is listed in the extension. Their object IDs (OID) are 1.3.6.1.5.5.7.3.1 and 1.3.6.1.4.1.311.54.1.2, respectively.

Finally, you will need to have access to the public and private key of the certificate to install it on each of the RD Gateway nodes. Please note that .pfx is the certificate file format in Windows that has both a public and private key. Make sure you have access to the certificate file and know the password since these files are usually password protected. Refer to your CA documentation to learn how to generate the request, submit the request to the CA, and retrieve the certificate with the private key.

RD Gateway node requirements

All gateway nodes should have identical credentials, Connection Authorization Policies (CAPs), and Resource Authorization Policies (RAPs). In case you’ve manually created your RD Gateway on Amazon EC2 instances, you can either create identical username and passwords on each instance or join them to an Active Directory instance. CAPs and RAPs should either be manually and identically created on the RD Gateway nodes or set to be retrieved from a central RADIUS server. If you use AWS Launch Wizard, this is all taken care of for you and you’ll have a username (by default, StackAdmin), which you can use to authenticate yourself to the RD Gateway farm.

RD Gateway certificate configuration

In this example, my domain name is Awslaunchwizarddemos.com, so I will create a CNAME record for RDGateway.Awslaunchwizarddemos.com, with its value being the DNS name of my load balancer.

If you’re using an AWS load balancer, you can use the Amazon EC2 Load Balancer console to view the DNS name. If you’ve used the AWS Launch Wizard to deploy the solution, you can find the load balancer in the AWS Resource Groups -> Saved resource groups -> <Launch Wizard Group Name> -> Group resources window (Figures 2 and 3):

Figure 2: Resource List

Figure 3: Load Balancer DNS name

Walkthrough

1. Create the CNAME record in your DNS. Set the value to the load balanced DNS name.
2. Create a certificate using the CNAME (RDGateway.Awslaunchwizarddemos.com, in this example, or wildcard name of *.Awslaunchwizarddemos.com) as the CN of the certificate. Alternatively, you can use the CNAME value as one of the Subject Alternative Names (SAN) of the certificate.
3. Once you have the .pfx certificate file, log into one of your RD Gateway Amazon EC2 instances. You can either use the username and password you defined during the AWS Launch Wizard steps or use the key pair to retrieve the Administrator password from the Amazon EC2 console. Log in from an IP address you’ve temporarily allowed to make direct RDP connections to your Amazon EC2 instances over port 3389. If you’ve used AWS Launch Wizard to deploy these Amazon EC2 instances, you can use the LaunchWizardResourceGroupID (Figure 4) tag filter to find gateway instances in the Amazon EC2 console faster:
   

   Figure 4: Resource Group filter

4. On your local station right-click on the .pfx file and select copy, and on your RDP session paste the file in a folder on the instance (Figure 5).
   

   
   Figure 5: PFX copy

5. Delete the self-signed certificate, as you’re going to use the one generated by the CA. Press Windows+R (Command + R if you’re using a MAC keyboard) to open the “Run” window. Type “certlm.msc” and select Enter. Accept UAC permission elevation if it pops up. This will open up the Local Machine Certificate Manager MMC (Microsoft Management Console) snap-in. Navigate to Personal->Certificates. You should see a self-signed certificate with the EC2AMAZ-* name. Delete that certificate (Figure 6).
   

   Figure 6: delete self-signed certificate

6. Once the self-signed certificate is deleted, press Windows+R (Command+R) buttons again. This time, type tsgateway.msc. This will open the RD Gateway Manager MMC. If you see the warning shown in Figure 7, click No.
   

   Figure 7: certificate mismatch warning

7. Highlight the server (Figure 8). In the main pane of the MMC, you’ll see a warning sign saying “<Node Name> is not yet fully configured as a RD Gateway server”. It also shows one configuration task pending for installing the certificate (Figure 8).
   

   Figure 8: Pending Cert config

8. To address the warning message, click on View or modify certificate properties. Then select Import a certificate into the RD Gateway (Figure 9). Click on Browse and Import Certificate…
   

   Figure 9: GW Properties

9. Choose the .pfx certificate. It will ask for the password. Type in the password and click OK on all the open dialogs. Let the service restart itself when prompted (Figures 10 through 12).
   

   
   Figure 10: PFX file password prompt

   

   Figure 11: successful pfx import message

   

   Figure 12: RD service restart warning

   The warning on the RD Gateway Manager main windows is now disappeared. (Figure 13):

   
   Figure 13: cleared

10. Log out of this instance. Repeat the same steps on all other RD Gateway nodes to import the certificate on all of them.
11. You are now done configuring the gateway node certificates, so you don’t need to have direct RDP capability to them anymore. You’re now going to remove all the rules in Security Groups attached to gateway instances that allow direct connection to port 3389 (Figure 14):
    

    Figure 14: Cleanup SG

Test

To test the new RD Gateway farm, launch an Amazon EC2 instance in one of the private subnets of your VPC. When it comes to choosing a security group (SG) for this instance, make sure you choose (or create) a SG that allows TCP 3389 and UDP 3389 ports only from the SG attached to the RD Gateway instances (Figure 15).

Figure 15: picking the correct SG for a private instance

Once the test target instance is ready, connect to it through the load balancer as follows:

1. Open the Remote Desktop Connection application. Click on Show Options (Figure 16):
   

   
   Figure 16: RDP options

2. Click on Advanced->Connect from anywhere->Settings to open the RD Gateway settings. Enter your CNAME address here. If your RD Gateway instances and target instance are joined to the same Active Directory (AD) infrastructure (or a different infrastructure, but connected through an AD Trust), you can optionally check the Use my RD Gateway credentials for the remote computer option. For this example, let’s keep it simple, as none of these instances are AD joined (Figure 17):
   

   Figure 17: Defining RDP Gateway

3. Click on the General tab, copy the private IP address of the test instance in the Computer field (Figure 18). Click Connect.
   

   Figure 18: Private IP as destination

4. You will now see the first credential dialog box (Figure 19).
   

   Figure 19: RD Gateway Login Prompt

   If you’ve used the AWS Launch Wizard, type the user credential you defined as part of it. Use the “.\” prefix (.\StackAdmin if you’ve used the default name) to use a local credential. Otherwise, use that manually-created identical username or an Active Directory username, if your instances are domain joined.

5. After authentication, you will be prompted again for your credentials. This time, it will be for the actual target server. You can tell these two prompts are different by their titles. Get the credentials for the test target from the Amazon EC2 console and enter (Figure 20):
   

   Figure 20: Private instance login prompt

6. You might see a certificate warning and wonder why you’re still getting this warning despite all the certificate procedures you’ve gone through. This warning is coming from the target server and not your load balancer or RD Gateway. More info can be found here. For testing purposes, you can safely select Yes if you see this certificate warning (Figure 21):
   

   Figure 21: self-signed trust warning

7. Voila! You’re connected to a server in a private subnet with no public IP, no VPN, and no external port mapping through your RD Gateway farm. Enjoy your deployment.
   

A note on user’s policy configuration

You might run into this error (Figure 22):

“Remote Desktop can’t connect to the remote computer “<name or IP address” for one of these reasons:

1. Your user account is not listed in the RD Gateway’s permission list
2. You might have specified the remote computer in NetBIOS format (for example, computer1), but the RD Gateway is expecting an FQDN or IP address format (for example, computer1.fabrikam.com or 157.60.0.1).

Contact your network administrator for assistance.”

Figure 22: GW Auth Error

In working with customers, especially those who manually deployed their gateway Amazon EC2 instances, I’ve seen this error even when neither of the two suggested reasons apply. If customers are using the built-in “Administrator” user rather than the “StackAdmin” (or whatever username they’ve created as part of deployment), the issue can be avoided.

The probable reason for this error is that if the “StackAdmin” is only a member of the “Administrators” group and the User Account Control (UAC) Admin Approval feature policy is enabled on the RD Gateway, the gateway RAP doesn’t validate “StackAdmin” using its higher-privileged token. Instead, it picks the Standard User token, hence declining resource access. The built-in Administrator, by default, doesn’t have the UAC Admin approval mode enabled, so this issue doesn’t happen for it.

I’ve found the following workarounds:

• Disable UAC for all admins through User Account Control: Run all administrators in Admin Approval Mode group policy settings.
  OR
• Make your “StackAdmin” user a member of another group, in addition to the built-in “Administrators” group, and include that group in your RAP. Remove the user from the “Administrators” group to enhance security once your RAPs and CAPs are adjusted.

AWS Launch Wizard already takes care of this issue for you, so this shouldn’t happen if you use our automated method of deploying gateway Amazon EC2 instances. 

Conclusion

In this blog post, I demonstrated how to generate and import the proper TLS certificate on a RD Gateway to be used as part of a load-balanced farm, giving you a resilient and secure infrastructure to manage Amazon EC2 for Windows Server instances.

For more information, see how to generate a self-signed certificate through PowerShell, how to create a certificate request file, and explore the AWS Launch Wizard documentation.

For information on the technical background relayed to Microsoft Remote Desktop Services, explore the Remote Desktop Services – Access from anywhere documentation.

AWS has significantly more services, and more features within those services, than any other cloud provider, making it faster, easier, and more cost effective to move your existing applications to the cloud and build nearly anything you can imagine. Give your Microsoft applications the infrastructure they need to drive the business outcomes you want. Visit our .NET on AWS and AWS Database blogs for additional guidance and options for your Microsoft workloads. Contact us to start your migration and modernization journey today.