Galileo Computing < openbook > Galileo Computing - Professionelle Bücher. Auch für Einsteiger.
Professionelle Bücher. Auch für Einsteiger.

Inhaltsverzeichnis
Geleitwort zu diesem Buch
Inhalt des Buchs
1 Warum eine neue Server-Version?
2 Editionen und Lizenzen
3 Hardware und Dimensionierung
4 Protokolle
5 Was überhaupt ist .NET?
6 Installation
7 Core-Installationsoption
8 Active Directory-Domänendienste
9 Netzwerkdienste im AD-Umfeld
10 Active Directory Lightweight Directory Services (AD LDS)
11 Active Directory-Verbunddienste (Federation Services)
12 Active Directory-Zertifikatdienste
13 Active Directory-Rechteverwaltungsdienste (AD RMS)
14 »Innere Sicherheit«
15 Dateisystem und Dateidienste
16 Drucken
17 Webserver (IIS)
18 SharePoint (Windows SharePoint Services, WSS)
19 Remotedesktopdienste (Terminaldienste)
20 Hochverfügbarkeit
21 Datensicherung
22 Servervirtualisierung mit Hyper-V
23 Windows PowerShell
24 Windows 7 und Windows Server 2008 R2
Stichwort

Download:
- ZIP, ca. 104 MB
Buch bestellen
Ihre Meinung?

Spacer
<< zurück
Windows Server 2008 R2 von Ulrich B. Boddenberg
Das umfassende Handbuch
Buch: Windows Server 2008 R2

Windows Server 2008 R2
geb., 1.410 S., 59,90 Euro
Galileo Computing
ISBN 978-3-8362-1528-2
Pfeil 19 Remotedesktopdienste (Terminaldienste)
Pfeil 19.1 Die Funktionen aus 10.000 m Höhe
Pfeil 19.2 Installation
Pfeil 19.3 Feature »Desktopdarstellung« installieren
Pfeil 19.4 Benutzerzugriff
Pfeil 19.5 Installation von Anwendungen
Pfeil 19.6 Desktop bereitstellen
Pfeil 19.7 RemoteApp-Programme
Pfeil 19.8 Administration und Verwaltung
Pfeil 19.8.1 Konfiguration des Remotedesktop-Sitzungshosts
Pfeil 19.8.2 Benutzeradministration
Pfeil 19.8.3 Remotedesktopdienste-Manager
Pfeil 19.8.4 Loopback-Verarbeitung
Pfeil 19.8.5 Remotedesktopdienste-Lizenzierungung
Pfeil 19.9 Drucken, Easy Print
Pfeil 19.9.1 Installation von Easy Print
Pfeil 19.9.2 Kurze Überprüfung
Pfeil 19.9.3 Gruppenrichtlinien
Pfeil 19.10 Web Access für Remotedesktop
Pfeil 19.11 RemoteApp- und Desktopverbindungen mit Windows 7
Pfeil 19.12 Remotedesktopdienste-Farmen mit Netzwerklastenausgleich und Remotedesktopdienste-Verbindungsbroker
Pfeil 19.12.1 Installation
Pfeil 19.12.2 Überwachen
Pfeil 19.12.3 RemoteApp-Programme »umpaketieren«
Pfeil 19.13 Remotedesktopdienste-Farmen mit DNS Round Robin bzw. Verbindungsbroker
Pfeil 19.14 Remotedesktopgateway
Pfeil 19.14.1 Anwendung und Architektur
Pfeil 19.14.2 Installation
Pfeil 19.14.3 Konfiguration
Pfeil 19.14.4 Clientkonfiguration und Verbindungsaufbau
Pfeil 19.14.5 Überwachung
Pfeil 19.14.6 NAP und das Remotedesktopgateway
Pfeil 19.15 Host für Remotedesktopvirtualisierung
Pfeil 19.15.1 Funktionsweise
Pfeil 19.15.2 Installation
Pfeil 19.15.3 Virtuelle Maschinen konfigurieren
Pfeil 19.15.4 Benutzer administrieren
Pfeil 19.15.5 Testen und verwenden
Pfeil 19.16 Schlussbemerkung


Galileo Computing - Zum Seitenanfang

19.14 Remotedesktopgateway Zur nächsten ÜberschriftZur vorigen Überschrift

In der heutigen Zeit kann man nicht mehr davon ausgehen, dass die Mehrheit der Mitarbeiter eines Unternehmens den größten Teil ihrer Zeit im Büro, sei es in der Zentrale oder einer Niederlassung, verbringt. Vielmehr wandelt sich das Arbeitsleben dahingehend, dass viele mobile Benutzer existieren oder solche, die vom Homeoffice aus arbeiten.

Klassischerweise greifen diese Benutzer über ein VPN zu; die Remotedesktopdienste von Windows Server 2008 (R2) stellen mit der Komponente Remotedesktopgateway eine Komponente zur Verfügung, die den Verbindungsaufbau durch das Internet zu einem Remotedesktop-Sitzungshost ohne ein VPN ermöglicht. Stattdessen wird eine SSL-Verbindung verwendet, wobei die RDP-Pakete durch RPC over HTTPS getunnelt werden. Das Prinzip entspricht übrigens dem RPC over HTTPS, das viele Leser bestimmt von Outlook und Exchange Server her kennen, Stichwort: Outlook Anywhere.

Wenn Sie zur Anbindung von mobilen Clients oder Homeoffice-Mitarbeitern nicht aus anderen Gründen ein »normales« VPN benötigen, ist die Nutzung von SSL-Verbindungen eine gute Alternative:

  • SSL-Verbindungen sind einfach einzurichten.
  • Sie sind kostengünstig. (Bei vielen VPN-Produkten muss pro angebundenem Client eine Lizenz erworben werden.)
  • Der Verbindungsaufbau ist schnell.

Falls Sie allerdings ohnehin ein »herkömmliches« VPN benötigen, beispielsweise weil die Anwender mit einer lokalen Applikation vom Notebook auf das Dateisystem eines Servers zugreifen müssen, können Sie auch den Zugriff auf die Remotedesktopdienste über das VPN laufen lassen.


Galileo Computing - Zum Seitenanfang

19.14.1 Anwendung und Architektur Zur nächsten ÜberschriftZur vorigen Überschrift

Abbildung 19.114 zeigt ein Szenario, im dem das Remotedesktopgateway verwendet wird:

  • In der DMZ der Firewall steht das Remotedesktopgateway, auf das der Client über eine HTTPS-Verbindung zugreift.
  • Das Remotedesktopgateway prüft den Kommunikationswunsch des Clients (d. h., welcher Benutzer mit welchem Remotedesktop-Sitzungshost kommunizieren möchte).
  • Bei der Überprüfung greift das Remotedesktopgateway auf einen Domänencontroller und einen Netzwerkrichtlinienserver (Network Policy Server, NPS) zu. Es wird also NAP, Network Access Protection, verwendet. Es gibt also etliche Server bzw. deren Dienste, die vom Remotedesktopgateway erreicht werden müssen.
  • Wenn der Kommunikationswunsch des Benutzers »genehmigt« ist, leitet das Remotedesktopgateway die RDP-Pakete (nun ohne die RPC over HTTPS-Hülle) an den entsprechenden Remotedesktop-Sitzungshost weiter.

Abbildung 19.114 Eine Funktionsskizze für die Verwendung des Remotedesktopgateways

Die zuvor gezeigte und besprochene Konfiguration ist vergleichsweise schnell eingerichtet – und funktioniert. Sie ist aber trotzdem nicht optimal:

  • Das Remotedesktopgateway steht vergleichsweise ungeschützt in der DMZ.
  • Sie müssen relativ viele Ports in den Innenbereich des Netzes öffnen, denn das Remotedesktopgateway muss auf alle Remotedesktop-Sitzungshosts, das Active Directory und einen Netzwerkrichtlinienserver zugreifen.

Abbildung 19.115 zeigt eine verbesserte Situation:

  • Hinter der Firewall wird ein Microsoft ISA Server positioniert. Alternativ könnte der ISA Server in die DMZ der Firewall gestellt werden.
  • Auf dem ISA Server wird eine sichere Webveröffentlichung des Remotedesktopgateways auf Port 443 konfiguriert.
  • Der Remotedesktopgateway-Server kann so im Innenbereich des Netzes stehen.

Abbildung 19.115 Hier wird der ISA Server verwendet, um das Remotedesktopgateway zu veröffentlichen.

Die Vorteile dieser Architektur sind offensichtlich:

  • Es müssen nicht umständlich Ports von einem in der DMZ stehenden Remotedesktopgateway in den Innenbereich geöffnet werden.
  • ISA Server ist ein sehr sicheres Gateway zum Internet. Es bietet deutlich mehr Schutzfunktionen als ein vergleichsweise »dummer« Portfilter.
  • Der ISA Server kann (und sollte!) den SSL-Verkehr terminieren. Ob zum Remotedesktopgateway eine HTTPS- oder HTTP-Verbindung zur Anwendung kommt, müssen Sie im Einzelfall prüfen und entscheiden.

Das Remotedesktopgateway sollte stets auf einem dedizierten Rechner installiert werden und insbesondere nicht auf einem Remotedesktop-Sitzungshost laufen. Eine Koexistenz mit dem RPC over HTTPS-Gateway, wie es von Exchange verwendet wird, ist auf einem Server möglich.


Galileo Computing - Zum Seitenanfang

19.14.2 Installation Zur nächsten ÜberschriftZur vorigen Überschrift

Die Installation verläuft wie üblich assistentengeführt und stellt keinerlei Problem dar, obwohl diverse Komponenten eingerichtet werden müssen, von denen das Remotedesktopgateway abhängig ist. Es empfiehlt sich aber, zwei vorbereitende Schritte durchzuführen, bevor Sie die Installation des Rollendiensts aufrufen.

Vorbereitung

Während der Installation müssen Sie zwei Eingaben durchführen: Sie müssen ein Zertifikat angeben sowie eine Gruppe mit den Remotedesktop-Sitzungshosts, auf die über das Remotedesktopgateway zugegriffen werden darf. Letzteres ist zwar optional, macht aber trotzdem Sinn.

Zertifikat installieren

Auf dem Remotedesktopgateway ist für die SSL-Verschlüsselung der Verbindung ein Zertifikat erforderlich. Dies kann entweder ein gekauftes Zertifikat (VeriSign, Thawte & Co.) sein oder eines, das Sie mit einer eigenen Zertifizierungsstelle erzeugt haben.


Dritter Weg

Der dritte Weg ist, im Verlauf des Installationsassistenten ein selbstsigniertes Zertifikat erstellen zu lassen (das ist übrigens nicht zu verwechseln mit »Von einer eigenen Zertifizierungsstelle ausgestellt«), was aber für den Produktivbetrieb nicht zu empfehlen ist.


Am einfachsten ist es, wenn Sie im Netz eine eigene Active Directory-integrierte Zertifizierungsstelle einsetzen. Wie Sie eine solche Zertifizierungsstelle einrichten, ist in Kapitel 12 ausführlich beschrieben. In diesem Fall ist die Vorgehensweise wie folgt:

  • Öffnen Sie die MMC, und Sie fügen das Snap-In Zertifikate hinzu. Geben Sie an, dass die Zertifikate des Computerkontos verwaltet werden sollen (Abbildung 19.116).
  • Falls bislang kein Zertifikat für diesen Computer ausgestellt worden ist, werden Sie unterhalb des Knotens Eigene Zertifikate nur »Leere« finden. Wählen Sie im Kontextmenü den Menüpunkt Neues Zertifikat anfordern. Hinweis: Falls Sie keine Active Directory-integrierte Zertifizierungsstelle betreiben, können Sie an dieser Stelle das Importieren eines gekauften Zertifikats wählen (Abbildung 19.117).
  • Abbildung 19.118 zeigt die Auswahl des Zertifikatstyps im Assistenten (nur mit AD-integrierter Zertifizierungsstelle) und das fertige Zertifikat. Beachten Sie, dass die Clients eine Verbindung unter Verwendung des Rechnernamens aufbauen müssen, auf den das Zertifikat ausgestellt ist (hier: ubinfWARD.ubinf.intra). An dieser Stelle wäre anzumerken, dass Sie in der Praxis vermutlich eine Serververöffentlichung mit dem ISA Server durchführen werden, so dass es korrekt ist, das Zertifikat auf den internen Namen des Remotedesktopgateway-Servers auszustellen.

Abbildung 19.116 Öffnen Sie den Zertifikatsspeicher des Computerkontos auf dem zukünftigen Remotedesktopgateway-Server.

Abbildung 19.117 Falls bislang kein Computerzertifikat vorhanden ist, können Sie hier ein neues anfordern.

Abbildung 19.118 Im Assistenten bestätigen Sie das Anfordern eines Computer-Zertifikats. Rechts ist das »Ergebnis« zu sehen. Achten Sie besonders auf den Namen, für den das Zertifikat ausgestellt wurde (»Ausgestellt für«).

Eine Gruppe mit Remotedesktop-Sitzungshosts anlegen

Um die »Missbrauchsgefahr« noch stärker einzudämmen, empfiehlt es sich, nur bestimmte Server für den Zugriff über das Remotedesktopgateway freizuschalten. Im Verlauf des Assistenten werden Sie nach einer solchen Gruppe gefragt, die Sie am besten bereits im Vorfeld einrichten (Abbildung 19.119).

Abbildung 19.119 Diese Gruppe enthält die Remotedesktop-Sitzungshosts, auf die ein Zugriff über das Remotedesktopgateway möglich sein soll. Sie sollten sie im Vorfeld anlegen.

Es handelt sich um eine »ganz normale Gruppe«, in der die entsprechenden Computerkonten Mitglied werden.

Installation des Remotedesktopgateways

Die eigentliche Installation des Remotedesktopgateways erfolgt wie gewohnt vom Server-Manager aus; Remotedesktopgateway ist ein Rollendienst der Remotedesktopdienste.

Wie Sie in Abbildung 19.120 sehen können, sind diverse zusätzliche Komponenten erforderlich, insbesondere:

  • ein Webserver, der für die Abwicklung der HTTP-Kommunikation zuständig ist.
  • Der RPC-über-HTTP-Proxy wird benötigt, um die in HTTP eingekapselten RPC-Pakete »auseinanderzunehmen«.
  • Der Netzwerkrichtlinienserver (Network Policy Server, NPS) wird zur Durchsetzung der Zugriffsrichtlinien benötigt.

Abbildung 19.120 Der Rollendienst Remotedesktopgateway benötigt etliche Helfer.

Der Installationsassistent fragt zunächst ab, welches Zertifikat verwendet werden soll. Sofern sich das zu verwendende Zertifikat im Zertifikatsspeicher des Computerkontos befindet, wird es direkt zur Auswahl angeboten (Abbildung 19.121).

Eine Alternative ist die Erstellung eines selbstsignierten Zertifikats, was aber grundsätzlich nicht zu empfehlen ist. Sie können die SSL-Verschlüsselung auch später konfigurieren, allerdings ist das Remotedesktopgateway so lange nicht funktionsfähig, bis ein Zertifikat installiert ist (Ausnahme: Sie konfigurieren SSL-Bridging).

Um die Verwendung des Remotedesktopgateway zu steuern, werden Autorisierungsrichtlinien benötigt. Sie können die Richtlinien direkt im Assistenten erzeugen (Abbildung 19.122). Alternativ könnten Sie das auch zu einem späteren Zeitpunkt erledigen – aber warum nicht gleich?

Abbildung 19.121 Es muss zwingend ein Zertifikat für die SSL-Verschlüsselung angegeben werden. Am besten ist es, wenn bereits eines im Zertifikatsspeicher vorhanden ist.

Abbildung 19.122 Eine Autorisierungsrichtlinie kann direkt durch den Installationsassistenten erstellt werden.

Zunächst wird festgelegt, welche Benutzergruppen das Gateway nutzen dürfen – mehr ist dazu nicht zu sagen (Abbildung 19.123).

Abbildung 19.123 Erstellen der Autorisierungsrichtlinie: Nur diese Benutzergruppen dürfen das RDGW nutzen.

Im nächsten Schritt geht es um die Erstellung der Clientzugriffsrichtlinie (Abbildung 19.124). Auf der Dialogseite des Assistenten legen Sie fest, welche Authentifizierungsmethode (Kennwort oder Smartcard) zulässig sein soll. In der »fertigen« Richtlinie werden sich dann auch die zuvor ausgewählten Benutzergruppen finden.

Die zweite Richtlinie ist die Ressourcenautorisierungsrichtlinie (Abbildung 19.125). Mit dieser kann ganz primär gesteuert werden, auf welche Remotedesktop-Sitzungshosts über das Remotedesktopgateway zugriffen werden kann. Ich hatte Ihnen zu Beginn der Installationsanleitung empfohlen, eine weitere AD-Gruppe anzulegen, deren Mitglieder die Computerkonten der Remotedesktop-Sitzungshosts sind – diese wird hier eingetragen.

Abbildung 19.124 Erstellen der Remotedesktopdienste-Verbindungsautorisierungsrichtlinie (RD-CAP)

Abbildung 19.125 Erstellen der Remotedesktopdienste-Ressourcenautorisierungsrichtlinie (RD-RAP). Hier kommt die zuvor erstellte Gruppe zur Verwendung.

Alternativ können Sie den Zugriff auf sämtliche Server zulassen, allerdings wären dann auch alle Server mit aktiviertem Remotezugriff erreichbar, was vermutlich nicht gewollt sein wird. Die fertig angelegte Richtlinie bietet übrigens einige zusätzliche Konfigurationsmöglichkeiten, aber der primäre Gedanke ist, die Server festzulegen, die überhaupt über das Gateway erreichbar sein sollen.

Zu Beginn hatte ich Sie darauf hingewiesen, dass diverse zusätzliche Funktionen benötigt und vom Assistenten folglich automatisch mitinstalliert werden. Obwohl der Assistent Ihnen jeweils die Dialoge zur Auswahl der Rollendienste vorlegt, können Sie die vorgeschlagenen Auswahlen einfach bestätigen. Exemplarisch sehen Sie auf Abbildung 19.126 die Auswahl für die Netzwerkrichtlinien- und Zugriffsdienste: Benötigt wird hier nur der Netzwerkrichtlinienserver, der auch bereits selektiert sein wird. Die folgende Dialogseite fragt ab, welche Rollendienste des Webservers installiert werden sollen. Auch hier müssen Sie lediglich die Auswahl bestätigen.

Abbildung 19.126 Bestätigen Sie die Installation des Netzwerkrichtlinienservers.

Die eigentliche Installation läuft »ein Weilchen«: Immerhin ist einiges zu installieren. Nach Abschluss ist das Remotedesktopgateway mehr oder weniger betriebsbereit.


Galileo Computing - Zum Seitenanfang

19.14.3 Konfiguration Zur nächsten ÜberschriftZur vorigen Überschrift

In diesem Abschnitt möchte ich Sie in kurzer und knapper Form auf einige Aspekte der Konfiguration des Remotedesktopgateway aufmerksam machen. Die Grundkonfiguration ist vom Assistenten so weit vorgenommen worden, dass keine wirklich grundlegenden Einrichtungsarbeiten mehr notwendig sind. Es kann aber erfahrungsgemäß nicht schaden, ein wenig durch die Dialoge »zu blättern«, um ein Gefühl dafür zu bekommen, was noch alles konfiguriert werden kann.

Nach der Installation des Remotedesktopgateway taucht ein neues Konfigurationswerkzeug auf, nämlich der Remotedesktopgateway-Manager, (Abbildung 19.127). Mit diesem Werkzeug können Sie die grundlegenden Arbeiten vergleichsweise einfach erledigen. Wenn Sie tiefer einsteigen möchten, werden Sie darüber hinaus einige Einstellungen im Verwaltungswerkzeug des Netzwerkrichtlinienservers vornehmen müssen.

Abbildung 19.127 Nach der Installation des Remotedesktopgateways ist ein neues Verwaltungswerkzeug vorhanden: der Remotedesktopgateway-Manager.

Der Remotedesktopgateway-Manager ist ein vergleichsweise »übersichtliches« Werkzeug (Abbildung 19.128):

  • Auf der linken Seite befindet sich die obligatorische Baumansicht mit einigen Konfigurationsoptionen. Außer an den Eigenschaften des Servers selbst können Sie allerdings nur an den Richtlinien herumbasteln.
  • Die beim Start des Werkzeugs aufgerufene initiale Ansicht gibt einen ersten Überblick über den Status des Gateways.

Eigenschaften des Remotedesktopgateways

Der Eigenschaftendialog des Remotedesktopgateway umfasst sieben Registerkarten, die ich allerdings nicht einzeln durcharbeiten möchte (Abbildung 19.129). Die Einstellmöglichkeiten sind weitestgehend selbsterklärend. Die »komplizierteste« Angelegenheit beim Remotedesktopgateway dürfte die Integration in einen zentralen NPS (Network Policy Server) sein, was ich Ihnen im weiteren Verlauf dieses Kapitels sehr detailliert vorführen werde.

Abbildung 19.128 Der Remotedesktopgateway Manager bietet einen Schnellüberblick über den aktuellen Zustand. Auf der linken Seite finden Sie die obligatorische Baumansicht der Konfigurationsoptionen

Abbildung 19.129 Die Eigenschaften des Remotedesktopgateway-Servers werden auf sieben Registerkarten konfiguriert.

Verbindungsautorisierungsrichtlinien

Wenn Sie den Assistenten bei der Installation damit »beauftragt« haben, wird bereits eine Verbindungsautorisierungsrichtlinie vorhanden sein, die im Grunde genommen zwei wesentliche Aspekte regelt:

  • Mit ihr wird definiert, welche Benutzergruppen das Remotedesktopgateway nutzen dürfen und welche Authentifizierungsmethode dabei verwendet wird. Optional kann, ebenfalls mit Gruppen, bestimmt werden, welche Clientcomputer verwendet werden dürfen (Abbildung 19.130).
  • Weiterhin kann festgelegt werden, welche Ressourcen der Clients in den Remotedesktopdienste-Sitzungen genutzt werden dürfen (Abbildung 19.131).

Abbildung 19.130 Auf dieser Dialogseite wird festgelegt, welche Benutzergruppen Zugriff auf das Remotedesktopgateway haben sollen.

Abbildung 19.131 Es kann konfiguriert werden, ob Geräteumleitungen erlaubt sind.


»Gesunde Systeme«

Falls Sie bereits Abschnitt 14.1 gelesen haben, in dem die Network Access Protection (NAP) besprochen wird, werden Sie für das Thema »Gesundheitsstatus« des Clients sensibilisiert sein – umso mehr, wenn lokale Ressourcen des Clients in einer Remotedesktopdienste-Sitzung verwendet werden. Es bietet sich an, das Verbinden der Clients über das Remotedesktopgateway nur dann zu erlauben, wenn diese die Anforderungen an »gesunde« Systeme erfüllt. Mit dem einfachen standardmäßigen Verbindungsautorisierungsrichtlinien-Dialog kann dies zwar nicht eingestellt werden, da aber der Netzwerkrichtlinienserver dahintersteht, ist eine solche Konfiguration realisierbar – mehr dazu später.


Ressourcenautorisierungsrichtlinien

Der Installationsassistent wird weiterhin eine Ressourcenautorisierungsrichtlinie angelegt haben. Auch diese umfasst die Benutzergruppen, die das Remotedesktopgateway nutzen dürfen (Abbildung 19.132). Weiterhin wird auf der Registerkarte Computergruppe festgelegt, ob beliebige Remotedesktop-Sitzungshosts über das Gateway erreicht werden können. Besser ist es natürlich, eine Gruppe anzugeben, deren Mitglieder die Computerkonten sind, auf die Zugriff möglich sein soll (Abbildung 19.133).

Abbildung 19.132 Mit der Ressourcenautorisierungsrichtlinie können Sie einstellen, welche Benutzergruppen auf welchen Remotedesktop-Sitzungshost Zugriff haben.

Abbildung 19.133 Hier findet sich die Einstellung für die Computergruppe, die die im Zugriff befindlichen Server enthält.


Galileo Computing - Zum Seitenanfang

19.14.4 Clientkonfiguration und Verbindungsaufbau Zur nächsten ÜberschriftZur vorigen Überschrift

Der »normale« Remotedesktopverbindungs-Client ist seit der Version 6.0 in der Lage, Verbindungen zum Remotedesktopgateway aufzubauen.

Auf der Registerkarte Allgemein tragen Sie den Namen des zu nutzenden Remotedesktop-Sitzungshost bzw. den Namen der Farm ein – so, als wäre nie vom Remotedesktopgateway die Rede gewesen. Auf der Registerkarte Leistung können Sie in der Rubrik Verbindung von überall aus herstellen den Dialog aus Abbildung 19.134 aufrufen – das dürfte so weit selbsterklärend sein. Sehr nützlich ist übrigens die Checkbox Remotedesktop-Gatewayserver für lokale Adressen nicht verwenden: Diese Auswahl führt erwartungsgemäß dazu, dass eine »direkte Verbindung« erfolgt, wenn der PC im lokalen Netz und nicht in den Weiten des Internets steht.

Abbildung 19.134 Konfiguration des Remotedesktopverbindungs-Clients


Zur Erinnerung

Für die Verbindung vom Remotedesktopverbindungs-Client zum Remotedesktopgateway wird die Information über die Adresse des Gateways benötigt (im Allgemeinen eine URL, die über das Internet zu erreichen ist).

Zum Aufbau der Verbindung vom Remotedesktopgateway bis zum eigentlichen Remotedesktop-Sitzungshost wird der interne Name des Remotedesktop-Sitzungshosts bzw. der Farm benötigt.


Wird eine Verbindung über das Remotedesktopgateway aufgebaut, ist der Anmeldedialog ein wenig modifiziert. Es wird darauf hingewiesen, dass für die Verbindung das Gateway genutzt wird (Abbildung 19.135). Auf dem Dialog ist auch schön die »Zweiteiligkeit« der Verbindung zu erkennen: Zunächst zum Remotedesktopdienste-Gatewayserver und von dort aus zum Remotedesktop-Sitzungshost bzw. zur Farm.

Abbildung 19.135 Wenn eine Verbindung über das Remotedesktopgateway aufgebaut wird, ist dies im Anmeldedialog angegeben.

Selbstverständlich ist die Konfiguration der Remotedesktopgateway-Einstellungen auch über Gruppenrichtlinien möglich. Sie finden diese in der Benutzerkonfiguration unter Administrative VorlagenWindows-KomponentenRemotedesktopdiensteRemotedesktopgateway (Abbildung 19.136).

Abbildung 19.136 Die Einstellungen für das Remotedesktopgateway können auch über Gruppenrichtlinien vorgenommen werden.

Es ist noch darauf hinzuweisen, dass in den Konfigurationsdateien von RemoteApp-Programmen die »passenden« Remotedesktopgateway-Einstellungen angegeben werden können; den entsprechenden Dialog sehen Sie in Abbildung 19.137.

Wenn Sie dieses Buch von vorn nach hinten durcharbeiten, wissen Sie, dass ich großer Fan des Netzwerkmonitors bin. Auch in diesem Fall möchte ich Ihnen den Mitschnitt der Kommunikation zwischen einem Remotedesktopverbindungs-Client und einem Remotedesktopgateway zeigen. Wie Sie in Abbildung 19.138 sehen können, läuft die Verbindung in der Tat ausschließlich über Port 443. Neben den TCP-Statuspaketen sind nur SSL-Pakete zu sehen.

Abbildung 19.137 Bei RemoteApp-Programmen kann die Remotedesktopgateway-Einstellung hinterlegt werden.

Abbildung 19.138 Dies ist ein Mitschnitt der Kommunikation zwischen Remotedesktopverbindungs-Client und Remotedesktopgateway: Alles läuft über Port 443.


Galileo Computing - Zum Seitenanfang

19.14.5 Überwachung Zur nächsten ÜberschriftZur vorigen Überschrift

Im Remotedesktopgateway-Manager finden Sie einen Knoten Überwachung, der zu einer Ansicht führt, in der Sie mit einem Blick erkennen können, welche Benutzer derzeit mit dem Gateway verbunden sind (Abbildung 19.139). Diese Dialogseite ist durchaus hilfreich; die Bezeichnung »Überwachung« erscheint mir allerdings etwas hochgegriffen. Eine »richtige« Überwachung muss weitere quantitative Angaben umfassen, um beispielsweise mögliche Engpässe erkennen zu können. Im Systemmonitor finden sich diverse Leistungsindikatoren, und zwar unter den Titeln Remotedesktopgateway, RPC-/HTTP-Proxy und RPC-/HTTP-Proxy pro Server (Abbildung 19.140).

Abbildung 19.139 Man kann auf einen Blick sehen, welche Benutzer momentan über das Remotedesktopgateway verbunden sind.

Abbildung 19.140 Im Systemmonitor gibt es diverse Leistungsindikatoren rund um das RDGW und den RPC-/HTTP-Proxy (ja, im Leistungsmonitor werden noch die »alten« Namen verwendet).


Galileo Computing - Zum Seitenanfang

19.14.6 NAP und das Remotedesktopgateway topZur vorigen Überschrift

Mittels Network Access Protection (NAP) kann geprüft, werden, ob ein Client gewissen Anforderungen genügt, beispielsweise können Voraussetzungen wie die aktuelle Virensignatur, die aktivierte Firewall und aktuelle Patchlevel durchgesetzt werden. Bei der Installation des Remotedesktopgateways ist eine der Installationsvoraussetzungen der Netzwerkrichtlinienserver (NPS – Network Policy Server), zu dessen Aufgaben unter anderem die Durchsetzung genau solcher Richtlinien gehört.

Wenn Sie auf dem Remotedesktopgateway-Server das Verwaltungswerkzeug des Netzwerkrichtlinienservers aufrufen, werden Sie feststellen, dass dort eine Verbindungsanforderungsrichtlinie und eine Netzwerkrichtlinie für die Nutzung durch das Remotedesktopgateway angelegt worden sind (Abbildung 19.141). Eine Integritätsrichtlinie ist allerdings nicht vorhanden, so dass standardmäßig keine Überprüfung des Gesundheitszustands der zugreifenden Clients erfolgt.

Abbildung 19.141 Auf dem Netzwerkrichtlinienserver, der auf dem Remotedesktopgateway-Server installiert ist, finden Sie eine Verbindungsanforderungsrichtlinie und eine Netzwerkrichtlinie.

Diese »fehlende« Integritätsrichtlinie ließe sich zwar ohne größere Probleme hinzufügen, vermutlich stellt sich aber eine ganz andere Anforderung: Wenn ein Unternehmen bzw. eine Organisation sich für die Nutzung von NAP (Network Access Protection) entscheidet, wird es viele verschiedene Erzwingungspunkte geben.


Erzwingungspunkte

Erzwingungspunkte sind die Punkte, an denen Clients auf Ihre Kompatibilität zu den Richtlinien hin überprüft werden, wobei nur einem kompatiblen Client Zugriff gewährt wird. Das Remotedesktopgateway ist so ein Erzwingungspunkt.


Nun wäre es recht lästig, die Richtlinien jeweils lokal auf den einzelnen Erzwingungspunkten verwalten zu müssen. Es wird also der dringende Wunsch vorhanden sein, einen zentralen Netzwerkrichtlinienserver aufzusetzen, den die einzelnen Erzwingungspunkte kontaktieren, um die Kompatibilität der Clients mit den netzwerkweit gültigen Richtlinien zu überprüfen. Es sind also folgende Aufgaben zu erledigen:

  • Sie müssen dafür sorgen, dass das Remotedesktopgateway mit dem zentralen Netzwerkrichtlinienserver zusammenarbeitet.
  • Sie müssen die Richtlinie für Zugriffe über das Remotedesktopgateway einrichten.
  • Sie müssen die Clients so einrichten, dass sie die relevanten »Gesundheitsinformationen« bei der Anmeldung am Remotedesktopgateway übermitteln.

In den folgenden Abschnitten werde ich genau diese Arbeitsschritte im Detail vorführen. Ich gehe davon aus, dass ein zentraler Netzwerkrichtlinienserver vorhanden ist.

Ausführliche Informationen zur Funktionsweise und Einrichtung des Netzwerkrichtlinienservers und von NAP finden Sie in Abschnitt 14.1.

Vorbereitungen auf dem zentralen Netzwerkrichtlinienserver

Im ersten Schritt richten Sie das Remotedesktopgateway auf dem zentralen Netzwerkrichtlinienserver als RADIUS-Client ein. Rufen Sie dazu, wie in Abbildung 19.142 gezeigt, den entsprechenden Menüpunkt auf.

Abbildung 19.142 Das Remotedesktopgateway wird als RADIUS-Client eingerichtet.

Daraufhin öffnet sich der Dialog aus Abbildung 19.143:

  • Tragen Sie die notwendigen Informationen, wie den Namen des Remotedesktopgateway-Servers, ein.
  • Dann generieren Sie einen gemeinsamen geheimen Schlüssel.
  • Diesen kopieren Sie in die Zwischenablage oder eine Datei; Sie müssen ihn gleich in einem Dialog auf dem Remotedesktopgateway parat haben.

Abbildung 19.143 Ein wesentlicher Aspekt bei der Einrichtung eines RADIUS-Clients ist der gemeinsame geheime Schlüssel.

Konfiguration auf dem Remotedesktopgateway-Server

Um das Remotedesktopgateway dazu zu bringen, mit dem zentralen Netzwerkrichtlinienserver zusammenzuarbeiten, gehen Sie folgendermaßen vor:

  • Im Remotedesktopgateway-Manager rufen Sie die Eigenschaften des Servers auf.
  • Wechseln Sie auf die Registerkarte RD-CAP-Speicher (wenn Sie mit Windows Server 2008 ohne R2 arbeiten, heißt diese übrigens TS-CAP).
  • Achten Sie darauf, dass die Checkbox Clients zum Senden eines SoHs auffordern aktiviert ist.
  • Wählen Sie die Option Zentraler NPS.
  • Tragen Sie den zentralen Netzwerkrichtlinienserver ein. Neben dem Namen wird der gemeinsame geheime Schlüssel benötigt, den Sie zuvor beim Anlegen des RADIUS-Client-Eintrags erzeugt haben (Abbildung 19.144).

Abbildung 19.144 Wählen Sie in den Eigenschaften des Remotedesktopgateways die Verwendung eines »Zentralen NPS«. Dazu tragen Sie den Namen des zentralen Netzwerkrichtlinienservers und den gemeinsamen geheimen Schlüssel ein.

Wenn es keine Tippfehler oder dergleichen gibt, werden das Remotedesktopgateway und der zentrale Netzwerkrichtlinenserver ab jetzt gut zusammenarbeiten. Clients können sich übrigens momentan nicht anmelden, da noch keine Richtlinie auf dem zentralen NPS vorhanden ist.

Im Remotedesktopgateway-Manager ist übrigens eine kleine, aber wichtige Änderung zu beobachten: Der Knoten, der vormals Verbindungsautorisierungsrichtlinien hieß, ist in Zentrale Netzwerkrichtlinienserver umbenannt worden (Abbildung 19.145). Klickt man darauf, werden der (oder die) zentrale NPS angezeigt. Die Konfiguration der Richtlinien erfolgt nun nicht mehr wie zuvor im Remotedesktopgateway-Manager, sondern auf dem zentralen Netzwerkrichtlinienserver.

Abbildung 19.145 Eine kleine, aber wichtige Änderung: »Früher« hieß der Knoten »Verbindungsautorisierungsrichtlinien«, nun heißt er »Zentrale Netzwerkrichtlinienserver«.

NAP-Assistenten ausführen

Auf dem zentralen Netzwerkrichtlinienserver wird nun der Assistent zum Erzeugen des Regelwerks für den Remotedesktopgateway-Zugriff gestartet. Sie könnten die Regeln zwar auch »per Hand« erstellen – aber wir machen uns das Leben alle gern ein bisschen einfacher.

Abbildung 19.146 Zunächst wählen Sie die Verbindungsmethode und den Remotedesktopgateway-Server aus.

Hier folgen die Einstellungen des Assistenten in Kurzform; mehr Details finden Sie in Abschnitt 14.1:

  • Beim Start des Assistenten müssen Sie zunächst die Netzwerkverbindungsmethode wählen. Das ist natürlich Remotedesktopgateway (Abbildung 19.146, links).
  • Auf der nächsten Dialogseite wählen Sie den Remotedesktopgateway-Server aus (Abbildung 19.146, rechts). Wenn Sie, wie zuvor erklärt, das Remotedesktopgateway als RADIUS-Client angelegt haben, wird es hier aufgelistet sein. In dem Dialog werden übrigens sämtliche eingetragenen RADIUS-Clients angezeigt; alles, was kein Remotedesktopgateway ist, wird gelöscht.

Nun folgen ein paar Einstellungen, die für das Remotedesktopgateway spezifisch sind (Abbildung 19.147):

  • Zunächst legen Sie die Geräteumleitungen und Authentifizierungsmethoden fest (Abbildung links).
  • Im nächsten Dialog werden die zugelassenen Benutzergruppen konfiguriert.

Abbildung 19.147 Hier legen Sie fest, ob die Umleitung der lokalen Geräte zulässig sein soll. Weiterhin definieren Sie die erlaubten Benutzergruppen.

  • Zum Schluss wählen Sie die Systemintegritätsprüfungen aus. Standardmäßig ist nur die Windows-Sicherheitsintegritätsverifizierung vorhanden. Diese prüft beispielsweise, ob aktuelle Virensignaturen vorhanden sind, ob die Firewall läuft und dergleichen mehr (Abbildung 19.148).

Abbildung 19.148 In diesem Dialog wählen Sie aus, welche Systemintegritätsprüfungen verwendet werden sollen – standardmäßig ist nur die »Windows-Sicherheitsintegritätsverifizierung« vorhanden.

Der Assistent legt mehrere Richtlinien an, und zwar eine Verbindungsanforderungsrichtlinie, drei Netzwerkrichtlinien und zwei Integritätsrichtlinien. Ich möchte nun nicht alle Details der generierten Richtlinien diskutieren; in Abbildung 19.149 sehen Sie eine Netzwerkrichtlinie: Sie sehen, dass unter anderem eine Integritätsrichtlinie als Bedingung eingetragen ist. Diese prüft den Gesundheitszustand des Clients.

Abbildung 19.149 Ein erster Blick auf die neu angelegte Netzwerkrichtlinie für kompatible Clients. Als Bedingung ist unter anderem eine Integritätsrichtlinie angegeben.

Anpassung der Clients

Wenn Sie nun testweise von einem Client, auf dem NAP nicht oder nicht für diesen Verwendungszweck konfiguriert ist, eine Verbindung zum Remotedesktopgateway aufbauen möchten, gibt es das in Abbildung 19.150 gezeigte Ergebnis: Keine Verbindung.

Falls Sie bereits ein wenig NAP-Erfahrung haben, wird Ihr erster Gedanke sein, dass Sie den TS-Gateway-Quarantäneerzwingungsclient aktivieren müssen (Abbildung 19.151). Das ist eine gute Idee, aber hilft nichts: Jetzt gibt es eine andere Fehlermeldung, nämlich die aus Abbildung 19.152. Sie weist darauf hin, dass der Remotedesktopgateway-Server nicht auf der Liste der vertrauenswürdigen Server steht.

Abbildung 19.150 Ein nicht-NAP-aktivierter Client kann nun nicht mehr zugreifen.

Abbildung 19.151 Erster Versuch: Sie aktivieren den TS-Gateway-Quarantäneerzwingungs-Client, …

Abbildung 19.152 … aber das genügt nicht.

Microsoft stellt im Download Center freundlicherweise eine kleine .cmd-Datei zur Verfügung, die den NAP-Client für den Zugriff auf ein NAP-geschütztes Remotedesktopgateway vorbereitet, inklusive des Eintrags der vertrauenswürdigen Gatewayserver. Abbildung 19.153 ist eine kleine Suchhilfe.

Abbildung 19.153 Im Download Center gibt es eine .cmd-Datei, die den NAP-Client vorbereitet – inklusive Eintrag der vertrauenswürdigen Gatewayserver.

Beim Download erhalten Sie zunächst eine Textdatei, die Sie in eine .cmd-Datei umbenennen und dann auf dem Client ausführen. Beim Aufruf geben Sie als Parameter den Namen des Remotedesktopgateways an, das sieht dann wie in Abbildung 19.154 aus.

Abbildung 19.154 So sieht es aus, wenn die .cmd-Datei gelaufen ist.

Wenn Sie nach dem Ausführen der .cmd-Datei nochmals den Verbindungsaufbau versuchen und der Client die »Gesundheitsanforderungen« erfüllt, wird die Verbindung aufgebaut. Abbildung 19.155 zeigt den Beweis.

Abbildung 19.155 Und jetzt funktioniert es! Hier ist der Beweis.

Nun wäre es einigermaßen lästig, wenn Sie auf jedem Client eine .cmd-Datei ausführen müssten. Die entscheidenden Zeilen der .cmd-Datei sind hier zu sehen:

echo Setting the list of trusted TS Gateway servers to %1 ...
reg add "HKLM\Software\Microsoft\Terminal Server Client\TrustedGateways"/v GatewayFQDN /t REG_MULTI_SZ /d %1 /f
echo Enabling the TS Gateway Quarantine Enforcement Client
reg add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services
\napagent\LocalConfig\Qecs\79621 /v Enabled /t REG_DWORD /d 1 /f
echo Setting the Network Access Protection service startup type to
Automatic...
sc config napagent start= auto
echo Starting the Network Access Protection service...
net start napagent

Es werden also Registry-Keys gesetzt, und ein Dienst wird konfiguriert und gestartet. Zumindest die Konfigurationsaspekte lassen sich über Gruppenrichtlinien erledigen.



Ihr Kommentar

Wie hat Ihnen das <openbook> gefallen? Wir freuen uns immer über Ihre freundlichen und kritischen Rückmeldungen.






<< zurück
  Zum Katalog
Zum Katalog: Windows Server 2008 R2

Windows Server 2008 R2
Jetzt bestellen


 Ihre Meinung?
Wie hat Ihnen das <openbook> gefallen?
Ihre Meinung

 Buchempfehlungen
Zum Katalog: Windows 7 für Administratoren






 Windows 7 für
 Administratoren


Zum Katalog: Konzepte und Lösungen für Microsoft-Netzwerke






 Konzepte und
 Lösungen für
 Microsoft-Netzwerke


Zum Katalog: Office SharePoint Server 2007 und Windows SharePoint Services 3.0






 Office SharePoint
 Server 2007 und
 Windows SharePoint
 Services 3.0


Zum Katalog: Exchange Server 2007 und Office Communications Server 2007






 Exchange Server 2007
 und Office
 Communications
 Server 2007


Zum Katalog: Citrix XenApp 5






 Citrix XenApp 5


Zum Katalog: PC-Netzwerke






 PC-Netzwerke


Zum Katalog: VMware vSphere 4






 VMware vSphere 4


Zum Katalog: VMware vSphere 4 - Videotraining






 VMware vSphere 4
 - Videotraining


Zum Katalog: VirtualBox






 VirtualBox


 Shopping
Versandkostenfrei bestellen in Deutschland und Österreich
InfoInfo




Copyright © Galileo Press 2010
Für Ihren privaten Gebrauch dürfen Sie die Online-Version natürlich ausdrucken. Ansonsten unterliegt das <openbook> denselben Bestimmungen, wie die gebundene Ausgabe: Das Werk einschließlich aller seiner Teile ist urheberrechtlich geschützt. Alle Rechte vorbehalten einschließlich der Vervielfältigung, Übersetzung, Mikroverfilmung sowie Einspeicherung und Verarbeitung in elektronischen Systemen.


[Galileo Computing]

Galileo Press, Rheinwerkallee 4, 53227 Bonn, Tel.: 0228.42150.0, Fax 0228.42150.77, info@galileo-press.de