Configurer LDAPS
Le protocole LDAP sécurisé (LDAPS) vous permet d’activer le protocole Lightweight Directory Access Protocol sécurisé pour vos domaines gérés Active Directory afin d’assurer les communications via SSL (Secure Socket Layer)/TLS (Transport Layer Security).
- Par défaut, les communications LDAP entre les applications client et serveur ne sont pas chiffrées. LDAP utilisant SSL/TLS (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 courtier : enregistrement du VDA Linux auprès d’un Delivery Controller™
-
Service de stratégie : évaluation des stratégies
-
La configuration de LDAPS implique :
- L’activation de LDAPS sur le serveur Active Directory (AD)/LDAP
- L’exportation de l’autorité de certification racine pour l’utilisation par le client
- L’activation/désactivation de LDAPS sur le VDA Linux
- La configuration de LDAPS pour les plateformes tierces
- La configuration de SSSD
- La configuration de Winbind
- La configuration de Centrify
- La configuration de Quest
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 :
LDAP sur SSL/TLS (LDAPS) est automatiquement activé 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 sur le site du support Microsoft.
Lorsque vous disposez d’une hiérarchie d’autorité de certification à plusieurs niveaux (par exemple, à deux ou trois 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 utilisant une hiérarchie d’autorité de certification à plusieurs niveaux, consultez l’article Certificat LDAP sur SSL (LDAPS) sur le site Microsoft TechNet.
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 de confiance.
- 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 de l’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 de l’autorité de certification racine pour la liaison de canal doit être au format PEM. Avant d’activer la liaison de canal, assurez-vous de créer un environnement virtuel Python3. Pour plus d’informations, consultez Créer un environnement virtuel Python3.
-
Revenir à LDAP sans SSL/TLS
/opt/Citrix/VDA/sbin/enable_ldaps.sh -Disable
<!--NeedCopy-->
Le magasin de clés Java dédié à LDAPS se trouve 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 une plateforme tierce
-
Outre les composants 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 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é 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 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 ldap.conf dans /etc/openldap/ldap.conf et smb.conf dans /etc/samba/smb.conf. Modifiez les fichiers comme suit :
ldap.conf:
TLS_REQCERT never
smb.conf:
ldap ssl = start tls
ldap ssl ads = yes
client ldap sasl wrapping = plain
<!--NeedCopy-->
Alternativement, LDAP sécurisé peut être configuré par SASL GSSAPI sign and seal, mais il ne peut pas coexister avec TLS/SSL. Pour utiliser le chiffrement SASL, modifiez la configuration smb.conf :
smb.conf:
ldap ssl = off
ldap ssl ads = no
client ldap sasl wrapping = seal
<!--NeedCopy-->
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 lors de l’utilisation de 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.
-
L’enregistrement du VDA Linux a échoué 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 les clés liées à LDAPS ont été mises à jour 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) de l’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.