Sur le serveur GLPI (Debian) :

apt install ldap-utils -y

Avant toute configuration dans GLPI, vérifier que la connexion LDAPS fonctionne depuis le serveur :

LDAPTLS_REQCERT=never ldapsearch -x \
  -H ldaps://10-ServAD-DNS.cbaudiment.fr:636 \
  -D "CN=Administrateur,CN=Users,DC=cbaudiment,DC=fr" \
  -w "MOTDEPASSE" \
  -b "OU=Utilisateurs,OU=Organisation,DC=cbaudiment,DC=fr" \
  "(objectClass=user)" samaccountname

Si la commande retourne la liste des utilisateurs, la connectivité est OK.

Chemin : Configuration → Authentification → Annuaires LDAP → + Ajouter

• Cliquer sur Active Directory dans la ligne "Préconfiguration" pour pré-remplir les champs automatiquement
• Renseigner les champs suivants :
  • Nom : Annuaire AD
  • Serveur par défaut : Oui
  • Actif : Oui
  • Serveur : ldaps://10-ServAD-DNS.cbaudiment.fr
  • Port : 636
  • BaseDN : OU=Utilisateurs,OU=Organisation,DC=cbaudiment,DC=fr
  • Utiliser bind : Oui
  • DN du compte : CN=Administrateur,CN=Users,DC=cbaudiment,DC=fr
  • Mot de passe : mot de passe du compte
  • Champ de l'identifiant : samaccountname
  • Champ de synchronisation : objectguid
• Le champ Serveur doit impérativement contenir le préfixe ldaps://. Sans ce préfixe, GLPI construit une URI ldap:// en clair même avec le port 636, et la connexion échoue.
• Dans l'onglet Informations avancées, laisser Utiliser TLS sur Non — LDAPS sur le port 636 est déjà chiffré nativement, StartTLS est inutile et incompatible.

Chemin : Administration → Utilisateurs → Liaison annuaire LDAP → Importation de nouveaux utilisateurs

• Cliquer sur Rechercher sans filtre
• Sélectionner tous les utilisateurs
• Cliquer sur Actions → Importer
• La recherche est récursive par défaut : les utilisateurs dans les sous-OU (Commerciaux, RH, IT, etc.) sont tous remontés sans configuration supplémentaire.

Pour que les nouveaux comptes AD soient importés automatiquement sans attendre la première connexion :

• Ouvrir le crontab de www-data : crontab -e -u www-data
• Ajouter la ligne suivante :

  # Synchronisation GLPI ↔ AD toutes les heures
  0 * * * * cd /var/www/html/glpi && /usr/bin/php bin/console glpi:ldap:synchronize_users --no-interaction -d 3 >/dev/null 2>&1

• L'option -d 3 désactive automatiquement les comptes GLPI lorsqu'un compte est supprimé ou désactivé dans l'AD.

Problème 1 — L'AD refuse les connexions LDAP non sécurisées

• Symptôme :

  ldap_bind: Strong(er) authentication required (8)
  00002028: LdapErr: DSID-0C09035C, comment: The server requires binds to turn on integrity checking if SSL\TLS are not already active

• Cause : La GPO de sécurité du domaine impose LDAP signé ou chiffré. Les connexions LDAP en clair sur le port 389 sont refusées.
• Résolution : Utiliser LDAPS sur le port 636 au lieu de LDAP sur le port 389.

Problème 2 — LDAPS échoue à cause du certificat auto-signé

• Symptôme : ldap_sasl_bind(SIMPLE): Can't contact LDAP server (-1)
• Cause : Le certificat du DC est signé par la CA interne SERVAD-CA, non reconnue par défaut.
• Résolution : Importer le certificat racine dans le magasin système :
  • Télécharger le certificat CA depuis http://172.30.10.11/certsrv → format Base 64
  • Copier le contenu dans /usr/local/share/ca-certificates/ca-cbaudiment.crt
  • Mettre à jour le magasin et vérifier :
    • update-ca-certificates
    • ls /usr/lib/ssl/certs/ | grep cbaudiment

Problème 3 — PHP/Apache ne valide pas le certificat malgré l'import système

• Symptôme : Le test GLPI échoue avec Can't contact LDAP server (-1) alors que ldapsearch fonctionne.
• Cause : PHP utilise la libldap qui ne lit pas toujours /etc/ldap/ldap.conf correctement dans le contexte Apache.
• Résolution : Ajouter la directive directement dans AuthLDAP.php pour forcer l'option avant la connexion :

  sed -i 's/$ds = @ldap_connect($ldapuri);/ldap_set_option(NULL, LDAP_OPT_X_TLS_REQUIRE_CERT, LDAP_OPT_X_TLS_NEVER);\n        $ds = @ldap_connect($ldapuri);/' /var/www/html/glpi/src/AuthLDAP.php

• Vérifier la modification :
  • sed -n '3097,3103p' /var/www/html/glpi/src/AuthLDAP.php

Problème 4 — OPcache empêche la prise en compte des modifications de code

• Symptôme : La modification du fichier PHP n'a aucun effet sur le comportement de GLPI.
• Cause : PHP OPcache met en cache le bytecode compilé et ne relit pas les fichiers modifiés.
• Résolution : Désactiver OPcache dans le php.ini d'Apache :
  • sed -i 's/opcache.enable=1/opcache.enable=0/' /etc/php/8.4/apache2/php.ini
  • systemctl restart apache2

Problème 5 — GLPI construit une URI LDAP incorrecte (cause racine principale)

• Symptôme : Test GLPI toujours en échec malgré toutes les corrections précédentes :

  Unable to bind to LDAP server 10-ServAD-DNS.cbaudiment.fr:636
  error: Can't contact LDAP server (-1)

• Cause : GLPI construit l'URI LDAP en utilisant ldap:// par défaut si le champ Serveur ne contient pas de préfixe explicite.
• Vérification en base de données :
  • mysql -u root -p glpi -e "SELECT name, host, port FROM glpi_authldaps;"
• Résolution : Corriger le champ host directement en base :
  • mysql -u root -p glpi -e "UPDATE glpi_authldaps SET host='ldaps://10-ServAD-DNS.cbaudiment.fr' WHERE name='Annuaire AD';"
• Ou depuis l'interface GLPI, modifier le champ Serveur pour qu'il contienne explicitement ldaps://10-ServAD-DNS.cbaudiment.fr.

Supprimer les fichiers de test créés pendant le débogage :

• rm /var/www/html/glpi/test_ldap.php
• rm /var/www/html/glpi/test_info.php
• rm /tmp/test_ldap.php
• rm /tmp/diag_ldap.php