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

Re: RFC2256: userPassword



Well there have been so many message with this subject I
just had to put put two and 1/2 cents in. :)

There seems to be two different situations for
authenticating
a user using the LDAP server. The conversation threads
haven't
seemed to out right define which one is being discussed.

1) Verify access to the LDAP server by calling ldap_bind()
or
some form of.
2) When a third party application (such as an accounting
system)
performs an authentication procedure before a user can
access
its data. The accounting system may want to verify a users
login
via the LDAP server.

Solutions:
2a) call ldap_bind() with the users DN and password then
allow access to the accounting function when the bind
succeeds.
( Not my favorite choice. )
2b) The LDAP server contains the accounting password that is
in an attribute other than userPassword.
2c) The LDAP server administrator provides the accounting
system (as a trusted system) with its own DN/password with
enough access rights to verify the accounting user's
password.
It is my assumption that the accounting system would call
ldap_compare() with what ever form the password would need
to
be in.

It seems that previous discussions have to do with what form
to pass the password/credentials. For client systems that do
not
know the form that a particular LDAP server expects then how 
does the client system discover the password form. An all
with
out compromising security.

Am I on the right track her?
JR


Robert Allen wrote:
> 
> One might argue that a user should know their format, rather than
> allowing users to read their password in order to figure out the
> format, as a security point.  If this level of complexity isn't
> acceptable to a user base then it should perhaps be left to the
> group which maintains the directory to write web interfaces, etc.,
> which take care of the decoration choice.
> 
> Robert Allen
> rja@Eng.Sun.COM
> 
> >>Your decorated hash values don't do the client any good if he only
> >>has Compare access and not Read access - how does the client find out
> >>which hash is in use? It seems to me that client-side validation is
> >>really precluded here.

-- 
-
J. R. Heisey