Bonjour tout le monde,
Je tente d'installer une appli web qui, normalement, peut authentifier les utilisateurs sur un LDAP. Le problème est que cette appli ne fait pas de search avant le bind, il faut lui donner un mapping pour transformer le login en un DN valide (le bind étant ensuite fait avec ce DN et le mot de passe). Par exemple : uid=%u,dc=foo (%u est remplacé par le login de l'utilisateur).
Et comme le monde est bien fait, mes utilisateurs sont répartis dans plusieurs OU (ou=bar1,dc=foo ; ou=bar2,dc=foo ; etc.). C'est la que ça coince ... je ne peux configurer qu'une seule OU dans l'appli.
Je me demandais s'il était possible de configurer OpenLDAP pour d'abord faire un search avec le login envoyé par l'appli, puis faire un bind avec le DN trouvé et le mot de passe. Mais j'avoue que j'ai un peu de mal avec la conf de slapd et que je ne sais pas trop par où chercher ... entre SASL, authz-regexp et autre proxy_auth, je suis perdu.
J'aimerai bien que quelqu'un me dise : "Utilise , ça fait ce que tu veux !". Je me débrouille ensuite à chercher la doc de .
Merci.
# de ce que j'ai compris de LDAP
Posté par NeoX . Évalué à 2.
tous tes utilisateurs sont normalement dans dc=maboite,dc=com
ensuite les OU ce n'est qu'une methode de classement de tes utilisateurs, et ca permet ensuite de filtrer dans ton appli pour dire que tu veux seulement ou=compta,dc=maboite,dc=com
donc normalement avec uid=%u,dc=maboite,dc=com ca devrait marcher
ou alors j'ai raté un episode dans l'art de construire son ldap
[^] # Re: de ce que j'ai compris de LDAP
Posté par Cofequei . Évalué à 0.
Dans cette annuaire, j'ai des utilisateurs dans différentes branches :
- uid=user1,ou=siege,dc=example,dc=com
- uid=user2,ou=annexe1,dc=example,dc=com
- uid=user3,ou=annexe2,dc=example,dc=com
Je ne sais pas si c'est déconnant ou pas, mais c'est ce que j'ai.
Si je mets simplement uid=%u,dc=example,dc=com, ça va pas coller. Un bind avec le DN uid=user1,dc=example,dc=com ne fonctionnera pas car cet objet n'existe pas ... (le DN de user1 est uid=user1,ou=siege,dc=example,dc=com).
La plupart des applis que j'ai branchées sur LDAP permettent le search+bind. Ça permet de trouver le DN avant de faire le bind en se basant sur l'attribut uid (par exemple), ce truc est codée directement dans l'appli. Sauf cette appli ... et je cherche un moyen de contourner cette limitation.
[^] # Re: de ce que j'ai compris de LDAP
Posté par NeoX . Évalué à 2.
et avec les caracteres generiques ?
uid=%u,ou=*,dc=example,dc=com
note : ce n'est peut-etre pas * qu'il faut utiliser
[^] # Re: de ce que j'ai compris de LDAP
Posté par Cofequei . Évalué à -1.
Non, pas mieux ... il faudrait quand même réussir à faire passer la chaine résultante en tant que recherche. Avec le mécanisme actuel, la chaine avec le %u remplacé par le login est utilisée telle quelle en tant que DN pour faire le bind, donc on se retrouverait avec l'étoile (ou tout autre caractère générique).
Finalement, je pense avoir trouvé une truande pour faire à peu près un truc qui fonctionne (côté appli, donc très spécifique), mais la question reste ouverte ... pour la prochaine appli J2EE enterprise ready et disaïdor compliant !
Merci de ton aide en tout cas :)
[^] # Re: de ce que j'ai compris de LDAP
Posté par NeoX . Évalué à 4.
en meme temps c'est du coté de l'appli se faire le search+bind
si l'appli ne fait pas le search, alors il faut recoder ce morceau là. ;)
[^] # Re: de ce que j'ai compris de LDAP
Posté par xav38 . Évalué à 0.
Voici une recherche pour trouver tout les utilisateurs "toto" dans ton annuaire.
Après si il existe 1 utilisateur "toto" dans chaque branche, ton appli prendra le 1er renvoyé par ldapsearch et le bind ne marchera pas puisque le mot de passe ne correspondra pas forcément avec l'utilisateur associé.
Je pense que tu vas être obligé de recoder l'appli pour préciser dans quelle branche est ton utilisateur (sauf si tu es sûr qu'il n'existe qu'un seul utilisateur toto dans tout ton annuaire).
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.