Using certificates in Remote Desktop Services
Remote Desktop Services uses certificates to sign the communication between two computers. When a client connects to a server, the identity of the server and the information from the client is validated using certificates.
Using certificates for authentication prevents possible man-in-the-middle attacks. When a communication channel is set up between the client and the server, the authority that generates the certificates vouches that the server is authentic. As long as the client trusts the server it is communicating with, the data being sent to and from the server is considered secure.
Certificates in Remote Desktop Services need to meet the following requirements:
The certificate is installed in the local computer’s “Personal” certificate store.
The certificate has a corresponding private key.
The Enhanced Key Usage extension has a value of either “Server Authentication” or “Remote Desktop Authentication” (1.3.6.1.4.1.311.54.1.2). You can also use certificates with no Enhanced Key Usage extension.
Create a Server Authentication certificate
As the name suggests, a Server Authentication certificate is required. You can use the Workstation Authentication template to generate this certificate, if necessary.
Here are the steps for creating the Server Authentication certificate from the template:
Open CERTSRV.MSC and configure certificates.
Open the Certificate Authority.
In the Details pane, expand the computer name.
Right-click Certificate Templates, and then click Manage. Right-click Workstation Authentication, and then click Duplicate Template.
On the General tab, change the Template display name to Client Server Authentication, and select Publish certificate in Active Directory.
On the Extensions tab, click Application Policies > Edit. Click Add, and then select Server Authentication. Click OK until you get back to the Properties page.
On the Security tab, select Allow Autoenroll next to Domain Computers. Click OK, and then close the Certificates Templates console.
In the certsrv snap-in right-click Certificate Templates, and then click New > Certificate Template.
Select Client-Server Authentication, and then click OK.
You can validate that the certificate was created in the Certificates MMC snap-in. When you open the new certificate, the General tab of the certificate will list the purpose as “Server Authentication.”
The easiest way to get certificates, if you control the client computers, is by using Active Directory Certificate Services. You can request and deploy your own certificates, and they will be trusted by every computer in the AD domain.
If you are going to let users to connect externally, and they are not part of your AD domain, you need to deploy certificates from a public CA, such as GoDaddy, Verisign, Entrust, Thawte, or DigiCert.
Certificate contents
In Windows 2008 and Windows 2008 R2, you connect to the farm name, which as per DNS round robin, gets first directed to the redirector, then to the connection broker, and finally to the server that hosts your session.
In Windows 2012, you connect to the connection broker, and it then routes you to the collection by using the collection name.
The certificates you deploy need to have a subject name or subject alternate name that matches the name of the server that the user is connecting to. For example, for Publishing, the certificate needs to contain the names of all the RDSH servers in the collection. The certificate for RDWeb needs to contain the FQDN or the URL, based on the name the users connect to. If you have users connecting externally, this needs to be an external name (it needs to match what they connect to). If you have users connecting internally to RDWeb, the name needs to match the internal name. For Single Sign On, the subject name needs to match the servers in the collection.
For example, imagine a Remote Desktop deployment with the following computers:
Computer name |
Description |
|---|---|
RDSH.CONTOSO.COM |
Session Host with RemoteApp configured |
RDSH2.CONTOSO.COM |
Session Host with RemoteApp configured |
RDVH1.CONTOSO.COM |
Virtualization host with VDI VMs configured |
RDVH2.CONTOSO.COM |
Virtualization host with VDI VMs configured |
RDCB.CONTOSO.COM |
Connection Broker |
RDWEB.CONTOSO.COM |
RDWeb and Gateway server |
When clients connect internally, they enter the FQDN for the server that hosts the web page, for example, RDWEB.CONTOSO.COM.
The name of the certificate needs to be the same as the URL. So in this example, “RDWEB.CONTOSO.COM.” But the connection does not end there – the connection flows from the web server to one of the session hosts or virtualization hosts and also to the connection broker. The certificate can be common on all of these servers. That is why we recommend that the Subject Alternate Name for the certificate contain the names of all the servers that are part of the deployment.
So the certificate for our example deployment would contain:
Type: Server Authentication Name: RDWEB.CONTOSO.COM SAN: RDSH1.CONTOSO.COM; RDSH2.CONTOSO.COM; RDVH1.CONTOSO.COM; RDVH2.CONTOSO.COM; RDCB.CONTOSO.COM |
This certificate approach works as long as you have five or fewer servers in your deployment. If you have more servers, you can’t use the Subject Alternate Name field (it is limited to just five servers). Instead, you need to get a wildcard certificate to cover all the servers in the deployment.
A wildcard certificate for our example deployment would contain:
Type: Server Authentication Name: RDWEB.CONTOSO.COM SAN: *.CONTOSO.COM |
Even with a wildcard certificate, you might run into problems in the following scenario if you have external users that access the deployment:
External name: RDWEB.CONTOSO.com Internal name: RDWEB.CONTOSO.local |
If you have a certificate with RDWEB.CONTOSO.COM in the name, you will see certificate errors. This is because the certificate is supposed to validate a server with the FQDN of “RDWEB.CONTOSO.COM,” but your server name is “RDWEB.CONTOSO.local.” (Changing the .com to .local occurs at your public firewall or router using port forwarding.)
In this case, you can get a certificate from a public CA with the external name (RDWEB.CONTOSO.COM) and bind it to the RD Web Access and RD Gateway roles. (These are the only roles that are exposed to the Internet.) For the RD Connection Broker – Publishing and RD Connection Broker – Enable Single Sign On roles, you can use an internal certificate with the DOMAIN.local name on it. However, be aware that this only works if your clients are connecting through RDC 8.0 or later.
The RD Gateway and Remote Desktop Client version 8.0 (and later) provides external users with a secure connection to the deployment. Once connected to the deployment, the internal certificate with the ‘.local’ name will take care of RemoteApp signing (publishing) and Single Sign On.
Selecting which certificate to use
Now that you have created your certificates and understand their contents, you need to configure Remote Desktop to use those certificates.
On the Connection Broker, open the Server Manager. Click Remote Desktop Services in the left navigation pane.
Click Tasks > Edit Deployment Properties.
In the Configure the deployment window, click Certificates.
Click Select existing certificates, and then browse to the location where you saved the certificate you created previously. Look for the file with the .pfx extension.
Import the certificate.
You can use a single certificate for all the roles if your clients are internal to the domain only, by generating a wildcard certificate (*.CONTOSO.local) and binding it to all roles.
Note that, even if you have multiple servers in the deployment, Server Manager will import the certificate to all servers, place the certificate in the trusted root for each server, and then bind the certificate to the respective roles.