Installation von einem Remote Desktop Services Gateway ohne Active Directory

In diesem Artikel möchte ich beschreiben, wie man ein Remote Desktop Services Gateway installiert, und zwar ohne eine aktive Domänen-Mitgliedschaft. Ein RDS-Gateway wird verwendet, um (primär) aus dem Internet per HTTPS auf einen Server zuzugreifen, der dann eine RDP-Sitzung im LAN weiterleitet. Mit dieser Lösung hat man den Vorteil, dass man seine Server nicht per RDP an das böse Internet stellen muss, sondern man stellt nur eine HTTPS-Verbindung bereit (nämlich das RDS-Gateway). Dieser zentrale Einstiegspunkt sorgt dann dafür, dass man an nahezu alle seine Server per RDP im lokalen Netzwerk kommt, sofern dies gewünscht ist.

Die Vorbereitungen

Als Basis für diese Beschreibung nutze ich einen Windows Server 2019 in der Standard Edition in Englisch. Das System läuft auf einem Hyper-V Host, besitzt aktuell 2 vCPUs und 4 GB RAM. Mit dem RAM muss ich mal schauen ob es ausreicht, wenn nicht können wir das ja auch mal eben erhöhen. Im Betrieb. Awesome 🙂
Das System wird vollständig auf den aktuellen Patchlevel gebracht (in meinem Fall ist dies aktuell CU 2019-10). Dies macht Sinn, da man sonst möglicherweise auf Fehler trifft, die mit einem späteren CU behoben wurden und die einem die Grundinstallation schon direkt vermasseln können. Ansonsten brauchen wir erstmal nichts weiter an Software.

Nach der Grundinstallation vergeben wir für das System eine statische IP-Adresse in meinem Server-Netz, damit sich die Adresse im nachhinein nicht mehr ändert.

Installation der benötigten Rollen und Features

Wir starten mit der Installation der Rollen und Features, die notwendig sind. Hierzu aktivieren wir unter Rollen (Rollen- und Featurebasierte Installation) die Rolle

  • Remote Desktop Services

Features benötigen wir erst einmal keine. Wenn wir nun weiter klicken, können wir innerhalb der ausgewählten Rolle die Art der Unterrollen auswählen. Hier klicken wir die Unterrolle

  • Remote Desktop Gateway

aus.

Nachdem wir die Rolle angeklickt haben, erscheint eine Auswahl von weiteren Rollen und Features, die in Abhängigkeit installiert werden müssen. Diese Auswahl bestätigen wir mit Ja.

Der Server-Manager erweitert sich nach der Bestätigung um weitere Abfragen und Eigenschaften, diese können wir bis zum Abschluss der Installation einfach bestätigen.

Ist die Installation abgeschlossen, können wir direkt mit der Installation loslegen, es ist kein Neustart vom Server notwendig.

Die Einrichtung des RDS Gateways

Zur Einrichtung des Gateways können wir den Remote Desktop Gateway Manager aufrufen, z.B. über das Tools-Menü vom Server-Manager.

In diesem Manager können wir nun alle benötigten Einstellungen setzen.

Zertifikat

Damit eine Verbindung von außen möglich ist, benötigt das RDS Gateway ein Zertifikat. Die einfachste (und schlechteste Variante) wäre ein selbstsigniertes Zertifikat. Da diesem Zertifikat, was direkt über den Manager erstellt werden kann, erst einmal kein Gerät vertraut, muss man so schmutzige Dinge tun wie dieses Zertifikat in den Trusted Root CA-Bereich zu packen, damit die Verbindung möglich ist.
Eine weitere Möglichkeit wäre, dass man ein Webserver-Zertifikat mit Hilfe seiner lokalen PKI ausstellt, ein Zertifikat bei einem der üblichen Anbieter kauft oder ein kostenfreies Lets Encrypt-Zertifikat nutzt.
Mit persönlich gefällt die letzte Variante am besten, da man hier ein kostenloses Zertifikat bekommt, welches in vielen Geräten unterstützt und akzeptiert wird.

Die Einrichtung und natürlich auch die Erneuerung nach maximal drei Monaten ist eigentlich ganz einfach, diesem Thema habe ich allerdings einen eigenen Beitrag gegönnt:

Die Nutzung von Lets Encrypt Zertifikaten in einem Remote Desktop Services Gateway

Allgemeine Einstellungen

In den allgemeinen Einstellungen kann man definieren, wie viele Verbindungen aufgebaut werden dürfen (entweder begrenzt oder, das ist der Standard, unbegrenzt). Weiterhin könnte hier eine Anmeldung unterbunden werden, z.B. wenn Wartung ansteht und man keine störenden Verbindungen von anderen Benutzern haben möchte.

RD CAP und NPS

Wenn man die Installation weiter absichern möchte, können in diesem Bereich weitere Systeme angebunden werden, die für eine zusätzliche Absicherung bzw. Authentifizierung genutzt werden können. In den Standard-Einstellungen wird das lokale System dafür genutzt.

Connection Profile

Um eine Verbindung zu erlauben, muss ein Verbindungs-Profil erstellt werden. Dies können wir über den Shortcut im RDS Gateway Manager erstellen und ändern:

Als erstes müssen wir der neuen Richtlinie einen Namen geben.

In den Anforderungen (Requirements) können wir nun auswählen, ob sich ein Client per Kennwort, Smart Card oder beidem authentifizieren darf. Weiterhin müssen wir hier festlegen, wer sich an dem System anmelden darf.

Ich erstelle in meinem Fall eine neue Gruppe auf dem lokalen System (wir erinnern uns, der Server ist nicht Mitglied einer Active Directory), die wir dann als Gruppe in den Einstellungen angeben:

Ist die Gruppe erstellt, können wir sie in den Einstellungen angeben und nutzen.

In den weiteren Einstellungen kann noch definiert werden, welche Art von Ressource nicht weitergeleitet werden darf (z.B. lokale Drucker oder so)

Unter Timeouts kann auch noch ein Idle Timeout (keine aktive Nutzung der Verbindung, trotzdem im Hintergrund verbunden) sowie ein Session Timeout (Ein Benutzer darf maximal für XX Stunden verbunden sein) angegeben werden. Der erste Wert ist recht sinnvoll (daher habe ich ihn mal auf 4 Stunden gestellt), bei dem zweiten Wert sehe ich unbedingt den Bedarf.

Resource Authorization Policy

Die zweite, zwingend benötigte Richtlinie, ist die Authorization Policy. Ist diese nicht eingestellt, wird sie im Manager mit einem gelben Ausrufezeichen versehen.

Als erstes müssen wir einen Namen für die Policy definieren.

Unter User Groups muss (mindestens) eine Gruppe definiert werden, die Benutzer enthält, die sich aktiv anmelden dürfen. Ich benutze in meinem Fall die gleiche Gruppe, die ich bereits in der anderen Policy verwendet habe.

Nun kommen wir zu einer sehr wichtigen Einstellung. Unter Network Ressource kann die Verbindung eingeschränkt werden, wohin sich ein Client verbinden darf. Wäre der Server Mitglied einer Active Directory, könnte hier ein Service-Gruppe ausgewählt werden. Da er dies aber nicht ist, müssen wir hier entweder eine Liste der Server anlegen oder eine Verbindung zu “Any” erlauben.

RD Gateway-managed group

Um nur eine bestimmte Liste an Systemen bzw. IP-Adressen zu erlauben, kann hier eine neue Liste erstellt werden.

Sind die Einstellungen so gesetzt, kann ich von außen nur eine Verbindung zu diesen beiden IP-Adressen aufbauen.

Any

Diese Einstellung ist aus Gründen der Sicherheit nicht zu empfehlen, allerdings können wir diese Einstellung im Hintergrund noch deutlich entschärfen.

Höhere Sicherheit trotz “Any”

Um die Verbindung nur zu definierten Ressourcen zu erlauben, setze ich das RDS Gateway in einen eigenen Netzwerk-Bereich (man nannte das glaube ich mal DMZ oder so 😉 ). Damit die interne Verbindung per RDP nun über einen Router inkl. einer Firewall muss, kann hier eine Einschränkung der Ziel-Adressen vorgenommen werden.

Beispiel

Um das alles ein bisschen besser zu erklären, hier eine kleine, vereinfachte Übersicht des Netzwerks:

Die Verbindung zum RDS Gateway kommt per WAN rein und wird in LAN A geleitet. Ist die Anmeldung erfolgreich, wird eine interne RDP-Verbindung zu dem VM (oder was auch immer in dem gewünschten Netz steht) in LAN B aufgebaut. Diese Verbindung muss aktiv in der Firewall, die zwischen LAN A und LAN B besteht, erlaubt werden.

Ist das RDS Gateway das einzige Gerät in LAN A, und ich kann sämtliche Verbindung aktiv per Firewall steuern, erhöht dies signifikant die Sicherheit. Da ich dies in meinem Fall so betreibe, habe ich auch kein Problem mit der Allow any connection-Regel, die ich eingestellt habe.

Im letzten Reiter kann nun noch eingestellt werden, auf welche Ziel-Ports die RDP-Verbindung erlaubt ist. Dies ist in den Standard-Einstellungen der default Port 3389, ich habe in meinem Fall auch kein Bedarf an einer Änderung.

Abschluss der Installation und Test der Verbindung

Mit diesen Einstellungen sind wir erst einmal an Ende der Konfiguration. Natürlich können noch mehr und erweiterte Einstellungen gemacht werden, mit dieser Konfiguration ist der Server allerdings erst einmal einsatzfähig. Nun muss dafür gesorgt werden, dass der Server von außen per HTTPS erreichbar ist. Ist dies der Fall, kann die Verbindung aus dem Internet heraus getestet werden.

Jan

Jan Kappen arbeitet sein 2005 in der IT. Er hat seine Ausbildung 2008 abgeschlossen und war bis 2018 als IT-Consultant im Bereich Hyper-V, Failover Clustering und Software Defined Storage unterwegs. Seit 2015 wurde er jährlich von Microsoft als Most Valuable Professional (MVP) im Bereich "Cloud & Datacenter Management" ausgezeichnet für seine Kenntnisse und die Weitergabe seines Wissens. Jan ist häufig auf Konferenzen als Sprecher zu finden, weiterhin bloggt er viel. Seit September 2018 ist Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

Ein Kommentar:

  1. Pingback:Die Nutzung von Lets Encrypt Zertifikaten in einem Remote Desktop Services Gateway - Jans Blog

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.