Certificates play a huge role in securing connections between Remote Desktop Services hosts and clients.
Asking which roles use certificates is kind of a trick question. The real answer is “all of them.” It’s important to understand where you should use certificates in Remote Desktop Services (RDS) deployments, and why you use them with each particular RDS role service.
Most roles you’ll need to configure, but some of them you won’t (such as the RD License Server). By default, you’ll need SSL (x.509) certificates at every stage of connecting to a session or hosted virtual machine (VM). You’ll use these for three main purposes: to secure communications between client and server, to confirm the identity of the server or Web site to which the client is connecting, and to sign Remote Desktop Protocol (RDP) files so your users know the RDP file comes from a trusted source and hasn’t been altered.
Here are some examples of how RDS uses certificates:
Enabling RDS functionality relies on specific technologies to support the use of certificates (see Figure 1).
Figure 1 Enabling RDS functionality brings into play certain security technologies.
TLS is the Internet Engineering Task Force (IETF) standard based on SSL version 3, published by Netscape. Some of the enhancements to TLS include new message alerts, the ability to chain certificates to an intermediary Certificate Authority (CA) certificate instead of the root CA certificate, and slightly different encryption algorithms from SSL.
Although TLS is based on SSL, the two are incompatible. TLS can, however, implement a mechanism by which it can fall back to SSL version 3 if necessary. To establish a secure communication channel between a client and server using TLS, the client and server go through a process of messaging, response and encryption (see Figure 2).
Figure 2 The two-way encryption process for establishing a secure channel.
There are two requirements for this process to work properly.
If the connection and encryption level meets those two requirements, the client and server establish communication as follows:
If any step of this sequence doesn’t work, the connection hasn’t been fully secured. What happens then depends on the Advanced tab settings on the Remote Desktop Connection (RDC) client. In the case of authentication failure, a user can choose to do any one of the following:
The exception is if the server requires a minimum security level. If that’s the case and the client can’t meet the minimum level, the connection will fail. By default, the client and server will negotiate and use the most secure connection settings they both support.
Credential caching was introduced with Windows Vista and Windows Server 2008. This enables two features—one that helps the user and one that helps protect the server.
Credential caching helps users by storing credentials for a particular connection so they don’t need to provide them every time they connect to that server (this is SSO). This speeds up the connection. Otherwise a brokered connection must be checked at each step.
On the server side, credential caching provides credentials to the server before it establishes a session. This avoids the overhead of a session if the user isn’t authorized (this is NLA).
The piece that makes credential caching work is the Credential Security Service Provider (CredSSP). This is supported by Windows 7, Windows Vista, Windows Server 2008 and Windows XP SP3. It isn’t linked to the version of RDC being used because CredSSP is part of the OS. CredSSP performs the following functions:
CredSSP enables mutual authentication of the server and client (see Figure 3).
Figure 3 Authenticating both the server and client requires a secure channel.
This authentication process takes the following steps.
One danger of communicating with a remote computer that requires you to supply your credentials is that the server might not be what you think. If it’s a rogue server impersonating a trusted one, you could inadvertently type your credentials into the wrong server. This would give attackers everything they need to connect to your domain or server.
RDP includes encryption, but the protocol doesn’t have any means to authenticate the server. That’s where TLS and CredSSP come in. Server Authentication checks the name you enter in the RDC client (or RDP file) against the name issued in the certificate specified in the RD Configuration Tool on the RD Session Host server to which it’s connected.
You can use certificates to digitally sign RemoteApp files, as well as RDP files used to connect to a pooled or personal VM (VDI). Signing these files assures the user they were created by a trusted source. It also secures the RDP file from tampering.
Signing RemoteApp files is also required for implementing Web SSO. This lets users sign in once to the RD Web Access Web site. Then they can launch RemoteApps from any farm without having to provide their credentials again.
CredSSP can’t pass credentials to RD Web Access. The user must first log in to the Web site to store their credentials. Then they won’t need to authenticate again to start RemoteApp programs. For this to work, the RemoteApps must be signed and the user must trust the certificate used to sign the RemoteApp.
RDP files created when a user launches an RDP connection from the RD Web Access Desktops tab are created on the fly. The files aren’t signed. Therefore, Web SSO won’t work when connecting to desktops. The user will have to log in to the endpoint once the connection is established. Web SSO also won’t work for connections to pooled or personal VMs.
RD Gateway uses TLS 1.0 to secure communications between RD Gateway and remote desktop clients, typically located outside your corporate network (over the Internet). TLS, as described earlier, requires an SSL certificate. You can also secure communications between clients and the RD Web Access server using a digital certificate to encrypt the Web site sessions (HTTPS).
Certificates are an essential piece of an RDS deployment. RDS uses certificates to secure communications and the features they enable. Next month, I’ll cover setting up RDS role services to use those certificates.
Not a TechNet Subscriber?
Confidently evaluate Microsoft software and plan deployments with a Microsoft TechNet Subscription.