Product Documentation

Créer un seul nom de domaine complet (FQDN) pour accéder à un magasin en interne et externe

Oct 31, 2016
Remarque : pour utiliser cette fonctionnalité avec des Receiver de bureau natifs, les versions suivantes sont requises.
  • Windows Receiver 4.2
  • MAC Receiver 11.9

Vous pouvez fournir un accès aux ressources depuis le réseau de votre entreprise et depuis Internet par le biais d'un NetScaler Gateway et simplifier l'expérience utilisateur en créant un seul nom de domaine complet (FQDN) pour à la fois les clients externes itinérants et les clients internes.

La création d'un seul nom de domaine complet est utile pour les utilisateurs qui configurent l'un des logiciels Receiver natifs. Ils n'ont besoin de mémoriser qu'une seule adresse URL qu'ils soient connectés à un réseau interne ou public.

Balises StoreFront pour Receiver natifs

Citrix Receiver tente de contacter des points balises et utilise les réponses pour déterminer si les utilisateurs sont connectés à des réseaux locaux ou publics. Lorsqu'un utilisateur accède à un bureau ou une application, les informations d'emplacement sont transmises au serveur fournissant les ressources afin que les détails de connexion appropriés puissent être renvoyés à Citrix Receiver. Ceci garantit que les utilisateurs ne sont pas invités à rouvrir une session lorsqu'ils accèdent à un bureau ou une application. Pour plus d'informations sur la configuration des points balises, consultez la section Configurer des points balises.

Configurez le vServer NetScaler Gateway et le certificat SSL

Le nom de domaine complet (FQDN) partagé est résolu sur l'adresse IP de l'interface de routeur du pare-feu externe où sur l'adresse IP vServer NetScaler Gateway dans la zone démilitarisée (DMZ) lorsque les clients externes essayent d'accéder aux ressources en dehors du réseau d'entreprise. Assurez-vous que les champs Nom commun et Autre nom de l'objet du certificat SSL contiennent le nom de domaine complet partagé à utiliser pour accéder au magasin en externe. Si vous utilisez une autorité de certification racine tierce comme Verisign plutôt qu'une autorité de certification (CA) d'entreprise pour signer le certificat de passerelle, tout client externe approuve automatiquement le certificat lié au vServer. Si vous utilisez une autorité de certification racine tierce comme Verisign, il n'est pas nécessaire d'importer des certificats d'autorité de certification racine supplémentaires sur les clients externes.

Pour déployer un seul certificat avec le nom commun du nom de domaine complet (FQDN) partagé sur le serveur NetScaler Gateway et le serveur StoreFront, vous devez décider si vous souhaitez prendre en charge la découverte à distance. Si c'est le cas, vérifiez que le certificat est conforme à la spécification relative aux Autres noms de l’objet.

Exemple de certificat de vServer NetScaler Gateway : storefront.exemple.com
  1. Assurez-vous que le nom de domaine complet partagé, l'URL de rappel et l'URL d'alias des comptes sont inclus dans le champ DNS en tant qu'Autre nom de l'objet (SAN).
  2. Vérifiez que la clé privée est exportable de façon à ce que le certificat et la clé puissent être importés dans NetScaler Gateway.
  3. Assurez-vous que Default Authorization est défini sur Allow.
  4. Signez le certificat à l'aide d'une autorité de certification tierce, comme Verisign ou d'une autorité de certification racine d'entreprise pour votre organisation.

Exemples d'autre nom de l'objet pour groupe de serveurs à deux nœuds :

storefront.exemple.com (obligatoire)

storefrontcb.exemple.com (obligatoire)

compte.exemple.com (obligatoire)

storefrontserver1.exemple.com (obligatoire)

storefrontserver2.exemple.com (obligatoire)

Signer le certificat SSL vServer Netscaler Gateway à l'aide d'une autorité de certification (CA)

En fonction de vos besoins, vous avez le choix entre deux options pour choisir le type de certificat signé par une autorité de certification.

  • Option 1: certificat signé par une autorité de certification tierce. Si le certificat lié au vServer Netscaler Gateway est signé par un tiers de confiance, les clients externes n'auront probablement PAS besoin de copier les certificats d'autorité de certification racine dans leurs magasins de certificats d'autorité de certification racine de confiance. Les clients Windows sont livrés avec les certificats d'autorité de certification racine des agences de signature les plus courantes. Les autorités de certification tierces commerciales pouvant être utilisées comprennent DigiCert, Thawte et Verisign. Notez que les appareils mobiles tels que iPad, iPhone et tablettes et téléphones Android peuvent encore nécessiter la copie de l'autorité de certification racine sur l'appareil pour faire confiance au vServer NetScaler Gateway.
  • Option 2 : certificat signé par une autorité de certification racine d'entreprise : si vous choisissez cette option, tous les clients externes nécessitent que le certificat d'autorité de certification racine d'entreprise soit copié sur leurs magasins d'autorité de certification racine de confiance. Si vous utilisez des appareils mobiles sur lesquels des logiciels Receiver natifs sont installés, tels que des iPhones et iPads, créez un profil de sécurité sur ces appareils.

Importer le certificat racine sur des appareils mobiles

  • Les appareils iOS peuvent importer des fichiers de certificat .CER x.509 en tant que pièces jointes à des e-mails, car l'accès au stockage local des appareils iOS n'est généralement pas possible.
  • Les appareils Android requièrent le même format .CER x.509. Le certificat peut être importé à partir du stockage local de l'appareil ou des pièces jointes.

DNS externe : storefront.exemple.com

Assurez-vous que la résolution DNS fournie par le fournisseur de services Internet de votre organisation est soit résolue sur l'adresse IP externe du routeur de pare-feu en périphérie extérieure de la zone démilitarisée (DMZ), soit sur l'adresse IP virtuelle du vServer NetScaler Gateway.

Split-view DNS

  • Lorsque la vue split-view DNS est correctement configurée, l'adresse source de la requête DNS doit envoyer le client vers l'enregistrement DNS A correct.
  • Lorsque les clients accèdent à des réseaux publics et réseaux d'entreprise, leur adresse IP doit s'adapter. En fonction du réseau auquel ils sont actuellement connectés, ils doivent recevoir l'enregistrement A correct lorsqu'ils interrogent storefront.exemple.com.

Importer des certificats émis par une autorité de certification Windows sur NetScaler Gateway

WinSCP est un outil tiers utile pour déplacer des fichiers d'un ordinateur Windows sur un système de fichiers NetScaler Gateway. Copiez les certificats à importer sur le dossier /nsconfig/ssl/ dans le système de fichiers NetScaler Gateway. Vous pouvez utiliser les outils OpenSSL sur NetScaler Gateway pour extraire la clé et le certificat à partir d'un fichier PKCS12/PFX pour créer deux fichiers .CER et .KEY X.509 séparés au format PEM qui peuvent être utilisés par NetScaler Gateway.

  1. Copiez le fichier PFX dans /nsconfig/ssl sur le boîtier NetScaler Gateway ou VPX.
  2. Ouvrez l'interface de ligne de commande NetScaler Gateway.
  3. Pour basculer vers le shell FreeBSD, tapez Shell pour quitter l'interface de ligne de commande NetScaler Gateway.
  4. Pour changer de répertoire, utilisez cd /nsconfig/ssl.
  5. Exécutez openssl pkcs12 -in < fichier de cert importé>.pfx -nokeys -out <nomfichiercert>.cer et entrez le mot de passe PFX lorsque vous y êtes invité.
  6. Exécutez openssl pkcs12 -in <fichier de cert importé>.pfx -nocerts -out <nomfichierclé>.key
  7. Entrez le mot de passe du fichier PFX lorsque vous y êtes invité, puis définissez une phrase secrète au format PEM pour la clé privée pour protéger le fichier .KEY.
  8. Pour vous assurer que les fichiers .CER et .KEY ont été correctement créés dans /nsconfig/ssl/, exécutez ls –al.
  9. Pour retourner à l'interface de ligne de commande NetScaler Gateway, tapez sur Exit.

Stratégie de session de la passerelle Receiver Windows/Mac native

REQ.HTTP.HEADER User-Agent CONTAINS CitrixReceiver && REQ.HTTP.HEADER X-Citrix-Gateway EXISTS

Stratégie de session de la passerelle Receiver pour Web

REQ.HTTP.HEADER User-Agent NOTCONTAINS CitrixReceiver && REQ.HTTP.HEADER Referer EXISTS

Paramètres cVPN et Smart Access

Si vous utilisez SmartAccess, activez le mode Smart Access sur la page des propriétés de vServer NetScaler Gateway. Des licences universelles sont requises pour chaque utilisateur simultané qui accède à des ressources distantes.

Profil Receiver

Configurez l'URL de service des comptes de profil de session sur https://comptes.exemple.com/Citrix/Roaming/Accounts et NON https://storefront.exemple.com/Citrix/Roaming/Accounts.

Ajoutez également cette URL en tant que <allowedAudiences> supplémentaire dans les fichiers de configuration d'authentification et d'itinérance web.config sur le serveur StoreFront. Pour de plus amples informations, consultez la section « Configurer l'URL de base de l'hôte serveur StoreFront, la passerelle et le certificat SSL » ci-dessous.

Profil Receiver pour Web

Paramètres ICA Proxy et du mode Basic

Si vous utilisez un serveur proxy ICA, activez le mode de base sur la page des propriétés de vServer NetScaler Gateway. Seule une licence de plate-forme Netscaler est requise.

Profil Receiver

Profil Receiver pour Web

Configurer l'URL de base de l'hôte serveur StoreFront, la passerelle et le certificat SSL

Le même nom de domaine complet (FQDN) partagé résolu sur le vServer NetScaler Gateway doit également être résolu directement sur l'équilibrage de la charge StoreFront, si un cluster StoreFront a été créé ou qu'une seule adresse IP StoreFront héberge le magasin.

DNS interne : créez trois enregistrements A DNS.

  • storefront.exemple.com doit être résolu sur l'équilibrage de charge StoreFront ou sur une adresse IP du serveur StoreFront.
  • storefrontcb.exemple.com doit être résolu sur l'adresse IP virtuelle du vServer de la passerelle, par conséquent si un pare-feu est présent entre la DMZ et le réseau local d'entreprise, tenez-en compte.
  • accounts.exemple.com : créez un alias DNS pour storefront.exemple.com. Cela permet également la résolution sur l'adresse IP d'équilibrage de charge pour le cluster StoreFront ou une adresse IP du serveur StoreFront.

Exemple de certificat de serveur StoreFront : storefront.exemple.com

  1. Créez un certificat approprié pour le serveur StoreFront ou groupe de serveurs avant l'installation de StoreFront.
  2. Ajoutez le nom de domaine complet partagé aux champs Nom commun et DNS. Assurez-vous qu'ils correspondent au nom de domaine complet (FQDN) utilisé dans le certificat SSL lié au vServer NetScaler Gateway que vous avez créé précédemment ou utilisez le même certificat lié au vServer NetScaler Gateway.
  3. Ajoutez les alias de comptes (comptes.exemple.com) comme un autre SAN au certificat. Notez que les alias de compte utilisés dans le SAN sont ceux utilisés dans le profil de session Netscaler Gateway dans la procédure précédente - Stratégie de session et profil de la passerelle Receiver pour Web.

  4. Vérifiez que la clé privée est exportable de façon à ce que le certificat puisse être transféré vers un autre serveur ou vers de multiples nœuds de groupe de serveurs StoreFront.

  5. Signez le certificat à l'aide d'une autorité de certification tierce, comme Verisign, de votre autorité de certification racine d'entreprise ou d'une autorité de certification intermédiaire.
  6. Exportez le certificat au format PFX y compris la clé privée.
  7. Importez le certificat et la clé privée sur le serveur StoreFront. Si vous déployez un cluster StoreFront NLB Windows, importez le certificat sur chaque nœud. Si vous utilisez un autre équilibreur de charge, tel qu'un vServer LB Netscaler, importez le certificat sur ce dernier.
  8. Créez une liaison HTTPS dans IIS sur le serveur StoreFront et liez-y le certificat SSL importé.

  9. Configurez l'adresse URL de l'hôte de base sur le serveur StoreFront pour correspondre au nom de domaine complet (FQDN) partagé déjà choisi.
    Remarque : StoreFront sélectionne toujours automatiquement le dernier Autre nom de l'objet dans la liste des SAN dans le certificat. Il s'agit simplement d'une suggestion d'adresse URL de base de l'hôte destinée à aider les administrateurs StoreFront Cette adresse est généralement correcte. Vous pouvez la définir manuellement sur toute adresse HTTPS://<FQDN> valide à condition qu'elle existe dans le certificat en tant que SAN. Exemple : https://storefront.exemple.com
localized image

Configurer la passerelle sur le serveur StoreFront : storefront.exemple.com

1. Dans le nœud Magasins, cliquez sur Gérer NetScaler Gateway dans le panneau Actions.

2. Sélectionnez la passerelle dans la liste Passerelle et cliquez sur Modifier.

localized image

 

3. Sur la page Paramètres généraux, indiquez le nom de domaine complet partagé dans le champ URL NetScaler Gateway.

4. Sélectionnez l'onglet Paramètres d'authentification et entrez le nom de domaine complet (FQDN) de rappel dans le champ d'adresse URL de rappel.

localized image

5. Sélectionnez l'onglet Secure Ticket Authority et vérifiez que les serveurs Secure Ticket Authority (STA) correspondent à la liste des Controller déjà configurés dans le nœud Magasin

6. Activez l'accès à distance pour le magasin.

7. Définissez manuellement la balise interne sur les alias de compte (comptes.exemple.com) et elle ne doit pas pouvoir être résolue en dehors de la passerelle. Ce nom de domaine complet (FQDN) doit être différent de la balise externe qui est partagée par l'adresse URL de base de l'hôte StoreFront et le vServer NetScaler Gateway (storefront.exemple.com). N'utilisez PAS le nom de domaine complet (FQDN) partagé car cela crée une situation dans laquelle les balises internes et externes sont identiques.

8. Notez que si vous souhaitez prendre en charge la découverte à l'aide de noms de domaine complets, suivez ces étapes. Si la configuration du fichier de provisioning est insuffisante ou si vous utilisez uniquement Receiver pour Web, vous pouvez ignorer les étapes suivantes.

Ajoutez une entrée <allowedAudiences> supplémentaire dans C:\inetpub\wwwroot\Citrix\Authentication\web.config. Il existe deux entrées <allowedAudiences> dans le fichier d'authentification web.config. Seule la première entrée dans le fichier pour Authentication Token Producer nécessite que vous ajoutiez un autre <allowedAudience>.

9. Recherchez la chaîne <allowedAudiences>. Recherchez l'entrée suivante ci-dessous et ajoutez la ligne affichée en gras, enregistrez et fermez le fichier web.config.

<service id="abd6f54b-7d1c-4a1b-a8d7-14804e6c8c64" displayName="Authentication Token Producer">

..........

..........
               <allowedAudiences>
                     <add name="https-storefront.example.com" audience="https://storefront.example.com/" />
                           <add name="https-accounts.example.com" audience="https://accounts.example.com/" />
                 </allowedAudiences>

9. Dans C:\inetpub\wwwroot\Citrix\Roaming\web.config. Recherchez l'entrée suivante ci-dessous et ajoutez la ligne affichée en gras, enregistrez et fermez le fichier web.config.

<tokenManager>
          <services>
                <clear />
..........

..........

                   </trustedIssuers>
                   <allowedAudiences>
                       <add name="https-storefront.example.com" audience="https://storefront.example.com/" />
                               <add name="https-accounts.example.com" audience="https://accounts.example.com/" />
                       </allowedAudiences>
                     </service>
                   </services>
                 </tokenManager>

 

Il est également possible d'exporter le fichier de provisioning .CR Receiver natif pour le magasin. Cela élimine le besoin de configurer la première utilisation des Receiver natifs. Distribuez ce fichier à tous les clients Receiver Mac et Windows.

Si un Receiver est installé sur le client, le type de fichier .CR est reconnu et le fait de double-cliquer sur le fichier de provisioning déclenche son importation automatique.