Terminal Services Gateway einrichten
In einem der letzten Server 2008 Workshops rannte uns nach einigem “Rumgeclustere” schlicht und einfach die Zeit davon – denn eigentlich war noch die neue Terminal Service Gateway Funktion angesagt. Leider war dann der Tag auch schon zu Ende. Ich sagte zu, einen Artikel in unserer Testumgebung zum Thema zu verfassen. Voilà, hier ist er.
Worum geht’s?
Terminaldienste reichen bis in die Zeit der ersten Großrechner zurück. Seinerzeit, also kurz
nach Erfindung des Rads, konnten mittels Tastatur und einem langen Kabel Daten zum Großrechner geschickt werden, der diese dann verarbeitete. Ein angeschlossener Bildschirm zeigte an, was man so trieb und machte natürlich auch die Ausgaben sichtbar. Der Arbeitsplatz, wo der Bildschirm und die Eingabegerätschaft steht wird als Terminal (Client) bezeichnet. Der Rechner, der die Daten entgegennimmt und verarbeitet – als Terminalserver (TS). Jeder Benutzer bekommt nach der Anmeldung am TS eine eigene Sitzung zugewiesen und “stört” die anderen somit nicht.
Windows-Server ist ja nicht gerade für den Betrieb auf derlei Dickschiffen berühmt. Dieser Umstand hindert das OS allerdings nicht daran, eine Terminal Server Rolle anzubieten – und dies schon seit NT-Zeiten. Es können allerdings mehrere TS zu einer sogenannten Terminalserverfarm zusammengeschlossen werden.
Die Terminal Services Rolle
Der aktuelle Windows Server 2008 bietet im Hinblick auf Terminaldienste einiges an. Das Grundprinzip ist jedoch schon Jahre unverändert:
Auf dem Client muss eine Software vorgehalten werden, mit Hilfe derer auf den Terminalserver zugegriffen wird. Auf den Windows Clients ist diese entweder schon vorhanden (Start\Ausführen\mstsc) oder kann für alle relevanten Systeme nachgerüstet werden.
Die Clients verbinden sich über das Netzwerk via Remote Desktop Protokoll über TCP Port 3389 auf den Terminalserver. Dort finden Sie Ihre klassische Windows Umgebung vor. Es wird jedoch nur das Bild und die Tastaturbefehle übertragen.
Der Vorteil liegt auf der Hand: Zentrale Verwaltbarkeit der Applikationen auf dem Server; wenn Applikationen laufen – keine Kompatibilitätsprobleme (z.B. eine aktuelle Software auf einem alten Windows NT-PC), zentrale Ressourcensteuerung, dadurch sind keine “Fat-Clients” notwendig.
Die Nachteile: Die Software muss für Terminaldienste geeignet sein, bei Windows sind zusätzliche TS-CALs notwendig, Rechner müssen ausreichend Ressourcen zur Verfügung stellen und ein Netzwerkausfall wirkt sich ziemlich ungünstig aus.
Was kann das Teil?
Einiges! Ein kleiner Abriss:
-
Klassischer Terminalservice Modus: Anmelden, Arbeit erledigen, abmelden. Es werden zusätzliche TS-CALs benötigt.
-
Remoteverwaltung: 2 Lizenzen im Server integriert, kann zur Fernwartung genutzt werden.
-
Webverwaltung: Die Terminaldienste mit Hilfe einer bereitgestellten Website verwalten.
-
Webzugriff: Einen RDP-Zugriff via Internet Explorer und ActiveX ermöglichen. Keine Zusatzsoftware notwendig. (Protokoll ist aber trotzdem RDP!)
-
Überwachung / Hilfe: Schauen, was die Benutzer auf dem TS treiben, Maus und Tastatur kann für Hilfestellungen übernommen werden.
-
Angeschlossene Laufwerke: Mittlerweile können auch lokale Laufwerke, Drucker, Zwischenablage und sogar Plug & Pray Geräte in der Terminalsitzung verwendet werden.
-
Auch die “Remoteunterstützung” von XP und Konsorten arbeitet nach dem TS-Prinzip und dem RDP Protokoll
-
Vista Experience: Eine entsprechende Grafikkarte auf dem TS vorausgesetzt, wird dem User eine Aero Umgebung zur Verfügung gestellt. Sein lokaler Rechner ist daran nicht beteiligt. (Ja Ja, ich weiß…)
-
Remote-Apps: Statt einer kompletten Windows Sitzung wird nur eine (oder mehrere) bestimmte Applikation zur Verfügung gestellt. Der Benutzer soll keinen Unterschied zu einer lokalen Installation bemerken.
Terminal Services Gateway
Terminaldienste laufen auch über das Internet flott und komfortabel. Wie erwähnt, nutzt das RDP-Protokoll Port 3389 – welcher in so gut wie keinem Unternehmen an der Firewall freigeschaltet ist. Für das Tunneling von RDP in HTTPS musste bisher auf Drittanbieter ausgewichen werden. Manch einer ist auch mit der RC4 Verschlüsselung nicht wirklich glücklich.
Das TS-Gateway ändert diesen Umstand. Der Remotedesktop Client verschlüsselt den Datenverkehr mit Hilfe von Zertifikaten und terminiert eine HTTPS Verbindung am TS-Gateway. Dieser packt die Pakete wieder aus und leitet selbige als klassische RDP-Verbindung zum Ziel. Ein Segen!
Vorbereitung
Wie so vieles, dauert die korrekte Vorbereitung fast länger, als der eigentliche Spaß. Wir 
benötigen in diesem Szenario folgende Rechner:
DC1, Gateway, Internet, CLT.home – Weiterhin muss eine eigenständige Stammzertifizierungsstelle aufgesetzt sein.
Ziel ist es, einen Internetclient via Gateway auf DC1 im LAN zugreifen zu lassen.
Die Stammzertifizierungsstelle wird unter der Domäne “elitetrainer.de” geführt. Um die CA später mit dem Namen ansprechnen zu können, erstellen wir in dieser Domäne einen DNS-Adresseintrag “pki”, der auf die Internetsimulation verweist.
Der Gateway Rechner wird später als TS-Gateway konfiguriert. Der Hostname im LAN lautet “gateway.lernschmiede.local” Da er jedoch später vom Internet aus angesprochen wird, erstellen wir auf dem DNS-Server im WAN in der schon vorhandenen DE-Zone zusätzlich die Domäne “Lernschmiede”. Danach verpassen wir auch der externen IP des Gateways einen DNS A-Eintrag. (gateway.lernschmiede.de)
Auf DC1 wird nun die Remotedesktopverbindung aktiviert. In der Demo arbeiten wir nur mit den Standardeinstellungen. Es wird sich später nur der Administrator anmelden – der auch standardmäßig TS-Zugriff hat.
Auf dem Gateway besorgen wir uns nun das “Stammzertifizierungsstellenzertifikat” von pki.elitetrainer.de. Danach beantragen wir gleich noch ein Serverzertifikat, mit Hilfe dessen später die Verbindung verschlüsselt wird. Anschließend stellen wir das Zertifikat gleich aus. Das ausgestellte Serverzertifikat wird in den lokalen Zertifikatsspeicher eingepflegt.
Auch der Internetclient “CLT.Home” benötigt das Stammzertifizierungsstellenzertifikat von pki.elitetrainer.de. Wie schon zuvor, schlagen wir uns mit der ActiveX Komponente des IE herum. Danach sind die Vorbereitungen abgeschlossen.
Screencast: Vorbereiten des Szenarios für das Terminalservice Gateway
Installation Der TS-Gateway Services und Test
Jetzt kann die TS-Rolle auf dem Gateway installiert werden. Das Gateway dient nur als Endpunkt, zum weiterleiten der Verbindung, nicht als Terminalserver selbst. Während der Installation werden gleich die wichtigsten Daten abgefragt. So kann z.B. das Zertifikat gleich angegeben werden. Weiterhin wird mit Hilfe von Richtlinien gesteuert, welche Benutzer oder Computer via TS-Gateway “reinkommen” und auf welche (TS) Rechner mit welcher Authentifizierung zugegriffen werden kann. Auch hier verwenden wir für diese kleine Demo den Weg des geringsten Widerstands.
Eine Abschlussprüfung / Import des Zertifikats schließt die Installation der TS-Gateway Rolle ab.
Auf CLT.Home wird nun der Gatewayserver eingetragen und eine Terminalverbindung zum Domänencontroller im LAN hergestellt. Da wir misstrauisch sind, prüfen wir mit Wireshark, ob die Verbindung tatsächlich sauber getunnelt wird, oder ob nicht doch noch RDP mit im Spiel ist.
Screencast: Installation des TS-Gateways und Zugriff vom Client
Zusatzinfos gibt es in diesem Thread im Technet Forum, der die gleiche Thematik in Srv 2008 R2 behandelt:
Comments
3 Comments on Terminal Services Gateway einrichten
-
Bernd Schäfer on
Do, 4th Mrz 2010 17:40
-
Michael Fritz on
Do, 4th Mrz 2010 21:37
-
Bernd Schäfer on
Fr, 5th Mrz 2010 15:58
Hallo erst mal;-)
Ich bin Anwender und habe nicht die große Ahnung, das erst einmal vorweg.
Ich habe mir einige Server zugelegt und ein paar PCs und betreibe die ganze Geschichte als Hobby, da ich Rentner bin.
Ich möchte in meiner Testumgebung Deine Konstellation nachbilden.
Habe aber noch einige Verständnissfragen.
Darf ich Dich damit belästigen?
Ich denke Du bist ein viel beschäftigter Mann und ich möchte Dich nicht mit meinem laienhaften Wissen nerven und Dir Deine wohlverdiente Freizeit stehlen.
Gib mir bitte eine kurzes Feedback und ich werde mich an Deine Antwort halten.
Moin Moin Bernd,
zunächst: Ich finde es klasse, wenn Anwender sich ein Stück tiefer mit der Thematik beschäftigen wollen. Genau das ist letztenendes mein Job und darauf fußt im weitesten Sinne auch die Lernschmiede.
Von daher: Nur zu! Der einzige Pferdefuß ist, wie Du schon richtig erwähnst: Die Zeit. Selten, aber immerhin manchmal gibt es reichlich davon. Dann engangiere ich mich in den Technetforen, bastle an der Website, beantworte Fragen und stelle neue Artikel ein.
Aber häufig zwingen einen so profane Dinge wie Brötchenverdienen, neue Produkte zu erlernen, Finanzamt, Akquise und etwas Privatleben dazu, solche Dinge nicht mit der gewünschten Intensität zu handhaben.
Vorschlag: Ich habe eine neue Seite eingerichtet:
http://www.lernschmiede.de/index.php/fragen-antworten/
Dort können wir Deine Verständnisprobleme in aller Ruhe ausdiskutieren – und vielleicht beteiligen sich auch andere.
motivierende Grüße
Michael
Hallo Michael,
ich habe heute den ganzen Tag genutzt und habe mir all Deine Beiträge auf dieser Seite angeschaut.(Einige sogar mehrfach)
Ein ganz ganz dickes Lob an Dich, alles super verständlich erklärt und wenn man es in der richtigen Reihenfolge anschaut, lösen sich auch die vorher noch vorhandenen Verständnissfragen. Wirklich ich habe die absolute Hochachtung vor Dir. Mach nur weiter so (ist ja auch in meinem Interesse) wirklich ganz ausgezeichnet. Werde mich jetzt gleich an die Umsetzung im eigenen LAN machen, bin wirklich durch Deine Beiträge bis in die Haarspitzen motiviert.
Nochmals vielen, vielen Dank !!!
Bernd Schäfer
Tell me what you're thinking...
and oh, if you want a pic to show with your comment, go get a gravatar!