Întrebări frecvente: Citrix Secure Gateway / NetScaler Gateway secure ticket Authority

notă: aceleași principii și concepte sunt valabile și pentru NetScaler Gateway.

acest articol răspunde la câteva întrebări frecvente referitoare la Citrix Secure Ticket Authority (STA). Întrebările sunt împărțite în următoarele patru categorii:

Prezentare generală

Î: Care este autoritatea de bilete sigură?
Î: Ce produse Citrix interacționează cu STA?
Î: De ce este necesar STA?
Î: Cum este implementat serviciul STA?
Î: Există o versiune a STA care nu necesită IIS?
Î: unde locuiește serverul STA?
Î: Care sunt diferențele dintre diferitele versiuni ale STA?

securitate

Î: Cum este generat biletul STA?
Î: ce constituie un bilet STA?
Î: Biletul este validat în raport cu stația de lucru?
Î: Biletul este șters după utilizare?
Î: biletele sunt scrise vreodată pe disc la STA?
Î: Este posibil ca cineva să deturneze un bilet?
Î: Cum protejez traficul STA cu SSL?
Î: Trebuie STA întotdeauna abordate folosind un nume de domeniu complet calificat?
Î: Cum pot schimba portul STA de la 80 la altceva?
Î: poate un atacator să trimită bilete aleatorii la Gateway pentru a se conecta?
Î: Ce alte informații sunt necesare pentru a vă conecta, altele decât un bilet de ședere valid?
Î: Cum putem seta durata de viață a biletului STA, după care biletul ar trebui să fie invalid?

scalabilitate

Î: De câte STAs am nevoie?
Î: Utilizatorii se conectează prin gateway dimineața și rulează o singură aplicație publicată toată ziua sau lansează mai multe aplicații pe parcursul zilei?
Î: Cum pot asigura STA toleranță la erori?
Î: Cum pot încărca echilibru STAs multiple?
Î: Pot folosi mai multe STAs cu Microsoft Network Load Balancing?
Î: Pot partaja un singur STA cu mai multe ferme, gateway-uri și servere de enumerare?

depanarea

Î: Cum ar trebui să fie configurat IIS pentru a găzdui STA?
Î: Cum pot activa logarea la STA?
Î: De ce instrumentul Microsoft IISLockDown rupe STA?
Î: Cum pot testa STA pentru a fi sigur că funcționează corect?
Î: Cum interpretez fișierele jurnal STA?
Î: Care sunt unele dintre erorile comune de configurare văzute de asistența tehnică Citrix?

Prezentare generală

Î: Care este autoritatea de bilete securizată?

A: Autoritatea pentru bilete securizate (STA) este un serviciu Web XML care schimbă informații despre serverul XenApp pentru bilete generate aleatoriu. Este folosit pentru a controla accesul pentru un Server Citrix Secure Gateway.

Î: Ce produse Citrix interacționează cu STA?

A: XenMobile, interfață Web, vitrină, XenApp Secure Access Manager, NetScaler Gateway și Citrix Secure Gateway interacționează cu STA. De-a lungul acestui articol, următoarele tipuri de servere sunt grupate într-o singură categorie numită servere de enumerare a aplicațiilor:

• interfață Web 2.0 sau o versiune ulterioară
• Secure Access Manager 2.0 sau mai târziu
• StoreFront
• serverele de enumerare a aplicațiilor sunt responsabile pentru autentificarea utilizatorilor, enumerarea pictogramelor aplicațiilor publicate și producerea unui fișier ICA pentru un client care le permite să se conecteze la o aplicație publicată printr-un server Gateway securizat.

Î: De ce este necesar STA?

A: în implementările Citrix Secure Gateway, serverul gateway nu efectuează autentificarea cererilor primite. În schimb, serverul gateway amână autentificarea la un server de enumerare a aplicațiilor și folosește STA pentru a garanta că fiecare utilizator este autentificat. Serverele de enumerare a aplicațiilor solicită bilete numai pentru utilizatorii care sunt deja autentificați pe serverul Web. Dacă utilizatorii au bilete STA valide, gateway-ul presupune că au trecut verificările de autentificare la serverul web și ar trebui să li se permită accesul.

acest design permite serverului Citrix Secure Gateway să moștenească orice metodă de autentificare în serverul dvs. web. De exemplu, dacă serverul dvs. de interfață Web este protejat cu RSA SecurID, prin proiectare numai utilizatorii autentificați SecurID pot traversa serverul Gateway securizat.

Î: Cum este implementat serviciul STA?

A: STA este scris ca o extensie ISAPI pentru Microsoft Internet Information Services (IIS). Extensia se numește CtxSta.dll și este găzduit în folderul / Scripts în mod implicit. Alte componente comunica cu STA folosind XML peste HTTP.

serverele de enumerare a aplicațiilor solicită bilete la momentul lansării aplicației, trimițând date către STA ca parte a unei cereri de bilete. Datele trimise către STA includ adresa serverului XenApp la care se va conecta utilizatorul și, în cazul interfeței Web 2.0 și Secure Access Manager 2.0, informații extinse despre numele utilizatorului curent și aplicația publicată pe care utilizatorul dorește să o ruleze. STA răspunde generând un bilet și trimițându-l înapoi la serverul de enumerare a aplicațiilor. Acest bilet și datele sale corespunzătoare rămân în memorie la STA pentru un număr configurabil de secunde (100 implicit).
serverul de enumerare a aplicațiilor construiește un fișier ICA pentru utilizator și introduce biletul STA în câmpul de adresă al fișierului ICA. Când Clientul se conectează la Gateway-ul securizat, biletul este prezentat și gateway-ul ar trebui să valideze biletul înainte de a stabili o sesiune sigură pentru client. Gateway-ul efectuează o cerere de date prin trimiterea biletului înapoi la STA și solicitând datele corespunzătoare în schimb. Dacă este validat cu succes, STA transmite datele originale către gateway și gateway-ul stabilește un releu între utilizatorul final și serverul XenApp.

atât cererile de bilete, cât și cererile de date sunt efectuate ca documente de solicitare/răspuns XML.

Î: există o versiune a STA care nu necesită IIS?

A: nu, în acest moment IIS este necesar pentru a găzdui STA. Amintiți – vă că STA nu trebuie să fie expus la o rețea de încredere, cum ar fi Internetul; STA se află în rețeaua dvs. de încredere și este accesat numai de serverele gateway și de enumerare a aplicațiilor.

Î: unde locuiește serverul STA?

A: serverul STA poate fi plasat oriunde, atâta timp cât Gateway-ul securizat și serverele de enumerare a aplicațiilor pot ajunge la acesta. Citrix recomandă plasarea STA pe rețeaua de încredere sau pe un picior separat al firewall-ului intern, dar nu există cerințe pentru serverul STA, altele decât IIS. STA nu trebuie să aparțină nici unui domeniu, XenApp Server farm, Secure Access Manager farm sau alt server Web intern, dar partajarea STA cu o altă funcție este o practică obișnuită. Un STA este inclus automat ca parte a configurației Secure Access Manager 2.0; mulți administratori consideră că este convenabil să localizeze STA pe un server XenApp.

Î: Care sunt diferențele dintre diferitele versiuni ale STA?

A: nu există diferențe funcționale materiale între versiunile 1.0 și 1.1, dar când se utilizează 2.0 STA cu interfața Web 2.0 sau Secure Access Manager 2.0, informații extinse se adaugă la cererea de bilet: numele utilizatorului și aplicația utilizatorul dorește să ruleze. Aceste date extinse sunt consumate de serviciul gateway pentru a afișa detalii despre fiecare sesiune gateway în consola de administrare Secure Gateway 2.0.

dacă Secure Gateway 2.0 este configurat să utilizeze un STA mai vechi din versiunea 1.1 sau 1.0, utilizatorii se pot conecta la aplicații, dar consola de administrare Secure Gateway va afișa „N/A” pentru numele de utilizator și numele aplicației asociate fiecărei sesiuni ICA. Pentru a vedea informațiile extinse în Gateway-ul securizat 2.0 consola de administrare, trebuie să utilizați versiunea 2.0 sau o versiune ulterioară a STA și să utilizați fie Secure Access Manager 2.0, fie Web Interface 2.0 ca server de enumerare a aplicațiilor.

securitate

Î: Cum este generat biletul STA?

A: extensia ISAPI CtxSta.dll utilizează generarea de numere pseudo-aleatoare pentru a produce un șir hexazecimal de 16 octeți. Din motive de securitate, Citrix nu dezvăluie pașii exacți utilizați pentru a produce această secvență aleatorie de caractere.

Î: ce constituie un bilet STA?

A: formatul de codificare este un șir de formă:

;STA_VERSION; STA_ID; bilet

unde:

• STA_VERSION este un câmp numeric care identifică versiunea STA. În prezent, singurele valori valide pentru acest câmp sunt „10” pentru STA versiunile 1.0 și 1.1 și ” 20 ” pentru STA versiunea 2.0.
• STA_ID este o secvență de 0 – 16 caractere reprezentând un nume arbitrar atribuit de administrator unui anumit STA. În Versiunea 1.X, acest șir implicit STA01, STA02, și așa mai departe. Când STA este instalat automat ca parte a Secure Access Manager 2.0, STA ID-ul este un hash al numelui serverului. Când mai multe STAs sunt partajate de un singur server gateway, fiecare ID STA trebuie să fie unic. Acest lucru permite gateway-ul pentru a localiza STA care a creat biletul și a reveni la faptul că STA pentru validarea biletului. Un bilet creat pe STA01 nu va exista pe STA02.
• TICKET este o secvență generată aleatoriu de 32 de caractere alfabetice sau numerice majuscule.

  de exemplu:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

Î: Biletul este validat în raport cu stația de lucru?

A: nu, nu există nimic care să lege un bilet de o anumită stație de lucru. Teoretic este posibil ca un bilet să fie solicitat de la stația de lucru A și apoi utilizat de la stația de lucru B. Pentru a atenua acest risc:

• utilizați întotdeauna HTTPS între client și serverul de enumerare a aplicațiilor pentru a împiedica un atacator să intercepteze biletul în timp ce călătorește de la server la client.
• reduceți durata de viață a biletului cât mai mult posibil pentru a reduce durata de timp pe care un atacator ar trebui să o transfere de la mașina a la mașina B.

amintiți-vă că un bilet emis de STA poate fi folosit o singură dată, deci dacă utilizatorul intenționat de pe mașina A se conectează cu succes, biletul este invalid pentru toate încercările viitoare de conectare de la mașina a sau mașina B.

Î: Biletul este șters după utilizare?

A: da, biletele sunt curățate imediat după o solicitare de date reușită, astfel încât să poată fi utilizate o singură dată. Acestea sunt, de asemenea, șterse după un time-out configurabil (implicit 100 secunde), dacă nu este utilizat.

Î: biletele sunt scrise vreodată pe disc la STA?

A: Numai atunci când înregistrarea detaliată este activată prin setarea LogLevel=3 în CtxSta.config. În caz contrar, STA menține toate biletele restante (bilete care au fost solicitate de un server de enumerare a aplicațiilor, dar care nu au fost încă validate de un Gateway securizat) folosind o bază de date în memorie. Datele XML sunt întotdeauna trimise la STA folosind comanda HTTP POST, astfel încât nu există date de bilete semnificative este scris vreodată jurnalele STA server web.

Î: Este posibil ca cineva să deturneze un bilet?

A: în timpul funcționării normale, un bilet trebuie să călătorească următoarele patru segmente ale rețelei:

• de la STA la serverul de enumerare a aplicațiilor
• de la serverul de enumerare a aplicațiilor la client
• de la client la serverul de Gateway securizat
• de la gateway la STA

primul și ultimul segment există doar între serverele din DMZ și STA pe serverul de rețea, ceea ce înseamnă că un intrus ar trebui să aibă acces la rețeaua dvs. pentru a intercepta biletul de-a lungul acestor linii. Totuși, aceste căi pot fi criptate cu SSL dacă utilizați Secure Gateway versiunea 2.0. În Citrix Secure Gateway 1.1 și mai devreme, traficul către STA nu poate fi criptat folosind SSL.

pentru a securiza al doilea segment, puneți un certificat pe serverul web de enumerare a aplicațiilor și permiteți clienților să se conecteze numai dacă utilizează HTTPS. Al treilea segment este întotdeauna securizat cu SSL.

chiar și atunci când toate linkurile precedente sunt securizate cu SSL, clienții sunt încă vulnerabili la atacurile programelor troiene care monitorizează activitatea clientului. Pentru a atenua acest risc, sfătuiți utilizatorii să se conecteze de la mașinile în care este instalat software de detectare antivirus și Troian.

Î: Cum protejez traficul STA cu SSL?

A: mai întâi, instalați un certificat de server Web pe copia IIS care găzduiește STA. Pentru mai multe informații, consultați documentația IIS.

Configurați serverul de enumerare a aplicațiilor și serverul de Gateway securizat pentru a utiliza HTTPS atunci când comunicați cu gateway-ul. Când vă conectați prin HTTPS, trebuie respectate întotdeauna următoarele reguli:

• trebuie să vă adresați STA folosind un nume de domeniu complet calificat care se potrivește cu subiectul certificatului de server STA.
• aparatul care comunică cu STA trebuie să poată rezolva numele de domeniu complet calificat STA la o adresă IP adecvată.
• aparatul care comunică cu STA trebuie să aibă încredere în Autoritatea de certificare (CA) care a emis certificatul de server STA.
• pentru a îndeplini cerințele celui de-al treilea element glonț, certificatul rădăcină CA trebuie instalat pe serverul Gateway securizat și pe serverul de enumerare a aplicațiilor. Aveți grijă când instalați certificatul rădăcină: nu puteți pur și simplu să faceți dublu clic pe un fișier certificat rădăcină și să rulați Expertul Import certificat.

(acest lucru indică faptul că contul dvs. de utilizator, Nu serverul sau orice servicii de sistem, are încredere în CA.) Pentru a instala un certificat rădăcină pentru utilizare cu Citrix Secure Gateway sau interfață Web, urmați pașii:

1. rulați Mmc.exe și adăugați snap-in-ul certificatelor.
2. când vi se solicită CE certificate să gestionați, selectați Cont Computer și apoi Computer Local.
3. extindeți certificatele (computerul Local) > Trusted Root Certification Authorities node. Faceți clic dreapta pe certificate și apoi selectați toate activitățile > Import.
4. Răsfoiți pentru a selecta certificatul rădăcină ca și pentru a finaliza Expertul import.

Î: trebuie ca STA să fie întotdeauna abordată folosind un nume de domeniu complet calificat?

A: Dacă intenționați să securizați traficul către STA folosind SSL, orice componentă care accesează STA, inclusiv serverul gateway și serverul de enumerare a aplicațiilor, trebuie să se adreseze STA folosind numele de domeniu complet calificat (FQDN) care se potrivește cu subiectul certificatului de server utilizat de IIS pe STA. De exemplu, în interfața Web 2.0, adresa STA va fi introdusă ca:https://sta-server.company.com/Scripts/CtxSta.dll

dacă alegeți să nu securizați traficul către STA, puteți adresa STA utilizând o adresă IP, un nume de gazdă sau un FQDN.

Î: Cum pot schimba portul STA de la 80 la altceva?

A: deoarece STA este deservit de IIS, schimbați portul STA atunci când schimbați portul IIS. Următorul exemplu ilustrează modul de schimbare a portului IIS de la 80 la 81.

1. Deschideți Managerul de servicii Internet.
2. faceți clic dreapta pe site-ul Web implicit și vizualizați proprietățile.
3. în fila site Web, modificați numărul portului TCP de la 80 la 81.
4. Faceți clic pe OK.
   modificarea precedentă afectează, de asemenea, orice alte resurse pe care le-ați publicat de pe serverul web STA. Dacă doriți să modificați portul de comunicare STA fără a afecta alte pagini web găzduite de același server Web, puteți crea un nou site web în IIS cu unicul scop de a găzdui STA. Următorul este un exemplu de modul în care ar crea un nou site Web pe portul 81 pentru STA.
5. creați un nou folder fizic, cum ar fi C:\MYSTA pe hard disk-ul serverului dvs. Web pentru a servi drept rădăcină de document pentru site-ul STA.
6. creați un subdirector sub Mysta numit Scripts. Mutați următoarele fișiere din STA existente în folderul scripturi noi:
   • CtxSta.DDL
   • CtxSta.config
   • ctxxmlss.txt
7. Deschideți Managerul de servicii Internet.
8. faceți clic dreapta pe numele serverului și selectați Nou > site web.
9. creați un nou site web numit „site-ul meu STA” și C:\MYSTA ca director rădăcină document.
10. Vizualizați proprietățile noului dvs. site web și modificați portul TCP la 81.
11. Sub site-ul meu STA din Internet Services Manager, faceți clic dreapta pe folderul Scripturi și vizualizați proprietățile. În secțiunea Setări aplicație, modificați permisiunile de executare la ” scripturi și executabile.”

Notă: Puteți alege un nume de folder, altele decât „Scripts”, dar să fie conștienți de faptul că Secure Gateway și toate serverele de enumerare aplicare, cum ar fi interfata Web presupune că STA este publicat ca /Scripts/CtxSta.dll deci, va trebui, de asemenea, să actualizați URL-ul STA în setările de pe aceste servere.

Î: poate un atacator să trimită bilete aleatorii la Gateway pentru a se conecta?

A: un atacator ar trebui să ghicească un bilet valid și, de asemenea, să-l răscumpere în câteva milisecunde după ce Clientul îl solicită, dar înainte ca gateway-ul să-l revendice.

Î: Ce alte informații sunt necesare pentru a vă conecta, altele decât un bilet de ședere valabil?

A: Utilizatorii au nevoie, de asemenea, de acreditări de domeniu sau de un bilet de server XenApp solicitat de serverul de enumerare a aplicațiilor. (Un bilet de server XenApp nu este același lucru cu un bilet STA.) Satisfacerea STA deschide o cale numai către rețeaua de încredere pentru un anumit server. Odată ajuns acolo, utilizatorul trebuie să se autentifice în continuare cu acreditări de domeniu valide.
Î: Cum putem seta durata de viață a biletului STA, după care biletul ar trebui să fie invalid?
A: putem seta durata de viață a biletului STA prin crearea unei chei de registry următoare pe controlerul de livrare:
locație: HKLM \ Software \ Citrix \ DesktopServer
nume: Xmlstatyketlifetimeinseconds
Tip: valoare Dword: Dă valoare în secunde (zecimal)
vă rugăm să faceți o copie de rezervă a registrului înainte de a edita valorile registrului, rețineți, de asemenea, că o modificare a registrului ar necesita o repornire la capătul controlerului.

scalabilitate

Î: De câte STAs am nevoie?

A: STA este accesat numai atunci când un utilizator lansează o aplicație, răspunsul la această întrebare variază de la o implementare la alta.

Î: utilizatorii se conectează prin gateway dimineața și rulează o singură aplicație publicată toată ziua sau lansează mai multe aplicații pe parcursul zilei?

A: Sarcinile îndeplinite de STA nu sunt scumpe din punct de vedere al procesorului; este un serviciu XML ușor limitat doar de performanța IIS. Într-un test, un server cu rază mică de acțiune, cu un procesor de 1GHz și 256 MB de memorie RAM, a acceptat peste 250 de cereri de bilete pe secundă, în timp ce utilizarea procesorului a rămas sub 60%.

Î: Cum pot asigura STA toleranță la erori?

A: următoarele servere de enumerare a aplicațiilor vă permit să introduceți mai multe adrese URL STA atunci când configurați parametrii pentru Gateway securizat:

• interfață Web 2.0
• Manager de acces securizat 2.0
• StoreFront

în toate cazurile, dacă un STA nu răspunde, serverul de enumerare a aplicației încearcă un alt STA din listă. La rândul său, fiecare server gateway trebuie configurat cu adresa URL STA și ID-ul STA unic pentru fiecare autoritate de bilete.

Î: Cum pot încărca echilibru STAs multiple?

A: trebuie să se acorde o atenție deosebită atunci când echilibrarea încărcării autoritățile de bilete sigure. O varietate de metode pot fi utilizate pentru a încărca-echilibra conexiunea dintre un server de enumerare a aplicațiilor și STAs, dar un server Gateway securizat trebuie să contacteze întotdeauna fiecare STA individual pe baza ID-ului său STA. Când configurați adresa fiecărui STA în instrumentul de configurare a serviciului gateway, fiecare adresă STA trebuie să fie adresa adevărată a serverului STA — nu introduceți adresa niciunui echilibrator de încărcare hardware, nume de cluster sau nume DNS round-robin aici.

vitrină, interfață Web 2.0 și manager de acces securizat 2.0 toate sprijină echilibrarea încărcării round-robin a STAs atunci când sunt listate mai multe STAs. Când această opțiune este activată, nu este necesar niciun software sau hardware suplimentar de echilibrare a încărcării.

serverele de enumerare a aplicațiilor pot utiliza orice formă de echilibrare a încărcării pentru emiterea unei cereri de bilet, deoarece fiecare bilet primit conține un câmp care indică ID-ul unic al STA care l-a generat. Atâta timp cât fiecare ID STA este unic și toate serverele gateway pot rezolva ID-ul STA la o anumită adresă de server (nu se încarcă echilibrat), operațiunea reușește și traficul STA este încărcat echilibrat.

Î: Pot folosi mai multe STAs cu Microsoft Network Load Balancing?

A: echilibrarea încărcării rețelei nu poate fi utilizată între serverul Gateway securizat și mai multe STAs. Dacă este configurat în acest fel, utilizatorii primesc refuzuri intermitente, deoarece, în timpul procesului de validare a biletului, gateway-ul ar putea fi încărcat echilibrat la o autoritate care nu a generat inițial biletul utilizatorului.

Î: Pot partaja un singur STA cu mai multe ferme, gateway-uri și servere de enumerare?

A: Da, un singur STA poate fi partajat între orice număr de servere Gateway securizate și servere de enumerare a aplicațiilor. STA nu este limitat la un anumit domeniu, fermă sau server de enumerare a aplicațiilor. Este un serviciu XML anonim.

depanarea

Î: Cum ar trebui să fie configurat IIS pentru a găzdui STA?

STA URL-ul /script-uri/CtxSta.dll trebuie să fie servit cu acces anonim activat. Dacă indicați orice browser Web către adresa URL STA, nu vi se va solicita o parolă.

• trebuie să acordați permisiunea scripturilor de resurse și a executabilelor în metabaza IIS. Această permisiune nu este necesară pentru întregul dosar /Scripts, dar poate fi setat pentru CtxSta.fișier dll individual.
• pentru Secure Gateway versiunea 1.1 și versiunile anterioare, nu activați opțiunea necesită SSL și necesită opțiuni SSL pe 128 de biți.
• în mod implicit, sunt necesare următoarele permisiuni de cont:

pe serverele Windows 2000

• contul IUSR_MachineName are nevoie de acces de citire la CtxSta.DDL.
• contul IWAM_MachineName trebuie să modifice accesul la directorul fișierului jurnal, care este \Inetpub\Scripts în mod implicit.

pe serverele Windows 2003

• contul IUSR_MachineName are nevoie de acces de citire la CtxSta.DDL.
• contul de serviciu de rețea încorporat trebuie să modifice accesul la directorul fișierului jurnal, care este \Inetpub\Scripts în mod implicit.

Î: Cum pot activa logarea la STA?

A: folosind Notepad, editați fișierul \Inetpub\Scripts\CtxSta.config pe serverul STA și localizați linia care spune LogLevel = 0. Pentru logare maximă, schimbați acest lucru la LogLevel = 3. Trebuie să reporniți serviciul de publicare World Wide Web pentru ca modificările să aibă efect.
Notă: După ce activați înregistrarea în jurnal, contul de utilizator sub a cărui autoritate se execută STA (IUSR_MachineName pe Windows 2000 sau serviciu de rețea pe Windows 2003 în mod implicit) trebuie să aibă acces de scriere la directorul fișierului jurnal, care este \Inetpub\Scripts în mod implicit. De asemenea, puteți modifica directorul fișierului jurnal Atunci când editați CtxSta.config.

Î: De ce instrumentul Microsoft IISLockDown rupe STA?

A: Dacă acceptați toate setările implicite pentru instrumentul IISLockDown, folderul / Scripts este dezactivat. STA este implementat ca un filtru ISAPI publicat ca /Scripts/CtxSta.dll; prin dezactivarea directorului / Scripts, refuzați accesul la STA. Activați folderul / Scripts și permiteți accesul Scripturilor și executabilelor pentru ca STA să funcționeze.

Î: Cum pot testa STA pentru a fi sigur că funcționează corect?

A: dacă indicați un browser Web către adresa URL STA, veți vedea fie o pagină albă goală, fie mesajul „405 Resource Not Allowed.”Oricare dintre aceste rezultate indică o STA funcțională. Puteți contacta STA în acest mod de la consola serverului Gateway securizat și, de asemenea, de la orice server de enumerare a aplicațiilor configurat să utilizeze gateway-ul. Dacă primiți o casetă de dialog de autentificare care vă solicită o parolă, STA nu este publicată anonim și cerințele de autentificare trebuie eliminate.

pentru a verifica dacă serverul de enumerare a aplicațiilor solicită cu succes bilete STA, consultați fișierele ICA pe care le generează. De exemplu, din interfața Web 2.0, puteți face clic dreapta pe o pictogramă a aplicației publicate și puteți salva rezultatul ca lansare.ica. Deschide lansarea.ica în Notepad și vizualizați adresa = linie. Pentru funcționarea normală a Gateway-ului securizat, parametrul adresă va conține un bilet în loc de o adresă reală a serverului XenApp.

Î: Cum interpretez fișierele jurnal STA?

A: Dacă activați înregistrarea prin setarea LogLevel=3 în CtxSta.config, veți vedea detalii despre fiecare bilet și cererea de date primite de STA. Rețineți că o cerere de bilet este generată de un server de enumerare a aplicațiilor, cum ar fi interfața Web, iar o solicitare de date este efectuată de serviciul Secure Gateway. Dacă fișierul jurnal arată mai multe cereri de bilete, dar nu există cereri de date, Acest lucru implică faptul că serverul de enumerare a aplicațiilor poate ajunge la STA, dar serverul Gateway securizat nu poate. De asemenea, poate implica faptul că utilizatorii nu pot ajunge la serverul gateway.

în timpul funcționării normale, caracteristica de partajare a sesiunii clientului ICA poate provoca solicitarea biletelor de la STA, dar niciodată revendicată de gateway. Luați în considerare următorul scenariu:

• un utilizator se conectează la interfața Web și face clic pe pictograma Outlook. Interfața Web solicită un bilet de la STA și îl trimite utilizatorului într-un fișier ICA.
• utilizatorul se conectează prin Gateway securizat și prezintă biletul de intrare. Gateway-ul validează biletul și permite utilizatorului să se conecteze la un server XenApp care găzduiește Outlook.
• după ce a lucrat câteva minute, utilizatorul revine la lista de aplicații de pe pagina interfeței Web și face clic pe pictograma Excel. Interfața Web solicită un al doilea bilet de la STA și îl trimite utilizatorului într-un fișier ICA.
• înainte de a vă conecta la un server nou pentru Excel, clientul ICA verifică mai întâi dacă serverele existente la care Clientul este deja conectat au aplicația publicată Excel disponibilă.
• serverul în care clientul rulează deja Outlook are, de asemenea, instalat Excel, astfel încât clientul ICA aruncă fișierul ICA și pornește Excel în cadrul sesiunii ICA existente.
• al doilea bilet solicitat de interfața Web nu este niciodată folosit, deoarece o a doua sesiune ICA nu a fost necesară. În mod implicit, biletul expiră după 100 de secunde.

acest scenariu ar avea ca rezultat o serie de intrări de fișiere jurnal STA similare cu următoarele:

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

o activitate mai suspectă ar putea arăta cam așa:

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

aici vedem ceea ce pare a fi un atacator care încearcă diferite bilete pe rând, incrementând ID-ul biletului cu fiecare încercare. În fiecare caz, conexiunea a fost respinsă și STA a înregistrat o intrare care indică faptul că clientul a prezentat un bilet care nu a fost recunoscut ca valid. Pentru a identifica adresa IP a atacatorului, căutați următorul mesaj în vizualizatorul de evenimente de pe serverul Secure Gateway:

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

nu interpretați unele mesaje „bilet nu a fost găsit” ca un atac. Clientul Win32 ICA poate încerca să se reconecteze la o sesiune deconectată dacă conexiunea de rețea a utilizatorului este abandonată momentan. Funcția de reconectare automată a Clientului nu funcționează pentru utilizatorii Citrix Secure Gateway, deoarece în timpul fiecărei încercări de reconectare, clientul retrimite biletul STA folosit cu care s-a conectat inițial. Clientul încearcă de obicei să se reconecteze de trei sau mai multe ori înainte de a renunța, astfel încât veți vedea trei sau mai multe mesaje „Ticket NOT found” care fac referire la același bilet în Jurnalul STA pentru fiecare apariție a acestei probleme. Încercările de reconectare a clienților se caracterizează prin încercarea de reutilizare a unui bilet de succes anterior:

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

deconectați reconectarea automată a clientului pentru utilizatorii Secure Gateway adăugând TransportReconnectEnabled = Off la secțiunea fișierului ICA. Modul corect de a vă reconecta la o sesiune deconectată atunci când utilizați Secure Gateway este să reveniți la serverul de enumerare a aplicațiilor și să faceți clic din nou pe pictograma aplicației.

Î: Care sunt unele dintre erorile comune de configurare văzute de suportul tehnic Citrix?

• folderul /Scripts sau întregul site web implicit este dezactivat ca urmare a rulării IISLockDown sau a respectării politicii companiei pentru protejarea serverelor Web.
• înregistrarea în jurnal este activată în CtxSta.config, dar contul de utilizator sub a cărui autoritate se execută STA (iusr_machinename implicit) nu are acces la scriere în directorul fișierului jurnal.
• IIS pe serverul STA este configurat să solicite SSL, dar Secure Gateway sunt configurate pentru a accesa STA folosind HTTP normal.
• dacă lansarea aplicației eșuează, primul lucru care trebuie verificat este dacă STAs pe interfața Magazinului/Web și NetScaler sunt date exact în același mod sau nu, adică dacă STAs sunt date ca adresă IP pe SF/WI, ar trebui să fie date folosind adresa IP pe NS și în mod similar în cazul FQDN.