FAQ: Citrix Secure Gateway/ NetScaler Gateway Secure Ticket Authority

Hinweis: Die gleichen Prinzipien und Konzepte gelten auch für NetScaler Gateway.

Dieser Artikel beantwortet einige häufig gestellte Fragen zur Citrix Secure Ticket Authority (STA). Die Fragen sind in folgende vier Kategorien unterteilt:

Übersicht

F: Was ist die Secure Ticket Authority?
F: Welche Citrix Produkte interagieren mit der STA?
Q: Warum ist die STA notwendig?
F: Wie wird der STA-Dienst implementiert?
Q: Gibt es eine Version der STA, für die IIS nicht erforderlich ist?
F: Wo befindet sich der STA-Server?
F: Was sind die Unterschiede zwischen den verschiedenen Versionen des STA?

Sicherheit

F: Wie wird das STA-Ticket generiert?
F: Was ist ein STA-Ticket?
F: Ist das Ticket gegen die Workstation validiert?
F: Wird das Ticket nach Gebrauch gelöscht?
F: Werden Tickets jemals in der STA auf die Festplatte geschrieben?
F: Ist es möglich, dass jemand ein Ticket entführt?
F: Wie schütze ich den STA-Verkehr mit SSL?
Q: Muss die STA immer mit einem vollqualifizierten Domainnamen angesprochen werden?
F: Wie ändere ich den STA-Port von 80 auf etwas anderes?
F: Kann ein Angreifer zufällige Tickets an das Gateway senden, um sich anzumelden?
F: Welche anderen Informationen als ein gültiges STA-Ticket sind für die Anmeldung erforderlich?
Q: Wie können wir die Lebenszeit von STA-Karte einstellen, nach der die Karte ungültig sein sollte?

Q: Wie viele STAs brauche ICH?
Q: Melden sich Benutzer morgens über das Gateway an und führen den ganzen Tag eine einzelne veröffentlichte Anwendung aus, oder starten sie den ganzen Tag über mehrere Anwendungen?
F: Wie kann ich die STA-Fehlertoleranz sicherstellen?
F: Wie kann ich mehrere STAs ausgleichen?
F: Kann ich mehrere STAs mit Microsoft Network Load Balancing verwenden?
F: Kann ich eine einzelne STA für mehrere Farmen, Gateways und Enumerationsserver freigeben?

Fehlerbehebung

F: Wie sollte IIS für das Hosten der STA konfiguriert werden?
F: Wie aktiviere ich die Protokollierung an der STA?
Q: Warum bricht das Microsoft IISLockDown-Tool die STA?
Q: Wie kann ICH test die STA zu werden sicher es ist richtig?
F: Wie interpretiere ich die STA-Protokolldateien?
F: Was sind einige der häufigsten Konfigurationsfehler, die vom technischen Support von Citrix angezeigt werden?

Übersicht

F: Was ist die Secure Ticket Authority?

A: Die Secure Ticket Authority (STA) ist ein XML-Webdienst, der XenApp Server-Informationen für zufällig generierte Tickets austauscht. Es wird verwendet, um den Zugriff für einen Citrix Secure Gateway-Server zu steuern.

F: Welche Citrix Produkte interagieren mit der STA?

A: XenMobile, Web Interface, StoreFront, XenApp Secure Access Manager, NetScaler Gateway und Citrix Secure Gateway interagieren mit STA. In diesem Artikel werden die folgenden Servertypen in einer einzigen Kategorie zusammengefasst, die als Anwendungsaufzählungsserver bezeichnet wird:

• Web Interface 2.0 oder höher
• Secure Access Manager 2.0 oder höher
• StoreFront
• Anwendungsaufzählungsserver sind für die Authentifizierung von Benutzern, die Aufzählung veröffentlichter Anwendungssymbole und die Erstellung einer ICA-Datei für einen Client verantwortlich, mit der sie über einen Secure Gateway-Server eine Verbindung zu einer veröffentlichten Anwendung herstellen können.

Q: Warum ist die STA notwendig?

A: In Citrix Secure Gateway-Bereitstellungen führt der Gatewayserver keine Authentifizierung eingehender Anforderungen durch. Stattdessen verschiebt der Gatewayserver die Authentifizierung auf einen Anwendungsaufzählungsserver und verwendet die STA, um sicherzustellen, dass jeder Benutzer authentifiziert ist. Anwendungsaufzählungsserver fordern Tickets nur für Benutzer an, die bereits beim Webserver authentifiziert sind. Wenn Benutzer über gültige STA-Tickets verfügen, geht das Gateway davon aus, dass sie die Authentifizierungsprüfungen am Webserver bestanden haben und Zugriff erhalten sollen.

Mit diesem Design kann der Citrix Secure Gateway-Server alle Authentifizierungsmethoden auf Ihrem Webserver erben. Wenn Ihr Webinterface-Server beispielsweise mit RSA SecurID geschützt ist, können standardmäßig nur Benutzer mit SecurID-Authentifizierung den Secure Gateway-Server durchlaufen.

F: Wie wird der STA-Dienst implementiert?

A: Die STA ist als ISAPI-Erweiterung für Microsoft Internet Information Services (IIS) geschrieben. Die Erweiterung heißt CtxSta.dll und wird standardmäßig im Ordner / Scripts gehostet. Andere Komponenten kommunizieren mit der STA über XML über HTTP.

Anwendungsaufzählungsserver fordern Tickets zum Zeitpunkt des Anwendungsstarts an, indem sie Daten als Teil einer Ticketanforderung an die STA senden. Die an die STA gesendeten Daten umfassen die Adresse des XenApp-Servers, mit dem sich der Benutzer verbinden wird, und im Fall von Web Interface 2.0 und Secure Access Manager 2.0 erweiterte Informationen über den Namen des aktuellen Benutzers und die veröffentlichte Anwendung, die der Benutzer ausführen möchte. Die STA antwortet, indem sie ein Ticket generiert und an den Anwendungsaufzählungsserver zurücksendet. Dieses Ticket und die entsprechenden Daten verbleiben für eine konfigurierbare Anzahl von Sekunden (standardmäßig 100) im Speicher der STA.
Der Anwendungsaufzählungsserver erstellt eine ICA-Datei für den Benutzer und fügt das STA-Ticket in das Adressfeld der ICA-Datei ein. Wenn der Client eine Verbindung zum sicheren Gateway herstellt, wird das Ticket angezeigt, und das Gateway sollte das Ticket validieren, bevor eine sichere Sitzung für den Client eingerichtet wird. Das Gateway führt eine Datenanforderung durch, indem es das Ticket an die STA zurücksendet und im Gegenzug nach den entsprechenden Daten fragt. Bei erfolgreicher Validierung leitet die STA die Originaldaten an das Gateway weiter, und das Gateway stellt ein Relay zwischen dem Endbenutzer und dem XenApp-Server her.

Sowohl Ticketanfragen als auch Datenanfragen werden als XML-Anfrage-/Antwortdokumente ausgeführt.

F: Gibt es eine Version der STA, für die IIS nicht erforderlich ist?

A: Nein, zu diesem Zeitpunkt ist IIS erforderlich, um die STA zu hosten. Denken Sie daran, dass die STA nicht einem nicht vertrauenswürdigen Netzwerk wie dem Internet ausgesetzt sein muss; die STA befindet sich in Ihrem vertrauenswürdigen Netzwerk und wird nur von den Gateway- und Anwendungsaufzählungsservern aufgerufen.

F: Wo befindet sich der STA-Server?

A: Der STA-Server kann überall platziert werden, solange die Secure Gateway- und Application Enumeration-Server ihn erreichen können. Citrix empfiehlt, die STA im vertrauenswürdigen Netzwerk oder in einem separaten Abschnitt Ihrer internen Firewall zu platzieren. Die STA muss keiner Domäne, XenApp Serverfarm, Secure Access Manager-Farm oder einem anderen internen Webserver angehören, aber die gemeinsame Nutzung der STA mit einer anderen Funktion ist gängige Praxis. Eine STA wird automatisch als Teil des Secure Access Manager 2.0-Setups bereitgestellt; Viele Administratoren finden es praktisch, die STA auf einem XenApp-Server zu finden.

Q: Was sind die unterschiede zwischen verschiedenen versionen der STA?

A: Es gibt keine wesentlichen funktionalen Unterschiede zwischen den Versionen 1.0 und 1.1, aber bei Verwendung der 2.0 STA mit Web Interface 2.0 oder Secure Access Manager 2.0 werden der Ticketanforderung erweiterte Informationen hinzugefügt: Der Name des Benutzers und die Anwendung, die der Benutzer ausführen möchte. Diese erweiterten Daten werden vom Gateway-Dienst verwendet, um Details zu jeder Gateway-Sitzung in der Secure Gateway 2.0-Verwaltungskonsole anzuzeigen.

Wenn Secure Gateway 2.0 für die Verwendung eines älteren STA ab Version 1.1 oder 1.0 konfiguriert ist, können Benutzer eine Verbindung zu Anwendungen herstellen, die Secure Gateway-Verwaltungskonsole zeigt jedoch „N / A“ für den Benutzernamen und den Anwendungsnamen an, die jeder ICA-Sitzung zugeordnet sind. Um die erweiterten Informationen im Secure Gateway zu sehen 2.Für die Verwaltungskonsole müssen Sie Version 2.0 oder höher der STA verwenden und Secure Access Manager 2.0 oder Web Interface 2.0 als Anwendungsaufzählungsserver verwenden.

Sicherheit

F: Wie wird das STA-Ticket generiert?

A: Die ISAPI-Erweiterung CtxSta.dll verwendet Pseudozufallszahlengenerierung, um eine 16-Byte-Hexadezimalzeichenfolge zu erzeugen. Aus Sicherheitsgründen gibt Citrix die genauen Schritte zur Erzeugung dieser zufälligen Zeichenfolge nicht bekannt.

F: Was ist ein STA-Ticket?

A: Das Codierungsformat ist eine Zeichenfolge der Form:

;STA_VERSION;STA_ID;TICKET

Wo:

• STA_VERSION ist ein numerisches Feld, das die Version der STA identifiziert. Derzeit sind die einzigen gültigen Werte für dieses Feld „10“ für STA-Versionen 1.0 und 1.1 und „20“ für STA-Version 2.0.
• STA_ID ist eine Folge von 0 – 16 Zeichen, die einen beliebigen Namen darstellt, der vom Administrator einer bestimmten STA zugewiesen wurde. In der Version 1.x, diese Zeichenfolge ist standardmäßig STA01, STA02 usw. Wenn die STA automatisch als Teil von Secure Access Manager 2.0 installiert wird, ist die STA-ID ein Hash des Servernamens. Wenn mehrere STAs von einem einzelnen Gateway-Server gemeinsam genutzt werden, muss jede STA-ID eindeutig sein. Auf diese Weise kann das Gateway die STA finden, die das Ticket erstellt hat, und zur Ticketvalidierung zu dieser STA zurückkehren. Ein auf STA01 erstelltes Ticket existiert auf STA02 nicht.
• TICKET ist eine zufällig generierte Folge von 32 alphabetischen oder numerischen Großbuchstaben.

  Zum Beispiel:
  ;10;STA01;FE0A7B2CE2E77DDC17C7FD3EE7959E79

F: Ist das Ticket gegen die Workstation validiert?

A: Nein, es gibt nichts, was ein Ticket an einen bestimmten Arbeitsplatz bindet. Es ist theoretisch möglich, dass ein Ticket von Workstation A angefordert und dann von Workstation B verwendet wird. Um dieses Risiko zu mindern:

• Verwenden Sie immer HTTPS zwischen dem Client und dem Anwendungsaufzählungsserver, um zu verhindern, dass ein Angreifer das Ticket auf dem Weg vom Server zum Client abfängt.
• Reduzieren Sie die Time-to-Live des Tickets so weit wie möglich, um die Zeit zu verkürzen, die ein Angreifer benötigt, um das Ticket von Maschine A auf Maschine B zu übertragen.

Denken Sie daran, dass ein von der STA ausgestelltes Ticket nur einmal verwendet werden kann. Wenn also der beabsichtigte Benutzer auf Maschine A erfolgreich eine Verbindung herstellt, ist das Ticket für alle zukünftigen Verbindungsversuche von Maschine A oder Maschine B ungültig.

F: Wird das Ticket nach der Verwendung gelöscht?

A: Ja, Tickets werden sofort nach einer erfolgreichen Datenanforderung gelöscht, sodass sie nur einmal verwendet werden können. Sie werden auch nach einem konfigurierbaren Timeout (Standard 100 Sekunden) gelöscht, wenn sie nicht verwendet werden.

F: Werden Tickets jemals in der STA auf die Festplatte geschrieben?

EIN: Nur wenn die ausführliche Protokollierung durch Setzen von LogLevel = 3 in CtxSta aktiviert ist.config. Andernfalls verwaltet die STA alle ausstehenden Tickets (Tickets, die von einem Anwendungsaufzählungsserver angefordert, aber noch nicht von einem sicheren Gateway validiert wurden) mithilfe einer speicherinternen Datenbank. XML-Daten werden immer mit dem Befehl HTTP POST an die STA gesendet, sodass niemals aussagekräftige Ticketdaten in die STA-Webserverprotokolle geschrieben werden.

F: Ist es möglich, dass jemand ein Ticket entführt?

A: Während des normalen Betriebs muss ein Ticket die folgenden vier Segmente des Netzwerks befahren:

• Von der STA zum Application Enumeration Server
• Vom application Enumeration Server zum Client
• Vom Client zum Secure Gateway Server
• Vom Gateway zur STA

Das erste und das letzte Segment existieren nur zwischen Servern in Ihrer DMZ und der STA auf ihr vertrauenswürdiges Netzwerk, was bedeutet, dass ein Eindringling Zugang zu Ihrem Netzwerk haben müsste, um das Ticket entlang dieser Linien abzufangen. Dennoch können diese Pfade mit SSL verschlüsselt werden, wenn Sie Secure Gateway Version 2.0 verwenden. Im Citrix Secure Gateway 1.1 und früher kann der Datenverkehr zur STA nicht mit SSL verschlüsselt werden.

Um das zweite Segment zu sichern, legen Sie ein Zertifikat auf Ihrem Anwendungsaufzählungs-Webserver an und erlauben Sie Clients, nur dann eine Verbindung herzustellen, wenn sie HTTPS verwenden. Das dritte Segment ist immer mit SSL gesichert.

Selbst wenn alle vorhergehenden Links mit SSL gesichert sind, sind Clients immer noch anfällig für Angriffe durch Trojaner-Programme, die Client-Aktivitäten überwachen. Um dieses Risiko zu verringern, empfehlen Sie Ihren Benutzern, sich von Computern aus zu verbinden, auf denen Antiviren- und Trojaner-Erkennungssoftware installiert ist.

F: Wie schütze ich den STA-Verkehr mit SSL?

A: Installieren Sie zunächst ein Webserverzertifikat auf der Kopie von IIS, die die STA hostet. Weitere Informationen finden Sie in der IIS-Dokumentation.

Konfigurieren Sie Ihren Application Enumeration Server und Secure Gateway Server für die Verwendung von HTTPS bei der Kommunikation mit dem Gateway. Bei der Verbindung über HTTPS müssen immer die folgenden Regeln erfüllt sein:

• Sie müssen die STA mit einem vollqualifizierten Domänennamen adressieren, der dem Betreff des STA-Serverzertifikats entspricht.
• Die Maschine, die mit der STA kommuniziert, muss in der Lage sein, den vollqualifizierten STA-Domänennamen in eine geeignete IP-Adresse aufzulösen.
• Der Computer, der mit der STA kommuniziert, muss der Zertifizierungsstelle (CA) vertrauen, die das STA-Serverzertifikat ausgestellt hat.
• Um die Anforderungen des dritten Aufzählungselements zu erfüllen, muss das Stammzertifikat der Zertifizierungsstelle auf dem Secure Gateway-Server und auf dem Anwendungsaufzählungsserver installiert werden. Seien Sie bei der Installation des Stammzertifikats vorsichtig: Sie können nicht einfach auf eine Stammzertifikatdatei doppelklicken und den Zertifikatimport-Assistenten ausführen.

( Dies zeigt an, dass Ihr Benutzerkonto und nicht der Server oder Systemdienste der Zertifizierungsstelle vertraut. Führen Sie die folgenden Schritte aus, um ein Stammzertifikat für die Verwendung mit Citrix Secure Gateway oder Web Interface zu installieren:

1. Führen Sie Mmc aus.exe und fügen Sie das Zertifikate-Snap-In hinzu.
2. Wenn Sie gefragt werden, welche Zertifikate verwaltet werden sollen, wählen Sie Computerkonto und dann Lokaler Computer.
3. Erweitern Sie den Knoten Zertifikate (lokaler Computer) > Vertrauenswürdige Stammzertifizierungsstellen. Klicken Sie mit der rechten Maustaste auf Zertifikate, und wählen Sie dann Alle Aufgaben > Importieren aus.
4. Navigieren Sie zu Ihrem CA-Stammzertifikat und schließen Sie den Import-Assistenten ab.

F: Muss die STA immer mit einem vollqualifizierten Domainnamen angesprochen werden?

A: Wenn Sie beabsichtigen, den Datenverkehr zur STA mithilfe von SSL zu sichern, muss jede Komponente, die auf die STA zugreift, einschließlich Ihres Gatewayservers und Anwendungsaufzählungsservers, die STA mit dem vollqualifizierten Domänennamen (FQDN) adressieren, der dem Betreff des Serverzertifikats entspricht, das von IIS auf der STA verwendet wird. In Web Interface 2.0 würde die STA-Adresse beispielsweise wie folgt eingegeben:https://sta-server.company.com/Scripts/CtxSta.dll

Wenn Sie den Datenverkehr zur STA nicht sichern möchten, können Sie die STA mit einer IP-Adresse, einem Hostnamen oder einem FQDN adressieren.

F: Wie ändere ich den STA-Port von 80 auf etwas anderes?

A: Da die STA von IIS bedient wird, ändern Sie den STA-Port, wenn Sie den IIS-Port ändern. Das folgende Beispiel zeigt, wie Sie den IIS-Port von 80 auf 81 ändern.

1. Öffnen Sie den Internetdienste-Manager.
2. Klicken Sie mit der rechten Maustaste auf Standardwebsite, und zeigen Sie die Eigenschaften an.
3. Ändern Sie auf der Registerkarte Website die TCP-Portnummer von 80 in 81.
4. Klicken Sie auf OK.
   Die vorherige Änderung betrifft auch alle anderen Ressourcen, die Sie vom STA-Webserver veröffentlicht haben. Wenn Sie den STA-Kommunikationsport ändern möchten, ohne andere vom selben Webserver gehostete Webseiten zu beeinträchtigen, können Sie eine neue Website in IIS erstellen, die ausschließlich zum Hosten der STA dient. Das folgende Beispiel zeigt, wie Sie eine neue Website auf Port 81 für die STA erstellen.
5. Erstellen Sie einen neuen physischen Ordner wie C:\STA auf der Festplatte Ihres Webservers, um als Dokumentstammverzeichnis für die STA-Site zu dienen.
6. Erstellen Sie unterhalb von MYSTA ein Unterverzeichnis namens Scripts. Verschieben Sie die folgenden Dateien aus Ihrem vorhandenen STA in den neuen Skriptordner:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. Öffnen Sie den Internetdienste-Manager.
8. Klicken Sie mit der rechten Maustaste auf den Servernamen und wählen Sie New > Web site.
9. Erstellen Sie eine neue Website mit dem Namen „My STA site“ und C:\MYSTA als Stammverzeichnis des Dokuments.
10. Zeigen Sie die Eigenschaften Ihrer neuen Website an und ändern Sie den TCP-Port in 81.
11. Klicken Sie unter Meine STA-Site im Internet Services Manager mit der rechten Maustaste auf den Ordner Scripts, und zeigen Sie die Eigenschaften an. Ändern Sie im Abschnitt Anwendungseinstellungen die Ausführungsberechtigungen in „Skripte und ausführbare Dateien.“

Hinweis: Sie können einen anderen Ordnernamen als „Scripts“ wählen, beachten Sie jedoch, dass Secure Gateway und alle Anwendungsaufzählungsserver wie Web Interface davon ausgehen, dass die STA als /Scripts/CtxSta veröffentlicht wird.daher müssen Sie auch die STA-URL in den Einstellungen auf diesen Servern aktualisieren.

F: Kann ein Angreifer zufällige Tickets an das Gateway senden, um sich anzumelden?

A: Ein Angreifer müsste ein gültiges Ticket erraten und es auch innerhalb weniger Millisekunden einlösen, nachdem der Client es angefordert hat, aber bevor das Gateway es beansprucht.

F: Welche anderen Informationen als ein gültiges STA-Ticket sind für die Anmeldung erforderlich?

A: Benutzer benötigen außerdem Domänenanmeldeinformationen oder ein XenApp Server-Ticket, das vom Anwendungsaufzählungsserver angefordert wird. (Ein XenApp Server-Ticket ist nicht dasselbe wie ein STA-Ticket.). Die STA öffnet für einen bestimmten Server nur einen Pfad zum vertrauenswürdigen Netzwerk. Dort muss sich der Benutzer weiterhin mit gültigen Domänenanmeldeinformationen authentifizieren.
Q: Wie können wir die Lebenszeit von STA-Karte einstellen, nach der die Karte ungültig sein sollte?
A: Wir können die Lebensdauer des STA-Tickets festlegen, indem wir einen folgenden Registrierungsschlüssel auf dem Delivery Controller erstellen:
Speicherort: HKLM \ Software \Citrix \DesktopServer
Name: XmlStaTicketLifetimeInSeconds
Typ: Dword-Wert: Geben Sie Wert in Sekunden (Dezimal)
Bitte nehmen Sie eine Registry-Backup vor der Bearbeitung Registry-Werte, beachten Sie auch, dass eine Registry-Änderung würde einen Neustart auf der Controller-Seite erfordern.

Q: Wie viele STAs brauche ICH?

A: Auf die STA wird nur zugegriffen, wenn ein Benutzer eine Anwendung startet.

F: Melden sich Benutzer morgens über das Gateway an und führen den ganzen Tag eine einzelne veröffentlichte Anwendung aus, oder starten sie den ganzen Tag über mehrere Anwendungen?

EIN: Die von der STA ausgeführten Aufgaben sind in CPU-Hinsicht nicht teuer. Es ist ein leichter XML-Dienst, der nur durch die Leistung von IIS begrenzt ist. In einem Test unterstützte ein Low-Range-Server mit einem 1-GHz-Prozessor und 256 MB RAM über 250 Ticketanfragen pro Sekunde, während die CPU-Auslastung unter 60% blieb.

F: Wie kann ich die STA-Fehlertoleranz sicherstellen?

A: Mit den folgenden Anwendungsaufzählungsservern können Sie beim Konfigurieren der Parameter für Secure Gateway mehrere STA-URLs eingeben:

• Webschnittstelle 2.0
• Sicherer Zugriffsmanager 2.0
• StoreFront

Wenn eine STA nicht antwortet, versucht der Anwendungsaufzählungsserver in allen Fällen eine andere STA in der Liste. Jeder Gateway-Server muss wiederum mit der STA-URL und der eindeutigen STA-ID für jede Ticketstelle konfiguriert werden.

F: Wie kann ich mehrere STAs ausgleichen?

A: Beim Load Balancing von sicheren Ticketstellen ist besondere Vorsicht geboten. Eine Vielzahl von Methoden kann zum Lastausgleich der Verbindung zwischen einem Anwendungsaufzählungsserver und dem STAs verwendet werden, aber ein Secure Gateway-Server muss immer jeden STA einzeln basierend auf seiner STA-ID kontaktieren. Wenn Sie die Adresse jedes STA im Gateway Service Configuration Tool konfigurieren, muss jede STA—Adresse die wahre Adresse des STA-Servers sein – geben Sie hier nicht die Adresse eines Hardware-Load Balancers, Clusternamens oder Round-Robin-DNS-Namens ein.

StoreFront, Web Interface 2.0 und Secure Access Manager 2.0 alle unterstützen den Round-Robin-Lastenausgleich der STAs, wenn mehrere STAs aufgelistet sind. Wenn diese Option aktiviert ist, ist keine zusätzliche Lastausgleichssoftware oder -hardware erforderlich.

Anwendungsaufzählungsserver können jede Form des Lastenausgleichs zum Ausgeben einer Ticketanforderung verwenden, da jedes empfangene Ticket ein Feld enthält, das die eindeutige ID der STA angibt, die es generiert hat. Solange jede STA-ID eindeutig ist und alle Gateway-Server die STA-ID in eine bestimmte (nicht lastausgeglichene) Serveradresse auflösen können, ist der Vorgang erfolgreich und der STA-Datenverkehr ist lastausgeglichen.

Q: Kann ich mehrere STAs mit Microsoft Network Load Balancing verwenden?

A: Der Netzwerklastausgleich zwischen dem Secure Gateway-Server und mehreren STAs kann nicht verwendet werden. Bei dieser Konfiguration erhalten Benutzer zeitweise Ablehnungen, da das Gateway während des Ticketvalidierungsprozesses möglicherweise an eine Behörde ausgelastet ist, die das Ticket des Benutzers ursprünglich nicht generiert hat.

F: Kann ich eine einzelne STA für mehrere Farmen, Gateways und Enumerationsserver freigeben?

EIN: Ja, eine einzelne STA kann von einer beliebigen Anzahl von Secure Gateway-Servern und Anwendungsaufzählungsservern gemeinsam genutzt werden. Die STA ist nicht auf bestimmte Domänen-, Farm- oder Anwendungsaufzählungsserver beschränkt. Es ist ein anonymer XML-Dienst.

Fehlerbehebung

F: Wie sollte IIS für das Hosten der STA konfiguriert werden?

Die STA-URL /Scripts/CtxSta.dll muss mit aktiviertem anonymen Zugriff bereitgestellt werden. Wenn Sie einen Webbrowser auf die STA-URL verweisen, werden Sie nicht zur Eingabe eines Kennworts aufgefordert.

• Sie müssen die Berechtigung Ressourcenskripts und ausführbare Dateien in der IIS-Metabasis erteilen. Diese Berechtigung wird nicht für den gesamten Ordner /Scripts benötigt, kann aber für den CtxSta festgelegt werden.dll-Datei einzeln.
• Aktivieren Sie für Secure Gateway Version 1.1 und früher nicht die Optionen Require SSL und Require 128-bit SSL.
• Standardmäßig sind die folgenden Kontoberechtigungen erforderlich:

Auf Windows 2000-Servern

• benötigt das Konto IUSR_MachineName Lesezugriff auf CtxSta.dll.
• Das IWAM_MachineName-Konto benötigt Zugriff auf das Protokolldateiverzeichnis, das standardmäßig \Inetpub\Scripts ist.

Auf Windows 2003-Servern

• Das Konto IUSR_MachineName benötigt Lesezugriff auf CtxSta.dll.
• Das integrierte Netzwerkdienstkonto benötigt Zugriff auf das Protokolldateiverzeichnis, das standardmäßig \Inetpub\Scripts ist.

F: Wie aktiviere ich die Protokollierung an der STA?

A: Bearbeiten Sie mit dem Editor die Datei \Inetpub\Scripts\CtxSta.config auf dem STA-Server und suchen Sie die Zeile mit der Aufschrift LogLevel =0. Ändern Sie dies für maximale Protokollierung in LogLevel=3. Sie müssen den World Wide Web Publishing Service neu starten, damit die Änderungen wirksam werden.
Hinweis: Nachdem Sie die Protokollierung aktiviert haben, muss das Benutzerkonto, unter dessen Berechtigung die STA ausgeführt wird (standardmäßig IUSR_MachineName unter Windows 2000 oder Network Service unter Windows 2003), Schreibzugriff auf das Protokolldateiverzeichnis haben, das standardmäßig \Inetpub\Scripts ist. Sie können auch das Protokolldateiverzeichnis ändern, wenn Sie CtxSta bearbeiten.config.

F: Warum bricht das Microsoft IISLockDown-Tool die STA?

EIN: Wenn Sie alle Standardeinstellungen für das IISLockDown-Tool akzeptieren, ist der Ordner /Scripts deaktiviert. Die STA wird als ISAPI-Filter implementiert, der als /Scripts/CtxSta veröffentlicht wird.dll; Durch Deaktivieren des Verzeichnisses / Scripts verweigern Sie den Zugriff auf die STA. Aktivieren Sie den Ordner /Scripts und erlauben Sie Skripten und ausführbaren Dateien den Zugriff, damit die STA funktioniert.

Q: Wie kann ICH test die STA zu werden sicher es ist richtig?

A: Wenn Sie einen Webbrowser auf die STA-URL verweisen, wird entweder eine leere weiße Seite oder die Meldung „405 Resource Not Allowed.“ Jedes dieser Ergebnisse weist auf eine funktionierende STA hin. Sie können die STA auf diese Weise über die Konsole Ihres Secure Gateway-Servers und über jeden Anwendungsaufzählungsserver kontaktieren, der für die Verwendung des Gateways konfiguriert ist. Wenn Sie ein Authentifizierungsdialogfeld erhalten, in dem Sie zur Eingabe eines Kennworts aufgefordert werden, wird die STA nicht anonym veröffentlicht, und die Authentifizierungsanforderungen müssen entfernt werden.

Um zu überprüfen, ob der Anwendungsaufzählungsserver erfolgreich STA-Tickets anfordert, sehen Sie sich die generierten ICA-Dateien an. In Web Interface 2.0 können Sie beispielsweise mit der rechten Maustaste auf ein veröffentlichtes Anwendungssymbol klicken und das Ergebnis als Start speichern.ica. Öffnen Sie launch.ica im Editor und zeigen Sie die Adresse = Zeile. Für den normalen Secure Gateway-Betrieb enthält der Parameter Address ein Ticket anstelle einer tatsächlichen XenApp-Serveradresse.

F: Wie interpretiere ich die STA-Protokolldateien?

A: Wenn Sie die Protokollierung aktivieren, indem Sie LogLevel=3 in CtxSta setzen.hier sehen Sie Details zu jedem Ticket und jeder Datenanforderung, die von der STA empfangen wurden. Denken Sie daran, dass eine Ticketanforderung von einem Anwendungsaufzählungsserver wie Web Interface generiert wird und eine Datenanforderung vom Secure Gateway-Dienst ausgeführt wird. Wenn in der Protokolldatei mehrere Ticketanforderungen, aber keine Datenanforderungen angezeigt werden, bedeutet dies, dass der Anwendungsaufzählungsserver die STA erreichen kann, der Secure Gateway-Server jedoch nicht. Es kann auch bedeuten, dass Benutzer den Gateway-Server nicht erreichen können.

Während des normalen Betriebs kann die Sitzungsfreigabefunktion des ICA-Clients dazu führen, dass Tickets von der STA angefordert, aber nie vom Gateway beansprucht werden. Betrachten Sie das folgende Szenario:

• Ein Benutzer meldet sich bei der Weboberfläche an und klickt auf das Outlook-Symbol. Das Webinterface fordert ein Ticket von der STA an und sendet es in einer ICA-Datei an den Benutzer.
• Der Benutzer stellt über ein sicheres Gateway eine Verbindung her und legt das Ticket für den Eintritt vor. Das Gateway validiert das Ticket und ermöglicht dem Benutzer die Verbindung zu einem XenApp-Server, auf dem Outlook gehostet wird.
• Nach einigen Minuten Arbeit kehrt der Benutzer zur Anwendungsliste auf der Seite Weboberfläche zurück und klickt auf das Excel-Symbol. Das Webinterface fordert ein zweites Ticket von der STA an und sendet es in einer ICA-Datei an den Benutzer.
• Vor dem Herstellen einer Verbindung zu einem neuen Server für Excel prüft der ICA-Client zunächst, ob auf vorhandenen Servern, mit denen der Client bereits verbunden ist, die veröffentlichte Excel-Anwendung verfügbar ist.
• Auf dem Server, auf dem der Client bereits Outlook ausführt, ist auch Excel installiert, sodass der ICA-Client die ICA-Datei verwirft und Excel innerhalb der vorhandenen ICA-Sitzung startet.
• Das zweite vom Webinterface angeforderte Ticket wird nie verwendet, da keine zweite ICA-Sitzung erforderlich war. Standardmäßig läuft das Ticket nach 100 Sekunden ab.

Dieses Szenario würde zu einer Reihe von STA-Protokolldateieinträgen führen, die den folgenden ähneln:

CSG1305 Request Ticket - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1304 Request Data - Successful 8DE802AE5A2F561233450B6CFD553035 ...CSG1305 Request Ticket - Successful 63EF3EAB182D846958143D19C1FDAEBA ...CSG1303 Ticket Timed Out 63EF3EAB182D846958143D19C1FDAEBA

Verdächtigere Aktivitäten könnten ungefähr so aussehen:

CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB804 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB805 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB806 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB807 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB808 CSG1203 Request Data - Ticket NOT found7DC6409CE228ECFCB5EE50A94D6AB809

Hier sehen wir, was ein Angreifer zu sein scheint, der nacheinander verschiedene Tickets ausprobiert und die Ticket-ID bei jedem Versuch erhöht. In jedem Fall wurde die Verbindung abgelehnt und die STA protokollierte einen Eintrag, der angibt, dass der Client ein Ticket vorgelegt hat, das nicht als gültig erkannt wurde. Um die IP-Adresse des Angreifers zu identifizieren, suchen Sie in der Ereignisanzeige auf dem Secure Gateway-Server nach der folgenden Meldung:

CSG3207 Service received error from STA or Authentication Service , Client IP connection dropped.

Interpretieren Sie einige „Ticket NICHT gefunden“ -Nachrichten nicht als Angriff. Der Win32-ICA-Client versucht möglicherweise, die Verbindung zu einer getrennten Sitzung wiederherzustellen, wenn die Netzwerkverbindung des Benutzers vorübergehend unterbrochen wird. Die automatische Clientwiederverbindungsfunktion funktioniert nicht für Citrix Secure Gateway-Benutzer, da der Client bei jedem erneuten Verbindungsversuch das verwendete STA-Ticket erneut sendet, mit dem er ursprünglich eine Verbindung hergestellt hat. Der Client versucht normalerweise, die Verbindung drei- oder mehrmals wiederherzustellen, bevor er aufgibt, sodass für jedes Auftreten dieses Problems drei oder mehr „Ticket NICHT gefunden“ -Meldungen angezeigt werden, die auf dasselbe Ticket im STA-Protokoll verweisen. Client-Wiederverbindungsversuche sind durch die versuchte Wiederverwendung eines zuvor erfolgreichen Tickets gekennzeichnet:

CSG1305 Request Ticket - Successful 766D558270CE32695903698AFA0F67A6 …CSG1304 Request Data - Successful 766D558270CE32695903698AFA0F67A6 …CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6 CSG1203 Request Data - Ticket NOT found766D558270CE32695903698AFA0F67A6

Trennen Sie die automatische Client-Wiederverbindung für Secure Gateway-Benutzer, indem Sie TransportReconnectEnabled=Off zum Abschnitt der ICA-Datei hinzufügen. Wenn Sie Secure Gateway verwenden, können Sie die Verbindung zu einer getrennten Sitzung wiederherstellen, indem Sie zum Anwendungsaufzählungsserver zurückkehren und erneut auf das Anwendungssymbol klicken.

F: Was sind einige der häufigsten Konfigurationsfehler, die vom technischen Support von Citrix angezeigt werden?

• Der Ordner /Scripts oder die gesamte Standardwebsite ist aufgrund der Ausführung von IISLockDown oder der Einhaltung der Unternehmensrichtlinie zum Schutz von Webservern deaktiviert.
• Die Protokollierung ist in CtxSta aktiviert.config, aber das Benutzerkonto, unter dessen Berechtigung die STA ausgeführt wird (standardmäßig IUSR_MachineName), hat keinen Schreibzugriff auf das Protokolldateiverzeichnis.
• IIS auf dem STA-Server ist so konfiguriert, dass SSL erforderlich ist, aber Secure Gateway ist so konfiguriert, dass es über normales HTTP auf die STA zugreift.
• Wenn der App-Start fehlschlägt, muss zunächst überprüft werden, ob die STAs auf StoreFront / Webinterface und NetScaler genau gleich angegeben sind oder nicht, dh wenn die STAs als IP-Adresse auf SF / WI angegeben werden, sollte sie mit IP-Adresse auf NS und ähnlich im Falle von FQDN angegeben werden.