Interroger LDAP et Active Directory depuis Linux avec ldapsearch sans mot de passe en ligne de commande

Objectif

Exécuter depuis un hôte Linux une requête LDAP authentifiée et chiffrée auprès d'un serveur LDAP ou d'Active Directory, sans exposer le mot de passe de liaison dans la liste des processus ni dans l'historique du shell.

Prérequis

Le paquet ldap-utils (ou équivalent) qui fournit ldapsearch ; soit un DN de liaison et son mot de passe, soit un ticket Kerberos valide obtenu avec kinit pour une liaison GSSAPI ; le DN de base du serveur.

Étapes

1. Ne jamais placer un mot de passe directement après -w sur la ligne de commande : il est visible de tous les utilisateurs de l'hôte via ps pendant toute la durée de la commande et se retrouve dans l'historique du shell. Utiliser -W, que la page de manuel décrit comme demandant interactivement le mot de passe de liaison, ou -y <file>, dont la page de manuel indique qu'il utilise l'intégralité du contenu du fichier comme mot de passe : un saut de ligne final en fait donc partie. Écrire le fichier avec printf '%s' "$PW" > file plutôt qu'avec echo, et le protéger avec chmod 600.
2. Exemple de liaison simple : ldapsearch -x -H ldaps://dc.example.com -D "cn=svc-agent,ou=service,dc=example,dc=com" -y /etc/ldap/svc.pass -b "dc=example,dc=com" "(uid=alice)" cn mail. -x sélectionne l'authentification simple ; -H ldaps://... utilise TLS implicite sur le port 636.
3. Liaison SASL/GSSAPI à partir d'un ticket Kerberos existant, donc sans aucun mot de passe : kinit svc-agent@EXAMPLE.COM (voir l'article sur les bases du client Kerberos), puis ldapsearch -Y GSSAPI -H ldap://dc.example.com -b "dc=example,dc=com" "(sAMAccountName=alice)". Cela nécessite le plugin SASL GSSAPI (libsasl2-modules-gssapi-mit sur Debian/Ubuntu, cyrus-sasl-gssapi sur la famille RHEL). De plus, ldapsearch canonicalise le nom d'hôte par résolution DNS inverse, sauf si -N est indiqué : un enregistrement PTR erroné entraîne donc une demande de ticket pour le mauvais principal de service.
4. Privilégier StartTLS plutôt que LDAP en clair lorsque LDAPS n'est pas disponible : ajouter -ZZ, que la page de manuel décrit comme exigeant la réussite de StartTLS (un simple -Z se contente de le demander et poursuit si le serveur refuse).
5. Pour les jeux de résultats volumineux, utiliser le contrôle de résultats paginés simple : -E pr=500/noprompt demande 500 entrées par page et enchaîne automatiquement les pages sans attendre une touche entre chacune, ce qui compte pour les scripts non interactifs. Active Directory plafonne la taille d'une page selon sa stratégie MaxPageSize (1000 par défaut) ; des valeurs plus élevées n'y apportent donc rien.

Résultat attendu

La commande renvoie les entrées correspondant au filtre au format LDIF. Une liaison échouée renvoie un code de résultat LDAP explicite (par exemple 49, identifiants invalides) plutôt qu'un jeu de résultats vide, ce qui permet de distinguer des « identifiants erronés » d'une « absence de correspondance ».

Limites et base de vérification

-y laisse tout de même le mot de passe lisible dans le contenu du fichier pour quiconque peut lire ce chemin ; les permissions du fichier comptent donc autant que le fait d'éviter -w. -ZZ échoue de manière stricte (toute la liaison échoue) si le serveur ne prend pas en charge StartTLS, ce qui est le comportement par défaut le plus sûr pour les scripts qui ne doivent pas retomber silencieusement sur du texte en clair.