Terminal Services Gateway in Windows Server 2008

 Executive Summary:

Windows Terminal Services (TS) lets users run applications on servers and administrators fully manage remote servers by connecting to the servers' desktop through RDP. In this article, I describe a new feature of TS in Windows Server 2008 called Terminal Services Gateway (TS Gateway), which lets you securely establish a terminal session with a remote machine over the Internet by using HTTP Secure (HTTPS).

How It Works
No matter if you're talking about remote administration of or running applications on remote servers, you have a potential security risk when you expose these resources to the Internet. If you want to make a server accessible via RDP to remote clients, you can use several approaches. You can open TCP port 3389 on the firewall and forward requests from Internet clients to the private IP address of the TS server in the local network. However, besides the fact that opening port 3389 can pose a security risk because it directly exposes hosts to the Internet, you also need multiple public IP addresses if you want to make more than one internal host available.

Alternatively, you can require remote users to establish a VPN connection before they start an RDP session to a server on your network. Although this solution is more secure and flexible, it can be inconvenient because many public Internet Access Points (APs) don’t have ports open for PPTP or L2TP traffic. A user on a business trip will likely be accessing the Internet via a hotel network or Internet cafe and won't have the ability to initiate a VPN connection.

TS Gateway in Windows Server 2008 solves this problem. Simply speaking, it encapsulates RDP within HTTPS (also known as RDP over HTTPS) and provides users the ability to connect to the TS Gateway server by using HTTPS's port, TCP port 443. TS Gateway authenticates the client, unpacks the RDP from HTTPS, and then forwards the connection to the desired resources by using port 3389. With TS Gateway, a client needs access only to port 443 to establish a secure RDP session.

In addition to using just one port, RDP over HTTP works with proxy servers that allow only HTTP and HTTPS for outgoing traffic. You need only one public IP address on the external network on which you'll publish the TS Gateway server. And, you can authenticate users on TS Gateway first, and then based on that authentication, allow or deny them access to specified (or all) computers in the local network configured for RDP access.

Configuring TS Gateway
Before you can configure a server as a TS Gateway, you must add the TS Gateway service to it. On the Windows 2008 server, go to Administrative Tools, Server Management, and start the Add roles wizard. Look for the TS Gateway service under the Terminal Services role, and select it. Adding the TS Gateway service also adds some other necessary services and features such as Network Policy Server, Microsoft IIS, and an RPC-over-HTTP proxy server. The wizard asks whether you want to configure a Secure Sockets Layer (SSL) certificate, Terminal Services policies, and Network Policy Server, but I recommend you do that configuration later. (I describe these steps later on in the article.) After you've finished the wizard, TS Gateway Manager will appear under Terminal Services in Administrative Tools.

Open TS Gateway Manager (which Figure 1 shows), and open the Properties dialog box of the server that you want to make a TS Gateway. On the General tab, you can limit the number of simultaneous connections to TS Gateway or disable new connections completely. The default value is to allow the maximum number of supported connections, and if you have no specific reason to change the value, leave the default.

The SSL Certificate tab has a setting that you must configure. By default, Transport Layer Security (TLS) 1.0 is used to encrypt communications between TS clients and TS Gateway servers over the Internet. In order to use encryption, you must select an appropriate computer certificate on the TS Gateway server. The certificate must have Server Authentication as its purpose and can be issued by a local Certificate Authority (CA). The certificate must have a Subject Name value equal to the public DNS name of the TS Gateway server—that is, the name users will use to connect to the server (e.g., tsg.domain.com)—or the connection won't work.

Be aware that you can't use the standard Certificate Request wizard from the Microsoft Management Console (MMC) Certificates snap-in to request the certificate. This wizard issues only certificates with the host name of the machine, and in this case, you want a certificate for a publicly available name, which is typically not the same as the local host name.

If you have an online CA, you can prepare the certificate request by using the certreq.exe utility. Or, if you don’t like command line–based utilities, you can use IIS Manager to request the certificate through a wizard. To do so, open IIS Manager, click the server name, and click Server Certificates in the right-hand pane. Select the Create Domain Certificate option, and enter the DNS name of your TS Gateway in the Common Name field. A certificate will be automatically issued and installed.

Alternatively, if you have an offline or standalone CA (i.e., a CA that's not on the network or not in Active Directory—AD), you can prepare an offline request through IIS Manager. Note that this certificate will be trusted only by domain clients. Non-domain clients will have to manually add a root (or issuing) CA certificate to their Trusted Root Certification Authorities list.

If no CA is available, you can select an option in TS Gateway Manager to create and install a self-signed certificate. I don't recommend this approach because although the encryption will work, clients won't trust the certificate for server authentication unless their users explicitly add the issuing CA to their client's Trusted Root Certification Authorities list.

The best solution, if possible, is to use a commercial certificate because most clients will probably trust it by default. After you receive a certificate from a commercial CA, you can import it by using the Certificates snap-in.

After the certificate is installed in the TS Gateway computer’s personal store, you can use the SSL Certificates tab of the TS Gateway computer's Properties dialog box to configure the gateway to use the certificate. Click Select an existing certificate for SSL encryption (recommended), then click Browse Certificates and select the certificate, as Figure 2 shows.

You use the TS CAP Store tab to configure connection authorization policies. Because TS Gateway uses Network Policy Server to control client access, all the policies that you create by using TS Gateway Manager are actually created on the Network Policy Server. (Network Policy Server is Windows 2008's replacement for Windows Server 2003's Internet Authentication Service—IAS.) You can choose a local Network Policy Server (installed on the TS Gateway system) or a remote one. On this tab, you can also enable an option to request clients to declare their state of health before they can connect if you have Network Access Protection (NAP) configured. For the purposes of this article, select the local Network Policy Server and don't select the option for clients to declare their state of health. (For information about configuring NAP, see the Windows IT Pro article “Network Access Protection in Windows Server 2008,” http://www.windowsitpro.com/articles/articleid/95617/95617.html.)

The Server Farm tab lets you group multiple TS Gateways to create a server farm for high availability of the TS Gateway service. You can't configure Network Load Balancing (NLB) on this tab; you must configure it earlier by using Windows tools. But after you've established NLB, you can use the Server Farm tab to add NLB members to a TS Gateway server farm.

The Auditing tab lets you configure logging options for TS Gateway. Simply click events that you want to log to turn on logging. TS Gateway server events appear in the MMC Event Viewer snap-in under Application and Services LogsMicrosoftWindowsTerminalServices-Gateway. I recommend that you select all available options.

The SSL Bridging tab, which Figure 3 shows, is an interesting one. It lets you configure how Microsoft ISA Server or another SSL bridging-capable device will connect to TS Gateway.

I recommend ISA Server as the bridging-capable solution because it helps enhance security by decrypting incoming SSL traffic, statefully inspecting the traffic for malicious code, and then blocking connections that contain suspicious packets or packets that reflect known exploits. ISA Server also performs stateful HTTP filtering, which provides deep inspection of HTTP application content. These functions protect TS Gateway from SSL- and HTTPS-based attacks and from attacks on lower layers of the TCP/IP stack.

The only available option on the SSL Bridging tab—Use HTTPS-HTTP bridging—isn't selected by default, which means that HTTPS-HTTPS (or SSL) bridging is used to maintain encryption from the client through ISA Server to TS Gateway. In this configuration, ISA Server will terminate the SSL session from the client, preauthenticate the user (if the listener is configured to do so), inspect the packets, and establish a new SSL session with TS Gateway server for maximum security.

Selecting the Use HTTPS-HTTP bridging option lets you terminate the SSL connection on ISA Server and, after authentication and inspection, create a new, unencrypted HTTP connection to TS Gateway. This setting, while not as secure as HTTPS-HTTPS bridging, lets you offload encryption/decryption and authentication from TS Gateway to ISA Server. Be aware that if you enable HTTPS-HTTP bridging, the TS Gateway server will depend on ISA Server to perform user authentication. If for any reason, you remove ISA Server without disabling HTTPS-HTTP bridging on TS Gateway, the gateway will let anyone connect without any authentication.

In order to allow clients to establish SSL sessions by using TS Gateway's public name, ISA Server must have the same certificate installed as the TS Gateway server.

Configuring TS Gateway Policies
After configuring the server properties, you must create connection authorization polices and resource authorization policies. By default, TS Gateway has no polices, and it won't work until you define at least one of each type.

Connection authorization policies let you select users or groups who will be allowed to pass through TS Gateway, the authentication method (smart card or password), and options for device redirection through RDP. You use resource authorization policies to select the hosts that will be available through TS Gateway, among other things.

First, we'll create a connection authorization policy. In the left-hand pane of TS Gateway Manager, right-click Connection Authorization Policies under YourTSGatewayServerPolicies, and select Create New Policy with the Custom (not wizard) option. On the General tab of the resulting dialog box, enter a name for the policy.

Go to the Requirements tab (Figure 4) to select user and computer groups that are allowed to connect to TS Gateway. You must add at least one user group (local or from AD). Note that adding a group lets the group connect only to TS Gateway; it doesn't permit the group to connect to other hosts via TS Gateway. You can also optionally add one or more computer groups if you want to restrict users to connecting from specific computers. The Requirements tab also lets you choose one or more authentication methods (password and/or smart card).

The Device Redirection tab's set of options is useful for both security and functionality reasons. It's possible to enable redirection of all devices from a remote computer, disable redirection completely, or selectively disable redirection of specific types of devices. Because device redirection through RDP can pose a potential security risk, it's a good idea to restrict it. Configure multiple connection authorization policies that set varying device redirection permissions depending on the user group and authentication method. For example, you can create one policy that forces members of the Administrators group to authenticate with a smart card but allows them full device redirection and another policy for ordinary users that allows authentication with a password but limited device redirection. Keep in mind that TS Gateway applies connection authorization policies in the same order that RRAS policies are applied.

Next, you must configure a resource authorization policy. In the left-hand pane of TS Gateway Manager, right-click Resource Authorization Policies under YourTSGatewayServerPolicies and select Create New Policy (custom). On the General tab of the resulting dialog box, enter a policy name and description. Go to the User Groups tab, and select one or more user groups (local or from AD) for the policy. Note that the user groups you specify here don’t have to be the same as in your connection authorization policy because here you're specifying groups that will have access to resources, not just to TS Gateway.

Go to the Computer Group tab (Figure 5), which is the most important one in configuring a resource authorization policy. Here you specify the computer group that the user groups you specified on the User Groups tab will have access to. You have three options. You can select an existing computer group from AD. You can select a TS Gateway–managed computer group. (After selecting this option and clicking Browse, you can create this group by entering the computers' Fully Qualified Domain Names—FQDNs—or IP addresses.) Or, you can choose to allow access to all internal computers, which is useful only if you're going to have just one resource authorization policy. As with connection authorization policies, it's a good idea to create multiple resource authorization policies in order to precisely control access to resources.

The Allowed Ports tab can be used to configure on which port the RDP session will be established. The default is TCP port 3389, but you can configure other ports or even allow all ports, which isn't recommended. Port 3389 is the well-known port for RDP. If you want to practice security by obscurity, you could configure a port other than the default.

Deploying TS Gateway
After you've configured the TS Gateway and its policies, you must properly deploy the server. If you're using ordinary firewalls, you should place the TS Gateway server in your demilitarized zone (DMZ), open TCP port 443 between your Internet-facing firewall and your TS Gateway server, and open TCP port 3389 between TS Gateway and your network-facing firewall. Note that the TS Gateway server must be a domain member, so additional ports on the network-facing firewall might be required.

If you're using ISA Server 2006 or ISA Server 2004, you can safely place the TS Gateway server on the local network and publish it via ISA Server. In this case, you'll have to copy the certificate from TS Gateway to ISA Server and optionally configure HTTPS bridging, as mentioned earlier.

Besides configuring firewalls, you must create a host in a public DNS with the name of the TS Gateway server (which must be the same as the certificate subject name) and the IP address.

Configuring TS Clients
For clients to use the TS Gateway, they must have Remote Desktop Connection 6.0 installed. To download the client, go to the Microsoft article "Remote Desktop Connection (Terminal Services Client 6.0)" (http://support.microsoft.com/kb/925876). To configure a client, start the RDP client software and enter the local DNS name of the computer that you want to connect to, click Advanced, and click Settings to configure TS Gateway–related options (which Figure 6 shows).

The default value is to automatically detect TS Gateway settings, which is sufficient if these settings are forced through Group Policy. Alternatively, you can manually enter the public name of the TS Gateway server. You can also choose to bypass TS Gateway when connecting to hosts with local IP addresses, which will allow the user to use the same RDP connection whether he or she is on the LAN or connecting from the Internet. You can also choose not to use TS Gateway at all.

After configuring these options and clicking Connect, you will first see a dialog box for authenticating to TS Gateway and then one for authenticating on the remote host. If both authentications are successful, an RDP session will start.