FAQ: Citrix Secure Gateway/ NetScaler Gateway Secure Ticket Authority

Nota: os mesmos princípios e conceitos também são bons para NetScaler Gateway.Este artigo responde a algumas perguntas frequentes sobre a Citrix Secure Ticket Authority (STA). As perguntas estão divididas em quatro categorias:

visão geral

Q: Qual é a autoridade segura de bilhetes?
Q: Quais os produtos Citrix que interagem com o STA?
Q: Por que o STA é necessário?
Q: Como é implementado o serviço STA?
Q: Existe uma versão do STA que não precise de IIS?
Q: onde reside o servidor STA?
Q: Quais são as diferenças entre as diferentes versões do STA?

segurança

Q: Como é gerado o bilhete STA?
Q: O que constitui um bilhete STA?
Q: O Bilhete é validado contra o Posto de trabalho?
Q: O Bilhete é suprimido após a utilização?
Q: os bilhetes são alguma vez escritos em disco na STA?Q: é possível alguém sequestrar um bilhete?
Q: Como proteger o tráfego STA com SSL?
Q: O STA deve ser sempre endereçado usando um nome de domínio totalmente qualificado?
Q: Como posso mudar o porto de STA de 80 para outra coisa?Q: um atacante pode enviar bilhetes aleatórios para o Gateway para entrar?
Q: Que outras informações são necessárias para Logon que não um bilhete de identidade válido?
Q: Como podemos definir o tempo de vida do Ticket STA, após o qual o ticket deve ser inválido?

escalabilidade

Q: de quantos STAs preciso?
Q: Os UTILIZADORES fazem logon através do gateway de manhã e executam uma única aplicação publicada o dia todo ou lançam várias aplicações durante todo o dia?
Q: Como posso garantir tolerância de falha STA?
Q: Como carregar vários STAs?
Q: Posso usar vários STAs com o equilíbrio de carga da Rede Microsoft?
Q: Posso compartilhar um único STA com várias fazendas, Gateways e Servidores de enumeração?

solução de problemas

Q: Como deve ser configurado o IIS para hospedar o STA?
Q: Como posso activar o registo no STA?
Q: Por que a ferramenta Microsoft IISLockDown quebra o STA?
Q: Como posso testar o STA para ter certeza de que está funcionando corretamente?
Q: Como interpretar os ficheiros de Registo STA?
Q: Quais são alguns dos erros de configuração comuns vistos pelo suporte técnico Citrix?

Overview

Q: What is the Secure Ticket Authority?

A: The Secure Ticket Authority (STA) é um serviço Web XML que troca informações do servidor XenApp por bilhetes gerados aleatoriamente. Ele é usado para controlar o acesso para um servidor de Gateway seguro Citrix.

Q: Quais os produtos Citrix que interagem com o STA?

a: XenMobile, interface Web, StoreFront, XenApp Secure Access Manager, NetScaler Gateway e Citrix Secure Gateway interagem com STA. Ao longo deste artigo, os seguintes tipos de servidores estão agrupados numa única categoria chamada servidores de enumeração de aplicações:

• Interface web 2.0 ou posterior
• Secure Access Manager 2.0 ou mais tarde
• StoreFront
• Application enumeration servers are responsible for authenticating users, enumerating published application icons, and producing an ICA file for a client that allows them to connect to a published application through a Secure Gateway server.

Q: Por que o STA é necessário?

A: No Citrix Secure Gateway deployments, o servidor gateway não executa autenticação de pedidos recebidos. Em vez disso, o servidor gateway defers autenticação para um servidor de enumeração de aplicação e usa o STA para garantir que cada usuário é autenticado. Servidores de enumeração de aplicativos solicitam bilhetes apenas para usuários que já estão autenticados para o servidor Web. Se os usuários têm bilhetes Sta válidos, o gateway assume que eles passaram as verificações de autenticação no servidor web e deve ser permitido o acesso.

este desenho permite que o servidor de Gateway seguro Citrix herde quaisquer métodos de autenticação no seu servidor web. Por exemplo, se o seu servidor de Interface Web estiver protegido com RSA SecurID, apenas os utilizadores autenticados com SecurID podem atravessar o servidor de Gateway seguro.

Q: Como é implementado o serviço STA?

A: o STA é escrito como uma extensão ISAPI para Microsoft Internet Information Services (IIS). A extensão é chamada CtxSta.dll e é hospedado na pasta /Scripts por padrão. Outros componentes se comunicam com o STA usando XML sobre HTTP.

os servidores de enumeração de aplicações solicitam bilhetes à hora de lançamento da aplicação, enviando dados para o STA como parte de um pedido de bilhete. Os dados enviados para o STA incluem o endereço do servidor XenApp ao qual o usuário vai se conectar e, no caso da Interface web 2.0 e Secure Access Manager 2.0, extendeu informações sobre o nome do usuário atual e a aplicação publicada que o usuário quer executar. O STA responde gerando um ticket e enviando – o de volta para o servidor de enumeração de aplicativos. Este bilhete e seus dados correspondentes permanecem em memória na STA por um número configurável de segundos (100 por padrão).
o application enumeration server constrói um arquivo ICA para o Usuário e insere o ticket STA no campo de endereço do arquivo ICA. Quando o cliente se conecta ao Gateway seguro, o ticket é apresentado e o gateway deve validar o ticket antes de estabelecer uma sessão segura para o cliente. O gateway executa um pedido de dados, enviando o bilhete de volta para o STA e pedindo seus dados correspondentes em troca. Se validado com sucesso, o STA encaminha os dados originais para o gateway e o gateway estabelece um relé entre o usuário final e o servidor XenApp.

tanto os pedidos de bilhetes como os pedidos de dados são realizados como documentos de pedido/resposta XML.

Q: Existe uma versão do STA que não necessita de IIS?

a: não, neste momento a IIS é necessária para hospedar o STA. Lembre-se que o STA não tem que ser exposto a uma rede não confiável como a Internet; o STA reside em sua rede confiável e é acessado apenas pelo gateway e servidores de enumeração de aplicativos.

Q: onde reside o servidor STA?

A: o servidor STA pode ser colocado em qualquer lugar, desde que o Gateway seguro e os servidores de enumeração de aplicativos possam alcançá-lo. O Citrix recomenda a colocação do STA na rede de confiança ou numa parte separada da sua firewall interna, mas não existem requisitos para o servidor STA para além do IIS. O STA não precisa pertencer a nenhum domínio, servidor de XenApp farm, Gerente de acesso seguro farm, ou outro servidor WEB interno, mas compartilhar o STA com outra função é prática comum. Um STA é incluído automaticamente como parte da configuração Secure Access Manager 2.0; muitos administradores acham conveniente localizar o STA em um servidor XenApp.

Q: Quais são as diferenças entre as diferentes versões do STA?

A: não existem diferenças funcionais materiais entre as versões 1.0 e 1.1, mas ao usar o sta 2.0 com a Interface 2.0 ou o Secure Access Manager 2.0, informação estendida é adicionada ao pedido de bilhete: o nome do Usuário e a aplicação que o usuário quer executar. Este extended data é consumido pelo serviço gateway para exibir detalhes sobre cada sessão gateway no console de gerenciamento Secure Gateway 2.0.

se o Secure Gateway 2.0 estiver configurado para usar um STA antigo da Versão 1.1 ou 1.0, os usuários podem se conectar a aplicações, mas o console seguro de gerenciamento de Gateway irá mostrar “N / A” para o nome de usuário e nome de Aplicação associado a cada sessão ICA. Para ver a informação estendida no Gateway seguro 2.0 consola de gestão, você deve usar a versão 2.0 ou mais tarde do STA e usar o Gerenciador de acesso seguro 2.0 ou a Interface web 2.0 como seu servidor de enumeração de Aplicação.

segurança

Q: Como é gerado o bilhete STA?

A: The ISAPI extension CtxSta.dll usa a geração pseudo-aleatória de números para produzir uma cadeia hexadecimal de 16 bytes. Por razões de segurança, Citrix não revela os passos exatos usados para produzir esta sequência aleatória de caracteres.

Q: O que constitui um bilhete STA?

A: o formato de codificação é uma cadeia da forma:

;STA_VERSION;STA_ID;bilhete

em que:

• o STA_VERSION é um campo numérico que identifica a versão do STA. Atualmente, os únicos valores válidos para este campo são “10” para Sta versões 1.0 e 1.1 e “20” para STA versão 2.0.
• STA_ID é uma sequência de 0 – 16 caracteres que representa um nome arbitrário atribuído pelo administrador a uma dada STA. Na Versão 1.x, esta string é padrão para STA01, STA02, e assim por diante. Quando o STA é instalado automaticamente como parte do Secure Access Manager 2.0, o ID STA é um hash do nome do servidor. Quando múltiplos STAs são compartilhados por um único servidor de gateway, cada ID STA deve ser único. Isto permite que o gateway localize o STA que criou o ticket e retorne a esse STA para validação do ticket. Um bilhete criado no STA01 não existirá no STA02.
• TICKET é uma sequência gerada aleatoriamente de 32 caracteres alfabéticos ou numéricos maiúsculos.

  por exemplo:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3E7959E79

P: O Bilhete é validado contra a estação de trabalho?

A: Não, Não há nada que ligue um bilhete a uma determinada estação de trabalho. Teoricamente, é possível solicitar um bilhete à estação de trabalho A e depois utilizá-lo na estação de trabalho B. para atenuar este risco:

• use sempre HTTPS entre o cliente e o servidor de enumeração da aplicação para evitar que um atacante intercepte o ticket enquanto ele viaja de servidor para cliente.
• reduzir o tempo de vida do bilhete tanto quanto possível para reduzir a quantidade de tempo que um atacante teria de transferir o bilhete da máquina A Para A máquina B.

lembre-se que um bilhete emitido pelo STA pode ser usado apenas uma vez, por isso, se o utilizador pretendido na máquina a se ligar com sucesso, o bilhete é inválido para todas as tentativas futuras de ligação da máquina A ou da máquina B.

Q: O Bilhete é eliminado após o uso?

A: Sim, os bilhetes são purgados imediatamente após um pedido de dados bem sucedido para que eles possam ser usados apenas uma vez. Eles também são excluídos após um tempo-out configurável (padrão 100 segundos), se não for usado.

Q: os bilhetes são alguma vez escritos em disco na STA?

A: Só quando o registo descritivo está activo ao definir o LogLevel=3 no CtxSta.configuracao. Caso contrário, o STA mantém todos os bilhetes pendentes (bilhetes que foram solicitados por um servidor de enumeração de aplicativos, mas ainda não validados por um Gateway seguro) usando um banco de dados em memória. Os dados XML são sempre enviados para o STA usando o comando HTTP POST, de modo que nenhum dado significativo de bilhete é alguma vez escrito para os logs do servidor Web STA.É possível alguém sequestrar um bilhete?

A: durante o funcionamento normal, um bilhete deve percorrer os quatro segmentos seguintes da rede::

• a Partir do STA para a aplicação de enumeração servidor
• a Partir da aplicação de enumeração servidor para o cliente
• a Partir do cliente para o Seguro de servidor de Gateway
• a Partir de uma porta de entrada para o STA

a primeira e A última segmentos de existir apenas entre os servidores na DMZ e o STA em sua rede confiável, o que significa que um intruso teria de ter acesso à rede para interceptar o bilhete ao longo dessas linhas. Ainda assim, estas vias podem ser criptografadas com SSL Se você usar o gateway seguro versão 2.0. No Citrix Secure Gateway 1.1 e anteriormente, o tráfego para o STA não pode ser criptografado usando SSL.

para proteger o segundo segmento, coloque um certificado no seu servidor web de enumeração de aplicativos e permita que os clientes se conectem apenas se eles usam HTTPS. O terceiro segmento é sempre seguro com SSL. Mesmo quando todos os links anteriores são assegurados com SSL, os clientes ainda são vulneráveis a ataques por programas de Trojan que monitoram a atividade do cliente. Para mitigar este risco, aconselhe seus usuários a se conectar a partir de máquinas onde o software de detecção anti-vírus e Trojan está instalado.

Q: Como proteger o tráfego STA com SSL?

a: primeiro, instalar um certificado de servidor Web na cópia do IIS que hospeda o STA. Para mais informações, consulte a documentação IIS.

Configure seu servidor de enumeração de aplicativos e servidor de Gateway seguro para usar HTTPS quando se comunicar com a gateway. Ao conectar por HTTPS, as seguintes regras devem ser sempre cumpridas:

• você deve dirigir o STA usando um nome de domínio totalmente qualificado que corresponde ao assunto do certificado do servidor STA.
• a máquina que comunica com o STA deve ser capaz de resolver o nome de domínio STA totalmente qualificado para um endereço IP apropriado.
• a máquina que comunica com o STA deve confiar na Autoridade de Certificação (CA) que emitiu o certificado do servidor STA.
• para cumprir os requisitos do terceiro item de bala, o certificado raiz da AC precisa ser instalado no servidor de gateway seguro e no servidor de enumeração de aplicações. Tome cuidado ao instalar o certificado de raiz: não pode simplesmente fazer duplo-click num ficheiro de certificado de raiz e executar o Assistente de importação de certificados.

(isso indica que sua conta de usuário, não o servidor ou qualquer serviço de Sistema, confia na CA.) Para instalar um certificado de raiz para usar com o Citrix Secure Gateway ou Interface Web, siga os passos:

1. executar Mmc.exe e adicione os certificados snap-in.
2. quando perguntado quais os certificados para gerenciar, selecionar conta de computador e, em seguida, computador Local.
3. expandir os certificados (computador Local) > nó das autoridades de certificação de raízes de confiança. Certificados com o botão direito do rato e, em seguida, seleccionar todas as tarefas > importar.
4. navegue para seleccionar o seu certificado raiz da AC e completar o Assistente de importação.

Q: O STA deve ser sempre endereçado usando um nome de domínio totalmente qualificado?

A: se você pretende garantir o tráfego para o STA usando SSL, qualquer componente que aceda ao STA, incluindo o seu servidor de gateway e servidor de enumeração de aplicações, deve endereçar o STA usando o nome de domínio totalmente qualificado (FQDN) que corresponde ao assunto do certificado do servidor usado pelo IIS no STA. Por exemplo, na Interface web 2.0, o endereço STA seria inserido como:https://sta-server.company.com/Scripts/CtxSta.dll

se optar por não garantir o tráfego para o STA, poderá dirigir-se ao STA usando um endereço IP, Nome da máquina ou FQDN.

Q: Como posso mudar o porto de STA de 80 para outra coisa?

A: uma vez que o STA é servido pelo IIS, você muda o porto STA quando muda o porto IIS. O exemplo seguinte ilustra como mudar o porto IIS de 80 para 81.

1. Gestor de Serviços de Internet abertos.
2. clique com o botão direito e veja as propriedades.
3. na página do site, mude o número da porta TCP de 80 para 81.
4. clique em OK.
   a alteração anterior também afeta quaisquer outros recursos que você publicou a partir do servidor Sta Web. Se você quiser alterar a porta de comunicação STA sem afetar outras páginas web hospedadas pelo mesmo servidor Web, você pode criar um novo site Web em IIS com o único propósito de hospedar o STA. O seguinte é um exemplo de como você criaria um novo site na porta 81 para o STA.
5. crie uma nova pasta física como C:\MYSTA no disco rígido do seu servidor Web para servir como a raiz do documento para o site STA.
6. crie uma subdiretoria abaixo de MYSTA chamada Scripts. Mova os seguintes ficheiros do seu STA existente para a pasta de novos programas:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. Gestor de Serviços de Internet abertos.
8. carregue com o botão direito no nome do servidor e seleccione o novo > Sítio Web.
9. crie um novo site chamado “My STA site” e C:\MYSTA como directório raiz do documento.
10. ver as propriedades do seu novo site e mudar a porta TCP para 81.
11. sob o meu site STA no Gestor de Serviços de Internet, clique com o botão direito na pasta Scripts e veja as propriedades. Na secção de configuração da aplicação, mude as permissões de execução para “Scripts e Executables.”

Nota: você pode escolher um nome de pasta diferente de “Scripts”, mas esteja ciente de que Gateway segura e todos os servidores de enumeração de aplicativos, como a interface Web, assumem que o STA é publicado como /Scripts/CtxSta.dll então você também vai precisar atualizar o URL STA nas Configurações nesses servidores.Q: Pode um atacante enviar bilhetes aleatórios para o Gateway para entrar?

A: um atacante teria que adivinhar um bilhete válido e também resgatá-lo dentro dos poucos milissegundos após o cliente o solicitar, mas antes do gateway reclamá-lo.

Q: Que outras informações são necessárias para registar além de um bilhete de identidade válido?

A: os usuários também precisam de credenciais de domínio ou um ticket de servidor de XenApp que é solicitado pelo servidor de enumeração de aplicativos. (A XenApp Server ticket is not the same as an STA ticket.) Satisfazer o STA abre um caminho apenas para a rede confiável para um servidor em particular. Uma vez lá, o usuário ainda deve autenticar com credenciais de domínio válidas.
Q: Como podemos definir o tempo de vida do Ticket STA, após o qual o Ticket deve ser inválido?
A: Podemos definir o tempo de vida do bilhete STA criando uma seguinte chave de registo no controlador de entrega:
localização: HKLM\Software\Citrix\DesktopServer
nome: Xmlstaticketimetimeinsegundos
Tipo: valor da palavra: Indique o valor em segundos (Decimal)
por favor, faça uma cópia de segurança do registo antes de editar os valores do registo; lembre-se também que uma alteração de Registo exigiria um reinício no fim do controlador.

escalabilidade

Q: de quantos STAs preciso?

A: o STA é acessado apenas quando um usuário lança uma aplicação, a resposta a esta pergunta varia de uma implantação para a próxima.

Q: os UTILIZADORES fazem logon através do gateway de manhã e executam uma única aplicação publicada o dia todo ou lançam várias aplicações ao longo do dia?

A: As funções desempenhadas pelo STA não são caras em termos de CPU; é um serviço XML leve limitado apenas pelo desempenho do IIS. Em um teste, um servidor de baixo alcance com um processador 1GHz e 256MB de RAM suportava mais de 250 pedidos de ingressos por segundo, enquanto a utilização da CPU permaneceu abaixo de 60%.

Q: Como posso assegurar a tolerância à falha STA?

A: os seguintes servidores de enumeração de aplicações permitem-lhe introduzir vários URLs STA ao configurar os parâmetros para a ‘Gateway’ segura:

• Interface Web 2.0
• Secure Access Manager 2.0
• StoreFront

em todos os casos, se um STA não responder, o servidor de enumeração de aplicações tenta outro STA da lista. Cada servidor de gateway por sua vez deve ser configurado com o URL STA e ID Sta único para cada Autoridade de ticket.

Q: Como faço para Balancear vários STAs?

A: devem ser tomadas precauções especiais quando as autoridades responsáveis pela compensação de cargas são seguras. Uma variedade de métodos podem ser usados para equilibrar a conexão entre um servidor de enumeração de aplicativos e os STAs, mas um servidor de Gateway seguro deve sempre contatar cada STA individualmente com base em seu ID STA. Ao configurar o endereço de cada STA na ferramenta de configuração do serviço de gateway, cada endereço STA deve ser o endereço verdadeiro do servidor STA — não digite o endereço de qualquer balancer de carga de hardware, nome de grupo, ou nome de DNS round-robin aqui.

Loja, Interface web 2.0, e Secure Access Manager 2.0 todos os sistemas de suporte de balanceamento de carga entre escalas dos STAs quando são listados vários STAs. Quando esta opção estiver activa, não é necessário nenhum software ou hardware de compensação de carga adicional.

os servidores de enumeração de aplicações podem utilizar qualquer forma de compensação de carga para a emissão de um pedido de bilhete porque cada bilhete recebido contém um campo que indica o ID único do STA que o gerou. Desde que cada ID STA seja único e todos os servidores de gateway possam resolver o ID STA para um determinado endereço (Sem carga balanceada) do servidor, a operação tem sucesso e o tráfego STA é balanceado.

Q: Posso usar vários STAs com o equilíbrio de carga da Rede Microsoft?

A: o balanceamento de carga em rede não pode ser utilizado entre o servidor de Gateway seguro e vários STAs. Se configurado desta forma, os usuários recebem negações intermitentes porque, durante o processo de validação do bilhete, o gateway pode ser carregado balanceado para uma autoridade que não gerou originalmente o bilhete do Usuário.

Q: Posso partilhar um único STA com várias quintas, portais e Servidores de enumeração?

A: Sim, um único STA pode ser compartilhado entre qualquer número de Servidores de Gateway seguros e servidores de enumeração de aplicativos. O STA não está restrito a nenhum domínio particular, fazenda ou servidor de enumeração de aplicações. É um serviço XML anónimo.

solução de problemas

Q: Como deve ser configurado o IIS para hospedar o STA?

the STA URL /Scripts/CtxSta.dll deve ser servido com acesso anônimo habilitado. Se você apontar qualquer navegador Web para o URL STA você não será solicitado para uma senha.

• você deve conceder a permissão dos programas de recursos e executáveis no metabase IIS. Esta permissão não é necessária para a pasta inteira /Scripts, mas pode ser definida para o CtxSta.arquivar individualmente.
• para o Secure Gateway Versão 1.1 e anterior, não permitem o SSL necessário e requerem opções SSL de 128 bits.
• por omissão, são necessárias as seguintes permissões de conta:

em servidores Windows 2000

• a conta IUSR_MachineName necessita de acesso lido ao CtxSta.dll.
• a conta Iwam_ Makinename necessita de modificar o acesso à pasta de ficheiros de registo, que é \Inetpub\Scripts por omissão.

nos servidores do Windows 2003

• a conta IUSR_MachineName necessita de acesso lido ao CtxSta.dll.
• a conta de serviço de rede incorporada necessita de modificar o acesso ao directório de ficheiros de registo, que é o \Inetpub\Scripts por omissão.

Q: Como posso permitir o registo no STA?

A: usando o bloco de notas, edite o ficheiro \Inetpub\Scripts\CtxSta.configuração no servidor STA e localizar a linha que diz LogLevel=0. Para o registo máximo, mude isto para LogLevel=3. Você deve reiniciar o serviço de publicação World Wide Web para que as mudanças entrem em vigor.
Nota: Depois de activar o registo, a conta de utilizador sob cuja autoridade o STA executa (IUSR_ Makinename no Windows 2000 ou serviço de rede no Windows 2003 por omissão) deverá ter acesso de escrita à pasta de ficheiros de registo, que é o \Inetpub\Scripts por omissão. Você também pode alterar o diretório de arquivos de log quando você editar CtxSta.configuracao.

Q: Por que a ferramenta Microsoft IISLockDown quebra o STA?

A: Se aceitar todas as opções predefinidas para a ferramenta IISLockDown, a pasta /Scripts está desactivada. O STA é implementado como um filtro ISAPI publicado como /Scripts/CtxSta.dll; ao desactivar a pasta /Scripts, você nega o acesso ao STA. Active a pasta /Scripts e permita que os Scripts e executables acedam à função STA.

Q: Como posso testar o STA para ter a certeza de que está a funcionar correctamente?

A: se você apontar um navegador Web para o URL STA, você vai ver uma página branca em branco ou a mensagem ” recurso 405 Não permitido.”Qualquer um destes resultados indica um STA funcional. Você pode entrar em contato com o STA desta forma a partir do console do seu servidor de Gateway seguro e também de qualquer servidor de enumeração de aplicação configurado para usar o gateway. Se receber uma janela de autenticação que lhe pede uma senha, o STA não é publicado anonimamente e os requisitos de autenticação têm de ser removidos.

para verificar se o servidor de enumeração de aplicações está a pedir bilhetes STA com sucesso, veja os ficheiros ICA que gera. Por exemplo, a partir da Interface web 2.0, você pode clicar com o direito em um ícone de Aplicação publicado e salvar o resultado como lançamento.ica. Abrir lançamento.ica in Notepad and view the Address= line. Para uma operação de Gateway segura normal, o parâmetro de endereço conterá um ticket em vez de um endereço de servidor de XenApp real.

Q: Como posso interpretar os ficheiros de Registo STA?

A: se activar o registo definindo o LogLevel=3 no CtxSta.config, você verá detalhes de cada bilhete e pedido de dados recebidos pelo STA. Lembre-se que um pedido de ticket é gerado por um servidor de enumeração de aplicativos como Interface Web, e um pedido de dados é realizado pelo serviço seguro Gateway. Se o arquivo de log mostra vários pedidos de ticket, mas nenhum pedido de dados, isso implica que o servidor de enumeração de aplicação pode chegar ao STA, mas o servidor de Gateway seguro não pode. Ele também pode implicar que os usuários não podem alcançar o servidor gateway.

durante a operação normal, a funcionalidade de partilha de sessões do cliente ICA pode fazer com que os bilhetes sejam solicitados ao STA, mas nunca reclamados pelo gateway. Considere o seguinte cenário::

• um usuário faz login na Interface Web e clica no ícone do Outlook. Interface web pede um bilhete do STA e envia-o para o usuário em um arquivo ICA.
• o usuário conecta – se através de Gateway segura e apresenta o bilhete para a admissão. A gateway valida o ticket e permite ao usuário se conectar a um servidor de XenApp hosting Outlook.
• depois de trabalhar por alguns minutos, o usuário retorna à lista de aplicativos na página de Interface Web e clica no ícone do Excel. Interface web pede um segundo bilhete do STA e envia-o para o usuário em um arquivo ICA.
• Antes de se conectar a um novo servidor para o Excel, o cliente ICA primeiro verifica se quaisquer servidores existentes aos quais o cliente já está conectado têm o Excel publicado aplicação disponível.
• o servidor onde o cliente já está executando o Outlook também tem o Excel instalado, de modo que o cliente ICA descarta o arquivo ICA e inicia o Excel dentro da sessão ICA existente.
• o segundo bilhete solicitado pela interface Web nunca é usado porque uma segunda sessão ICA não era necessária. Por padrão, o ticket sai ao fim de 100 segundos.

Este cenário pode resultar em uma série de STA entradas de arquivo de log semelhante à seguinte:

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

Mais uma atividade suspeita deve ser algo como:

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

Aqui vemos o que parece ser um atacante tentando vários bilhetes de uma vez, aumentando o bilhete de identidade com o cada tentativa. Em cada caso, a conexão foi rejeitada e o STA registrou uma entrada indicando que o cliente apresentou um bilhete que não foi reconhecido como válido. Para identificar o endereço IP do atacante, procure a seguinte mensagem no visualizador de eventos no servidor seguro Gateway:

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

não interprete algumas mensagens de “bilhete não encontrado” como um ataque. O cliente Win32 ICA pode tentar reconectar-se a uma sessão desconectada se a conexão de rede do usuário for retirada momentaneamente. O recurso Auto Client Reconect não funciona para os usuários do Citrix Secure Gateway porque durante cada tentativa de reconectação, o cliente resubstitui o ticket Sta usado com o qual ele originalmente conectou. O cliente geralmente tenta reconectar três ou mais vezes antes de desistir, então você verá três ou mais mensagens “Ticket NOT found” referenciando o mesmo ticket no Sta log para cada ocorrência deste problema. Tentativas de reconexão do cliente são caracterizadas pela tentativa de reutilização de um bilhete previamente bem sucedido:

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

desconectar Auto Client reconectar para os utilizadores seguros do Gateway adicionando TransportReconnectEnabled = Off para a secção do ficheiro ICA. A maneira correta de reconectar a uma sessão desconectada ao usar o Secure Gateway é retornar ao servidor de enumeração de aplicativos e clicar no ícone da aplicação novamente.

Q: Quais são alguns dos erros de configuração comuns vistos pelo suporte técnico Citrix?

• a pasta /Scripts ou todo o site padrão é desativado como resultado de executar o IISLockDown ou aderir à política da empresa para proteger servidores Web.
• o registo está activo no CtxSta.configuração, mas a conta de utilizador sob cuja autoridade o STA executa (IUSR_MachineName por omissão) não tem acesso de escrita à pasta de ficheiros de Registo.
• IIS no servidor STA está configurado para exigir SSL, mas a Gateway segura está configurada para acessar o STA usando HTTP normal.
• se o lançamento do aplicativo falhar, a primeira coisa a ser verificada é se os STAs na interface StoreFront / Web e NetScaler são dados exatamente da mesma forma ou não, ou seja, se os STAs são dados como endereço IP em SF/WI, ele deve ser dado usando o endereço IP em NS e similarmente no caso de FQDN.