Certains auront peut être eu la curiosité de regarder s’il était possible de mettre des options sur l’installation de XenDesktop. Pour l’exemple de la vidéo que je vous mets en ligne, je me suis servi de XenDesktop 4.

Comme je suis tombé une nouvelle fois sur quelqu’un me demandant comment installer juste le Desktop Delivery Controler sans installer Web Interface, je me suis dit que cela pouvait servir à d’autres.

Pour rappel ; le Desktop Delivery Controler à pour rôle de répartir les demandes de connections vers les postes de travail virtuels (système d’exploitation sous Windows XP, Vista, 7 possédant un Virtual Desktop Agent). Ce Desktop Delivery Controler permet donc de publier des postes de travail basé sur le protocole dynamique ICA (port 1494 et 2598).

Dans la vidéo, vous verrez ce qui s’installe réellement et pour ceux qui connaissent XenApp, vous ne serez pas dépayser à mon avis.

Bonne lecture,
Durée de la vidéo : 12 minutes 56 sec | format (flash en .swf) 1024×786 pixels
Taille de la vidéo : 2,97 Mo | Auteur : tescitrixoupas | Date de création : 12 Janvier 2010

Retrouvez toutes les vidéos dans la section Téléchargement.

A bientôt,
Patrice Jacques-gustave

J’archive ce précieux pdf et je vous le met en téléchargement Citrix_TCP_Ports.pdf

Ce document indique les ports pour les produits suivants :
Access Gateway 4.5 Advanced & Standard Edition
Access Gateway 4.6 Advanced & Standard Edition
Access Gateway 7.0/8.0/8.1 Enterprise Edition
Access Gateway 9.0/9.1 Enterprise Edition
Branch Repeater 4.5/5.0/5.5
Branch Repeater with Windows Server 1.0/1.5/2.0
Citrix Licensing 11.5/11.6
Citrix Licensing for 4.5
EasyCall 2.1/2.2
EdgeSight for Presentation Server 4.5
EdgeSight for XenApp 5.0/5.1
GoToAssist 7.0
GoToMeeting 3.0
Lab Manager 3.6
Password Manager 4.5/4.6
Presentation Server 4.5 for Windows Server 2003
Provisioning Server 4.5/5.0/5.1
SmartAuditor 1.1/1.2
Workflow Studio 1.0/2.0
XenApp 5.0 for Windows Server 2008 x64
XenDesktop 3.0 x64
XenServer 5.0/5.0 Update 3/5.5

Jeudi 23 Avril 2009 – Mise à jour
Laurent C. m’avait sympathiquement envoyé le fameux document (ci-dessous) reprenant les diverses architectures Citrix avec les ports réseaux associés. Avec beaucoup de retard je le met en ligne. Donc milles excuses Laurent et merci. J’en profite donc pour ré-ouvrir la base documentaire que j’avais mis en place et mettre en dessous une mise à jour de la liste des ports.

Je m’appuie donc de ce document pour démarrer.
Citrix Access Suite 4.2 Connections – format.pdf – 1,7 Mo

Mise à jour 03 Août 2009 : Mise en ligne d’une cartographie basique XenApp mise à jour.

Cet article va essayer de lister tous les ports utilisé par défaut par les solutions Citrix. Liste de ports disponible pour le moment dans cet article : XenApp, Presentation Server, Metaframe, Access Gateway, Edgesight

XenApp / Presentation Server / Metraframe

2512	|port tcp utilisé pour les communications entre serveurs au travers du service IMA (independant management architecture)
2513	|port tcp de communication entre les serveurs (service IMA) et la console d’administration java centralisée (Citrix Management Console)
135	|port tcp utilisé par le service DCOM+ pour la console d’administration centralisée (Access Suite Console – Access Management Console), utilisé aussi pour communiquer avec le serveur de licence « Terminal Server »)
1494	|port tcp utilisé pour le protocol ICA
2598	|port tcp utilisé pour le protocol ICA dans le cadre de la « fiabilité de session »
80 ou 443	|port tcp XML utilisé pour communiquer avec Web Interface
3268 ou/et 3269	|port udp utilisé pour communiquer avec l’Active Directory Microsoft
27000 + des ports aléatoires	|port udp utilisé pour communiquer avec le serveur de licence centralisé Citrix
Illustration:	Cartographie basique d’une architecture XenApp – ports TCP et UDP

Access Gateway

80 :
port tcp utilisé par le « Configuration Utility » et pour communiquer avec le Secure Ticket Authority (STA)

3010 :
port tcp utilisé par le « Configuration Utility » en mode applet java

22 :
port tcp pour se connecter en SSH et transférer des fichiers en utilisant le « Configuration Utility »

389 :
port tcp pour communiquer avec un annuaire LDAP

636 :
port tcp pour communiquer avec un annuaire LDAP en SSL

1812 :
port UDP pour communiquer avec un serveur Radius

443 :
port tcp pour communiquer avec la Web Interface, et le Secure Ticket Authority (STA)

1494 ou 2598 :
port tcp pour communiquer de la MIP vers le lan (session ICA) et si vous avez configurez la fiabilité de session le port tcp utilisé sera plutot le 2598

Edgesight

source : CTX111107
Ports (80, 443, 9035, 9036, 27000, 1433)

80 ou 443 :
port tcp de communication entre l’agent edgesight et le serveur edgesight.

9035 :
Port tcp de communication entre la console web edgesight et l’agent edgesight.

9036 :
port tcp de communication interne au poste où installé l’agent, entre l’agent et la base local. Les processes qui utilisent ce port sont RSCorSvc and FBserver.

2700 :
port tcp de communication pour le serveur de licences

1433 :
port tcp de communication pour la base Edgesight.

Vous pouvez trouvez un shcéma à cette adresse : CTX114355

————-A suivre ————

XenDesktop

XenServer

Provisioning

Wanscaler

Netscaler

Password Manager

Web Interface

Branch Repeater

Patrice Jacques-gustave

 

Petit retour aux basiques, pour répondre à mister Jean

Toute la base de Citrix tourne autour du protocole d’affichage ICA (Independant Computing Architecture), de ses atouts et de sa performance, qui pour le moment n’est pas encore égalée, surtout sur les liens Wan.

A quoi sert il ?
A la base, ce protocole d’affichage vous permet de transférer des données d’un point à un autre. Les données correspondent à du graphisme (essentiellement) entre un OS serveur Windows/Unix et un poste utilisateur (flux descendant), en échange des frappes clavier et souris (flux ascendant).
C’est ça fonction première. Citrix s’est donc focalisé sur les performances de transfert de ses données et surtout le niveau de consommation de bande passante induit à ces transferts.

Depuis un certain temps, il est possible de faire transférer d’autres type de données, comme les impressions, des fichiers, etc…

Techniquement comment ça marche ?
Le protocole ICA est composé de canaux virtuels pour chacun des types de flux ascendants ou descendants. Ainsi je peux retrouver mes imprimantes dans ma session, mes disques locaux, utiliser des scanners, des PDA, utiliser des douchettes à code barre, etc… Vous pouvez soit utiliser les canals virtuels par défaut, soit en développer vous même. Vous pouvez donc monter jusqu’à 32 canals virtuels.

Pour ce faire vous avez besoin de XenApp ou XenDesktop.

Ainsi les applications ou bureaux virtuels exploitées par un utilisateur, seraient exécutés en central et non sur le poste utilisateur (voir le post – « Vidéo – Et vu de l’utilisateur, le VDI XenDesktop ca donne quoi ? » . Par contre pour l’utilisateur, cela est complètement transparent, qu’il soit sous Windows, Mac, Unix, Linux, Windows CE, etc… Il bénéficie de la puissance des machines en central alors qu’il est lui sur une petite machine de faible puissance par exemple.

Une des particularités de l’ICA est sa gestion dynamique, il ne passe sur le réseau que ce dont à besoin l’utilisateur à l’instant T. Si l’utilisateur ne bouge pas dans son application, aucune données n’est envoyées. Si l’utilisateur bouge dans son application ou bureau virtuel, alors seul le refresh de l’interface graphique transite sur le réseau, on est donc bien dans de l’optimisation de bande passante.

Par défaut les ports ICA sont 1494 ou 2598 (pour la fiabilité de session – ce sera pour un autre post .

Je reste ouvert à tous commentaires, et à partager si vous souhaiter ajouter des informations à ce post.

Autres sources d’informations utiles à partir de google :
http://en.wikipedia.org/wiki/Independent_Computing_Architecture

http://www.brianmadden.com/blogs/citrix_metaframe_xp_advanced_technical_design_guide_including_feature_release_2/pages/independent-computing-architecture-ica.aspx

http://www.domsoft.com/citrix/ica.htm

http://www.google.com/url?sa=t&source=web&ct=res&cd=20&url=http//sandyetadrien.free.fr/adrien/pro/Ftravaux Freseau_citrix_presentation.pps

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