Accès refusé authentification ldap

malili · 2009-02-02 16:15:29

Bonjour,

Depuis la mise à jour de la version 0.70.2 vers 0.71.3 (maintenant en 0.71.5), la connexion d'un nouvel utilisateur via l'authentification ldap ne fonctionne plus.

Par contre, lorsque j'ajoute un utilisateur en utilisant l'onglet "Utilisateur / Depuis une source externe", l'utilisateur peut ouvrir une session sans pb via l'authentification Ldap.

De plus les anciens utilisateurs peuvent toujours ouvrir une session et je peux synchroniser leur login avec l'annuaire.

Au niveau de l'onglet Authentification : Test de connexion à l'annuaire LDAP est valide

De même au niveau de l'onglet Régle sur Règles d'affectation d'entité et de droits: Tester le moteur de règles est valide

Voici la config de la réglé :

Actions
Champs Type d'action Valeur
Profils Assigner post-only
Entité Assigner HOTLINE
Récursif Assigner Non

Merci pour votre aide.

Malili

malili · 2009-02-05 11:27:43

Bonjour à tous,

N'ayant pas de réponses, nous avons cherché de notre côté et nous avons remarqué que dans la base mysql de GLPI_users lors de l'authentifiaction d'un nouvel utilisateur, une entrée est bien créé ID par contre tous les champs sont NULL.

Mais en ajoutant un utilisateur via Ajout direct d'une source externe ldap (de notre annuaire), les champs sont bien remplis.

Voici un extrait de la table GLPI_Users :

ID name password password_md5 email phone phone2 mobile realname firstname

1590 collartd NULL dany.collart@upmc.fr 33144279733 NULL Collart Dany NULL
1589 NULL NULL NULL NULL NULL NULL NULL

1589 correspond à l'authentifiaction collartd avec un message "accès refusé"
1590 correspond à l'authentification via 'l'ajout directe d'une source externe de notre annuaire ldap"

Peux t on supprimer sans conséquences les entrées de la table GLPI_users pour laquelle les entrées sont à NULL car j'en ai 162 pour l'instant.

Merci de votre réponse.

Malili.

malili · 2009-02-06 00:14:01

Bonsoir,

Nous avons des questions par rapport à nos recherches : en tapant la requete INSERT de la table GLPI_Users est ce normal que les champs hors données de connexion "name, mail..." n'apparaissent pas dans la requete

après la requête INSERT l'authentification est considérée comme réussie
Dans login.php

// now we can continue with the process...
echo "<script language = 'javascript'>";
echo "alert(\"auth_succeded[".$identificat->auth_succeded."]\");"; --> me renvoie 1
echo "</script>";
if ($identificat->auth_succeded) {
$identificat->initSession(); --> on va dans l'inti de la session
} else { // we have done at least a good login? No, we exit.

On passe donc dans la function initSession() du fichier auth.class.php

Pourquoi dans cette fonction les variables $this->user->fields['firstname'] et $this->user->fields['name'] ne sont pas renseignées ?

J'espère que vous pourrez nous aider à trouver une solution.

Malili

malili · 2009-02-10 10:53:15

Bonjour,

Après avoir fait de nombreux tests et des recherches, nous avons trouvé "une solution" pour régler ce problème.

Nous sommes obligé d'ajouter dans un des champs de l'onglet Configuration / Authentifiaction ldap :

l'attribut uidinterne ( un de nos attribut ). Nous l'avons mis dans "commentaire" et à partir de là, on arrive bien à importer automatiquement l'uid qui permet l'authentification.

Pourriez-vous nous expliquer cette bizarrerie afin de mettre en place une solution propre.

Bonne journée.

Malili.

malili · 2009-02-10 12:39:41

Finalement, nous avons trouvé la solution par rapport à notre architecture.

Nous avons modifié le fichier user.class.php :

Nous avons ajouté la ligne suivante $v[0][$fields['name']][0] = $login;

dans la fonction dans la fonction "function getFromLDAP($ldap_connection,$ldap_method, $userdn, $login, $password = "")"

après les lignes
$sr = @ ldap_read($ldap_connection, $userdn, "objectClass=*", $f);
$v = ldap_get_entries($ldap_connection, $sr);

// Explication :
// Feb 3 16:48:02 ldap1 slapd[1357]: conn=79288 fd=39 ACCEPT from IP=x.x.x.x:4114 (IP=0.0.0.0:390)
// Feb 3 16:48:02 ldap1 slapd[1362]: conn=79288 op=0 BIND dn="uid=support,ou=machines,dc=xxx,dc=fr" method=128
// Feb 3 16:48:02 ldap1 slapd[1362]: conn=79288 op=0 BIND dn="uid=support,ou=Machines,dc=xxx,dc=fr" mech=SIMPLE ssf=0
// Feb 3 16:48:02 ldap1 slapd[1362]: conn=79288 op=0 RESULT tag=97 err=0 text=
// Feb 3 16:48:02 ldap1 slapd[6497]: conn=79288 op=1 SRCH base="ou=people,dc=xxx,dc=fr" scope=2 deref=0 filter="(uid=nataf)"
// Feb 3 16:48:02 ldap1 slapd[6497]: conn=79288 op=1 SRCH attr=dn uid
// Feb 3 16:48:02 ldap1 slapd[6497]: conn=79288 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
// Feb 3 16:48:02 ldap1 slapd[3485]: conn=79288 op=2 BIND anonymous mech=implicit ssf=0
// Feb 3 16:48:02 ldap1 slapd[3485]: conn=79288 op=2 BIND dn="uidInterne=toto,ou=People,dc=xxx,dc=fr" method=128
// Feb 3 16:48:02 ldap1 slapd[3485]: conn=79288 op=2 BIND dn="uidInterne=toto,ou=People,dc=xxx,dc=fr" mech=SIMPLE ssf=0
// Feb 3 16:48:02 ldap1 slapd[3485]: conn=79288 op=2 RESULT tag=97 err=0 text=
// Feb 3 16:48:02 ldap1 slapd[1363]: conn=79288 op=3 SRCH base="uidInterne=toto,ou=People,dc=xxx,dc=fr" scope=0 deref=0 filter="(objectClass=*)"
// Feb 3 16:48:02 ldap1 slapd[1363]: conn=79288 op=3 SRCH attr=uid mail sn givenname telephonenumber mobile
// Feb 3 16:48:02 ldap1 slapd[1363]: conn=79288 op=3 SEARCH RESULT tag=101 err=0 nentries=1 text=
// Feb 3 16:48:05 ldap1 slapd[6497]: conn=79288 op=4 UNBIND
// Feb 3 16:48:05 ldap1 slapd[6497]: conn=79288 fd=39 closed

// Le problème vient du fait que la recherche est faite avec le compte de l'utilisateur
// et non pas le compte machine 'support'
// Dans notre architecture, un utilisateur ne peut pas récupérer son propre uid qui ne sert qu'à s'authentifier
// Pour pallier au problème, on force ici le champs 'name' avec la valeur de la variable $login qui contient déjà l'uid de l'utilisateur
// Cette variable est passée en paramètre à cette fonction
// La solution serait :
// - soit récupérer l'uid avec le compte machine 'support' (compte LDAP paramétré dans la configuration GLPI : rootdn)
// - soit positionner 'name' avec $login au départ et ne plus y toucher.

Malili.

wawa · 2009-02-10 18:55:35

bonjour
http://www.glpi-project.org/forum/viewtopic.php?id=128
sans ces infos, c'est normal que vous n'avez pas de réponses

MoYo · 2009-02-10 20:21:57

malili wrote:

// Le problème vient du fait que la recherche est faite avec le compte de l'utilisateur
// et non pas le compte machine 'support'

Effectivement ca peux poser des problèmes. Car dans beaucoup d'archi l'utilisateur n'a accès qu'à très peu d'infos du LDAP.
wawa, il faudrait peut-être dans la fonction ldap_auth si l'authentification est réussite et qu'il existe un rootdn refaire une connexion en utilisant ce compte avant de faire un getFromLDAP

Forum GLPI-Project

Announcement

#1 2009-02-02 16:15:29

Accès refusé authentification ldap

#2 2009-02-05 11:27:43

Re: Accès refusé authentification ldap

#3 2009-02-06 00:14:01

Re: Accès refusé authentification ldap

#4 2009-02-10 10:53:15

Re: Accès refusé authentification ldap

#5 2009-02-10 12:39:41

Re: Accès refusé authentification ldap

#6 2009-02-10 18:55:35

Re: Accès refusé authentification ldap

#7 2009-02-10 20:21:57

Re: Accès refusé authentification ldap

Board footer