Citrix a mis à jour son fichier sur la liste des ports TCP Citrix, il date désormais d’Avril 2011. Il est disponible dans la base documentaire de ce site. XenDesktop 5 apparaît maintenant dedans, par exemple.

Ce document donne les ports TCP du:
- Citrix License Server
- Citrix XenApp, Presentation Server
- Citrix XenDesktop
- Citrix Provisioning Services
- Citrix Receiver
- Citrix XenServer
- Citrix Lab Manager
- Citrix Stage Manager
- Citrix Storage Link
- Citrix Netscaler, Access Gateway, Secure Gateway
- Citrix Branch Repeater
- Citrix Edgsight
- Citrix Password Manager
- Citrix Smart Auditor
- Citrix Workflow Studio
- Citrix Online Services

Citrix Web Interface n’est pas mentionné car ce produit s’appuie sur les ports TCP du serveur web sur lequel il est installé. Par ailleurs, Citrix XML Broker, Citrix Secure Ticket Authority s’appuie sur le port déclaré du service XML XenApp Server lors de son installation.

Bonne lecture et merci à Vincent R. de Citrix pour cette information.

Note; Information tirée de l’article Citrix ; http://support.citrix.com/article/ctx101810

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

Il y a dans la base de connaissances CTXReports que vous devez avoir dans votre boite à outil. Essayez le, car il remonte les informations suivantes (utiles pour le debug ou quand vous appelez le support Citrix ) :
Farm Connection Limit Settings
Farm CPU Optimization Settings
Farm Memory Optimization Settings
Farm License Server Settings
Farm Access Control Settings
Farm ICA Keep Alive Settings
Farm ICA Settings
Farm Application Isolation Settings
Farm Metaframe Settings
Farm Session Reliability Settings
Farm SNMP Settings
Farm Speed Screen Settings
Farm Published Application Name

Server Hotfix List
Server Published Application Names
Server Load Evaluator Name
Server Presentation Server Edition
Server ICA Port Number
Server RDP Port Number
Server Load
Server Zone Preference
Server ICA Keep Alive Settings
Server Application Isolation Settings
Server License Server Settings
Server CPU Optimization Settings
Server Memory Optimization Settings
Server Metaframe Settings
Server ICA Settings
Server Speed Screen Settings
Server SNMP Settings
Server Zone Data Collector

Tiré de l’article : http://support.citrix.com/article/CTX119955

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

Pour continuer sur la mise en place d’une maquette XenDesktop 2.0, je met en ligne l’installation de l’agent qui permet de rajouter un port d’écoute ICA sur un windows XP.

Ce qui permettra à un utilisateur de se connecter au travers du WAN. Puisque que le protocol ICA est optimisé et dynamique.

Pour résumé la technologie mis en place pour le protocol ICA est la même que pour les serveurs Xenapp/Presentation Server.

Du coup, il est possible d’imaginer ceci : un utilisateur se connecte depuis chez un client sur un bureau (basé dans le Datacenter, physique ou virtuel) à partir duquel il aurait soit des applications installées sur le bureau virtuel , soit installées sur un serveur XenApp, soit streamées. En terme d’architecture il y a matière à creuser.

Durée de la vidéo : 2 minutes 47 secondes

Pour télécharger, faites un clic droit et « enregistrer la cible sous… » : [download#9]

Note : Vous retrouvez toutes les vidéos et autres dans la section téléchargement

Patrice Jacques-gustave