Die meisten Windows-Server-Administratoren haben sicherlich an irgendeinem Punkt bereits mit den Remote Desktop Services [RDS] gearbeitet. Der Grund liegt auf der Hand: Windows-RDS ist eine kostengünstige Lösung, um für User Anwendungen und Desktops remote bereitzustellen. Darüber hinaus ist sie einfach zu realisieren: Jeder Windows-Server lässt sich mit nur wenigen Mausklicks in einen RDS-Server verwandeln.
Obwohl der Remote Desktop Session Host [RDSH] den Kern von RDS bildet, ist das Remote Desktop Gateway [RDG] ein ebenso wichtiger Rollendienst, da er sichere Benutzersitzungen zwischen nicht vertrauenswürdigen Netzwerken und/oder dem Internet ermöglicht.
Wenn also das RDG solch ein praktisches Tool ist, um Windows-RDS-Anwendungen ins Internet zu bringen, warum nutzen ihn nicht mehr IT-Abteilungen? Eine Hürde liegt im fehlenden Verständnis der unterschiedlichen Möglichkeiten, mit denen sich ein RDG in eine demilitarisierte Zone [DMZ] und/oder ein internes LAN integrieren lässt. Erschwert wird das Ganze noch durch eine Reihe von falschen Vorstellungen, aufgrund derer das RDG weniger sicher erscheint, als es in Wahrheit ist.
Der Unterschied liegt im Netzwerkdesign.
Es gibt vier deutlich verschiedene Designs, um das RDG in eine bestehende DMZ zu integrieren. Eines davon stellt die derzeit in der Branche favorisierte Best Practice dar. Bei jedem dieser Designs können Sie davon ausgehen, dass der RDG-Rollendienst auf einem eigenen Server installiert wird, der ausschließlich für RDG-Dienste verwendet wird.
Und obwohl der Begriff „Internet" gebraucht wird, um das Netz außerhalb des LAN zu beschreiben, kann er für jedes externe und nicht vertrauenswürdige Netzwerk stehen [zum Beispiel ein Extranet].
Design Nr. 1: Keine DMZ, RDG im LAN
Das häufigste RDG-Design ist gleichzeitig das einfachste. Darin wird keine DMZ benötigt, weil sich das RDG innerhalb des internen LAN befindet und vollständige Netzwerkkonnektivität zu seinem RDSH besitzt. In diesem Design wird der TCP-Port 443 der Firewall zwischen dem Internet und dem RDG geöffnet. Außerdem werden die DNS-Records korrekt aktualisiert, sodass der Fully Qualified Domain Name [FQDN] des RDG entweder über das LAN oder das Internet aufgelöst werden kann.
Dieses Design ist zwar recht einfach, bietet dafür aber nicht die Art von Netzwerktrennung und Schutz, die die meisten Sicherheitsrichtlinien vorschreiben. So verlangt der Großteil dieser Richtlinien, dass der Netzwerk-Traffic vom Internet über einen DMZ-Proxy-Server geleitet wird, bevor er das interne LAN erreicht. Dieses Design erfüllt diese Anforderung nicht.
Design Nr. 2: RDG in der DMZ, kein Abbilden des internen Active Directory
Um der für die meisten Unternehmensnetzwerke obligatorischen Proxy-Anforderung nachzukommen, verlegt das zweite Design das RDG in eine DMZ. Von seiner dortigen Position aus muss zuerst TCP-Port 443 zwischen dem Internet und dem RDG geöffnet werden, anschließend TCP-Port 3389 zwischen dem RDG und dem internen LAN.
Zwar trennt dieses Design das RDG vom internen LAN, allerdings wird auf diese Weise das interne Active Directory nicht nach außen abgebildet. Da zwischen der DMZ und dem internen LAN nur der TCP-Port 3389 für das Remote Desktop Protocol geöffnet ist, muss der Server, auf dem das RDG läuft, im Arbeitsgruppenmodus betrieben werden.
Beachten Sie, dass diese Verwendung des Arbeitsgruppenmodus nur ab Windows Server 2008 R2 möglich ist. Ältere Betriebssystemversionen setzten voraus, dass das RDG ein in die Domain eingebundener Server war. Bedenken Sie auch, dass bei der Nutzung dieses Designs Anwender, die eine Verbindung aufbauen wollen, zwei unterschiedliche Benutzernamen und Passwörter benötigen. Der erste Account wird als lokaler User auf dem RDG verwaltet, während der zweite zur internen Domain-Anmeldung dient.
Design Nr. 3: RDG in der DMZ, Abbilden des internen Active Directory
Dass User bei zwei verschiedenen Benutzernamen und Passwörtern den Überblick behalten, ist meist zu viel verlangt. Ebenso groß ist der administrative Aufwand, sie auf dem RDG-Server zu verwalten. Aus diesem Grund ist in den meisten Umgebungen ein Single Sign-on [SSO] erwünscht, und zwar bei der gesamten Verbindung vom Remote-Gerät, über das RDG bis hin zur RDSH-Anwendung.
Eine Methode, Single Sign-on zu erreichen, führt über einen in die Domain eingebundenen RDG-Server. Problematisch hierbei ist der große Bereich an Netzwerkports, der erforderlich ist, um eine Windows-Domain in eine DMZ zu erweitern. Die schiere Anzahl der notwendigen Ports ist oft der begrenzende Faktor, um Design Nr. 3 zu implementieren. Der RDS-Team-Blog dokumentiert diese Ports.
Der Prozess, um dieses Design umzusetzen, ist äußerst komplex. Damit der Artikel nicht zur Verwirrung beiträgt, nennen wir an dieser Stelle nur kurz drei High-Level-Optionen, mit denen sich Design Nr. 3 implementieren lässt:
Die erste Option öffnet genügend Netzwerkports zwischen dem RDG und einem internen Domain-Controller, damit Erstgenannter seine Mitgliedschaft in der Domain erhält.
Um diese Konfiguration weiter zu sichern, platziert die zweite Option stattdessen einen Read-Only Domain-Controller [RODC] in der DMZ. Der RODC wird über eine ausreichende Anzahl an Netzwerkports mit einem internen DC verbunden, um die Domain-Mitgliedschaft zu erhalten, und der RDG verwendet den RODC für die Authentifizierung.
Die dritte Option versucht, eine weitere Trennung vorzunehmen. Dazu nutzt sie eine separate Domain und einen Domain-Controller in der DMZ, der in eine Gesamtstruktur-Vertrauensstellung mit der internen Domain eingebunden ist. Dann werden zwischen dem DMZ-DC und einem internen DC genug Ports geöffnet, um die Authentifizierung durch diese Gesamtstruktur-Vertrauensstellung zu unterstützen.
Option Nr. 4: Reverse Proxy in der DMZ, RDG im LAN
Falls Option Nr. 3 wie zusätzlicher Aufwand erscheint, stimmt das. Außerdem öffnet sie Firewall-Ports, die laut Empfehlung der meisten Sicherheitsexperten lieber geschlossen bleiben sollten. Aus diesem Grund gilt Option Nr. 4 – für diejenigen, die es sich leisten können – in der Branche momentan als Best Practice.
Option Nr. 4 fügt dem in Option Nr. 1 vorgestellten Netzwerkdesign eine weitere Komponente hinzu. Diese zusätzliche Komponente sieht vor, einen Reverse-Proxy-Server in der DMZ unterzubringen, wobei der Netzwerk-Traffic über den Proxy geleitet wird, bevor er zum RDG innerhalb des LAN geroutet wird. Der Reverse-Proxy-Server kann Microsofts Forefront Threat Management Gateway oder Unified Access Gateway sein oder eine der Reverse-Proxy-Lösungen von Drittherstellern, die die RDG-Integration unterstützen.
Als Reverse Proxy kann jede dieser Lösungen als SSL-Bridging-Gerät fungieren, um HTTPS-Anfragen zu empfangen und zwischen dem Internet und dem internen LAN weiterzuleiten. Netzwerkpakete landen zunächst beim Reverse Proxy, werden auf schädlichen Code untersucht und neu zusammengesetzt, bevor sie an interne Server gesendet werden. Dieser Vorgang ermöglicht es einem in die Domain eingebundenen RDG im internen LAN, mithilfe von internen Domain-Anmeldeinformationen Benutzersitzungen zu authentifizieren und an weitere Proxies weiterzuleiten. Damit erreicht man Single Sign-on.
RDG - Weniger kompliziert als gedacht
Der RDG ist in der Tat ein Verbündeter, wenn Anwendungen über das Internet verfügbar sein sollen. Dieser kleine Rollendienst, der in Windows Server 2008 R2 integriert ist, bietet sich als pfiffige Lösung an. Er arbeitet solide und ist in der Lage, eine einfache Funktion äußerst erfolgreich zu übernehmen. Alles, worauf es ankommt, ist das richtige Netzwerkdesign.
Folgen Sie SearchDataCenter.de auch auf Facebook, Twitter und Google+!
This article shows you how to deploy a simple and secure remote access solution using Remote Desktop Gateway. The RD Gateway allows you to connect to desktops and servers in the office using RDP from home Securely.
In a nutshell the Remote Desktop Gateway role provides a RDP type of SSL VPN remote access service over TCP 443 and UDP 3391. You can essentially connect to your work computer from a home device using MSTSC [Remote Desktop connection].
Cost:
- Lets Encrypt public Certificate – free
- Windows Server licence – Free trial to test this out
Where can i deploy?
- On-premises
- Microsoft Azure
- Amazon AWS
- Google Cloud
Getting started:
Please follow the steps in order for best results….!
First we need a domain joined server [preferably]. Navigate to the Add roles and features wizard and install the Remote Desktop Gateway Role service.
Configuring IIS and a HTTPS certificate:
The next steps will be to download the win-acme lets Encrypt client tool for generating a free public SSL certificate. //www.win-acme.com/
Once downloaded, copy all of the files into the inetpub folder under a newly created folder called lets encrypt as shown in the screenshot.
Then ensure that the you configure external DNS with the FQDN required and ensure ports 443/3391 and port 80 are open on the firewall. You will then need to add the https binding to IIS.
Once this is all in place, you then would run the wacs.exe and follow the steps to generate the public certificate.
follow the steps to create a simple certificate for IIS.
Once completed the certificate will appear in the Web Hosting section of the local computer certificates.
The next step would be to run the importRDGateway script to auto configure the certificate as shown above. this can be found in the lets encrypt folder we created earlier.
Once the script is successfully run, you will see under SSL Certificate in the Remote Gateway Manager, the let’s Encrypt certificate is assigned.
Configuring a basic RAP and CAP Policy:
You need to create both policy’s in accordance to your security requirements. You can create both using a wizard in one sitting. follow the steps of the wizard.
Testing and connecting through the gateway:
This section shows the windows client, however you can use other OS’s and vendor client tools like thin clients to connect to your office resources. If users have apple mac’s this is also supported.
//docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-mac
To test connectivity, open up the Remote Desktop Connection [MSTSC] navigate to advanced and configure the gateway details. Once you have configured the gateway settings. Navigate back to the general tab and enter in the computer/server FQDN or name or IP address.
Once connected, you can see from the monitoring section of RD Gateway manager, we are now connected to our remote resources through the Gateway on TCP 443 / UDP3391.
As you can see from the Remote Desktop connection, the device is connected to 10.0.0.6 using the gateway service.
Summary:
This is a affordable and quick way of deploying a Remote Access Solution for users large or small in size. If you are in need of setting up remote access for workers quickly, this may be the answer.
Point to note, the certificate expires in two months however you can configure the automatic renewal of the certificate. If you only require a temporary solution, this is perfect to get all your staff up and running quickly. If you want this to be more permanent, then you should configure the Automation of the certificate renewal.
find out more about deploying RD Gateway in detail here: //ryanmangansitblog.com/2013/03/27/deploying-remote-desktop-gateway-rds-2012/