FAQ: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

Poznámka: stejné zásady a koncepty platí i pro NetScaler Gateway.

tento článek odpovídá na některé Často kladené otázky týkající se Citrix Secure Ticket Authority (STA). Otázky jsou rozděleny do následujících čtyř kategorií:

přehled

otázka: Jaký je Bezpečný Úřad pro lístky?
otázka: jaké produkty Citrix interagují se STA?
otázka: proč je Sta nutná?
otázka: jak je služba STA implementována?
Q: Existuje verze STA, která nevyžaduje službu IIS?
otázka: kde se nachází server STA?
otázka: Jaké jsou rozdíly mezi různými verzemi STA?

zabezpečení

otázka: jak se generuje vstupenka STA?
otázka: co představuje vstupenku STA?
otázka: je jízdenka ověřena proti pracovní stanici?
otázka: je lístek po použití smazán?
otázka: jsou vstupenky někdy zapsány na Disk na STA?
otázka: je možné, aby někdo unesl lístek?
otázka: Jak mohu chránit provoz STA pomocí SSL?
Q: Musí být STA vždy řešena pomocí plně kvalifikovaného názvu domény?
otázka: Jak mohu změnit port STA z 80 na něco jiného?
otázka: může útočník poslat náhodné vstupenky do brány, aby se přihlásil?
otázka: Jaké další informace jsou vyžadovány pro přihlášení kromě platné vstupenky STA?
otázka: jak můžeme nastavit životnost jízdenky STA, po které by měla být jízdenka neplatná?

škálovatelnost

otázka: kolik STAs potřebuji?
Q: Přihlašují se uživatelé přes bránu ráno a celý den spouštějí jednu publikovanou aplikaci nebo spouštějí několik aplikací po celý den?
otázka: Jak mohu zajistit odolnost proti chybám STA?
otázka: Jak načíst vyvážení více STAs?
Otázka: Mohu použít několik STAs s vyrovnáváním zatížení sítě Microsoft?
Otázka: Mohu sdílet jednu STA s více farmami, branami a výčtem serverů?

odstraňování problémů

otázka: jak by měla být služba IIS nakonfigurována tak, aby hostovala STA?
otázka: Jak povolím protokolování na STA?
Q: Proč nástroj Microsoft IISLockDown přeruší STA?
otázka: Jak mohu otestovat sta, abych se ujistil, že funguje správně?
otázka: jak interpretuji soubory protokolu STA?
otázka: Jaké jsou některé běžné chyby konfigurace, které vidí Technická podpora Citrix?

přehled

otázka: Jaký je Bezpečný Úřad pro lístky?

A: Secure Ticket Authority (sta) je webová služba XML, která si vyměňuje informace o serveru XenApp za náhodně generované vstupenky. Používá se k řízení přístupu pro Server Citrix Secure Gateway.

otázka: jaké produkty Citrix interagují se STA?

A: XenMobile, webové rozhraní, výkladní skříň, XenApp Secure Access Manager, NetScaler Gateway a Citrix Secure Gateway interagují se STA. V tomto článku jsou následující typy serverů seskupeny do jedné kategorie nazvané servery výčtu aplikací:

• webové rozhraní 2.0 nebo novější
• Secure Access Manager 2.0 nebo novější
• StoreFront
• servery výčtu aplikací jsou odpovědné za ověřování uživatelů, výčet publikovaných ikon aplikací a vytváření souboru ICA pro klienta, který jim umožňuje připojit se k publikované aplikaci prostřednictvím zabezpečeného serveru brány.

otázka: proč je Sta nutná?

A: v nasazení Citrix Secure Gateway server neprovádí ověřování příchozích požadavků. Místo toho gateway server odloží autentizaci na server výčtu aplikací a používá STA k zajištění autentizace každého uživatele. Servery výčtu aplikací požadují vstupenky pouze pro uživatele, kteří jsou již ověřeni na webovém serveru. Pokud mají uživatelé platné vstupenky STA, brána předpokládá, že prošli ověřovacími kontrolami na webovém serveru a měl by jim být povolen přístup.

tento návrh umožňuje serveru Citrix Secure Gateway zdědit jakékoli metody ověřování na vašem webovém serveru. Například, pokud je váš server webového rozhraní chráněn pomocí RSA SecurID, podle návrhu mohou přes server Secure Gateway procházet pouze uživatelé s ověřením SecurID.

otázka: jak je služba STA implementována?

A: STA je napsán jako rozšíření ISAPI pro Microsoft Internet Information Services (IIS). Rozšíření se nazývá CtxSta.dll a je ve výchozím nastavení hostován ve složce /Scripts. Ostatní komponenty komunikují se STA pomocí XML přes HTTP.

servery výčtu aplikací požadují vstupenky v době spuštění aplikace zasláním dat do STA jako součást žádosti o lístek. Data odeslaná na STA zahrnují adresu serveru XenApp, ke kterému se uživatel připojí, a v případě webového rozhraní 2.0 a Secure Access Manager 2.0 rozšířené informace o jménu aktuálního uživatele a publikované aplikaci, kterou chce uživatel spustit. Sta reaguje vygenerováním tiketu a jeho odesláním zpět na server výčtu aplikací. Tento lístek a jeho odpovídající data zůstávají v paměti na STA po konfigurovatelný počet sekund (ve výchozím nastavení 100).
server výčtu aplikací vytvoří soubor ICA pro uživatele a vloží lístek STA do pole adresy souboru ICA. Když se klient připojí k zabezpečené bráně, je lístek předložen a brána by měla lístek ověřit před vytvořením zabezpečené relace pro klienta. Brána provede požadavek na data zasláním lístku zpět do STA a na oplátku požádá o odpovídající data. Pokud je STA úspěšně ověřena, předá původní data do brány a Brána vytvoří relé mezi koncovým uživatelem a serverem XenApp.

jak požadavky na lístky, tak požadavky na data jsou prováděny jako dokumenty XML request/response.

otázka: existuje verze STA, která nevyžaduje IIS?

A: ne, v tuto chvíli je služba IIS povinna hostit STA. Nezapomeňte, že STA nemusí být vystavena nedůvěryhodné síti, jako je Internet; sta je umístěna ve vaší důvěryhodné síti a je přístupná pouze serverům s výčtem brány a aplikací.

otázka: kde se nachází server STA?

A: STA server může být umístěn kdekoli, pokud se k němu dostanou zabezpečené servery brány a výčtu aplikací. Citrix doporučuje umístit STA na důvěryhodnou síť nebo na samostatnou část interní brány firewall, ale neexistují žádné požadavky na server STA jiný než IIS. STA nemusí patřit do žádné domény, serverové farmy XenApp, farmy Správce zabezpečeného přístupu nebo jiného interního webového serveru, ale sdílení STA s jinou funkcí je běžnou praxí. Sta je automaticky součástí nastavení Secure Access Manager 2.0; mnoho správců považuje za vhodné lokalizovat STA na serveru XenApp.

otázka: Jaké jsou rozdíly mezi různými verzemi STA?

A: neexistují žádné materiální funkční rozdíly mezi verzemi 1.0 a 1.1, ale při použití 2.0 STA s webovým rozhraním 2.0 nebo Secure Access Manager 2.0, k žádosti o lístek se přidávají rozšířené informace: jméno uživatele a aplikace, kterou chce uživatel spustit. Tato rozšířená data jsou spotřebována službou gateway pro zobrazení podrobností o každé relaci brány v konzole pro správu Secure Gateway 2.0.

pokud je Secure Gateway 2.0 nakonfigurován tak, aby používal starší STA od Verze 1.1 nebo 1.0, mohou se uživatelé připojit k aplikacím, ale konzola Secure Gateway management console zobrazí „N / A“ pro uživatelské jméno a název aplikace přidružené ke každé relaci ICA. Chcete-li zobrazit rozšířené informace v zabezpečené bráně 2.0 konzola pro správu, musíte použít verzi 2.0 nebo novější z STA a použít buď Secure Access Manager 2.0 nebo webové rozhraní 2.0 jako aplikace výčtu serveru.

zabezpečení

otázka: jak se generuje lístek STA?

A: Rozšíření ISAPI CtxSta.dll používá generování pseudonáhodných čísel k vytvoření 16-byte hexadecimálního řetězce. Z bezpečnostních důvodů Citrix nezveřejňuje přesné kroky použité k vytvoření této náhodné sekvence znaků.

otázka: co představuje vstupenku STA?

A: formát kódování je řetězec tvaru:

;STA_VERSION; STA_ID; TICKET

kde:

• STA_VERSION je číselné pole identifikující verzi STA. V současné době jsou jedinými platnými hodnotami pro toto pole „10“ pro STA Verze 1.0 a 1.1 a “ 20 “ pro STA verze 2.0.
• STA_ID je posloupnost 0-16 znaků představující libovolný název přiřazený správcem konkrétní STA. Ve Verzi 1.x, tento řetězec výchozí STA01, STA02, a tak dále. Je-li STA nainstalován automaticky jako součást Secure Access Manager 2.0, STA ID je hash názvu serveru. Pokud je více sta sdíleno jedním serverem brány, musí být každé ID STA jedinečné. To umožňuje bráně najít STA, která vytvořila lístek, a vrátit se k tomuto STA pro ověření lístku. Lístek vytvořený na STA01 nebude existovat na STA02.
• TICKET je náhodně generovaná posloupnost 32 velkých abecedních nebo číselných znaků.

  například:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

otázka: je jízdenka ověřena proti pracovní stanici?

A: ne, neexistuje nic, co by spojovalo lístek s konkrétní pracovní stanicí. Teoreticky je možné, aby byl lístek vyžádán z pracovní stanice A a poté použit z pracovní stanice B. ke zmírnění tohoto rizika:

• vždy používejte protokol HTTPS mezi klientem a serverem výčtu aplikací, abyste zabránili útočníkovi v zachycení tiketu při cestě ze serveru na klienta.
• co nejvíce zkracujte dobu trvání tiketu, abyste snížili dobu, po kterou by útočník musel přenést letenku ze stroje A do stroje B.

nezapomeňte, že lístek vydaný STA lze použít pouze jednou, takže pokud se zamýšlený uživatel na stroji a úspěšně připojí, je lístek neplatný pro všechny budoucí pokusy o připojení ze stroje a nebo stroje B.

otázka: je lístek po použití smazán?

A: ano, vstupenky jsou vymazány ihned po úspěšném požadavku na data, takže je lze použít pouze jednou. Jsou také odstraněny po nastavitelném časovém limitu (výchozí 100 sekund) , pokud nejsou použity.

otázka: jsou vstupenky někdy zapsány na Disk na STA?

A: Pouze pokud je protokolování upovídané povoleno nastavením LogLevel=3 v CtxSta.konfigurace. V opačném případě sta udržuje všechny zbývající vstupenky (vstupenky, které byly požadovány serverem výčtu aplikací, ale dosud nebyly ověřeny zabezpečenou bránou) pomocí databáze v paměti. XML data jsou vždy odesílána do STA pomocí příkazu HTTP POST, takže do protokolů webového serveru STA nejsou nikdy zapsána žádná smysluplná data vstupenek.

otázka: je možné, aby někdo unesl lístek?

A: během normálního provozu musí jízdenka cestovat po následujících čtyřech segmentech sítě:

• od STA k serveru výčtu aplikací
• od serveru výčtu aplikací ke klientovi
• od klienta k serveru zabezpečené brány
• od brány k serveru STA

první a poslední segmenty existují pouze mezi servery ve vašem DMZ a STA ve vaší důvěryhodné síti, což znamená, že vetřelec by musel mít přístup k vaší síti, aby zachytil lístek podél těchto linek. Přesto mohou být tyto cesty šifrovány pomocí SSL, Pokud používáte zabezpečenou bránu verze 2.0. V Citrix Secure Gateway 1.1 a dříve, provoz na STA nelze zašifrovat pomocí SSL.

Chcete-li zabezpečit druhý segment, vložte certifikát na webový server výčtu aplikací a umožněte klientům připojení pouze v případě, že používají protokol HTTPS. Třetí segment je vždy zabezpečen SSL.

i když jsou všechny předchozí odkazy zabezpečeny pomocí SSL, klienti jsou stále zranitelní vůči útoku trojskými programy, které monitorují aktivitu klienta. Chcete-li toto riziko zmírnit, poraďte svým uživatelům, aby se připojili ze strojů, kde je nainstalován antivirový software a software pro detekci trojských koní.

otázka: Jak mohu chránit provoz STA pomocí SSL?

A: Nejprve nainstalujte certifikát webového serveru na kopii služby IIS, která je hostitelem STA. Další informace naleznete v dokumentaci služby IIS.

nakonfigurujte server výčtu aplikací a server zabezpečené brány tak, aby při komunikaci s bránou používaly protokol HTTPS. Při připojení pomocí HTTPS musí být vždy splněna následující pravidla:

• sta musíte oslovit pomocí plně kvalifikovaného názvu domény, který odpovídá předmětu certifikátu serveru STA.
• zařízení komunikující se sta musí být schopno vyřešit sta plně kvalifikovaný doménový název na příslušnou IP adresu.
• stroj komunikující se sta musí důvěřovat certifikační autoritě (CA), která certifikát STA server vydala.
• aby byly splněny požadavky třetí položky bullet, musí být kořenový certifikát CA nainstalován na serveru Secure Gateway a na serveru výčtu aplikací. Při instalaci kořenového certifikátu buďte opatrní: nemůžete jednoduše poklepat na soubor kořenového certifikátu a spustit Průvodce importem certifikátu.

(to znamená, že váš uživatelský účet, nikoli server nebo jakékoli systémové služby, důvěřuje CA.) Chcete-li nainstalovat kořenový certifikát pro použití s Citrix Secure Gateway nebo webovým rozhraním, postupujte takto:

1. spusťte Mmc.exe a přidejte modul snap-in certifikátů.
2. na otázku, které certifikáty chcete spravovat, vyberte účet počítače a poté Místní počítač.
3. rozbalte uzel Certificates (Local Computer) > Trusted Root Certification Authorities. Klepněte pravým tlačítkem myši na certifikáty a poté vyberte všechny úlohy > importovat.
4. Procházejte výběrem kořenového certifikátu CA a dokončete průvodce importem.

otázka: musí být STA vždy adresována pomocí plně kvalifikovaného názvu domény?

A: pokud máte v úmyslu zabezpečit provoz na STA pomocí protokolu SSL, musí každá komponenta, která přistupuje k STA, včetně vašeho serveru brány a serveru výčtu aplikací, oslovit STA pomocí plně kvalifikovaného názvu domény (FQDN), který odpovídá předmětu certifikátu serveru používaného službou IIS na STA. Například ve webovém rozhraní 2.0 bude adresa STA zadána jako:https://sta-server.company.com/Scripts/CtxSta.dll

pokud se rozhodnete nezajistit provoz na STA, můžete adresu STA adresovat pomocí IP adresy, názvu hostitele nebo FQDN.

otázka: Jak mohu změnit port STA z 80 na něco jiného?

A: protože sta slouží službě IIS, změníte port STA při změně portu IIS. Následující příklad ukazuje, jak změnit port IIS z 80 na 81.

1. otevřete Správce internetových služeb.
2. klepněte pravým tlačítkem myši na výchozí Web a zobrazte vlastnosti.
3. na kartě webové stránky změňte číslo portu TCP z 80 na 81.
4. klikněte na OK.
   předchozí změna se týká i všech dalších zdrojů, které jste zveřejnili z webového serveru STA. Pokud chcete změnit komunikační port STA bez ovlivnění jiných webových stránek hostovaných stejným webovým serverem, můžete vytvořit nový Web ve službě IIS pouze za účelem hostování STA. Následuje příklad toho, jak byste vytvořili nový Web na portu 81 pro STA.
5. vytvořte novou fyzickou složku, jako je C:\MYSTA na pevném disku vašeho webového serveru, který slouží jako kořen dokumentu pro web STA.
6. Vytvořte podadresář pod MYSTA s názvem skripty. Přesuňte následující soubory ze stávajícího STA do složky nové skripty:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. otevřete Správce internetových služeb.
8. klepněte pravým tlačítkem myši na název serveru a vyberte Nový > Web site.
9. vytvořit nový Web s názvem „My STA site“ a C:\MYSTA jako kořenový adresář dokumentu.
10. zobrazit vlastnosti nového webu a Změnit TCP port na 81.
11. pod mým sta webem ve Správci služeb Internetu klepněte pravým tlačítkem myši na složku skripty a zobrazte vlastnosti. V části Nastavení Aplikace změňte oprávnění ke spuštění na “ skripty a spustitelné soubory.“

Poznámka: Můžete si vybrat jiný název složky než „skripty“, ale uvědomte si, že Secure Gateway a všechny servery výčtu aplikací, jako je webové rozhraní, předpokládají, že STA je publikován jako / Scripts / CtxSta.dll takže budete také muset aktualizovat adresu URL STA v nastavení na těchto serverech.

otázka: může útočník poslat náhodné vstupenky do brány, aby se přihlásil?

A: útočník by musel uhodnout platnou letenku a také ji uplatnit během několika milisekund poté, co o ni klient požádá, ale dříve, než si ji brána nárokuje.

otázka: Jaké další informace jsou vyžadovány pro přihlášení kromě platné vstupenky STA?

A: uživatelé také potřebují pověření domény nebo lístek serveru XenApp, který je požadován serverem výčtu aplikací. (Lístek XenApp Server není stejný jako lístek STA.) Uspokojením STA se otevře cesta pouze k důvěryhodné síti pro konkrétní server. Poté, co tam, uživatel musí ještě ověřit s platnými pověření domény.
otázka: jak můžeme nastavit životnost jízdenky STA, po které by měla být jízdenka neplatná?
A: životnost jízdenky STA můžeme nastavit vytvořením následujícího klíče registru na ovladači dodávky:
umístění: HKLM \ Software \ Citrix \ DesktopServer
Název: XmlStaTicketLifetimeInSeconds
Typ: Hodnota Dword: Uveďte hodnotu v sekundách (desetinné)
před úpravou hodnot registru si prosím vezměte zálohu registru, také si všimněte, že změna registru by vyžadovala restart na konci řadiče.

škálovatelnost

otázka: kolik STAs potřebuji?

A: sta je přístupná pouze tehdy, když uživatel spustí aplikaci, odpověď na tuto otázku se liší od jednoho nasazení k druhému.

otázka: přihlašují se uživatelé přes bránu ráno a celý den spouštějí jednu publikovanou aplikaci nebo spouštějí několik aplikací po celý den?

A: Povinnosti prováděné STA nejsou drahé z hlediska CPU; jedná se o lehkou službu XML omezenou pouze výkonem služby IIS. V jednom testu podporoval server s nízkým dosahem s procesorem 1GHz a 256 MB RAM více než 250 požadavků na lístky za sekundu, zatímco využití procesoru zůstalo pod 60%.

otázka: Jak mohu zajistit odolnost proti chybám STA?

A: následující servery s výčtem aplikací umožňují při konfiguraci parametrů zabezpečené brány zadávat více adres URL STA:

• webové rozhraní 2.0
• Správce zabezpečeného přístupu 2.0
• StoreFront

ve všech případech, pokud STA neodpovídá, server výčtu aplikací zkusí další STA v seznamu. Každý server brány musí být nakonfigurován s adresou sta URL a jedinečným ID STA pro každou autoritu lístku.

otázka: Jak načíst vyvážení více STAs?

A: při vyrovnávání zatížení je třeba věnovat zvláštní pozornost bezpečnostním orgánům letenek. K vyvážení spojení mezi serverem výčtu aplikací a STAs lze použít různé metody, ale server zabezpečené brány musí vždy kontaktovat každou STA individuálně na základě svého ID STA. Při konfiguraci adresy každého STA v nástroji pro konfiguraci služby gateway musí být každá adresa STA skutečnou adresou serveru STA-nezadávejte zde adresu žádného vyvažovače zatížení hardwaru — názvu clusteru nebo názvu DNS round-robin.

výkladní skříň, webové rozhraní 2.0 a správce zabezpečeného přístupu 2.0 všechny podporují round-robin vyrovnávání zátěže STAs, pokud jsou uvedeny více STAs. Pokud je tato volba povolena, není nutný žádný další software nebo hardware pro vyrovnávání zatížení.

servery výčtu aplikací mohou použít jakoukoli formu vyvažování zátěže pro vydání žádosti o lístek, protože každá přijatá jízdenka obsahuje pole označující jedinečné ID STA, které ji vygenerovalo. Dokud je každé ID STA jedinečné a všechny servery brány mohou vyřešit ID STA na konkrétní adresu serveru (není vyváženo zatížení), operace uspěje a provoz STA je vyvážen.

Q: Mohu použít několik STAs s vyrovnáváním zatížení sítě Microsoft?

A: vyvažování zátěže sítě nelze použít mezi serverem Secure Gateway a více STAs. Pokud je takto nakonfigurován, uživatelé dostávají přerušované odmítnutí, protože během procesu ověření tiketu může být brána vyvážena na autoritu, která původně nevytvořila tiket uživatele.

Otázka: Mohu sdílet jednu STA s více farmami, branami a výčtem serverů?

A: Ano, Jeden STA lze sdílet mezi libovolným počtem serverů zabezpečené brány a serverů výčtu aplikací. Sta není omezen na žádnou konkrétní doménu, farmu nebo server výčtu aplikací. Jedná se o anonymní XML službu.

odstraňování problémů

otázka: jak by měla být služba IIS nakonfigurována tak, aby hostovala STA?

STA URL / Scripts / CtxSta.dll musí být doručena s povoleným anonymním přístupem. Pokud ukážete jakýkoli webový prohlížeč na adresu URL STA, nebudete vyzváni k zadání hesla.

• musíte v metabáze IIS udělit oprávnění skriptům a spustitelným zdrojům prostředků. Toto oprávnění není nutné pro celou složku / Scripts, ale lze jej nastavit pro CtxSta.dll soubor jednotlivě.
• pro Secure Gateway Verze 1.1 a starší nepovolujte Require SSL a vyžadujte 128bitové možnosti SSL.
• ve výchozím nastavení jsou zapotřebí následující oprávnění účtu:

na serverech Windows 2000

• účet iusr_machinename potřebuje přístup ke čtení k CtxSta.DLL.
• účet IWAM_MachineName potřebuje upravit přístup do adresáře souboru protokolu, který je ve výchozím nastavení \Inetpub\Scripts.

na serverech Windows 2003

• účet IUSR_MachineName potřebuje přístup ke čtení k CtxSta.DLL.
• vestavěný účet síťové služby potřebuje upravit přístup k adresáři souborů protokolu, který je ve výchozím nastavení \Inetpub\Scripts.

otázka: Jak povolím protokolování na STA?

A: pomocí programu Poznámkový blok upravte soubor \Inetpub \ Scripts\CtxSta.config na STA serveru a vyhledejte řádek, který říká LogLevel=0. Pro maximální protokolování to změňte na LogLevel=3. Aby se změny projevily, musíte restartovat službu publikování na webu.
Poznámka: Po povolení protokolování musí mít uživatelský účet, pod jehož autoritou STA provádí (iusr_machinename v systému Windows 2000 nebo Network Service v systému Windows 2003 ve výchozím nastavení) Přístup pro zápis do adresáře souborů protokolu, který je ve výchozím nastavení \Inetpub\Scripts. Adresář souborů protokolu můžete také změnit při úpravě CtxSta.konfigurace.

otázka: Proč nástroj Microsoft IISLockDown přeruší STA?

A: Pokud přijmete všechna výchozí nastavení nástroje IISLockDown, složka / Scripts je zakázána. Sta je implementován jako filtr ISAPI publikovaný jako / Scripts / CtxSta.dll; vypnutím adresáře / Scripts odepřete přístup ke STA. Povolte složku / Scripts a povolte přístup skriptů a spustitelných souborů pro funkci STA.

otázka: Jak mohu otestovat sta, abych se ujistil, že funguje správně?

A: pokud ukážete webový prohlížeč na adresu URL STA, zobrazí se buď prázdná bílá stránka, nebo zpráva “ 405 zdroj není povolen.“Jeden z těchto výsledků naznačuje fungující STA. Tímto způsobem můžete kontaktovat STA z konzoly serveru zabezpečené brány a také z libovolného serveru výčtu aplikací nakonfigurovaného pro použití brány. Pokud se zobrazí dialogové okno ověřování s výzvou k zadání hesla, STA není zveřejněna anonymně a požadavky na ověření je třeba odstranit.

Chcete-li ověřit, že server výčtu aplikací úspěšně požaduje vstupenky STA, podívejte se na soubory ICA, které generuje. Například z webového rozhraní 2.0 můžete kliknout pravým tlačítkem myši na ikonu publikované aplikace a výsledek uložit jako spuštění.ica. Spustit start.ica v Poznámkovém bloku a zobrazit řádek Address=. Pro normální provoz zabezpečené brány bude parametr adresa obsahovat lístek místo skutečné adresy serveru XenApp.

otázka: jak interpretuji soubory protokolu STA?

A: pokud povolíte protokolování nastavením LogLevel=3 v CtxSta.config, uvidíte podrobnosti o každém lístku a žádosti o údaje přijaté STA. Nezapomeňte, že požadavek na lístek je generován serverem výčtu aplikací, jako je webové rozhraní, a požadavek na data provádí služba Secure Gateway. Pokud soubor protokolu zobrazuje několik požadavků na lístky, ale žádné požadavky na data, znamená to, že server výčtu aplikací může dosáhnout sta, ale server zabezpečené brány nemůže. To může také znamenat, že uživatelé se nemohou dostat na server brány.

během normálního provozu může funkce sdílení relací klienta ICA způsobit, že vstupenky budou požadovány od STA, ale nikdy nebudou nárokovány bránou. Zvažte následující scénář:

• uživatel se přihlásí do webového rozhraní a klikne na ikonu aplikace Outlook. Webové rozhraní požaduje lístek od STA a odešle jej uživateli v souboru ICA.
• uživatel se připojí přes zabezpečenou bránu a předloží vstupenku k přijetí. Brána ověřuje lístek a umožňuje uživateli připojit se k serveru XenApp hostujícímu aplikaci Outlook.
• po několika minutách práce se uživatel vrátí do seznamu aplikací na stránce webového rozhraní a klikne na ikonu aplikace Excel. Webové rozhraní požaduje druhou vstupenku ze STA a odešle ji uživateli v souboru ICA.
• před připojením k novému serveru pro Excel klient ICA nejprve zkontroluje, zda existující servery, ke kterým je klient již připojen, mají k dispozici publikovanou aplikaci Excel.
• server, na kterém klient již používá aplikaci Outlook, má také nainstalovanou aplikaci Excel, takže klient ICA zahodí soubor ICA a spustí aplikaci Excel v rámci existující relace ICA.
• druhá vstupenka požadovaná webovým rozhraním se nikdy nepoužívá, protože druhá relace ICA nebyla nutná. Ve výchozím nastavení se jízdenka krátí po 100 sekundách.

tento scénář by měl za následek řadu položek protokolu sta podobných následujícím:

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

další podezřelá aktivita může vypadat asi takto:

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

zde vidíme, co se zdá být útočníkem, který zkouší různé lístky jeden po druhém, zvyšování ID lístku s každým pokusem. V každém případě bylo spojení odmítnuto a sta zaznamenal záznam označující, že klient předložil lístek, který nebyl uznán jako platný. Chcete-li identifikovat IP adresu útočníka, vyhledejte následující zprávu v Prohlížeči událostí na serveru Secure Gateway:

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

neinterpretujte některé zprávy“ Ticket NOT found “ jako útok. Klient ICA Win32 se může pokusit znovu připojit k odpojené relaci, pokud je síťové připojení uživatele na okamžik přerušeno. Funkce automatického opětovného připojení klienta nefunguje pro uživatele Citrix Secure Gateway, protože během každého pokusu o opětovné připojení klient znovu odešle použitý lístek STA, se kterým se původně připojil. Klient se obvykle pokusí znovu připojit třikrát nebo vícekrát, než se vzdá, takže uvidíte tři nebo více zpráv „Ticket NOT found“ odkazujících na stejný lístek v protokolu STA pro každý výskyt tohoto problému. Pokusy o opětovné připojení klienta jsou charakterizovány pokusem o opětovné použití dříve úspěšného tiketu:

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

odpojte Auto Client Reconnect pro uživatele zabezpečené brány přidáním TransportReconnectEnabled=Off do části souboru ICA. Správný způsob, jak se znovu připojit k odpojené relaci při použití zabezpečené brány, je vrátit se na server výčtu aplikací a znovu kliknout na ikonu aplikace.

otázka: Jaké jsou některé běžné chyby konfigurace, které vidí Technická podpora Citrix?

• složka / Scripts nebo celý výchozí Web je deaktivován v důsledku spuštění IISLockDown nebo dodržování zásad společnosti pro ochranu webových serverů.
• protokolování je povoleno v CtxSta.config, ale uživatelský účet, pod jehož autoritou STA vykonává (iusr_machinename ve výchozím nastavení), nemá přístup k zápisu do adresáře souborů protokolu.
• IIS na serveru STA je nakonfigurován tak, aby vyžadoval SSL, ale Secure Gateway je nakonfigurován pro přístup k STA pomocí normálního HTTP.
• pokud se spuštění aplikace nezdaří, je třeba nejprve zkontrolovat, zda jsou STAs na výloze / webovém rozhraní a NetScaler uvedeny přesně stejným způsobem nebo ne, tj. pokud jsou STAs uvedeny jako IP adresa na SF / WI, měla by být zadána pomocí IP adresy na NS a podobně v případě FQDN.