What is Microsoft Remote Desktop Gateway?
A Remote Desktop Gateway (RD Gateway) server is a type of gateway that enables authorized users to connect to remote computers on a corporate network from any computer with an Internet connection. RD Gateway uses the Remote Desktop Protocol (RDP) along with the HTTPS protocol to help create a more secure, encrypted connection.
In earlier versions of Remote Desktop Connection, people couldn’t connect to remote computers across firewalls and network address translators because port 3389—the port used for Remote Desktop connections—is typically blocked to enhance network security. However, an RD Gateway server uses port 443, which transmits data through a Secure Sockets Layer (SSL) tunnel.
Benefits of an RD Gateway server
- Enables Remote Desktop connections to a corporate network from the Internet without having to set up virtual private network (VPN) connections.
- Enables connections to remote computers across firewalls
- Allows you to share a network connection with other programs running on your computer. This enables you to use your ISP connection instead of your corporate network to send and receive data over the remote connection.
How does RD Gateway work?
When a client makes a connection, RD Gateway first establishes SSL tunnels between itself and the external client. Next, RD Gateway checks the client’s user (and optionally the computer) credentials to make sure that the user / computer are authorized to connect to RD Gateway. Then RD Gateway makes sure the client is allowed to connect to the requested resource. If the request is authorized then RD Gateway sets up an RDP connection between itself and the internal resource. All communication between the external client and the internal endpoint goes through RD Gateway
Connections to RD Gateway use the RDGSP protocol. RDGSP creates two SSL tunnels (one for incoming data and one for outgoing data) from the external client to RD Gateway. Once the tunnels are established the client and RD Gateway establish a main channel over each tunnel. Data between client and the destination machine is sent over the channels and RD Gateway sits in the middle proxying the data back and forth
RDGSP uses a transport to create the channels. In Windows Server 2008 R2, RDGSP used the RPC over HTTP transport. RPC over HTTP is still available for down-level RDP clients, but whenever available, RDP 8.0 clients will use the new and much more efficient HTTP transport. The difference is this: RPC over HTTP makes RPC calls for every data transfer to and from the client. This adds significant CPU overhead. The new HTTP transport does not have this overhead so it’s possible to accommodate up to twice as many RDP sessions on the same hardware.
Important Notes about Certificates
The certificate must meet these requirements:
- The name in the Subject line of the server certificate (certificate name, or CN) must match the DNS name that the client uses to connect to the TS Gateway server, unless you are using wildcard certificates or the SAN attributes of certificates. If your organization issues certificates from an enterprise CA, a certificate template must be configured so that the appropriate name is supplied in the certificate request. If your organization issues certificates from a stand-alone CA, you do not need to do this.
- The certificate is a computer certificate.
- The intended purpose of the certificate is server authentication. The Extended Key Usage (EKU) is Server Authentication (1.3.6.1.5.5.7.3.1).
- The certificate has a corresponding private key.
- The certificate has not expired. We recommend that the certificate be valid one year from the date of installation.
- A certificate object identifier (also known as OID) of 2.5.29.15 is not required. However, if the certificate that you plan to use contains an object identifier of 2.5.29.15, you can only use the certificate if at least one of the following key usage values is also set: CERT_KEY_ENCIPHERMENT_KEY_USAGE, CERT_KEY_AGREEMENT_KEY_USAGE, and CERT_DATA_ENCIPHERMENT_KEY_USAGE.
- The certificate must be trusted on clients. That is, the public certificate of the CA that signed the TS Gateway server certificate must be located in the Trusted Root Certification Authorities store on the client computer
Checklist to install the Remote Desktop Gateway Role
- Install the Remote Desktop Gateway role service.
- Obtain a certificate for the RD Gateway server.
- Create a Remote Desktop connection authorization policy (RD CAP)
- Create a Remote Desktop resource authorization policy (RD RAP)
- Configure the Remote Desktop Services client for RD Gateway.
Install the Remote Desktop Gateway Role
- Open Server Manager and select Add Roles and Features. You will get the Before you begin page. Click Next
- Select Installation Type. Choose Role based or Feature based Installation
- Select Destination Server
- Select Server Roles. Choose Remote Desktop Services
- Click Next on Features
- Click Next on Remote Desktop Services Page
- On the Select Role Services, choose Remote Desktop Gateway
- Click Add Features
- On the Network Policy and Access Screen, click Next
- Leave Network Policy Server checked
- Confirm Installation Selections and click Install
- Next launch Remote Desktop Gateway Manager by going to Server Manager > Tools > Terminal Services > Remote Desktop Gateway Manager
- Select the Servername and you will see several messages to further configure this server
- Select View or modify certificate properties
- You do not need a certification authority (CA) infrastructure within your organization if you can use another method to obtain an externally trusted certificate that meets the requirements for TS Gateway. If your company does not maintain a stand-alone CA or an enterprise CA and you do not have a compatible certificate from a trusted public CA, you can create and import a self-signed certificate for your TS Gateway server for technical evaluation and testing purpose
- I am going to use a Self-Signed Certificate. Select Create and Import Certificate.
- The following screen will come up
- It will pop up with a confirmation box below
- In the Server Farm tab, enter the name of the Remote Desktop Gateway Server and click Add
- The add the second Remote Desktop Gateway Server etc if you have one
- Now have a look at the other settings
- Look at General
- Look at Transport Setttings
- Next is RD CAP Store
- Look at Messaging
- Look at SSL Bridging
- Look at Auditing
- Now we need to define Connection Authorization Policy. Select Create connection authorization policy.
- Click Requirements and add your User Groups or Computer Groups
- Click on Device Redirection
- Click on Timeouts
- Next go back to the main console and create a resource authorization policy
- Click User Groups and add a group or groups
- Click Network Resource
- Click Allowed Ports
- Complete
- Now test your mstsc access!
Useful Step by Step Guide from Microsoft
http://technet.microsoft.com/en-us/library/cc771530%28v=ws.10%29.aspx
PDF Guide
Useful Notes about Certificates
http://go.microsoft.com/fwlink/?LinkID=74577
Useful RD Gateway Firewall Blog
Resolving Issues
- You must make sure you have the correct certificates. You must use a certificate with a SAN (Subject Alternative Name) and this must match the internal FQDN.
- You must make sure you have set up the correct RAPs and CAPs
- You used password authentication but the TS Gateway server is expecting smart card authentication (or vice versa
- Make sure you haven’t limited connections
- Check DNS for individual servers and RDS Farms
- Check Event Viewer on the Gateway Server > Event Viewer > Applications and Services Logs > Microsoft > Windows > TerminalServices-Gateway > Operational
- You may have a Port assignment conflict. You can use netstat tool to determine if port 3389 (or the assigned RDP port) is being used by another application on the Remote Desktop server
- Users must be a member of the Remote Desktop Group on the servers they want to connect to
If using RD Gateway with RD Web Access then it can be useful to check the following
- If you are using a Terminal Server Farm, you need to make sure the Start > All Programs > Administrative Tools > Remote Desktop Services > Remote Desktop Session Host Configuration has the following set for Networking
- Sometimes you may need to check NIC Order in Network Connections
- In RemoteApp Manager check you have a FQDN in your RemoteApp Deployment Settings and the port is correct
- Check RD Gateway Settings are correct. Note I have blanked out the FQDN but this should be the case in these fields
- Make sure on each individual RDS Server in a farm that you have the Connection Broker Server and the RD Web Access Server.