FAQ: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

Nota: Gli stessi principi e concetti valgono anche per NetScaler Gateway.

Questo articolo risponde ad alcune domande frequenti riguardanti la Citrix Secure Ticket Authority (STA). Le domande sono suddivise nelle seguenti quattro categorie:

Panoramica

D: Qual è l’Autorità dei biglietti sicuri?
D: Quali prodotti Citrix interagiscono con la STA?
D: Perché è necessario lo STA?
D: Come viene implementato il servizio STA?
Q: Esiste una versione di STA che non richiede IIS?
D: Dove risiede il server STA?
D: Quali sono le differenze tra le diverse versioni di STA?

Sicurezza

D: Come viene generato il ticket STA?
D: Che cosa costituisce un biglietto STA?
D: Il ticket è convalidato rispetto alla Workstation?
D: Il biglietto viene cancellato dopo l’uso?
D: I biglietti sono mai scritti su Disco presso la STA?
D: È possibile per qualcuno dirottare un biglietto?
D: Come posso proteggere il traffico STA con SSL?
Q: Lo STA deve essere sempre indirizzato utilizzando un nome di dominio completo?
D: Come posso cambiare la porta STA da 80 a qualcos’altro?
D: Un utente malintenzionato può inviare Ticket casuali al Gateway per accedere?
D: Quali altre informazioni sono necessarie per effettuare l’accesso oltre a un ticket STA valido?
Q: Come possiamo fissare il tempo di vita del biglietto di STA, dopo di che il biglietto dovrebbe essere invalido?

Scalabilità

D: Quanti STAS ho bisogno?
Q: Gli utenti accedono tramite il gateway al mattino ed eseguono una singola applicazione pubblicata tutto il giorno o lanciano diverse applicazioni durante il giorno?
D: Come posso garantire la tolleranza ai guasti STA?
D: Come faccio a bilanciare il carico di più STAS?
D: È possibile utilizzare più STA con il bilanciamento del carico di rete Microsoft?
D: È possibile condividere un singolo STA con più farm, gateway e server di enumerazione?

Risoluzione dei problemi

D: Come configurare IIS per ospitare la STA?
D: Come posso abilitare la registrazione allo STA?
Q: Perché lo strumento Microsoft IISLockDown rompe lo STA?
D: Come posso testare la STA per essere sicuro che funzioni correttamente?
D: Come posso interpretare i file di registro STA?
D: Quali sono alcuni degli errori di configurazione più comuni riscontrati dal supporto tecnico Citrix?

Panoramica

D: Qual è l’autorità dei biglietti sicuri?

A: La Secure Ticket Authority (STA) è un servizio web XML che scambia le informazioni del server XenApp per i biglietti generati casualmente. Viene utilizzato per controllare l’accesso per un server Citrix Secure Gateway.

D: Quali prodotti Citrix interagiscono con STA?

A: XenMobile, Interfaccia Web, StoreFront, XenApp Secure Access Manager, NetScaler Gateway e Citrix Secure Gateway interagiscono con STA. In questo articolo, i seguenti tipi di server sono raggruppati in un’unica categoria denominata server di enumerazione delle applicazioni:

• Interfaccia Web 2.0 o successiva
• Secure Access Manager 2.0 o versioni successive
• StoreFront
• I server di enumerazione delle applicazioni sono responsabili dell’autenticazione degli utenti, dell’enumerazione delle icone delle applicazioni pubblicate e della produzione di un file IC per un client che consente loro di connettersi a un’applicazione pubblicata tramite un server Gateway sicuro.

D: Perché è necessario lo STA?

A: Nelle distribuzioni Citrix Secure Gateway, il server gateway non esegue l’autenticazione delle richieste in arrivo. Invece, il server gateway rinvia l’autenticazione a un server di enumerazione delle applicazioni e utilizza la STA per garantire che ogni utente sia autenticato. I server di enumerazione delle applicazioni richiedono ticket solo per gli utenti che sono già autenticati sul server Web. Se gli utenti dispongono di ticket STA validi, il gateway presuppone che abbiano superato i controlli di autenticazione sul server Web e dovrebbe essere consentito l’accesso.

Questo design consente al server Citrix Secure Gateway di ereditare qualsiasi metodo di autenticazione nel server Web. Ad esempio, se il server di interfaccia Web è protetto con RSA SecurID, in base alla progettazione solo gli utenti autenticati con SecurID possono attraversare il server Gateway sicuro.

D: Come viene implementato il servizio STA?

A: STA è scritto come estensione ISAPI per Microsoft Internet Information Services (IIS). L’estensione si chiama CtxSta.dll ed è ospitato nella cartella / Scripts per impostazione predefinita. Altri componenti comunicano con lo STA utilizzando XML su HTTP.

I server di enumerazione delle applicazioni richiedono ticket all’avvio dell’applicazione inviando dati allo STA come parte di una richiesta di ticket. I dati inviati allo STA includono l’indirizzo del server XenApp a cui l’utente si connetterà e, nel caso di Web Interface 2.0 e Secure Access Manager 2.0, informazioni estese sul nome dell’utente corrente e sull’applicazione pubblicata che l’utente desidera eseguire. La STA risponde generando un ticket e inviandolo al server di enumerazione dell’applicazione. Questo ticket e i suoi dati corrispondenti rimangono in memoria presso lo STA per un numero configurabile di secondi (100 per impostazione predefinita).
Il server di enumerazione delle applicazioni costruisce un file IC per l’utente e inserisce il ticket STA nel campo Indirizzo del file IC. Quando il client si connette al gateway sicuro, il ticket viene presentato e il gateway deve convalidare il ticket prima di stabilire una sessione sicura per il client. Il gateway esegue una richiesta di dati inviando il ticket allo STA e chiedendo in cambio i dati corrispondenti. Se convalidato correttamente, lo STA inoltra i dati originali al gateway e il gateway stabilisce un relè tra l’utente finale e il server XenApp.

Sia le richieste di ticket che le richieste di dati vengono eseguite come documenti di richiesta/risposta XML.

D: Esiste una versione di STA che non richiede IIS?

A: No, in questo momento IIS è necessario per ospitare la STA. Ricorda che la STA non deve essere esposta a una rete non affidabile come Internet; la STA risiede sulla rete attendibile e vi si accede solo dai server di enumerazione gateway e applicazione.

D: Dove risiede il server STA?

A: Il server STA può essere posizionato ovunque purché il gateway sicuro e i server di enumerazione delle applicazioni possano raggiungerlo. Citrix consiglia di posizionare lo STA sulla rete attendibile o su una parte separata del firewall interno, ma non ci sono requisiti per il server STA diversi da IIS. Lo STA non deve appartenere a nessun dominio, Server farm XenApp, Secure Access Manager farm o altro server Web interno, ma condividere lo STA con un’altra funzione è pratica comune. Uno STA è incluso automaticamente come parte della configurazione Secure Access Manager 2.0; molti amministratori trovano conveniente localizzare lo STA su un server XenApp.

D: Quali sono le differenze tra le diverse versioni di STA?

A: Non ci sono differenze funzionali materiali tra le versioni 1.0 e 1.1, ma quando si utilizza la STA 2.0 con interfaccia Web 2.0 o Secure Access Manager 2.0, informazioni estese vengono aggiunte alla richiesta di ticket: il nome dell’utente e l’applicazione che l’utente desidera eseguire. Questi dati estesi vengono utilizzati dal servizio gateway per visualizzare i dettagli relativi a ciascuna sessione gateway nella console di gestione Secure Gateway 2.0.

Se Secure Gateway 2.0 è configurato per utilizzare uno STA precedente dalla versione 1.1 o 1.0, gli utenti possono connettersi alle applicazioni, ma la console di gestione Secure Gateway mostrerà “N / A” per il nome utente e il nome dell’applicazione associati a ciascuna sessione IC. Per visualizzare le informazioni estese nel Secure Gateway 2.0 console di gestione, è necessario utilizzare la versione 2.0 o successiva di STA e utilizzare Secure Access Manager 2.0 o Web Interface 2.0 come server di enumerazione delle applicazioni.

Sicurezza

D: Come viene generato il ticket STA?

A: L’estensione ISAPI CtxSta.dll utilizza la generazione di numeri pseudo-casuali per produrre una stringa esadecimale di 16 byte. Per motivi di sicurezza, Citrix non rivela i passaggi esatti utilizzati per produrre questa sequenza casuale di caratteri.

D: Cosa costituisce un biglietto STA?

A: Il formato di codifica è una stringa del modulo:

;STA_VERSION; STA_ID; TICKET

Dove:

• STA_VERSION è un campo numerico che identifica la versione di STA. Attualmente gli unici valori validi per questo campo sono “10 “per le versioni STA 1.0 e 1.1 e” 20 ” per la versione STA 2.0.
• STA_ID è una sequenza di 0-16 caratteri che rappresentano un nome arbitrario assegnato dall’amministratore a un particolare STA. Nella versione 1.x, questa stringa di default è STA01, STA02 e così via. Quando lo STA viene installato automaticamente come parte di Secure Access Manager 2.0, l’ID STA è un hash del nome del server. Quando più STA sono condivisi da un singolo server gateway, ogni ID STA deve essere univoco. Ciò consente al gateway di individuare lo STA che ha creato il biglietto e tornare a tale STA per la convalida del biglietto. Un ticket creato su STA01 non esisterà su STA02.
• TICKET è una sequenza generata casualmente di 32 caratteri alfabetici o numerici maiuscoli.

  Per esempio:
  ;10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

D: Il ticket è convalidato rispetto alla Workstation?

A: No, non c’è nulla che leghi un ticket a una particolare workstation. È teoricamente possibile che un ticket venga richiesto dalla Workstation A e quindi utilizzato dalla Workstation B. Per mitigare questo rischio:

• Utilizzare sempre HTTPS tra il client e il server di enumerazione dell’applicazione per impedire a un utente malintenzionato di intercettare il ticket mentre viaggia da server a client.
• Riduci il più possibile il time-to-live del biglietto per ridurre la quantità di tempo che un utente malintenzionato avrebbe dovuto trasferire il biglietto dalla Macchina A alla Macchina B.

Ricorda che un ticket emesso dallo STA può essere utilizzato una sola volta, quindi se l’utente previsto sulla Macchina A si connette correttamente, il ticket non è valido per tutti i futuri tentativi di connessione dalla Macchina A o dalla Macchina B.

D: Il ticket viene eliminato dopo l’uso?

R: Sì, i ticket vengono eliminati immediatamente dopo una richiesta di dati riuscita in modo che possano essere utilizzati una sola volta. Vengono eliminati anche dopo un timeout configurabile (predefinito 100 secondi) se non utilizzati.

D: I biglietti sono mai scritti su Disco presso la STA?

A: Solo quando la registrazione dettagliata è abilitata impostando LogLevel = 3 in CtxSta.config. In caso contrario, lo STA mantiene tutti i ticket in sospeso (ticket richiesti da un server di enumerazione delle applicazioni ma non ancora convalidati da un gateway sicuro) utilizzando un database in memoria. I dati XML vengono sempre inviati allo STA utilizzando il comando HTTP POST, quindi nessun dato significativo del ticket viene mai scritto nei registri del server Web STA.

D: È possibile per qualcuno dirottare un biglietto?

A: Durante il normale funzionamento, un biglietto deve percorrere i seguenti quattro segmenti della rete:

• Dal PERSONALE per l’applicazione di enumerazione server
• Dall’applicazione di enumerazione server al client
• Dal client Secure Gateway server
• Dal gateway di STA

Il primo e l’ultimo segmenti di esistere solo tra i server in DMZ e il PERSONALE di fiducia di rete, il che significa che un intruso avrebbe bisogno di avere accesso alla rete per intercettare il biglietto lungo queste linee. Tuttavia, questi percorsi possono essere crittografati con SSL se si utilizza Secure Gateway Versione 2.0. In Citrix Secure Gateway 1.1 e versioni precedenti, il traffico verso la STA non può essere crittografato utilizzando SSL.

Per proteggere il secondo segmento, inserire un certificato sul server Web di enumerazione delle applicazioni e consentire ai client di connettersi solo se utilizzano HTTPS. Il terzo segmento è sempre protetto con SSL.

Anche quando tutti i link precedenti sono protetti con SSL, i client sono ancora vulnerabili agli attacchi dei programmi Trojan che monitorano l’attività del client. Per mitigare questo rischio, consiglia agli utenti di connettersi dalle macchine in cui è installato il software di rilevamento antivirus e Trojan.

D: Come posso proteggere il traffico STA con SSL?

A: Innanzitutto, installare un certificato del server Web sulla copia di IIS che ospita la STA. Per ulteriori informazioni, consultare la documentazione di IIS.

Configurare il server di enumerazione delle applicazioni e il server gateway sicuro per utilizzare HTTPS quando si comunica con il gateway. Quando ci si connette tramite HTTPS, le seguenti regole devono sempre essere soddisfatte:

• È necessario indirizzare lo STA utilizzando un nome di dominio completo che corrisponda all’oggetto del certificato del server STA.
• La macchina che comunica con la STA deve essere in grado di risolvere il nome di dominio completo con un indirizzo IP appropriato.
• La macchina che comunica con la STA deve fidarsi dell’Autorità di certificazione (CA) che ha emesso il certificato del server STA.
• Per soddisfare i requisiti del terzo elemento bullet, il certificato radice CA deve essere installato sul server Secure Gateway e sul server di enumerazione delle applicazioni. Fare attenzione quando si installa il certificato principale: non è sufficiente fare doppio clic su un file di certificato principale ed eseguire la procedura guidata di importazione del certificato.

(Ciò indica che il tuo account utente, non il server o qualsiasi servizio di sistema, si fida della CA.) Per installare un certificato root da utilizzare con Citrix Secure Gateway o l’interfaccia Web, seguire i passaggi:

1. Eseguire Mmc.exe e aggiungere i certificati snap-in.
2. Quando viene chiesto quali certificati gestire, selezionare Account computer e quindi Computer locale.
3. Espandere il nodo Certificati (Computer locale) >Autorità di certificazione root attendibili. Fare clic con il pulsante destro del mouse su Certificati, quindi selezionare Tutte le attività > Importa.
4. Selezionare il certificato principale CA e completare l’importazione guidata.

D: Lo STA deve essere sempre indirizzato utilizzando un nome di dominio completo?

A: Se si intende proteggere il traffico verso la STA utilizzando SSL, qualsiasi componente che accede alla STA, incluso il server gateway e il server di enumerazione delle applicazioni, deve indirizzare la STA utilizzando il nome di dominio completo (FQDN) che corrisponde all’oggetto del certificato server utilizzato da IIS nella STA. Ad esempio, nell’interfaccia Web 2.0, l’indirizzo STA verrà inserito come:https://sta-server.company.com/Scripts/CtxSta.dll

Se si sceglie di non proteggere il traffico verso lo STA, è possibile indirizzarlo utilizzando un indirizzo IP, un nome host o un FQDN.

D: Come posso cambiare la porta STA da 80 a qualcos’altro?

A: Poiché la STA è servita da IIS, si modifica la porta STA quando si modifica la porta IIS. L’esempio seguente illustra come modificare la porta IIS da 80 a 81.

1. Apri Gestore Servizi Internet.
2. Fare clic con il pulsante destro del mouse sul sito Web predefinito e visualizzare le Proprietà.
3. Nella scheda Sito Web, modificare il numero di porta TCP da 80 a 81.
4. Fare clic su OK.
   La modifica precedente influisce anche su qualsiasi altra risorsa pubblicata dal server Web STA. Se si desidera modificare la porta di comunicazione STA senza influire su altre pagine Web ospitate dallo stesso server Web, è possibile creare un nuovo sito Web in IIS al solo scopo di ospitare la STA. Di seguito è riportato un esempio di come si creerebbe un nuovo sito Web sulla porta 81 per la STA.
5. Crea una nuova cartella fisica come C:\ MYSTA sul disco rigido del server Web per servire come radice del documento per il sito STA.
6. Crea una sottodirectory sotto MYSTA chiamata Scripts. Sposta i seguenti file dal tuo STA esistente nella nuova cartella Scripts:
   • CtxSta.dll
   • CtxSta.configurazione
   • ctxxmlss.txt
7. Apri Gestore Servizi Internet.
8. Fare clic con il pulsante destro del mouse sul nome del server e selezionare Nuovo sito Web >.
9. Creare un nuovo sito Web chiamato “My STA site” e C:\MYSTA come directory principale del documento.
10. Visualizzare le proprietà del nuovo sito web e modificare la porta TCP su 81.
11. Sotto Il mio sito STA in Internet Services Manager, fare clic con il pulsante destro del mouse sulla cartella Scripts e visualizzare le proprietà. Nella sezione Impostazioni dell’applicazione, modificare le autorizzazioni di esecuzione in ” Script ed eseguibili.”

Nota: È possibile scegliere un nome di cartella diverso da “Script”, ma tenere presente che Secure Gateway e tutti i server di enumerazione delle applicazioni come l’interfaccia Web presuppongono che la STA sia pubblicata come /Scripts/CtxSta.dll quindi sarà anche necessario aggiornare l’URL STA nelle impostazioni su quei server.

D: Un utente malintenzionato può inviare Ticket casuali al Gateway per accedere?

A: Un utente malintenzionato dovrebbe indovinare un ticket valido e anche riscattarlo entro pochi millisecondi dopo che il client lo richiede ma prima che il gateway lo richieda.

D: Quali altre informazioni sono necessarie per effettuare l’accesso oltre a un ticket STA valido?

R: Gli utenti necessitano anche di credenziali di dominio o di un ticket Server XenApp richiesto dal server di enumerazione delle applicazioni. (Un ticket Server XenApp non è lo stesso di un ticket STA.) Soddisfare la STA apre un percorso solo alla rete attendibile per un particolare server. Una volta lì, l’utente deve comunque autenticarsi con credenziali di dominio valide.
Q: Come possiamo fissare il tempo di vita del biglietto di STA, dopo di che il biglietto dovrebbe essere invalido?
A: Possiamo impostare la durata del ticket STA creando una seguente chiave di registro sul Controller di consegna:
Posizione: HKLM\Software\Citrix\DesktopServer
Nome: XmlStaTicketLifetimeInSeconds
Tipo: Valore Dword: Dare valore in secondi (decimale)
Si prega di prendere un backup del registro prima di modificare i valori del registro, si noti inoltre che una modifica del registro richiederebbe un riavvio all’estremità del Controller.

Scalabilità

D: Quanti STAS ho bisogno?

A: La STA è accessibile solo quando un utente avvia un’applicazione, la risposta a questa domanda varia da una distribuzione all’altra.

D: Gli utenti accedono al gateway al mattino ed eseguono una singola applicazione pubblicata tutto il giorno o lanciano diverse applicazioni durante il giorno?

A: I compiti svolti dallo STA non sono costosi in termini di CPU; è un servizio XML leggero limitato solo dalle prestazioni di IIS. In un test, un server di fascia bassa con un processore da 1 GHz e 256 MB di RAM ha supportato oltre 250 richieste di ticket al secondo mentre l’utilizzo della CPU è rimasto inferiore al 60%.

D: Come posso garantire la tolleranza ai guasti STA?

A: I seguenti server di enumerazione delle applicazioni consentono di immettere più URL STA durante la configurazione dei parametri per Secure Gateway:

• Interfaccia Web 2.0
• Gestione accesso sicuro 2.0
• StoreFront

In tutti i casi, se uno STA non risponde, il server di enumerazione delle applicazioni tenta un altro STA nell’elenco. Ogni server gateway a sua volta deve essere configurato con l’URL STA e l’ID STA univoco per ogni autorità ticket.

D: Come faccio a bilanciare il carico di più STAS?

A: È necessario prestare particolare attenzione quando le autorità di sicurezza del ticket di bilanciamento del carico. È possibile utilizzare una varietà di metodi per bilanciare il carico della connessione tra un server di enumerazione delle applicazioni e gli STAS, ma un server Gateway sicuro deve sempre contattare ogni STA individualmente in base al suo ID STA. Quando si configura l’indirizzo di ogni STA nello strumento di configurazione del servizio gateway, ogni indirizzo STA deve essere il vero indirizzo del server STA-non inserire l’indirizzo di qualsiasi bilanciamento del carico hardware, nome cluster o nome DNS round-robin qui.

StoreFront, Interfaccia Web 2.0, e Secure Access Manager 2.0 tutti supportano il bilanciamento del carico round-robin degli STAS quando sono elencati più STAS. Quando questa opzione è abilitata, non è necessario alcun software o hardware aggiuntivo per il bilanciamento del carico.

I server di enumerazione delle applicazioni possono utilizzare qualsiasi forma di bilanciamento del carico per l’emissione di una richiesta di ticket poiché ogni ticket ricevuto contiene un campo che indica l’ID univoco dello STA che lo ha generato. Finché ogni ID STA è univoco e tutti i server gateway possono risolvere l’ID STA su un particolare indirizzo del server (non bilanciato dal carico), l’operazione ha esito positivo e il traffico STA è bilanciato dal carico.

Q: Posso utilizzare diverse STA con il bilanciamento del carico di rete Microsoft?

A: Impossibile utilizzare il bilanciamento del carico di rete tra il server Secure Gateway e più STA. Se configurato in questo modo, gli utenti ricevono negazioni intermittenti perché, durante il processo di convalida del ticket, il gateway potrebbe essere bilanciato dal carico su un’autorità che non ha generato originariamente il ticket dell’utente.

D: È possibile condividere un singolo STA con più farm, gateway e server di enumerazione?

A: Sì, un singolo STA può essere condiviso tra qualsiasi numero di server gateway sicuri e server di enumerazione delle applicazioni. Lo STA non è limitato a un particolare server di enumerazione di domini, farm o applicazioni. Si tratta di un servizio XML anonimo.

Risoluzione dei problemi

D: Come configurare IIS per ospitare la STA?

L’URL STA / Scripts / CtxSta.dll deve essere servito con accesso anonimo abilitato. Se si punta qualsiasi browser Web per l’URL STA non verrà richiesta una password.

• È necessario concedere l’autorizzazione agli script di risorse e agli eseguibili nella metabase IIS. Questa autorizzazione non è necessaria per l’intera cartella /Scripts ma può essere impostata per CtxSta.file dll singolarmente.
• Per Secure Gateway Versione 1.1 e precedenti, non abilitare le opzioni Richiedi SSL e Richiedi SSL a 128 bit.
• Per impostazione predefinita, sono necessarie le seguenti autorizzazioni account:

Sui server Windows 2000

• L’account IUSR_MachineName richiede l’accesso in lettura a CtxSta.DLL.
• L’account IWAM_MachineName deve Modificare l’accesso alla directory del file di log, che è \Inetpub\Scripts per impostazione predefinita.

Sui server Windows 2003

• L’account IUSR_MachineName richiede l’accesso in lettura a CtxSta.DLL.
• L’account del servizio di rete integrato deve Modificare l’accesso alla directory del file di registro, che è \Inetpub\Scripts per impostazione predefinita.

D: Come posso abilitare la registrazione allo STA?

A: Utilizzando il blocco note, modificare il file \ Inetpub \ Scripts \ CtxSta.config sul server STA e individuare la riga che dice LogLevel=0. Per la registrazione massima, cambia questo in LogLevel = 3. Affinché le modifiche abbiano effetto, è necessario riavviare il servizio di pubblicazione World Wide Web.
Nota: dopo aver abilitato la registrazione, l’account utente sotto la cui autorità viene eseguito STA (IUSR_MachineName su Windows 2000 o Servizio di rete su Windows 2003 per impostazione predefinita) deve avere accesso in scrittura alla directory del file di registro, che è \Inetpub\Scripts per impostazione predefinita. È inoltre possibile modificare la directory del file di registro quando si modifica CtxSta.config.

D: Perché lo strumento Microsoft IISLockDown interrompe lo STA?

A: Se si accettano tutte le impostazioni predefinite per lo strumento IISLockDown, la cartella / Scripts è disabilitata. Lo STA è implementato come un filtro ISAPI pubblicato come / Scripts / CtxSta.dll; disabilitando la directory / Scripts, si nega l’accesso alla STA. Abilitare la cartella / Scripts e consentire l’accesso agli script e agli eseguibili per il funzionamento dello STA.

D: Come posso testare la STA per essere sicuri che funzioni correttamente?

A: Se si punta un browser Web all’URL STA, verrà visualizzata una pagina bianca vuota o il messaggio ” 405 Resource Not Allowed.”Uno di questi risultati indica una STA funzionante. È possibile contattare lo STA in questo modo dalla console del server Secure Gateway e anche da qualsiasi server di enumerazione delle applicazioni configurato per utilizzare il gateway. Se si riceve una finestra di dialogo di autenticazione che richiede una password, lo STA non viene pubblicato in modo anonimo e i requisiti di autenticazione devono essere rimossi.

Per verificare che il server di enumerazione delle applicazioni richieda correttamente i ticket STA, esaminare i file generates generati. Ad esempio, da Web Interface 2.0, è possibile fare clic con il pulsante destro del mouse sull’icona di un’applicazione pubblicata e salvare il risultato come avvio.ic. Apri lancio.Notepad nel blocco note e visualizzare l’indirizzo = linea. Per il normale funzionamento del Gateway sicuro, il parametro Address conterrà un ticket anziché un indirizzo server XenApp effettivo.

D: Come posso interpretare i file di registro STA?

A: Se si abilita la registrazione impostando LogLevel = 3 in CtxSta.config, vedrete i dettagli di ogni biglietto e richiesta di dati ricevuti dalla STA. Ricorda che una richiesta di ticket viene generata da un server di enumerazione delle applicazioni come l’interfaccia Web e una richiesta di dati viene eseguita dal servizio Secure Gateway. Se il file di registro mostra diverse richieste di ticket ma nessuna richiesta di dati, ciò implica che il server di enumerazione delle applicazioni può raggiungere lo STA ma il server Gateway sicuro non può. Può anche implicare che gli utenti non possono raggiungere il server gateway.

Durante il normale funzionamento, la funzione di condivisione della sessione del client IC può causare la richiesta di ticket da parte dello STA ma mai richiesta dal gateway. Considera il seguente scenario:

• Un utente accede all’interfaccia Web e fa clic sull’icona di Outlook. L’interfaccia Web richiede un ticket dallo STA e lo invia all’utente in un file IC.
• L’utente si connette tramite Secure Gateway e presenta il biglietto di ingresso. Il gateway convalida il ticket e consente all’utente di connettersi a un server XenApp che ospita Outlook.
• Dopo aver lavorato per alcuni minuti, l’utente ritorna all’elenco delle applicazioni nella pagina dell’interfaccia Web e fa clic sull’icona di Excel. L’interfaccia Web richiede un secondo ticket dallo STA e lo invia all’utente in un file IC.
• Prima di connettersi a un nuovo server per Excel, il client Excel verifica innanzitutto se i server esistenti a cui il client è già connesso hanno l’applicazione pubblicata di Excel disponibile.
• Anche il server in cui il client sta già eseguendo Outlook ha installato Excel, quindi il client IC scarta il file Excel e avvia Excel all’interno della sessione existing esistente.
• Il secondo ticket richiesto dall’interfaccia Web non viene mai utilizzato perché non era necessaria una seconda sessione IC. Per impostazione predefinita, il biglietto scade dopo 100 secondi.

Questo scenario comporterebbe una serie di voci del file di registro STA simili alle seguenti:

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

Altre attività sospette potrebbero assomigliare a questo:

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

Qui vediamo quello che sembra essere un attaccante che prova vari biglietti uno alla volta, incrementando l’ID del biglietto ad ogni tentativo. In ogni caso, la connessione è stata rifiutata e lo STA ha registrato una voce che indica che il client ha presentato un ticket che non è stato riconosciuto come valido. Per identificare l’indirizzo IP dell’attaccante, cercare il seguente messaggio nel visualizzatore eventi sul server Secure Gateway:

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

Non interpretare alcuni messaggi” Ticket NOT found ” come un attacco. Il client Win32 Win può tentare di riconnettersi a una sessione disconnessa se la connessione di rete dell’utente viene interrotta momentaneamente. La funzione di riconnessione automatica del client non funziona per gli utenti Citrix Secure Gateway perché durante ogni tentativo di riconnessione, il client invia nuovamente il ticket STA utilizzato con cui si è originariamente connesso. Il client di solito tenta di riconnettersi tre o più volte prima di rinunciare, quindi vedrai tre o più messaggi “Ticket NOT found” che fanno riferimento allo stesso ticket nel registro STA per ogni occorrenza di questo problema. I tentativi di riconnessione del client sono caratterizzati dal tentativo di riutilizzo di un ticket precedentemente riuscito:

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

Disconnettere la riconnessione automatica del client per gli utenti Secure Gateway aggiungendo TransportReconnectEnabled = Off alla sezione del file IC. Il modo corretto per riconnettersi a una sessione disconnessa quando si utilizza Secure Gateway consiste nel tornare al server di enumerazione dell’applicazione e fare nuovamente clic sull’icona dell’applicazione.

D: Quali sono alcuni degli errori di configurazione comuni osservati dal supporto tecnico Citrix?

• La cartella /Scripts o l’intero sito Web predefinito è disabilitata in seguito all’esecuzione di IISLockDown o all’adesione alla politica aziendale per la protezione dei server Web.
• La registrazione è abilitata in CtxSta.config, ma l’account utente sotto la cui autorità esegue STA (IUSR_MachineName per impostazione predefinita) non ha accesso in scrittura alla directory del file di log.
• IIS sul server STA è configurato per richiedere SSL, ma Secure Gateway sono configurati per accedere alla STA utilizzando il normale HTTP.
• Se l’avvio dell’app non riesce, la prima cosa da controllare è se gli STAS sull’interfaccia StoreFront/Web e NetScaler sono dati esattamente allo stesso modo o meno, cioè se gli STAS sono dati come indirizzo IP su SF/WI dovrebbe essere dato usando l’indirizzo IP su NS e allo stesso modo in caso di FQDN.