Vanliga frågor: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

Obs: samma principer och koncept gäller även för NetScaler Gateway.

den här artikeln svarar på några vanliga frågor om Citrix Secure Ticket Authority (STA). Frågorna är indelade i följande fyra kategorier:

översikt

F: Vad är Secure Ticket Authority?
f: vilka Citrix-produkter interagerar med STA?
f: Varför är STA nödvändigt?
F: Hur implementeras STA-tjänsten?
Q: Finns det en version av STA som inte kräver IIS?
F: Var bor STA-servern?
f: vilka är skillnaderna mellan olika versioner av STA?

säkerhet

F: hur genereras sta-biljetten?
F: Vad utgör en sta-biljett?
F: är biljetten validerad mot arbetsstationen?
f: raderas biljetten efter användning?
F: är biljetter någonsin skrivna till Disk på STA?
F: är det möjligt för någon att kapa en biljett?
F: Hur skyddar jag STA-trafiken med SSL?
Q: Måste STA alltid adresseras med ett fullt kvalificerat domännamn?
F: Hur ändrar jag sta-porten från 80 till något annat?
F: kan en angripare skicka slumpmässiga biljetter till porten för att logga in?
F: Vilken annan information krävs för att logga in än en giltig STA-biljett?
F: Hur kan vi ställa in livstiden för STA-biljetten, varefter biljetten ska vara ogiltig?

skalbarhet

F: hur många STAs behöver jag?
Q: Loggar användarna in via gatewayen på morgonen och kör en enda publicerad applikation hela dagen eller startar de flera applikationer under hela dagen?
F: Hur kan jag säkerställa sta feltolerans?
F: Hur laddar jag balans flera STAs?
F: Kan jag använda flera STAs med Microsoft Network Load Balancing?
F: Kan jag dela en enda STA med flera gårdar, Gateways och Uppräkningsservrar?

felsökning

F: Hur ska IIS konfigureras för att vara värd för STA?
F: Hur aktiverar jag loggning på STA?
Q: Varför bryter Microsoft IISLockDown-verktyget STA?
F: Hur kan jag testa STA för att vara säker på att den fungerar korrekt?
F: Hur tolkar jag STA-loggfilerna?
f: vilka är några av de vanliga konfigurationsfel som ses av Citrix tekniska Support?

översikt

F: Vad är Secure Ticket Authority?

A: Secure Ticket Authority (STA) är en XML-webbtjänst som utbyter XenApp-serverinformation för slumpmässigt genererade biljetter. Den används för att styra åtkomst för en Citrix Secure Gateway-server.

f: vilka Citrix-produkter interagerar med STA?

A: XenMobile, webbgränssnitt, StoreFront, XenApp Secure Access Manager, NetScaler Gateway och Citrix Secure Gateway interagerar med STA. I hela den här artikeln grupperas följande typer av servrar i en enda kategori som heter application enumeration servers:

• webbgränssnitt 2.0 eller senare
• Secure Access Manager 2.0 eller senare
• StoreFront
• Application enumeration servers är ansvariga för att autentisera användare, räkna upp publicerade programikoner och producera en ICA-fil för en klient som tillåter dem att ansluta till en publicerad applikation via en säker Gateway-server.

f: Varför är STA nödvändigt?

A: i Citrix Secure Gateway-distributioner utför gateway-servern inte autentisering av inkommande förfrågningar. I stället skickar gateway-servern autentisering till en programuppräkningsserver och använder STA för att garantera att varje användare är autentiserad. Program uppräkningsservrar begär endast biljetter för användare som redan är autentiserade till webbservern. Om användare har giltiga sta-biljetter antar gatewayen att de passerade autentiseringskontrollerna på webbservern och bör tillåtas åtkomst.

denna design gör det möjligt för Citrix Secure Gateway-servern att ärva alla autentiseringsmetoder i din webbserver. Till exempel, om din Webbgränssnittsserver är skyddad med RSA SecurID, kan endast SecurID-autentiserade användare genom design korsa Secure Gateway-servern.

F: Hur implementeras STA-tjänsten?

A: STA är skrivet som ett ISAPI-tillägg för Microsoft Internet Information Services (IIS). Förlängningen kallas CtxSta.dll och är värd i mappen / Scripts som standard. Andra komponenter kommunicerar med STA med hjälp av XML över HTTP.

Application enumeration servers begär biljetter vid programmets starttid genom att skicka data till STA som en del av en biljettförfrågan. Uppgifterna som skickas till STA inkluderar adressen till XenApp-servern som användaren kommer att ansluta till och, när det gäller Web Interface 2.0 och Secure Access Manager 2.0, utökad information om namnet på den aktuella användaren och den publicerade applikationen som användaren vill köra. STA svarar genom att generera en biljett och skicka den tillbaka till application enumeration server. Denna biljett och dess motsvarande data förblir i minnet vid STA under ett konfigurerbart antal sekunder (100 som standard).
application enumeration server konstruerar en ICA-fil för användaren och infogar STA-biljetten i adressfältet i Ica-filen. När klienten ansluter till den säkra gatewayen presenteras biljetten och gatewayen bör validera biljetten innan en säker session upprättas för klienten. Gatewayen utför en dataförfrågan genom att skicka biljetten tillbaka till STA och be om motsvarande data i gengäld. Om den validerats framgångsrikt vidarebefordrar STA originaldata till gatewayen och gatewayen etablerar ett relä mellan slutanvändaren och XenApp-servern.

både biljettförfrågningar och dataförfrågningar utförs som XML-begäran/svarsdokument.

f: finns det en version av STA som inte kräver IIS?

A: Nej, vid denna tidpunkt krävs IIS för att vara värd för STA. Kom ihåg att STA inte behöver utsättas för ett otillförlitligt nätverk som Internet; STA finns på ditt betrodda nätverk och nås endast av gateway-och applikationsräkningsservrarna.

F: Var bor STA-servern?

A: sta-servern kan placeras var som helst så länge den säkra gatewayen och applikationsräkningsservrarna kan nå den. Citrix rekommenderar att du placerar STA på det betrodda nätverket eller på en separat del av din interna brandvägg, men det finns inga krav för STA-servern än IIS. STA behöver inte tillhöra någon domän, XenApp Server farm, Secure Access Manager farm eller annan intern webbserver, men att dela STA med en annan funktion är vanligt. En STA ingår automatiskt som en del av Secure Access Manager 2.0 setup; många administratörer tycker att det är bekvämt att hitta STA på en XenApp-server.

f: vilka är skillnaderna mellan olika versioner av STA?

A: Det finns inga väsentliga funktionella skillnader mellan versioner 1.0 och 1.1, men när du använder 2.0 STA med webbgränssnitt 2.0 eller Secure Access Manager 2.0, utökad information läggs till biljettförfrågan: användarens namn och applikationen som användaren vill köra. Denna utökade data förbrukas av gateway-tjänsten för att visa information om varje gateway-session i Secure Gateway 2.0-hanteringskonsolen.

om Secure Gateway 2.0 är konfigurerad att använda en äldre STA från Version 1.1 eller 1.0, kan användare ansluta till program men Secure Gateway management console visar ”N/A” för användarnamnet och applikationsnamnet som är associerat med varje ICA-session. För att se den utökade informationen i Secure Gateway 2.0 Management console, måste du använda Version 2.0 eller senare av STA och använda antingen Secure Access Manager 2.0 eller Web Interface 2.0 som din ansökan uppräkning server.

säkerhet

F: hur genereras sta-biljetten?

A: ISAPI-förlängningen CtxSta.dll använder pseudoslumptalsgenerering för att producera en 16-byte hexadecimal sträng. Av säkerhetsskäl avslöjar Citrix inte de exakta stegen som används för att producera denna slumpmässiga sekvens av tecken.

F: Vad utgör en sta-biljett?

A: kodningsformatet är en sträng av formen:

;STA_VERSION; STA_ID; biljett

var:

• STA_VERSION är ett numeriskt fält som identifierar versionen av STA. För närvarande är de enda giltiga värdena för detta fält ”10 ”för sta-versionerna 1.0 och 1.1 och” 20 ” för STA-Version 2.0.
• STA_ID är en sekvens av 0 – 16 tecken som representerar ett godtyckligt namn som tilldelats av administratören till en viss STA. I Version 1.X, den här strängen är som standard STA01, STA02 och så vidare. När STA installeras automatiskt som en del av Secure Access Manager 2.0 är STA-ID en hash av servernamnet. När flera STAs delas av en enda gateway-server måste varje STA-ID vara unikt. Detta gör det möjligt för porten att hitta STA som skapade biljetten och återgå till den STA för biljettvalidering. En biljett Skapad på STA01 kommer inte att finnas på STA02.
• TICKET är en slumpmässigt genererad sekvens av 32 stora bokstäver eller numeriska tecken.

  till exempel:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

F: är biljetten validerad mot arbetsstationen?

A: Nej, det finns inget som binder en biljett till en viss arbetsstation. Det är teoretiskt möjligt för en biljett att begäras från arbetsstation A och sedan användas från arbetsstation B. För att mildra denna risk:

• använd alltid HTTPS mellan klienten och application enumeration server för att förhindra att en angripare avlyssnar biljetten när den reser från server till klient.
• minska ticket time-to-live så mycket som möjligt för att minska den tid en angripare skulle behöva överföra biljetten från maskin A till maskin B.

kom ihåg att en biljett som utfärdats av STA endast kan användas en gång, så om den avsedda användaren på maskin A ansluter framgångsrikt är biljetten ogiltig för alla framtida anslutningsförsök från maskin A eller maskin B.

f: raderas biljetten efter användning?

A: ja, biljetter rensas omedelbart efter en lyckad dataförfrågan så att de bara kan användas en gång. De raderas också efter en konfigurerbar timeout (Standard 100 sekunder) om de inte används.

F: är biljetter någonsin skrivna till Disk på STA?

A: Endast när verbose loggning är aktiverad genom att ställa LogLevel = 3 i CtxSta.konfiguration. I annat fall behåller STA alla utestående biljetter (biljetter som begärdes av en applikationsräkningsserver men ännu inte validerats av en säker Gateway) med en databas i minnet. XML-data skickas alltid till STA med HTTP POST-kommandot, så ingen meningsfull biljettdata skrivs någonsin till sta-Webbserverloggarna.

F: är det möjligt för någon att kapa en biljett?

A: under normal drift måste en biljett resa följande fyra segment av nätverket:

• från Sta till Application enumeration server
• från application enumeration server till klienten
• från klienten till Secure Gateway server
• från porten till STA

de första och sista segmenten finns bara mellan servrar i din DMZ och STA på din betrodda server nätverk, vilket innebär att en inkräktare skulle behöva ha tillgång till ditt nätverk för att fånga biljetten längs dessa linjer. Ändå kan dessa vägar krypteras med SSL om du använder Secure Gateway Version 2.0. I Citrix Secure Gateway 1.1 och tidigare kan trafik till STA inte krypteras med SSL.

för att säkra det andra segmentet, sätta ett certifikat på din ansökan uppräkning webbserver och tillåta klienter att ansluta endast om de använder HTTPS. Det tredje segmentet är alltid säkrat med SSL.

även när alla föregående länkar är säkrade med SSL är klienter fortfarande sårbara för attacker av trojanska program som övervakar klientaktivitet. För att mildra denna risk, råda dina användare att ansluta från maskiner där anti-virus och Trojan upptäckt programvara är installerad.

F: Hur skyddar jag sta-trafiken med SSL?

A: installera först ett Webbservercertifikat på kopian av IIS som är värd för STA. Mer information finns i IIS-dokumentationen.

konfigurera din application enumeration server och Secure Gateway server för att använda HTTPS när du kommunicerar med gatewayen. Vid anslutning via HTTPS måste följande regler alltid uppfyllas:

• du måste adressera STA med ett fullständigt kvalificerat domännamn som matchar ämnet för sta-servercertifikatet.
• maskinen som kommunicerar med STA måste kunna lösa sta-fullständigt kvalificerat domännamn till en lämplig IP-adress.
• maskinen som kommunicerar med STA måste lita på certifikatutfärdaren (CA) som utfärdade sta-servercertifikatet.
• för att uppfylla kraven i det tredje punktobjektet måste ca-rotcertifikatet installeras på Secure Gateway-servern och på application enumeration-servern. Var försiktig när du installerar rotcertifikatet: du kan inte bara dubbelklicka på en rotcertifikatfil och köra certifikatimportguiden.

(om du gör det indikerar att ditt användarkonto, inte servern eller några systemtjänster, litar på CA.) För att installera ett rotcertifikat för användning med Citrix Secure Gateway eller webbgränssnitt, följ stegen:

1. kör Mmc.exe och Lägg till snapin-modulen certifikat.
2. när du blir frågad vilka certifikat som ska hanteras väljer du datorkonto och sedan lokal dator.
3. expandera noden certifikat (lokal dator) > Betrodda rotcertifikatutfärdare. Högerklicka på certifikat och välj sedan alla aktiviteter > importera.
4. Bläddra för att välja ditt CA-rotcertifikat och slutföra importguiden.

f: måste STA alltid adresseras med ett fullständigt kvalificerat domännamn?

A: om du har för avsikt att säkra trafik till STA med SSL måste alla komponenter som har åtkomst till STA, inklusive din gateway-server och application enumeration server, adressera STA med det fullständigt kvalificerade domännamnet (FQDN) som matchar ämnet för servercertifikatet som används av IIS på STA. Till exempel, i Web Interface 2.0, skulle STA-adressen anges som:https://sta-server.company.com/Scripts/CtxSta.dll

om du väljer att inte säkra trafik till STA kan du adressera STA med en IP-adress, värdnamn eller FQDN.

F: Hur ändrar jag sta-porten från 80 till något annat?

A: eftersom STA betjänas av IIS ändrar du STA-porten när du ändrar IIS-porten. Följande exempel illustrerar hur du ändrar IIS-porten från 80 till 81.

1. öppna Internet Services Manager.
2. högerklicka på Standardwebbplats och visa egenskaperna.
3. på fliken webbplats ändrar du TCP-portnumret från 80 till 81.
4. klicka på OK.
   den föregående ändringen påverkar även andra resurser som du har publicerat från Sta-webbservern. Om du vill ändra sta-kommunikationsporten utan att påverka andra webbsidor som är värd för samma webbserver kan du skapa en ny webbplats i IIS med det enda syftet att vara värd för STA. Följande är ett exempel på hur du skulle skapa en ny webbplats på port 81 för STA.
5. skapa en ny fysisk mapp som C:\ MYSTA på din webbservers hårddisk för att fungera som dokumentroten för STA-webbplatsen.
6. skapa en underkatalog under MYSTA som heter Scripts. Flytta följande filer från din befintliga STA till mappen nya skript:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. öppna Internet Services Manager.
8. högerklicka på servernamnet och välj Ny > webbplats.
9. skapa en ny webbplats som heter ”My STA site” och C:\MYSTA som dokumentets rotkatalog.
10. visa egenskaperna för din nya webbplats och ändra TCP-porten till 81.
11. under min sta-webbplats i Internet Services Manager högerklickar du på mappen Scripts och visar egenskaperna. I avsnittet programinställningar ändrar du Körbehörigheterna till ” skript och körbara filer.”

Obs: Du kan välja ett annat mappnamn än ”Scripts” men tänk på att Secure Gateway och alla program uppräkningsservrar som webbgränssnitt antar att STA publiceras som /Scripts/CtxSta.dll så du kommer också att behöva uppdatera sta URL i inställningarna på dessa servrar.

F: kan en angripare skicka slumpmässiga biljetter till porten för att logga in?

A: en angripare måste gissa en giltig biljett och även lösa in den inom några millisekunder efter att klienten begär det men innan gatewayen hävdar det.

F: Vilken annan information krävs för att logga in än en giltig STA-biljett?

A: användare behöver också domänuppgifter eller en XenApp-Serverbiljett som begärs av application enumeration server. (En XenApp Server biljett är inte samma sak som en STA biljett.) Att uppfylla STA öppnar en sökväg endast till det betrodda nätverket för en viss server. En gång där måste användaren fortfarande autentisera med giltiga domänuppgifter.
F: Hur kan vi ställa in livstiden för STA-biljetten, varefter biljetten ska vara ogiltig?
A: vi kan ställa in Sta-biljettlivslängden genom att skapa en följande registernyckel på Leveranskontrollen:
plats: HKLM \ Software \ Citrix \ DesktopServer
namn: XmlStaTicketLifetimeInSeconds
Typ: DWORD-värde: Ge värde i sekunder (Decimal)
ta en säkerhetskopia av registret innan du redigerar registervärden, Observera också att en registerändring skulle kräva en omstart på Kontrolleränden.

skalbarhet

F: hur många STAs behöver jag?

A: STA nås endast när en användare startar ett program, svaret på denna fråga varierar från en distribution till nästa.

f: loggar användare in via gatewayen på morgonen och kör en enda publicerad applikation hela dagen eller startar de flera applikationer under dagen?

A: De uppgifter som utförs av STA är inte dyra i CPU-termer; det är en lätt XML-tjänst som endast begränsas av IIS-prestanda. I ett test stödde en lågdistansserver med en 1 GHz-processor och 256 MB RAM över 250 biljettförfrågningar per sekund medan CPU-användningen stannade under 60%.

F: Hur kan jag säkerställa sta feltolerans?

A: följande program uppräkning servrar alla kan du ange flera STA webbadresser när du konfigurerar parametrarna för Secure Gateway:

• webbgränssnitt 2.0
• säker Åtkomsthanterare 2.0
• StoreFront

i alla fall, om en STA inte svarar, försöker application enumeration server en annan STA på listan. Varje gateway-server måste i sin tur konfigureras med STA-URL och unikt STA-ID för varje biljettmyndighet.

F: Hur laddar jag balans flera STAs?

A: särskild försiktighet måste vidtas vid lastbalansering säkra Biljettmyndigheter. En mängd olika metoder kan användas för att belastningsbalansera anslutningen mellan en applikationsräkningsserver och STAs, men en säker Gateway-server måste alltid kontakta varje STA individuellt baserat på dess STA-ID. När du konfigurerar adressen för varje STA i konfigurationsverktyget för gateway-tjänsten måste varje STA-adress vara den sanna adressen för STA-servern-ange inte adressen till någon hårdvarubelastningsbalans, klusternamn eller Round-robin DNS-namn här.

skyltfönster, webbgränssnitt 2.0 och Secure Access Manager 2.0 allt stöd round-robin lastbalansering av STAs när flera STAs listas. När det här alternativet är aktiverat krävs ingen ytterligare lastbalanseringsprogramvara eller maskinvara.

Application enumeration servers kan använda någon form av lastbalansering för att utfärda en biljett begäran eftersom varje mottagen biljett innehåller ett fält som anger det unika ID för STA som genererade det. Så länge varje STA-ID är unikt och alla gateway-servrar kan lösa STA-ID till en viss (inte belastningsbalanserad) serveradress, lyckas operationen och STA-trafiken belastas.

Q: Kan jag använda flera STAs med Microsoft Network Load Balancing?

A: nätverksbelastningsbalansering kan inte användas mellan Secure Gateway-servern och flera STAs. Om konfigureras på detta sätt, användare får intermittenta avslag eftersom, under biljett valideringsprocessen, gatewayen kan belastas till en myndighet som inte ursprungligen generera användarens biljett.

F: Kan jag dela en enda STA med flera gårdar, Gateways och Uppräkningsservrar?

A: Ja, en enda STA kan delas mellan valfritt antal säkra Gateway-servrar och program uppräkningsservrar. STA är inte begränsat till någon särskild domän, gård, eller program uppräkning server. Det är en anonym XML-tjänst.

felsökning

F: Hur ska IIS konfigureras för att vara värd för STA?

sta URL/skript / CtxSta.dll måste serveras med anonym åtkomst aktiverad. Om du pekar någon webbläsare till STA URL du inte kommer att bli tillfrågad om ett lösenord.

• du måste ge behörighet för Resursskript och körbara filer i IIS-metabasen. Denna behörighet behövs inte för hela / Scripts-mappen men kan ställas in för CtxSta.dll-fil individuellt.
• för Secure Gateway Version 1.1 och tidigare, aktivera inte Require SSL och Kräv 128-bitars SSL-alternativ.
• som standard behövs följande kontobehörigheter:

på Windows 2000-servrar

• iusr_machinename-kontot behöver läsåtkomst till CtxSta.DLL.
• iwam_machinename-kontot behöver ändra åtkomst till loggfilskatalogen, som är \Inetpub\Scripts som standard.

på Windows 2003-servrar

• kontot iusr_machinename behöver läsåtkomst till CtxSta.DLL.
• det inbyggda Nätverkstjänstkontot behöver ändra åtkomst till loggfilkatalogen, som är \Inetpub\Scripts som standard.

F: Hur aktiverar jag loggning på STA?

A: redigera filen \Inetpub\Scripts\CtxSta med anteckningsblock.konfigurera på sta-servern och leta reda på raden som säger LogLevel = 0. För maximal loggning, ändra detta till LogLevel = 3. Du måste starta om World Wide Web Publishing Service för att ändringarna ska träda i kraft.
Obs! När du har aktiverat loggning måste användarkontot under vars behörighet STA körs (IUSR_MachineName på Windows 2000 eller Network Service på Windows 2003 som standard) ha skrivåtkomst till loggfilskatalogen, som är \Inetpub\Scripts som standard. Du kan också ändra loggfilkatalogen när du redigerar CtxSta.konfiguration.

f: Varför bryter Microsoft IISLockDown-verktyget STA?

A: Om du accepterar alla standardinställningar för IISLockDown-verktyget är mappen /Scripts inaktiverad. STA implementeras som ett ISAPI-filter publicerat som /Scripts/CtxSta.dll; genom att inaktivera katalogen / Scripts nekar du åtkomst till STA. Aktivera mappen / Scripts och Tillåt åtkomst till skript och körbara filer för att STA ska fungera.

F: Hur kan jag testa STA för att vara säker på att den fungerar korrekt?

A: om du pekar en webbläsare på sta-webbadressen ser du antingen en tom vit sida eller meddelandet ”405-resurs tillåts inte.”Något av dessa resultat indikerar en fungerande STA. Du kan kontakta STA på detta sätt från konsolen på din Secure Gateway server och även från alla program uppräkning server konfigurerad för att använda gateway. Om du får en dialogruta för autentisering som uppmanar dig att ange ett lösenord, publiceras inte STA anonymt och autentiseringskraven måste tas bort.

för att verifiera att programuppräkningsservern framgångsrikt begär STA-biljetter, titta på de Ica-filer som den genererar. Från Web Interface 2.0 kan du till exempel högerklicka på en publicerad programikon och spara resultatet som start.ica. Öppna lanseringen.Ica i anteckningsblock och visa adressen= rad. För normal säker Gateway-drift innehåller adressparametern en biljett istället för en faktisk XenApp-serveradress.

F: Hur tolkar jag sta-loggfilerna?

A: om du aktiverar loggning genom att ställa LogLevel = 3 i CtxSta.config, du kommer att se detaljer om varje biljett och dataförfrågan mottagen av STA. Kom ihåg att en biljett begäran genereras av en ansökan uppräkning server som webbgränssnitt, och en dataförfrågan utförs av Secure Gateway tjänsten. Om loggfilen visar flera biljettförfrågningar men inga dataförfrågningar, innebär detta att programuppräkningsservern kan nå STA men den säkra Gateway-servern kan inte. Det kan också innebära att användare inte kan nå gateway-servern.

under normal drift kan sessionsdelningsfunktionen i Ica-klienten göra att biljetter begärs från STA men aldrig begärs av gatewayen. Tänk på följande scenario:

• en användare loggar in på webbgränssnittet och klickar på Outlook-ikonen. Webbgränssnittet begär en biljett från STA och skickar den till användaren i en ICA-fil.
• användaren ansluter via Secure Gateway och presenterar biljetten för antagning. Gatewayen validerar biljetten och låter användaren ansluta till en XenApp-Server som är värd för Outlook.
• efter att ha arbetat i några minuter återgår användaren till programlistan på Webbgränssnittssidan och klickar på Excel-ikonen. Webbgränssnittet begär en andra biljett från STA och skickar den till användaren i en ICA-fil.
• innan du ansluter till en ny server för Excel kontrollerar Ica-klienten först om några befintliga servrar som klienten redan är ansluten till har Excel published-programmet tillgängligt.
• servern där klienten redan kör Outlook har också Excel installerat, så Ica-klienten kasserar ICA-filen och startar Excel inom den befintliga ICA-sessionen.
• den andra biljetten som begärs av webbgränssnittet används aldrig eftersom en andra ICA-session inte var nödvändig. Som standard tickar biljetten ut efter 100 sekunder.

detta scenario skulle resultera i en serie sta-loggfilposter som liknar följande:

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

mer misstänkt aktivitet kan se ut så här:

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

här ser vi vad som verkar vara en angripare som försöker olika biljetter en i taget och ökar biljett-ID med varje försök. I varje fall avvisades anslutningen och STA loggade en post som indikerar att klienten presenterade en biljett som inte erkändes som giltig. För att identifiera angriparens IP-adress, leta efter följande meddelande i loggboken på den säkra Gateway-servern:

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

tolka inte några” Ticket NOT found ” – meddelanden som en attack. Win32 Ica-klienten kan försöka återansluta till en frånkopplad session om användarens nätverksanslutning tappas tillfälligt. Funktionen Auto Client Reconnect fungerar inte för Citrix Secure Gateway-användare eftersom klienten skickar in den använda sta-biljetten som den ursprungligen anslöt till under varje återanslutningsförsök. Klienten försöker vanligtvis att återansluta tre eller flera gånger innan du ger upp, så du kommer att se tre eller fler ”Ticket NOT found” – meddelanden som refererar till samma biljett i STA-loggen för varje förekomst av detta problem. Klientåterkopplingsförsök kännetecknas av försök till återanvändning av en tidigare framgångsrik biljett:

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

koppla bort Auto Client Reconnect för Secure Gateway-användare genom att lägga till TransportReconnectEnabled=Off i avsnittet i Ica-filen. Det rätta sättet att återansluta till en frånkopplad session när du använder Secure Gateway är att återgå till application enumeration server och klicka på programikonen igen.

f: vilka är några av de vanliga konfigurationsfel som ses av Citrix tekniska Support?

• mappen /Scripts eller hela standardwebbplatsen är inaktiverad som ett resultat av att IISLockDown körs eller följer företagets policy för att skydda webbservrar.
• loggning är aktiverad i CtxSta.config, men användarkontot under vars auktoritet STA körs (iusr_machinename som standard) har inte skrivåtkomst till loggfilskatalogen.
• IIS på sta-servern är konfigurerad för att kräva SSL, men Secure Gateway är konfigurerad för att komma åt STA med normal HTTP.
• om applanseringen misslyckas är det första som ska kontrolleras om STAs på StoreFront/Web Interface och NetScaler ges på exakt samma sätt eller inte, dvs om STAs ges som IP-adress på SF/WI ska den ges med IP-adress på NS och på liknande sätt vid FQDN.