This is the second part of a two-part series on Remote Desktop Gateway. See part one here.
Remote Desktop Services, a role service found in Windows Server 2008 R2 enables you to extend the reach of business apps onto the Internet. With a little effort, applications installed to an RDS server can be delivered nearly anywhere with a network connection.
RDS by itself is often sufficient when client and server connections both lie within a protected network. Getting those apps securely extended onto the Internet, however, requires the added support of RDS’ Remote Desktop Gateway role service.
That role service can be deployed in a variety of configurations, the most effective of which make use of an Internet-facing DMZ in combination with a reverse proxy solution such as Microsoft’s Forefront Threat Management Gateway or Unified Access Gateway.
Mind you, these extra servers aren’t absolutely necessary. They are a really good idea when absolute security is a priority. There are four commonly accepted designs that add an RDG to an existing RDS environment. One option, the Threat Management Gateway or the Unified Access Gateway's reverse proxy support, is considered the industry best practice. Here's step-by-step guidance you need to get everything installed and working.
1. Acquire a server certificate. Transport Layer Security (TLS) 1.0 is the protocol used to encrypt communications between an RDG server and connecting clients. For TLS to function, you will need to acquire an SSL-compatible X.509 server certificate that will be installed onto the RDG server. While it is possible to create your own self-signed certificate, it is generally a best practice to use one obtained from a Public CA that participates in Microsoft’s Root Certificate Program Members program.
2. Build a new RDG server and install the certificate. Being a part of your RDS environment’s security infrastructure, that server should operate exclusively as an RDG server. That server will run Windows Server 2008 R2 with the RDS role and RDG role service installed. It should be added to the Active Directory domain used in your LAN. Prior to installing the role service, install the certificate you obtained in step one. Pay careful attention to the location where that certificate is installed. It must be installed into the local computer’s Personal Store to be accessible by the RDG. Note that this is not the current user’s Personal Store, which can sometimes be set as the default location for install.
More on Remote Management
How to set up Remote Desktop Services on Windows 2008 R2
Making the most of the Terminal Services Gateway
3. Install the RDG role service. With the certificate installed, navigate to Server Manager and install the RDS role along with the RDG role service. The installation will prompt for the certificate to use. The certificate installed in step two should be available in the wizard pane. If it isn’t, then it is either not installed, or has been installed to the wrong store location. Select the Gateway User Groups that are to be allowed access to internal RDS resources through the RDG.
You will also be asked to create an RD Client Authorization Policy (RD CAP) and an RD Resource Authorization Policy (RD RAP). The first of these identifies which users are permitted to access the RDG and via which authentication methods (password, smart card, or both). The second identifies which internal resources those users can then interact with after authentication. This can be either an Active Directory group of computers or all computers on the network. Accept the defaults for all remaining wizard pages.
4. Adjust RD CAP and RD RAP settings. The RDG will at this point complete its installation. Your next step after installation will be to adjust any RD CAP and/or RD RAP settings you find under the RD Gateway Manager in Server Manager. Navigate down to Connection Authorization Policies and Resource Authorization Policies to expose the policies created in the wizard. Double-clicking any policy will bring forward its control panel for making additional configurations, such as device redirection, additional requirements, timeouts, network resources, user groups, and allowed ports. Be aware that these RD CAP and RD RAP settings provide a mechanism to limit various user experience settings for connections on the Internet, such as restricting access to local hard drives. They are useful for tightening security when users connect over untrusted networks.
5. Configure the Reverse Proxy. Since the RDG operates as a point of authentication between external clients and internal resources, positioning it in the DMZ adds significant complexity in maintaining its internal domain membership. As a result, positioning a reverse proxy in the DMZ with the RDG inside the LAN gives both technologies the network resources to accomplish what they do best. Your next step will be to configure your reverse proxy server with the settings that enable it to hand off communication to the internal RDG. If that reverse proxy is a Microsoft Threat Management Gateway, you can view a detailed step-by-step guide here. You can also view the step-by-step configuration of Microsoft’s Forefront Unified Access Gateway.
6. Reconfigure RemoteApps for use with the RDG. The final step in this process requires a reconfiguration of any published RemoteApps to direct their connections through the RDG. In RemoteApp Manager, view the properties screen of any configured RemoteApp. Select the RD Gateway tab and move the radio button to Use these RD Gateway server settings. Enter in an externally resolvable server name and login method. You can select Use the same server credentials for RD Gateway and RD Session Host server if you wish to enable Single Sign-On between the RDG and the RDSH server hosting the RemoteApp. If you wish LAN clients to connect directly to the RemoteApp (and not through the RDG) while connecting from the LAN, you can also select Bypass RD Gateway server for local addresses. Once complete, republish any RDP or MSI files to clients in order for them to recognize the new configuration.
If you’ve done everything correctly, your clients should now be able to access internal resources via the Internet. Congratulations! If you’re still having issues, pay careful attention to the differences in DNS resolution between external and internal clients. This is particularly the case when external clients are given a different DNS domain than that used by internal clients.
You can follow SearchWindowsServer.com on Twitter @WindowsTT.
ABOUT THE AUTHOR
Greg Shields is a Partner and Principal Technologist with Concentrated Technology, an IT analysis and strategic consulting firm. Contact him at http://www.ConcentratedTech.com.