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.


Sie benötigten persönliche Unterstützung oder haben nicht die richtige Lösung für Ihr Problem gefunden?

Dieser Blog wird von mir, Jan Kappen, in seiner Freizeit betrieben, hier beschreibe ich Lösungen für Probleme aller Art oder technische Anleitungen mit Lösungsansätzen.

Die berufliche Unabhängigkeit

Ich bin seit Januar 2020 vollständig selbstständig und habe meine eigene Firma gegründet, die Building Networks mit Sitz in Winterberg im schönen Sauerland. Hier stehe ich als Dienstleister gerne für Anfragen, Support oder Projekte zur Verfügung.

Die Firma Building Networks bietet Ihnen:

  • Hilfe und Support per Telefon, Fernwartung oder persönlich vor Ort
  • Projekt-Unterstützung
  • Ausgezeichnete Kompetenz zu den Themen
    • Microsoft Hyper-V
    • Microsoft Failover Clustering & HA
    • Storage Spaces Direct (S2D) & Azure Stack HCI
    • Veeam Backup & Recovery
    • Microsoft Exchange
    • Microsoft Exchange Hybrid Infrastruktur
    • Microsoft Active Directory
    • Microsoft Office 365
    • Ubiquiti
    • 3CX VoIP PBX
    • Fortinet Network Security
    • Baramundi Software
    • ...

Ich freue mich über Ihren Kontakt, weitere Informationen finden Sie auf der Webseite meiner Firma unter Building-Networks.de

Jan

Jan Kappen arbeitet seit 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. Von September 2018 bis Dezember 2019 war Jan als Senior Network- und Systemadministrator bei einem großen mittelständischen Unternehmen im schönen Sauerland angestellt. Im Januar 2020 hat er den Sprung in die Selbstständigkeit gewagt und ist seitdem Geschäftsführer der Firma Building Networks in Winterberg. In seiner Freizeit kümmert er sich um das Freifunk-Netzwerk in Winterberg und Umgebung.

4 Kommentare:

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

  2. Hey, bin ziemlich neu in der Windows Server Welt und wollte wissen, ob die RD Gateway User dennoch in die Remote Desktop Users Group eingetragen werden müssen? Da bei der Verbindung die die Anmeldung abgelehnt wird, weil der User nicht in für remoteanmeldung autorisiert ist.

    Danke!

    • Hi,
      um sich an dem RDS Gateway anzumelden, wird keine Mitgliedschaft in der Gruppe benötigt, außer du benutzt diese Gruppe als Grundlage der Authentifizierung. Ich habe in diesem Artikel eine neue Gruppe erstellt mit dem Namen „RDSGW User“. Für die nachfolgende Authentifizierung an dem Server selbst (per RDP) muss RDP freigegeben sein. Dazu wird der Benutzer in die RDS User Group gepackt (wie du beschrieben hast) oder du gibst ihn in den RDP-Einstellungen einzeln frei oder du nimmst ihn in eine neue Gruppe auf und erlaubst einen Zugriff für diese Gruppe. Wenn noch Fragen sind antworte gerne auf meinen Kommentar.
      Gruß, Jan

  3. Sehr hilfreich, danke.
    Im letzten Satz des Beitrags schreiben sie folgendes….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…

    Kann man genauer darauf eingehen, wie der Server von außen per HTTPS erreichbar wird?
    Grüße
    Johannes

Schreibe einen Kommentar

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