RE: Authentication using DN or uid? - RESOLVED

["Howard Chu" <hyc@highlandsun.com>]

Your question seemed to be two separate questions - how best to configure for
maximum interoperability with a variety of server products, and how to best
solve the problem. Configurable searches answers the first question, if you
don't know what features you can rely on. Using SASL is the best solution to
the problem - keep the issue of uid-to-DN mapping on the server, completely
away from clients. Authentication clients should not need to concern
themselves with the details of the security DIT. That is a matter solely for
the DIT administrator to deal with.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support

> -----Original Message-----
> From: owner-openldap-software@OpenLDAP.org
> [mailto:owner-openldap-software@OpenLDAP.org]On Behalf Of Kristin Engstrom

> Thanks for all your help, everyone.  I basically got the same
> answer from
> three people.  This approach had occurred to me, but I
> thought there might
> be a faster way (i.e., less than two separate queries) to
> authenticate that
> I had somehow overlooked.
>
> I'm satisfied that this is the way to go, and making the
> users' identifying
> attribute(s) configurable solves my other problem.
>
> Thanks again!
>
> Kristin
>
> -----Original Message-----
> From: Matthew J Backes [mailto:lucca@CSUN.EDU]
> Sent: Friday, September 20, 2002 5:20 PM
> To: Kristin Engstrom
> Cc: openldap-software@OpenLDAP.org
> Subject: Re: Authentication using DN or uid?
>
>
> On Fri, 20 Sep 2002 15:18:07 -0700
> Kristin Engstrom <Kristin.Engstrom@netiq.com> wrote:
>
> > Perhaps I'm misunderstanding the whole LDAP authentication
> model.  Has
> > anyone figured out how to use user-friendly usernames and
> still have their
> > front-end talk to a wide variety of directories (on
> different platforms)?
>
> It is unreasonable to assume an enduser knows their DN.  It is also
> unreasonable to assume that you may construct a DN by knowing the
> value of an attribute.  Many programs get that wrong and it makes life
> very difficult for people with complex DIT's.
>
> The Ideal situation is to have your software configurable; the user
> will enter some value referring to their identity and some value that
> authenticates their identity.  Make the attribute of the first value
> configurable.
>
> This assumes that you will be doing a search for their object.  Often
> this can be done anonymously, (and you should have an option for
> anonymous proxy binds) but frequently sites restrict things so that a
> "proxy user" will need to do the initial search.
>
> So.  You will want configuration details such as:
>
>     LDAP URL e.g.
> ldap://ldap.some.domain:389/ou=foo,o=mybase?sub?(uid=$UID)
>     Proxy User bind DN
>     Proxy User credentials
>
> So a typical session for a unix-like username/password login might
> look like:
>
>     Ask user for their username/password
>     Connect and BIND anonymously to the server in the URL
>     SEARCH on (uid=$UID), (where $UID would be what you are seeking)
>     if you get exactly ONE result back,
>     re-BIND to that dn with the supplied credentials.
>
> This way an administrator could reconfigure your client to bind
> non-anonymously for it's searches, search only part of the tree,
> require certain attributes to be present e.g.
>
>     (&(uid=foo)(objectclass=posixAccount))
>
> or change the search attribute to mail alias, cn, or potentially an
> ORing of these fields:
>
>     (|(uid=$val)(cn=$val)(mail=$val)(mailLocalAddress=$val))
>
> So that you can let them in via any string uniquely identifying their
> object.
>
> See RFC-2255 for the details on ldap URL formatting.
>
> Matthew Backes
> lucca@csun.edu
>
>