Problème connexion LDAP

Bonjour,
pour ce qui est de la version 3.5.0, dont vous disiez qu'elle fonctionne, les identifiants AD sont-ils enregistrés dans la base GRR avec la casse d'origine ?
Car l'identification a été modifiée entre 3.5.0 et 3.5.1 en principe seulement pour les identifications sur base locale... il doit y avoir un grain de sable qui bloque quelque part.
Merci encore pour votre aide,
cordialement,
YN

En fait c'est en version 3.4.3 que la connexion via LDAP fonctionnait.
Ensuite nous avons migré directement dans la version 3.5.1, sans toucher aux données, donc la casse des identifiants AD est toujours restée la même dans la base GRR (en minuscules, sauf pour mon login que j'ai forcé en majuscules pour éliminer cette hypothèse => mais ça ne fonctionne ni pour mon collègue qui a le login en minuscules ni pour moi qui l'ai en majuscules).
Cordialement.

Bonjour,
je viens de reprendre les différences entre le code de la 3.5.1 et la 3.4.3b et je ne vois pas ce qui justifie cet échec.
Avez-vous des caractères accentués en cause ? Le changement de codage de la base de latin1 à utf8 poserait-il problème ?
Cordialement,
YN

Bonjour,
Dans mon mot de passe je n'ai pas de caractère accentué. Le seul caractère spécial est un %
Est-ce que ce type de caractère peut poser problème entre latin1 et utf8 ?
Si oui quel caractère spécial ne poserait pas de problème ? (je suis obligé d'en avoir un dans l'AD)
NB : pour un user local j'ai mis le même mot de passe que le mien (donc avec le %) et je peux toujours me connecter
L'idéal serait vraiment de pouvoir ajouter des traces sur l'environnement de test concerné pour savoir ce qui bloque...
Cordialement.

D'après les tables ASCII et utf8, le code du % est identique. Cela ne devrait donc pas poser de problème.
Dès que possible, je cherche où poser des jalons pour tirer ce problème au clair.
Merci pour votre compréhension.
Cordialement,
YN

Bonjour,
je viens de reprendre le code et je suis toujours dans le brouillard...
Si vous pouviez tester :
les scripts de la version 3.4.3b github.com/JeromeDevome/GRR/releases/tag/v3.4.3b
ceux-ci github.com/JeromeDevome/GRR/tree/GRR-3.4.3
ceux de la v3.5.0b github.com/JeromeDevome/GRR/releases/tag/v3.5.0b
D'après le code php, c'est la fonction grr_opensession qui rend un code 2 au lieu de reconnaître que l'utilisateur est bien authentifié. En testant ces différentes versions, je pourrai peut-être comprendre ce qui cloche.
Merci pour votre patience et votre aide précieuse.
Cordialement,
YN

Bonjour,
Je vais voir avec mon collègue pour qu'il mette en place successivement les différentes versions.
Est-ce qu'il faut faire un copier/coller de l'ensemble des fichiers des ZIP (pour écraser la version actuelle) ou est-ce qu'il suffit de cibler certains répertoires/fichiers ?
Cordialement.

Bonjour,
le mieux serait d'installer successivement les versions indiquées, éventuellement dans le même répertoire, en décompressant les archives zip. Le fichier connect.inc.php devrait être récupéré et valable de la 3.4.3b à la 3.5.0b.
Pour chaque version, merci de faire le test de connexion depuis un compte AD puis un test de deuxième connexion, certains utilisateurs ayant remonté un souci de reconnexion.
Merci pour votre aide.
Cordialement,
YN

Bonjour,
Nous avons installé les versions 3.4.3b puis 3.5.0b et fait plusieurs tests de connexions/déconnexions avec des users LDAP : ça fonctionne bien.
Ca serait donc la version 3.5.1 qui "casse" la connexion LDAP dans notre cas ?
Est-ce que l'on tente de réinstaller la version 3.5.1 ou est-ce qu'il existe une version 3.5.0x à tester au préalable ?
Cordialement.

Après avoir fait un backup de la version 3.5.0b on a réinstallé la version 3.5.1.RC0 : la connexion LDAP ne fonctionne plus (dès la 1ère tentative de connexion).