Echec de la première connexion des utilisateurs LDAP et non création de leur compte #4129

Open
opened 3 years ago by miros · 9 comments
miros commented 3 years ago

version de SPIP : 3.2.1 [23954]
version de PHP : 5.6.33
version de MySQL : 14.14

Jusqu'à il n'y a pas si longtemps (désolé pour l'imprécision, on ajoute pas des utilisateurs si fréquemment), les utilisateurs LDAP pouvaient s'authentifier sur SPIP et l'utilisateur SPIP était créé dans la base de donnée. J'ai remarqué récemment que les nouveaux arrivants ne pouvaient plus s'authentifier, et donc créer leur compte, de cette manière.

Problème

Ce problème a été remarqué sur le site en production mis à jour en 3.2.1, ainsi que sur une installation de test 3.2.1 propre (attention au "bug de config LDAP":https://forum.spip.net/fr_263478.html?debut_forums=%40266046#forum266046 ).

Le site SPIP est configuré pour utiliser l'authentification LDAP ;

Un nouvel utilisateur est créé dans le LDAP ;

Il se connecte au site SPIP avec ses identifiants LDAP ;

La connexion échoue systématiquement.

La demande #3824 offre une solution avec _AUTORISER_AUTH_FAIBLE mais elle ne me semble pas satisfaisante sachant que LDAP est configurable à l'installation de SPIP, le mode par défaut devrait assurer que l'on puisse se connecter.

Workaround

Il y a au moins deux solutions qui fonctionnent :

La création de l'utilisateur à la main dans la base de donnée permet à l'utilisateur de se connecter (insert into spip_auteurs ...)

Mettre define ('_AUTORISER_AUTH_FAIBLE', true);

Analyse

Lors de la toute première authentification d'un utilisateur inconnu de SPIP, le mot de passe est envoyé sécurisé par défaut (hachage réalisé par le javascript avec les aleas actuel/futur). Seulement l'authentification LDAP requiert le mot de passe en clair. Lorsque l'utilisateur existe déjà et que la source est ldap, alors la sécurisation du mot de passe est désactivée (login.js, login-sha-min.js, le cadenas à côté du champ mot de passe disparait), d'où le fonctionnement du workaround 1. Si on désactive la sécurisation du mot de passe, workaround 2, alors cela fonctionne lors de la première authentification, et l'utilisateur est bien créé dans SPIP.

Remarque

L'envoi en clair n'est pas un gros problème dans notre cas, le site est forcé en HTTPS.

version de SPIP : 3.2.1 [23954] version de PHP : 5.6.33 version de MySQL : 14.14 Jusqu'à il n'y a pas si longtemps (désolé pour l'imprécision, on ajoute pas des utilisateurs si fréquemment), les utilisateurs LDAP pouvaient s'authentifier sur SPIP et l'utilisateur SPIP était créé dans la base de donnée. J'ai remarqué récemment que les nouveaux arrivants ne pouvaient plus s'authentifier, et donc créer leur compte, de cette manière. ## Problème Ce problème a été remarqué sur le site en production mis à jour en 3.2.1, ainsi que sur une installation de test 3.2.1 propre (attention au "bug de config LDAP":https://forum.spip.net/fr_263478.html?debut_forums=%40266046#forum266046 ). # Le site SPIP est configuré pour utiliser l'authentification LDAP ; # Un nouvel utilisateur est créé dans le LDAP ; # Il se connecte au site SPIP avec ses identifiants LDAP ; # La connexion échoue systématiquement. La demande #3824 offre une solution avec `_AUTORISER_AUTH_FAIBLE` mais elle ne me semble pas satisfaisante sachant que LDAP est configurable à l'installation de SPIP, le mode par défaut devrait assurer que l'on puisse se connecter. ## Workaround Il y a au moins deux solutions qui fonctionnent : # La création de l'utilisateur à la main dans la base de donnée permet à l'utilisateur de se connecter (`insert into spip_auteurs ...`) # Mettre `define ('_AUTORISER_AUTH_FAIBLE', true);` ## Analyse Lors de la toute première authentification d'un utilisateur inconnu de SPIP, le mot de passe est envoyé sécurisé par défaut (hachage réalisé par le javascript avec les aleas actuel/futur). Seulement l'authentification LDAP requiert le mot de passe en clair. Lorsque l'utilisateur existe déjà et que la source est `ldap`, alors la sécurisation du mot de passe est désactivée (`login.js`, `login-sha-min.js`, le cadenas à côté du champ mot de passe disparait), d'où le fonctionnement du workaround 1. Si on désactive la sécurisation du mot de passe, workaround 2, alors cela fonctionne lors de la première authentification, et l'utilisateur est bien créé dans SPIP. ## Remarque L'envoi en clair n'est pas un gros problème dans notre cas, le site est forcé en HTTPS.
b_b commented 3 years ago
Owner

Salut et merci pour le signalement, on dirait bien que ton bug est le même que celui signalé dans #3919, tu confirmes ?
Version cible mise à 90. LDAP
Statut changé à En cours

Salut et merci pour le signalement, on dirait bien que ton bug est le même que celui signalé dans #3919, tu confirmes ? **Version cible mise à 90. LDAP** **Statut changé à En cours**
Poster

b b a écrit :

Salut et merci pour le signalement, on dirait bien que ton bug est le même que celui signalé dans #3919, tu confirmes ?

Le bug #3919 est celui auquel je fais référence par "bug de config LDAP", mais pas le bug rapporté.

b b a écrit : > Salut et merci pour le signalement, on dirait bien que ton bug est le même que celui signalé dans #3919, tu confirmes ? Le bug #3919 est celui auquel je fais référence par "bug de config LDAP", mais pas le bug rapporté.
Poster

Petite précisions sur le workaround 2, il faut préciser la source comme ldap :

insert into spip_auteurs (nom, statut, login, source, pass) values ("Foo", "1comite", "bar", "ldap", "");

Petite précisions sur le workaround 2, il faut préciser la source comme `ldap` : `insert into spip_auteurs (nom, statut, login, source, pass) values ("Foo", "1comite", "bar", "ldap", "");`
Poster

workaround 1 pardon

workaround 1 pardon
b_b commented 3 years ago
Owner

J'ai comme l'impression qu'il y a incompréhension :)

Peux-tu vérifier que ça fonctionne ou non, en appliquant les modifications proposées dans #3918 & #3919 ?

J'ai comme l'impression qu'il y a incompréhension :) Peux-tu vérifier que ça fonctionne ou non, en appliquant les modifications proposées dans #3918 & #3919 ?
Poster

La modification #3919 n'est pas liée, elle ne concerne que le fichier de configuration, elle ne règle donc pas le problème. Comme je l'ai précisé, je n'ai pas patché SPIP, vu que cela ne concerne que l'installation, j'ai édité le fichier connect.php après installation en remplaçant '','utf8' par 'ldap.php','utf8'

La modification #3918 n'est pas nécessaire non plus, le ldap.php ci-dessus évite d'avoir à ajouter le suffixe .php dans le code comme proposé dans ce patch, ce qui n'est valable que dans le cas où l'on spécifie simplement ldap.

La modification #3919 n'est pas liée, elle ne concerne que le fichier de configuration, elle ne règle donc pas le problème. Comme je l'ai précisé, je n'ai pas patché SPIP, vu que cela ne concerne que l'installation, j'ai édité le fichier `connect.php` après installation en remplaçant `'','utf8'` par `'ldap.php','utf8'` La modification #3918 n'est pas nécessaire non plus, le `ldap.php` ci-dessus évite d'avoir à ajouter le suffixe `.php` dans le code comme proposé dans ce patch, ce qui n'est valable que dans le cas où l'on spécifie simplement `ldap`.
b_b commented 3 years ago
Owner

Ok, je comprends mieux ton signalement, la piste serait donc d'appliquer la proposition de marcimat dans #3824, cf :

On peut activer cette constante lorsque le type d'authentification remarque que l'utilisateur peut être logé avec ce type d'authentification (si c'est possible, dans xx_retrouver_login() donc),

Du coup, le ticket ici-présent ne serait-il pas un doublon de #3824 ?

Ok, je comprends mieux ton signalement, la piste serait donc d'appliquer la proposition de marcimat dans #3824, cf : > On peut activer cette constante lorsque le type d'authentification remarque que l'utilisateur peut être logé avec ce type d'authentification (si c'est possible, dans xx_retrouver_login() donc), Du coup, le ticket ici-présent ne serait-il pas un doublon de #3824 ?
Poster

C'est pour cela que je mentionne cette demande effectivement, les problèmes sont connexes mais il ne s'agit pas d'un doublon pour moi : #3824 est une demande d'évolution, certes qui pourrait éventuellement régler le problème signalé, mais à mon avis il s'agit ici d'un bug, puisqu'il rend la connexion impossible via LDAP sur un site nouvellement créé/mis à jour. Seule l'utilisation d'un workaround permet de régler ce problème.

C'est pour cela que je mentionne cette demande effectivement, les problèmes sont connexes mais il ne s'agit pas d'un doublon pour moi : #3824 est une demande d'évolution, certes qui pourrait éventuellement régler le problème signalé, mais à mon avis il s'agit ici d'un bug, puisqu'il rend la connexion impossible via LDAP sur un site nouvellement créé/mis à jour. Seule l'utilisation d'un workaround permet de régler ce problème.
b_b commented 3 years ago
Owner

J'ai fais le lien entre les deux tickets, ceci afin qu'on oublie pas de fermer celui-ci le jour où on corrigera le premier.

J'ai fais le lien entre les deux tickets, ceci afin qu'on oublie pas de fermer celui-ci le jour où on corrigera le premier.
cy.altern added the
LDAP
label 1 week ago
cy.altern removed this from the (deleted) milestone 1 week ago
Sign in to join this conversation.
No Milestone
No project
No Assignees
2 Participants
Notifications
Due Date

No due date set.

Dependencies

This issue currently doesn't have any dependencies.

Loading…
There is no content yet.