GYIK: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

Megjegyzés: ugyanazok az elvek és koncepciók érvényesek a NetScaler Gateway esetében is.

ez a cikk megválaszol néhány gyakran feltett kérdést a Citrix Secure Ticket Authority (STA) kapcsán. A kérdések a következő négy kategóriába sorolhatók:

áttekintés

K: Mi a biztonságos Jegyhatóság?
K: Milyen Citrix termékek lépnek kapcsolatba az STA-val?
K: Miért szükséges az STA?
k: hogyan valósul meg az STA szolgáltatás?
Q: Van-e az STA olyan verziója, amely nem igényli az IIS-t?
K: Hol található az STA szerver?
K: Mi a különbség az STA különböző verziói között?

biztonság

K: Hogyan készül az STA jegy?
k: mit jelent az STA jegy?
K: érvényesítik-e a jegyet a munkaállomással szemben?
K: használat után törlődik a Jegy?
K: írtak már jegyeket lemezre az STA-ban?
K: lehetséges, hogy valaki eltérítsen egy jegyet?
K: Hogyan védhetem meg az STA forgalmat SSL-lel?
Q: Az STA-t mindig teljesen minősített Domain névvel kell kezelni?
K: Hogyan változtathatom meg az STA portot 80-ról valami másra?
k: a támadó véletlenszerű jegyeket küldhet az átjáróra a bejelentkezéshez?
k: az érvényes Sta-jegyen kívül milyen egyéb információ szükséges a bejelentkezéshez?
k: hogyan állíthatjuk be az STA jegy élettartamát, amely után a jegynek érvénytelennek kell lennie?

méretezhetőség

K: Hány Sta – ra van szükségem?
Q: A felhasználók reggel bejelentkeznek az átjárón keresztül, és egész nap egyetlen közzétett alkalmazást futtatnak, vagy egész nap több alkalmazást indítanak?
K: Hogyan biztosíthatom az STA hibatűrését?
K:Hogyan tölthetek be több Sta-t?
K: használhatok több Sta-t a Microsoft hálózati terheléselosztással?
K: megoszthatok egyetlen STA-t több farmmal, átjáróval és Számlálószerverrel?

hibaelhárítás

kérdés: hogyan kell konfigurálni az IIS-t az STA fogadására?
K: Hogyan engedélyezhetem a naplózást az STA – ban?
Q: Miért szakítja meg a Microsoft IISLockDown eszköz az STA-t?
K: Hogyan tesztelhetem az STA-t, hogy megbizonyosodjon arról, hogy megfelelően működik?
K: Hogyan értelmezhetem az STA naplófájlokat?
k: melyek a Citrix technikai támogatása által észlelt gyakori konfigurációs hibák?

áttekintés

K: Mi a biztonságos Jegyhatóság?

V: A Secure Ticket Authority (Sta) egy XML webszolgáltatás, amely véletlenszerűen generált jegyekre cseréli a XenApp Szerver adatait. Arra használják, hogy ellenőrizzék a hozzáférést a Citrix Secure Gateway server.

K: Milyen Citrix termékek lépnek kapcsolatba az STA-val?

V: XenMobile, webes felület, kirakat, XenApp Secure Access Manager, NetScaler Gateway és Citrix Secure Gateway kölcsönhatásba lépnek az STA-val. Ebben a cikkben a következő típusú kiszolgálók egyetlen kategóriába vannak csoportosítva, az úgynevezett application enumeration servers kategóriába:

• webes felület 2.0 vagy újabb
• Secure Access Manager 2.0 vagy újabb
• StoreFront
• az Alkalmazásszámláló kiszolgálók felelősek a felhasználók hitelesítéséért, a közzétett alkalmazásikonok felsorolásáért, valamint egy ICA fájl létrehozásáért az ügyfél számára, amely lehetővé teszi számukra, hogy biztonságos átjárókiszolgálón keresztül csatlakozzanak egy közzétett alkalmazáshoz.

K: Miért szükséges az STA?

V: A Citrix Secure Gateway telepítésekben az átjárókiszolgáló nem hajtja végre a bejövő kérések hitelesítését. Ehelyett az átjárókiszolgáló elhalasztja a hitelesítést egy alkalmazásszámláló kiszolgálóra, és az STA segítségével garantálja, hogy minden felhasználó hitelesítve van. Az alkalmazásszámláló kiszolgálók csak a webkiszolgálón már hitelesített felhasználók számára kérnek jegyet. Ha a felhasználók érvényes STA-jegyekkel rendelkeznek, az átjáró feltételezi, hogy megfeleltek a hitelesítési ellenőrzéseknek a webkiszolgálón, és engedélyezni kell számukra a hozzáférést.

ez a kialakítás lehetővé teszi a Citrix Secure Gateway server számára, hogy bármilyen hitelesítési módszert örököljön a webszerveren. Ha például a webes felület kiszolgálóját RSA SecurID védi, akkor csak a SecurID által hitelesített felhasználók léphetnek át a biztonságos átjárókiszolgálón.

k: hogyan valósul meg az STA szolgáltatás?

V: az STA a Microsoft Internet Information Services (IIS) ISAPI kiterjesztéseként van megírva. A kiterjesztés neve CtxSta.a dll alapértelmezés szerint a /Scripts mappában található. Más komponensek kommunikálni az STA segítségével XML HTTP-n keresztül.

az Alkalmazásszámláló kiszolgálók jegyeket kérnek az alkalmazás indításakor azáltal, hogy adatokat küldenek az STA-nak egy jegykérelem részeként. Az STA-nak küldött adatok tartalmazzák annak a XenApp szervernek a címét, amelyhez a felhasználó csatlakozik, valamint a Web Interface 2.0 és a Secure Access Manager 2.0 esetében bővített információkat az aktuális felhasználó nevéről és a felhasználó által futtatni kívánt közzétett alkalmazásról. Az STA úgy válaszol, hogy létrehoz egy jegyet, majd visszaküldi azt az alkalmazásszámláló szerverre. Ez a jegy és a hozzá tartozó adatok az STA memóriájában maradnak egy beállítható számú másodpercig (alapértelmezés szerint 100).
az application enumeration server létrehoz egy ICA-fájlt a felhasználó számára, és beszúrja az STA-jegyet az ICA-fájl címmezőjébe. Amikor az ügyfél csatlakozik a biztonságos átjáróhoz, megjelenik a jegy, és az átjárónak érvényesítenie kell a jegyet, mielőtt biztonságos munkamenetet hozna létre az ügyfél számára. Az átjáró adatkérést hajt végre úgy, hogy visszaküldi a jegyet az STA-nak, és cserébe kéri a megfelelő adatokat. Sikeres validálás esetén az STA továbbítja az eredeti adatokat az átjárónak, és az átjáró létrehoz egy relét a végfelhasználó és a XenApp Szerver között.

mind a jegykérelmek, mind az adatkérések XML kérési/válaszdokumentumként kerülnek végrehajtásra.

k: van az STA-nak olyan verziója, amely nem igényel IIS-t?

A: nem, jelenleg az IIS szükséges az STA tárolásához. Ne feledje, hogy az STA-t nem kell olyan megbízható hálózatnak kitenni, mint az Internet; az STA az Ön megbízható hálózatán található,és csak az átjáró-és alkalmazásszámláló kiszolgálók férnek hozzá.

K: Hol található az STA szerver?

V: az STA szerver bárhol elhelyezhető, amíg a biztonságos átjáró és az alkalmazásszámláló szerverek el tudják érni. A Citrix azt javasolja, hogy az STA-t a megbízható hálózatra vagy a belső tűzfal külön szakaszára helyezze, de az IIS-en kívül az STA-kiszolgálóra nincsenek követelmények. Az STA-nak nem kell semmilyen tartományhoz, XenApp Server farmhoz, Secure Access Manager farmhoz vagy más belső webszerverhez tartoznia, de az STA megosztása egy másik funkcióval bevett gyakorlat. Az STA automatikusan szerepel a Secure Access Manager 2.0 beállítás részeként; sok rendszergazda kényelmesnek találja az STA megkeresését egy XenApp szerveren.

K: Mi a különbség az STA különböző verziói között?

V: nincsenek lényeges funkcionális különbségek az 1.0 és az 1.1 verziók között, de a 2.0 Sta használata a Web Interface 2.0 vagy a Secure Access Manager 2 használatával.0, bővített információ kerül hozzáadásra a jegykérelemhez: a felhasználó neve és a felhasználó által futtatni kívánt alkalmazás. Ezeket a kiterjesztett adatokat az átjáró szolgáltatás felhasználja az egyes átjáró-munkamenetek részleteinek megjelenítéséhez a Secure Gateway 2.0 Felügyeleti konzolon.

ha a Secure Gateway 2.0 úgy van konfigurálva, hogy egy régebbi, 1.1-es vagy 1.0-s verziójú STA-t használjon, a felhasználók csatlakozhatnak az alkalmazásokhoz, de a Secure Gateway management console “N/A” – t jelenít meg az egyes ICA-munkamenetekhez társított felhasználónév és alkalmazásnév esetében. A kiterjesztett információk megtekintése a biztonságos átjáróban 2.0 management console, az STA 2.0 vagy újabb verzióját kell használnia, és a Secure Access Manager 2.0 vagy a Web Interface 2.0 alkalmazást kell használnia alkalmazásszámláló kiszolgálóként.

biztonság

K: Hogyan készül az STA jegy?

A: az ISAPI kiterjesztés CtxSta.a dll ál-véletlenszám-generálást használ egy 16 bájtos hexadecimális karakterlánc előállításához. Biztonsági okokból a Citrix nem hozza nyilvánosságra a véletlenszerű karaktersorozat előállításához használt pontos lépéseket.

k: mit jelent az STA jegy?

A: a kódolási formátum egy karakterlánc a következő formában:

;STA_VERSION; STA_ID; jegy

hol:

• a STA_VERSION egy numerikus mező, amely azonosítja az STA verzióját. Jelenleg a mező egyetlen érvényes értéke a “10” az STA 1.0-s és 1.1-es verzióihoz, valamint a ” 20 ” az STA 2.0-s verziójához.
• a STA_ID egy 0-16 karakterből álló sorozat, amely az adminisztrátor által egy adott STA – hoz rendelt tetszőleges nevet képvisel. Az 1. Verzióban.x, Ez a karakterlánc alapértelmezés szerint STA01, STA02 stb. Amikor az STA automatikusan települ a Secure Access Manager 2.0 részeként, az STA ID a kiszolgáló nevének kivonata. Ha egyetlen átjárókiszolgáló több Sta-t oszt meg, minden STA-azonosítónak egyedinek kell lennie. Ez lehetővé teszi az átjáró számára, hogy megkeresse a jegyet létrehozó STA-t, és visszatérjen az STA-hoz a jegy érvényesítéséhez. Az STA01-en létrehozott jegy nem létezik az STA02-en.
• a TICKET egy véletlenszerűen generált, 32 nagybetűs alfabetikus vagy numerikus karakterből álló sorozat.

  például:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

k: a jegyet a munkaállomással szemben érvényesítik?

A: nem, semmi sem köti a jegyet egy adott munkaállomáshoz. Elméletileg lehetséges, hogy jegyet kell kérni az a munkaállomásról, majd felhasználni a B munkaállomásról. ennek a kockázatnak a csökkentése érdekében:

• mindig használja a HTTPS-t az ügyfél és az alkalmazásszámláló kiszolgáló között, hogy megakadályozza a támadót a jegy elfogásában a kiszolgálóról az ügyfélre történő utazás során.
• a lehető legnagyobb mértékben csökkentse a jegy élettartamának időtartamát, hogy csökkentse azt az időt, ameddig a támadónak át kell vinnie a jegyet az A gépről a B gépre.

ne feledje, hogy az STA által kiadott jegy csak egyszer használható fel, tehát ha az a gépen a kívánt felhasználó sikeresen csatlakozik, akkor a jegy érvénytelen az A vagy a B gép minden jövőbeli csatlakozási kísérletére.

K: használat után törli a jegyet?

V: Igen, a jegyeket a sikeres adatkérés után azonnal töröljük, így csak egyszer használhatók fel. A konfigurálható időtúllépés (alapértelmezett 100 másodperc) után is törlődnek, ha nem használják.

K: írtak már jegyeket lemezre az STA-ban?

A: Csak akkor, ha a részletes naplózás engedélyezve van a LogLevel=3 beállításával a CtxSta – ban.config. Ellenkező esetben az STA az összes fennálló jegyet (olyan jegyeket, amelyeket egy alkalmazásszámláló szerver kért, de amelyeket egy biztonságos átjáró még nem érvényesített) egy memóriában lévő adatbázis segítségével tart fenn. Az XML-adatokat mindig a HTTP POST paranccsal küldi el az STA-nak, így soha nem írnak értelmes jegyadatokat az STA webszerver naplóiba.

K: lehetséges, hogy valaki eltérítsen egy jegyet?

A: normál működés közben a jegynek a hálózat következő négy szegmensén kell utaznia:

• az STA-tól az application enumeration server-ig
• az application enumeration server-től az ügyfélig
• az ügyféltől a Secure Gateway server-ig
• az átjárótól az STA-ig

az első és az utolsó szegmens csak a DMZ-ben lévő kiszolgálók és a megbízható szolgáltatáson lévő sta között létezik hálózat, ami azt jelenti, hogy egy behatolónak hozzáférnie kell a hálózatához, hogy elfogja a jegyet ezen a vonalon. Ennek ellenére ezek az útvonalak SSL-vel titkosíthatók, ha a Secure Gateway 2.0 verziót használja. A Citrix Secure Gateway 1-Ben.1 és korábban az STA-ba irányuló forgalmat nem lehet SSL-lel titkosítani.

a második szegmens biztosításához helyezzen el egy tanúsítványt az application enumeration webkiszolgálón, és csak akkor engedélyezze az ügyfelek számára a csatlakozást, ha HTTPS-t használnak. A harmadik szegmens mindig SSL-vel van biztosítva.

még akkor is, ha az összes előző link SSL-rel van rögzítve, az ügyfelek továbbra is sebezhetőek az ügyféltevékenységet figyelő trójai programok támadásaival szemben. A kockázat csökkentése érdekében javasoljuk a felhasználóknak, hogy csatlakozzanak olyan gépekről, amelyeken vírus-és trójai felderítő szoftver van telepítve.

K: Hogyan védhetem meg az STA forgalmat SSL-lel?

V: először telepítsen egy webkiszolgáló tanúsítványt az IIS azon példányára, amely az STA-t tárolja. További információ az IIS dokumentációjában található.

az application enumeration server és a Secure Gateway server konfigurálása HTTPS használatára az átjáróval való kommunikáció során. Ha HTTPS-en keresztül csatlakozik, a következő szabályokat mindig be kell tartani:

• az STA-t egy teljesen minősített tartománynévvel kell címeznie, amely megegyezik az STA-kiszolgáló tanúsítványának tárgyával.
• az STA-val kommunikáló gépnek képesnek kell lennie az STA teljes minősítésű domain név megfelelő IP-címre történő feloldására.
• az STA-val kommunikáló gépnek megbíznia kell az STA-kiszolgáló tanúsítványt kiadó Hitelesítésszolgáltatóban (CA).
• a harmadik felsoroláselem követelményeinek teljesítéséhez a hitelesítésszolgáltató főtanúsítványát telepíteni kell a Secure Gateway kiszolgálóra és az application enumeration kiszolgálóra. Vigyázzon a gyökértanúsítvány telepítésekor: nem lehet egyszerűen duplán kattintani egy gyökértanúsítványfájlra, és futtatni a Tanúsítványimportáló varázslót.

(ez azt jelzi, hogy a felhasználói fiók, nem a szerver vagy bármely rendszerszolgáltatás, bízik a CA-ban.) A Citrix Secure Gateway vagy webes felület használatával használható gyökértanúsítvány telepítéséhez kövesse az alábbi lépéseket:

1. futtassa az Mmc-t.exe és adja hozzá a tanúsítványok beépülő modult.
2. amikor megkérdezi, hogy mely tanúsítványokat kezelje, válassza a Számítógépfiók, majd a helyi számítógép lehetőséget.
3. bontsa ki a tanúsítványokat (helyi számítógép) > Megbízható legfelső szintű hitelesítésszolgáltatók csomópont. Kattintson a jobb gombbal a Tanúsítványok elemre, majd válassza az összes feladat > Importálás lehetőséget.
4. tallózással válassza ki a CA gyökértanúsítványát, majd fejezze be az Importálás varázslót.

k: az STA-t mindig teljesen minősített Domain névvel kell kezelni?

V: Ha SSL használatával kívánja biztosítani az STA-ba irányuló forgalmat, az STA-hoz hozzáférő bármely összetevőnek, beleértve az átjárókiszolgálót és az alkalmazásszámláló-kiszolgálót is, az STA-t az IIS által az STA-n használt kiszolgálótanúsítvány tárgyának megfelelő, teljesen minősített tartománynévvel (FQDN) kell címeznie. Például a Web Interface 2.0 – ban az STA címet a következőképpen kell megadni:https://sta-server.company.com/Scripts/CtxSta.dll

ha úgy dönt, hogy nem biztosítja a forgalmat az STA-ba, akkor az STA-t IP-címmel, gazdagépnévvel vagy FQDN-vel címezheti.

K: Hogyan változtathatom meg az STA portot 80-ról valami másra?

V: mivel az STA-t az IIS szolgálja ki, az STA-portot az IIS-port módosításakor módosítja. A következő példa bemutatja, hogyan lehet az IIS-portot 80-ról 81-re változtatni.

1. nyissa meg az Internet Services Manager alkalmazást.
2. kattintson a jobb gombbal az alapértelmezett webhelyre, és tekintse meg a tulajdonságokat.
3. a webhely lapon módosítsa a TCP port számát 80-ról 81-re.
4. kattintson az OK gombra.
   az előző módosítás az STA webkiszolgálón közzétett egyéb erőforrásokat is érinti. Ha módosítani szeretné az STA kommunikációs portot anélkül, hogy befolyásolná az ugyanazon webkiszolgáló által üzemeltetett más weboldalakat, létrehozhat egy új webhelyet az IIS-ben, kizárólag az STA tárolása céljából. Az alábbiakban bemutatjuk, hogyan hozhat létre új webhelyet a 81-es porton az STA számára.
5. hozzon létre egy új fizikai mappát, például C:\MYSTA a webkiszolgáló merevlemezén, hogy az STA webhely dokumentumgyökéreként szolgáljon.
6. hozzon létre egy alkönyvtárat a Mysta alatt Scripts néven. Helyezze át a következő fájlokat a meglévő STA-ból az új szkriptek mappába:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. nyissa meg az Internet Services Manager alkalmazást.
8. kattintson a jobb gombbal a kiszolgáló nevére, majd válassza az új > webhely lehetőséget.
9. hozzon létre egy új weboldalt “My sta site” néven és C:\MYSTA a dokumentum gyökérkönyvtáraként.
10. tekintse meg az új webhely tulajdonságait, és módosítsa a TCP portot 81-re.
11. az Internet Services Manager saját STA webhelye alatt kattintson a jobb gombbal a parancsfájlok mappára, és tekintse meg a tulajdonságokat. Az alkalmazás beállításai részben módosítsa a végrehajtási engedélyeket “Scripts and Executables” értékre.”

megjegyzés: a “parancsfájlok” – tól eltérő mappanevet is választhat, de vegye figyelembe, hogy a Secure Gateway és az összes alkalmazásszámláló kiszolgáló, például a webes felület feltételezi, hogy az STA /Scripts/CtxSta néven jelenik meg.dll így akkor is frissíteni kell az STA URL-t a beállításokat ezen szerverek.

k: a támadó véletlenszerű jegyeket küldhet az átjáróra a bejelentkezéshez?

V: A támadónak meg kell találnia egy érvényes jegyet, és be kell váltania azt néhány milliszekundumon belül, miután az ügyfél kéri, de mielőtt az átjáró igényelné.

k: az érvényes Sta-jegyen kívül milyen egyéb információ szükséges a bejelentkezéshez?

V: A felhasználóknak domain hitelesítő adatokra vagy XenApp Kiszolgálójegyre is szükségük van, amelyet az alkalmazásszámláló kiszolgáló kér. (A XenApp Szerver jegy nem ugyanaz, mint egy STA jegy.) Az STA kielégítése csak egy adott szerver megbízható hálózatának elérési útját nyitja meg. Miután odaért, a felhasználónak továbbra is érvényes domain hitelesítő adatokkal kell hitelesítenie.
k: hogyan állíthatjuk be az STA jegy élettartamát, amely után a jegynek érvénytelennek kell lennie?
V: az STA jegy élettartamát a következő rendszerleíró kulcs létrehozásával állíthatjuk be a kézbesítési vezérlőn:
hely: HKLM \ Software \ Citrix \ DesktopServer
név: XmlStaTicketLifetimeInSeconds
Típus: Dword érték: Adjon értéket másodpercben (decimális)
kérjük, készítsen biztonsági másolatot a rendszerleíró adatbázis értékeinek szerkesztése előtt, vegye figyelembe azt is, hogy a rendszerleíró adatbázis módosítása újraindítást igényel a vezérlő végén.

méretezhetőség

K: Hány Sta – ra van szükségem?

A: az STA csak akkor érhető el, ha a felhasználó elindít egy alkalmazást, a válasz erre a kérdésre telepítésenként változik.

k: a felhasználók reggel bejelentkeznek az átjárón, és egész nap egyetlen közzétett alkalmazást futtatnak, vagy egész nap több alkalmazást indítanak?

A: Az STA által végzett feladatok CPU szempontjából nem drágák; ez egy könnyű XML szolgáltatás, amelyet csak az IIS teljesítménye korlátoz. Az egyik teszt során egy alacsony hatótávolságú, 1 GHz-es processzorral és 256 MB RAM-mal rendelkező szerver másodpercenként több mint 250 jegykérelmet támogatott, míg a CPU kihasználtsága 60% alatt maradt.

K: Hogyan biztosíthatom az STA hibatűrését?

V: A következő alkalmazásszámláló kiszolgálók mindegyike lehetővé teszi több Sta URL megadását a biztonságos átjáró paramétereinek konfigurálásakor:

• webes felület 2.0
• biztonságos hozzáférés-kezelő 2.0
• StoreFront

minden esetben, ha EGY STA nem válaszol, az alkalmazás számlálókiszolgáló megpróbál egy másik STA-t a listán. Minden átjárókiszolgálót be kell állítani az STA URL-jével és az egyes jegyhatóságok egyedi sta-azonosítójával.

K:Hogyan tölthetek be több Sta-t?

V: különös gonddal kell eljárni, amikor a rakomány kiegyenlítése biztonságos Jegyhatóságok. Számos módszer használható az alkalmazásszámláló kiszolgáló és az STA-k közötti kapcsolat betöltésére, de a biztonságos Átjárókiszolgálónak mindig külön-külön kell kapcsolatba lépnie az egyes STA-kkal az STA-azonosítója alapján. Az átjáró szolgáltatás konfigurációs eszközében az egyes STA-k címének konfigurálásakor minden STA-címnek Az STA-kiszolgáló valódi címének kell lennie — ne írja be ide a hardverterhelés-kiegyenlítő, a fürt nevét vagy a körmérkőzéses DNS-nevet.

StoreFront, Web Interface 2.0 és Secure Access Manager 2.0 Minden támogatja a sta-k körmérkőzéses terheléselosztását, ha több Sta szerepel a listán. Ha ez az opció engedélyezve van, nincs szükség további terheléselosztó szoftverre vagy hardverre.

az Alkalmazásszámláló kiszolgálók a terheléselosztás bármely formáját használhatják jegykérelem kiadásához, mivel minden beérkezett jegy tartalmaz egy mezőt, amely jelzi az azt létrehozó STA egyedi azonosítóját. Mindaddig, amíg minden egyes STA-azonosító egyedi, és az összes átjárókiszolgáló fel tudja oldani az STA-azonosítót egy adott (nem terheléskiegyenlített) kiszolgáló címére, a művelet sikeres, és az STA-forgalom terheléskiegyenlített.

Q: Használhatok több Sta-t a Microsoft hálózati terheléselosztással?

V: A Hálózati terheléselosztás nem használható a biztonságos átjárókiszolgáló és több Sta között. Ha így van konfigurálva, a felhasználók időszakos elutasításokat kapnak, mert a jegyellenőrzési folyamat során az átjáró betöltése kiegyensúlyozható lehet egy olyan hatósággal, amely eredetileg nem generálta a felhasználó jegyét.

K: megoszthatok egyetlen STA-t több farmmal, átjáróval és Számlálószerverrel?

A: Igen, egyetlen STA megosztható tetszőleges számú biztonságos átjárókiszolgáló és alkalmazásszámláló szerver között. Az STA nem korlátozódik egy adott tartományra, farmra vagy alkalmazásszámláló kiszolgálóra. Ez egy névtelen XML szolgáltatás.

hibaelhárítás

kérdés: hogyan kell konfigurálni az IIS-t az STA fogadására?

az STA URL /szkriptek/CtxSta.a dll-t névtelen hozzáféréssel kell kiszolgálni. Ha bármely webböngészőt az STA URL-re mutat, akkor a rendszer nem kéri a jelszót.

• engedélyt kell adnia az erőforrás-parancsfájloknak és a végrehajtható fájloknak az IIS metabázisában. Ez az engedély nem szükséges a teljes / Scripts mappához, de beállítható a CtxSta számára.dll fájl külön-külön.
• a Secure Gateway 1.1-es és korábbi verziója esetén ne engedélyezze az SSL megkövetelése és a 128 bites SSL megkövetelése beállítást.
• alapértelmezés szerint a következő fiókengedélyekre van szükség:

Windows 2000 kiszolgálókon

• az IUSR_MachineName fiók olvasási hozzáférést igényel a CtxSta-hoz.dll.
• az IWAM_MachineName fióknak módosítania kell a naplófájl könyvtárhoz való hozzáférést, amely alapértelmezés szerint \Inetpub\Scripts.

Windows 2003 kiszolgálókon

• az IUSR_MachineName fiók olvasási hozzáférést igényel a CtxSta-hoz.dll.
• a beépített hálózati szolgáltatási fióknak módosítania kell a naplófájl-könyvtárhoz való hozzáférést, amely alapértelmezés szerint \Inetpub\Scripts.

K: Hogyan engedélyezhetem a naplózást az STA-ban?

V: a Jegyzettömb használatával szerkessze az \Inetpub\Scripts\CtxSta fájlt.állítsa be az STA kiszolgálón, és keresse meg a LogLevel=0 Sort. A maximális naplózáshoz módosítsa ezt LogLevel=3 értékre. A módosítások érvénybe lépéséhez újra kell indítania a World Wide Web Publishing szolgáltatást.
Megjegyzés: miután engedélyezte a naplózást, annak a felhasználói fióknak, amelynek jogosultsága alatt az STA végrehajtásra kerül (alapértelmezés szerint az iusr_machinename Windows 2000 rendszeren vagy a Network Service Windows 2003 rendszeren) írási hozzáféréssel kell rendelkeznie a naplófájl könyvtárához, amely alapértelmezés szerint \Inetpub\Scripts. A ctxsta szerkesztésekor megváltoztathatja a naplófájl könyvtárát is.config.

K: Miért szakítja meg a Microsoft IISLockDown eszköz az STA-t?

A: Ha elfogadja az iislockdown eszköz összes alapértelmezett beállítását, a / Scripts mappa le van tiltva. Az STA egy ISAPI szűrőként van megvalósítva, amelyet /Scripts/CtxSta néven tesznek közzé.dll; a /Scripts könyvtár letiltásával megtagadja a hozzáférést az STA-hoz. Engedélyezze a / Scripts mappát, és engedélyezze a szkriptek és végrehajtható fájlok elérését az STA működéséhez.

K: Hogyan tesztelhetem az STA-t, hogy megbizonyosodjon arról, hogy megfelelően működik?

V: Ha egy webböngészőt az STA URL-re mutat, akkor vagy egy üres fehér oldal jelenik meg, vagy a “405 erőforrás nem engedélyezett.”Ezen eredmények bármelyike működő STA-t jelez. Ilyen módon kapcsolatba léphet az STA-val a biztonságos átjáró-kiszolgáló konzoljáról, valamint az átjáró használatára konfigurált bármely alkalmazás-felsoroló kiszolgálóról. Ha egy hitelesítési párbeszédpanelt kap, amelyben jelszót kér, az STA nem jelenik meg névtelenül, és a hitelesítési követelményeket el kell távolítani.

annak ellenőrzéséhez, hogy az alkalmazásszámláló kiszolgáló sikeresen kér-e STA-jegyeket, nézze meg az általa létrehozott ICA-fájlokat. Például a Web Interface 2.0 alkalmazásban kattintson a jobb gombbal egy közzétett alkalmazás ikonjára, és mentse az eredményt indításkor.ica. Indítás megnyitása.Ica a Jegyzettömbben, és tekintse meg a cím = Sort. A normál biztonságos átjáró működéséhez a Címparaméter egy jegyet tartalmaz a tényleges XenApp Szerver cím helyett.

K: Hogyan értelmezhetem az STA naplófájlokat?

V: Ha engedélyezi a naplózást a LogLevel=3 beállításával a CtxSta – ban.config, látni fogja az egyes jegyek részleteit és az STA által kapott adatkéréseket. Ne feledje, hogy a jegykérelmet egy alkalmazásszámláló kiszolgáló, például a webes felület generálja, az adatkérést pedig a biztonságos átjáró szolgáltatás hajtja végre. Ha a naplófájl több jegykérelmet jelenít meg, de adatkéréseket nem, ez azt jelenti, hogy az alkalmazásszámláló kiszolgáló elérheti az STA-t, de a biztonságos átjárókiszolgáló nem. Ez azt is jelentheti, hogy a felhasználók nem tudják elérni az átjárókiszolgálót.

normál működés közben az ICA kliens munkamenet-megosztási funkciója miatt jegyek kérhetők az STA-tól, de az átjáró soha nem igényelte őket. Vegye figyelembe a következő forgatókönyvet:

• a felhasználó bejelentkezik a webes felületre, és rákattint az Outlook ikonra. A webes felület jegyet kér az STA-tól, és elküldi azt a felhasználónak egy ICA fájlban.
• a felhasználó biztonságos átjárón keresztül csatlakozik, és bemutatja a belépőjegyet. Az átjáró ellenőrzi a jegyet, és lehetővé teszi a felhasználó számára, hogy csatlakozzon egy XenApp kiszolgálóhoz, amely az Outlookot tárolja.
• néhány perc munka után a felhasználó visszatér az alkalmazások listájához a webes felületen, és rákattint az Excel ikonra. A webes felület egy második jegyet kér az STA-tól, és elküldi azt a felhasználónak egy ICA fájlban.
• mielőtt csatlakozna egy új Excel-kiszolgálóhoz, az ICA-ügyfél először ellenőrzi, hogy a meglévő kiszolgálók, amelyekhez az ügyfél már csatlakozik, rendelkeznek-e az Excel közzétett alkalmazással.
• azon a kiszolgálón, amelyen az ügyfél már futtatja az Outlookot, az Excel is telepítve van, így az ICA-ügyfél elveti az ICA-fájlt, és elindítja az Excelt a meglévő ICA-munkameneten belül.
• a webes felület által kért második jegyet soha nem használják, mert nem volt szükség második ICA-munkamenetre. Alapértelmezés szerint a Jegy 100 másodperc után lejár.

ez a forgatókönyv az alábbiakhoz hasonló sta naplófájl-bejegyzések sorozatát eredményezné:

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

a gyanúsabb tevékenység így nézhet ki:

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

itt láthatjuk, hogy egy támadó egyesével próbál különféle jegyeket, minden kísérletnél növeli a jegyazonosítót. Minden esetben a kapcsolatot elutasították, és az STA naplózott egy bejegyzést, amely jelzi, hogy az ügyfél olyan jegyet mutatott be, amelyet nem ismertek érvényesnek. A támadó IP-címének azonosításához keresse meg a következő üzenetet az Eseménynaplóban a biztonságos átjárókiszolgálón:

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

ne értelmezzen néhány” jegy nem található ” üzenetet támadásként. A Win32 Ica kliens megkísérelhet újracsatlakozni egy leválasztott munkamenethez, ha a felhasználó hálózati kapcsolata pillanatnyilag megszakad. Az automatikus ügyfél-újracsatlakozás funkció nem működik a Citrix Secure Gateway felhasználók számára, mert minden újracsatlakozási kísérlet során az Ügyfél újra elküldi a használt STA jegyet, amelyhez eredetileg csatlakozott. Az ügyfél általában háromszor vagy többször próbál újra csatlakozni, mielőtt feladná, így három vagy több “jegy nem található” üzenet jelenik meg, amelyek ugyanarra a jegyre utalnak az STA naplóban a probléma minden előfordulására vonatkozóan. Az ügyfelek újracsatlakozási kísérleteit a korábban sikeres jegy újrafelhasználásának kísérlete jellemzi:

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

válassza le az automatikus kliens újracsatlakozást a biztonságos átjáró felhasználók számára a TransportReconnectEnabled=Off hozzáadásával az ICA fájl szakaszához. A secure Gateway használatakor a leválasztott munkamenethez való újracsatlakozás helyes módja az, ha visszatér az alkalmazásszámláló kiszolgálóra, majd ismét rákattint az alkalmazás ikonjára.

k: melyek a Citrix technikai támogatása által észlelt gyakori konfigurációs hibák?

• a /Scripts mappa vagy a teljes Alapértelmezett webhely le van tiltva az IISLockDown futtatása vagy a webkiszolgálók védelmére vonatkozó vállalati irányelvek betartása miatt.
• a naplózás engedélyezve van a CtxSta-ban.config, de az a felhasználói fiók, amelynek jogosultsága alatt az STA végrehajtja (alapértelmezés szerint iusr_machinename), nem rendelkezik írási hozzáféréssel a naplófájl könyvtárához.
• az STA-kiszolgáló IIS-je úgy van konfigurálva, hogy SSL-t igényeljen, de a Secure Gateway úgy van konfigurálva, hogy normál HTTP-n keresztül érje el az STA-t.
• ha az alkalmazás elindítása sikertelen, először ellenőrizni kell, hogy a StoreFront/Web Interface és a NetScaler Sta-jai pontosan ugyanúgy vannak-e megadva, vagyis ha az STA-k IP-címként vannak megadva az SF/WI-n, akkor az NS IP-címével kell megadni, és hasonlóan az FQDN esetén.