On 09/12/2011 07:15 AM, sim123 wrote:
On Sun, Sep 11, 2011 at 9:46 PM, sim123<[email protected]> wrote:
On Fri, Sep 9, 2011 at 11:57 AM, sim123<[email protected]> wrote:
Hi All,
I want third party applications to authenticate against my ldap using any
attribute (specially mail& password) is it possible to do a bind using any
attribute with/without RDN rather then DN? For example my LDAP user looks
like this :
dn: uid=1,ou=users,dc=example,dc=local
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top
cn: Josh
sn: Cho
mail: [email protected]
uid: 1
userPassword: joshcho
I can bind to ldap if I use DN& password but I can not bind to ldap if I
use any attribute like
[email protected],ou=users,dc=example,dc,local& password
Would greatly appreciate any help.
Thanks
*simon*
I was wondering if someone can help me with this issue?
Thanks for the help and support.
Well, while browsing for solution I realized that I was misinterpreting
RDN, so basically what I want is any third party application to authenticate
against my ldap using attributes other then DN, I guess its the job of
application to do a search for DN and then do a bind, am I correct? Does
anyone experienced similar problem while integrating with third party
applications like Nagios/ Forum/ Confluence softwares? As I said earlier my
DN contains uid field instead of any modifiable attribute, however end users
won't know the DN they would only know email/ cn. Is it safe to assume that
usually third party applications have lookup and bind option so they can
search for DN and then do the bind? Or I am going into wrong direction.
I don't know much about SASL bind but would that help solving this issue
rather then simple bind? I would greatly appreciate any help on this issue.
As soon as the request comes in in a form that complies with DN syntax,
you may have a look at slapo-rwm(5); there should be an example exactly
about resolving bind requests as "mail=<address>" into the DN of the
corresponding entry.
Otherwise, yes, SASL is the right way to go, provided your client can do
a SASL bind. In that case, what attribute is used as the ID may depend
on the SASL mech of choice.
p.
