Continuons dans la série des « qu’est ce que ? »

J’ai abordé ICA précédement, au tour de IMA (Independant Management Architecture)

Un serveur XenApp ou XenDesktop repose sur un service très important, le service Independant Management Architecture.

Considérez ce service comme l’épine dorsale de votre serveur XenApp ou XenDesktop. Ce service s’appuie sur un ensemble de .dll, où chacune à sa propre fonctionnalité.

Ce service permet au serveur de communiquer avec un magasin de données centralisé (DataStore – qui contient toutes les informations statiques d’une ferme de serveur XenApp ou XenDesktop), ou de communiquer avec un autre serveur. etc…

En somme si votre service IMA ne fonctionne pas ou est corrompu, vous mettez votre serveur en péril, ainsi que le rendu utilisateur au final. D’où l’importance de vérifier constamment son bon mode de fonctionnement, notamment par health monitoring de XenApp par exemple ou par healthcheck de NetScaler autre exemple…il existe bien des méthodes bien sur pour s’assurer que le service est up dans de bonnes conditions.

Le port utilisé par le services IMA sont 2512 (connexion avec le magasin de données) et le 2513 (connexion avec les consoles d’administrations)

Je reste ouvert aux commentaires et si vous souhaitez ajouter des commentaires, n’hésitez pas.
A bientôt,

Patrice Jacques-gustave

Eric Fourn s’est gentiment proposé, fan (et expert) Mac Apple qu’il est, de nous partager son expérience sur le tout nouveau Client Citrix ICA pour iPhone. Je mets son article dans la Base Documentaire. Et ci-dessous un extrait de son premier article, pour vous donner une petite idée :

« …Cet article a pour but de présenter la première application pour Apple iPhone OS de lʼéditeur Citrix systems.

I l sʼagit dʼun client XenApp implémentant donc le protocole ICA (Independant Computing Architecture) afin dʼétablir des connexions à des applications publiées sur une ferme de serveurs XenApp. Ce client appelé le citrix receiver est en version 0.9.0. La version 1.0 est en développement. La version présentée est une «technology preview».

Lʼapplication est gratuite et disponible sur Appstore (iTunes), en anglais uniquement pour le moment… »

prez_citrix_iphone-partI-ericF.pdf – 1,7 Mo

Merci à Eric Fourn pour sa participation. Nous attendons patiemment la suite…;)

Patrice Jacques-gustave

Je continue dans la lancée d’une mise en place de Citrix Secure Gateway. Cette article suit donc le post « Les fondamentaux – Architecture Citrix Secure Gateway – Part 1″.

Une fois que vous avez en tête les différents composant, je vais vous décrire comment techniquement tout cela s’enchaîne. Tout ce que je décris en dessous se déroule en très peu de seconde, mais il s’en passe des choses en fait, bonne lecture à tous:

1- l’utilisateur ouvre un navigateur Web et lance une URL en HTTPS. L’url correspond au nom FQDN d’une passerelle Citrix Secure Gateway (tescitrixoupas.demo.fr par exemple),

2- La passerelle CSG envoie son certificat serveur vers le navigateur Web. Le poste utilisateur doit donc posséder le certificat racine de l’entité certifiante qui a créée le certificat serveur,

3- Une fois la liaison SSL établie, la passerelle CSG présente la page d’authentification de la Web Interface. Donc par défaut, l’utilisateur est en HTTPS vers la CSG et CSG communique en HTTP avec la Web Interface (ce flux peut être aussi sécurisé par un certificat SSL),

4- L’utilisateur entre son identification, Web Interface soumet cette identification au serveur XenApp via le port XML de XenApp. XenApp interroge l’Active Directory ou la NDS Novell ou la base SAM local, et si le compte est valide, il retourne la liste des applications aux-quelles l’identifiant à droit et l’envoie à la Web Interface,

5- La Web Interface construit donc une page HTML avec les icônes des applications publiées.

6- L’utilisateur clique sur une icône d’application publiée,

7- Web Interface interroge le serveur XenApp, pour connaître l’adresse IP du serveur XenApp de la ferme le plus disponible à l’instant T,

8- Web Interface soumet cette adresse IP au Secure Ticket Authority. le STA sotcke cette adresse IP et donne un ticket de session tronqué à Web Interface,

9- Web Interface construit un fichier de connexion .ica à partir d’un fichier template. Ce fichier de connexion .ica comprend l’adresse FQDN de la passerelle CSG, le ticket de session STA tronqué, l’identifiant du STA (qui n’est exploitable que par la CSG), le nom de l’application publiée et pleins d’autres options de session. Ce fichier est envoyé via le canal SSL vers le poste utilisateur,

10- Ce fichier .ica est interprété par un client Citrix. Ce dernier tente d’ouvrir une session ICA sous SSL vers la passerelle CSG,

11- La passerelle CSG envoie son certificat serveur vers le poste utilisateur. le poste utilisateur doit donc avoir le certificat racine de l’autorité de certification qui à créée le certificat serveur de la passerelle CSG,

12- une fois le tunnel SSL créée, le client ICA ouvre une session ICA vers la passerelle CSG en présentant les informations contenu dans le fichier .ica. La passerelle CSG envoie le ticket de session STA vers celui qui l’a créée et lui demande si ce ticket de session est bien valide. Si oui le STA envoie l’adresse IP du serveur XenApp, qu’il avait stocké à la demande de la Web Interface, à la passerelle CSG,

13- la passerelle établie une connexion ICA sous le port 1494 vers le serveur XenApp.

Donc l’utilisateur se connecte toujours à la passerelle CSG en ICA sous SSL (port 443) et la passerelle CSG se connecte en ICA (port 1494 ou 2598).

J’espère que ça vous éclaire un peu plus

A bientôt pour la partie 3

PS: je vais décrire ce type de connexion sécurisée en plusieurs partie, histoire de ne pas faire de long article (chiant à lire )

Patrice Jacques-gustave