LDAPS
LDAPS est la version sécurisée du protocole LDAP (Lightweight Directory Access Protocol) où les communications LDAP sont chiffrées à l’aide de TLS/SSL.
- Par défaut, les communications LDAP entre les applications clientes et serveurs ne sont pas chiffrées. LDAPS vous permet de protéger le contenu des requêtes LDAP entre le VDA Linux et les serveurs LDAP.
Les composants VDA Linux suivants dépendent de LDAPS :
- Agent de broker : Enregistrement du VDA Linux auprès d’un Delivery Controller™
-
Service de stratégie : Évaluation des stratégies
-
La configuration de LDAPS implique :
- Activer LDAPS sur le serveur Active Directory (AD)/LDAP
- Exporter l’autorité de certification racine pour l’utilisation par le client
- Activer/désactiver LDAPS sur le VDA Linux
- Configurer LDAPS pour les plateformes tierces
- Configurer SSSD
- Configurer Winbind
- Configurer Centrify
- Configurer Quest
Remarque :
Vous pouvez exécuter la commande suivante pour définir un cycle de surveillance pour vos serveurs LDAP. La valeur par défaut est de 15 minutes. Définissez-la à 10 minutes au minimum.
/opt/Citrix/VDA/bin/ctxreg create -k "HKLM\Software\Citrix\VirtualDesktopAgent" -v "ListOfLDAPServersMonitorPeroid" -t "REG_DWORD" -d "0x0000000f" --force <!--NeedCopy-->
Activer LDAPS sur le serveur AD/LDAP
Vous pouvez activer LDAP sur SSL (LDAPS) en installant un certificat correctement formaté provenant d’une autorité de certification (CA) Microsoft ou d’une autorité de certification non-Microsoft.
Conseil :
LDAPS est activé automatiquement lorsque vous installez une autorité de certification racine d’entreprise sur un contrôleur de domaine.
Pour plus d’informations sur l’installation du certificat et la vérification de la connexion LDAPS, consultez Comment activer LDAP sur SSL avec une autorité de certification tierce.
- Lorsque vous disposez d’une hiérarchie d’autorités de certification à plusieurs niveaux, vous ne disposez pas automatiquement du certificat approprié pour l’authentification LDAPS sur le contrôleur de domaine.
Pour plus d’informations sur l’activation de LDAPS pour les contrôleurs de domaine à l’aide d’une hiérarchie d’autorités de certification à plusieurs niveaux, consultez l’article LDAP over SSL (LDAPS) Certificate.
Activer l’autorité de certification racine pour l’utilisation par le client
Le client doit utiliser un certificat d’une autorité de certification à laquelle le serveur LDAP fait confiance. Pour activer l’authentification LDAPS pour le client, importez le certificat de l’autorité de certification racine dans un magasin de clés approuvé.
Pour plus d’informations sur l’exportation de l’autorité de certification racine, consultez Comment exporter le certificat de l’autorité de certification racine sur le site Web du support Microsoft.
Activer ou désactiver LDAPS sur le VDA Linux
Pour activer ou désactiver LDAPS sur le VDA Linux, exécutez le script suivant (en étant connecté en tant qu’administrateur) :
La syntaxe de cette commande inclut les éléments suivants :
-
Activer LDAP sur SSL/TLS avec le certificat d’autorité de certification racine fourni :
/opt/Citrix/VDA/sbin/enable_ldaps.sh -Enable pathToRootCA <!--NeedCopy--> -
Activer LDAP sur SSL/TLS avec liaison de canal :
/opt/Citrix/VDA/sbin/enable_ldaps.sh -Enablecb pathToRootCA <!--NeedCopy-->Remarque :
Le certificat d’autorité de certification racine pour la liaison de canal doit être au format PEM. Si l’activation de LDAPS ne crée pas un environnement virtuel Python3 avec succès, créez-le manuellement en suivant les instructions de Créer un environnement virtuel Python3.
Pour résoudre les erreurs de connexion SSL que vous pourriez rencontrer lors de l’utilisation de l’outil pip, envisagez d’ajouter les hôtes de confiance suivants au fichier /etc/pip.conf :
[global] -
trusted-host =pypi.orgfiles.pythonhosted.org - Revenir à LDAP sans SSL/TLS
/opt/Citrix/VDA/sbin/enable_ldaps.sh -Disable
<!--NeedCopy-->
Le magasin de clés Java dédié à LDAPS réside dans /etc/xdl/.keystore. Les clés de registre affectées incluent :
HKLM\Software\Citrix\VirtualDesktopAgent\ListOfLDAPServers
HKLM\Software\Citrix\VirtualDesktopAgent\ListOfLDAPServersForPolicy
HKLM\Software\Citrix\VirtualDesktopAgent\UseLDAPS
HKLM\Software\Policies\Citrix\VirtualDesktopAgent\Keystore
HKLM\Software\Citrix\VirtualDesktopAgent\EnableChannelBinding
<!--NeedCopy-->
-
Configurer LDAPS pour les plateformes tierces
-
Outre les composants du VDA Linux, plusieurs composants logiciels tiers qui adhèrent au VDA peuvent également nécessiter un LDAP sécurisé, tels que SSSD, Winbind, Centrify et Quest. Les sections suivantes décrivent comment configurer un LDAP sécurisé avec LDAPS, STARTTLS ou SASL sign and seal.
-
Conseil :
-
Tous ces composants logiciels ne préfèrent pas utiliser le port SSL 636 pour assurer un LDAP sécurisé. Et la plupart du temps, LDAPS (LDAP sur SSL sur le port 636) ne peut pas coexister avec STARTTLS sur le port 389.
SSSD
Configurez le trafic LDAP sécurisé de SSSD sur le port 636 ou le port 389 selon les options. Pour plus d’informations, consultez la page de manuel Linux SSSD LDAP.
Winbind
La requête LDAP de Winbind utilise la méthode ADS. Winbind ne prend en charge que la méthode StartTLS sur le port 389. Les fichiers de configuration affectés sont /etc/samba/smb.conf et /etc/openldap/ldap.conf (pour RHEL) ou /etc/ldap/ldap.conf (pour Ubuntu). Modifiez les fichiers comme suit :
-
smb.conf
ldap ssl = start tlsldap ssl ads = yesclient ldap sasl wrapping = plain -
ldap.conf
TLS_REQCERT never
Alternativement, vous pouvez configurer un LDAP sécurisé par SASL GSSAPI sign and seal, mais cela ne peut pas coexister avec TLS/SSL. Pour utiliser le chiffrement SASL, modifiez la configuration de smb.conf :
ldap ssl = off
ldap ssl ads = no
client ldap sasl wrapping = seal
Centrify
Centrify ne prend pas en charge LDAPS sur le port 636. Cependant, il fournit un chiffrement sécurisé sur le port 389. Pour plus d’informations, consultez le site Centrify.
Quest
Quest Authentication Service ne prend pas en charge LDAPS sur le port 636, mais il fournit un chiffrement sécurisé sur le port 389 en utilisant une méthode différente.
Dépannage
Les problèmes suivants peuvent survenir lorsque vous utilisez cette fonctionnalité :
-
Disponibilité du service LDAPS
Vérifiez que la connexion LDAPS est disponible sur le serveur AD/LDAP. Le port est 636 par défaut.
-
Échec de l’enregistrement du VDA Linux lorsque LDAPS est activé
Vérifiez que le serveur LDAP et les ports sont configurés correctement. Vérifiez d’abord le certificat de l’autorité de certification racine et assurez-vous qu’il correspond au serveur AD/LDAP.
-
Modification incorrecte du registre par accident
Si vous avez mis à jour les clés liées à LDAPS par accident sans utiliser enable_ldaps.sh, cela pourrait rompre la dépendance des composants LDAPS.
-
Le trafic LDAP n’est pas chiffré via SSL/TLS depuis Wireshark ou tout autre outil de surveillance réseau
Par défaut, LDAPS est désactivé. Exécutez /opt/Citrix/VDA/sbin/enable_ldaps.sh pour le forcer.
-
Il n’y a pas de trafic LDAPS depuis Wireshark ou tout autre outil de surveillance réseau
Le trafic LDAP/LDAPS se produit lors de l’enregistrement du VDA Linux et de l’évaluation des stratégies de groupe.
-
Échec de la vérification de la disponibilité de LDAPS en exécutant ldp connect sur le serveur AD
Utilisez le nom de domaine complet (FQDN) d’AD au lieu de l’adresse IP.
-
Échec de l’importation du certificat de l’autorité de certification racine en exécutant le script /opt/Citrix/VDA/sbin/enable_ldaps.sh
Fournissez le chemin complet du certificat de l’autorité de certification et vérifiez que le certificat de l’autorité de certification racine est du type correct. Il est censé être compatible avec la plupart des types Java Keytool pris en charge. S’il n’est pas répertorié dans la liste de support, vous pouvez d’abord convertir le type. Nous recommandons le format PEM encodé en base64 si vous rencontrez un problème de format de certificat.
-
Échec de l’affichage du certificat de l’autorité de certification racine avec Keytool -list
Lorsque vous activez LDAPS en exécutant
/opt/Citrix/VDA/sbin/enable_ldaps.sh, le certificat est importé dans /etc/xdl/.keystore, et le mot de passe est défini pour protéger le magasin de clés. Si vous oubliez le mot de passe, vous pouvez réexécuter le script pour créer un magasin de clés.