Forum GLPI-Project

Fix

Member

Registered: 2006-09-14

Posts: 4

Re: Authentification externe avec AD.

Complement d'information.
Mon probleme de connexion vient de l'attributs UserWorkstations, si un utilisateur (toto) a une restriction d'ouverture de session a un ou plusieurs ordinateurs declaré dans AD, alors la connexion à glpi avec cette utilisateur (toto) me renvoie l'erreur invalid credential. Mais si j'utilise un utilisateur (tata) sans restriction donc sans attribut UserWorkstations aucun probleme: connexion reussi!
Quelqu'un a une solution! Merci d'avance

nickola

Member

Registered: 2007-04-13

Posts: 8

Re: Authentification externe avec AD.

Un petit UP pour ce problème.

Le post de Cygate donné comme solution sur la page 1 ne traite pas ce problème de restriction de machine.

cordialement.

---

Plateforme: Windows 2003 SP2
Version : GLPI 0.7 RC2
PHP:  5.2.4;  MySQL: 5.0.45;   Apache: 2.2.6;

wawa

GLPI-DEV

From: Montpellier / France

Registered: 2006-07-03

Posts: 6,019

Website

Re: Authentification externe avec AD.

à voir avec votre AD, ça ne concerne pas GLPI ça non ?

nickola

Member

Registered: 2007-04-13

Posts: 8

Re: Authentification externe avec AD.

Bonjour,

Ce n'est pas si simple.
Si en veillant à étendre la restriction à la machine hébergeant GLPI et que pourtant l'authentification échoue, cela permet de ne pas écarter le process d'authentification avec l'AD.

Donc cela ne vient pas forcément de l'AD, mais plus de l'intéraction entre GLPI et l'AD.
Je ne sais pas si l'on peut maquetter une restriction de poste avec un OpenLDAP pour vérifier la chose.

Cordialement.

---

Plateforme: Windows 2003 SP2
Version : GLPI 0.7 RC2
PHP:  5.2.4;  MySQL: 5.0.45;   Apache: 2.2.6;

nickola

Member

Registered: 2007-04-13

Posts: 8

Re: Authentification externe avec AD.

Bonjour,

Voici la solution pour ce problème de restriction de connection à une ou plusieurs machines.

[solution]
La solution consiste à ajouter le serveur où se situe l'AD à la liste des PC sur lesquels l'utilisateur peut se connecter.

[Question de sécurité]
Si quelques uns se posent la question de savoir, si cela est pénalisant du point de vue de la sécurité, la réponse est non. L'AD est par essence sur un DC et un simple user ne peut s'y ouvrir une session dessus.

[explication]
Voici l'explication pour ceux que çà intéresserai :

Il est question dans la page 1 d'ajouter dans le profil de l'utilisateur dans l'AD la possibilité de so connecter au serveur sur lequel GLPI est installé.
En fait, le processus de connection ou les infos de l'utilisateur sont prise en compte se situe dans le sens GLPI vers le serveur hébergeant l'AD.

Pour s'en convaincre il suffit de vérifier le processus de validation LDAP.
L'enchainement des fonctions est celui-là (sauf erreur ) :
1) login.php utilise la fonction try_LDAP_auth située dans auth.function.php
2) auth.function.php lance la fonction ldap_auth située toujours dans auth.function.php
3) Cette fonction utilise la fonction connection_ldap (ligne 817) présente dans auth.class.php
4) Cette dernière utilise connect_ldap présente dans auth.function.php (ligne 739).
Ligne 753 une connection est faite à l'AD via les infos de l'utilisateur configuré dans la section Authentification de GLPI où nous avons configuré la connection au serveur LDAP.
Cette procédure renvoie donc une ressource en retour placée dans la varible $ds (ligne 152 de auth.class.php).

Si l'on rajoute le bloc de test suivant :

if (connect_ldap($host, $port, $login, $password, $use_tls)) {
  echo "Connect_ldap OK";
} else {
  echo "Connect_ldap Error";
}

On s'aperçoit que l'erreur commence ici.

Dès lors le test

if (@ldap_bind($ds, $dn, $password))

ligne 159 échoue et l'on passe directement à l'affectation de l'erreur login[16] qui affiche Utilisateur non trouvé ou plusieurs utilisateurs identiques trouvés

A la ligne 158 on peut se rendre compte que la variable $dn comporte bien les infos sur l'utilisateur.
Donc la piste d'une impossibilité de connection sur l'AD semblait probable.

[OpenLdap]

Personne n'a précisé avoir le problème avec OpenLDAP.
Il serait peut-être bien de faire le même test malgré tout pour vérifier définitivement la présence ou non de ce problème et l'efficacité de cette solution avec OpenLDAP.

Cordialement.

---

Plateforme: Windows 2003 SP2
Version : GLPI 0.7 RC2
PHP:  5.2.4;  MySQL: 5.0.45;   Apache: 2.2.6;