[Date Prev][Date Next]
RE: Authentication using DN or uid? - RESOLVED
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.
From: Matthew J Backes [mailto:lucca@CSUN.EDU]
Sent: Friday, September 20, 2002 5:20 PM
To: Kristin Engstrom
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
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
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.
or change the search attribute to mail alias, cn, or potentially an
ORing of these fields:
So that you can let them in via any string uniquely identifying their
See RFC-2255 for the details on ldap URL formatting.