On 09/12/2011 07:15 AM, sim123 wrote:
On Sun, Sep 11, 2011 at 9:46 PM, sim123Sim3159@gmail.com wrote:
On Fri, Sep 9, 2011 at 11:57 AM, sim123Sim3159@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.
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.