Installer Virtual Delivery Agent Linux pour Ubuntu

Vous pouvez choisir de suivre les étapes dans cet article pour l’installation manuelle ou easy install pour l’installation et la configuration automatiques. Easy Install permet des gains de temps et de main d’œuvre et il est plus fiable que l’installation manuelle.

Remarque :

utilisez Esay Install uniquement pour les nouvelles installations. N’utilisez pas Easy Install pour mettre à jour une installation existante.

Étape 1 : préparer Ubuntu pour l’installation du VDA

Étape 1a : vérifier la configuration réseau

Citrix recommande que le réseau soit connecté et correctement configuré avant de continuer.

Étape 1b : définir le nom d’hôte

Pour vous assurer que le nom d’hôte de la machine est indiqué correctement, modifiez le fichier /etc/hostname afin que celui-ci contienne uniquement le nom d’hôte de la machine.

hostname

Étape 1c : attribuer une adresse de bouclage au nom d’hôte

Pour vous assurer que le nom de domaine DNS et le nom de domaine complet (FQDN) de la machine sont indiqués correctement, modifiez la ligne suivante du fichier /etc/hosts afin que celle-ci inclue le nom de domaine complet et le nom d’hôte dans les deux premières entrées :

127.0.0.1 hostname-fqdn hostname localhost

Par exemple :

127.0.0.1 vda01.example.com vda01 localhost

Supprimez toute autre référence à hostname-fqdn ou hostname des autres entrées du fichier.

Remarque :

Le VDA Linux ne prend actuellement pas en charge la troncation de noms NetBIOS. Par conséquent, le nom d’hôte ne doit pas comporter plus de 15 caractères.

Conseil :

Utilisez uniquement les caractères a–z, A–Z, 0–9 et tiret (-). Évitez les caractères de soulignement (_), les espaces et autres symboles. Ne démarrez pas un nom d’hôte par un chiffre et ne le terminez pas par un tiret. Cette règle s’applique également aux noms d’hôte Delivery Controller.

Étape 1d : vérifier le nom d’hôte

Vérifiez que le nom d’hôte est correctement configuré :

hostname

Cette commande renvoie uniquement le nom d’hôte de la machine et non son nom de domaine complet.

Vérifiez que le nom de domaine complet est correctement configuré :

hostname -f

Cette commande renvoie le nom de domaine complet de la machine.

Étape 1e : désactiver DNS multidiffusion

Les paramètres par défaut activent DNS multidiffusion (mDNS), ce qui peut entraîner des résultats incohérents de résolution de nom.

Pour désactiver mDNS, modifiez /etc/nsswitch.conf ainsi que la ligne suivante qui contient :

hosts: files mdns_minimal [NOTFOUND=return] dns

à :

hosts: files dns

Étape 1f : vérifier la résolution de nom et l’accessibilité du service

Vérifiez que vous pouvez résoudre le nom de domaine complet et effectuer un sondage ping sur le contrôleur de domaine et le Delivery Controller XenDesktop :

nslookup domain-controller-fqdn
ping domain-controller-fqdn
nslookup delivery-controller-fqdn
ping delivery-controller-fqdn

Si vous ne pouvez pas résoudre le nom de domaine complet ou effectuer un sondage ping sur l’une de ces machines, reprenez les étapes avant de continuer.

Étape 1g : configurer la synchronisation de l’horloge (chrony)

Il est très important de maintenir la synchronisation de l’horloge entre les VDA, les Delivery Controller et les contrôleurs de domaine. L’hébergement du VDA Linux en tant que machine virtuelle peut entraîner des problèmes de décalage d’horloge. Pour cette raison, il est recommandé de synchroniser l’heure avec un service de temps à distance.

Installez chrony :

apt-get install chrony

En tant qu’utilisateur racine, modifiez /etc/chrony/chrony.conf et ajoutez une entrée de serveur pour chaque serveur de temps distant :

server peer1-fqdn-or-ip-address iburst
server peer2-fqdn-or-ip-address iburst

Dans un déploiement type, synchronisez l’heure depuis les contrôleurs de domaine locaux et non pas directement depuis des serveurs de pool NTP publics. Ajoutez une entrée de serveur pour chaque contrôleur de domaine Active Directory du domaine.

Supprimez toute autre entrée server ou pool répertoriée, y compris les entrées d’adresse IP de bouclage, localhost et *.pool.ntp.org de serveur public.

Enregistrez les modifications et redémarrez le démon Chrony :

sudo systemctl restart chrony

Étape 1h : installer OpenJDK

Le VDA Linux dépend de OpenJDK. L’environnement d’exécution est généralement installé dans le cadre de l’installation du système d’exploitation. Vérifiez qu’il a été installé avec :

sudo apt-get install -y default-jdk

Étape 1i : installer PostgreSQL

Le VDA Linux requiert PostgreSQL version 9.x sur Ubuntu 16.04 :

sudo apt-get install -y postgresql
sudo apt-get install -y libpostgresql-jdbc-java

Étape 1j : installer Motif

sudo apt-get install -y libxm4

Étape 1k : installer les autres packages

sudo apt-get install -y libsasl2-2

sudo apt-get install -y libsasl2-modules-gssapi-mit

sudo apt-get install -y libldap-2.4-2

sudo apt-get install -y krb5-user

sudo apt-get install -y cups

Étape 2 : préparer l’hyperviseur

Certaines modifications sont requises pour l’exécution du VDA Linux en tant que machine virtuelle sur un hyperviseur pris en charge. Apportez les modifications suivantes en fonction de la plateforme d’hyperviseur utilisée. Aucune modification n’est requise si vous utilisez la machine Linux sur un matériel bare metal.

Corriger la synchronisation de l’heure sur Citrix XenServer

Si la fonctionnalité de synchronisation de l’heure de XenServer est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car XenServer et NTP tenteront de gérer l’horloge du système. Pour éviter que l’horloge ne soit plus synchronisée avec d’autres serveurs, assurez-vous l’horloge du système de chaque invité Linux est synchronisée avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte. Aucune modification n’est requise en mode HVM.

Sur certaines distributions Linux, si vous utilisez un noyau Linux paravirtualisé avec XenServer Tools installé, vous pouvez vérifier si la fonctionnalité de synchronisation de l’heure de XenServer est présente et activée à partir de la VM Linux :

su -
cat /proc/sys/xen/independent_wallclock

Cette commande renvoie 0 ou 1 :

  • 0 - La fonctionnalité de synchronisation de l’heure est activée, et doit être désactivée.
  • 1 - La fonctionnalité de synchronisation de l’heure est désactivée, et aucune action n’est requise.

Si le fichier /proc/sys/xen/indepent_wallclock n’existe pas, les étapes suivantes ne sont pas nécessaires.

Si cette option est activée, désactivez la fonctionnalité de synchronisation de l’heure en indiquant 1 dans le fichier :

sudo echo 1 > /proc/sys/xen/independent_wallclock

Pour rendre cette modification permanente et persistante après le redémarrage, modifiez le fichier /etc/sysctl.conf et ajoutez la ligne :

xen.independent_wallclock = 1

Pour vérifier ces modifications, redémarrez le système :

su -
cat /proc/sys/xen/independent_wallclock

Cette commande renvoie la valeur 1.

Corriger la synchronisation de l’heure sur Microsoft Hyper-V

Les VM Linux sur lesquelles Hyper-V Integration Services est installé peuvent tirer parti de la fonctionnalité de synchronisation de l’heure Hyper-V pour utiliser l’heure du système d’exploitation hôte. Pour vous assurer que l’horloge du système est toujours précise, cette fonctionnalité doit être activée avec les services NTP.

Depuis le système d’exploitation de gestion :

  1. Ouvrez la console du gestionnaire Hyper-V.
  2. Pour les paramètres d’une machine virtuelle Linux, sélectionnez Integration Services.
  3. Assurez-vous que Time synchronization est sélectionné.

Remarque :

cette approche diffère de XenServer et VMware, pour lesquels la synchronisation de l’heure est désactivée afin d’éviter tout conflit avec NTP. La synchronisation de l’heure Hyper-V peut co-exister avec la synchronisation de l’heure NTP.

Corriger la synchronisation de l’heure sur ESX et ESXi

Si la fonctionnalité de synchronisation de l’heure de VMware est activée, vous rencontrerez des problèmes dans chaque VM Linux paravirtualisée car l’hyperviseur et NTP tenteront de synchroniser l’horloge du système. Pour éviter que l’horloge ne soit plus synchronisée avec d’autres serveurs, assurez-vous l’horloge du système de chaque invité Linux est synchronisée avec NTP. Cela nécessite la désactivation de la synchronisation de l’heure de l’hôte.

Si vous exécutez un noyau Linux paravirtualisé sur lequel VMware Tools est installé :

  1. Ouvrez vSphere Client.
  2. Modifiez les paramètres pour la VM Linux.
  3. Dans la boîte de dialogue Virtual Machine Properties (Propriétés de la machine virtuelle), ouvrez l’onglet Options.
  4. Sélectionnez VMware Tools.
  5. Dans la zone Advanced (Avancé), désélectionnez Synchronize guest time with host (Synchroniser l’heure de l’invité avec l’hôte).

Étape 3 : ajouter la machine virtuelle (VM) Linux au domaine Windows

Le Linux VDA prend en charge plusieurs méthodes pour ajouter des machines Linux au domaine Active Directory (AD) :

  • Samba Winbind
  • Service d’authentification Quest
  • Centrify DirectControl
  • SSSD

Suivez les instructions en fonction de la méthode choisie.

Remarque :

Les lancements de session peuvent échouer lorsque le même nom d’utilisateur est utilisé pour le compte local dans le VDA Linux et le compte dans AD.

Samba Winbind

Installer ou mettre à jour les packages requis

sudo apt-get install winbind samba libnss-winbind libpam-winbind krb5-config krb5-locales krb5-user

Activer le démon Winbind pour qu’il soit lancé au démarrage de la machine

Le démon Winbind doit être configuré pour être lancé au démarrage de la machine :

sudo systemctl enable winbind

Configurer Kerberos

Ouvrez /etc/krb5.conf en tant qu’utilisateur racine et configurez les paramètres suivants :

[libdefaults]

default_realm = REALM

dns_lookup_kdc = false



[realms]

REALM = {

admin_server = domain-controller-fqdn

kdc = domain-controller-fqdn

}



[domain_realm]

domain-dns-name = REALM

.domain-dns-name = REALM

La propriété domain-dns-name dans ce contexte est le nom de domaine DNS, tel que example.com. La propriété REALM est le nom du domaine Kerberos en majuscules, tel que EXAMPLE.COM.

Configurer l’authentification Winbind

Vous devez configurer Winbind manuellement car Ubuntu ne possède pas d’outil tel que authconfig dans RHEL et yast2 dans SUSE.

Ouvrez /etc/samba/smb.conf et configurez les paramètres suivants :

[global]

workgroup = WORKGROUP

security = ADS

realm = REALM

encrypt passwords = yes

idmap config *:range = 16777216-33554431

winbind trusted domains only = no

kerberos method = secrets and keytab

winbind refresh tickets = yes

template shell = /bin/bash

WORKGROUP est le premier champ dans REALM, et REALM est le nom de domaine Kerberos en majuscules.

Configurer nsswitch

Ouvrez /etc/nsswitch.conf et ajoutez winbind aux lignes suivantes :

passwd: compat winbind

group: compat winbind

Rejoindre un domaine Windows

Votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte utilisateur Active Directory avec les autorisations nécessaires pour ajouter des ordinateurs au domaine :

sudo net ads join REALM -U user

Où REALM est le nom de domaine Kerberos en majuscules, et user est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter les ordinateurs au domaine.

Redémarrer winbind

sudo systemctl restart winbind

Configurer PAM pour Winbind

Exécutez la commande suivante et assurez-vous que les options Winbind NT/Active Directory authentication et Create home directory on login sont sélectionnées :

sudo pam-auth-update

Conseil :

Le démon winbind ne reste en cours d’exécution que si la machine est associée à un domaine.

Vérifier l’appartenance à un domaine

Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory.

Exécutez la commande net ads de Samba pour vérifier que la machine est associée à un domaine :

sudo net ads testjoin

Exécutez la commande suivante pour vérifier les informations d’objet de domaine et d’ordinateur supplémentaires :

sudo net ads info

Vérifier la configuration de Kerberos

Pour vérifier que Kerberos est correctement configuré pour être utilisé avec Linux VDA, vérifiez que le fichier keytab système a été créé et contient des clés valides.

sudo klist -ke

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms principaux et de suites de chiffrement. Exécutez la commande kinit Kerberos pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit -k MACHINE\$@REALM

Les noms de machine et de domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être placé dans une séquence d’échappement avec une barre oblique inverse (\) pour empêcher le remplacement shell. Dans certains environnements, le nom de domaine DNS est différent du nom de domaine Kerberos. Assurez-vous que le nom de domaine est utilisé. Si cette commande réussit, aucun résultat n’est affiché.

Vérifiez que le ticket TGT pour le compte de machine a été mis en cache à l’aide de :

sudo klist

Examinez les détails du compte de machine à l’aide de :

sudo net ads status

Vérifier l’authentification utilisateur

Utilisez l’outil wbinfo pour vérifier que les utilisateurs de domaine peuvent s’authentifier auprès du domaine :

wbinfo --krb5auth=domain\\username%password

Le domaine spécifié ici est le nom de domaine Active Directory, et non le nom de domaine Kerberos. Pour le shell bash, la barre oblique inverse (\) doit être placée dans une séquence d’échappement avec une autre barre oblique inverse. Cette commande renvoie un message indiquant la réussite ou l’échec.

Pour vérifier que le module PAM Winbind est correctement configuré, ouvrez une session à l’aide d’un compte d’utilisateur de domaine sur le VDA Linux. Le compte d’utilisateur de domaine n’a pas été utilisé auparavant.

ssh localhost -l domain\\username
id -u

Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le uid renvoyé par la commande id -u :

ls /tmp/krb5cc_uid

Vérifiez que les tickets dans le cache d’identification de Kerberos de l’utilisateur sont valides et n’ont pas expiré :

klist

Quittez la session :

exit

Le même test peut être réalisé en ouvrant une session directement sur la console KDE ou Gnome.

Conseil :

Si l’authentification utilisateur réussit mais que vous ne pouvez pas afficher votre bureau lors de la connexion avec un compte de domaine, redémarrez la machine et réessayez.

Service d’authentification Quest

Configurer Quest sur le contrôleur de domaine

Cette procédure suppose que vous avez installé et configuré le logiciel Quest sur les contrôleurs de domaine Active Directory et disposez des droits Administrateur pour créer des objets ordinateur dans Active Directory.

Autoriser les utilisateurs de domaine à ouvrir une session sur des machines VDA Linux

Pour autoriser les utilisateurs de domaine à établir des sessions HDX sur une machine VDA Linux :

  1. Dans la console de gestion Utilisateurs et ordinateurs Active Directory, ouvrez les propriétés de l’utilisateur Active Directory pour ce compte d’utilisateur.
  2. Sélectionnez l’onglet Unix Account.
  3. Sélectionnez Unix-enabled.
  4. Définissez Primary GID Number sur l’ID d’un groupe d’utilisateurs de domaine.

Remarque :

Ces instructions sont les mêmes que pour la configuration d’utilisateurs de domaine pour l’ouverture de session à l’aide de la console, RDP, SSH ou tout autre protocole de communication à distance.

Configurer Quest sur un VDA Linux

Solution à l’application forcée de la stratégie SELinux

L’environnement RHEL par défaut applique entièrement SELinux. Cette mise en œuvre interfère avec les mécanismes IPC de socket de domaine Unix utilisés par Quest et empêche les utilisateurs de domaine d’ouvrir une session.

Le moyen pratique de remédier à ce problème consiste à désactiver SELinux. En tant qu’utilisateur racine, modifiez /etc/selinux/config en modifiant le paramètre SELinux :

SELINUX=disabled

Cette modification nécessite le redémarrage de la machine :

reboot

Important :

Utilisez ce paramètre avec précaution. La réactivation de l’application forcée de la stratégie SELinux après sa désactivation peut entraîner un verrouillage complet, même pour l’utilisateur racine et d’autres utilisateurs locaux.

Configurer le démon VAS

Le renouvellement automatique des tickets Kerberos doit être activé et déconnecté. L’authentification (ouverture de session en mode déconnecté) doit être désactivée :

sudo /opt/quest/bin/vastool configure vas vasd auto-ticket-renew-interval 32400
sudo /opt/quest/bin/vastool configure vas vas_auth allow-disconnected-auth false

Cette commande définit l’intervalle de renouvellement sur 9 heures (32 400 secondes), ce qui représente une heure de moins que la valeur par défaut de 10 heures pour la durée de vie d’un ticket. Définissez ce paramètre sur une valeur inférieure sur les systèmes avec une durée de vie de ticket plus courte.

Configuration de PAM et de NSS

Pour permettre l’ouverture de session d’utilisateur de domaine via HDX et d’autres services tels que su, ssh et RDP, exécutez les commandes suivantes pour configurer manuellement PAM et le NSS :

sudo /opt/quest/bin/vastool configure pam
sudo /opt/quest/bin/vastool configure nss

Rejoindre un domaine Windows

Associez la machine Linux au domaine Active Directory à l’aide de la commande Quest vastool :

sudo /opt/quest/bin/vastool -u user join domain-name

L’utilisateur est un utilisateur de domaine disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le nom de domaine est le nom DNS du domaine ; par exemple, exemple.com.

Vérifier l’appartenance à un domaine

Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux associée à Quest se trouve sur le domaine :

sudo /opt/quest/bin/vastool info domain

Si la machine est associée à un domaine, cette commande renvoie le nom de domaine. Si la machine n’est pas associée à un domaine, l’erreur suivante apparaît :

ERROR: No domain could be found.
ERROR: VAS_ERR_CONFIG: at ctx.c:414 in _ctx_init_default_realm
default_realm not configured in vas.conf. Computer may not be joined to domain

Vérifier l’authentification utilisateur

Pour vérifier que Quest peut authentifier les utilisateurs de domaine via PAM, utilisez un compte d’utilisateur de domaine pour vous connecter au VDA Linux. Le compte d’utilisateur de domaine n’a pas été utilisé auparavant.

ssh localhost -l domain\\username
id -u

Vérifiez qu’un fichier cache d’identification Kerberos correspondant a été créé pour le uid renvoyé par la commande id -u :

ls /tmp/krb5cc_uid

Vérifiez que les tickets dans le cache d’identification de Kerberos sont valides et n’ont pas expiré :

/opt/quest/bin/vastool klist

Quittez la session :

exit

Centrify DirectControl

Rejoindre un domaine Windows

Une fois Centrify DirectControl Agent installé, associez la machine Linux au domaine Active Directory à l’aide de la commande adjoin Centrify :

su –
adjoin -w -V -u user domain-name

Le paramètre user est un utilisateur de domaine Active Directory disposant des autorisations nécessaires pour associer des ordinateurs au domaine Active Directory. Le paramètre domain-name est le nom du domaine auquel associer la machine Linux.

Vérifier l’appartenance à un domaine

Le Delivery Controller requiert que toutes les machines VDA, Windows ou Linux, aient un objet ordinateur dans Active Directory. Pour vérifier qu’une machine Linux associée à Centrify se trouve sur le domaine :

su –
adinfo

Vérifiez que la valeur Joined to domain est valide et que CentrifyDC mode renvoie connected. Si le mode reste bloqué à l’état de démarrage, le client Centrify rencontre des problèmes de connexion au serveur ou d’authentification.

Des informations plus complètes sur le système et les diagnostics sont disponibles à l’aide de :

adinfo --sysinfo all
adinfo --diag

Pour tester la connectivité avec les différents services Active Directory et Kerberos :

adinfo --test

SSSD

Configurer Kerberos

Exécutez la commande suivante pour installer Kerberos :

sudo apt-get install krb5-user

Pour configurer Kerberos, ouvrez /etc/krb5.conf en tant qu’utilisateur racine et configurez les paramètres suivants :

[libdefaults]
 default_realm = REALM
 dns_lookup_kdc = false
[realms]
 REALM = {
  admin_server = domain-controller-fqdn
  kdc = domain-controller-fqdn
 }
[domain_realm]
 domain-dns-name = REALM
 .domain-dns-name = REALM

La propriété domain-dns-name dans ce contexte est le nom de domaine DNS, tel que example.com. La propriété REALM est le nom du domaine Kerberos en majuscules, tel que EXAMPLE.COM.

Joindre le domaine

SSSD doit être configuré pour pouvoir utiliser Active Directory en tant que fournisseur d’identité et Kerberos pour l’authentification. Toutefois, SSSD ne fournit pas de fonctions de client Active Directory pour rejoindre le domaine et gérer le fichier keytab du système. Il existe plusieurs méthodes de jonction du domaine :

  • adcli
  • samba
  • realmd

Remarque :

Cette section fournit des informations uniquement pour adcli et samba.

Utilisez adcli pour rejoindre le domaine :

Installer adcli :

Installez les packages requis :

sudo apt-get install adcli

Rejoindre le domaine avec adcli :

Supprimez l’ancien fichier keytab du système et rejoignez le domaine à l’aide de :

su -
rm -rf /etc/krb5.keytab
adcli join domain-dns-name -U user -H hostname-fqdn

user est un utilisateur du domaine autorisé à ajouter des machines au domaine. hostname-fqdn est le nom d’hôte au format FQDN de la machine.

L’option -H est requise pour permettre à adcli de générer SPN au format host/hostname-fqdn@REALM, ce qui est requis par Linux VDA.

Vérifier le fichier keytab système :

Les fonctionnalités de l’outil adcli sont limitées et ne permettent pas de tester si une machine est jointe au domaine. Le meilleur moyen consiste à vérifier que le fichier keytab système a été créé :

sudo klist -ket

Vérifiez que l’horodatage de chaque clé correspond à l’heure à laquelle la machine a été jointe au domaine.

Utiliser samba pour rejoindre le domaine :

Installer le package :

sudo apt-get install samba

Configurer samba :

Ouvrez /etc/samba/smb.conf et configurez les paramètres suivants :

[global]

   workgroup = WORKGROUP

   security = ADS

   realm = REALM

   client signing = yes

   client use spnego = yes

   kerberos method = secrets and keytab

WORKGROUP est le premier champ dans REALM, et REALM est le nom de domaine Kerberos en majuscules.

Rejoindre le domaine avec samba :

Votre contrôleur de domaine doit être accessible et vous devez disposer d’un compte Windows avec les autorisations nécessaires pour ajouter des ordinateurs au domaine.

sudo net ads join REALM -U user

REALM est le nom de domaine Kerberos en majuscules, et user est un utilisateur de domaine disposant des autorisations nécessaires pour ajouter les ordinateurs au domaine.

Configurer SSSD

Installer ou mettre à jour les packages requis :

Installez les packages de configuration et SSSD requis s’ils ne sont pas déjà installés :

sudo apt-get install sssd

Si les packages sont déjà installés, une mise à jour est recommandée :

sudo apt-get update sssd

Remarque :

Par défaut, le processus d’installation dans Ubuntu configure automatiquement nsswitch.conf et le module de connexion PAM.

Configurer SSSD

Des modifications doivent être apportées à la configuration SSSD avant de démarrer le démon SSSD. Pour certaines versions de SSSD, le fichier de configuration /etc/sssd/sssd.conf n’est pas installé par défaut et doit être créé manuellement. En tant qu’utilisateur racine, créez ou ouvrez /etc/sssd/sssd.conf et configurez les paramètres suivants :

[sssd]
services = nss, pam
config_file_version = 2
domains = domain-dns-name

[domain/domain-dns-name]
id_provider = ad
access_provider = ad
auth_provider = krb5
krb5_realm = REALM
# Set krb5_renewable_lifetime higher if TGT renew lifetime is longer than 14 days
krb5_renewable_lifetime = 14d
# Set krb5_renew_interval to lower value if TGT ticket lifetime is shorter than 2 hours
krb5_renew_interval = 1h
krb5_ccachedir = /tmp
krb5_ccname_template = FILE:%d/krb5cc_%U
# This ldap_id_mapping setting is also the default value
ldap_id_mapping = true
override_homedir = /home/%d/%u
default_shell = /bin/bash
ad_gpo_map_remote_interactive = +ctxhdx

Remarque :

ldap_id_mapping est défini sur true de façon à ce que SSSD se charge de mapper les SID Windows avec les UID Unix. Sinon, Active Directory doit être en mesure de fournir des extensions POSIX. Le service PAM ctxhdx est ajouté au paramètre ad_gpo_map_remote_interactive.

La propriété domain-dns-name dans ce contexte est le nom de domaine DNS, tel que example.com. Le REALM est le nom du domaine Kerberos en majuscules, tel que EXAMPLE.COM. Il n’est pas nécessaire de configurer le nom de domaine NetBIOS.

Conseil :

Pour de plus amples informations sur ces paramètres de configuration, consultez les pages man pour sssd.conf et sssd-ad.

Le démon SSSD nécessite que le fichier de configuration dispose uniquement de l’autorisation d’accès en lecture de propriétaire :

sudo chmod 0600 /etc/sssd/sssd.conf

Démarrer le démon SSSD

Exécutez les commandes suivantes pour démarrer le démon SSSD maintenant et pour permettre le lancement du démon au démarrage de la machine :

sudo systemctl start sssd
sudo systemctl enable sssd

Configuration de PAM

Exécutez la commande suivante et assurez-vous que les options SSS authentication et Create home directory on login sont sélectionnées :

sudo pam-auth-update

Vérifier l’appartenance à un domaine

Le Delivery Controller requiert que toutes les machines VDA (VDA Windows et Linux) aient un objet ordinateur dans Active Directory.

Utiliser addi pour vérifier l’appartenance à un domaine :

Affichez les informations de domaine en exécutant la commande suivante :

sudo adcli info domain-dns-name

Utiliser samba pour vérifier l’appartenance à un domaine :

Exécutez la commande net ads de Samba pour vérifier que la machine est associée à un domaine :

sudo net ads testjoin

Exécutez la commande suivante pour vérifier les informations d’objet de domaine et d’ordinateur supplémentaires :

sudo net ads info

Vérifier la configuration de Kerberos

Pour vérifier que Kerberos est correctement configuré pour être utilisé avec Linux VDA, vérifiez que le fichier keytab système a été créé et contient des clés valides.

sudo klist -ke

Cette commande affiche la liste des clés disponibles pour les différentes combinaisons de noms principaux et de suites de chiffrement. Exécutez la commande kinit Kerberos pour authentifier la machine auprès du contrôleur de domaine à l’aide de ces clés :

sudo kinit -k MACHINE\$@REALM

Les noms de machine et de domaine doivent être spécifiés en majuscules. Le signe dollar ($) doit être placé dans une séquence d’échappement avec une barre oblique inverse (\) pour empêcher le remplacement shell. Dans certains environnements, le nom de domaine DNS est différent du nom de domaine Kerberos. Assurez-vous que le nom de domaine est utilisé. Si cette commande réussit, aucun résultat n’est affiché.

Vérifiez que le ticket TGT pour le compte de machine a été mis en cache à l’aide de :

sudo klist

Vérifier l’authentification utilisateur

SSSD ne fournit pas d’outil de ligne de commande pour tester l’authentification directement avec le démon. Cela peut uniquement être effectué via PAM.

Pour vérifier que le module PAM SSSD est correctement configuré, ouvrez une session à l’aide d’un compte d’utilisateur de domaine sur le VDA Linux. Le compte d’utilisateur de domaine n’a pas été utilisé auparavant.

ssh localhost -l domain\\username
id -u
klist
exit

Vérifiez que les tickets Kerberos renvoyés par la commande klist sont corrects pour cet utilisateur et qu’ils n’ont pas expiré.

En tant qu’utilisateur racine, vérifiez qu’un fichier cache de ticket correspondant a été créé pour l’UID renvoyé par la commande id -u précédente :

ls /tmp/krb5cc_uid

Le même test peut être réalisé en ouvrant une session directement sur KDE ou Gnome Display Manager.

Étape 4 : installer le VDA Linux

Étape 4a : télécharger le package VDA Linux

Accédez au site Web de Citrix et téléchargez le package VDA Linux approprié à votre distribution Linux.

Étape 4b : installer le VDA Linux

Installez le logiciel Linux VDA à l’aide du gestionnaire de package Debian :

sudo dpkg -i xendesktopvda_7.18.0.430-1.ubuntu16.04_amd64.deb

Liste des dépendances Debian pour Ubuntu :

postgresql >= 9.5

libpostgresql-jdbc-java >= 9.2

default-jdk >= 2:1.8

imagemagick >= 8:6.8.9.9

ufw >= 0.35

ubuntu-desktop >= 1.361

libxrandr2 >= 2:1.5.0

libxtst6 >= 2:1.2.2

libxm4 >= 2.3.4

util-linux >= 2.27.1

bash >= 4.3

findutils >= 4.6.0

sed >= 4.2.2

cups >= 2.1

libldap-2.4-2 >= 2.4.42

libsasl2-modules-gssapi-mit >= 2.1.~

python-requests >= 2.9.1

libgoogle-perftools4 >= 2.4~

xserver-xorg-core >= 2:1.18

xserver-xorg-core << 2:1.19

x11vnc>=0.9.13

python-websockify >= 0.6.1

Remarque :

pour une matrice des distributions Linux et des versions Xorg que cette version du VDA Linux prend en charge, consultez la section Configuration système requise.

Étape 4c : configurer le VDA Linux

Après l’installation du package, vous devez configurer le VDA Linux en exécutant le script ctxsetup.sh. Avant d’apporter des modifications, le script vérifie l’environnement et s’assure que toutes les dépendances sont installées. Si nécessaire, vous pouvez exécuter le script à tout moment pour modifier les paramètres.

Vous pouvez exécuter le script manuellement avec invite, ou automatiquement avec réponses pré-configurées. Consultez l’aide sur le script avant de continuer :

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh –help

Configuration avec invites

Exécutez une configuration manuelle avec questions :

sudo /opt/Citrix/VDA/sbin/ctxsetup.sh

Configuration automatique

Pour une installation automatique, les options requises par le script d’installation peuvent être fournies avec des variables d’environnement. Si toutes les variables requises sont présentes, le script ne demande aucune information à l’utilisateur, ce qui permet de procéder à l’installation à l’aide d’un script.

Les variables d’environnement prises en charge sont les suivantes :

  • CTX_XDL_SUPPORT_DDC_AS_CNAME = Y | N : Linux VDA prend en charge la spécification d’un nom de Delivery Controller à l’aide d’un enregistrement DNS CNAME. La valeur est définie par défaut sur N.
  • CTX_XDL_DDC_LIST = list-ddc-fqdns : Linux VDA requiert une liste séparée par des espaces de noms de domaines complets. Cette dernière sera utilisée pour l’enregistrement auprès d’un Delivery Controller. Au moins un alias de nom de domaine complet (FQDN) ou CNAME doit être spécifié.
  • CTX_XDL_VDA_PORT = port-number : Linux VDA communique avec les Delivery Controller à l’aide d’un port (80 par défaut) TCP/IP.
  • CTX_XDL_REGISTER_SERVICE = Y | N : les services Linux Virtual Desktop sont lancés après le démarrage de la machine. Valeur définie sur Y par défaut.
  • CTX_XDL_ADD_FIREWALL_RULES = Y | N : les services Linux Virtual Desktop requièrent que les connexions réseau entrantes soient autorisées via le pare-feu du système. Vous pouvez ouvrir automatiquement les ports requis (ports 80 et 1494 par défaut) dans le pare-feu du système pour Linux Virtual Desktop. Valeur définie sur Y par défaut.
  • CTX_XDL_AD_INTEGRATION = 1 | 2 | 3 | 4 : Linux VDA requiert que les paramètres de configuration Kerberos s’authentifient auprès des Delivery Controller. La configuration de Kerberos est déterminée depuis l’outil d’intégration d’Active Directory installé et configuré sur le système. Spécifiez la méthode d’intégration d’Active Directory prise en charge à utiliser :
    • 1 – Samba Winbind
    • 2 – Service d’authentification Quest
    • 3 - Centrify DirectControl
    • 4 – SSSD
  • CTX_XDL_HDX_3D_PRO = Y | N : Linux Virtual Desktop prend en charge HDX 3D Pro, un ensemble de technologies d’accélération des graphiques conçues pour optimiser la virtualisation des applications riches en graphiques HDX 3D Pro nécessite l’installation d’une carte graphique NVIDIA GRID compatible. Si HDX 3D Pro est sélectionné, le Virtual Delivery Agent est configuré pour le mode Bureaux VDI (session unique) – (c’est-à-dire, CTX_XDL_VDI_MODE=Y).
  • CTX_XDL_VDI_MODE = Y | N : indique si la machine est configurée comme modèle de mise à disposition de bureaux dédiés (VDI) ou comme modèle de mise à disposition de bureaux partagés hébergés. Pour les environnements HDX 3D Pro, définissez cette variable sur Y. Elle est définie par défaut sur N.
  • CTX_XDL_SITE_NAME = dns-name : Linux VDA découvre les serveurs LDAP à l’aide de DNS. Pour limiter les résultats de recherche DNS à un site local, spécifiez un nom de site DNS. Cette variable est définie sur <none> par défaut.
  • CTX_XDL_LDAP_LIST = list-ldap-servers : Linux VDA envoie une requête vers le DNS pour découvrir les serveurs LDAP. Si DNS ne peut pas fournir d’enregistrements de service LDAP, vous pouvez entrer une liste séparée par des espaces de noms de domaines complets LDAP avec port LDAP. Par exemple, ad1.mycompany.com:389. Cette variable est définie sur <none> par défaut.
  • CTX_XDL_SEARCH_BASE = search-base-set : Linux VDA envoie une requête vers le LDAP via une base de recherche définie sur la racine du domaine (Active Directory (par exemple, D, DC=mycompany,DC=com). Toutefois, pour améliorer les performances de recherche, vous pouvez spécifier une base de recherche (par exemple, OU=VDI,DC=mycompany,DC=com). Cette variable est définie sur <none> par défaut.
  • CTX_XDL_FAS_LIST = list-fas-servers : les serveurs du service d’authentification fédérée (FAS) sont configurés via la stratégie de groupe AD. Comme le VDA Linux ne prend pas en charge la stratégie de groupe AD, vous pouvez fournir une liste de serveurs FAS séparés par des points-virgules. La séquence doit être la même que celle configurée dans la stratégie de groupe AD. Si une adresse de serveur est supprimée, remplissez son espace vide avec la chaîne de texte <none> et conservez la séquence d’adresses du serveur sans effectuer de modification.
  • CTX_XDL_START_SERVICE = Y | N : indique si les services Linux VDA sont lancés lorsque la configuration de Linux VDA est terminée. Valeur définie sur Y par défaut.

Définissez la variable d’environnement et exécutez le script de configuration :

export CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N

export CTX_XDL_DDC_LIST=list-ddc-fqdns

export CTX_XDL_VDA_PORT=port-number

export CTX_XDL_REGISTER_SERVICE=Y|N

export CTX_XDL_ADD_FIREWALL_RULES=Y|N

export CTX_XDL_AD_INTEGRATION=1|2|3|4

export CTX_XDL_HDX_3D_PRO=Y|N

export CTX_XDL_VDI_MODE=Y|N

export CTX_XDL_SITE_NAME=dns-site-name | '<none>'

export CTX_XDL_LDAP_LIST=list-ldap-servers | '<none>'

export CTX_XDL_SEARCH_BASE=search-base-set | '<none>'

export CTX_XDL_FAS_LIST = list-fas-servers | '<none>'

export CTX_XDL_START_SERVICE=Y|N

sudo -E /opt/Citrix/VDA/sbin/ctxsetup.sh

Lors de l’exécution de la commande sudo, entrez l’option -E pour transmettre les variables d’environnement existantes au nouveau shell créé. Citrix vous recommande de créer un fichier de script shell à partir des commandes précédentes avec #!/bin/bash en tant que première ligne.

Éventuellement, vous pouvez spécifier les paramètres en utilisant une seule commande :

sudo CTX_XDL_SUPPORT_DDC_AS_CNAME=Y|N \

CTX_XDL_DDC_LIST=list-ddc-fqdns \

CTX_XDL_VDA_PORT=port-number \

CTX_XDL_REGISTER_SERVICE=Y|N \

CTX_XDL_ADD_FIREWALL_RULES=Y|N \

CTX_XDL_AD_INTEGRATION=1|2|3|4 \

CTX_XDL_HDX_3D_PRO=Y|N \

CTX_XDL_VDI_MODE=Y|N \

CTX_XDL_SITE_NAME=dns-name \

CTX_XDL_LDAP_LIST=list-ldap-servers \

CTX_XDL_SEARCH_BASE=search-base-set \

CTX_XDL_FAS_LIST = list-fas-servers \

CTX_XDL_START_SERVICE=Y|N \

/opt/Citrix/VDA/sbin/ctxsetup.sh

Supprimer les modifications de configuration

Dans certains scénarios, il peut être nécessaire de supprimer les modifications de configuration effectuées par le script ctxsetup.sh sans désinstaller le package Linux VDA.

Consultez l’aide sur ce script avant de continuer :

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh --help

Pour supprimer les modifications de configuration :

sudo /opt/Citrix/VDA/sbin/ctxcleanup.sh

Important :

Ce script supprime toutes les données de configuration de la base de données et empêche VDA Linux de fonctionner.

Journaux de configuration

Les scripts ctxsetup.sh et ctxcleanup.sh affichent les erreurs dans la console, avec des informations supplémentaires consignées dans le fichier journal de configuration /tmp/xdl.configure.log.

Redémarrez les services de VDA Linux pour que les modifications prennent effet.

Désinstaller le logiciel VDA Linux

Pour vérifier que le VDA Linux est installé et pour afficher la version du package installé :

dpkg -l xendesktopvda

Pour afficher des informations plus détaillées :

apt-cache show xendesktopvda

Remarque :

La désinstallation du logiciel VDA Linux supprime le PostgreSQL associé et d’autres données de configuration. Toutefois, le package PostgreSQL et les autres packages dépendants qui ont été installés avant l’installation du VDA Linux ne sont pas supprimés.

Conseil :

Les informations figurant dans cette section ne couvrent pas la suppression de packages dépendants, y compris PostgreSQL.

Étape 5 : exécuter le VDA Linux

Une fois que vous avez configuré le VDA Linux à l’aide du script ctxsetup.sh, utilisez les commandes suivantes pour contrôler le VDA Linux.

Démarrer Linux VDA :

Pour démarrer les services VDA Linux :

sudo systemctl start ctxhdx
sudo systemctl start ctxvda

Arrêter Linux VDA :

Pour arrêter les services VDA Linux :

sudo systemctl stop ctxvda
sudo systemctl stop ctxhdx

Redémarrer Linux VDA :

Pour redémarrer les services VDA Linux :

sudo systemctl stop ctxvda
sudo systemctl restart ctxhdx
sudo systemctl restart ctxvda

Vérifier l’état de Linux VDA :

Pour vérifier l’état de fonctionnement des services du VDA Linux :

sudo systemctl status ctxvda
sudo systemctl status ctxhdx

Étape 6 : créer le catalogue de machines dans XenApp ou XenDesktop

Le processus de création de catalogues de machines et d’ajout de machines VDA Linux est similaire à l’approche traditionnelle avec les VDA Windows. Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, consultez les sections Créer des catalogues de machines et Gérer des catalogues de machines.

Pour la création de catalogues de machines contenant des machines VDA Linux, il existe quelques restrictions qui différencient ce processus de la création de catalogues de machines pour VDA Windows :

  • Pour le système d’exploitation, sélectionnez :
    • L’OS de serveur pour un modèle de mise à disposition de bureaux partagés hébergés
    • L’OS de bureau pour un modèle de mise à disposition de bureaux dédiés VDI
  • Assurez-vous que les machines sont définies avec une alimentation non gérée.
  • Ne combinez pas de machines VDA Linux et Windows dans le même catalogue de machines.

Remarque :

Les versions antérieures de Citrix Studio ne prenaient pas en charge la notion de « système d’exploitation Linux. » Toutefois, la sélection de l’option d’OS de serveur Windows ou d’OS de serveur implique un modèle de mise à disposition équivalent de bureaux partagés hébergés. La sélection de l’option Système d’exploitation de bureau Windows ou OS de bureau implique un modèle de mise à disposition d’un utilisateur XenDesktop unique par machine.

Conseil :

Pour supprimer une machine puis la rejoindre au domaine Active Directory, vous devez supprimer et rajouter la machine au catalogue de machines.

Étape 7 : créer le groupe de mise à disposition dans XenApp ou XenDesktop

Le processus de création d’un groupe de mise à disposition et d’ajout de catalogues de machines contenant des machines VDA Linux est presque identique aux machines VDA Windows. Pour obtenir une description plus détaillée de la méthode à utiliser pour effectuer ces tâches, consultez la section Créer des groupes de mise à disposition.

Lors de la création de groupes de mise à disposition qui contiennent des catalogues de machines VDA Linux, les restrictions suivantes s’appliquent :

  • Pour le type de mise à disposition, sélectionnez Bureaux. Les VDA Linux pour Ubuntu ne prennent pas en charge la mise à disposition d’applications.
  • Assurez-vous que les utilisateurs et les groupes AD que vous sélectionnez ont été correctement configurés pour l’ouverture de session sur les machines VDA Linux.
  • N’autorisez pas l’ouverture de session d’utilisateurs non authentifiés (anonymes).
  • Ne combinez pas le groupe de mise à disposition avec des catalogues de machines contenant des machines Windows.

Pour plus d’informations sur la création de catalogues de machines et de groupes de mise à disposition, consultez XenApp et XenDesktop 7.18.