[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: RFC2256: userPassword
JR Heisey wrote:
>
> 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. )
I think its the best solution also if it is not your favorite
one. Our servers have a default configuration where nobody
is allowed to make a compare or a search to a User-Password. You
can only verify it by a bind.
> 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
begin:vcard
n:Volpers;Helmut
tel;fax:+49-89-63645860
tel;home:+49-89-1576588
tel;work:+49-89-63646713
x-mozilla-html:FALSE
url:http://www.siemens.com/bus-com/
adr:;;Otto-Hahn-Ring 6;Munich;;81730;Germany
version:2.1
email;internet:Helmut.Volpers@icn.siemens.de
title:Directory Server Architect
x-mozilla-cpt:;30160
fn:Volpers, Helmut
end:vcard