- Delegate permissions for domain join - Mon, Jun 5 2023
- Join Windows 11 to an Active Directory domain - Thu, Jun 1 2023
- Change Windows network profiles between public and private - Wed, May 24 2023
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
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
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
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
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
Here, AD-related traffic is reduced to that which is necessary for the trust relationship.
Subscribe to 4sysops newsletter!
Also read: Install RD Gateway, assign a certificate, and configure CAP and RAP
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.