Q. How can I extend my domain into a DMZ to support Remote Desktop Gateway (RDG)?

A. In my last FAQ, I suggested that an all-internal design's simplicity makes it best for testing RDG. However, an all-internal design does nothing for protecting your network traffic. Most production RDG implementations will require the RDG to exist in a DMZ where it is appropriately isolated.

One problem with this configuration is that the RDG must be domain-joined to authenticate external users as they connect to internal resources. Getting that domain out to the DMZ can be a challenge.

Microsoft recommends using any of three different Active Directory (AD) Domain Services (DS) models for getting the necessary domain resources into the DMZ. The Terminal Services Team Blog provides a comprehensive explanation of these models.

•  No AD DS in perimeter network: There's no AD in the perimeter network and RDG (in the perimeter network) is joined to the internal network domain.

•  Forest trust model: One-way trust between the perimeter network AD DS and the internal network AD DS. RDG is joined to perimeter AD DS.

•  Extended corporate forest model: A read-only domain controller for the internal network forest is in the perimeter network, and RDG is joined to the internal network domain.

The first model requires opening a series of firewall ports from the internal network to the RDG for access to its domain resources. The number of ports required is large, so many environments will shy away from this configuration.

The second and third models require fewer open ports. They also segregate domain controller functionality onto its own server, which can be specifically protected from external traffic. In the second model, a trust is used between a domain (and domain controller) in the DMZ and the internal network domain. The third places an internal domain's RODC in the DMZ. The link above discusses the specifics of each selection along with their needed firewall ports.