Configurer LDAPS

Le protocole LDAP sécurisé (LDAPS) vous permet d’activer le protocole LDAP (Lightweight Directory Access Protocol) sécurisé pour vos domaines gérés Active Directory afin d’assurer la communication 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. L’utilisation de LDAP avec 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 broker : enregistrement du VDA Linux auprès du Delivery Controller™
  • Service de stratégie : évaluation de la stratégie

  • 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 une utilisation côté 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 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 l’article 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 à l’aide d’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 une utilisation côté client

Le client doit utiliser un certificat provenant 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 le magasin de clés de confiance.

Pour plus d’informations sur l’exportation de l’autorité de certification racine, consultez l’article 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 pour 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-->
  • 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
<!--NeedCopy-->

Configurer LDAPS pour les plateformes tierces

  • 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 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 et 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 de 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 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.

  • Aucun 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 d’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 bon type. Généralement, il est censé être compatible avec la plupart des types Java Keytool pris en charge. S’il ne figure pas dans la liste des supports, vous pouvez d’abord convertir le type. Citrix® recommande le format PEM encodé en base64 si vous rencontrez un problème de format de certificat.

  • Échec de l’affichage du certificat d’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.

Configurer LDAPS