Ich habe ja hier in unserem Blog schon des öfteren Beiträge zum Thema “Remote Desktop Services”, kurz RDS, geschrieben. Heute kommt ein neuer dazu, in dem ich die Installation eines Remotedesktopgateways (Im weiteren Text mit RDSGW abgekürzt) erläutere. Ein RDSGW ist dazu gedacht, einen oder mehrere RDS-Hosts über Internet verfügbar zu machen. Das hat den Vorteil, das man sich für den Aufruf eines Programms über RDS nicht erst extra eine VPN-Verbindung aufbauen muss, sondern direkt loslegen kann.
Geholfen bei der Einrichtung hat mir das von Microsoft zur Verfügung gestellte Dokument
Deploying Remote Desktop Gateway Step-by-Step Guide
Beim Betrieb kann man es entweder so machen, das man das RDSGW in die DMZ stellt, der von Microsoft empfohlene Weg wäre eine sichere Veröffentlichung mit Hilfe eines Microsoft ISA Server. In meinem Fall wähle ich die DMZ-Variante.
Es ist wichtig, das man die Gateway-Funktion nicht auf einem der RDS-Hosts aktiviert, es sollte immer ein eigener Server verwendet werden.
Gruppe in der Active Directory anlegen
Wir benötigen später eine Gruppe, in der all die Server eingetragen werden, auf die ein Zugriff von außen erfolgen darf. Dies sollten normalerweise nur die RDS-Hosts sein.
Zertifikat erstellen
Wir benötigen während der Einrichtung ein Zertifikat, mit dem die Kommunikation abgesichert wird. Dieses Zertifikat muss auf den Namen hören, mit dem wir eine Verbindung aufbauen wollen, sprich die Adresse des RDSGW. Bedingung hierfür ist eine PKI ( Einrichten einer Microsoft PKI mit Windows Server 2008 (R2) ). Hierzu öffnen wir eine MMC, fügen “Zertifikate” => “Computerkonto” hin zu navigieren zu “Eigene Zertifikate”. Dort wählen wir “Neues Zertifikat anfordern…” und generieren ein neues Zertifikat mit dem gewählten Namen.
Ich wähle in meinem Fall die Vorlage, die ich während der Einrichtung von Direct Access ( Howto: Einrichtung von DirectAccess ) erstellt habe.
Die Installation und Einrichtung des RDSGW
An dieser Stelle müssen wir das soeben erzeugte Zertifikat auswählen. In meinem Screenshot taucht kein Zertifikat auf, da ich die Screenshots nachträglich auf einem anderen System erstellt habe.
Hier wählen wir die Benutzergruppen aus, die eine Verbindung zum RDSGW aufbauen dürfen.
An diesem Punkt wählen wir die vorhin erstellte Gruppe aus. Durch diese Gruppe wird festgelegt, zu welchen Systemen der Benutzer eine Verbindung aufbauen darf.
Während der Installation wird ein lokaler Netzwerkrichtlinienserver installiert. Man muss diesen nicht nutzen, später kann man in der Konfiguration einen anderen, globalen Server auswählen.
Nach der Installation und einem Neustart des Systems taucht im Startmenü unter Verwaltung der Reiter “Remotedesktopdienste” auf, und hier der “Remotedesktopgateway-Manager”.
Nach dem Aufruf erwartet einen ein Fenster mit recht wenig Optionen:
Konfigurieren kann man das Gateway wie folgt:
Man kann hier diverse Dinge konfigurieren, die meisten davon sind in diesem “einfachen” Szenario allerdings nicht von Bedeutung. Hier einmal die Reiter, die in unserer Umgebung von Bedeutung sind.
Unter Allgemein kann man die Anzahl der gleichzeitigen Verbindungen einschränken oder die Anmeldung komplett deaktivieren, bei einer Wartung des Systems zum Beispiel.
Unter “RD-CAP-Speicher” kann man einstellen, ob ein lokaler NPS oder ob ein zentraler NPS genutzt werden soll. Weiterhin kann man einstellen, ob ein “Statement of Health” (SoH) vom Client gesendet werden soll. Mit dieser Option könnte man z.B. verhindern, das Systeme ohne Virenscanner eine Verbindung aufbauen.
Unter “Messaging” kann man Systemmeldungen konfigurieren, Anmelde-Meldungen konfigurieren oder einstellen, ob nur Verbindungen von RD-Clients zugelassen werden, die Remotedesktopgateway-Messaging unterstützten.
Unter “SSL-Zertifikat” kann man nachträglich das Zertifikat ändern, unter “Serverfarm” kann man mehrere Gateway-Server zu einer Farm hinzufügen, unter “SSL-Bridging” kann man eine SSL-Brücke zu einem ISA-Server oder einem anderen Produkt herstellen und unter “Überwachung” kann man konfigurieren, welche Ereignisse mitprotokolliert werden.
Die NPS-Richtlinie kann unter “Richtlinien” konfiguriert werden, hier kann sowohl die “TS_CAP_01” (Verbindungsauthorisierungsrichtlinie) als auch die “TS_RAP_01” (Ressourcenauthorisierungsrichtlinie) konfigurieren.
Verbindung mit einem Client
Bei einem Verbindungsaufbau von außen muss man im RDP-Client die folgenden Einstellungen hinterlegen:
Guten Tag Herr Kappen
Wie ich sehe sind Sie mit den Remotedesktopdiensten von Microsoft sehr vertraut. Ich werde in der kommender Woche meine Lehre als Informatiker Richtung Systemtechnik abschliessen. Um erfolgreich abschliessen zu können, muss ich eine Individuelle Praktische Arbeit absolvieren und das Thema ist „Remote Desktop Services auf Microsoft Basis“. Ziel ist es, von einem externen Netzwerk aus, die Remote Desktop Services nutzen zu können. Nun wollte ich Sie fragen, ob Sie mir wie folgt helfen könnten:
Welche Vorbereitung ist zwingend notwendig (Zertifikat & Gruppen erstellen?) vor der Installation der RD-Dienste?
Installationsreihenfolge und Zusammengehörigkeit der verschiedenen Dienste (Jeder Dienst auf eienem separaten Server, oder gibt es Koppelungsmöglichkeiten?)?
Ich Danke Ihnen schon im Voraus für Ihre Hilfe!
Bitte senden Sie mir eine E-Mail: adri_b_90@hotmail.com
Freundliche Grüsse
Adriano
Ich hab mal ne blöde Frage. Wird eine Remote Desktop Verbindung nicht sowieso immer verschlüsselt?
Wenn man keine Möglichkeit hat, extra einen weiteren Server für das Gateway anzuschaffen und nur ein (max. 2) Mitarbeiter übers Netz auf den RDS zugreifen müssen, würde dann nicht eine einfache Port-Weiterleitung reichen?
Danke im vorraus für eine Antwort, trotz der blöden Frage.
Freundliche Grüße
Andy
Hi, eine RDP-Verbindung is grundsätzlich verschlüsselt, allerdings laufen die Daten über den Port 3389. Bei einem RDS-Gateway wird der Traffic vom Client im Internet zum Gateway über HTTPS gesendet, erst danach geht es mit RDP firmenintern weiter.
Cheers, Jan
Danke für die super schnelle Antwort!
Das mit dem Port wäre an sich für mich kein Problem. Kann es sein, dass das Passwort bei der RDP-Verbindung unverschlüsselt übertragen wird?
Wenn nein, würde ich es mit der Port-Weiterleitung realisieren. Also nochmal: Danke für Antwort, Du warst echt schnell!
Nein, das wäre ja der Gau schlechthin, wenn die Bilddaten verschlüsselt würden, das Kennwort aber nicht :)
In deinem Fall wäre die Öffnung bzw. Weiterleitung des Ports wahrscheinlich die Variante der Wahl, falls möglich könnte man in der Firewall noch den IP-Bereich aus dem Internet heraus begrenzen, durch dynamische IPs der Clients ist das aber meist nicht möglich…
Gruß
Hi Jan!
Danke für Deine Erläuterungen. Wie gesagt ich werde das heute mit der Weiterleitung einrichten. Die Clients werden dynamische IPs haben, daher wird das mit dem Eingrenzen nix geben.
Nochmal danke und ein schönes Wochenende!
Hallo,
nachdem Sie sich damit gut auskennen, darf ich Sie was fragen?
Aufbau wie folgt:
Netzwerk 1 ist ein Produktivnetz
Netzwerk 2 ein von Netzwerk 1 komplett getrenntes Testnetz.
In Netzwerk 2 sollen 10 WIN XP Maschinen per RD aus dem NW1 erreichbar sein. kann ich dann als „Brücke“ den RDGWS benutzen? Wenn ja, sollte der RDGWS im NW2 sein und kann ich den Server wie oben beschrieben einrichten?
Vielen Dank
Michael
Hallo Michael,
die von dir beschriebene Variante sollte funktionieren, ob ich nun über Internet gehe oder über eine lokale Adresse sollte dem Gateway und dem RDP-Client egal sein.
Gruß, Jan
Vielen Dank für die Auskunft
Ich melde mich wenn ich den RDGWS fertig habe :)
Gruß
Michael
So nun habe ich den DC neu und den RDSGW neu (beide NW2 RDSGW mit einer Netzwerkkarte im NW1).
Allerdings funktioniert es nicht, da der RD Client wegen einem abgelaufenen bzw. gesperrten Zertifikat meckert. Ich habe ein Zertifikat erstellt wie in dem PKI Artikel beschrieben, sowie eins wie in Direct Access beschrieben, bei beiden der gleiche Fehler. Muss ich evtl in NW1 auch eine Zertifizierungsstelle einrichten? Kann ich auch den ganzen Zertifizierungskram weglassen, da sowieso nur von NW1 bzw. VPN Zugriffe gehen?
Fragen über Fragen :)
Danke schonmal
Schöne Grüße
Michael
Es kommt auf die Art des Fehlers an. Alle Zertifikate müssen auf allen Geräten vertraut sein. Vielleicht kann dir der folgende Artikel weiterhelfen:
http://technikblog.rachfahl.de/tipps_tricks/rds-programme-erzeugen-eine-warnmeldung-beim-ersten-aufruf/
Dort wird beschrieben, wie du die Fingerabdrücke der Zertifikate vertraut machst. Am saubersten wäre es aber, wenn alle Geräte der einen PKI vertrauen würden und diese alle Zertifikate ausgestellt hat.
Gruß, Jan
So Fehler gefunden: Das Zertifikat war rein für NW2 ausgestellt, nun habe ich das Zertifikat wie bei Direct Access nochmals gebaut zusätzlich mit den Daten des NW 1 (auch IP usw.) nun geht es :)
Tausend Dank :)
LG
Michael
Hört sich gut an, Wochenende gerettet :)
Zu dem „Gateway-Funktion nicht auf einem der RDS-Hosts“ – wie steht es denn mit http://www.lemonbits.com/2014/06/20/installing-standalone-remote-desktop-gateway-on-the-windows-server-2012-r2-without-complete-remote-desktop-services-infrastructure/ ? Oder liegt das an Verbesserungen in 2012? Ist das denn eig., auch in 2016 möglich?