In this article

In this article

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.

Kristin Griffin

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 proto­col 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:

Network-Level Authentication

NLA isn’t required by default. To require the use of NLA for connecting to the RD Session Host server, select the appropri­ate 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.

Server Authentication

Set the server authentication settings from the Security Layer section. The default is Nego­tiate, meaning that client and server will both use Transport Layer Security (TLS) for server authentication, if that’s sup­ported.

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:

Do Not Connect If Authentication Fails

Warn Me If Authentication Fails

Always Connect, Even If Authentication Fails

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:

The certificate authenticity isn’t vetted at all.

The certificate isn’t trusted by clients because it’s not signed by a trusted party (such as a public CA or your company’s internal public key infrastructure solution).

If you’re implementing a farm, the name on the default certificate won’t match the RD Session host server farm name, so verifying the server identity will fail.

Signing Pooled and Personal VMs

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.

Signing RemoteApps

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:

The section where you install the certificate on RD Connection Broker is called “Virtual Desktops: Resources and Configuration,” which is misleading. The certificate installed here is not only used for signing virtual desktop infrastructure (VDI) VMs, it’s also used in the Web SSO process for signing RemoteApps when RD Connection Broker is involved. The signing certificates in RD Connection Broker and RD Session Host server RemoteApp Manager must match or Web SSO will fail.

When you start a RemoteApp, and the certificate installed on RD Connection Broker is different than the one installed on the RD Session Host servers, Web SSO won’t work. There’s no indication, however, the certificate is actually different on RD Connection Broker. The pop-up window only shows the certificate set in RemoteApp Manager, so it’s hard to tell there’s a certificate issue.

Securing the RD Web Access Site

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

Using Certificates with RDS Q & A

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:

Create a Microsoft Management Console (MMC) snap-in (type MMC in the Run or Search box)

Add the Certificates snap-in (File, Add/Remove Snap-ins)

Choose Computer Account, Add, then click OK

Navigate to the Personal folder, then into the Certificates folder

Right-click and choose Import to import the certificate you received from your CA

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:

Using Server Gated Cryptography (SGC) certificates seems to cause issues. Make sure your certificates are not SGC certificates. For more information, see the RDS Forum threads here and here.

If your connecting clients get the error, “The certificate is not valid for this usage,” the certificate chain for the certificate on the RD Session Host server may be too long. See this RDS Forum thread for more information.

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:

rdgateway.domain.com

rdweb.domain.com

sign.domain.com

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.