Citrix Secure Gateway

Citrix Secure Gateway und WebInterface auf einem Server

Wichtig Dieser Artikel enthält Informationen zum Bearbeiten der Registrierung. Bevor Sie die Registrierung bearbeiten, vergewissern Sie sich bitte, dass Sie die Registrierung wiederherstellen können, falls ein Problem auftritt. Weitere Informationen zum Erstellen einer Sicherungskopie, zum Wiederherstellen und Bearbeiten der Registrierung finden Sie in folgendem Artikel der Microsoft Knowledge Base:

Externer Verweis außerhalb dieser Website!

256986 Beschreibung der Microsoft Windows-Registrierung

Update Für Informationen zur Konfiguration vom Citrix Secure Gaetway 3.0 in Verbindung mit Citrix Presentation Server 4.5 und WebInterface 4.5 sehen Sie sich bitte folgendes Dokument an:

Konfiguration Citrix Secure Gateway 3.0

Citrix bietet mit dem Produkt Secure Gateway (CSG) eine komfortable Möglichkeit den gesamten ICA Traffic durch Firewalls hindurch über HTTP oder SSL zu tunneln. Dadurch ist es möglich durch nahezu jede Firwall hindurch (sowohl beim Kunden als auch beim Anbieter) Applikationen ohne spezielle Zugangssoftware wie VPN-Clients zur Verfügung zu stellen.

Voraussetzungen

Wie bisher benötigt man dazu einen Citrix WebInterface for MetaFrame XP (WebInterface auf IIS, ehemals NFuse) und einen MetaFrame XP Server. Hierzu kommt dann noch die eigentliche Secure Gateway (CSG) Komponente, die das Tunneln des ICA Traffic vornimmt. Dabei kommuniziert das CSG mit einer Secure Ticket Authority (STA), die für die Authentifizierung zuständig ist und beispielsweise auch RSATokens unterstützt. Die Verschlüsselung des ICA Traffics geschieht regulär mit X.509-Zertifikaten über HTTP/SSL. Normalerweise empfiehlt Citrix, CSG und das WebInterface auf getrennten Servern zu installieren. Es gibt aber auch eine nicht unterstützte Möglichkeit mit 2 IP Adressen auf einem Server beide Komponenten laufen zu lassen.

Bild: Topologie des Netzwerks
Bild anzeigen

Das in diesem Bild dargestellte Netzwerk besteht aus einem Server (mycert.d-fens.net), auf dem das CSG und das WebInterface laufen. Ein Client verbindet sich durch die eigene Firewall und die Firewall vor dem CSG mit dem Server mycert.d-fens.net, um Applikationen auf dem MetaFrame Server nutzen zu können. Für eine Authentifizierung steht die STA (mysta.d-fens.net) zur Verfügung, die intern vom CSG angesprochen wird. Die gesamte Kommunikation beschränkt sich auf die Ports 80 (http) und 443 (https).

Das Problem

Bei der von Citrix vorgeschlagenen Lösung mit 2 IP Adressen, ergeben sich aber folgende Nachteile:

Es werden 2 X.509 Zertifikate benötigt, da jeder IP-Adresse ein vollständig qualifizierter Domänenname (FQDN) zugeordnet werden muß.
Sollen auf dem Server auch noch unverschlüsselte Webseiten laufen (beispielsweise die Startseite), so muß der Benutzer jeweils den passenden FQDN des Servers (CSG oder WebInterface) angeben, da das CSG nur HTTP/SSL entgegennimmt.

Bild: CSG, Kommunikation
Bild anzeigen

Möchte man aber den Traffic zum WebInterface ebenfalls verschlüsseln, so ergibt sich dabei eine Schwierigkeit: X.509 Zertifikate haben ein "subject", das mit dem vollständigen qualifizierten Domänennamen (FQDN) übereinstimmen muß, da sonst nicht die Identität des Servers garantiert werden kann. Wenn jetzt aber zwei IP-Adressen auf einem Server für 2 Dienste (CSG und WebInterface) vorhanden sind, müssen diese Adressen über DNS auch differenziert angesprochen werden können. Das heißt, es müßte 2 Zertifikate geben. Da es aber für den Benutzer nicht zu unterscheiden ist, wann er auf welchen Dienst zugreift (CSG oder WebInterface), ist diese Variante in der Praxis auf einem Server nicht zu empfehlen. Daher implementiert Citrx das CSG als transparent proxy, der alle Anfragen selber vom WebInterface abfragt und diese dann an den Client zurückgibt.

Bild: IIS, SSL Einstellungen
Bild anzeigen

Will man aber verhindern, daß die Webseiten des WebInterface unverschlüsselt zum Browser übertragen werden, so muß der IIS so eingerichtet werden, daß er ausschließlich SSL unterstützt, wie im Bild zu sehen ist (optional auch mit 128Bit-Verschlüsselung).

Bild: IIS, Konfiguration Website
Bild anzeigen

Da in dieser Konfiguration aber beide Dienste standardmäßig auf Port 443 (HTTP/SSL) laufen, kann sich der als zuletzt gestartete Dienst nicht auf den Socket (IP address/port pair) binden. Da dies normalerweise das WebInterface ist, gibt es de facto keine Möglichkeit, verschlüsselte Seiten vom WebInterface abzurufen. Das CSG beatwortet diese Anfragen mit HTTP Error 404 ("Seite konnte nicht gefunden werden"). Daher muß das WebInterface auf einem anderen Port als 443 gestartet werden.

Die Lösung

Um das WebInterface und das CSG auf einem Server mit einer IP Adresse mit nur einem Zertifikat laufen lassen zu können, müssen folgende Einstellungen konfiguriert werden:

Es muß ein SSL Zertifikat geben, daß einen gültigen FQDN besitzt, über den der Server angesprochen werden kann.
Das CSG muß über Port 443 (standard HTTP/SSL) erreichbar sein.
Im CSG muß das X.509-Zerifikat mit dem passenden FQDN ausgewählt sein.
Das WebInterface muß für SSL auf einen anderen (high) Port konfiguriert sein, der sonst nicht in Verwendung ist.
Im IIS muß das X.509-Zerifikat mit dem passenden FQDN ausgewählt sein.
Wenn unverschlüsselte Kommunikation gewünscht ist, muß der unverschlüsselte Port des IIS auf 80 konfiguriert sein.
Für alle zu verschlüsselnde Verzeichnisse auf dem IIS muß "Require secure channel (SSL)" gewählt sein.
Im CSG muß als WebInterface die Option "Installed on different computer" mit dem FQDN des lokalen Rechners eingetragen werden. Dabei ist der im IIS verwendete SSL Port einzutragen. Außerdem muß die Option "Secured with HTTPS" gewählt sein.
Im WebInterface muß in der Konfiguration für das CSG als FQDN der Name des lokalen Rechners mit dem Standard SSL Port 443 eingetragen werden.

Die Konfigurationsschritte im einzelnen

Bild: CSG, Auswahl der Zertifikate
Bild anzeigen

Das X.509 Zertifikat ist im Server importiert worden und wird aus der Konfiguration des CSG heraus ausgewählt.

Bild: CSG, Verwendetes WebInterface
Bild anzeigen

Als WebInterface wird der FQDN des lokalen Servers (deckungsgleich mit dem X.509 subject angegeben). Dabei ist auch der spezielle Port und die Option HTTPS zu wählen.

Bild: IIS, Konfiguration Website
Bild anzeigen

Der IIS ist für HTTPS mit einem anderen Port zu belegen, da es sonst zu einem Socket Error kommt. Die unverschlüsselte Kommunikation kann weiter über Port 80 erfolgen.

Bild: WebInterface, Auswahl des CSG
Bild anzeigen

Im WebInterface wird das CSG ausgewählt. Hierbei ist wieder der FQDN des lokalen Servers wichtig. Der HTTPS Port ist 443 (Standard).

Weitere Informationen

IIS Socket Pooling

Standardmäßig bindet sich der IIS auf alle verfügbaren IP Adressen, auch wenn in der Konfiguration nur eine einzelne Adresse angegeben wird. Dieses Verhalten kann aber geändert werden. Dazu gibt es ein Script AdsUtil.vbs, mit der Änderungen an der MetaBase des IIS vorgenommen werden können. Das Script liegt im Verzeichnis AdminScripts unterhalb des InetPub:

CD \Inetpub\AdminScripts
CScript adsutil.vbs set w3svc/disablesocketpooling true

Die Information ist aus diesen Microsoft Knowledge Base Artikeln:

Prozeßkommunikation zwischen CSG und IIS/WebInterface

Bild: Prozeßkommunikation 1
Bild anzeigen

In diesem Bild kann man sehen, daß das CSG sich auf Port 443 bindet (CtxSecGwy.exe) und der IIS auf Port 80 und 4443 (inetinfo.exe). Der Browser hat hierbei gerade 2 unverschlüsselte Sessions zum IIS aufgebaut (IExplore.exe).

Bild: Prozeßkommunikation 2
Bild anzeigen

In diesem Bild sieht man, daß der Browser (IExplore.exe) 2 Sitzungen per HTTPS zum CSG aufgebaut hat (Mitte, grün). Das CSG wiederum läuft als transparenter Proxy und verbindet sich zum IIS mit 2 wiederum verschlüsselten Sessions (unten gelb und grün).

Kontrollieren der Start-Reihenfolge von CSG und IIS

Im Normalfall ist es wünschenswert, daß das CSG vor dem IIS startet, beziehungsweise der IIS bei einem Neustart des CSG mit gestartet wird. Dies kann durch Setzen dieses Eintrags realisiert werden.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\IISADMIN
DependOnService	REG_MULTI_SZ	"RPCSS
				Protected Storage
				CtxSecGwy"

Um die Änderungen (Abhängigkeiten) wirksam zu machen, muß allerdings der Server neu gestartet werden.

Misc

Bild: CSG, Citrix MetaFrame products to secure
Bild anzeigen

Bild: CSG, Configuration level
Bild anzeigen

Bild: CSG, Zu bindende IP Adresse(n) und Ports
Bild anzeigen

Bild: CSG, ACLs
Bild anzeigen

Bild: CSG, Auswahl der Secure Ticket Authority
Bild anzeigen

Bild: CSG, Auswahl des Logging Level
Bild anzeigen

Bild: CSG, Abschluß der Konfiguration
Bild anzeigen