Usein kysytyt kysymykset: Citrix Secure Gateway/ NetScaler Gateway Secure Ticket Authority

Huom: samat periaatteet ja käsitteet pätevät myös NetScaler Gatewayssa.

tämä artikkeli vastaa joihinkin Citrix Secure Ticket Authorityn (STA) usein kysyttyihin kysymyksiin. Kysymykset on jaettu seuraaviin neljään kategoriaan:

yleiskatsaus

Q: Mikä on turvallinen Lippuviranomainen?
K: mitkä Citrix-tuotteet ovat vuorovaikutuksessa STA: n kanssa?
K: Miksi STA on tarpeen?
K: Miten STA-palvelu toteutetaan?
K: Onko STA olemassa versiota, joka ei vaadi IIS: ää?
K: Missä STA-palvelin sijaitsee?
K: mitkä ovat STA: n eri versioiden väliset erot?

turvallisuus

K: Miten STA-lippu syntyy?
K: Mikä on STA-lippu?
Q: Onko lippu vahvistettu työpistettä vasten?
Q: poistetaanko lippu käytön jälkeen?
K: kirjoitetaanko lippuja koskaan levylle STA?
K:Voiko joku kaapata lipun?
kysymys: Miten voin suojata STA-liikennettä SSL: llä?
K: Täytyykö henkilöstöä aina puhutella täysin pätevällä verkkotunnuksella?
Q: Miten voin muuttaa STA portin 80: stä joksikin muuksi?
K: Voiko hyökkääjä lähettää satunnaisia lippuja Gatewaylle kirjautuakseen sisään?
Q: Mitä muuta kirjautumiseen vaaditaan kuin voimassa oleva STA-lippu?
kysymys: Miten voidaan asettaa STA-Lipun elinaika, jonka jälkeen Lipun pitäisi olla kelvoton?

skaalautuvuus

Q: montako Staa tarvitsen?
K: Kirjautuvatko käyttäjät yhdyskäytävän kautta aamulla ja käyttävät yhtä julkaistua sovellusta koko päivän vai käynnistävätkö he useita sovelluksia pitkin päivää?
K: Miten voin varmistaa STA vikasietoisuuden?
Q: Miten lataan tasapainon useita Stoja?
Q:Voinko käyttää useita STAs Microsoft Network Load Balancing?
K: Voinko jakaa yhden henkilöstön useiden maatilojen, yhdyskäytävien ja Luettelointipalvelimien kanssa?

Vianetsintä

kysymys: Miten IIS: n tulisi olla määritetty isännöimään henkilöstöä?
K: Miten otan käyttöön kirjautumisen STA: ssa?
K: Miksi Microsoftin IISLockDown-työkalu rikkoo STA?
K: Miten voin testata Staa varmistaakseni, että se toimii oikein?
K: Miten tulkitsen STA – lokitiedostoja?
Q: Mitkä ovat Citrixin teknisen tuen yleisiä konfiguraatiovirheitä?

yleiskatsaus

K: Mikä on turvallinen Lippuviranomainen?

A: Secure Ticket Authority (STA) on XML-verkkopalvelu, joka vaihtaa XenApp-palvelimen tietoja satunnaisesti luotuihin lippuihin. Sitä käytetään Citrix Secure Gateway-palvelimen käytön ohjaamiseen.

K: mitkä Citrix-tuotteet ovat vuorovaikutuksessa STA: n kanssa?

A: STA ovat vuorovaikutuksessa XenMobile, Web Interface, StoreFront, XenApp Secure Access Manager, NetScaler Gateway ja Citrix Secure Gateway. Tässä artikkelissa seuraavat palvelintyypit on ryhmitelty yhteen luokkaan, jota kutsutaan sovellusten luettelointipalvelimiksi:

• Web Interface 2.0 tai uudempi
• Secure Access Manager 2.0 tai myöhemmin
• StoreFront
• Sovellusluettelopalvelimet vastaavat käyttäjien todentamisesta, julkaistujen sovelluskuvakkeiden luetteloinnista ja ICA-tiedoston tuottamisesta asiakkaalle, jonka avulla he voivat muodostaa yhteyden julkaistuun sovellukseen turvallisen yhdyskäytäväpalvelimen kautta.

K: Miksi henkilökuntaa tarvitaan?

A: Citrix Secure Gateway-käyttöönotoissa gateway-palvelin ei suorita saapuvien pyyntöjen todennusta. Sen sijaan gateway-palvelin lykkää todennuksen sovelluksen luettelointipalvelimelle ja käyttää STA takaamaan, että jokainen käyttäjä on todennettu. Sovellusten luettelointipalvelimet pyytävät lippuja vain käyttäjille, jotka ovat jo todennettuja www-palvelimelle. Jos käyttäjillä on voimassa olevat STA-liput, yhdyskäytävä olettaa, että he ovat läpäisseet verkkopalvelimen todennustarkastukset ja heille olisi sallittava pääsy.

tämän rakenteen avulla Citrix Secure Gateway-palvelin voi periä kaikki www-palvelimesi todennusmenetelmät. Jos esimerkiksi Web-Käyttöliittymäpalvelimesi on suojattu RSA SecurID-järjestelmällä, vain SecurID-varmennetut käyttäjät voivat kulkea Secure Gateway-palvelimen läpi.

K: Miten STA-palvelu toteutetaan?

A: STA kirjoitetaan ISAPI-laajennuksena Microsoft Internet Information Servicesille (IIS). Laajennuksen nimi on CtxSta.DLL ja isännöi /skriptit-kansiossa oletuksena. Muut komponentit kommunikoivat STA käyttäen XML over HTTP.

sovellusten luettelointipalvelimet pyytävät lippuja sovelluksen julkaisuhetkellä lähettämällä tiedot henkilöstölle osana lippupyyntöä. Henkilöstölle lähetetyt tiedot sisältävät sen XenApp-palvelimen osoitteen, johon käyttäjä muodostaa yhteyden, ja Web Interface 2.0: n ja Secure Access Manager 2.0: n osalta laajennetut tiedot nykyisen käyttäjän nimestä ja julkaistusta sovelluksesta, jonka käyttäjä haluaa suorittaa. STA vastaa luomalla lipun ja lähettämällä sen takaisin sovelluksen luettelointipalvelimelle. Tämä lippu ja sitä vastaavat tiedot säilyvät STA: n muistissa määritettävän määrän sekunteja (oletusarvoisesti 100).
sovelluksen luettelointipalvelin muodostaa käyttäjälle ICA-tiedoston ja lisää STA-lipun ICA-tiedoston osoitekenttään. Kun asiakas muodostaa yhteyden suojattuun yhdyskäytävään, lippu esitetään ja yhdyskäytävän tulee vahvistaa lippu ennen suojatun istunnon luomista asiakkaalle. Yhdyskäytävä suorittaa tietopyynnön lähettämällä Lipun takaisin henkilöstölle ja pyytämällä sitä vastaavat tiedot vastineeksi. Jos validointi on hyväksytty, henkilöstöhallinto välittää alkuperäiset tiedot yhdyskäytävälle ja yhdyskäytävä muodostaa loppukäyttäjän ja XenApp-palvelimen välisen releen.

sekä lippupyynnöt että tietopyynnöt toteutetaan XML-pyyntö/vastausdokumentteina.

K: Onko STA olemassa versiota, joka ei vaadi IIS: ää?

A: ei, tällä hetkellä IIS: n on isännöitävä henkilöstöä. Muista, että STA ei tarvitse altistua epäluotettava verkko, kuten Internet; STA sijaitsee luotetussa verkossasi, ja sitä käyttävät vain yhdyskäytävä-ja sovellusluettelopalvelimet.

K: Missä STA-palvelin sijaitsee?

A: STA-palvelin voidaan sijoittaa minne tahansa, kunhan suojattu yhdyskäytävä ja sovellusluettelopalvelimet pääsevät sinne. Citrix suosittelee, että STA sijoitetaan luotettuun verkkoon tai sisäisen palomuurin erilliseen jalkaan, mutta STA-palvelimelle ei ole muita vaatimuksia kuin IIS. STA: n ei tarvitse kuulua mihinkään domainiin, XenApp Server farm: iin, Secure Access Manager farm: iin tai muuhun sisäiseen WWW-palvelimeen, mutta henkilöstön jakaminen toisen toiminnon kanssa on yleinen käytäntö. STA sisältyy automaattisesti osana Secure Access Manager 2.0-asetusta; monien ylläpitäjien mielestä on kätevää paikantaa STA XenApp-palvelimella.

K: mitkä ovat STA: n eri versioiden väliset erot?

A: versioiden 1.0 ja 1.1 välillä ei ole olennaisia toiminnallisia eroja, mutta käytettäessä 2.0 STA Web Interface 2.0: lla tai Secure Access Manager 2: lla.0, laajennetut tiedot lisätään lippupyyntöön: käyttäjän nimi ja sovellus, jonka käyttäjä haluaa suorittaa. Gateway-palvelu käyttää tätä laajennettua tietoa näyttääkseen tietoja jokaisesta gateway-istunnosta suojatussa Gateway 2.0-hallintakonsolissa.

jos Secure Gateway 2.0 on määritetty käyttämään vanhempaa STA versiosta 1.1 tai 1.0, käyttäjät voivat muodostaa yhteyden sovelluksiin, mutta Secure Gateway management console näyttää ”N/A” kuhunkin ICA-istuntoon liittyvälle käyttäjänimelle ja sovelluksen nimelle. Voit nähdä laajennetut tiedot suojatussa yhdyskäytävässä 2.0 hallinta konsoli, sinun täytyy käyttää Versio 2.0 tai uudempi STA ja käyttää joko Secure Access Manager 2.0 tai Web Interface 2.0 kuin sovellus luettelointi palvelin.

turvallisuus

K: Miten STA-lippu syntyy?

A: ISAPI-laajennus CtxSta.dll käyttää pseudo-satunnaislukusukupolvea 16-tavuisen heksadesimaalisen merkkijonon tuottamiseen. Turvallisuussyistä Citrix ei paljasta tarkkoja vaiheita, joita käytetään tämän satunnaisen merkkisarjan tuottamiseen.

K: Mikä on STA-lippu?

A: koodausmuoto on merkkijono muodossa:

;STA_VERSION;STA_ID; TICKET

Where:

• STA_VERSION on numeerinen kenttä, joka tunnistaa STA: n version. Tällä hetkellä tämän kentän ainoat kelvolliset arvot ovat” 10 ”STA versioille 1.0 ja 1.1 ja” 20 ” STA versiolle 2.0.
• STA_ID on 0-16 merkin jono, joka edustaa ylläpitäjän tietylle henkilöstölle osoittamaa mielivaltaista nimeä. Versiossa 1.x, tämä merkkijono oletuksena sta01, STA02, ja niin edelleen. Kun STA asennetaan automaattisesti osana Secure Access Manager 2.0-ohjelmaa, STA-tunnus on palvelimen nimen hajautus. Kun yksi gateway-palvelin jakaa useita Palvelinyksiköitä, jokaisen STA-tunnuksen on oltava yksilöllinen. Tämän avulla yhdyskäytävä voi paikantaa lipun luoneen henkilöstön ja palata kyseiseen henkilöstöön lipun vahvistamista varten. Sta01: ssä luotua lippua ei ole sta02: ssa.
• lippu on satunnaistettu sarja, jossa on 32 isoa – tai numeerista merkkiä.

  esimerkiksi:
  ;10; STA01; FE0A7B2CE2E77DC17C7FD3EE7959E79

K: onko lippu vahvistettu työpistettä vastaan?

A: Ei, mikään ei sido lippua tiettyyn työpisteeseen. Teoriassa on mahdollista, että lippu pyydetään työpisteeltä A ja sitä käytetään työpisteeltä B. riskin pienentämiseksi:

• käytä aina HTTPS: tä asiakkaan ja sovelluksen luettelointipalvelimen välillä estääksesi hyökkääjää sieppaamasta lippua sen kulkiessa palvelimelta asiakkaalle.
• lyhennä lippuaikaa niin paljon kuin mahdollista, jotta hyökkääjällä olisi aikaa siirtää lippu koneelta A koneelle B.

muista, että STA: n myöntämää lippua voi käyttää vain kerran, joten jos aiottu käyttäjä yhdistää koneen a onnistuneesti, lippu on mitätön kaikissa tulevissa yhteydenottoyrityksissä koneelta A tai kone B.

Q: Onko lippu poistettu käytön jälkeen?

A: Kyllä, liput tyhjennetään heti onnistuneen tietopyynnön jälkeen, joten niitä voi käyttää vain kerran. Ne poistetaan myös konfiguroitavan aikalisän jälkeen (oletusarvo 100 sekuntia), jos niitä ei käytetä.

K: kirjoitetaanko lippuja koskaan levylle STA?

A: Vain silloin, kun monisanainen kirjaus on käytössä asettamalla LogLevel=3 ctxstassa.määritys. Muussa tapauksessa STA ylläpitää kaikkia jäljellä olevia lippuja (lippuja, jotka on pyydetty sovelluksen luettelointipalvelimelta mutta joita ei ole vielä vahvistettu suojatussa yhdyskäytävässä) käyttäen muistitietokantaa. XML-tiedot lähetetään aina STA: lle HTTP POST-komennolla, joten STA: n www-palvelinlokeihin ei koskaan kirjoiteta merkityksellisiä lipputietoja.

K:Voiko joku kaapata lipun?

A: normaalin liikennöinnin aikana lipun on kuljettava seuraavat neljä rataverkon osaa:

• STA sovelluksen luettelointipalvelimelle
• sovelluksen luettelointipalvelimelta asiakkaalle
• asiakkaalta suojatulle Gateway-palvelimelle
• portilta STA STA

ensimmäinen ja viimeinen segmentti on olemassa vain DMZ: n ja luotettu verkkosi, mikä tarkoittaa, että tunkeilija tarvitsee pääsyn verkkoosi siepatakseen lipun. Silti, nämä polut voidaan salata SSL jos käytät Secure Gateway versio 2.0. Citrix Secure Gateway 1: Ssä.1 ja aiemmin, liikennettä STA ei voida salata SSL.

toisen segmentin turvaamiseksi laita varmenne sovellusluettelon WWW-palvelimeen ja salli asiakkaiden muodostaa yhteys vain, jos he käyttävät HTTPS-protokollaa. Kolmas segmentti on aina suojattu SSL.

vaikka kaikki edelliset linkit on suojattu SSL: llä, asiakkaat ovat edelleen alttiita troijalaisten ohjelmien hyökkäyksille, jotka valvovat asiakkaan toimintaa. Tämän riskin vähentämiseksi neuvo käyttäjiäsi muodostamaan yhteys koneisiin, joihin on asennettu Anti-virus-ja Troijalaistunnistusohjelmisto.

K: Miten voin suojata STA-liikennettä SSL: llä?

A: Asenna ensin www-palvelinvarmenne IIS: n kopioon, joka isännöi henkilöstöä. Lisätietoja on IIS: n dokumentaatiossa.

Määritä sovelluksen luettelointipalvelin ja Secure Gateway server käyttämään HTTPS-protokollaa yhdyskäytävän kanssa kommunikoidessa. HTTPS-yhteyden muodostamisessa on aina noudatettava seuraavia sääntöjä:

• sinun on käsiteltävä henkilöstöä käyttämällä täysin hyväksyttyä verkkotunnusta, joka vastaa STA-palvelinvarmenteen kohdetta.
• henkilöstön kanssa kommunikoivan koneen on kyettävä ratkaisemaan henkilöstön täysin pätevä verkkotunnus asianmukaiseen IP-osoitteeseen.
• henkilöstön kanssa kommunikoivan koneen on luotettava STA – palvelinvarmenteen myöntäneeseen Varmenneviranomaiseen (CA).
• täyttääkseen kolmannen bullet-kohteen vaatimukset CA-juurivarmenteen on oltava asennettuna Secure Gateway-palvelimelle ja sovelluksen luettelointipalvelimelle. Ole varovainen juurivarmenteen asennuksessa: et voi kaksoisnapsauttaa juurivarmentetiedostoa ja suorittaa ohjattua varmenteen tuontia.

(tämä osoittaa, että käyttäjätilisi, ei palvelin tai mikään järjestelmäpalvelu, luottaa CA: han.) Jos haluat asentaa juurivarmenteen käytettäväksi Citrix Secure Gateway-tai Web-käyttöliittymän kanssa, seuraa ohjeita:

1. aja Mmc: tä.exe ja lisää Varmenteet-laajennus.
2. kun kysytään, mitä varmenteita hallitaan, valitse Tietokonetili ja sen jälkeen paikallinen tietokone.
3. Laajenna varmenteet (Paikallinen tietokone) > Luotetut Root Certification Authorities node. Napsauta varmenteita hiiren kakkospainikkeella ja valitse sitten kaikki tehtävät > tuo.
4. Selaa valitaksesi CA-juurivarmenteesi ja suorittaaksesi ohjatun tuonnin.

K: Onko STA aina käytettävä täysin pätevää verkkotunnusta?

A: Jos aiot suojata liikenteen henkilöstöön SSL: n avulla, mikä tahansa osa, joka käyttää henkilöstöä, mukaan lukien yhdyskäytäväpalvelin ja sovellusten luettelointipalvelin, on osoitettava henkilöstölle käyttäen täysin hyväksyttyä verkkotunnusta (FQDN), joka vastaa IIS: n henkilöstössä käyttämän palvelinvarmenteen kohdetta. Esimerkiksi Web Interface 2.0: ssa STA-osoite merkittäisiin seuraavasti:https://sta-server.company.com/Scripts/CtxSta.dll

jos päätät olla suojaamatta liikennettä henkilöstöön, voit ottaa yhteyttä henkilöstöön käyttämällä IP-osoitetta, isäntänimeä tai FQDN: ää.

Q: Miten voin muuttaa STA portin 80: stä joksikin muuksi?

A: koska henkilöstöä palvelee IIS, HENKILÖSTÖPORTTIA vaihdetaan, kun vaihdetaan IIS-porttia. Seuraavassa esimerkissä havainnollistetaan, miten IIS-portti muutetaan 80: stä 81: een.

1. Open Internet Services Manager.
2. napsauta hiiren kakkospainikkeella Oletussivustoa ja tarkastele ominaisuuksia.
3. Vaihda www-sivuston välilehdessä TCP-portin numero 80: stä 81: een.
4. klikkaa OK.
   edeltävä muutos vaikuttaa myös muihin STA – verkkopalvelimelta julkaisemiisi resursseihin. Jos haluat muuttaa STA-viestintäporttia vaikuttamatta muihin saman WWW-palvelimen ylläpitämiin verkkosivuihin, voit luoda uuden verkkosivuston IIS: ään ainoastaan henkilöstöä varten. Seuraavassa on esimerkki siitä, miten voit luoda uuden sivuston port 81 STA.
5. Luo uusi fyysinen kansio, kuten C:\ MYSTA Web-palvelimen kovalevylle toimimaan asiakirjan root STA sivuston.
6. luo MYSTAN alle alihakemisto nimeltä skriptit. Siirrä seuraavat tiedostot olemassa olevasta STA uuteen komentosarjat-kansioon:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. Open Internet Services Manager.
8. Napsauta palvelimen nimeä hiiren kakkospainikkeella ja valitse Uusi > verkkosivu.
9. Luo uusi verkkosivusto nimeltä ”Oma STA site” ja C:\MYSTA asiakirjan juurihakemistona.
10. Tarkastele uuden verkkosivustosi ominaisuuksia ja vaihda TCP-portti 81: een.
11. Napsauta komentosarjat-kansiota hiiren kakkospainikkeella Internet Services managerin oma STA-sivuston kohdassa ja tarkastele ominaisuuksia. Sovelluksen Asetukset-osiossa, muuta Suoritusoikeudet ” skriptit ja suoritettavat tiedostot.”

Huomautus: Voit valita kansion nimen muu kuin ”skriptit”, mutta muista, että turvallinen yhdyskäytävä ja kaikki sovellusten luettelointipalvelimet, kuten Web-käyttöliittymä, olettavat, että STA on julkaistu nimellä /Scripts/CtxSta.dll joten sinun on myös päivitettävä STA URL-osoite näiden palvelimien asetuksissa.

K:Voiko hyökkääjä lähettää satunnaisia lippuja Porttikäytävään kirjautumaan?

A: hyökkääjän pitäisi arvata voimassa oleva lippu ja myös lunastaa se muutaman millisekunnin kuluessa siitä, kun asiakas sitä pyytää, mutta ennen kuin yhdyskäytävä vaatii sitä.

K: Mitä muuta kirjautumiseen vaaditaan kuin voimassa oleva STA-lippu?

A: käyttäjät tarvitsevat myös toimialueen tunnukset tai XenApp-Palvelinlipun, jonka sovelluksen luettelointipalvelin pyytää. (XenApp Server-lippu ei ole sama kuin STA-lippu.) Täytä STA avaa polun vain luotettuun verkkoon tietylle palvelimelle. Kun olet siellä, käyttäjän on vielä todennettava kelvollisilla toimialueen tunnuksilla.
kysymys: Miten voidaan asettaa STA-Lipun elinaika, jonka jälkeen Lipun pitäisi olla kelvoton?
A: voimme asettaa STA – lipun eliniän luomalla seuraavan rekisteriavaimen toimituksen ohjaimeen:
Location: HKLM\Software\Citrix\DesktopServer
Name: XmlStaTicketLifetimeInSeconds
Type: Dword Value: Anna arvo sekunneissa (desimaali)
ota rekisterin varmuuskopio ennen rekisterin arvojen muokkaamista, huomaa myös, että rekisterin muutos vaatisi uudelleenkäynnistyksen ohjaimen päässä.

skaalautuvuus

Q: montako Staa tarvitsen?

A: STA pääsee käsiksi vain, kun käyttäjä käynnistää sovelluksen, vastaus tähän kysymykseen vaihtelee käyttöönotosta toiseen.

Q: kirjautuvatko käyttäjät yhdyskäytävän kautta aamulla ja käyttävät yhtä julkaistua sovellusta koko päivän vai käynnistävätkö he useita sovelluksia pitkin päivää?

A: STA: n suorittamat tehtävät eivät ole suorittimen kannalta kalliita; kyseessä on kevyt XML-palvelu, jota rajoittaa vain IIS: n suorituskyky. Eräässä testissä matalan kantaman palvelin, jossa oli 1GHz-prosessori ja 256MB RAM-muistia, tuki yli 250 lippupyyntöä sekunnissa suorittimen käyttöasteen pysyessä Alle 60%: ssa.

K: Miten voin varmistaa STA vikasietoisuuden?

A: seuraavien sovellusten luettelointipalvelimien avulla voit syöttää useita STA-URL-osoitteita määritettäessä suojatun yhdyskäytävän parametreja:

• Web Interface 2.0
• Secure Access Manager 2.0
• StoreFront

kaikissa tapauksissa, jos STA ei vastaa, sovelluksen luettelointipalvelin yrittää toista luetteloa. Jokaiselle yhdyskäytäväpalvelimelle on puolestaan määritettävä kunkin lippuviranomaisen STA-URL-osoite ja yksilöllinen STA-tunnus.

Q: Miten Kuormitan tasapainon useita Stoja?

A: kuorman tasapainottamisessa on noudatettava erityistä huolellisuutta turvallisten Lippuviranomaisten kanssa. Sovelluksen luettelointipalvelimen ja STAs: n välisen yhteyden lataamiseen voidaan käyttää erilaisia menetelmiä, mutta turvallisen yhdyskäytäväpalvelimen on aina otettava yhteyttä kuhunkin STA erikseen sen STA-tunnuksen perusteella. Kun määrität kunkin henkilöstön osoitteen gateway service configuration tool-työkalussa, jokaisen henkilöstön osoitteen on oltava STA-palvelimen todellinen osoite — älä syötä tähän laitteistokuorman tasapainottajan, klusterin nimen tai round-robin DNS-nimen osoitetta.

StoreFront, Web Interface 2.0 ja Secure Access Manager 2.0 kaikki tuki Round-robin kuorman tasapainotus STAs kun useita STAs on lueteltu. Kun tämä asetus on käytössä, kuormantasausohjelmistoa tai-laitteistoa ei tarvita.

sovellusten luettelointipalvelimet voivat käyttää mitä tahansa kuormitustasapainoa lippupyynnön esittämiseen, koska jokainen vastaanotettu lippu sisältää kentän, josta käy ilmi sen tuottaneen henkilöstön yksilöllinen tunnus. Niin kauan kuin jokainen STA-tunnus on yksilöllinen ja kaikki yhdyskäytävän palvelimet voivat ratkaista STA-tunnuksen tiettyyn (ei kuormaa tasapainotettuun) palvelinosoitteeseen, operaatio onnistuu ja STA-liikenne on kuormitustasapainotettu.

K: Voinko käyttää useita STAs Microsoft Network Load Balancing?

A: verkon kuormituksen tasapainottamista ei voida käyttää Secure Gateway-palvelimen ja useiden STAs-järjestelmien välillä. Näin määritettynä käyttäjät saavat ajoittaisia kieltoja, koska lippujen vahvistusprosessin aikana yhdyskäytävä saatetaan ladata tasapainoisesti viranomaiselle, joka ei alun perin tuottanut käyttäjän lippua.

K: Voinko jakaa yhden henkilöstön useiden maatilojen, yhdyskäytävien ja Luettelointipalvelimien kanssa?

A: Kyllä, yksi STA voidaan jakaa minkä tahansa määrän suojattuja Gateway-palvelimia ja sovellusten luettelointipalvelimia. STA ei rajoitu mihinkään tiettyyn toimialueen, maatilan tai sovelluksen luettelointipalvelimeen. Se on anonyymi XML-palvelu.

Vianetsintä

K: Miten IIS tulisi konfiguroida isännöimään henkilöstöä?

The STA URL / Scripts/CtxSta.DLL on palveltava anonyymin käytön ollessa käytössä. Jos osoitat minkä tahansa verkkoselaimen STA-URL-osoitteeseen, sinulta ei kysytä salasanaa.

• sinun on myönnettävä resurssikommenteille ja suoritettaville ohjelmille lupa IIS-metakannassa. Tätä lupaa ei tarvita Koko /skriptit-kansiolle, mutta se voidaan asettaa ctxsta-tiedostolle.DLL tiedosto erikseen.
• Secure Gateway-versiossa 1.1 ja sitä aikaisemmassa, älä ota käyttöön vaadi SSL: ää ja vaadi 128-bittisiä SSL-asetuksia.
• oletusarvoisesti tarvitaan seuraavat tilin käyttöoikeudet:

Windows 2000-palvelimilla

• Iusr_machinename-tili tarvitsee lukuoikeuden Ctxstaan.DLL.
• Iwam_machinename-tili tarvitsee muokata pääsyä lokitiedostohakemistoon, joka on oletusarvoisesti \Inetpub\Scripts.

Windows 2003-palvelimilla

• IUSR_MachineName-tili tarvitsee lukuoikeuden Ctxstaan.DLL.
• sisäänrakennettu Verkkopalvelutili tarvitsee muokata pääsyä lokitiedostohakemistoon, joka on oletusarvoisesti \Inetpub\Scripts.

K: Miten MAHDOLLISTAN kirjaamisen STA: ssa?

A: Muokkaa tiedostoa Notepadilla \Inetpub\Scripts\CtxSta.config STA palvelimella ja etsi rivi, joka sanoo LogLevel=0. Jos haluat maksimilookauksen, muuta tämä muotoon LogLevel=3. World Wide Web Publishing Service on käynnistettävä uudelleen, jotta muutokset tulevat voimaan.
Huomautus: Kun olet ottanut kirjaamisen käyttöön, käyttäjätilillä, jonka alaisuudessa STA suorittaa (iusr_machinename Windows 2000: ssa tai verkkopalvelu Windows 2003: ssa) on oltava Kirjoitusoikeus lokitiedostohakemistoon, joka on oletusarvoisesti \Inetpub\Scripts. Voit myös muuttaa lokitiedostohakemistoa, kun muokkaat ctxstaa.määritys.

Q: Miksi Microsoftin IISLockDown-työkalu rikkoo STA?

A: Jos hyväksyt Kaikki IISLockDown-työkalun oletusasetukset, / Scripts-kansio on poistettu käytöstä. STA toteutetaan ISAPI-suodattimena, joka julkaistaan nimellä / Scripts / CtxSta.DLL; poistamalla / Scripts Hakemisto, estät pääsyn STA. Ota /Scripts-kansio käyttöön ja salli skriptien ja suoritettavien tiedostojen pääsy STA: n toimintaan.

K: Miten voin testata Staa varmistaakseni, että se toimii oikein?

A: Jos osoitat verkkoselaimen STA-URL-osoitteeseen, näet joko tyhjän valkoisen sivun tai viestin ”405 resurssi ei sallittu.”Jompikumpi näistä tuloksista viittaa toimivaan henkilöstöön. Voit ottaa yhteyttä henkilöstöön tällä tavalla suojatun Gateway-palvelimesi konsolista ja myös mistä tahansa sovelluksen luettelointipalvelimesta, joka on määritetty käyttämään yhdyskäytävää. Jos saat todennus-valintaikkunan, jossa pyydetään salasanaa, STA ei julkaista anonyymisti ja todennusvaatimukset on poistettava.

voit tarkistaa, että sovelluksen luettelointipalvelin pyytää onnistuneesti STA-lippuja, katso sen luomia ICA-tiedostoja. Esimerkiksi Web Interface 2.0: sta voit napsauttaa julkaistua sovelluskuvaketta hiiren kakkospainikkeella ja tallentaa tuloksen laukaisuna.ica. Avatkaa laukaisu.ica Muistiossa ja tarkastella osoite = line. Tavanomaisessa suojatussa yhdyskäytävän toiminnassa Osoiteparametri sisältää lipun varsinaisen XenApp-palvelimen osoitteen sijaan.

K: Miten tulkitsen STA – lokitiedostoja?

A: Jos otat lokin käyttöön asettamalla LogLevel=3 ctxstassa.config, näet tiedot jokaisesta lipusta ja tietopyynnöstä, jonka STA on vastaanottanut. Muista, että lippupyynnön luo sovelluksen luettelointipalvelin, kuten Web-käyttöliittymä, ja tietopyynnön suorittaa Secure Gateway-palvelu. Jos lokitiedostossa näkyy useita lippupyyntöjä, mutta ei tietopyyntöjä, tämä tarkoittaa, että sovelluksen luettelointipalvelin voi tavoittaa STA, mutta Secure Gateway-palvelin ei. Se voi myös tarkoittaa, että käyttäjät eivät pääse gateway-palvelimelle.

normaalissa käytössä ICA-asiakkaan istuntojen jako-ominaisuus voi aiheuttaa sen, että STA voi pyytää lippuja, mutta yhdyskäytävä ei koskaan lunasta niitä. Harkitse seuraavaa skenaariota:

• käyttäjä kirjautuu Web-käyttöliittymään ja napsauttaa Outlook-kuvaketta. Web-käyttöliittymä pyytää pääsylipun STA ja lähettää sen käyttäjälle ICA-tiedostona.
• käyttäjä muodostaa yhteyden suojatun yhdyskäytävän kautta ja esittää pääsylipun. Yhdyskäytävä validoi lipun ja sallii käyttäjän muodostaa yhteyden XenApp-palvelimeen, joka isännöi Outlookia.
• työskenneltyään muutaman minuutin käyttäjä palaa sovellusluetteloon Web-Käyttöliittymäsivulle ja napsauttaa Excel-kuvaketta. Web-käyttöliittymä pyytää toista lippua STA ja lähettää sen käyttäjälle ICA-tiedostona.
• ennen kuin muodostat yhteyden uuteen Excel-palvelimeen, ICA-asiakas tarkistaa ensin, onko olemassa palvelimia, joihin asiakas on jo liitetty, saatavilla Excel-julkaistu sovellus.
• palvelimeen, jossa asiakas on jo Outlookissa, on asennettu myös Excel, joten ICA-asiakas hylkää ICA-tiedoston ja käynnistää Excelin olemassa olevassa ICA-istunnossa.
• Web-käyttöliittymän pyytämää toista lippua ei koskaan käytetä, koska toista ICA-istuntoa ei tarvittu. Oletuksena lippu aikaistuu 100 sekunnin kuluttua.

tämä skenaario johtaisi samaan sarjaan STA-lokitiedostoja kuin seuraavat:

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

epäilyttävämpi toiminta voi näyttää tältä.:

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

Tässä näemme, mitä näyttää olevan hyökkääjä yrittää eri lippuja yksi kerrallaan, korottamalla lipun ID jokaisella yrityksellä. Jokaisessa tapauksessa yhteys hylättiin ja STA kirjasi merkinnän, jonka mukaan asiakas esitti lipun, jota ei tunnustettu päteväksi. Tunnistaaksesi hyökkääjän IP-osoitteen, Etsi seuraava viesti Secure Gateway-palvelimen tapahtumienvalvonnasta:

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

älä tulkitse joitakin ”lippua ei löytynyt” – viestejä hyökkäykseksi. Win32 ICA-asiakas voi yrittää muodostaa yhteyden katkaistuun istuntoon, jos käyttäjän verkkoyhteys katkeaa hetkellisesti. Auto Client Reconnect-ominaisuus ei toimi Citrix Secure Gateway-käyttäjille, koska jokaisen uudelleensijoitusyrityksen aikana asiakas lähettää uudelleen käytetyn STA-lipun, johon se alun perin yhdistettiin. Asiakas yleensä yrittää uudelleen kolme tai useamman kerran ennen luopumista, joten näet kolme tai useampia ”lippua ei löytynyt” viestejä, joissa viitataan samaan lippuun STA lokiin jokaisen tämän ongelman esiintymisen osalta. Asiakkaan uudelleensijoitusyrityksille on ominaista aiemmin onnistuneen lipun uudelleenkäyttöyritys:

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

katkaise Automaattinen Client Reconnect for Secure Gateway users lisäämällä TransportReconnectEnabled=Off ICA-tiedoston osaan. Oikea tapa muodostaa yhteys katkaistuun istuntoon, kun käytät Secure Gateway-yhdyskäytävää, on palata sovelluksen luettelointipalvelimeen ja napsauttaa sovelluskuvaketta uudelleen.

Q: millaisia yleisiä konfiguraatiovirheitä Citrixin Tekninen tuki on havainnut?

• / Scripts-kansio tai koko Oletussivusto on poistettu käytöstä Iislockdownin suorittamisen tai yrityksen web-palvelimien suojauskäytäntöjen noudattamisen vuoksi.
• kirjaaminen on käytössä ctxstassa.config, mutta käyttäjätilillä, jonka alaisuudessa STA suorittaa (oletuksena IUSR_MACHINENAME), ei ole kirjoitusoikeutta lokitiedostohakemistoon.
• STA-palvelimen IIS on määritetty vaatimaan SSL: ää, mutta Secure Gateway on määritetty käyttämään STA: ää normaalin HTTP: n avulla.
• jos Sovelluksen käynnistäminen epäonnistuu, ensimmäinen asia on tarkistettava, jos STAs on StoreFront/Web-käyttöliittymä ja NetScaler annetaan täsmälleen samalla tavalla tai ei, eli jos STAs annetaan IP-osoitteena SF/WI se olisi annettava käyttäen IP-osoite NS ja vastaavasti, jos FQDN.