Utilisateur LDAP/AD absent de la gestion des utilisateurs dans Medulla

S'applique à : Medulla / GLPI embarqué / LDAP / Active Directory
Version : Toutes
Environnement : On-Premise / SaaS dédié
Catégorie : Authentification / LDAP / Gestion des utilisateurs

Contexte

Medulla permet aux utilisateurs de se connecter à l'interface en utilisant :

•     le compte administrateur local root ;

•     un compte provenant d'un annuaire LDAP ou Active Directory, lorsque cette authentification a été configurée.

Lors de la première connexion avec un compte LDAP, Medulla doit normalement créer automatiquement l'utilisateur dans sa base locale.

L'utilisateur peut ensuite être retrouvé dans la gestion des utilisateurs afin de lui attribuer les droits et le rôle nécessaires, notamment le rôle Super-Admin.

Important : La connexion avec un compte LDAP ne suffit pas à attribuer automatiquement des droits d'administration. Une fois l'utilisateur créé, un administrateur doit se connecter avec le compte root afin de modifier ses autorisations.

Comment tester la connexion à Medulla ?

La connexion peut être testée de deux manières.

Méthode 1 – Se connecter avec le compte root

Le compte root permet d'accéder à l'administration locale de Medulla, indépendamment de l'authentification LDAP.

Si vous ne disposez pas du mot de passe root, vous pouvez le récupérer en suivant la procédure suivante :

Récupérer le mot de passe root de l'interface Medulla

Méthode 2 – Se connecter avec un compte LDAP

Connectez-vous une première fois à l'interface Medulla avec votre compte LDAP ou Active Directory.

Cette première connexion permet normalement à Medulla de créer automatiquement votre utilisateur dans sa base locale.

Une fois cette première connexion effectuée :

1.   Déconnectez-vous du compte LDAP

2.   Reconnectez-vous avec le compte root

3.   Ouvrez la gestion des utilisateurs

4.   Recherchez l'utilisateur LDAP nouvellement créé

5.   Modifiez ses droits et attribuez-lui le rôle Super-Admin, si nécessaire

La procédure est décrite dans la section « Modifier un utilisateur existant » de la documentation suivante :

Ajouter une entité et créer des utilisateurs

Que faire si l'utilisateur LDAP n'apparaît pas dans la gestion des utilisateurs ?

Si l'utilisateur parvient à saisir ses identifiants LDAP mais qu'il n'apparaît pas dans la gestion des utilisateurs après sa première connexion, il est nécessaire de contrôler la configuration LDAP du GLPI embarqué par Medulla.

Information : Medulla s'appuie sur le GLPI embarqué pour une partie de la gestion des utilisateurs et de l'authentification LDAP. Une configuration LDAP incomplète ou non fonctionnelle dans GLPI peut empêcher l'importation ou la création correcte de l'utilisateur.

Point de contrôle : Vérifiez que la connexion LDAP aboutit réellement à l'ouverture de l'interface Medulla. Le simple fait de ne pas obtenir immédiatement un message d'erreur ne garantit pas que l'authentification et la création de l'utilisateur ont abouti.

Comment vérifier la configuration LDAP dans le GLPI embarqué ?

Connectez-vous au GLPI embarqué par Medulla avec un compte administrateur.

Accédez ensuite au menu de configuration des annuaires LDAP :

Configuration
    └── Authentification
            └── Annuaires LDAP

Sélectionnez l'annuaire LDAP utilisé par Medulla.

Vérifiez notamment les éléments suivants :

•     l'adresse ou le nom DNS complet du serveur LDAP ;

•     le port LDAP ou LDAPS utilisé ;

•     le Base DN utilisé pour rechercher les utilisateurs ;

•     le compte de connexion ou Bind DN ;

•     le mot de passe du compte de connexion ;

•     le filtre de recherche des utilisateurs ;

•     l'attribut utilisé comme identifiant de connexion, par exemple sAMAccountName ou userPrincipalName ;

•     la capacité du serveur Medulla à joindre le contrôleur de domaine ;

•     la résolution DNS du nom complet du contrôleur de domaine.

Tester la connexion à l'annuaire LDAP

Dans la fiche de configuration de l'annuaire LDAP, enregistrez la configuration, puis utilisez le bouton Tester proposé par GLPI.

Le test doit confirmer que GLPI parvient à se connecter et à interroger l'annuaire LDAP.

Important : Si le test de connexion LDAP échoue, la création ou l'importation automatique des utilisateurs dans Medulla ne pourra pas fonctionner correctement.

Que faire si la configuration LDAPS sur le port 636 ne fonctionne pas ?

Le port 636 correspond à une connexion LDAP sécurisée par TLS, appelée LDAPS.

Pour fonctionner, le serveur GLPI embarqué par Medulla doit pouvoir vérifier le certificat TLS présenté par le contrôleur de domaine.

Une connexion LDAPS peut notamment échouer si :

•     l'autorité de certification ayant émis le certificat n'est pas reconnue par le serveur Medulla ;

•     la chaîne de certification racine ou intermédiaire est incomplète ;

•     le certificat est expiré ou n'est pas encore valide ;

•     le nom DNS utilisé dans GLPI ne correspond pas au nom présent dans le certificat ;

•     une adresse IP est utilisée à la place du nom DNS complet du contrôleur de domaine ;

•     le serveur Medulla ne résout pas correctement le nom DNS du contrôleur de domaine ;

•     le port 636 est bloqué par un pare-feu ou n'est pas disponible sur le contrôleur de domaine.

Quelle configuration utiliser dans GLPI pour le LDAPS ?

Pour configurer le LDAPS dans GLPI, deux champs doivent être renseignés de manière précise.

Serveur :

ldaps://nom-complet-du-controleur-de-domaine.domaine.local

Port :

636

Important : Utilisez le nom DNS complet du contrôleur de domaine et non son adresse IP. Le nom utilisé doit correspondre à l'un des noms déclarés dans le certificat TLS du serveur.

Attention : Lorsque le serveur est configuré avec le préfixe ldaps:// et le port 636, n'activez pas l'option Utiliser TLS dans les informations avancées de GLPI. Cette option correspond à une connexion LDAP avec StartTLS, qui constitue un autre mode de fonctionnement.

Importer le certificat ou la chaîne de certification sur le serveur Medulla

Si le certificat LDAPS est auto-signé, le certificat public du contrôleur de domaine doit être ajouté au magasin de certificats du serveur Medulla.

Si le certificat LDAPS a été émis par une autorité de certification interne, par exemple Microsoft AD CS, il faut importer le certificat de l'autorité racine ainsi que les éventuels certificats intermédiaires.

Copiez le certificat au format CRT dans le répertoire suivant :

/usr/local/share/ca-certificates/

Exemple :

sudo cp certificat-autorite.crt /usr/local/share/ca-certificates/

Mettez ensuite à jour le magasin de certificats du serveur :

sudo update-ca-certificates

La sortie de la commande doit indiquer que le certificat a été ajouté.

1 added

Si le certificat a été exporté au format CER binaire, vous pouvez le convertir au format CRT avec OpenSSL :

openssl x509 -inform der -in certificat-ldaps.cer -out certificat-ldaps.crt

Information : Après l'ajout du certificat, il peut être nécessaire de redémarrer les services Web ou le serveur Medulla afin que le nouveau magasin de certificats soit pris en compte.

Tester la connexion LDAPS depuis le serveur Medulla

Sur un serveur Debian, installez l'outil ldapsearch si celui-ci n'est pas disponible :

sudo apt-get update
sudo apt-get install ldap-utils

Effectuez ensuite un test de connexion LDAPS :

ldapsearch -H "ldaps://dc01.domaine.local:636" -x -W -D "CN=Compte_GLPI,OU=Comptes de service,DC=domaine,DC=local" -b "DC=domaine,DC=local"

Les principales options utilisées sont :

•     -H : adresse du serveur LDAPS ;

•     -x : authentification LDAP simple ;

•     -W : demande interactive du mot de passe ;

•     -D : Distinguished Name du compte utilisé pour interroger l'annuaire ;

•     -b : Base DN à partir de laquelle effectuer la recherche.

Si le test échoue, ajoutez l'option suivante pour activer le mode de diagnostic :

-d1

Exemple :

ldapsearch -H "ldaps://dc01.domaine.local:636" -x -W -d1 -D "CN=Compte_GLPI,OU=Comptes de service,DC=domaine,DC=local" -b "DC=domaine,DC=local"

Peut-on tester temporairement le port 389 ?

Oui. Si le test LDAPS sur le port 636 échoue, le port 389 peut être utilisé temporairement afin de distinguer un problème général de configuration LDAP d'un problème spécifique au certificat ou au LDAPS.

Pour effectuer ce diagnostic :

1.   Ouvrez la configuration de l'annuaire LDAP dans GLPI

2.   Notez la configuration actuelle avant toute modification

3.   Remplacez temporairement le serveur ldaps:// par le nom DNS du serveur LDAP

4.   Remplacez temporairement le port 636 par le port 389

5.   Enregistrez la configuration

6.   Relancez le test de connexion LDAP dans GLPI

7.   Effectuez une nouvelle connexion à Medulla avec le compte LDAP

8.   Reconnectez-vous avec le compte root et vérifiez si l'utilisateur apparaît dans la gestion des utilisateurs

Attention : Le passage du port 636 au port 389 doit uniquement servir de test de diagnostic. Une connexion LDAP simple sur le port 389 peut transmettre des informations sensibles sans chiffrement si StartTLS ou un autre mécanisme de protection n'est pas activé. Pour un environnement de production, corrigez la configuration du certificat et rétablissez une connexion LDAPS sécurisée.

Interprétation : Si le test fonctionne sur le port 389 mais échoue sur le port 636, la configuration du Base DN, du compte Bind et du mot de passe est probablement correcte. Le problème est alors vraisemblablement lié au certificat TLS, à la chaîne de certification, au nom DNS ou à l'accès au port 636.

Que faire après avoir corrigé la configuration LDAP ?

Après avoir corrigé la configuration LDAP ou LDAPS et obtenu un test de connexion positif :

1.   Déconnectez-vous de l'interface Medulla

2.   Connectez-vous de nouveau avec le compte LDAP concerné

3.   Vérifiez que l'interface Medulla s'ouvre correctement

4.   Déconnectez-vous du compte LDAP

5.   Reconnectez-vous avec le compte root

6.   Ouvrez la gestion des utilisateurs

7.   Recherchez l'utilisateur LDAP

8.   Attribuez-lui les droits et le rôle souhaités

Que faire si l'utilisateur est toujours absent ?

Si l'utilisateur n'apparaît toujours pas après un test LDAP réussi et une nouvelle connexion, vérifiez :

•     que l'utilisateur est bien présent, actif et non verrouillé dans l'annuaire LDAP ou Active Directory ;

•     qu'il correspond au filtre de recherche configuré dans GLPI ;

•     qu'il se trouve dans une unité d'organisation incluse dans le Base DN ;

•     que le compte Bind dispose des droits de lecture nécessaires ;

•     que l'attribut utilisé comme identifiant de connexion est correctement configuré ;

•     que l'utilisateur emploie le format de connexion attendu, par exemple nom_utilisateur ou utilisateur@domaine.local ;

•     qu'un utilisateur portant le même identifiant ou la même adresse e-mail n'existe pas déjà dans une autre entité ;

•     que l'annuaire LDAP est actif et utilisé comme source d'authentification ;

•     que les journaux du serveur Web ne contiennent pas d'erreur LDAP ou TLS.

Consulter les journaux du serveur Web

Sur un serveur utilisant Apache, vous pouvez consulter les erreurs avec la commande suivante :

sudo tail -f /var/log/apache2/error.log

Reproduisez ensuite le test LDAP ou la tentative de connexion afin d'identifier une erreur de certificat, de connexion, de Bind DN ou de recherche LDAP.

Quelles informations transmettre au support Medulla ?

Si le problème persiste, transmettez au support Medulla :

•     une capture de la configuration LDAP dans GLPI, en masquant le mot de passe ;

•     le résultat du test de connexion LDAP ou LDAPS ;

•     le résultat de la commande ldapsearch, sans communiquer le mot de passe ;

•     le format d'identifiant utilisé par l'utilisateur concerné ;

•     le nom DNS complet du contrôleur de domaine ;

•     le port utilisé, 389 ou 636 ;

•     la date et l'heure de la tentative de connexion ;

•     les erreurs correspondantes présentes dans les journaux Apache ;

•     la version de Medulla utilisée.

Attention : Ne transmettez jamais le mot de passe du compte Bind, le mot de passe de l'utilisateur ou une clé privée de certificat au support.

Résumé des vérifications

Vérification	Action
Connexion avec le compte root	Vérifier l'accès à l'administration locale de Medulla
Première connexion LDAP	Permettre la création automatique de l'utilisateur local
Utilisateur absent	Contrôler la configuration LDAP dans le GLPI embarqué
Test LDAP dans GLPI	Vérifier que GLPI parvient à se connecter et à interroger l'annuaire
Serveur LDAPS	Utiliser ldaps:// suivi du nom DNS complet du contrôleur de domaine
Port LDAPS	Utiliser le port 636
Option Utiliser TLS	Ne pas l'activer pour une configuration ldaps:// sur le port 636
Certificat LDAPS	Importer le certificat ou la chaîne de certification dans le magasin du serveur Medulla
Test serveur	Tester la connexion avec ldapsearch depuis le serveur Medulla
Test temporaire sur le port 389	Identifier un problème spécifique au certificat, au DNS ou au LDAPS
Après correction	Reconnecter l'utilisateur LDAP, puis vérifier sa présence avec le compte root
Attribution des droits	Modifier l'utilisateur et lui attribuer le rôle Super-Admin si nécessaire

Source complémentaire

Pour plus d'informations sur la configuration du LDAPS dans GLPI, l'importation du certificat TLS et les tests avec ldapsearch, consultez le tutoriel suivant :

GLPI : comment configurer l'authentification Active Directory en LDAPS ?