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

    Nativer RDP-Client für WindowsDas Remote Desktop Gateway dient dazu, den Zugriff auf interne Remote-Desktop-Dienste aus nicht vertrauens­würdigen Netz­werken abzu­sichern. Dafür bieten sich mehrere Optionen für seine Platzierung im Netz­werk an. Ein weiteres Kriterium besteht darin, ob und wie man ein RD Gateway mit dem AD integriert.

    Das RD Gateway erlaubt Clients aus dem Internet, die RDP-Kommunikation über einen HTTPS-Tunnel abzuwickeln und erspart Anwendern so das Einrichten eines VPN. In Richtung RD Session Host nutzt das Gateway reines RDP, standard­mäßig also über Port 3389. Der Zugriff lässt sich auf bestimmte Ressourcen und User beschränken.

    Verhältnis zu RD Web Access

    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.

    RemoteApp in RD Web Access

    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.

    Funktionsweise eines Reverse Proxy

    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 vorhanden ist)

    Kommunikation eines RD Gateway in der DMZ, das Mitglied in einer Domäne ist, mit dem internen Netzwerk.

    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.

    Ein RODC in der DMZ authentifiziert die Remotedesktop-User und reduziert den Traffic nach innen.

    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.

    Konstellation mit einem eigenen AD-Forest in der DMZ, der über einen One-way-Trust mit der interen Struktur verbunden ist.

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

    1 Kommentar

    Martin Feuerstein sagt:
    1. August 2020 - 21:24

    Ich würde mich über eine Ergänzung bzgl. RD-Gateway und Client-Proxy ("Internetoptionen") sowie UDP-RDP-Verkehr freuen.