Je suis pas certain d'avoir tout compris ton message.
Une chose est certaine : des applications codées avec les pieds au niveau de l'authentification, il y'en a. Comme j'ai compris ton problème, c'est le cas des applications qui s'authentifient et gèrent ça un peu comme une base de donnée sql. En fait c'est faux car, comme tu l'as si bien remarqué, ça contourne les ACL du serveur LDAP (qui sont, à mon avis, très puissantes (par expression régulière, demander un niveau d'algo de chiffrement minimum (en plus du classique utilisateurs/groupe) avec diverses niveaux (tu peux donner l'accès à un attribut uniquement à l'authentification, mais pas à la lecture, la comparaison et la recherche)).
Malheureusement j'ai trop souvent vu des applications qui demandent un utilisateur dédié et vont comparer le mot de passe directement en assumant que l'annuaire stocke celui-ci dans un format X (genre SSHA ou SHA ou MD5) ou pire qui vont modifier le mot de passe en écrivant directement l'attribut userPassword au lieu d'utiliser l'opération étendue disponible pour ça (et qui permet à l'annuaire de gérer d'autres champs, très utile pour avoir les mots de passe unifié entre Unix et Windows (samba et pam gère très bien le changement de mot de passe avec exop))
Le problème de LDAP c'est que du côté applicatif, beaucoup de gens n'ont pas compris et utilisent ça comme une base MySQL (et tellement peu d'applications ont compris le referal qu'il faut faire faire au serveur le chaînage (alors que le client est nettement moins occupé et peut le faire (d'ailleurs je dois le faire pour lref)).
Donc oui la méthode 2 est la plus utilisée parce que c'est fait comme ça dans MySQL, mais maintenant je banni automatiquement ou corrige (si je peux) l'application. Quand je fait la remarque à un projet, on me dit que non https://linuxfr.org//comments/1107150.html#1107150
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell
[^] # Re: Pour ou contre
Posté par Etienne Bagnoud . En réponse au journal Références et LDAP. Évalué à 3.
Une chose est certaine : des applications codées avec les pieds au niveau de l'authentification, il y'en a. Comme j'ai compris ton problème, c'est le cas des applications qui s'authentifient et gèrent ça un peu comme une base de donnée sql. En fait c'est faux car, comme tu l'as si bien remarqué, ça contourne les ACL du serveur LDAP (qui sont, à mon avis, très puissantes (par expression régulière, demander un niveau d'algo de chiffrement minimum (en plus du classique utilisateurs/groupe) avec diverses niveaux (tu peux donner l'accès à un attribut uniquement à l'authentification, mais pas à la lecture, la comparaison et la recherche)).
Malheureusement j'ai trop souvent vu des applications qui demandent un utilisateur dédié et vont comparer le mot de passe directement en assumant que l'annuaire stocke celui-ci dans un format X (genre SSHA ou SHA ou MD5) ou pire qui vont modifier le mot de passe en écrivant directement l'attribut userPassword au lieu d'utiliser l'opération étendue disponible pour ça (et qui permet à l'annuaire de gérer d'autres champs, très utile pour avoir les mots de passe unifié entre Unix et Windows (samba et pam gère très bien le changement de mot de passe avec exop))
Le problème de LDAP c'est que du côté applicatif, beaucoup de gens n'ont pas compris et utilisent ça comme une base MySQL (et tellement peu d'applications ont compris le referal qu'il faut faire faire au serveur le chaînage (alors que le client est nettement moins occupé et peut le faire (d'ailleurs je dois le faire pour lref)).
Donc oui la méthode 2 est la plus utilisée parce que c'est fait comme ça dans MySQL, mais maintenant je banni automatiquement ou corrige (si je peux) l'application. Quand je fait la remarque à un projet, on me dit que non https://linuxfr.org//comments/1107150.html#1107150
"It was a bright cold day in April, and the clocks were striking thirteen" - Georges Orwell