Using certificates is an important part of securing communications for Remote Desktop Services. Here’s the rest of the story on how to install them on each of your servers.
Certificates play an important role in Remote Desktop Services (RDS) deployments. They help secure communications between client and server. They confirm the identity of the server or Web site to which you’re connecting. They also sign Remote Desktop Protocol (RDP) files to assure you they’re from a trusted source.
You should use certificates with every RDS role service. Here’s what you need to know to install certificates on each role server using local tools or Group Policy. First, you configure all RD Session Host per-server connection security settings from the General tab of the protocol listener Properties dialog box of the RD Configuration Tool. To get there, go to Administrative Tools | Remote Desktop Services | Remote Desktop Session Host Configuration. Then double-click RDP-Tcp in the Connections section of the middle pane. This is also where you add the server’s SSL certificate.
You can configure these settings on a per-server basis. You can also configure these settings using Group Policy by applying the following set of Group Policy Object (GPO) settings to the RD Session Host server organizational unit (OU) from Computer Configuration | Policies | Administrative Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Security:
NLA isn’t required by default. To require the use of NLA for connecting to the RD Session Host server, select the appropriate check box. Doing so will prevent any clients that don’t support NLA (any client running RDC prior to version 6.x and any OS that doesn’t support Credential Security Support Provider, or CredSSP) from connecting to the server. Only clients running Windows 7, Windows Vista and Windows XP SP3 support CredSSP.
Set the server authentication settings from the Security Layer section. The default is Negotiate, meaning that client and server will both use Transport Layer Security (TLS) for server authentication, if that’s supported.
You can edit this setting to force server authentication using TLS. If you can’t authenticate the server, you can set the client behavior from the settings on the Advanced tab of the Remote Desktop Client:
You can choose the certificate the server should use to authenticate itself by clicking Select near the bottom of the screen. If you click Select, you can get more details about the certificate, including what it’s used for, the name of the Certificate Authority (CA), and when it expires.
The certificate should contain the DNS name of the RD Session Host server. This will be something like rdsh1.domain.local, for example. If you’ve implemented a server farm, the certificate should contain the DNS name of the RD Session Host server farm—for example, farm.domain.local.
The RD Session Host server is set to use a self-signed certificate, by default. This certificate isn’t meant to be used in production environments for three reasons:
You can have pooled and personal virtual machines (VMs) signed by installing an SSL certificate on the RD Connection Broker using RD Connection Manager (se Figure 1).
Figure 1 You can use RD Connection Manager to sign pooled or single VMs.
Sign RemoteApps using the certificate installed in RemoteApp Manager on the RD Session Host server (see Figure 2).
Figure 2 You can also sign RemoteApps; use the certificate in RemoteApp Manager.
If you set up an RD Session Host server farm, make sure to install the exact same certificate on all RD Session Host servers in the farm, and in any other farms you deploy. That way Web single sign-on (SSO) will work across all farm members and across all farms.
To do this, export the certificate, including the private key, from one server. Import it to the other server using the Certificates snap-in in the Microsoft Management Console (MMC)—add the computer account, not the user account.
If you’re implementing Web SSO with RD Web Access and you’re using RD Connection Broker as the source in RD Web Access, then you must install the same certificate in the RD Connection Broker as you do on all RD Session Host servers (the same certificate you use to sign RemoteApps). This can be confusing for two reasons:
Check the “Introducing Web Single Sign-On for RemoteApp and Desktop Connections” blog for more information on setting up Web SSO.
Securing a Web site isn’t RDS-specific. To secure the RD Web Access Web site, add a certificate with the DNS name of the Web site in IIS (see Figure 3).
Figure 3 Adding a certificate with the DNS name can secure an RD Web Access site.
Certificates installed to the server’s Computer Personal Store that have the private key included will appear as options in the corresponding dropdown box in the Edit menu.
Configuring RD Gateway with a Certificate
The RD Gateway installation requires a certificate to encrypt communications between client and server, especially over the Internet. The SSL certificate should contain the DNS name of the RD Gateway server that external users can resolve (the external DNS name, for example: rdgateway.domain.com).
You install the RD Gateway certificate via the SSL Certificate tab in RD Gateway Manager Properties (see Figure 4). See more information on RD Gateway certificates in the TechNet Library.
Figure 4 Install the RD Gateway certificate.
You can set up certificates in your RDS deployment to secure communications and authenticate both client and server. There are specific certificate requirements for each role service. This should help you understand why you need certificates in RDS implementations, and how and where to implement certificates with each RDS role service.
Q: How do I add certificates to my server so I can use them in my Remote Desktop Services (RDS) role services?
A: Certificates located in your server’s Computer Account Personal Store will be available for you to add to RDS implementations. To add certificates to the computer Account Personal Store:
RD Gateway Manager is easier in this regard because it gives you an Import button in the interface so you don’t have to create an MMC snap-in manually.
Q: How do I suppress any warning messages when a user starts a signed Remote Desktop Protocol (RDP)file?
A: Enable the policy setting. Specify Secure Hash Algorithm (SHA1) thumbprints of certificates representing trusted .rdp publishers. When you enable this policy, you’re specifying certificates that the client will see as trusted. When you tell the client it trusts a certificate, any RDP file signed by that certificate is trusted. Thus, you won’t receive any warning pop-ups asking you to verify that you trust the publisher. Check here for more information on this setting.
Q: I have the correct certificates in place on my RD Session Host servers, but I’m still having problems connecting.
A: There are a few known issues with regards to certificates and RDS implementations:
Q: Can I use a wildcard certificate or a Storage Area Network (SAN) certificate with my RDS implementation?
A: Yes, you may. A SAN certificate is a certificate that has more than one host name. Because a SAN certificate contains multiple subject names, you can use one certificate in multiple places that require a certificate. An example of a SAN certificate might be one that contains your RD Gateway and your RD Web Access DNS names, as well as the name you’ll use to sign your RemoteApp files:
By using a wildcard certificate, you need as little as two certificates to implement a typical small farm deployment. The RD Session Host farm still needs to reference the DNS name of the farm, and this name is typically an internal DNS name (domain.local). That’s not the same as your external DNS zone (domain.com), so you’ll need to have a separate certificate for this.
Q: I have multiple role services installed on one server. Do I still need to install certificates in all the role services I have utilized?
A: Yes. Each role service uses certificates for specific purposes. Even though role services may be combined on one server, think of them as separate entities when you implement certificates.
Not a TechNet Subscriber?
Confidently evaluate Microsoft software and plan deployments with a Microsoft TechNet Subscription.