RD Gateway: Deployment options, workgroup, or domain joined

The RD Gateway is designed to secure access to remote desktop deployments from untrusted networks. There are several options for its placement in the network. Another criterion is whether and how to integrate it with AD.

The RD Gateway allows RDP clients to communicate over the internet through an HTTPS tunnel, thus saving organizations the need to set up a VPN. Talking to the RD Session Host, the gateway uses pure RDP on port 3389 by default. Access can be restricted to certain resources and users.

Relationship to RD Web Access ^

The RD Gateway is one of several server roles for Remote Desktop Services. RD Web Access, another RDS role, is also an entry point for remote desktop clients. It allows the start of a desktop or a RemoteApp from the web browser.

Remote Desktop in RD Web Access

Remote Desktop in RD Web Access

Accordingly, one could assume that RD Web Access could be used as an alternative to an RD Gateway. But this is not the case. As expected, the clients can also access the web interface via HTTPS, but opening an application leads to an unsecured RDP connection to a session host. RD Web Access can, however, be combined with a gateway to make access easier for users.

Placement of the gateway in the internal network ^

In a simple configuration, you could place the RD Gateway in the LAN and open firewall port 443 for external access to the gateway. You also need a public DNS record so that clients can resolve the name of the gateway.

How a reverse proxy works

How a reverse proxy works

However, this configuration is not very secure, as it allows an intruder to move laterally through the network if he compromises the RD Gateway. You can therefore protect it by placing a reverse proxy in the DMZ, which forwards the requests via HTTPS through the firewall to the gateway.

Gateway in the DMZ ^

Alternative deployment options assume that an RD Gateway does not run in the internal network, but rather in the DMZ, which is usually shielded internally and externally by firewalls.

In the internal facing firewall, port 3389 must be open for the RDP toward the LAN and externally port 443 for the SSL connection from the internet. However, if the RD Gateway is a member of an AD domain, then a whole series of ports must be opened toward the internal network for communication with the DC.

An older post from Microsoft's RDS Team Blog lists the following functions that require access to internal resources:

  • Authentication and authorization of users
  • Resolving the names of internal resources
  • Obtaining the certificate revocation list
  • Sending RADIUS requests (if a central NPS server is used)
Communication of an RD Gateway in the DMZ, which is a member of a domain, with the internal network

Communication of an RD Gateway in the DMZ, which is a member of a domain, with the internal network

Reduced traffic with a workgroup server ^

Much of this communication can be avoided by configuring the RD Gateway as a workgroup server instead of joining it to an AD domain. This has been supported since Windows Server 2008 R2.

But the configuration is more complex than with a member server, and then you have to manage all permitted users locally. In addition, GPOs are no longer available for the management of the server, and local group policies must be used instead.

RODC in the DMZ ^

To avoid extensive communication with a domain controller in the LAN and still not have to forgo the AD integration, it makes sense to place a read-only domain controller (RODC) in the DMZ.

An RODC in the DMZ authenticates remote desktop users and reduces traffic to the internal network

An RODC in the DMZ authenticates remote desktop users and reduces traffic to the internal network

The RODC belongs to the internal AD forest and authenticates remote desktop users. Its communication with the internal network is restricted to replication with the DCs in the LAN.

Dedicated forest in the DMZ ^

A similar result can be achieved if you set up your own forest in the DMZ and create a unidirectional trust relationship to the internal forest. The RDS Gateway is a member of the DMZ domain; hence, the RDP users authenticate against the DC there.

A topology with its own AD forest in the DMZ, which is connected to the internal forest via a one way trust

A topology with its own AD forest in the DMZ, which is connected to the internal forest via a one way trust

Here, AD-related traffic is reduced to that which is necessary for the trust relationship.

Also read: Install RD Gateway, assign a certificate, and configure CAP and RAP

Poll: Does your organization plan to introduce Artifical Intelligence?

Read 4sysops without ads and for free by becoming a member!

1+
1 Comment
  1. Alex Bailey 2 months ago

    Thanks for some useful advice here.

    I am right in the middle of an RD gateway deployment for a client and this was great timing. Its taken me quite a while to get up to speed with basic gateway implementation as there are quite a few pitfalls for the novice and MS documentation never leads you along a linear procedure.

    The tips here are not easily found in other places and I hadn't considered any of them before. Certainly the reverse proxy is a very good idea.

    4+

Leave a reply

Your email address will not be published. Required fields are marked *

*

© 4sysops 2006 - 2020

CONTACT US

Please ask IT administration questions in the forums. Any other messages are welcome.

Sending

Log in with your credentials

or    

Forgot your details?

Create Account