Virtualization: Use the RD Gateway

  • Article

The Remote Desktop Gateway can help you provide secure access to virtual machines over public networks.

Kristin Griffin

You can use the Remote Desktop (RD) Web Access role service to publish user sessions and virtual machines (VMs). However, that only works over your LAN. To enable secure access to sessions and VMs over public networks, you’ll have to use the RD Gateway.

There are specific reasons you should use the RD Gateway for both public and private networks, ways you should set it up in a typical deployment, and ways you should configure the required access policies—most having to do with maintaining a secure channel. There are also many helpful hotfixes that pertain to using this role service.

Secure Access with the RD Gateway

You can always access RemoteApps, remote desktops, and VMs on your internal network. What if you or your users want to access those resources from your favorite coffee shop or your laptop while sitting on the beach? You could open up port 3389 (the RDP port) in your firewall to enable access from public networks, but that would leave you vulnerable to attack.

This is where the RD Gateway comes into play. The RD Gateway role service provides secure access by establishing an SSL tunnel from the client to the RD Gateway. The RD Gateway acts as the middleman. It passes traffic to and from the client over port 443, and to and from the internal resource over port 3389. Any communication between the RD Gateway and the external client is also encrypted.

One difference between using the RD Gateway and a typical Virtual Private Network (VPN) solution is that VPNs provide full network access to anyone who can connect. The RD Gateway uses authorization policies to determine who can use the service and the specific resources to which they’re allowed access.

You can configure different permission sets for people depending on whether they’re connecting from within or outside the network. RD Gateway uses a two-tiered whitelist model. Users must be explicitly allowed to use RD Gateway. They must also have explicit permission to access the resources they want to use through the gateway (see Figure 1).

RD Gateway sets permissions for specific users and the resources to which they have access

Figure 1 RD Gateway sets permissions for specific users and the resources to which they have access.

A remote client will attempt to access an RDS resource through the RD Gateway. The gateway will allow and make the connection if the client is authorized to access the RD Gateway and has permission to access the requested resource. It will then create a secure tunnel between the client and the RD Gateway server. If the client isn’t authorized to connect to the RD Gateway, the client will be denied access (see Figure 2).

This is what you’ll see if you attempt an unauthorized access

Figure 2 This is what you’ll see if you attempt an unauthorized access.

If the client is authorized to access RD Gateway, but not authorized to access the requested resource, the client will still be denied access (see Figure 3).

If you have access to the RD Gateway, but not the resource, you’ll still be denied

Figure 3 If you have access to the RD Gateway, but not the resource, you’ll still be denied.

Access Filtering

The RD Gateway controls access to itself and internal RDS resources separately with two different types of access policies: RD Resource Access Policies (RD RAPs) and RD Connection Access Policies (RD CAPs). RD RAPs control the resources (RD Session Host servers and desktops with remote desktop enabled, including pooled or personal desktop VMs) any user can access. RD CAPs control which users (and optionally computers) have permission to connect to RD Gateway.

RD CAPs also control:

  • Supported authentication methods (users can authenticate via smart card or password)
  • What devices you can redirect during connection (if you disable device redirection in RD Gateway, it will be disabled even if it’s allowed by the RD client and server)
  • Optional timeouts for active and idle sessions

RD Gateway gives you a simple interface with which you can create these policies. Their storage location depends on the type of access policy. You create and store RD RAPs in RD Gateway. RD CAPs are really NPS Network Policies. Once you create RD CAPs, they’ll be visible in the RD Gateway under the Connection Authorization Policies folder. You can also open the Network Policy Service (NPS) and see the corresponding Network Policy (see Figure 4).

You can open NPS to view the corresponding Network Policy

Figure 4 You can open NPS to view the corresponding Network Policy.

These are really the same policies. RD Gateway just gives you a different view and a simpler way to manage the policies as they pertain to RD Gateway.

You can create granular access policies using multiple RD CAPs and RD RAPs, but there’s one simple rule: A user must meet the requirements of at least one RD CAP and one RD RAP in order to successfully connect to the RD Gateway (and subsequently to internal RDS resources). The user must first connect to the RD Gateway (RD CAP). Once they’ve been permitted to establish an RD Gateway connection, that user then needs permission to access an RDS resource (RD RAP). One policy is really no good without the other.

Deploying RD Gateway

The “Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit” (Microsoft Press, 2010) explains how to set up RD Gateway. At a high level, you must take these steps:

  • Add the required SSL certificate to the server
  • Install the RD Gateway role service
  • Create RD Gateway-managed groups for reference in RD RAPs
  • Create or tweak RD CAPs and RD RAPs
  • Add the RD Gateway server address to RD Web Access, RemoteApp Manager and RD Connection Broker—or to pre-created RDP files.

The RD Gateway Installation Wizard will create and install a self-signed SSL certificate to use while you’re testing out RD Gateway. You could also create this self-signed certificate afterward. Self-signed certificates aren’t verified by a trusted third party, though. You’d have to add a self-signed certificate to every client machine’s Trusted Root Certification Authorities store for the client to trust and connect to the RD Gateway server. This is impractical if the client machine isn’t a managed computer.

For live environments, you’ll want to use a certificate issued by a public CA or an in-house PKI solution. If you’ve already installed an SSL certificate, select it when prompted by the wizard before installing the RD Gateway. Install an SSL certificate by adding it to the server’s Personal Computer certificate store via the Certificates MMC snap-in.

Next, open Server Manager and install the RD Gateway role service. You can also install this role using Windows PowerShell, but some of the options you’ll get if you install using Server Manager won’t be available. The RD Gateway role service requires both the IIS and NPS role services to perform key functions, so it will automatically install them if they aren’t installed already.

RD Gateway uses IIS to make RPC calls over HTTPS, and creates NPS Network Policies (called RD Connection Authorization Policies in RD Gateway) to control who is allowed to connect. The wizard will prompt you for the SSL certificate you wish to use to secure connections. It will also walk you through creating one RD CAP and one RD RAP policy.

Next you need to set up any RD Gateway-Managed groups you might need to reference in your RD RAPs. An RD Gateway-managed group is a group of computers maintained by an RD Gateway, instead of Active Directory. Most of the time, specifying Active Directory computer groups in RD RAPs will make the most sense. If you have an RD Session Host farm, though, you’ll have to create an RD Gateway-managed group to control access to the farm via RD Gateway. Active Directory doesn’t have a way of identifying multiple RD Session Host servers by their farm name.

To create an RD Gateway-managed group, select the Resource Authorization Policies folder under the RD Gateway server in RD Gateway Manager. Click the Manage Local Computer Groups link in the Actions pane on the right side of the RD Gateway Manager window. Once you create an RD Gateway managed group containing RD Session Host farm members, you can add that group to an RD RAP.

Once your installation is complete, you can tweak your RD CAPs and RD RAPs. You can also create more authorization policies in the RD Gateway Manager. For instance, you might want to use one set of authorization policies for the sales team and another for the IT team.

To create more RD CAPs and RD RAPs, right-click the Policies folder under the RD Gateway server listed in RD Gateway Manager and select Create New Authorization Policies. This will start the Create Authorization Policies for the RD Gateway wizard. Double-click an existing RD CAP or RAP to edit its properties.

Existing policies are located in the Connection Authorization Policies and Resource Authorization Policies folders listed under the RD Gateway server in RD Gateway Manager. Once you’ve implemented an RD Gateway, clients need to reference the RD Gateway address when they access RDS resources:

  • If you publish RemoteApps in RD Web Access or use RemoteApps and Desktop Connections in Windows 7, add the RD Gateway server address to RemoteApp Manager on each RD Session Host server.
  • If you’ve implemented Virtual Desktop Infrastructure pooled and personal VMs, you need to add the RD Gateway server address to RD Connection Broker’s RD Connection Manager’s Virtual Desktops Resources and Configuration section.
  • If you give out pre-created RDP files, add the RD Gateway address to the RDP file by editing the file. Open the RDP file, click the Options button, select the Advanced tab, click the Settings button in the Connect From Anywhere section and add the RD Gateway server address. Then save the RDP file.

Verifying and Troubleshooting RD Gateway

Once you’ve set up the service, you should test it before making it widely available. To test RD Gateway connectivity, open a browser and browse to the RPC folder on your RD Gateway server.You should be prompted for credentials. Then you should get a blank page. This is the expected behavior for a working RD Gateway implementation.

Analyzing event logs on the RD Gateway server can help you understand why a user might be denied access to RD Gateway or a requested RDS resource, and how to remedy the situation. RD Gateway logs are stored in the Event Viewer at: Event Viewer\Applications and Services Logs\Microsoft\Windows\TerminalServices-Gateway.

Specify the types of events RD Gateway will log by checking or unchecking the checkboxes next to the auditing events listed on the Auditing tab of RD Gateway Manager Properties page. Here are some examples of the types of event IDs you might see, and what you should do if you have users unintentionally denied access through RD Gateway:

  • Events 302 and 303 show when a user connects and disconnects from an RDS resource through RD Gateway.
  • Events 200 and 300 indicate that a user has met the requirements of an RD CAP and RD RAP, respectively.
  • Event 201 indicates the RD CAP requirements weren’t met and the user couldn’t connect to RD Gateway. Change the RD CAP to allow the user the proper access by including an Active Directory user group of which the user is a member.
  • Event ID 304 indicates the RD CAP and RD RAP requirements were met, but the user wasn’t able to connect to the requested resource. In this case, check that the requested resource is operational, and that the user is added to the resources Remote Desktop Users group.

NPS also logs events in the Event Viewer Security log when users are granted or denied access through RD Gateway. Here are some examples:

  • Event IDs 6272 and 6278 indicate the NPS server granted a user access and gave connection authentication details in the log, including the name of the Network Policy that gave the user access.
  • Event ID 6273 shows a user met the requirements of the Network Policy named “-- RDG Marker Policy.” This is the default policy that denies access to RD Gateway. If no other Network Policy is met (that is, the user doesn’t meet any RD CAP requirements) then the requirements of this policy are met and the user is denied access.

These are the essentials of RD Gateway, including why you’d use this role service to provide remote access, how to set up the role service, and how to configure the access policies that define the rules for remote access. Next month, we’ll discuss how certificates combine with the Credential Security Support Provider to enable a feature called Network-Level Authentication (NLA) that improves the user logon experience.

Kristin Griffin

Kristin Griffin is a Remote Desktop Services MVP. She moderates a Microsoft forum dedicated to helping the server-based computing community (Remote Desktop Services) and maintains an RDS blog at blog.kristinlgriffin.com. She’s a contributor to Mark Minasi’s “Mastering Windows Server 2008” (Sybex, 2008) and “Mastering Windows Server 2008 R2” (Sybex, 2010). She also coauthored “Microsoft Windows Server 2008 Terminal Services Resource Kit” (Microsoft Press, 2008) and “Microsoft Windows Server 2008 R2 Remote Desktop Services Resource Kit” (Microsoft Press, 2010) with Christa Anderson.

Related Content

The following hotfixes regarding RD Gateway are also helpful:

RD Gateway Q&A

Q. How many connections can the RD Gateway accommodate?
A. The RD Gateway can accommodate many connections. In fact, a dual processor server with 4GB of RAM can ac­commodate more than 1,200 connections. Read the Microsoft white paper, “RD Gateway Capacity Planning in Windows 2008 R2,”  for more information on RD Gateway capacity testing and results analysis performed by Microsoft. From a licensing perspective, RD Gateway is limited to 256 simultaneous connections in Windows Server 2008 R2 Standard edition, and 50 simultaneous connections in Windows Server 2008 R2 Foundation edition. RD Gateway connections in Windows Server 2008 R2 Datacenter and Enterprise editions are unlimited.

Q. Can I use RD Gateway behind an ISA server? What about Forefront Threat Management Gateway (TMG)?
A. Yes, you can do this. Use this script to publish RD Gateway on an ISA server. You can also implement RD Gateway behind Forefront TMG. The Configuring Forefront Threat Management Gateway Integration with RD Gateway Step-by-Step Guide shows you how to use TMG as an SSL bridging device in front of RD Gateway.

Q. What kind of SSL certificate do I need to use when I configure RD Gateway?
A. You can use a regular SSL certificate, a wildcard certificate (*.domain.com) or a SAN certificate (a certificate with multiple names, like rdg.domain.com, rdwa.domain.com, rds.domain.com) with RD Gateway.

Q. How can you force connections from the Remote Desktops page of RD Web Access to use RD Gateway?
A. There’s no checkbox on the Remote Desktops tab of the RD Web Access Web site to force the use of RD Gateway, but you can make it happen by editing Desktop.aspx file from this:

if ((DefaultTSGateway != null) && (DefaultTSGateway.length> 0)) { 
RDPstr += "gatewayusagemethod:i:2\n";

to this:

if ((DefaultTSGateway != null) &&(DefaultTSGateway.length> 0)) { 
RDPstr += "gatewayusagemethod:i:1\n";

Explicitly forcing the use of RD Gateway will also speed up connections because there’s no delay while the connection attempts to connect directly over port 3389, times out and then tries again over SSL port 443.