Commandes LDAP pour le diagnostic

Commandes ldapsearch et ldapwhoami couramment utilisées pour diagnostiquer des problèmes LDAP : DN incorrect, filtre invalide, utilisateur introuvable, problème TLS, ou authentification applicative (ex: AAP, applications web).

Mode debug LDAP

Pour afficher les échanges LDAP détaillés, sorte de ‘débug’ très verbeux mais permet de comprendre ce que fait réellement ldapsearch :

# ldapsearch -x -d9

Permet de voir :

• les bind effectués
• les requêtes envoyées
• les erreurs TLS ou réseau
• les DN réellement utilisés

Vérifier l’existence exacte d’un DN utilisateur

Erreur fréquente : un DN mal écrit (ordre prénom/nom, casse, espaces).

Recherche directe par DN

Pour directement faire une recherche par DN :

# ldapsearch -x -H ldaps://ldap.subdomain.company.org \
  -D "cn=svc_subdomain_ldap,ou=Users,dc=company,dc=org" \
  -W \
  -b "cn=Rick Sanchez EXT,ou=Users,dc=company,dc=org" \
  userPassword

Interprétation

La commande a renvoyé un résultat indiquant que le le DN existe mais faux (erreur 32).

• Succès : le DN existe
• Erreur 32 No such object

result: 32 No such object
matchedDN: ou=Users,dc=company,dc=org

Ici le DN existe mais est faux et l’utilisateur n’existe pas sous cette forme.

Identifier le DN correct d’un utilisateur

Plutôt que deviner un DN, il vaut mieux le chercher.

Recherche globale dans l’OU Users

Cette commande permet de comprendre la structure réelle de l’annuaire.

# ldapsearch -x -H ldaps://ldap.subdomain.company.org \
  -D "cn=svc_subdomain_ldap,ou=Users,dc=company,dc=org" \
  -W \
  -b "ou=Users,dc=company,dc=org" \
  "(mail=*)" dn cn uid

Cette commande :

• Parcourt tous les utilisateurs
• Liste DN, CN et UID
• Permet de comprendre la structure de l’annuaire

Filtrer un utilisateur précis

Cette commande cibleun utilisateur précis.

# ldapsearch -x -H ldaps://ldap.subdomain.company.org \
  -D "cn=svc_subdomain_ldap,ou=Users,dc=company,dc=org" \
  -W \
  -b "ou=Users,dc=company,dc=org" \
  "(mail=*)" dn cn uid | grep Rick

Résultat :

dn: cn=Sanchez Rick EXT,ou=Users,dc=company,dc=org
cn: Sanchez Rick EXT
uid: sanchr

Ici le DN réel est donc :

cn=Sanchez Rick EXT,ou=Users,dc=company,dc=org

Il faut veiller à :

• l’ordre Nom / Prénom
• la casse
• les espaces

Retrouver un DN à partir d’un uid

Dans la majorité des cas, l’authentification applicative repose sur l’uid.

# ldapsearch -x -H ldaps://ldap.subdomain.company.org \
  -D "cn=svc_subdomain_ldap,ou=Users,dc=company,dc=org" \
  -W \
  -b "ou=Users,dc=company,dc=org" \
  "(uid=sanchr)" dn

Résultat :

dn: cn=sanchez Rick EXT,ou=Users,dc=company,dc=org

Meilleure méthode car :

• Le uid est stable
• Indépendant du nom affiché
• Idéal pour les applications (AAP, apps web, etc.)

Vérifier les identifiants utilisateur (bind direct)

Une fois le DN correct identifié, on teste le mot de passe (de Rick Sanchez).

# ldapwhoami -x \
  -D "cn=Sanchez Rick EXT,ou=Users,dc=company,dc=org" \
  -W

Résultat :

dn:cn=Sanchez Rick EXT,ou=Users,dc=company,dc=org

Le mot de passe est valide et L’utilisateur peut s’authentifier

Diagnostiquer les erreurs TLS (LDAPS)

Si une application échoue mais que ldapsearch fonctionne, vérifier les erreurs TLS :

certificate verify failed (self-signed certificate in certificate chain)

Les causes possibles :

• Certificat LDAP auto-signé
• CA non reconnu par le système ou l’application

Solutions :

• Installer le certificat CA dans le trust store
• Ou désactiver temporairement la vérification TLS (tests uniquement)

Documentation

MAN ldapsearch
MAN ldapwhoami