Linux Virtual Delivery Agent

Configurer LDAPS

Le protocole LDAPS (LDAP sécurisé) vous permet d’activer le protocole LDAPS (Secure Lightweight Directory Access Protocol) pour vos domaines gérés Active Directory afin de pouvoir utiliser SSL (Secure Socket Layer) ou TLS (Transport Layer Security) pour les communications.

Par défaut, les communications LDAP entre les applications du client et du serveur ne sont pas cryptées. L’utilisation de LDAP en conjonction avec SSL/TLS (LDAPS) vous permet de protéger le contenu de la requête LDAP entre le Linux VDA et les serveurs LDAP.

Les composants Linux VDA suivants ont des dépendances avec LDAPS :

  • Agent broker : enregistrement de l’agent Linux VDA auprès du Delivery Controller
  • Service de stratégie : évaluation de la stratégie

La configuration de LDAPS implique les actions suivantes :

  • Activer LDAPS sur le serveur Active Directory (AD)/LDAP
  • Exporter l’autorité de certification racine pour les clients
  • Activer/désactiver LDAPS sur le Linux VDA
  • Configurer LDAPS pour les plates-formes tierces
  • Configurer SSSD
  • Configurer Winbind
  • Configurer Centrify
  • Configurer 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 autre que 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 de plus amples informations sur la manière d’installer le certificat et de vérifier la connexion LDAPS, consultez l’article Comment faire pour activer le protocole LDAP sur SSL avec une autorité de certification tierce sur le site de support de Microsoft.

Lorsque vous disposez d’une hiérarchie d’autorité de certification à plusieurs niveaux (à deux ou trois niveaux par exemple), vous ne disposerez pas automatiquement du certificat approprié pour l’authentification LDAPS sur le contrôleur de domaine.

Pour de plus amples informations sur la manière d’activer LDAPS pour les contrôleurs de domaine à l’aide d’une hiérarchie d’autorité de certification à plusieurs niveaux, consultez l’article LDAP over SSL (LDAPS) Certificate sur le site Microsoft TechNet.

Activer l’autorité de certification racine pour le client

Le client doit utiliser un certificat provenant d’une autorité de certification approuvée par le serveur LDAP. Pour activer l’authentification LDAPS pour le client, importez le certificat d’autorité de certification racine sur le keystore approuvé.

Pour de plus amples informations sur la manière d’exporter l’autorité de certification racine, consultez l’article Comment faire pour exporter le certificat d’autorité de Certification racine sur le site Web de support de Microsoft.

Activer ou désactiver LDAPS sur le Linux VDA

Pour activer ou désactiver LDAPS pour Linux VDA, exécutez le script suivant (vous devez être connecté en tant qu’administrateur) :

La syntaxe de cette commande comprend 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-->
  • Retour à LDAP sans SSL/TLS
/opt/Citrix/VDA/sbin/enable_ldaps.sh -Disable
<!--NeedCopy-->

Le keystore Java dédié à LDAPS se trouve dans /etc/xdl/.keystore. Clés de registre affectées :

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 une plate-forme tierce

Outre les composants Linux VDA, plusieurs composants logiciels tiers conformes au VDA peuvent également nécessiter le protocole LDAP sécurisé, comme SSSD, Winbind, Centrify et Quest. Les sections suivantes décrivent comment configurer le protocole LDAP sécurisé avec LDAPS, STARTTLS ou SASL (signer et sceller).

Conseil :

Ces composants logiciels ne préfèrent pas tous utiliser le port SSL 636 pour garantir un protocole LDAP sécurisé. De plus, la plupart du temps, LDAPS (LDAP sur SSL sur le port 636) ne peut pas coexister avec STARTTLS sur 389.

SSSD

Configurez le trafic LDAP sécurisé SSSD sur le port 636 ou 389 conformément aux options. Pour plus d’informations, consultez la page SSSD LDAP Linux man page.

Winbind

La requête LDAP Winbind utilise la méthode ADS. Winbind prend uniquement en charge 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 tls
    ldap ssl ads = yes
    client ldap sasl wrapping = plain

  • ldap.conf

    TLS_REQCERT never

LDAP sécurisé peut également être configuré par SASL GSSAPI (signer et sceller), mais il ne peut pas coexister avec TLS/SSL. Pour utiliser le cryptage SASL, modifiez la configuration du fichier 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. Toutefois, il fournit un cryptage sécurisé sur le port 389. Pour de plus amples informations, consultez le site Centrify.

Quest

Quest Authentication Service ne prend pas en charge LDAPS sur le port 636, mais il offre un cryptage sécurisé sur le port 389 à l’aide d’une autre méthode.

Résolution des problèmes

Les problèmes suivants peuvent se produire 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 par défaut est 636.

  • Échec de l’enregistrement du Linux VDA lorsque LDAPS est activé

    Vérifiez que le serveur LDAP et les ports sont configurés correctement. Vérifiez le certificat d’autorité de certification racine et assurez-vous qu’il correspond au serveur AD/LDAP.

  • Modification incorrecte du registre effectuée accidentellement

    Si les clés liées à LDAPS ont été mises à jour par accident sans utiliser enable_ldaps.sh, cela peut rompre la dépendance des composants LDAPS.

  • Le trafic LDAP n’est pas crypté via SSL/TLS à partir de Wireshark ou tout autre outil de gestion du réseau

    Par défaut, LDAPS est désactivé. Exécutez /opt/Citrix/VDA/sbin/enable_ldaps.sh pour le forcer.

  • Il n’existe aucun trafic LDAPS depuis Wireshark ou tout autre outil d’analyse du réseau

    Le trafic LDAP/LDAPS se produit lors de l’enregistrement du Linux VDA et de l’évaluation de la stratégie de groupe.

  • Impossible de vérifier la disponibilité de LDAPS en exécutant ldp Connect sur le serveur Active Directory

    Utilisez le nom de domaine complet (FQDN) Active Directory au lieu de l’adresse IP.

  • Impossible d’importer le certificat d’autorité de certification racine en exécutant le script /opt/Citrix/VDA/sbin/enable_ldaps.sh

    Fournissez le chemin d’accès complet du certificat d’autorité de certification, et vérifiez que le type de certificat d’autorité de certification racine est correct. En général, il est supposé être compatible avec la plupart des types de keystore Java pris en charge. S’il n’est pas répertorié dans la liste, vous pouvez convertir le type. Citrix recommande le format PEM codé en base64 si vous rencontrez un problème avec le format du certificat.

  • Impossible d’afficher le certificat d’autorité de certification racine avec la commande -list de Keytool

    Lorsque vous activez LDAPS en exécutant /opt/Citrix/VDA/sbin/enable_ldaps.sh, le certificat est importé sur /etc/xdl/.keystore, et le mot de passe est défini pour protéger le keystore. Si vous avez oublié le mot de passe, vous pouvez réexécuter le script pour créer un keystore.

Configurer LDAPS