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 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
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 sur 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 utilisant une hiérarchie d’autorités de certification à plusieurs niveaux, consultez l’article Certificat LDAP sur SSL (LDAPS).
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 un certificat d’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 enable_ldaps.sh (en étant connecté en tant qu’administrateur). Pour exécuter le script enable_ldaps.sh en mode non interactif, exportez les variables suivantes vers votre environnement :
#CTX_LDAPS_KEYSTORE_PASSWORD=
#CTX_LDAPS_LDAP_SERVERS=
<!--NeedCopy-->
-
Pour activer LDAP sur SSL/TLS avec le certificat d’autorité de certification racine fourni (liaison de canal LDAP prise en charge) :
/opt/Citrix/VDA/sbin/enable_ldaps.sh -Enable pathToRootCA <!--NeedCopy--> -
Pour 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 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 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 garantir 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 /etc/samba/smb.conf et /etc/openldap/ldap.conf (pour Amazon Linux 2, RHEL, Rocky Linux, CentOS et SUSE) ou /etc/ldap/ldap.conf (pour Debian et Ubuntu). Modifiez les fichiers comme suit :
-
smb.conf
ldap ssl = start tlsldap ssl ads = yesclient ldap sasl wrapping = plain -
ldap.conf
TLS_REQCERT never
Vous pouvez également configurer un LDAP sécurisé 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 :
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 à l’aide d’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.
-
L’enregistrement du VDA Linux a échoué lorsque LDAPS est activé
Vérifiez que le serveur et les ports LDAP 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 à partir de Wireshark ou de 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 à partir de Wireshark ou de 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 ne figure pas 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.