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.

On Mon, Sep 12, 2011 at 7:24 AM, Marc Patermann < hans.moser@ofd-z.niedersachsen.de> wrote:

Hi,

sim123 schrieb (12.09.2011 07:15 Uhr):

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?

Nowadays most of the applications that claim to have "ldap support" for authentication work with non-rdn values by searching for the corresponding DN first and bind with this later. Every other application which only uses auth with the rdn (by combining the rd with the given base to an DN) is very poorly designed and should be avoided. (IMHO)

Marc

Thanks Marc for the verification. So my assumption was correct and instead of doing things at ldap server level, I modified Nagios component to do the right thing.

I appreciate the help I get from this mailing list.