Problem solve Get help with specific problems with your technologies, process and projects.

Bringing Windows RDS to the web: Designing the DMZ

Remote Desktop Gateway secures Internet access for Remote Desktop Services applications – if you set it up properly.

This is the first part of a two-part series on Remote Desktop Gateway. See part two here.

Most Windows Server administrators  at some point have worked with Remote Desktop Services. That’s the case because Windows RDS is an inexpensive solution for remotely delivering applications and desktops to users. It’s also easy to acquire: Any Windows Server can be made an RDS server with just a few mouse clicks.

Though the Remote Desktop Session Host (RDSH) is the core of RDS, the Remote Desktop Gateway (RDG) is an equally powerful role service, enabling secure user sessions across untrusted networks and/or the Internet.

So if the RDG is such a useful tool for Internet-enabling Windows RDS applications, why don’t more IT shops use it? One hurdle lies in a lack of understanding about the different ways an RDG can be integrated into a DMZ and/or internal LAN. Complicating matters are a series of misconceptions that make the RDG appear less secure than it really is.

The difference is in your design.

There are four very different designs for integrating the RDG into an existing DMZ, with one of the four representing the current industry best practice. In each, you can assume that the RDG role service is installed to a separate server which is used solely for RDG services. Also, while the term “Internet” is used to describe the outside-the-LAN network, that term could represent any external and untrusted network (such as an extranet, for example).

Design No. 1: No DMZ. RDG in the LAN.

The most common RDG design is also its simplest. In it, no DMZ is required because the RDG is located within the internal LAN and has full network connectivity to its RDSH. In this design, firewall ports TCP/443 are opened between the Internet and the RDG, and DNS records are updated appropriately so that the RDG’s fully qualified domain name (FQDN) can be resolved from either the LAN or the Internet.

While this design is  simple enough, it does not provide the kinds of network segregation and protection that most security policies require. For example, most security policies require network traffic from the Internet to proxy through a DMZ server before entering the internal LAN. This design does not support that requirement.

Design No. 2: RDG in the DMZ. No internal Active Directory exposure.

In order to support the proxy requirement mandated on most corporate networks, a second design relocates the RDG into a DMZ. From its position there, port TCP/443 must first be opened between the Internet and the RDG, and then port TCP/3389 between the RDG and the internal LAN.

While this design segregates the RDG from the internal LAN, it does so at the cost of internal Active Directory exposure. With only the Remote Desktop Protocol port (TCP/3389) open between the DMZ and the internal LAN, the server running the RDG must operate in Workgroup mode.

Note that this use of Workgroup mode is only possible atop Windows Server 2008 R2. Previous OS versions required the RDG to be a domain-joined server. Note also that by using this design, connecting users will need two different usernames and passwords. The first will be managed as local users on the RDG, while the second will be their internal domain credentials.

Design No. 3: RDG in the DMZ, with internal Active Directory exposure.

Asking users to keep track of two different usernames and passwords is a huge burden, as is the administrative effort of maintaining them on the RDG server itself. For that reason, most environments desire a single sign-on experience throughout the entire connection from the remote device, through RDG, and ultimately to the RDSH application.

One method of providing that single sign-on experience is by using a domain-joined RDG server. At issue here is the wide range of network ports required to extend a Windows domain into a DMZ. The sheer number of ports required is often the limiting factor to implementing Design No. 3. The RDS Team Blog documents these ports.

The process to construct this design is quite complex, and as a result the article can be a confusing read. Recognize, however, that any of three high-level options can be used to implement Design No. 3:

The first option opens sufficient network ports between the RDG and an internal Domain Controller to maintain its domain membership.

To further secure this configuration, the second option instead places a Read-Only Domain Controller in the DMZ. That RODC is connected via sufficient network ports to an internal DC in order to maintain its domain membership, and the RDG uses the RODC for authentication.

A third option attempts to further segregate things by using a separate domain and Domain Controller in the DMZ that participates in a forest trust with the internal domain. Sufficient ports are then opened between the DMZ DC and an internal DC to support authentication through that forest trust.

Option No. 4: Reverse Proxy in the DMZ. RDG in the LAN.

If Option No. 3 seems like extra effort, it is. It also opens firewall ports most security professionals would rather keep closed. It’s for this reason why Option No. 4, for those who can afford it, is considered the current industry best practice.

Option No. 4 adds one additional component to the network design used in Option No. 1. That additional component is the positioning of a reverse proxy server in the DMZ, with network traffic passing through the proxy before being routed to the RDG inside the LAN. That reverse proxy server can be Microsoft’s Forefront Threat Management Gateway or Unified Access Gateway, or any of the array of third-party reverse proxy solutions that support RDG integration.

Being a reverse proxy, any of these solutions can operate as an SSL bridging device for receiving and passing on HTTPS requests between the Internet and the internal LAN. Network packets are terminated at the reverse proxy, inspected for malicious code, and reconstructed before sending on to internal servers. This process enables a domain-joined RDG in the internal LAN to authenticate and further proxy user sessions using internal domain credentials. That’s SSO.

A Not-So-Complicated RDG

The RDG is indeed a friend when applications need Internet exposure. A solid solution that performs a simple function with great success, this little role service built right into Windows Server 2008 R2 can be a smart solution.

All you need is the right design.

You can follow on Twitter @WindowsTT.

This is the first part of a two-part series on Remote Desktop Gateway. See part two here.

ABOUT THE AUTHOR:  Greg Shields is a Partner and Principal Technologist with Concentrated Technology, an IT analysis and strategic consulting firm. Contact him at

This was last published in February 2012

Dig Deeper on Windows Server troubleshooting

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

If anyone knows of an actual guide to deploy in the DMZ, that would be great. I cannot find the information anywhere....
I am using option 3 with a one-way trust setup, but am unable to add the DMZ Web Gateway to my deployment.