Citrix depuis hier a mis en téléchargement sur www.citrix.com, une version gratuite d’un Netscaler (incluant Access Gateway) virtuel limité à 1Mo de bande passante. Il vous faut juste avoir un compte mycitrix (enregistrement gratuit aussi).

Ce qui me permet de remplacer mon Citrix Secure Gateway sous Windows (gratuit) dans ma DMZ de démo par une version sous Linux (aussi gratuit).

Merci à Citrix devrais je dire

A bientôt,
Patrice Jacques-gustave

www.citrixtools.net de Pierre Marmignon, a fêté en douceur sa première année ( Juin 2009) et que de chemin parcouru par Pierre en si peu de temps.

En effet, ses outils (free) disponibles sur son site, sont reconnu dans le monde entier pour ses performances, ses stabilités et surtout pour leur intérêts. Il y a par exemple un outil de clonage de serveur XenApp pour Provisioning Server qui cartonne dans le milieu.

Toi qui débute sur les technologies Citrix, ses outils sont devenu des incontournables dans la communauté international Citrix. Au point que même chez Citrix, il parait que…

Bon Anniversaire à CitrixTools.net et merci Pierre pour ta contribution.

Note : n’hésitez pas à lui faire un retour sur son site je sais que les français aiment pas faire de commentaire mais au vu du boulot (énorme) qu’il utilise pour nous, un petit mot serais pas du luxe
C’est un passionnée qui ne compte ses heures comme moi

Pour la petite histoire, quand j’ai rencontré pierre pour la première fois, il y quelques années déjà, je voyais dans son oeil, le petit jedi dépassé le maitre un jour Mais il a grandit plus vite que je ne le pensais

A bientôt,
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

Ca faisait longtemps que j’avais pas écrit un article sans vidéo . Je vais répondre à certaines interrogations du moment. En essayant d’être le plus simple possible. Faites moi signe si ce qui suit n’est pas clair.

Citrix Secure Gateway:
Chaque édition de XenApp possède un logiciel de VPN SSL pour le protocol ICA. Ce logiciel est inclut directement sur le CD ou dans l’iso XenApp, c’est une fonctionnalité de XenApp. Cet outil se nomme Citrix Secure Gateway. L’idée est de mettre à disposition une architecture XenApp à des utilisateurs externes à l’entreprise de manière sécurisée.

Comment ça marche techniquement du coté utilisateur:
1 – l’utilisateur se connecte à une Web Interface via HTTPS. Il rentre son identification et reçoit en échange la liste des applications publiées par l’administrateur de l’infrastructure XenApp.
2 – l’utilisateur clique alors sur une icône d’application publiée
3 – l’utilisateur se connecte en ICA sous SSL vers cette application publiée

Toute la session utilisateur est donc sous SSL.

Comment ça marche techniquement du coté administration:
1 – l’administrateur doit installer un serveur XenApp, et définir un port XML à l’installation. Le service STA (gestionnaire sécurisée des tickets de sessions) est automatiquement installé aussi par défaut sur le XenApp. Il utilisera le même port que le service XML.
2 – l’administrateur doit installer une Web Interface, qui pointera vers le service XML du serveur XenApp, vers le service STA et vers une passerelle VPN SSL ICA (Citrix Secure Gateway).
3 – l’administrateur doit installer Citrix Secure Gateway dans la DMZ, qui pointera vers le serveur Web Interface et le STA (Secure Ticket Authority – fonctionnalité de XenApp).

Avec ce modèle d’infrastructure, l’utilisateur ne se connecte jamais en direct vers le serveur XenApp, car il ne connait jamais l’adresse IP de ce dernier. Mais uniquement l’adresse de la passerelle Citrix Secure Gateway.

Et dans ce modèle d’infrastructure, seul la passerelle Citrix Secure Gateway peut se connecter au serveur XenApp.

A bientôt

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