RD Gateway: Deployment-Optionen, Workgroup oder Mitglied in AD-Domäne

Beim RD Gateway handelt es sich um eine von mehreren Server-Rollen für die Remote Desktop Services. Einen Einstiegs­punkt für Remotedesktop-Clients stellt auch RD Web Access dar, eine weitere Rolle der RDS. Es erlaubt den Start eines Desktops bzw. einer RemoteApp aus dem Web-Browser.

Entsprechend könnte man annehmen, dass sich RD Web Access als Alternative zu einem RD Gateway einsetzen ließe. Dem ist aber nicht so. Die Clients können das Web-Interface zwar erwartungs­gemäß ebenfalls über HTTPS ansprechen, aber das Öffnen einer Anwendung führt zum Aufbau einer ungesicherten RDP-Verbindung zu einem Session Host. RD Web Access lässt sich aber mit einem Gateway kombinieren, um für User den Zugang zu erleichtern.

Platzierung des Gateways im internen Netzwerk

In einer einfachen Konfiguration könnte man das RD Gateway im LAN platzieren und den Firewall-Port 443 für den Zugriff von außen auf das Gateway öffnen. Zusätzlich benötigt man einen öffentlichen DNS-Eintrag, so dass externe Clients den Namen des Gateways auflösen können.

Eine solche Konfiguration ist aber nicht besonders sicher, da es einem Einbrecher eine ungehinderte seitliche Bewegung durch das Netzwerk erlaubt, wenn er das RD Gateway kompromittiert. Daher kann man es zusätzlich schützen, indem man in der DMZ einen Reverse Proxy platziert, der die Anfragen über HTTPS entgegen­nimmt und durch die Firewall an das Gateway weiterleitet.

Gateway in der DMZ

Alternative Deployment-Optionen sehen vor, dass ein RD Gateway nicht im internen Netzwerk, sondern in der DMZ läuft. Sie ist in der Regel durch eigene Firewalls nach innen und außen abgeschirmt.

In der Firewall Richtung LAN muss in jedem Fall Port 3389 für RDP geöffnet sein, und nach außen 443 für die SSL-Verbindung. Wenn das RD Gateway allerdings Mitglied in einer AD-Domäne ist, dann muss nach innen für die Kommunikation mit dem DC eine ganze Reihe von Ports in der Firewall aufgemacht werden.

Ein älterer Beitrag aus Microsofts RDS Team Blog nennt folgende Funktionen, die in dieser Konstellation zusätzlich Durchlass benötigen:

• Authentifizierung und Autorisierung von Benutzern
• Auflösung der Namen von internen Ressourcen
• Abrufen der Zertifikatsperrliste
• Senden von RADIUS-Anforderungen (wenn ein zentraler NPS-Server verwendet wird)

Weniger Traffic mit einem Workgroup-Server

Diese Kommunikation kann man vermeiden, wenn man das RD Gateway nicht in die AD-Domäne aufnimmt, sondern als Workgroup-Server konfiguriert. Dies ist seit Windows Server 2008 R2 möglich.

Die Konfiguration ist aber aufwändiger als bei einem Member-Server und anschließend muss man alle zugelassenen Benutzer lokal verwalten. Für das Management des Servers entfallen zudem GPOs, und man muss dafür auf lokale Gruppen­richtlinien ausweichen.

RODC in der DMZ

Um die umfangreiche Kommunikation mit einem Domain Controller im LAN zu vermeiden und trotzdem nicht auf die AD-Anbindung zu verzichten, bietet sich an, einen Read-only Domain Controller (RODC) in der DMZ zu platzieren.

Dieser gehört zum internen AD-Forest und übernimmt dann die Authentifizierung der Remotedesktop-User. Er beschränkt sich auf die Replikation mit den DCs im LAN.

Eigener Forest in der DMZ

Ein ähnliches Ergebnis erzielt man, wenn man in der DMZ eine eigene Gesamtstruktur einrichtet und diese über eine unidirektionale Ver­trauens­stellung mit dem internen Forest verknüpft. Das RDS Gateway ist dabei Mitglied in der DMZ-Domäne, so dass sich die RDP-User gegen den dortigen DC authentifizieren.

Auch hier reduziert sich der AD-bezogene Traffic, und zwar auf jenen innerhalb der Vertrauens­stellung.