[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: Bind with attribute + RDN instead of DN

On 09/12/2011 07:15 AM, sim123 wrote:
On Sun, Sep 11, 2011 at 9:46 PM, sim123<Sim3159@gmail.com>  wrote:

On Fri, Sep 9, 2011 at 11:57 AM, sim123<Sim3159@gmail.com>  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: joshcho@example.com

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

mail=joshcho@example.com,ou=users,dc=example,dc,local&  password

Would greatly appreciate any help.


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.