Preguntas frecuentes: Citrix Secure Gateway / NetScaler Gateway Secure Ticket Authority

Nota: Los mismos principios y conceptos también son válidos para NetScaler Gateway.

Este artículo responde a algunas preguntas frecuentes sobre Citrix Secure Ticket Authority (STA). Las preguntas se dividen en las siguientes cuatro categorías:

Descripción general

P: ¿Cuál es la Autoridad de Ticket seguro?
P: ¿Qué productos Citrix interactúan con el STA?
P: ¿Por qué es necesario el STA?
P: ¿Cómo se implementa el servicio STA?
Q: ¿Hay una versión del STA que no requiera IIS?
P: ¿Dónde reside el servidor STA?
P: ¿Cuáles son las diferencias entre las diferentes versiones del STA?

Seguridad

P: ¿Cómo se genera el ticket STA?
P: ¿Qué constituye un boleto STA?
P: ¿Se valida el ticket en la estación de trabajo?
P: ¿Se elimina el ticket después de su uso?
P: ¿Alguna vez se escriben tickets en Disco en el STA?
P: ¿Es posible que alguien secuestre un boleto?
P: ¿Cómo protejo el tráfico STA con SSL?
Q: ¿Debe dirigirse siempre al STA con un Nombre de Dominio Completo?
P: ¿Cómo cambio el puerto STA de 80 a otra cosa?
P: ¿Puede un atacante enviar Tickets aleatorios a la Puerta de enlace para Iniciar sesión?
P: ¿Qué otra información se requiere para iniciar sesión que no sea un ticket STA válido?
P: ¿Cómo podemos establecer el tiempo de vida del ticket STA, después del cual el ticket debe ser inválido?

Escalabilidad

P: ¿Cuántos STA necesito?
Q: ¿Los usuarios inician sesión a través de la puerta de enlace por la mañana y ejecutan una sola aplicación publicada durante todo el día o inician varias aplicaciones a lo largo del día?
P: ¿Cómo puedo garantizar la tolerancia a fallos STA?
P: ¿Cómo puedo Equilibrar la carga de varios STA?
P: ¿Puedo usar varios STA con Equilibrio de carga de red de Microsoft?
P: ¿Puedo compartir un solo STA con varias Granjas, Puertas de enlace y Servidores de Enumeración?

Solución de problemas

P: ¿Cómo se debe configurar IIS para alojar el STA?
P: ¿Cómo habilito el registro en el STA?
Q: ¿Por qué la herramienta Microsoft IISLockDown rompe el STA?
P: ¿Cómo puedo probar el STA para asegurarme de que funciona correctamente?
P: ¿Cómo interpreto los archivos de registro STA?
P: ¿Cuáles son algunos de los errores de configuración comunes observados por el soporte técnico de Citrix?

Descripción general

P: ¿Qué es la Autoridad de Ticket seguro?

A: Secure Ticket Authority (STA) es un servicio web XML que intercambia información del servidor XenApp por tickets generados aleatoriamente. Se utiliza para controlar el acceso de un servidor Citrix Secure Gateway.

P: ¿Qué productos Citrix interactúan con el STA?

A: XenMobile, Interfaz Web, StoreFront, XenApp Secure Access Manager, NetScaler Gateway y Citrix Secure Gateway interactúan con STA. A lo largo de este artículo, los siguientes tipos de servidores se agrupan en una sola categoría denominada servidores de enumeración de aplicaciones:

• Interfaz Web 2.0 o posterior
• Administrador de acceso seguro 2.0 o posterior
• StoreFront
• Los servidores de enumeración de aplicaciones son responsables de autenticar a los usuarios, enumerar los iconos de aplicaciones publicadas y producir un archivo IC para un cliente que les permita conectarse a una aplicación publicada a través de un servidor de puerta de enlace segura.

P: ¿Por qué es necesario el STA?

A: En las implementaciones de Citrix Secure Gateway, el servidor de puerta de enlace no realiza la autenticación de las solicitudes entrantes. En su lugar, el servidor de puerta de enlace aplaza la autenticación a un servidor de enumeración de aplicaciones y utiliza el STA para garantizar que cada usuario esté autenticado. Los servidores de enumeración de aplicaciones solo solicitan tickets para usuarios que ya están autenticados en el servidor Web. Si los usuarios tienen tickets STA válidos, la puerta de enlace asume que pasaron las comprobaciones de autenticación en el servidor web y se les debe permitir el acceso.

Este diseño permite que el servidor Citrix Secure Gateway herede cualquier método de autenticación del servidor web. Por ejemplo, si su servidor de interfaz Web está protegido con RSA SecurID, por diseño solo los usuarios autenticados con SecurID pueden atravesar el servidor de puerta de enlace segura.

P: ¿Cómo se implementa el servicio STA?

A: El STA se escribe como una extensión ISAPI para Microsoft Internet Information Services (IIS). La extensión se llama CtxSta.dll y está alojado en la carpeta / Scripts de forma predeterminada. Otros componentes se comunican con el STA mediante XML a través de HTTP.

Los servidores de enumeración de aplicaciones solicitan tickets en el momento del inicio de la aplicación enviando datos al STA como parte de una solicitud de ticket. Los datos enviados al STA incluyen la dirección del servidor XenApp al que se conectará el usuario y, en el caso de Web Interface 2.0 y Secure Access Manager 2.0, información ampliada sobre el nombre del usuario actual y la aplicación publicada que el usuario desea ejecutar. El STA responde generando un ticket y enviándolo de vuelta al servidor de enumeración de aplicaciones. Este ticket y sus datos correspondientes permanecen en memoria en el STA durante un número de segundos configurable (100 por defecto).
El servidor de enumeración de aplicaciones construye un archivo IC para el usuario e inserta el ticket STA en el campo de dirección del archivo IC. Cuando el cliente se conecta a la puerta de enlace segura, se presenta el ticket y la puerta de enlace debe validar el ticket antes de establecer una sesión segura para el cliente. La pasarela realiza una solicitud de datos enviando el ticket de vuelta al STA y solicitando a cambio sus datos correspondientes. Si se valida correctamente, el STA reenvía los datos originales a la puerta de enlace y la puerta de enlace establece un relé entre el usuario final y el servidor XenApp.

Tanto las solicitudes de tickets como las solicitudes de datos se realizan como documentos XML de solicitud/respuesta.

P: ¿Hay una versión de STA que no requiera IIS?

A: No, en este momento se requiere IIS para alojar el STA. Recuerde que el STA no tiene que estar expuesto a una red no confiable como Internet; el STA reside en su red de confianza y solo se accede a él mediante los servidores de enumeración de aplicaciones y de puerta de enlace.

P: ¿Dónde reside el servidor STA?

A: El servidor STA se puede colocar en cualquier lugar siempre que la puerta de enlace segura y los servidores de enumeración de aplicaciones puedan llegar a él. Citrix recomienda colocar el STA en la red de confianza o en un tramo separado del firewall interno, pero no hay requisitos para el servidor STA que no sean IIS. El STA no necesita pertenecer a ningún dominio, granja de servidores XenApp, granja de administradores de acceso seguro u otro servidor web interno, pero compartir el STA con otra función es una práctica común. Un STA se incluye automáticamente como parte de la configuración de Secure Access Manager 2.0; a muchos administradores les resulta conveniente ubicar el STA en un servidor XenApp.

P: ¿Cuáles son las diferencias entre las diferentes versiones del STA?

A: No hay diferencias funcionales importantes entre las versiones 1.0 y 1.1, pero al usar el STA 2.0 con Interfaz Web 2.0 o Secure Access Manager 2.0, se agrega información extendida a la solicitud de ticket: El nombre del usuario y la aplicación que el usuario desea ejecutar. El servicio de puerta de enlace consume estos datos extendidos para mostrar detalles sobre cada sesión de puerta de enlace en la consola de administración de Secure Gateway 2.0.

Si Secure Gateway 2.0 está configurado para usar un STA anterior de la versión 1.1 o 1.0, los usuarios pueden conectarse a las aplicaciones, pero la consola de administración de Secure Gateway mostrará «N/A» para el nombre de usuario y el nombre de aplicación asociados con cada sesión IC. Para ver la información ampliada en Secure Gateway 2.0 consola de administración, debe usar la versión 2.0 o posterior de STA y usar Secure Access Manager 2.0 o Web Interface 2.0 como servidor de enumeración de aplicaciones.

Seguridad

P: ¿Cómo se genera el ticket STA?

A: La extensión ISAPI CtxSta.dll utiliza la generación de números pseudoaleatorios para producir una cadena hexadecimal de 16 bytes. Por razones de seguridad, Citrix no revela los pasos exactos utilizados para producir esta secuencia aleatoria de caracteres.

P: ¿Qué constituye un boleto STA?

A: El formato de codificación es una cadena de la forma:

;STA_VERSION;STA_ID; TICKET

Donde:

• STA_VERSION es un campo numérico que identifica la versión del STA. Actualmente, los únicos valores válidos para este campo son «10» para las versiones 1.0 y 1.1 de STA y «20» para la versión 2.0 de STA.
• STA_ID es una secuencia de 0 a 16 caracteres que representan un nombre arbitrario asignado por el administrador a un STA en particular. En la versión 1.x, esta cadena por defecto es STA01, STA02, y así sucesivamente. Cuando el STA se instala automáticamente como parte de Secure Access Manager 2.0, el ID de STA es un hash del nombre del servidor. Cuando un único servidor de puerta de enlace comparte varios STA, cada ID de STA debe ser único. Esto permite que la puerta de enlace localice el STA que creó el ticket y regrese a ese STA para la validación del ticket. Un ticket creado en STA01 no existirá en STA02.El TICKET
• es una secuencia generada aleatoriamente de 32 caracteres alfabéticos o numéricos en mayúsculas.

  Por ejemplo:
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

P: ¿Se valida el ticket en la estación de trabajo?

A: No, no hay nada que vincule un ticket a una estación de trabajo en particular. Teóricamente, es posible solicitar un ticket desde la estación de trabajo A y luego usarlo desde la estación de trabajo B. Para mitigar este riesgo:

• Utilice siempre HTTPS entre el cliente y el servidor de enumeración de aplicaciones para evitar que un atacante intercepte el ticket mientras viaja del servidor al cliente.
• Reduzca el tiempo de vida del ticket tanto como sea posible para reducir la cantidad de tiempo que un atacante tendría que transferir el ticket de la Máquina A a la Máquina B.

Recuerde que un ticket emitido por el STA solo se puede usar una vez, por lo que si el usuario previsto en la Máquina A se conecta correctamente, el ticket no es válido para todos los intentos de conexión futuros desde la Máquina A o la Máquina B.

P: ¿Se elimina el Ticket después de su uso?

R: Sí, los tickets se purgan inmediatamente después de una solicitud de datos exitosa, por lo que solo se pueden usar una vez. También se eliminan después de un tiempo de espera configurable (100 segundos por defecto) si no se utilizan.

P: ¿Alguna vez se escriben tickets en Disco en el STA?

A: Solo cuando se habilita el registro detallado configurando LogLevel=3 en CtxSta.config. De lo contrario, la STA mantiene todos los tickets pendientes (tickets que fueron solicitados por un servidor de enumeración de aplicaciones pero que aún no han sido validados por una puerta de enlace segura) mediante una base de datos en memoria. Los datos XML siempre se envían a la STA mediante el comando HTTP POST, por lo que nunca se escriben datos de ticket significativos en los registros del servidor web de STA.

P: ¿Es posible que alguien secuestre un boleto?

A: Durante el funcionamiento normal, un billete debe viajar por los siguientes cuatro segmentos de la red:

• Del STA al servidor de enumeración de aplicaciones
• Del servidor de enumeración de aplicaciones al cliente
• Del cliente al servidor de puerta de enlace segura
• De la puerta de enlace al STA

El primer y el último segmento solo existen entre los servidores de la zona desmilitarizada y el STA de confianza red, lo que significa que un intruso necesitaría tener acceso a su red para interceptar el ticket a lo largo de esas líneas. Sin embargo, estas vías se pueden cifrar con SSL si utiliza Secure Gateway Versión 2.0. En Citrix Secure Gateway 1.1 y anteriores, el tráfico a la STA no se puede cifrar mediante SSL.

Para proteger el segundo segmento, coloque un certificado en el servidor web de enumeración de aplicaciones y permita que los clientes se conecten solo si usan HTTPS. El tercer segmento siempre está protegido con SSL.

Incluso cuando todos los enlaces anteriores están protegidos con SSL, los clientes siguen siendo vulnerables al ataque de programas troyanos que monitorean la actividad del cliente. Para mitigar este riesgo, aconseje a los usuarios que se conecten desde las máquinas donde esté instalado el software de detección de virus y troyanos.

P: ¿Cómo protejo el tráfico STA con SSL?

A: Primero, instale un certificado de servidor web en la copia de IIS que aloja el STA. Para obtener más información, consulte la documentación de IIS.

Configure el servidor de enumeración de aplicaciones y el servidor de puerta de enlace segura para usar HTTPS al comunicarse con la puerta de enlace. Al conectarse por HTTPS, siempre se deben cumplir las siguientes reglas:

• Debe dirigirse al STA utilizando un nombre de dominio completo que coincida con el asunto del certificado de servidor STA.
• La máquina que se comunica con el STA debe ser capaz de resolver el nombre de dominio completo de STA en una dirección IP adecuada.
• La máquina que se comunica con el STA debe confiar en la Autoridad de certificación (CA) que emitió el certificado de servidor STA.
• Para cumplir los requisitos del tercer elemento de viñeta, el certificado raíz de CA debe instalarse en el servidor Secure Gateway y en el servidor de enumeración de aplicaciones. Tenga cuidado al instalar el certificado raíz: No puede hacer doble clic en un archivo de certificado raíz y ejecutar el asistente para importación de certificados.

(Al hacerlo, indica que su cuenta de usuario, no el servidor ni ningún servicio del sistema, confía en la CA.) Para instalar un certificado raíz para usarlo con Citrix Secure Gateway o la interfaz Web, siga los pasos siguientes:

1. Corre Mmc.exe y agregue el complemento Certificados.
2. Cuando se le pregunte qué certificados administrar, seleccione Cuenta de equipo y, a continuación, Equipo local.
3. Expanda el nodo Entidades de certificación raíz de confianza de Certificados (Equipo local) >. Haga clic con el botón secundario en Certificados y, a continuación, seleccione Todas las tareas > Importar.
4. Busque para seleccionar su certificado raíz de CA y complete el asistente de importación.

P: ¿Debe dirigirse siempre al STA con un Nombre de dominio Completo?

A: Si desea proteger el tráfico a la STA mediante SSL, cualquier componente que acceda a la STA, incluidos el servidor de puerta de enlace y el servidor de enumeración de aplicaciones, debe dirigirse a la STA utilizando el nombre de dominio completo (FQDN) que coincida con el asunto del certificado de servidor utilizado por IIS en la STA. Por ejemplo, en la Interfaz Web 2.0, la dirección STA se introduciría como:https://sta-server.company.com/Scripts/CtxSta.dll

Si elige no proteger el tráfico al STA, puede dirigirse al STA mediante una dirección IP, un nombre de host o un FQDN.

P: ¿Cómo cambio el puerto STA de 80 a otra cosa?

A: Debido a que el STA es servido por IIS, se cambia el puerto STA cuando se cambia el puerto IIS. El siguiente ejemplo ilustra cómo cambiar el puerto de IIS de 80 a 81.

1. Abra el Administrador de Servicios de Internet.
2. Haga clic con el botón secundario en el sitio web predeterminado y vea las propiedades.
3. En la pestaña Sitio web, cambie el número de puerto TCP de 80 a 81.
4. Haga clic en Aceptar.
   El cambio anterior también afecta a cualquier otro recurso que haya publicado desde el servidor web STA. Si desea modificar el puerto de comunicación STA sin afectar a otras páginas Web alojadas en el mismo servidor Web, puede crear un nuevo sitio Web en IIS con el único propósito de alojar el STA. El siguiente es un ejemplo de cómo crear un nuevo sitio web en el puerto 81 para el STA.
5. Crear una nueva carpeta física como C:\MYSTA en el disco duro de su servidor Web para servir como raíz de documentos para el sitio STA.
6. Cree un subdirectorio debajo de MYSTA llamado Scripts. Mueva los siguientes archivos de su STA existente a la carpeta nuevos scripts:
   • CtxSta.dll
   • CtxSta.config
   • ctxxmlss.txt
7. Abra el Administrador de Servicios de Internet.
8. Haga clic con el botón secundario en el nombre del servidor y seleccione Nuevo sitio web >.
9. Crear un nuevo sitio web llamado «My STA site» y C:\MYSTA como el directorio raíz del documento.
10. Vea las propiedades de su nuevo sitio web y cambie el puerto TCP a 81.
11. En Mi sitio STA en el Administrador de servicios de Internet, haga clic con el botón secundario en la carpeta Scripts y vea las propiedades. En la sección Configuración de la aplicación, cambie los permisos de ejecución a «Scripts y ejecutables».»

Nota: Puede elegir un nombre de carpeta que no sea «Scripts», pero tenga en cuenta que Secure Gateway y todos los servidores de enumeración de aplicaciones, como Web Interface, asumen que el STA se publica como /Scripts/CtxSta.dll, por lo que también tendrá que actualizar la URL de STA en la configuración de esos servidores.

P: ¿Puede un atacante enviar Tickets aleatorios a la Puerta de enlace para Iniciar sesión?

R: Un atacante tendría que adivinar un ticket válido y también canjearlo en unos pocos milisegundos después de que el cliente lo solicite, pero antes de que la puerta de enlace lo reclame.

P: ¿Qué otra información se requiere para iniciar sesión que no sea un ticket STA válido?

A: Los usuarios también necesitan credenciales de dominio o un ticket de servidor XenApp solicitado por el servidor de enumeración de aplicaciones. (Un ticket de servidor XenApp no es lo mismo que un ticket STA.) Satisfacer el STA abre una ruta solo a la red de confianza para un servidor en particular. Una vez allí, el usuario aún debe autenticarse con credenciales de dominio válidas.
P: ¿Cómo podemos establecer el tiempo de vida del Ticket STA, después del cual el Ticket debe ser inválido?
A: Podemos establecer la duración del ticket STA creando una clave de registro siguiente en el Delivery Controller:
Ubicación: HKLM\Software \ Citrix \ DesktopServer
Nombre: XmlStaTicketLifetimeInSeconds
Tipo: Valor Dword: Dar valor en segundos (Decimal)
Tome una copia de seguridad del registro antes de editar los valores del registro, también tenga en cuenta que un cambio del registro requeriría un reinicio en el extremo del Controlador.

Escalabilidad

P: ¿Cuántos STA necesito?

A: Solo se accede a la STA cuando un usuario inicia una aplicación, la respuesta a esta pregunta varía de una implementación a otra.

P: ¿Los usuarios inician sesión a través de la puerta de enlace por la mañana y ejecutan una sola aplicación publicada durante todo el día o inician varias aplicaciones a lo largo del día?

A: Las tareas realizadas por el STA no son costosas en términos de CPU; es un servicio XML ligero limitado solo por el rendimiento de IIS. En una prueba, un servidor de bajo alcance con un procesador de 1 GHz y 256 MB de RAM admitía más de 250 solicitudes de tickets por segundo, mientras que la utilización de la CPU se mantuvo por debajo del 60%.

P: ¿Cómo puedo garantizar la tolerancia a fallos STA?

A: Los siguientes servidores de enumeración de aplicaciones le permiten introducir varias direcciones URL STA al configurar los parámetros de Secure Gateway:

• Interfaz Web 2.0
• Administrador de acceso seguro 2.0
• StoreFront

En todos los casos, si un STA no responde, el servidor de enumeración de aplicaciones intenta otro STA de la lista. Cada servidor de puerta de enlace a su vez debe configurarse con la URL STA y el ID STA único para cada autoridad de ticket.

P: ¿Cómo puedo Equilibrar la carga de varios STA?

A: Se debe tener especial cuidado al equilibrar la carga de las Autoridades de Tickets seguros. Se pueden utilizar diversos métodos para equilibrar la carga de la conexión entre un servidor de enumeración de aplicaciones y los STA, pero un servidor de puerta de enlace segura siempre debe ponerse en contacto con cada STA individualmente en función de su ID de STA. Al configurar la dirección de cada STA en la herramienta de configuración del servicio de puerta de enlace, cada dirección STA debe ser la dirección verdadera del servidor STA; no introduzca aquí la dirección de ningún equilibrador de carga de hardware, nombre de clúster o nombre DNS de todos contra todos.

Escaparate, Interfaz Web 2.0 y Administrador de acceso seguro 2.0 todos admiten el equilibrio de carga round-robin de los STA cuando se enumeran varios STA. Cuando esta opción está habilitada, no se requiere software o hardware de equilibrio de carga adicional.

Los servidores de enumeración de aplicaciones pueden usar cualquier forma de equilibrio de carga para emitir una solicitud de ticket porque cada ticket recibido contiene un campo que indica el ID único del STA que lo generó. Siempre y cuando cada ID de STA sea único y todos los servidores de puerta de enlace puedan resolver el ID de STA en una dirección de servidor particular (no balanceada de carga), la operación se realiza correctamente y el tráfico de STA está balanceado de carga.

Q: ¿Puedo usar varios STA con Equilibrio de carga de red de Microsoft?

A: No se puede utilizar el equilibrio de carga de red entre el servidor de puerta de enlace segura y varios STA. Si se configura de esta manera, los usuarios reciben denegaciones intermitentes porque, durante el proceso de validación de tickets, la puerta de enlace puede estar balanceada de carga con una autoridad que no generó originalmente el ticket del usuario.

P: ¿Puedo compartir un solo STA con varias Granjas, Puertas de enlace y Servidores de Enumeración?

A: Sí, se puede compartir un solo STA entre cualquier número de servidores de puerta de enlace segura y servidores de enumeración de aplicaciones. El STA no está restringido a ningún servidor de enumeración de dominios, granjas o aplicaciones en particular. Es un servicio XML anónimo.

Solución de problemas

P: ¿Cómo se debe configurar IIS para alojar el STA?

La URL de STA / Scripts / CtxSta.la dll debe servirse con el acceso anónimo habilitado. Si apunta cualquier navegador web a la URL de STA, no se le solicitará una contraseña.

• Debe conceder permisos a los Scripts de recursos y Ejecutables en la metabase de IIS. Este permiso no es necesario para toda la carpeta /Scripts, pero se puede establecer para CtxSta.archivo dll individualmente.
• Para Secure Gateway Versión 1.1 y anterior, no habilite las opciones Requerir SSL y requerir SSL de 128 bits.
• De forma predeterminada, se necesitan los siguientes permisos de cuenta:

En servidores Windows 2000

• La cuenta IUSR_MachineName necesita acceso de lectura a CtxSta.DLL.
• La cuenta IWAM_MachineName necesita modificar el acceso al directorio del archivo de registro, que es \Inetpub\Scripts de forma predeterminada.

En servidores Windows 2003

• La cuenta IUSR_MachineName necesita acceso de lectura a CtxSta.DLL.
• La cuenta de Servicio de red integrada necesita modificar el acceso al directorio del archivo de registro, que es \Inetpub\Scripts de forma predeterminada.

P: ¿Cómo habilito el registro en el STA?

A: Con el Bloc de notas, edite el archivo \Inetpub\Scripts \ CtxSta.config en el servidor STA y localice la línea que dice LogLevel = 0. Para un registro máximo, cambie esto a LogLevel = 3. Debe reiniciar el Servicio de publicación en la World Wide Web para que los cambios surtan efecto.
Nota: Después de habilitar el registro, la cuenta de usuario bajo cuya autoridad se ejecuta el STA (IUSR_MachineName en Windows 2000 o Servicio de red en Windows 2003 de forma predeterminada) debe tener acceso de escritura al directorio del archivo de registro, que es \Inetpub\Scripts de forma predeterminada. También puede cambiar el directorio del archivo de registro al editar CtxSta.config.

P: ¿Por qué la herramienta Microsoft IISLockDown rompe el STA?

A: Si acepta todas las configuraciones predeterminadas de la herramienta IISLockDown, la carpeta /Scripts se deshabilita. El STA se implementa como un filtro ISAPI publicado como / Scripts / CtxSta.dll; al deshabilitar el directorio / Scripts, se deniega el acceso al STA. Habilite la carpeta / Scripts y permita el acceso a scripts y ejecutables para que el STA funcione.

P: ¿Cómo puedo probar el STA para asegurarme de que funciona correctamente?

A: Si apunta un navegador web a la URL de STA, verá una página en blanco en blanco o el mensaje » No se permite el recurso 405.»Cualquiera de estos resultados indica un STA. Puede ponerse en contacto con el STA de esta manera desde la consola de su servidor de puerta de enlace segura y también desde cualquier servidor de enumeración de aplicaciones configurado para usar la puerta de enlace. Si recibe un cuadro de diálogo de autenticación que le solicita una contraseña, el STA no se publica de forma anónima y es necesario eliminar los requisitos de autenticación.

Para verificar que el servidor de enumeración de aplicaciones está solicitando tickets STA correctamente, mire los archivos generates que genera. Por ejemplo, desde la Interfaz Web 2.0, puede hacer clic con el botón secundario en el icono de una aplicación publicada y guardar el resultado como inicio.a. Lanzamiento abierto.ic en el bloc de notas y ver la línea Address=. Para el funcionamiento normal de Secure Gateway, el parámetro Address contendrá un ticket en lugar de una dirección de servidor XenApp real.

P: ¿Cómo interpreto los archivos de registro STA?

A: Si habilita el registro configurando LogLevel=3 en CtxSta.configuración, verá los detalles de cada ticket y solicitud de datos recibidos por el STA. Recuerde que una solicitud de ticket es generada por un servidor de enumeración de aplicaciones, como una interfaz web, y el servicio Secure Gateway realiza una solicitud de datos. Si el archivo de registro muestra varias solicitudes de ticket pero ninguna solicitud de datos, esto implica que el servidor de enumeración de aplicaciones puede llegar al STA, pero el servidor de puerta de enlace segura no puede. También puede implicar que los usuarios no pueden llegar al servidor de puerta de enlace.

Durante el funcionamiento normal, la función de uso compartido de sesiones del Cliente IC puede hacer que los tickets se soliciten al STA, pero nunca sean reclamados por la puerta de enlace. Considere el siguiente escenario:

• Un usuario inicia sesión en la interfaz Web y hace clic en el icono de Outlook. La interfaz Web solicita un ticket al STA y lo envía al usuario en un archivo IC.
• El usuario se conecta a través de Secure Gateway y presenta el ticket de admisión. La puerta de enlace valida el ticket y permite al usuario conectarse a un servidor XenApp que aloja Outlook.
• Después de trabajar unos minutos, el usuario regresa a la lista de aplicaciones en la página de la interfaz Web y hace clic en el icono de Excel. La interfaz Web solicita un segundo ticket al STA y lo envía al usuario en un archivo IC.
• Antes de conectarse a un nuevo servidor para Excel, el Cliente IC comprueba primero si algún servidor existente al que el cliente ya esté conectado tiene disponible la aplicación publicada de Excel.
• El servidor donde el cliente ya está ejecutando Outlook también tiene instalado Excel, por lo que el cliente IC descarta el archivo IC e inicia Excel dentro de la sesión existing existente.
• El segundo ticket solicitado por la Interfaz Web nunca se utiliza porque no era necesaria una segunda sesión deA. De forma predeterminada, el tiempo de espera del ticket se agota después de 100 segundos.

Este escenario daría lugar a una serie de entradas de archivo de registro STA similares a las siguientes:

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

Más actividad sospechosa podría verse algo como esto:

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

Aquí vemos lo que parece ser un atacante que intenta varios tickets uno a la vez, incrementando el ID de ticket con cada intento. En cada caso, la conexión fue rechazada y el STA registró una entrada indicando que el cliente presentó un ticket que no fue reconocido como válido. Para identificar la dirección IP del atacante, busque el siguiente mensaje en el visor de eventos del servidor de puerta de enlace segura:

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

No interprete algunos mensajes de «Ticket NO encontrado» como un ataque. El cliente Win32 Win puede intentar volver a conectarse a una sesión desconectada si la conexión de red del usuario se interrumpe momentáneamente. La función de reconexión automática de clientes no funciona para los usuarios de Citrix Secure Gateway porque, durante cada intento de reconexión, el cliente vuelve a enviar el ticket STA utilizado con el que se conectó originalmente. Por lo general, el cliente intenta volver a conectarse tres o más veces antes de darse por vencido, por lo que verá tres o más mensajes de «Ticket NO encontrado» que hacen referencia al mismo ticket en el registro STA para cada aparición de este problema. Los intentos de reconexión de clientes se caracterizan por el intento de reutilización de un ticket previamente exitoso:

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

Desconecte la reconexión automática de clientes para usuarios de Puerta de enlace segura agregando TransportReconnectEnabled = Off a la sección del archivo IC. La forma correcta de volver a conectarse a una sesión desconectada cuando se utiliza Secure Gateway es volver al servidor de enumeración de aplicaciones y hacer clic de nuevo en el icono de la aplicación.

P: ¿Cuáles son algunos de los errores de configuración comunes observados por el soporte técnico de Citrix?

• La carpeta / Scripts o todo el sitio Web predeterminado se deshabilita como resultado de la ejecución de IISLockDown o de la adhesión a la política de la empresa para proteger los servidores web.
• El registro está habilitado en CtxSta.configuración, pero la cuenta de usuario bajo cuya autoridad se ejecuta el STA (IUSR_MachineName por defecto) no tiene acceso de escritura al directorio del archivo de registro.
• IIS en el servidor STA está configurado para requerir SSL, pero Secure Gateway está configurado para acceder al STA mediante HTTP normal.
• Si el inicio de la aplicación falla, lo primero que debe comprobarse es si los STA en la interfaz StoreFront/Web y NetScaler se dan exactamente de la misma manera o no, es decir, si los STA se dan como Dirección IP en SF/WI, debe proporcionarse utilizando la dirección IP en NS y de manera similar en el caso de FQDN.