Décision de conception : conception de l’intégration StoreFront et Gateway

Le but de cet article est d’approfondir l’intégration de Citrix Gateway avec StoreFront : ce que signifient les paramètres et considérations de conception pour les configurer.

URL de passerelle, URL de rappel et URL GSLB

StoreFront permet aux administrateurs de définir plusieurs passerelles qui peuvent être utilisées pour l’authentification passthrough de passerelle dans un seul magasin. Cette fonctionnalité est grandement bénéfique car elle réduit le nombre de magasins qui doivent être configurés dans des déploiements globaux volumineux. Nous voyons qu’il existe quatre paramètres clés pour que cette intégration fonctionne correctement : URL Citrix Gateway, adresse IP du serveur virtuel, URL de rappel et URL GSLB, qui sont décrits dans les sections suivantes.

URL de passerelle

Le premier écran de configuration lors de la configuration d’une passerelle invite l’administrateur à entrer un nom complet convivial et l’URL de la passerelle, qui est l’URL saisie par les utilisateurs, comme illustré ci-dessous :

Paramètres généraux Figure 1 : Paramètres généraux

StoreFront autorise uniquement la passerelle passerelle à partir des passerelles définies dans sa configuration. Citrix Gateway prend l’URL entrée dans les navigateurs Web des utilisateurs ou dans les clients de l’application Workspace (Receiver) et l’insère dans un en-tête HTTP (XCITRIXVIA). Ces informations sont transmises à StoreFront. StoreFront tente ensuite de faire correspondre cette valeur à l’une des URL de passerelle définies. Le champ URL de la passerelle est obligatoire et doit correspondre à ce qui est entré dans le navigateur Web d’un utilisateur ou dans l’application Workspace (Receiver) pour que le passage de passerelle à StoreFront fonctionne.

URL de rappel et adresses IP de serveur virtuel

Ensuite, nous abordons quelques champs facultatifs : l’adresse IP du serveur virtuel et l’URL de rappel, dont l’utilisation est liée et couverte ensemble. Ces champs apparaissent sur l’écran Paramètres d’authentification de l’assistant de configuration de la passerelle, comme indiqué ici :

Paramètres généraux Figure 2 : Paramètres d’authentification

L’ URL de rappel est destinée à être utilisée par StoreFront pour recueillir des informations supplémentaires sur la session Gateway d’un utilisateur. Il n’est pas strictement utilisé pour l’authentification. Au lieu de cela, il interroge des éléments tels que le nom de la stratégie Session de passerelle appliquée à la session de l’utilisateur. Ces informations supplémentaires peuvent ensuite être utilisées dans le cadre des filtres de politique basés sur le contrôle d’accès Citrix Virtual Apps and Desktops. Elle est également requise dans les scénarios d’authentification « sans mot de passe » tels que lorsque les cartes à puce et SAML sont utilisées pour effectuer une validation supplémentaire sur la session Gateway de l’utilisateur. Pour les déploiements GSLB (Global Site Load Balancing), l’URL de rappel et l’adresse IP du vServer sont utilisées. Ces scénarios sont abordés plus loin dans cet article. Si l’un de ces scénarios n’est pas en cours de lecture, les champs URL de rappel et adresse IP du serveur virtuel ne sont pas obligatoires et peuvent être laissés vides.

Si une URL de rappel est requise et que plusieurs passerelles sont liées à un seul magasin, StoreFront a besoin d’un moyen d’identifier correctement non seulement si le trafic passe par une passerelle, mais quel serveur virtuel Gateway le trafic provient pour acheminer le rappel vers la passerelle correcte qui contient le session. StoreFront effectue d’abord cette action en faisant correspondre l’URL de la passerelle, qu’il reçoit via l’en-tête HTTP XCITRIXVIA comme précédemment couvert. Si plusieurs passerelles ont la même URL de passerelle spécifiée (ce qui se produirait dans les architectures GSLB où la même URL est résolue pour plusieurs serveurs virtuels Gateway individuels), StoreFront revient à utiliser une adresse IP pour identifier une passerelle, qui est une valeur unique. StoreFront reçoit l’adresse VIP du serveur virtuel à partir d’une passerelle via un autre en-tête HTTP (XCITRIXVIAVIP). Une fois reçu, il tente alors de faire correspondre la valeur du champ Adresse IP vServer dans l’une de ses passerelles attribuées. En supposant que StoreFront puisse identifier une passerelle en fonction d’une correspondance d’adresse IP de serveur virtuel, le rappel se termine avec succès. Par conséquent, l’adresse IP du serveur virtuel n’est nécessaire que lorsqu’une URL de rappel est spécifiée et qu’il existe plusieurs passerelles liées à un magasin avec la même URL de passerelle définie.

URL GSLB

Enfin, un paramètre qui n’est pas affiché dans l’interface graphique : l’ URL GSLB. StoreFront version 3.9 a introduit la possibilité via PowerShell de spécifier uniquement un paramètre d’URL GSLB à une définition de passerelle. Cette URL GSLB fonctionne comme une source alternative à partir de laquelle StoreFront accepte les demandes d’authentification pour cette même définition de passerelle. Ce paramètre est visible dans la sortie de la commande Get-STfroamingGateway. Le but de ce paramètre est de réduire le nombre total de passerelles qui doivent être définies pour un seul magasin afin de simplifier l’administration. Sans cela, un objet Gateway doit être défini pour chaque combinaison URL de passerelle+URL de rappel unique pouvant être utilisée par les utilisateurs, qui peut s’ajouter rapidement dans un environnement d’entreprise.

Par exemple, trois passerelles globales derrière une adresse GSLB unifiée (https://www.nsg.com) : une en Amérique, une en Europe, une en Asie, chacune avec une URL de rappel unique nécessiterait trois passerelles définies. En plus de cela, ces administrateurs veulent pouvoir tester l’authentification sur chaque passerelle individuellement. Cela est important pour comprendre s’il y a des problèmes de GSLB, ce qui entraîne la définition de noms alternatifs et uniques pour chaque passerelle. Cette instance signifie qu’un total de six passerelles doivent être configurées pour le Store, comme suit :

Nom d’affichage URL de la passerelle Adresse IP du vServer URL de rappel
GSLB US https://www.nsg.com 1.1.1.1 https://callback-us.nsg.com
GSLB EU https://www.nsg.com 2.2.2.2 https://callback-eu.nsg.com
GSLB AP https://www.nsg.com 3.3.3.3 https://callback-ap.nsg.com
Passerelle USA https://us.nsg.com 1.1.1.1 https://callback-us.nsg.com
Passerelle UE https://eu.nsg.com 2.2.2.2 https://callback-eu.nsg.com
Passerelle AP https://ap.nsg.com 3.3.3.3 https://callback-ap.nsg.com

Tableau 1 : Liste complète des passerelles

En appliquant plutôt le paramètre URL GSLB, le nombre de passerelles définies peut être réduit de moitié, tout en permettant aux utilisateurs de se connecter via toutes les adresses GSLB et Gateway uniques comme suit :

Nom d’affichage URL de la passerelle Adresse IP du vServer URL de rappel URL GSLB
Passerelle USA https://us.nsg.com 1.1.1.1 https://callback-us.nsg.com https://www.nsg.com
Passerelle UE https://eu.nsg.com 2.2.2.2 https://callback-eu.nsg.com https://www.nsg.com
Passerelle AP https://ap.nsg.com 3.3.3.3 https://callback-ap.nsg.com https://www.nsg.com

Tableau 2 : Liste de passerelles consolidée avec URL GSLB

Même si le paramètre est appelé « GSLBurl », il fonctionne comme un nom d’hôte alternatif pour cette définition de passerelle. Il ne doit pas être une adresse GSLB, juste un autre nom par lequel ce même serveur virtuel de passerelle peut être consulté. Un autre cas d’utilisation peut être divisé DNS avec des adresses de passerelle externe/interne qui sont routées vers le même serveur virtuel.

Notez que ce paramètre n’est pas reconnu par l’application Workspace (Receiver). Par conséquent, les URL de l’exemple précédent sont généralement inversées afin que les clients de l’application Workspace (Receiver) puissent continuer à utiliser l’adresse GSLB et que les URL par passerelle puissent être utilisées lors de la connexion via des navigateurs Web :

Nom d’affichage URL de la passerelle Adresse IP du serveur virtuel URL de rappel URL GSLB
Passerelle USA https://www.nsg.com 1.1.1.1 https://callback-us.nsg.com https://us.nsg.com
Passerelle UE https://www.nsg.com 2.2.2.2 https://callback-eu.nsg.com https://eu.nsg.com
Passerelle AP https://www.nsg.com 3.3.3.3 https://callback-ap.nsg.com https://ap.nsg.com

Tableau 3 : URL GSLB ajustée pour Receiver et l’application Workspace

Points clés du design

Pour résumer les sections précédentes :

  • Une URL de passerelle est toujours nécessaire et doit correspondre à ce qui est saisi dans les navigateurs Web ou les clients de l’application Workspace (Receiver)
  • L’URL de rappel n’est nécessaire que si les politiques SmartAccess Citrix Virtual Apps and Desktops, les méthodes d’authentification sans mot de passe (cartes à puce, SAML, etc.) ou les URL GSLB sont utilisées
  • Une adresse IP de serveur virtuel n’est nécessaire que si une URL de rappel est spécifiée et que plusieurs passerelles liées au magasin ont la même URL de passerelle spécifiée
  • L’URL GSLB est un nouveau paramètre qui a été ajouté dans StoreFront 3.9. L’URL simplifie l’intégration de Gateway avec StoreFront lorsqu’un seul serveur virtuel Gateway est accessible via plusieurs URL
  • L’application Workspace (Receiver) ne lit pas le paramètre URL GSLB, de sorte que l’URL de la passerelle est toujours l’URL utilisée par ces clients et l’URL GSLB est une URL alternative qui peut être utilisée par les connexions basées sur un navigateur Web

Sélection d’une « appliance par défaut »

Lorsqu’un administrateur active l’accès distant pour un magasin, une « appliance par défaut » doit être définie comme indiqué dans la capture d’écran.

Appliance par défaut Figure 3 : Appliance par défaut

Pour l’accès basé sur un navigateur Web, le paramètre « appliance par défaut » n’a aucun impact. Pour l’accès basé sur l’application Workspace (Receiver), ce paramètre est téléchargé sur Receiver lors de la connexion au Store dans le cadre de la configuration du Store. La passerelle est ensuite utilisée par défaut. Si toutes les passerelles définies partagent l’URL de la passerelle, là encore, l’occurrence n’a aucun impact (Receiver utilise simplement cette définition de passerelle pour extraire l’URL à interroger pour l’authentification, donc dans les configurations GSLB, cette requête est routée GSLB). Comme indiqué précédemment, l’application Workspace (Receiver) ne lit pas le paramètre « URL GSLB ». Par conséquent, la passerelle définie comme appliance par défaut doit disposer d’une URL de passerelle appropriée, comme indiqué dans le « Tableau 3 : URL GSLB ajustée pour Receiver et l’application Workspace » dans la section précédente.

Si les passerelles liées au Store ont des URL de passerelle différentes, celle qui est définie par défaut par tous les clients Receiver est « nous ». Cette occurrence est problématique si vous avez défini différentes passerelles à utiliser par différents ensembles d’utilisateurs. Par exemple, une passerelle configurée avec l’authentification LDAP + RADIUS pour les utilisateurs avec des jetons et une passerelle configurée avec l’authentification par carte à puce. Si l’utilisateur entre l’URL de la passerelle de carte à puce dans l’application Workspace (Receiver), mais que StoreFront a la passerelle LDAP+RADIUS définie comme la passerelle par défaut, une fois que l’application Workspace (Receiver) se connecte à StoreFront et met en cache la configuration, toutes les futures demandes d’authentification seront envoyées à la passerelle LDAP+RADIUS , malgré ce que l’utilisateur a entré à l’origine. La seule façon de contourner ce problème est un magasin ou un groupe de serveurs distinct.

Points clés du design

  • Le magasin avec accès distant activé possède une passerelle par défaut qui définit l’URL de passerelle utilisée par les clients de l’application Workspace (Receiver)
  • Pour utiliser plusieurs URL de passerelle et l’accès initié par l’application Workspace (Receiver), des magasins ou des groupes de serveurs StoreFront distincts doivent être définis

Routage HDX optimal

En dehors de l’authentification, une autre raison pour laquelle les passerelles peuvent être définies dans StoreFront est le routage HDX optimal. Ce paramètre affecte une passerelle par site ou zone Citrix Virtual Apps and Desktops. Le but du paramètre est de réacheminer la connexion ICA via une passerelle qui peut être différente du point d’authentification d’origine de l’utilisateur (par exemple via une passerelle plus proche du VDA hébergeant la session de l’utilisateur). Si cette passerelle « optimale » n’effectue pas d’authentification, elle n’a besoin que de serveurs STA liés au proxy de session et peut être configurée dans StoreFront en tant que type de passerelle « HDX Routage uniquement », ce qui élimine tous les paramètres d’authentification.

Lorsque vous attribuez cette passerelle à un site (via Gérer les Delivery Controllers) ou à une zone (via Gérer les zones) dans les paramètres du magasin indiqués ici, une case à cocher externe uniquement est facultative.

Routage HDX optimal Figure 4 : routage HDX optimal

Ce paramètre signifie que la passerelle « optimale » ne sera utilisée que pour les sessions ICA provenant « de l’extérieur », c’est-à-dire pour les sessions qui utilisent Gateway passthrough comme type d’authentification (ce qui, selon StoreFront, signifie que l’utilisateur provient de l’extérieur du réseau de l’entreprise). Le paramètre ne s’applique pas aux utilisateurs qui s’authentifient directement auprès de StoreFront (ce qui, selon StoreFront, signifie que l’utilisateur se trouve sur le réseau de l’entreprise). Si cette case est désactivée, toutes les sessions ICA destinées à ce site ou zone seront routées via la passerelle définie, que l’utilisateur soit externe ou interne. Il n’y a pas de case à cocher « interne uniquement ». Cela signifie que l’URL de passerelle définie doit être accessible à partir de tous les emplacements utilisateur possibles, ce qui peut être difficile sans DNS fractionné. Il s’agit d’un autre cas où des magasins distincts (puisqu’il s’agit d’un paramètre au niveau du magasin) peuvent être nécessaires pour des scénarios d’architecture complexes avec routage HDX optimal.

Points clés du design

Pour résumer :

  • La passerelle utilisée pour le routage HDX optimal nécessite uniquement des serveurs STA liés
  • Les passerelles utilisées pour le routage HDX optimal peuvent être « externe seulement » ou « externe et interne », mais pas « interne uniquement »
  • Des magasins ou des groupes de serveurs séparés sont nécessaires pour définir des URL de passerelle internes et externes distinctes pour un routage HDX optimal

Balises

Les balises sont définies séparément des passerelles dans la configuration StoreFront et sont activées automatiquement lorsque vous activez l’accès distant pour un magasin et configurez la première passerelle. Les balises sont des adresses de site Web qui permettent à l’application Workspace (Receiver) d’identifier si le client de point de terminaison se trouve à l’intérieur ou à l’extérieur du réseau d’entreprise et d’acheminer la demande d’accès de manière transparente vers l’URL de base StoreFront, si le client est déterminé comme étant « interne », ou l’adresse de passerelle par défaut, si le est déterminé comme étant « externe » sans demander à l’utilisateur d’entrer davantage. Pour ce faire, l’application Workspace (Receiver) interroge d’abord l’adresse de balise interne (en supposant que l’adresse externe faisant face à Internet peut toujours être accessible), puis revenir aux adresses des balises externes uniquement en cas de défaillance interne. S’il peut atteindre l’URL interne (obtient une réponse HTTP 200), le client est supposé être sur le réseau de l’entreprise et sera dirigé vers l’URL de base StoreFront.

Gestion des balises Figure 5 : Gestion des balises

Les balises ne sont pas utilisées du tout si un utilisateur se connecte via un navigateur Web. En effet, un utilisateur fournit une entrée en saisissant une URL dans la barre du navigateur et dirige donc le navigateur vers une adresse spécifique. Avec l’application Workspace (Receiver), après la configuration initiale, l’utilisateur ne fournit plus aucune information sur l’URL à utiliser. L’application Workspace (Receiver) possède l’URL de base et toutes les URL de passerelle configurées mises en cache dans le cadre de la configuration et doit être en mesure de choisir intelligemment, au nom de l’utilisateur, l’URL à utiliser lorsque celui-ci tente d’utiliser l’application.

Il n’est pas nécessaire de modifier ou de modifier les adresses des balises à moins que les mêmes URL de passerelle et URL de base de StoreFront ne soient utilisées. Dans ce cas, les balises externes et internes seraient alors les mêmes et l’URL interne serait accessible en externe, ce qui irait à l’encontre de l’objectif. Par conséquent, un administrateur devrait choisir de « Spécifier l’adresse de balise » pour la balise interne et entrer dans un site Web accessible uniquement à partir du réseau de l’entreprise. Sinon, il est tout simplement une bonne pratique de dépannage de comprendre comment les adresses des balises sont appliquées afin qu’elles ne soient pas examinées lors de l’étude de problèmes liés à l’accès basé sur un navigateur Web.

Points clés du design

Pour résumer :

  • Les balises ne sont utilisées que par les clients de l’application Workspace (Receiver)
  • Les balises ne sont modifiées que si l’URL de base StoreFront correspond à une URL de passerelle (et est accessible depuis l’extérieur du réseau d’entreprise)

Références

Intégration de Gateway et StoreFront

Configuration du routage HDX optimal

Nouvelles fonctionnalités de StoreFront

Décision de conception : conception de l’intégration StoreFront et Gateway