The Remote Desktop Gateway is used to secure access to internal remote desktop services from untrustworthy networks. There are several options for its placement in the network. Another criterion is whether and how to integrate an RD Gateway with the AD.
The RD Gateway allows clients from the Internet to handle RDP communication via an HTTPS tunnel and thus saves users from setting up a VPN. In the direction of the RD Session Host, the gateway uses pure RDP, which is standard via port 3389. 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 role of RDS, is also an entry point for remote desktop clients. It allows the start of a desktop or a RemoteApp from the web browser.
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 address the web interface via HTTPS, but opening an application leads to the establishment of 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, one could place the RD Gateway in the LAN and open the firewall port 443 for external access to the gateway. You also need a public DNS entry so that external clients can resolve the gateway name.
However, such a configuration is not particularly secure, as a burglar can move freely through the network if he compromises the RD Gateway. You can therefore protect it additionally by placing a reverse proxy in the DMZ, which receives the requests via HTTPS and forwards them through the firewall to the gateway.
Gateway in the DMZ
Alternative deployment options provide that an RD Gateway does not run in the internal network, but in the DMZ. It is usually shielded internally and externally by its own firewalls.
In the firewall in the direction of the LAN, port 3389 must be open for RDP and 443 for the SSL connection. However, if the RD Gateway is a member of an AD domain, then a whole series of ports must be opened in the firewall for communication with the DC.
An older one Contribution from Microsoft’s RDS Team Blog names the following functions that require additional passage in this constellation:
- Authentication and authorization of users
- Resolution of the names of internal resources
- Get the CRL
- Send RADIUS requests (if a central NPS server is present)
Less traffic with a workgroup server
This communication can be avoided if the RD Gateway is not included in the AD domain, but configured as a workgroup server. This has been possible since Windows Server 2008 R2.
However, the configuration is more complex than with a member server and then you have to manage all authorized users locally. The management of the server also eliminates GPOs, and you have to switch to local group policies.
RODC in the DMZ
In order to avoid extensive communication with a domain controller in the LAN and still not forego the AD connection, it is advisable to place a read-only domain controller (RODC) in the DMZ.
This belongs to the internal AD forest and then takes over the authentication of the remote desktop users. It is limited to replication with the DCs in the LAN.
Own forest in the DMZ
A similar result can be achieved if you set up your own overall structure in the DMZ and link it to the internal forest via a unidirectional trust relationship. The RDS gateway is a member of the DMZ domain, so that the RDP users authenticate themselves against the DC there.
Here, too, the AD-related traffic is reduced to that within the trust relationship.