Securing Remote Desktop Services in Windows Server 2008 R2

Introduction

Remote Desktop Services (RDS) on Windows Server 2008 R2 has more than just a new name; this is not your father’s Terminal Services. With new features (some of them introduced in Windows Server 2008) such as RemoteApp, RD Gateway, and RD Virtualization Host, this Windows Server role now provides you with the flexibility to deploy individual applications or full desktops via RDS or a VDI solution – in many cases without the need for Citrix or other third party add-ons.

But what about security? All of these added complexities translate to new security challenges, too. In this article, we will look at the security mechanisms built into RDS, how you can use configuration settings and Group Policy for better security, and best security practices for an RDS deployment.

What’s New in R2

If you’re coming to RDS from Windows Server 2008 Terminal Services, you will not see as many dramatic changes as if you have upgraded from Windows Server 2003. WS 2008 added some big improvements to Terminal Services, including TS Web Access for connecting via a browser, the TS Gateway for users connecting across the Internet, RemoteApp for delivering individual applications to users over the Remote Desktop Protocol (RDP) and the Session Broker which included a load balancing feature.

WS 2008 R2 added even more goodness:

• Remote Desktop Virtualization for a VDI solution
  
  
• RDS Provider for PowerShell so admins can change configuration and perform tasks at the command line and via scripts
  
  
• Remote Desktop IP Virtualization, which allows IP addresses to be assigned to connections on a per-session or per-program basis
  
  
• A new version of RDP and the Remote Desktop Connection (RDC) client, v. 7.0
  
  
• Fair Share CPU scheduling to dynamically distribute processing time across sessions based on the number of active sessions.
  
  
• Windows Installer compatibility to make it easier to install programs that require per-user configuration.
  
  
• True multiple monitor support for up to 16 monitors, whereby programs function just as they do when running on the client computer.
  

There are also improvements to audio/video and support for Windows Aero in an RD session (however, note that Desktop Composition, which enables Aero, is not supported in a session with multiple monitors).

Security Implications and Mechanisms

Obviously, potential security issues depend on how you deploy RDS. If you have a more complex setup, with users connecting over the Internet and/or via a web browser, you’ll have more security issues to address than if you have a simple deployment where users only connect via the RDC client over the LAN.

RDS includes a number of security mechanisms to help you make RD connections more secure.

Network Level Authentication

For best security, you should require Network Level Authentication (NLA) for all connections. NLA requires that the user be authenticated to the RD Session Host server before a session is created. This helps protect the remote computer from malicious users and malware. To use NLA, the client computer must be using an operating system that supports Credential Security Support Provider (CredSSP) protocols, which means Windows XP SP3 or above, and running RDC client 6.0 or above.

NLA is configured on the RD Session Host server via Administrative Tools | Remote Desktop Services | Desktop Session Host Configuration. To configure a connection to use NLA, follow these steps:

1. Right click the Connection
   
2. Select Properties
   
3. Click the General tab
   
4. Check the box that says “Allow connections only from computers running Remote Desktop with Network Level Authentication” as shown in Figure 1
   
5. Click OK.

Figure 1

Transport Layer Security (TLS)

An RDS session can use one of three security layers for protecting communications between the client and the RDS Session Host server:

• RDP security layer – this uses native RDP encryption and is least secure. The RD Session Host server is not authenticated.
  
  
• Negotiate – TLS 1.0 (SSL) encryption will be used if the client supports it. If not, the session will fall back to RDP security.
  
  
• SSL – TLS 1.0 encryption will be used for server authentication and encryption of data sent between the client and Session Host server. This is the most secure option.

For best security practices, you can require SSL/TLS encryption. You will need a digital certificate, which can be issued by a CA (preferred) or self-signed. 

In addition to selecting the security layer, you can select the encryption level for the connection. Your choices here are:

• Low – uses 56 bit encryption for data sent from client to server. Does not encrypt data sent from server to client.
  
  
• Client Compatible – this is the default. It encrypts data sent both ways between client and server with the maximum key strength that the client supports.
  
  
• High – this encrypts data sent both ways between client and server with 128 bit encryption.
  
  
• FIPS Compliant – this encrypts data sent both ways between client and server with FIPS 140-1 validated encryption.

Note that if you select a High or FIPS Compliant level, any clients that don’t support those levels won’t be able to connect.

Here’s how you configure the server authentication and encryption settings:

1. On the RD Session Host, open Remote Desktop Session Host Configuration and the connection’s Properties dialog box as described above.
   
2. On the General tab, choose the appropriate security layer and encryption level from the drop-down boxes, as shown in Figure 2.
   
3. Click OK.

Figure 2

You can also use Group Policy to control these authentication and encryption settings, along with other aspects of RDS.

Group Policy

There are a number of Group Policy settings for RDS in Windows Server 2008 R2. These are located under Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services in the Group Policy Management Console for your domain, as shown in Figure 3.

Figure 3

As you can see, there are policies for licensing, the RDC client and the RD Session Host. The security-related policies for the RD Session Host include:

• Server Authentication Certificate Template: Use this policy to specify the name of the certificate template that determines which certificate is automatically selected to authenticate an RD Session Host server. If you enable this policy, only certificates that are created using the specified template will be considered in selecting a certificate to authenticate the RD Session Host server.
  
  
• Set Client Connection Encryption Level: This policy is used to control whether use of a specific encryption level is required. When you enable the policy, all communications must use the specified encryption level. The default encryption level setting is High.
  
  
• Always Prompt for Password upon Connection: You can use this policy to force RDS to always ask for the user’s password when logging onto an RD session, even if the password is entered in the RDC client. By default, users can log in automatically if the password is entered in the RDC client.
  
  
• Require Secure RPC Communication: Enabling this policy means only authenticated and encrypted requests from clients will be allowed. Communications with untrusted clients will not be allowed.
  
  
• Require Use of Specific Security Layer for Remote (RDP) Connections: If you enable this policy, all communications between clients and Session Host servers must use the security layer that you specify here (RDP, Negotiate or SSL/TLS)
  
  
• Do Not Allow Local Administrators to Customize Permissions: This policy disables administrator rights to customize security permissions in the RD Session Host Configuration tool, to prevent local admins from changing the user groups on the Permissions tab in the configuration tool.
  
  
• Require User Authentication for Remote Connections by using Network Level Authentication: With this policy, you can require NLA for all remote connections to the RD Session Host server. Only clients that support NLA will be able to connect.

Note:
Here’s how you can find out whether a client computer supports Network Level Authentication: Open the RDC client and click the icon in the upper left corner, then select “about“. If NLA is supported, you will see “Network Level Authentication Supported”.

Other Group Policy settings worth checking out fall under the RD Connection Client node. These include:

• Do not allow passwords to be saved: Enabling this policy will disable the checkbox to save the password in the RDC client dialog box. If a user opens an RDP file and saves his settings, previously saved passwords will be deleted. This forces the user to enter his password each time he logs on.
  
  
• Specify SHA1 thumbprints of certificates representing trusted .rdp publishers: With this policy, you can specify a list of SHA1 certificate thumbprints and when a certificate matches a thumbprint on the list, it will be trusted.
  
• Prompt for credentials on the client computer: This policy causes users to be prompted for credentials on the client computer instead of on the RD Session Host.
  
  
• Configure server authentication for client: With this policy, you can determine whether a client can establish a connection to the RD Session Host when the client cannot authenticate the RD Session Host server. Highest security setting is “Do not connect if authentication fails.”  

You can also use Group Policy to configure FIPS compliance, but you won’t find that policy here with the other RDS security policies. Instead, it’s in Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options. In the right pane, scroll down to: “System Cryptography: use FIPS compliant algorithms for encryption, hashing and signing.”  When you enable this policy, it supports only the Triple DES (3DES) encryption algorithm for RDS communications.

RD Web Access

For client computers that don’t have the RDC client software installed, users can access the published apps to which they have access using the web browser. The user goes to the URL to which the RDS resources are published. The RD Web Access Server is a separate server from the RD Session Host. You define which RD Web Access servers can connect to which RD Session Host servers.

The web interface is configured with SSL and the user must be authenticated with his/her credentials. The authenticated user will only be able to see those RemoteApp programs that his/her account is authorized to use because the published programs are “trimmed,” using an access control list (ACL).

The Web Access Server uses an X.509 certificate to provide encryption. By default, a self-signed certificate is used. For better security, you should obtain a certificate from a public CA or your company’s PKI.

RD Gateway

The RD Gateway (RDG) is used to give access to RD resources to users across the Internet. The Gateway server is located at the edge and it filters incoming RDS requests according to a Network Policy Server (NPS). The NPS uses two policies: the Connection Authorization Policy (CAP) that lists which users can access the RDG and the Resource Authorization Policy (RAP) that specifies which devices the CAP user can connect to via the RDG.

Summary

Remote Desktop Services in Windows Server 2008 R2 greatly extends the functionality of its predecessor, Terminal Services – but it also presents some new security issues that need to be addressed. Following security best practices in configuring the components of your RDS deployment – the RD Session Host, the RD Web Access Server, the RD Gateway and the client – and using Group Policy to control the configuration will help you maintain a secure environment while reaping the benefits of RDS delivery of applications and full desktops to your users.