FAQ: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

opmerking: dezelfde principes en concepten gelden ook voor NetScaler Gateway.

dit artikel beantwoordt enkele veelgestelde vragen over de Citrix Secure Ticket Authority (STA). De vragen zijn onderverdeeld in vier categorieën:

overzicht

Q: Wat is de autoriteit voor beveiligde tickets?
V: welke Citrix-producten interageren met de STA?
Q: Waarom is de STA noodzakelijk?
V: Hoe wordt de STA-dienst geïmplementeerd?
Q: Is er een versie van de STA die geen IIS vereist?
Q: Waar bevindt de STA-server zich?
Q: Wat zijn de verschillen tussen de verschillende versies van de STA?

veiligheid

Q: Hoe wordt het Sta-Ticket gegenereerd?
V: Wat is een sta-Ticket?
Q: Is het Ticket gevalideerd tegen het werkstation?
V: wordt het Ticket na gebruik verwijderd?
V: zijn Tickets ooit naar de schijf Geschreven bij de STA?
Q: Is het mogelijk voor iemand om een ticket te kapen?
V: Hoe bescherm ik het STA-verkeer met SSL?
Q: Moet de STA altijd worden aangesproken met behulp van een volledig gekwalificeerde domeinnaam?
Q: Hoe verander ik de STA poort van 80 naar iets anders?
V: kan een aanvaller willekeurige Tickets naar de Gateway sturen om in te loggen?
V: welke andere informatie is vereist om in te loggen dan een geldig STA-Ticket?
V: Hoe kunnen we de levensduur van STA-Ticket instellen, waarna het ticket ongeldig zou moeten zijn?

schaalbaarheid

Q: hoeveel sta ‘ s heb ik nodig?
Q: Loggen gebruikers ‘ s ochtends in via de gateway en draaien ze de hele dag één gepubliceerde applicatie of starten ze meerdere applicaties gedurende de dag?
V: Hoe kan ik sta fouttolerantie garanderen?
V: Hoe laad ik meerdere sta ‘ s?
V: Kan ik meerdere sta ‘ s gebruiken met Microsoft Netwerktaakverdeling?
Q: Kan ik een enkele STA delen met meerdere Farms, Gateways en Enumeratieservers?

probleemoplossing

Q: Hoe moet IIS worden geconfigureerd om de STA te hosten?
V: Hoe schakel ik Logging in bij de STA?
Q: Waarom breekt de Microsoft Iislockdown Tool de STA?
V: Hoe kan ik de STA testen om er zeker van te zijn dat deze goed werkt?
v: hoe interpreteer ik de Sta-logbestanden?
Q: Wat zijn enkele veelvoorkomende configuratiefouten die door Citrix Technical Support worden gezien?

overzicht

Q: Wat is de autoriteit voor beveiligde tickets?

A: De Secure Ticket Authority (STA) is een XML-webservice die XenApp-serverinformatie uitwisselt voor willekeurig gegenereerde tickets. Het wordt gebruikt om de toegang voor een Citrix Secure Gateway server te beheren.

Q: welke Citrix-producten interageren met de STA?

a: XenMobile, webinterface, StoreFront, XenApp Secure Access Manager, NetScaler Gateway en Citrix Secure Gateway interacteren met STA. In dit artikel worden de volgende typen servers gegroepeerd in een enkele categorie, genaamd application enumeration servers.:

• webinterface 2.0 of hoger
• Secure Access Manager 2.
• StoreFront
• toepassingsservers zijn verantwoordelijk voor het verifiëren van gebruikers, het opsommen van gepubliceerde toepassingspictogrammen en het aanmaken van een ICA-bestand voor een client waarmee ze verbinding kunnen maken met een gepubliceerde toepassing via een beveiligde gatewayserver.

Q: Waarom is het personeel noodzakelijk?

A: In Citrix Secure Gateway-implementaties voert de gatewayserver geen verificatie uit van inkomende aanvragen. In plaats daarvan stelt de gatewayserver de verificatie uit naar een toepassingsserver en gebruikt hij de STA om te garanderen dat elke gebruiker wordt geverifieerd. Opsommingsservers voor toepassingen vragen alleen tickets aan voor gebruikers die al bij de webserver zijn geverifieerd. Als gebruikers geldige STA-tickets hebben, gaat de gateway ervan uit dat ze de authenticatiecontroles op de webserver hebben doorstaan en dat ze toegang moeten krijgen.

met dit ontwerp kan de Citrix Secure Gateway server alle verificatiemethoden in uw webserver overnemen. Als uw Webinterfaceserver bijvoorbeeld is beveiligd met RSA-SecurID, kunnen alleen met SecurID geverifieerde gebruikers door de beveiligde gatewayserver reizen.

V: Hoe wordt de STA-dienst geïmplementeerd?

A: de STA is geschreven als een ISAPI-extensie voor Microsoft Internet Information Services (IIS). De extensie heet CtxSta.dll en wordt standaard gehost in de map / Scripts. Andere componenten communiceren met de STA met behulp van XML via HTTP.

toepassingsservers vragen tickets aan tijdens het opstarten van de toepassing door gegevens naar de STA te sturen als onderdeel van een ticketaanvraag. De gegevens die naar het STA worden verzonden, bevatten het adres van de XenApp-Server waarmee de gebruiker verbinding zal maken en, in het geval van Web Interface 2.0 en Secure Access Manager 2.0, uitgebreide informatie over de naam van de huidige gebruiker en de gepubliceerde toepassing die de gebruiker wil uitvoeren. De STA reageert door het genereren van een ticket en het terug te sturen naar de Application enumeration server. Dit ticket en de bijbehorende gegevens blijven in het geheugen op het STA voor een configureerbaar aantal seconden (standaard 100).
de enumeratieserver voor toepassingen maakt een ICA-bestand voor de gebruiker en voegt het sta-ticket in het adresveld van het ICA-bestand in. Wanneer de client verbinding maakt met de beveiligde Gateway, wordt het ticket gepresenteerd en moet de gateway het ticket valideren voordat een beveiligde sessie voor de client wordt ingesteld. De gateway voert een gegevensaanvraag uit door het ticket terug te sturen naar de STA en in ruil daarvoor de bijbehorende gegevens te vragen. Indien met succes gevalideerd, stuurt de STA de originele gegevens naar de gateway en de gateway zorgt voor een relais tussen de eindgebruiker en de XenApp-Server.

zowel ticketverzoeken als gegevensverzoeken worden uitgevoerd als XML-aanvraag/ – antwoorddocumenten.

Q: Is er een versie van de STA die geen IIS vereist?

A: nee, op dit moment is IIS vereist om de STA te hosten. Vergeet niet dat de STA niet hoeft te worden blootgesteld aan een niet-vertrouwd netwerk zoals het Internet; de STA bevindt zich op uw vertrouwde netwerk en wordt alleen geopend door de gateway-en toepassingsservers.

Q: Waar bevindt de STA-server zich?

A: de STA-server kan overal worden geplaatst zolang de beveiligde Gateway-en toepassingsservers deze kunnen bereiken. Citrix raadt aan om de STA op het vertrouwde netwerk of op een apart deel van uw interne firewall te plaatsen, maar er zijn geen andere vereisten voor de Sta-server dan IIS. De STA hoeft niet behoren tot een domein, XenApp Server farm, Secure Access Manager farm, of andere interne webserver, maar het delen van de STA met een andere functie is gebruikelijk. Een STA wordt automatisch meegeleverd als onderdeel van de Secure Access Manager 2.0 setup; veel beheerders vinden het handig om de STA te lokaliseren op een XenApp-server.

Q: Wat zijn de verschillen tussen de verschillende versies van de STA?

A: Er zijn geen materiële functionele verschillen tussen versies 1.0 en 1.1, maar bij gebruik van de 2.0 STA met webinterface 2.0 of Secure Access Manager 2.0, uitgebreide informatie wordt toegevoegd aan de ticketaanvraag: de naam van de gebruiker en de toepassing die de gebruiker wil uitvoeren. Deze uitgebreide gegevens worden gebruikt door de gateway-service om details weer te geven over elke gateway-sessie in de Secure Gateway 2.0-beheerconsole.

als Secure Gateway 2.0 is geconfigureerd om een oudere STA Van Versie 1.1 of 1.0 te gebruiken, kunnen gebruikers verbinding maken met toepassingen, maar de Secure Gateway management console zal “N/A” tonen voor de gebruikersnaam en de naam van de toepassing die aan elke ICA-sessie zijn gekoppeld. Om de uitgebreide informatie in de beveiligde Gateway te zien 2.0 beheerconsole, moet u Versie 2.0 of hoger van de STA gebruiken en Secure Access Manager 2.0 of webinterface 2.0 gebruiken als uw toepassingsserver.

veiligheid

Q: Hoe wordt het Sta-Ticket gegenereerd?

A: de ISAPI-extensie CtxSta.dll maakt gebruik van pseudo-random getalgeneratie om een 16-byte hexadecimale string te produceren. Om veiligheidsredenen maakt Citrix niet de exacte stappen bekend die worden gebruikt om deze willekeurige reeks tekens te produceren.

Q: Wat is een sta-Ticket?

A: het coderingsformaat is een tekenreeks in de vorm:

;STA_VERSION; STA_ID; TICKET

waarbij:

• STA_VERSION is een numeriek veld dat de versie van de STA identificeert. Momenteel zijn de enige geldige waarden voor dit veld “10” voor STA versies 1.0 en 1.1 en “20” voor STA Versie 2.0.
• STA_ID is een reeks van 0 – 16 tekens die een willekeurige naam vertegenwoordigt die door de beheerder aan een bepaalde STA is toegewezen. In Versie 1.x, deze string is standaard STA01, STA02, enzovoort. Wanneer de STA automatisch wordt geïnstalleerd als onderdeel van Secure Access Manager 2.0, is de STA ID een hash van de servernaam. Wanneer meerdere sta ‘ s worden gedeeld door een enkele gatewayserver, moet elke sta-ID uniek zijn. Hierdoor kan de gateway de STA die het ticket heeft aangemaakt lokaliseren en terugkeren naar die STA voor ticketvalidatie. Een ticket gemaakt op STA01 zal niet bestaan op STA02.
• TICKET is een willekeurig gegenereerde reeks van 32 hoofdletters, alfabetisch of numeriek.

  bijvoorbeeld:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

V: is het Ticket gevalideerd tegen het werkstation?

A: Nee, er is niets dat een ticket koppelt aan een bepaald werkstation. Theoretisch is het mogelijk dat een ticket wordt aangevraagd bij werkstation A en vervolgens wordt gebruikt vanaf werkstation B. Om dit risico te beperken:

• Gebruik altijd HTTPS tussen de client en de toepassingsserver om te voorkomen dat een aanvaller het ticket onderschept terwijl het van server naar client reist.
• verkort de time-to-live van het ticket zo veel mogelijk om de tijd te verkorten die een aanvaller zou hebben om het ticket van Machine A naar Machine B over te dragen.

onthoud dat een ticket dat door de STA wordt uitgegeven slechts één keer kan worden gebruikt, dus als de beoogde gebruiker op Machine A succesvol verbinding maakt, is het ticket ongeldig voor alle toekomstige verbindingspogingen vanaf Machine A of Machine B.

Q: wordt het Ticket na gebruik verwijderd?

A: Ja, tickets worden onmiddellijk na een succesvolle gegevensaanvraag gewist, zodat ze slechts één keer kunnen worden gebruikt. Ze worden ook verwijderd na een configureerbare time-out (standaard 100 seconden) als ze niet worden gebruikt.

V: zijn Tickets ooit naar schijf geschreven in het STA?

A: Alleen als uitgebreide logging is ingeschakeld door LogLevel=3 in CtxSta in te stellen.configuratiebestand. Anders onderhoudt de STA alle openstaande tickets (tickets die werden aangevraagd door een toepassingsserver, maar nog niet gevalideerd door een beveiligde Gateway) met behulp van een in-memory database. XML-gegevens worden altijd naar de STA verzonden met behulp van het HTTP POST-commando, dus er worden nooit betekenisvolle ticketgegevens naar de Sta-webserverlogboeken geschreven.

Q: Is het mogelijk voor iemand om een ticket te kapen?

A: tijdens normaal gebruik moet een ticket de volgende vier segmenten van het net vervoeren:

• van de STA naar de toepassingsserver
• van de toepassingsserver naar de client
• van de client naar de beveiligde gatewayserver
• van de gateway naar de STA

het eerste en laatste segment bestaan alleen tussen servers in uw DMZ en de STA op uw vertrouwde netwerk, wat betekent dat een indringer toegang tot uw netwerk moet hebben om het ticket langs deze lijnen te onderscheppen. Toch kunnen deze paden versleuteld worden met SSL Als u Secure Gateway Versie 2.0 gebruikt. In Citrix Secure Gateway 1.1 en eerder, verkeer naar de STA kan niet worden versleuteld met behulp van SSL.

als u het tweede segment wilt beveiligen, plaatst u een certificaat op de webserver voor het inventariseren van toepassingen en staat u clients toe alleen verbinding te maken als zij HTTPS gebruiken. Het derde segment is altijd beveiligd met SSL.

zelfs wanneer alle voorgaande links beveiligd zijn met SSL, zijn clients nog steeds kwetsbaar voor aanvallen door Trojaanse programma ‘ s die de activiteit van de client controleren. Om dit risico te beperken, adviseren uw gebruikers om verbinding te maken vanaf machines waar anti-virus en Trojan detectie software is geïnstalleerd.

Q: Hoe bescherm ik het STA-verkeer met SSL?

A: installeer eerst een Webservercertificaat op de kopie van IIS die als host fungeert voor de STA. Zie de IIS-documentatie voor meer informatie.

configureer uw Toepassingsserver en beveiligde gatewayserver om HTTPS te gebruiken bij het communiceren met de gateway. Bij verbinding via HTTPS moet altijd aan de volgende regels worden voldaan:

• u moet de STA adresseren met een volledig gekwalificeerde domeinnaam die overeenkomt met het onderwerp van het sta-servercertificaat.
• de machine die met de STA communiceert, moet in staat zijn de volledig gekwalificeerde domeinnaam van STA om te zetten in een passend IP-adres.
• de machine die communiceert met de STA moet de Certificate Authority (CA) vertrouwen die het sta servercertificaat heeft uitgegeven.
• om te voldoen aan de vereisten van het derde bullet-item, moet het CA-basiscertificaat op de beveiligde gatewayserver en op de toepassingsserver worden geïnstalleerd. Wees voorzichtig bij het installeren van het basiscertificaat: u kunt niet gewoon dubbelklikken op een basiscertificaatbestand en de wizard Certificaat importeren uitvoeren.

(dit betekent dat uw gebruikersaccount, niet de server of andere systeemservices, de CA vertrouwt.) Om een basiscertificaat te installeren voor gebruik met Citrix Secure Gateway of webinterface, volgt u de stappen:

1. voer Mmc uit.exe en voeg de module Certificaten toe.
2. wanneer u wordt gevraagd welke certificaten u wilt beheren, selecteert u Computeraccount en vervolgens lokale Computer.
3. vouw het knooppunt certificaten (lokale Computer) > Vertrouwde basiscertificeringsinstanties uit. Klik met de rechtermuisknop op Certificaten en selecteer vervolgens alle taken > importeren.
4. Blader om uw CA-basiscertificaat te selecteren en voltooi de ImportWizard.

Q: moet de STA altijd worden aangesproken met een volledig gekwalificeerde domeinnaam?

A: als u het verkeer naar de STA wilt beveiligen met SSL, moet elk onderdeel dat toegang heeft tot de STA, met inbegrip van uw gatewayserver en toepassingsserver, de STA aanspreken met de FQDN (fully qualified domain name) dat overeenkomt met het onderwerp van het servercertificaat dat door IIS op de STA wordt gebruikt. Bijvoorbeeld, in webinterface 2.0, zou het STA-adres worden ingevoerd als:https://sta-server.company.com/Scripts/CtxSta.dll

als u ervoor kiest om het verkeer naar de STA niet te beveiligen, kunt u de STA adres met behulp van een IP-adres, hostnaam, of FQDN.

Q: Hoe verander ik de STA-poort van 80 naar iets anders?

A: omdat de STA wordt bediend door IIS, wijzigt u de Sta-poort wanneer u de IIS-poort wijzigt. Het volgende voorbeeld illustreert hoe de IIS-poort van 80 naar 81 moet worden gewijzigd.

1. Open Internet Services Manager.
2. Klik met de rechtermuisknop op de Standaardwebsite en bekijk de eigenschappen.
3. wijzig op het tabblad website het TCP-poortnummer van 80 naar 81.
4. klik op OK.
   de vorige wijziging heeft ook invloed op andere bronnen die u op de STA-webserver heeft gepubliceerd. Als u de STA-communicatiepoort wilt wijzigen zonder dat dit gevolgen heeft voor andere webpagina ‘ s die door dezelfde webserver worden gehost, kunt u in IIS een nieuwe website maken met als enig doel de STA te hosten. Het volgende is een voorbeeld van hoe je een nieuwe website zou maken op poort 81 voor de STA.
5. Maak een nieuwe fysieke map aan, zoals C:\MYSTA op de harde schijf van uw webserver om te dienen als het document root voor de STA site.
6. Maak een submap onder MYSTA genaamd Scripts. Verplaats de volgende bestanden van uw bestaande STA naar de nieuwe Scripts map:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. Open Internet Services Manager.
8. Klik met de rechtermuisknop op de servernaam en selecteer Nieuwe > website.
9. Maak een nieuwe website genaamd “My STA site” en C:\MYSTA als de hoofdmap van het document.
10. bekijk de eigenschappen van uw nieuwe website en wijzig de tcp-poort naar 81.
11. onder Mijn STA-site in Internet Services Manager, klik met de rechtermuisknop op de map Scripts en bekijk de eigenschappen. Wijzig in het gedeelte Toepassingsinstellingen de machtigingen uitvoeren in ” Scripts en uitvoerbare bestanden.”

Opmerking: U kunt een andere mapnaam kiezen dan “Scripts”, maar houd er rekening mee dat Secure Gateway en alle toepassingsservers zoals webinterface ervan uitgaan dat de STA wordt gepubliceerd als /Scripts/CtxSta.dll dus je moet ook de STA URL bijwerken in de instellingen op die servers.

V: kan een aanvaller willekeurige Tickets naar de Gateway sturen om in te loggen?

A: een aanvaller moet een geldig ticket raden en het ook inwisselen binnen enkele milliseconden nadat de client het vraagt, maar voordat de gateway het claimt.

Q: Welke andere informatie is vereist om in te loggen dan een geldig STA-Ticket?

A: gebruikers hebben ook domeinreferenties of een XenApp-Serverticket nodig dat door de toepassingsserver wordt aangevraagd. (Een XenApp Server ticket is niet hetzelfde als een STA ticket.) Het voldoen aan de STA opent een pad alleen naar het vertrouwde netwerk voor een bepaalde server. Eenmaal daar, de gebruiker moet nog steeds verifiëren met geldige domeinreferenties.
V: Hoe kunnen we de levensduur van STA-Ticket instellen, waarna het Ticket ongeldig zou moeten zijn?
A: We kunnen de levensduur van het STA-ticket instellen door een volgende registersleutel aan te maken op de Aflevercontroller:
locatie: HKLM \ Software \ Citrix \ DesktopServer
naam: Xmlstaticketlifetimeinseconden
Type: Dword-waarde: Geef waarde in seconden (decimaal)
neem een reservekopie van het register voordat u de registerwaarden bewerkt, merk ook op dat een registerwijziging een herstart op het einde van de Controller vereist.

schaalbaarheid

Q: hoeveel sta ‘ s heb ik nodig?

A: de STA is alleen toegankelijk wanneer een gebruiker een toepassing start, het antwoord op deze vraag varieert van de ene implementatie tot de volgende.

V: loggen gebruikers ‘ s ochtends in via de gateway en draaien ze de hele dag één gepubliceerde applicatie of starten ze meerdere applicaties gedurende de dag?

A: De taken uitgevoerd door de STA zijn niet duur in CPU termen; het is een lichte XML-dienst beperkt alleen door de prestaties van IIS. In één test ondersteunde een low-range server met een 1GHz processor en 256 MB RAM meer dan 250 ticketverzoeken per seconde, terwijl het CPU-gebruik onder de 60% bleef.

V: Hoe kan ik sta-fouttolerantie garanderen?

A: met de volgende toepassingsservers kunt u meerdere STA-URL ‘ s invoeren bij het configureren van de parameters voor Secure Gateway:

• webinterface 2.0
• Secure Access Manager 2.0
• StoreFront

In alle gevallen, als een STA niet reageert, probeert de toepassingsserver een andere STA op de lijst. Elke gateway server op zijn beurt moet worden geconfigureerd met de STA URL en unieke STA ID voor elke ticket Autoriteit.

V: Hoe laad ik meerdere sta ‘ s?

A: speciale aandacht moet worden besteed aan het regelen van de taakverdeling voor veilige Ticketautoriteiten. Er kunnen verschillende methoden worden gebruikt om de verbinding tussen een toepassingsserver en de Sta ‘ s in evenwicht te brengen, maar een beveiligde gatewayserver moet altijd individueel contact opnemen met elke STA op basis van zijn STA-ID. Wanneer u het adres van elke STA configureert in het configuratieprogramma voor gateway — service, moet elk STA-adres het ware adres van de STA-server zijn.Voer hier niet het adres in van een hardware-load balancer, clusternaam of round-robin DNS-naam.

StoreFront, webinterface 2.0 en Secure Access Manager 2.0 alle ondersteunen round-robin load balancing van de Sta ’s wanneer meerdere sta’ s worden weergegeven. Als deze optie is ingeschakeld, is geen extra software of hardware voor taakverdeling vereist.

servers voor het inventariseren van toepassingen kunnen elke vorm van taakverdeling gebruiken om een ticketaanvraag uit te geven, omdat elk ontvangen ticket een veld bevat dat de unieke ID van de STA aangeeft die het heeft gegenereerd. Zolang elke STA-ID uniek is en alle gatewayservers de STA-ID kunnen omzetten naar een bepaald (niet load balanced) serveradres, slaagt de operatie en STA-verkeer is load balanced.

Q: Kan ik meerdere sta ‘ s gebruiken met Microsoft Netwerktaakverdeling?

A: netwerktaakverdeling kan niet worden gebruikt tussen de beveiligde gatewayserver en meerdere sta ‘ s. Als dit op deze manier is geconfigureerd, ontvangen gebruikers intermitterende weigeringen omdat de gateway tijdens het validatieproces mogelijk wordt gebalanceerd voor een autoriteit die oorspronkelijk het ticket van de gebruiker niet heeft gegenereerd.

Q: Kan ik een enkele STA delen met meerdere Farms, Gateways en Enumeratieservers?

A: Ja, een enkele STA kan worden gedeeld tussen een willekeurig aantal beveiligde gatewayservers en toepassingsservers. De STA is niet beperkt tot een bepaalde domein -, farm-of toepassingsserver. Het is een anonieme XML-dienst.

probleemoplossing

Q: Hoe moet IIS worden geconfigureerd om de STA te hosten?

de STA URL / Scripts / CtxSta.dll moet worden geserveerd met anonieme toegang ingeschakeld. Als u een webbrowser naar de STA-URL wijst, wordt u niet om een wachtwoord gevraagd.

• u moet de toestemming voor bronscripts en uitvoerbare bestanden in de IIS-metabase verlenen. Deze toestemming is niet nodig voor de volledige map /Scripts, maar kan worden ingesteld voor de CtxSta.dll-bestand afzonderlijk.
• schakel voor Secure Gateway versie 1.1 en eerder de SSL-vereisten en 128-bit SSL-opties niet in.
• standaard zijn de volgende accountrechten nodig:

op Windows 2000-servers

• heeft het iusr_machinename-account leestoegang tot CtxSta nodig.DLL.
• het iwam_machinename-account moet de toegang tot de map met logbestanden wijzigen, die standaard \Inetpub \ Scripts is.

op Windows 2003-Servers

• het iusr_machinename-account heeft leestoegang tot CtxSta nodig.DLL.
• het ingebouwde netwerkserviceaccount moet de toegang tot de map met logbestanden wijzigen, die standaard\Inetpub \ Scripts is.

Q: Hoe schakel ik Logging in bij de STA?

a: bewerk met Kladblok het bestand \Inetpub \ Scripts \ CtxSta.config op de STA server en zoek de regel die LogLevel=0 zegt. Voor maximale logging, verander dit naar LogLevel = 3. U moet de World Wide Web Publishing Service opnieuw opstarten voordat wijzigingen van kracht worden.
Opmerking: Nadat u logboekregistratie hebt ingeschakeld, moet het gebruikersaccount onder wiens gezag het STA uitvoert (standaard IUSR_MachineName op Windows 2000 of Netwerkservice op Windows 2003) schrijftoegang hebben tot de map logbestand, die standaard \Inetpub\Scripts is. U kunt ook de map van het logboekbestand wijzigen wanneer u CtxSta bewerkt.configuratiebestand.

Q: Waarom breekt de Microsoft IISLockDown Tool de STA?

A: Als u alle standaardinstellingen voor het hulpprogramma IISLockDown accepteert, is de map / Scripts uitgeschakeld. De STA wordt geà mplementeerd als een ISAPI-filter gepubliceerd als / Scripts / CtxSta.dll; door de map /Scripts uit te schakelen, weigert u toegang tot de STA. Schakel de map /Scripts in en sta Scripts en uitvoerbare bestanden toe om de STA te laten functioneren.

V: Hoe kan ik de STA testen om er zeker van te zijn dat deze goed werkt?

A: als u een webbrowser naar de STA-URL wijst, ziet u een lege witte pagina of het bericht “405 Resource Not Allowed.”Beide resultaten wijzen op een functionerend STA. U kunt op deze manier contact opnemen met de STA vanaf de console van uw beveiligde gatewayserver en ook vanaf elke toepassingsserver die is geconfigureerd om de gateway te gebruiken. Als u een authenticatiedialoogvenster ontvangt waarin u wordt gevraagd om een wachtwoord, wordt de STA niet anoniem gepubliceerd en moeten verificatievereisten worden verwijderd.

om te controleren of de toepassingsserver met succes STA-tickets aanvraagt, kijkt u naar de ICA-bestanden die deze genereert. In webinterface 2.0 kunt u bijvoorbeeld met de rechtermuisknop op een gepubliceerd toepassingspictogram klikken en het resultaat opslaan als starten.ica. Open lancering.ica in Kladblok en bekijk de Address = line. Voor een normale veilige Gateway-werking bevat de Adresparameter een ticket in plaats van een daadwerkelijk XenApp-serveradres.

v: hoe interpreteer ik de Sta-logbestanden?

A: als u logging inschakelt door LogLevel=3 in te stellen in CtxSta.config, ziet u de details van elk ticket en gegevens verzoek ontvangen door de STA. Vergeet niet dat een ticketaanvraag wordt gegenereerd door een toepassingsserver zoals een webinterface en dat een gegevensaanvraag wordt uitgevoerd door de Secure Gateway-service. Als in het logbestand meerdere ticketverzoeken maar geen gegevensverzoeken worden weergegeven, betekent dit dat de toepassingsserver de STA kan bereiken, maar de beveiligde gatewayserver niet. Het kan ook betekenen dat gebruikers de gateway server niet kunnen bereiken.

tijdens normale werking kan de functie voor het delen van sessies van de ICA-Client ertoe leiden dat tickets bij de STA worden aangevraagd, maar nooit door de gateway worden geclaimd. Overweeg het volgende scenario:

• een gebruiker logt in op de webinterface en klikt op het Outlook-pictogram. Webinterface vraagt een ticket aan bij de STA en stuurt het naar de gebruiker in een ICA-bestand.
• de gebruiker maakt verbinding via een beveiligde Gateway en presenteert het ticket voor toegang. De gateway valideert het ticket en stelt de gebruiker in staat om verbinding te maken met een XenApp-Server hosting Outlook.
• na een paar minuten te hebben gewerkt, keert de gebruiker terug naar de toepassingslijst op de webinterface-pagina en klikt op het Excel-pictogram. Webinterface vraagt een tweede ticket aan bij de STA en stuurt het naar de gebruiker in een ICA-bestand.
• voordat u verbinding maakt met een nieuwe server voor Excel, controleert de ICA-Client eerst of bestaande servers waarmee de client al verbonden is, de Excel gepubliceerde toepassing beschikbaar hebben.
• de server waarop de client Outlook al draait, heeft ook Excel geïnstalleerd, dus de ICA-Client verwijdert het ICA-bestand en start Excel binnen de bestaande ICA-sessie.
• het tweede ticket dat door de webinterface wordt aangevraagd, wordt nooit gebruikt omdat een tweede ICA-sessie niet nodig was. Standaard, het ticket time out na 100 seconden.

dit scenario zou resulteren in een reeks van Sta log file entries vergelijkbaar met de volgende:

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

meer verdachte activiteiten kunnen er ongeveer zo uitzien:

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

hier zien we wat lijkt op een aanvaller proberen verschillende tickets een voor een, het verhogen van de ticket-ID bij elke poging. In elk geval werd de verbinding geweigerd en registreerde het STA een vermelding dat de klant een ticket presenteerde dat niet als geldig werd erkend. Om het IP-adres van de aanvaller te identificeren, zoekt u naar het volgende bericht in de LogViewer op de beveiligde gatewayserver:

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

interpreteer sommige “Ticket NOT found” berichten niet als een aanval. De Win32 ICA-Client kan proberen opnieuw verbinding te maken met een niet-verbonden sessie als de netwerkverbinding van de gebruiker tijdelijk wordt verbroken. De functie Auto Client Reconnect werkt niet voor Citrix Secure Gateway-gebruikers, omdat de client tijdens elke poging om opnieuw verbinding te maken het gebruikte STA-ticket waarmee de client oorspronkelijk verbonden was, opnieuw indient. De client probeert meestal drie of meer keer opnieuw verbinding te maken voordat hij opgeeft, dus u zult drie of meer” Ticket niet gevonden ” berichten zien die verwijzen naar hetzelfde ticket in het STA log voor elke gebeurtenis van dit probleem. Clientherverbindingspogingen worden gekenmerkt door pogingen tot hergebruik van een eerder succesvol ticket:

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

Koppel Auto Client opnieuw verbinden voor veilige Gateway gebruikers door TransportReconnectEnabled=Off toe te voegen aan de sectie van het ICA bestand. De juiste manier om opnieuw verbinding te maken met een sessie zonder verbinding bij gebruik van Secure Gateway is om terug te keren naar de toepassingsserver en opnieuw op het toepassingspictogram te klikken.

Q: Wat zijn enkele veelvoorkomende configuratiefouten die worden gezien door Citrix Technical Support?

• de map / Scripts of de gehele Standaardwebsite is uitgeschakeld als gevolg van het uitvoeren van IISLockDown of het volgen van het bedrijfsbeleid voor het beschermen van webservers.
• loggen is ingeschakeld in CtxSta.config, maar het gebruikersaccount onder wiens gezag de STA uitvoert (iusr_machinename standaard) heeft geen schrijftoegang tot de map logbestand.
• IIS op de STA-server is geconfigureerd om SSL te vereisen, maar beveiligde Gateway is geconfigureerd om toegang te krijgen tot de STA met behulp van normale HTTP.
• als het opstarten van de app mislukt, moet eerst worden gecontroleerd of de Sta ’s op StoreFront/webinterface en NetScaler op exact dezelfde manier of niet worden gegeven, dat wil zeggen dat als de Sta’ s worden gegeven als IP-adres op SF/WI het moet worden gegeven met behulp van IP-adres op NS en op dezelfde manier in het geval van FQDN.