XenApp and XenDesktop

Déploiements de carte à puce

Les types de déploiements de carte à puce suivants sont pris en charge par cette version du produit et par les environnements mixtes contenant cette version. D’autres configurations peuvent fonctionner mais ne sont pas prises en charge.

Type Connectivité StoreFront
Ordinateurs appartenant à un domaine local Directement connectés
Accès à distance à partir d’ordinateurs appartenant à un domaine Connectés au travers de NetScaler Gateway
Ordinateurs n’appartenant pas à un domaine Directement connectés
Accès à distance depuis des ordinateurs n’appartenant pas à un domaine Connectés au travers de NetScaler Gateway
Ordinateurs n’appartenant pas à un domaine et clients légers accédant au site Desktop Appliance Connectés au travers des sites Desktop Appliance
Ordinateurs appartenant à un domaine et clients légers accédant à StoreFront au travers de l’adresse URL XenApp Services Connectés via les adresses URL XenApp Services

Les types de déploiement sont définis par les caractéristiques de la machine utilisateur sur laquelle le lecteur de carte à puce est connecté :

  • Indique si la machine appartient à un domaine ou n’appartient pas à un domaine.
  • Comment le périphérique est-il connecté à StoreFront.
  • Quel logiciel est utilisé pour afficher les applications et les bureaux virtuels.

En outre, les applications compatibles avec les cartes à puce, telles que Microsoft Word et Microsoft Excel, peuvent être utilisées dans ces déploiements. Ces applications permettent aux utilisateurs de signer numériquement ou de crypter des documents.

Authentification bimodale

Lorsque cela est possible dans chacun de ces déploiements, Receiver prend en charge l’authentification bimodale en offrant à l’utilisateur le choix d’utilisation d’une carte à puce ou de saisie de leur nom d’utilisateur et mot de passe. Ceci est utile si la carte à puce ne peut pas être utilisé (par exemple, si l’utilisateur l’a laissé chez lui, ou que le certificat d’ouverture de session a expiré).

Étant donné que les utilisateurs de machines n’appartenant pas à un domaine ouvrent une session sur Receiver pour Windows directement, vous pouvez autoriser les utilisateurs à revenir à l’authentification explicite. Si vous configurez l’authentification bimodale, les utilisateurs sont initialement invités à ouvrir une session à l’aide de leurs cartes à puce et codes PIN mais ont la possibilité de sélectionner l’authentification explicite s’ils rencontrent des problèmes avec leurs cartes à puce.

Si vous déployez NetScaler Gateway, les utilisateurs ouvrent une session sur leurs machines et sont invités par Receiver pour Windows à s’authentifier auprès de NetScaler Gateway. Cela s’applique aussi bien aux machines appartenant à un domaine qu’à celles n’appartenant pas à un domaine. Les utilisateurs peuvent ouvrir une session sur NetScaler Gateway à l’aide de leurs cartes à puce et codes PIN, ou avec des informations d’identification explicites. Cela vous permet de fournir aux utilisateurs une authentification bimodale pour l’ouverture de session NetScaler Gateway. Configurez l’authentification pass-through via NetScaler Gateway à StoreFront et déléguez la validation des informations d’identification à NetScaler Gateway pour les utilisateurs de cartes à puce de façon à ce que les utilisateurs soient authentifiés auprès de StoreFront de manière silencieuse.

Considérations relatives à la forêt Active Directory

Dans un environnement Citrix, les cartes à puce sont prises en charge dans une forêt unique. Les ouvertures de session par carte à puce entre les forêts nécessitent une approbation de forêt bidirectionnelle pour tous les comptes d’utilisateur. Les déploiements plus complexes de forêts multiples impliquant des cartes à puce (c’est-à-dire, où les approbations sont uniquement à sens unique ou de types différents) ne sont pas pris en charge.

Vous pouvez utiliser des cartes à puce dans un environnement Citrix qui comprend des bureaux distants. Cette fonctionnalité peut être installée localement (sur la machine utilisateur à laquelle la carte à puce est connectée) ou à distance (sur le bureau distant à laquelle la machine utilisateur se connecte).

Stratégie de retrait de carte à puce

La stratégie définie pour le retrait de la carte à puce sur le produit détermine ce qui se passe lorsque vous retirez la carte à puce du lecteur au cours d’une session. Cette stratégie est configurée et gérée par le système d’exploitation Windows.

Paramètre de stratégie Comportement du Bureau
Aucune action Aucune action.
Verrouiller la station de travail La session de bureau est déconnectée et le bureau virtuel est verrouillé.
Forcer la fermeture de session L’utilisateur est obligé de fermer la session. Si la connexion réseau est interrompue et que ce paramètre est activé, la session peut être fermée et l’utilisateur peut perdre des données.
Déconnecter en cas de session Terminal Server La session est déconnectée et le bureau virtuel est verrouillé.

Vérification de la révocation des certificats

Si la vérification de la révocation des certificats est activée et qu’un utilisateur insère une carte à puce avec un certificat non valide dans un lecteur de carte, l’utilisateur ne peut pas authentifier ou accéder au bureau ou à l’application associée à ce certificat. Par exemple, si le certificat non valide est utilisé pour le déchiffrement de messagerie, l’e-mail reste crypté. Si d’autres certificats sur la carte, tels que ceux utilisées pour l’authentification, sont toujours valides, ces fonctions restent actives.

Exemple de déploiement : ordinateurs appartenant à un domaine

Ce déploiement implique des machines utilisateur appartenant à un domaine qui exécutent Desktop Viewer et se connectent directement à StoreFront.

image localisée

Un utilisateur ouvre une session sur une machine à l’aide d’une carte à puce et du code confidentiel. Receiver authentifie l’utilisateur à un serveur StoreFront à l’aide de l’authentification Windows intégrée (IWA). StoreFront transmet les identificateurs de sécurité (SID) de l’utilisateur à XenApp ou XenDesktop. Lorsque l’utilisateur démarre un bureau virtuel ou une application, l’utilisateur n’est pas invité à entrer un code confidentiel, car la fonctionnalité d’authentification unique est configurée sur Receiver.

Ce déploiement peut être étendu à une DMZ double avec l’ajout d’un deuxième serveur StoreFront et un serveur hébergeant des applications. Un Receiver depuis le bureau virtuel s’authentifie sur le deuxième serveur StoreFront. Toute méthode d’authentification peut être utilisée pour cette seconde connexion. La configuration indiquée pour le premier hop peut être réutilisée dans le deuxième hop ou utilisée dans le deuxième hop uniquement.

Exemple de déploiement : accès à distance à partir d’ordinateurs appartenant à un domaine

Ce déploiement implique des machines utilisateur appartenant à un domaine qui exécutent Desktop Viewer et se connectent à StoreFront via NetScaler Gateway/Access Gateway.

image localisée

Un utilisateur ouvre une session sur une machine à l’aide d’une carte à puce et d’un code confidentiel, puis ouvre une session sur NetScaler Gateway/Access Gateway. Cette seconde ouverture de session peut être effectuée avec la carte à puce et un code confidentiel ou un nom d’utilisateur et un mot de passe car Receiver permet l’authentification bimodale dans ce déploiement.

L’utilisateur ouvre automatiquement une session sur StoreFront, qui transmet les identificateurs de sécurité (SID) de l’utilisateur à XenApp ou XenDesktop. Lorsque l’utilisateur démarre un bureau ou une application virtuel(le), l’utilisateur n’est pas invité à entrer à nouveau un code confidentiel, car la fonctionnalité d’authentification unique est configurée sur Receiver.

Ce déploiement peut être étendu à une DMZ double avec l’ajout d’un deuxième serveur StoreFront et un serveur hébergeant des applications. Un Receiver depuis le bureau virtuel s’authentifie sur le deuxième serveur StoreFront. Toute méthode d’authentification peut être utilisée pour cette seconde connexion. La configuration indiquée pour le premier hop peut être réutilisée dans le deuxième hop ou utilisée dans le deuxième hop uniquement.

Exemple de déploiement : ordinateurs n’appartenant pas à un domaine

Ce déploiement implique des machines utilisateur n’appartenant pas au domaine qui exécutent Desktop Viewer et se connectent directement à StoreFront.

image localisée

Un utilisateur ouvre une session sur une machine. En général, l’utilisateur entre un nom d’utilisateur et un mot de passe, mais puisque la machine n’appartient pas à un domaine, les informations d’identification de cette ouverture de session sont facultatives. Comme l’authentification bimodale est possible dans ce déploiement, Receiver invite l’utilisateur à entrer une carte à puce et un code confidentiel ou un nom d’utilisateur et un mot de passe. Receiver s’authentifie ensuite auprès de StoreFront.

StoreFront transmet les identificateurs de sécurité (SID) de l’utilisateur à XenApp ou XenDesktop. Lorsque l’utilisateur démarre un bureau virtuel ou une application, l’utilisateur est invité à entrer un code confidentiel, car la fonctionnalité d’authentification unique n’est pas disponible dans ce déploiement.

Ce déploiement peut être étendu à une DMZ double avec l’ajout d’un deuxième serveur StoreFront et un serveur hébergeant des applications. Un Receiver depuis le bureau virtuel s’authentifie sur le deuxième serveur StoreFront. Toute méthode d’authentification peut être utilisée pour cette seconde connexion. La configuration indiquée pour le premier hop peut être réutilisée dans le deuxième hop ou utilisée dans le deuxième hop uniquement.

Exemple de déploiement : accès à distance à partir d’ordinateurs n’appartenant pas à un domaine

Ce déploiement implique des machines utilisateur n’appartenant pas au domaine qui exécutent Desktop Viewer et se connectent directement à StoreFront.

image localisée

Un utilisateur ouvre une session sur une machine. En général, l’utilisateur entre un nom d’utilisateur et un mot de passe, mais puisque la machine n’appartient pas à un domaine, les informations d’identification de cette ouverture de session sont facultatives. Comme l’authentification bimodale est possible dans ce déploiement, Receiver invite l’utilisateur à entrer une carte à puce et un code confidentiel ou un nom d’utilisateur et un mot de passe. Receiver s’authentifie ensuite auprès de StoreFront.

StoreFront transmet les identificateurs de sécurité (SID) de l’utilisateur à XenApp ou XenDesktop. Lorsque l’utilisateur démarre un bureau virtuel ou une application, l’utilisateur est invité à entrer un code confidentiel, car la fonctionnalité d’authentification unique n’est pas disponible dans ce déploiement.

Ce déploiement peut être étendu à une DMZ double avec l’ajout d’un deuxième serveur StoreFront et un serveur hébergeant des applications. Un Receiver depuis le bureau virtuel s’authentifie sur le deuxième serveur StoreFront. Toute méthode d’authentification peut être utilisée pour cette seconde connexion. La configuration indiquée pour le premier hop peut être réutilisée dans le deuxième hop ou utilisée dans le deuxième hop uniquement.

Exemple de déploiement : ordinateurs n’appartenant pas à un domaine et clients légers accédant au site Desktop Appliance

Ce déploiement implique des machines utilisateur n’appartenant pas au domaine pouvant exécuter Desktop Lock et se connecter à StoreFront via des sites Desktop Appliance.

Desktop Lock est un composant distinct fourni avec XenApp, XenDesktop et VDI-in-a-Box. Il constitue une alternative à Desktop Viewer et il est conçu principalement pour les ordinateurs Windows réaffectés et les clients légers Windows. Desktop Lock remplace le shell Windows et le Gestionnaire des tâches dans ces machines utilisateur, ce qui empêche les utilisateurs d’accéder à des machines sous-jacentes. Grâce à Desktop Lock, les utilisateurs peuvent accéder aux bureaux Windows Server Machine et aux bureaux Windows Desktop Machine. l’installation de Desktop Lock est facultative.

image localisée

Un utilisateur ouvre une session sur une machine avec une carte à puce. Si Desktop Lock est en cours d’exécution sur la machine, celle-ci est configurée pour démarrer un site Desktop Appliance au travers d’Internet Explorer exécuté en mode Kiosque. Un contrôle ActiveX présent sur le site invite l’utilisateur à entrer un code confidentiel, et l’envoie à StoreFront. StoreFront transmet les identificateurs de sécurité (SID) de l’utilisateur à XenApp ou XenDesktop. Le premier bureau disponible de la liste alphabétique d’un groupe de bureaux attribué démarre.

Ce déploiement peut être étendu à une DMZ double avec l’ajout d’un deuxième serveur StoreFront et un serveur hébergeant des applications. Un Receiver depuis le bureau virtuel s’authentifie sur le deuxième serveur StoreFront. Toute méthode d’authentification peut être utilisée pour cette seconde connexion. La configuration indiquée pour le premier hop peut être réutilisée dans le deuxième hop ou utilisée dans le deuxième hop uniquement.

Exemple de déploiement : ordinateurs appartenant à un domaine et clients légers accédant à StoreFront via l’adresse URL XenApp Services

Ce déploiement implique des machines utilisateur appartenant à un domaine qui exécutent Desktop Lock et se connectent à StoreFront via les adresses URL XenApp Services.

Desktop Lock est un composant distinct fourni avec XenApp, XenDesktop et VDI-in-a-Box. Il constitue une alternative à Desktop Viewer et il est conçu principalement pour les ordinateurs Windows réaffectés et les clients légers Windows. Desktop Lock remplace le shell Windows et le Gestionnaire des tâches dans ces machines utilisateur, ce qui empêche les utilisateurs d’accéder à des machines sous-jacentes. Grâce à Desktop Lock, les utilisateurs peuvent accéder aux bureaux Windows Server Machine et aux ordinateurs de bureau Windows. l’installation de Desktop Lock est facultative.

image localisée

Un utilisateur ouvre une session sur une machine à l’aide d’une carte à puce et du code confidentiel. Si Desktop Lock est en cours d’exécution sur la machine, il authentifie l’utilisateur à un serveur StoreFront à l’aide de l’authentification Windows intégrée (IWA). StoreFront transmet les identificateurs de sécurité (SID) de l’utilisateur à XenApp ou XenDesktop. Lorsque l’utilisateur démarre un bureau virtuel, l’utilisateur n’est pas invité à entrer un code confidentiel, car la fonctionnalité d’authentification unique est configurée sur Receiver.

Ce déploiement peut être étendu à une DMZ double avec l’ajout d’un deuxième serveur StoreFront et un serveur hébergeant des applications. Un Receiver depuis le bureau virtuel s’authentifie sur le deuxième serveur StoreFront. Toute méthode d’authentification peut être utilisée pour cette seconde connexion. La configuration indiquée pour le premier hop peut être réutilisée dans le deuxième hop ou utilisée dans le deuxième hop uniquement.