FAQ : Autorité de ticket sécurisée Citrix Secure Gateway / NetScaler Gateway

Remarque : Les mêmes principes et concepts sont également valables pour NetScaler Gateway.

Cet article répond à certaines questions fréquemment posées concernant Citrix Secure Ticket Authority (STA). Les questions sont divisées en quatre catégories :

Aperçu

Q: Qu’est-ce que l’Autorité de ticket sécurisée?
Q : Quels produits Citrix interagissent avec la STA ?
Q: Pourquoi le STA est-il nécessaire?
Q : Comment le service STA est-il implémenté ?
Q: Existe-t-il une version de la STA qui ne nécessite pas IIS ?
Q : Où réside le serveur STA ?
Q: Quelles sont les différences entre les différentes versions de la STA ?

Sécurité

Q : Comment le ticket STA est-il généré ?
Q : Qu’est-ce qui constitue un ticket STA ?
Q : Le Ticket est-il validé par rapport au Poste de travail ?
Q : Le Ticket est-il supprimé après utilisation ?
Q : Les tickets sont-ils déjà écrits sur le disque au STA ?
Q: Est-il possible pour quelqu’un de détourner un billet?
Q : Comment puis-je protéger le trafic STA avec SSL ?
Q: La STA doit-elle toujours être adressée à l’aide d’un nom de domaine complet ?
Q : Comment changer le port STA de 80 à autre chose ?
Q : Un attaquant peut-il envoyer des tickets aléatoires à la Passerelle pour se connecter ?
Q: Quelles autres informations sont requises pour ouvrir une session autres qu’un ticket STA valide?
Q: Comment pouvons-nous définir la durée de vie du billet STA, après quoi le billet devrait être invalide?

Évolutivité

Q : De combien de STA ai-je besoin?
Q: Les utilisateurs se connectent-ils via la passerelle le matin et exécutent-ils une seule application publiée toute la journée ou lancent-ils plusieurs applications tout au long de la journée?
Q : Comment puis-je garantir la tolérance aux pannes STA ?
Q: Comment puis-je équilibrer la charge de plusieurs STAs?
Q : Puis-je utiliser plusieurs STA avec l’équilibrage de charge réseau Microsoft ?
Q : Puis-je partager une seule STA avec plusieurs fermes, Passerelles et serveurs d’énumération ?

Dépannage

Q : Comment IIS doit-il être configuré pour héberger la STA ?
Q : Comment activer la journalisation à la STA ?
Q: Pourquoi l’outil Microsoft IISLockDown casse-t-il la STA?
Q: Comment puis-je tester la STA pour être sûr qu’elle fonctionne correctement?
Q: Comment interpréter les fichiers journaux STA ?
Q : Quelles sont les erreurs de configuration courantes observées par le support technique Citrix ?

Aperçu

Q : Qu’est-ce que l’Autorité de ticket sécurisée?

R : La Secure Ticket Authority (STA) est un service Web XML qui échange des informations de serveur XenApp contre des tickets générés aléatoirement. Il est utilisé pour contrôler l’accès d’un serveur Citrix Secure Gateway.

Q : Quels produits Citrix interagissent avec la STA ?

A : XenMobile, Interface Web, StoreFront, XenApp Secure Access Manager, NetScaler Gateway et Citrix Secure Gateway interagissent avec STA. Tout au long de cet article, les types de serveurs suivants sont regroupés dans une seule catégorie appelée serveurs d’énumération d’applications:

• Interface Web 2.0 ou version ultérieure
• Gestionnaire d’accès sécurisé 2.0 ou version ultérieure
• StoreFront
• Les serveurs d’énumération d’applications sont chargés d’authentifier les utilisateurs, d’énumérer les icônes d’applications publiées et de produire un fichier ICA pour un client qui leur permet de se connecter à une application publiée via un serveur de passerelle sécurisée.

Q: Pourquoi le STA est-il nécessaire?

A : Dans les déploiements Citrix Secure Gateway, le serveur de passerelle n’effectue pas l’authentification des demandes entrantes. Au lieu de cela, le serveur de passerelle reporte l’authentification à un serveur d’énumération d’applications et utilise la STA pour garantir que chaque utilisateur est authentifié. Les serveurs d’énumération d’applications ne demandent des tickets que pour les utilisateurs déjà authentifiés sur le serveur Web. Si les utilisateurs ont des tickets STA valides, la passerelle suppose qu’ils ont réussi les vérifications d’authentification sur le serveur Web et qu’ils devraient être autorisés à y accéder.

Cette conception permet au serveur Citrix Secure Gateway d’hériter de toutes les méthodes d’authentification de votre serveur Web. Par exemple, si votre serveur d’interface Web est protégé par RSA SecurID, seuls les utilisateurs authentifiés par SecurID peuvent, de par leur conception, traverser le serveur Secure Gateway.

Q : Comment le service STA est-il implémenté ?

R : La STA est écrite en tant qu’extension ISAPI pour Microsoft Internet Information Services (IIS). L’extension s’appelle CtxSta.dll et est hébergé dans le dossier /Scripts par défaut. D’autres composants communiquent avec la STA en utilisant XML via HTTP.

Les serveurs d’énumération d’applications demandent des tickets au moment du lancement de l’application en envoyant des données à la STA dans le cadre d’une demande de ticket. Les données envoyées à la STA incluent l’adresse du serveur XenApp auquel l’utilisateur se connectera et, dans le cas de Web Interface 2.0 et Secure Access Manager 2.0, des informations étendues sur le nom de l’utilisateur actuel et l’application publiée que l’utilisateur souhaite exécuter. La STA répond en générant un ticket et en le renvoyant au serveur d’énumération d’applications. Ce ticket et ses données correspondantes restent en mémoire à la STA pendant un nombre de secondes configurable (100 par défaut).
Le serveur d’énumération d’applications construit un fichier ICA pour l’utilisateur et insère le ticket STA dans le champ d’adresse du fichier ICA. Lorsque le client se connecte à la passerelle sécurisée, le ticket est présenté et la passerelle doit valider le ticket avant d’établir une session sécurisée pour le client. La passerelle effectue une demande de données en renvoyant le ticket à la STA et en demandant ses données correspondantes en retour. Si elle est validée avec succès, la STA transmet les données d’origine à la passerelle et celle-ci établit un relais entre l’utilisateur final et le serveur XenApp.

Les demandes de ticket et les demandes de données sont effectuées en tant que documents de demande/réponse XML.

Q: Existe-t-il une version de la STA qui ne nécessite pas IIS ?

R: Non, à ce moment, IIS est requis pour héberger la STA. N’oubliez pas que la STA n’a pas à être exposée à un réseau non fiable comme Internet; la STA réside sur votre réseau de confiance et n’est accessible que par les serveurs de passerelle et d’énumération d’applications.

Q : Où réside le serveur STA ?

R : Le serveur STA peut être placé n’importe où tant que la passerelle sécurisée et les serveurs d’énumération d’applications peuvent l’atteindre. Citrix recommande de placer la STA sur le réseau de confiance ou sur une branche distincte de votre pare-feu interne, mais il n’y a aucune exigence pour le serveur STA autre que IIS. La STA n’a pas besoin d’appartenir à un domaine, à une batterie de serveurs XenApp, à une batterie de gestionnaires d’accès sécurisés ou à un autre serveur Web interne, mais le partage de la STA avec une autre fonction est une pratique courante. Un STA est inclus automatiquement dans la configuration de Secure Access Manager 2.0 ; de nombreux administrateurs trouvent pratique de localiser le STA sur un serveur XenApp.

Q: Quelles sont les différences entre les différentes versions de la STA?

R: Il n’y a pas de différences fonctionnelles importantes entre les versions 1.0 et 1.1, mais lors de l’utilisation de la STA 2.0 avec l’interface Web 2.0 ou Secure Access Manager 2.0, des informations étendues sont ajoutées à la demande de ticket : le nom de l’utilisateur et l’application que l’utilisateur souhaite exécuter. Ces données étendues sont consommées par le service de passerelle pour afficher des détails sur chaque session de passerelle dans la console de gestion Secure Gateway 2.0.

Si Secure Gateway 2.0 est configuré pour utiliser une ancienne STA de la version 1.1 ou 1.0, les utilisateurs peuvent se connecter aux applications, mais la console de gestion Secure Gateway affichera  » N/A  » pour le nom d’utilisateur et le nom d’application associés à chaque session ICA. Pour voir les informations étendues dans la passerelle sécurisée 2.0 console de gestion, vous devez utiliser la version 2.0 ou ultérieure de la STA et utiliser Secure Access Manager 2.0 ou Interface Web 2.0 comme serveur d’énumération d’applications.

Sécurité

Q : Comment le ticket STA est-il généré ?

A : L’extension ISAPI CtxSta.la dll utilise la génération de nombres pseudo-aléatoires pour produire une chaîne hexadécimale de 16 octets. Pour des raisons de sécurité, Citrix ne divulgue pas les étapes exactes utilisées pour produire cette séquence aléatoire de caractères.

Q : Qu’est-ce qui constitue un ticket STA ?

A: Le format d’encodage est une chaîne de la forme :

;STA_VERSION; STA_ID; TICKET

Où:

• STA_VERSION est un champ numérique identifiant la version de la STA. Actuellement, les seules valeurs valides pour ce champ sont « 10 » pour les versions STA 1.0 et 1.1 et « 20 » pour la version STA 2.0.
• STA_ID est une séquence de 0 à 16 caractères représentant un nom arbitraire attribué par l’administrateur à une STA particulière. Dans la version 1.x, cette chaîne est par défaut STA01, STA02, etc. Lorsque la STA est installée automatiquement dans le cadre de Secure Access Manager 2.0, l’ID STA est un hachage du nom du serveur. Lorsque plusieurs STA sont partagées par un seul serveur de passerelle, chaque id STA doit être unique. Cela permet à la passerelle de localiser la station qui a créé le ticket et de revenir à cette station pour la validation du ticket. Un ticket créé sur STA01 n’existera pas sur STA02.
• TICKET est une séquence de 32 caractères alphabétiques ou numériques en majuscules générée aléatoirement.

  Par exemple :
  ; 10; STA01; FE0A7B2CE2E77DDC17C7FD3EE7959E79

Q : Le Ticket est-il validé par rapport au Poste de travail ?

R : Non, il n’y a rien qui lie un ticket à un poste de travail particulier. Il est théoriquement possible qu’un ticket soit demandé au poste de travail A puis utilisé à partir du poste de travail B. Pour atténuer ce risque:

• Utilisez toujours HTTPS entre le client et le serveur d’énumération d’applications pour empêcher un attaquant d’intercepter le ticket lorsqu’il passe d’un serveur à un client.
• Réduisez autant que possible la durée de vie du ticket pour réduire le temps nécessaire à un attaquant pour transférer le ticket de la machine A à la machine B.

Rappelez-vous qu’un ticket émis par la STA ne peut être utilisé qu’une seule fois, donc si l’utilisateur prévu sur la Machine A se connecte avec succès, le ticket n’est pas valide pour toutes les tentatives de connexion futures de la Machine A ou de la Machine B.

Q : Le Ticket est-il supprimé après utilisation ?

R : Oui, les tickets sont purgés immédiatement après une demande de données réussie, de sorte qu’ils ne peuvent être utilisés qu’une seule fois. Ils sont également supprimés après un délai d’expiration configurable (100 secondes par défaut) s’ils ne sont pas utilisés.

Q : Les tickets sont-ils déjà écrits sur le disque au STA ?

A: Uniquement lorsque la journalisation détaillée est activée en définissant LogLevel=3 dans CtxSta.configuration. Sinon, la STA conserve tous les tickets en attente (tickets demandés par un serveur d’énumération d’applications mais non encore validés par une passerelle sécurisée) à l’aide d’une base de données en mémoire. Les données XML sont toujours envoyées à la STA à l’aide de la commande HTTP POST, de sorte qu’aucune donnée de ticket significative n’est jamais écrite dans les journaux du serveur Web STA.

Q: Est-il possible pour quelqu’un de détourner un billet?

R : En fonctionnement normal, un billet doit parcourir les quatre segments suivants du réseau:

• De la STA au serveur d’énumération d’applications
• Du serveur d’énumération d’applications au client
• Du client au serveur de passerelle sécurisée
• De la passerelle à la STA

Les premier et dernier segments existent uniquement entre les serveurs de votre DMZ et la STA sur votre serveur de confiance. réseau, ce qui signifie qu’un intrus devrait avoir accès à votre réseau pour intercepter le ticket le long de ces lignes. Néanmoins, ces voies peuvent être cryptées avec SSL si vous utilisez Secure Gateway Version 2.0. Dans Citrix Secure Gateway 1.1 et les versions antérieures, le trafic vers la STA ne peut pas être chiffré à l’aide de SSL.

Pour sécuriser le deuxième segment, placez un certificat sur votre serveur Web d’énumération d’applications et autorisez les clients à se connecter uniquement s’ils utilisent HTTPS. Le troisième segment est toujours sécurisé avec SSL.

Même lorsque tous les liens précédents sont sécurisés avec SSL, les clients sont toujours vulnérables aux attaques des programmes de Chevaux de Troie qui surveillent l’activité des clients. Pour atténuer ce risque, conseillez à vos utilisateurs de se connecter à partir de machines sur lesquelles un logiciel de détection antivirus et de chevaux de Troie est installé.

Q : Comment puis-je protéger le trafic STA avec SSL ?

R : Tout d’abord, installez un certificat de serveur Web sur la copie d’IIS qui héberge la STA. Pour plus d’informations, consultez la documentation IIS.

Configurez votre serveur d’énumération d’applications et votre serveur de passerelle sécurisée pour qu’ils utilisent HTTPS lors de la communication avec la passerelle. Lors de la connexion par HTTPS, les règles suivantes doivent toujours être respectées:

• Vous devez adresser la STA à l’aide d’un nom de domaine complet qui correspond à l’objet du certificat de serveur STA.
• La machine communiquant avec la STA doit pouvoir résoudre le nom de domaine complet de la STA à une adresse IP appropriée.
• La machine communiquant avec la STA doit faire confiance à l’autorité de certification (CA) qui a délivré le certificat de serveur STA.
• Pour répondre aux exigences du troisième élément de puce, le certificat racine de l’autorité de certification doit être installé sur le serveur Secure Gateway et sur le serveur d’énumération d’applications. Faites attention lors de l’installation du certificat racine : Vous ne pouvez pas simplement double-cliquer sur un fichier de certificat racine et exécuter l’assistant d’importation de certificat.

( Cela indique que votre compte utilisateur, et non le serveur ou tout autre service système, fait confiance à l’autorité de certification.) Pour installer un certificat racine à utiliser avec Citrix Secure Gateway ou une interface Web, procédez comme suit:

1. Exécutez Mmc.exe et ajoutez le composant logiciel enfichable Certificats.
2. Lorsqu’on vous demande quels certificats gérer, sélectionnez Compte d’ordinateur, puis Ordinateur local.
3. Développez le nœud Certificats (Ordinateur local) > Autorités de certification Racine de confiance. Cliquez avec le bouton droit sur Certificats, puis sélectionnez Toutes les tâches > Importer.
4. Naviguez pour sélectionner votre certificat racine CA et terminez l’assistant d’importation.

Q : La STA doit-elle toujours être adressée à l’aide d’un nom de domaine complet ?

R : Si vous avez l’intention de sécuriser le trafic vers la STA à l’aide de SSL, tout composant qui accède à la STA, y compris votre serveur de passerelle et votre serveur d’énumération d’applications, doit adresser la STA à l’aide du nom de domaine complet (FQDN) qui correspond à l’objet du certificat de serveur utilisé par IIS sur la STA. Par exemple, dans l’interface Web 2.0, l’adresse STA serait entrée en tant que:https://sta-server.company.com/Scripts/CtxSta.dll

Si vous choisissez de ne pas sécuriser le trafic vers la STA, vous pouvez adresser la STA à l’aide d’une adresse IP, d’un nom d’hôte ou d’un nom de domaine complet.

Q : Comment changer le port STA de 80 à autre chose ?

R : Comme la STA est desservie par IIS, vous modifiez le port STA lorsque vous modifiez le port IIS. L’exemple suivant illustre comment changer le port IIS de 80 à 81.

1. Gestionnaire de Services Internet Ouvert.
2. Cliquez avec le bouton droit sur le site Web par défaut et affichez les propriétés.
3. Dans l’onglet Site Web, changez le numéro de port TCP de 80 à 81.
4. Cliquez sur OK.
   La modification précédente affecte également toutes les autres ressources que vous avez publiées à partir du serveur Web STA. Si vous souhaitez modifier le port de communication STA sans affecter d’autres pages Web hébergées par le même serveur Web, vous pouvez créer un nouveau site Web dans IIS dans le seul but d’héberger le STA. Ce qui suit est un exemple de la façon dont vous créeriez un nouveau site Web sur le port 81 pour la STA.
5. Créer un nouveau dossier physique tel que C:\MYSTA sur le disque dur de votre serveur Web pour servir de racine de document pour le site STA.
6. Créez un sous-répertoire sous MYSTA appelé Scripts. Déplacez les fichiers suivants de votre STA existante dans le nouveau dossier Scripts :
   • CtxSta.dll
   • CtxSta.configuration
   • ctxxmlss.txt
7. Gestionnaire de Services Internet Ouvert.
8. Cliquez avec le bouton droit sur le nom du serveur et sélectionnez Nouveau site Web >.
9. Créer un nouveau site Web appelé « Mon site STA » et C:\MYSTA comme répertoire racine du document.
10. Affichez les propriétés de votre nouveau site Web et remplacez le port TCP par 81.
11. Sous Mon site STA dans Internet Services Manager, cliquez avec le bouton droit sur le dossier Scripts et affichez les propriétés. Dans la section Paramètres de l’application, modifiez les autorisations d’exécution en  » Scripts et exécutables. »

Remarque : Vous pouvez choisir un nom de dossier autre que « Scripts », mais sachez que Secure Gateway et tous les serveurs d’énumération d’applications tels que l’interface Web supposent que la STA est publiée sous /Scripts/CtxSta.dll vous devrez donc également mettre à jour l’URL STA dans les paramètres de ces serveurs.

Q : Un attaquant peut-il envoyer des tickets aléatoires à la Passerelle pour se connecter ?

R : Un attaquant devrait deviner un ticket valide et l’échanger dans les quelques millisecondes suivant la demande du client mais avant que la passerelle ne le réclame.

Q: Quelles autres informations sont requises pour ouvrir une session autres qu’un ticket STA valide?

A : Les utilisateurs ont également besoin d’informations d’identification de domaine ou d’un ticket XenApp Server demandé par le serveur d’énumération d’applications. (Un ticket serveur XenApp n’est pas le même qu’un ticket STA.) La satisfaction de la STA ouvre un chemin d’accès uniquement au réseau de confiance pour un serveur particulier. Une fois sur place, l’utilisateur doit toujours s’authentifier avec des informations d’identification de domaine valides.
Q: Comment pouvons-nous définir la durée de vie du billet STA, après quoi le Billet devrait être invalide?
A : Nous pouvons définir la durée de vie du ticket STA en créant une clé de registre suivante sur le Delivery Controller :
Emplacement : HKLM\Software\Citrix\DesktopServer
Nom : XmlStaTicketLifetimeInSeconds
Type : Valeur Dword: Donnez une valeur en secondes (décimales)
Veuillez effectuer une sauvegarde du registre avant de modifier les valeurs du registre, notez également qu’une modification du registre nécessiterait un redémarrage à l’extrémité du contrôleur.

Évolutivité

Q : De combien de STAs ai-je besoin?

R : La STA n’est accessible que lorsqu’un utilisateur lance une application, la réponse à cette question varie d’un déploiement à l’autre.

Q: Les utilisateurs se connectent-ils via la passerelle le matin et exécutent-ils une seule application publiée toute la journée ou lancent-ils plusieurs applications tout au long de la journée ?

A: Les tâches effectuées par la STA ne sont pas coûteuses en termes de CPU; c’est un service XML léger limité uniquement par les performances d’IIS. Dans un test, un serveur bas de gamme avec un processeur de 1 GHz et 256 Mo de RAM a pris en charge plus de 250 demandes de tickets par seconde, tandis que l’utilisation du processeur est restée inférieure à 60%.

Q : Comment puis-je garantir la tolérance aux pannes STA ?

A : Les serveurs d’énumération d’applications suivants vous permettent tous d’entrer plusieurs URL STA lors de la configuration des paramètres de Secure Gateway:

• Interface Web 2.0
• Gestionnaire d’accès sécurisé 2.0
• StoreFront

Dans tous les cas, si une STA ne répond pas, le serveur d’énumération d’applications essaie une autre STA sur la liste. Chaque serveur de passerelle à son tour doit être configuré avec l’URL STA et l’ID STA unique pour chaque autorité de ticket.

Q: Comment puis-je équilibrer la charge de plusieurs STAs?

R: Des précautions particulières doivent être prises lors de l’équilibrage de charge des autorités de ticket sécurisées. Diverses méthodes peuvent être utilisées pour équilibrer la charge de la connexion entre un serveur d’énumération d’applications et les STAS, mais un serveur de passerelle sécurisée doit toujours contacter chaque STA individuellement en fonction de son id STA. Lors de la configuration de l’adresse de chaque STA dans l’outil de configuration du service de passerelle, chaque adresse STA doit être la véritable adresse du serveur STA — n’entrez pas ici l’adresse d’un équilibreur de charge matériel, d’un nom de cluster ou d’un nom DNS round-robin.

Vitrine, Interface Web 2.0 et Gestionnaire d’accès sécurisé 2.0 tous prennent en charge l’équilibrage de charge round-robin des STAS lorsque plusieurs STAS sont répertoriées. Lorsque cette option est activée, aucun logiciel ou matériel d’équilibrage de charge supplémentaire n’est requis.

Les serveurs d’énumération d’applications peuvent utiliser n’importe quelle forme d’équilibrage de charge pour émettre une demande de ticket car chaque ticket reçu contient un champ indiquant l’ID unique de la station qui l’a généré. Tant que chaque ID STA est unique et que tous les serveurs de passerelle peuvent résoudre l’ID STA à une adresse de serveur particulière (non équilibrée en charge), l’opération réussit et le trafic STA est équilibré en charge.

Q: Puis-je utiliser plusieurs STA avec l’équilibrage de charge réseau Microsoft ?

A : L’équilibrage de charge réseau ne peut pas être utilisé entre le serveur Secure Gateway et plusieurs STA. S’ils sont configurés de cette façon, les utilisateurs reçoivent des refus intermittents car, pendant le processus de validation du ticket, la passerelle peut être équilibrée en charge avec une autorité qui n’a pas généré à l’origine le ticket de l’utilisateur.

Q : Puis-je partager une seule STA avec plusieurs fermes, passerelles et serveurs d’énumération ?

A: Oui, une seule STA peut être partagée entre n’importe quel nombre de serveurs de passerelle sécurisée et de serveurs d’énumération d’applications. La STA n’est pas limitée à un serveur d’énumération de domaine, de batterie de serveurs ou d’applications particulier. C’est un service XML anonyme.

Dépannage

Q : Comment IIS doit-il être configuré pour héberger la STA ?

L’URL STA/Scripts/CtxSta.la dll doit être servie avec un accès anonyme activé. Si vous pointez un navigateur Web vers l’URL de la STA, vous ne serez pas invité à entrer un mot de passe.

• Vous devez accorder l’autorisation des scripts de ressources et des exécutables dans la métabase IIS. Cette autorisation n’est pas nécessaire pour l’ensemble du dossier /Scripts mais peut être définie pour le CtxSta.fichier dll individuellement.
• Pour les versions 1.1 et antérieures de Secure Gateway, n’activez pas les options Require SSL et Require SSL 128 bits.
• Par défaut, les autorisations de compte suivantes sont nécessaires:

Sur les serveurs Windows 2000

• Le compte IUSR_MachineName a besoin d’un accès en lecture à CtxSta.DLL.
• Le compte IWAM_MachineName doit modifier l’accès au répertoire du fichier journal, qui est \Inetpub\Scripts par défaut.

Sur les serveurs Windows 2003

• Le compte IUSR_MachineName a besoin d’un accès en lecture à CtxSta.DLL.
• Le compte de service réseau intégré doit Modifier l’accès au répertoire du fichier journal, qui est \Inetpub\Scripts par défaut.

Q : Comment activer la journalisation à la STA ?

R: À l’aide du bloc-notes, modifiez le fichier \Inetpub\Scripts\CtxSta.config sur le serveur STA et localisez la ligne indiquant LogLevel=0. Pour une journalisation maximale, remplacez cette valeur par LogLevel=3. Vous devez redémarrer le service de publication World Wide Web pour que les modifications prennent effet.
Remarque : Après avoir activé la journalisation, le compte d’utilisateur sous l’autorité duquel la STA s’exécute (IUSR_MachineName sous Windows 2000 ou Service réseau sous Windows 2003 par défaut) doit avoir un accès en écriture au répertoire du fichier journal, qui est \Inetpub\Scripts par défaut. Vous pouvez également modifier le répertoire du fichier journal lorsque vous modifiez CtxSta.configuration.

Q : Pourquoi l’outil Microsoft IISLockDown casse-t-il la STA ?

A: Si vous acceptez tous les paramètres par défaut de l’outil IISLockDown, le dossier /Scripts est désactivé. La STA est implémentée comme un filtre ISAPI publié sous /Scripts/CtxSta.dll ; en désactivant le répertoire /Scripts, vous refusez l’accès à la STA. Activez le dossier /Scripts et autorisez l’accès aux scripts et aux exécutables pour que la STA fonctionne.

Q: Comment puis-je tester la STA pour être sûr qu’elle fonctionne correctement?

R : Si vous pointez un navigateur Web vers l’URL STA, vous verrez soit une page blanche vierge, soit le message  » 405 Ressource non autorisée. »L’un ou l’autre de ces résultats indique un STA fonctionnel. Vous pouvez contacter la STA de cette manière depuis la console de votre serveur de passerelle sécurisée et également depuis n’importe quel serveur d’énumération d’applications configuré pour utiliser la passerelle. Si vous recevez une boîte de dialogue d’authentification vous demandant un mot de passe, la STA n’est pas publiée de manière anonyme et les exigences d’authentification doivent être supprimées.

Pour vérifier que le serveur d’énumération d’applications demande avec succès des tickets STA, examinez les fichiers ICA qu’il génère. Par exemple, à partir de l’interface Web 2.0, vous pouvez cliquer avec le bouton droit sur une icône d’application publiée et enregistrer le résultat en tant que lancement.ica. Lancement ouvert.ica dans le bloc-notes et afficher la ligne Address=. Pour un fonctionnement normal de la passerelle sécurisée, le paramètre Address contiendra un ticket au lieu d’une adresse de serveur XenApp réelle.

Q: Comment interpréter les fichiers journaux STA ?

R : Si vous activez la journalisation en définissant LogLevel=3 dans CtxSta.config, vous verrez les détails de chaque demande de ticket et de données reçues par la STA. N’oubliez pas qu’une demande de ticket est générée par un serveur d’énumération d’applications, comme une interface Web, et qu’une demande de données est effectuée par le service Secure Gateway. Si le fichier journal affiche plusieurs demandes de ticket mais aucune demande de données, cela implique que le serveur d’énumération d’applications peut atteindre la STA, mais le serveur de passerelle sécurisée ne le peut pas. Cela peut également impliquer que les utilisateurs ne peuvent pas atteindre le serveur de passerelle.

Pendant le fonctionnement normal, la fonctionnalité de partage de session du client ICA peut entraîner la demande de tickets auprès de la STA mais ne jamais être réclamée par la passerelle. Considérez le scénario suivant:

• Un utilisateur se connecte à l’interface Web et clique sur l’icône Outlook. L’interface Web demande un ticket à la STA et l’envoie à l’utilisateur dans un fichier ICA.
• L’utilisateur se connecte via une passerelle sécurisée et présente le billet d’entrée. La passerelle valide le ticket et permet à l’utilisateur de se connecter à un serveur XenApp hébergeant Outlook.
• Après avoir travaillé quelques minutes, l’utilisateur revient à la liste des applications sur la page de l’interface Web et clique sur l’icône Excel. L’interface Web demande un deuxième ticket à la STA et l’envoie à l’utilisateur dans un fichier ICA.
• Avant de se connecter à un nouveau serveur pour Excel, le client ICA vérifie d’abord si l’application publiée Excel est disponible sur tous les serveurs existants auxquels le client est déjà connecté.
• Excel est également installé sur le serveur sur lequel le client exécute déjà Outlook, de sorte que le client ICA rejette le fichier ICA et démarre Excel dans la session ICA existante.
• Le deuxième ticket demandé par l’interface Web n’est jamais utilisé car une deuxième session ICA n’était pas nécessaire. Par défaut, le ticket expire après 100 secondes.

Ce scénario se traduirait par une série d’entrées de fichier journal STA similaires aux suivantes:

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

Une activité plus suspecte pourrait ressembler à ceci:

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

Ici, nous voyons ce qui semble être un attaquant essayant différents tickets un à la fois, incrémentant l’ID du ticket à chaque tentative. Dans chaque cas, la connexion a été rejetée et la STA a enregistré une entrée indiquant que le client avait présenté un ticket non reconnu comme valide. Pour identifier l’adresse IP de l’attaquant, recherchez le message suivant dans l’observateur d’événements sur le serveur Secure Gateway:

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

N’interprétez pas certains messages « Ticket introuvable  » comme une attaque. Le client ICA Win32 peut tenter de se reconnecter à une session déconnectée si la connexion réseau de l’utilisateur est momentanément interrompue. La fonctionnalité de reconnexion automatique du client ne fonctionne pas pour les utilisateurs de Citrix Secure Gateway car lors de chaque tentative de reconnexion, le client soumet à nouveau le ticket STA utilisé avec lequel il s’est connecté à l’origine. Le client tente généralement de se reconnecter trois fois ou plus avant d’abandonner, de sorte que vous verrez trois messages « Ticket INTROUVABLE » ou plus faisant référence au même ticket dans le journal STA pour chaque occurrence de ce problème. Les tentatives de reconnexion du client sont caractérisées par la tentative de réutilisation d’un ticket précédemment réussi:

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

Déconnectez la reconnexion automatique du client pour les utilisateurs de Secure Gateway en ajoutant TransportReconnectEnabled=Off à la section du fichier ICA. La bonne façon de se reconnecter à une session déconnectée lors de l’utilisation de Secure Gateway consiste à revenir au serveur d’énumération d’applications et à cliquer à nouveau sur l’icône de l’application.

Q : Quelles sont les erreurs de configuration courantes observées par le support technique Citrix ?

• Le dossier /Scripts ou l’ensemble du site Web par défaut est désactivé en raison de l’exécution d’IISLockDown ou du respect de la stratégie de l’entreprise pour la protection des serveurs Web.
• La journalisation est activée dans CtxSta.config, mais le compte d’utilisateur sous l’autorité duquel la STA s’exécute (IUSR_MachineName par défaut) n’a pas d’accès en écriture au répertoire du fichier journal.
• IIS sur le serveur STA est configuré pour nécessiter SSL, mais Secure Gateway est configuré pour accéder à la STA à l’aide d’un protocole HTTP normal.
• Si le lancement de l’application échoue, la première chose à vérifier est si les STAs sur StoreFront / Interface Web et NetScaler sont donnés exactement de la même manière ou non, c’est-à-dire si les STAs sont donnés comme adresse IP sur SF / WI, il doit être donné en utilisant l’adresse IP sur NS et de la même manière en cas de nom de domaine complet.