Re: Access Rights in SLAPD.CONF

[David J N Begley <david@avarice.nepean.uws.edu.au>]

On Sat, 1 May 1999, patl@phoenix.volant.org wrote:

> > Which brings me back to my original question - what's the purpose of "by *
> > compare"?  I mean, under what example circumstances might it be needed?
> 
> The most obvious use is password checking without exposing the (encrypted)
> passwords.

In what circumstances would "other" users need to check someone's password?
"Self" needs to be able to change their password which means (as previously
mentioned) it's unfortunate that "write" also exposes the password to "read"
access..

> > Now, attributes like "write", "read" and "none" are pretty obvious, but
> > what's the difference between "search" and "compare"?
> 
> I believe that ompare is roughly equivalent to allowing exact match
> searches while denying substring, inequality, presence, etc.

This is the sort of stuff that needs to be explicitly mentioned in the admin
guide.  :-)

> > > This makes lots of sense with passwords, where you wouldn't want your
> > > users to be able to display their password on screen, but you still
> > > want them to be able to change passwords.
> 
> Why shouldn't you be able to see your own (encrypted) password?

Depends on the local security policy;  for example, if it is possible for
someone to sniff traffic to/from/at the user's end, they may be able to take
the encrypted password string and run it through a brute-force cracker -
without the string, they can't do anything.

Also, not all systems permit/allow encrypted passwords yet (Novell NetWare's
NLDAP/NDS doesn't appear to support Unix-style encryption so in order to
"share" passwords they need to be stored in cleartext), so you don't want the
cleartext to accidentally (or on purpose) appear on a screen where it can be
seen by a third-party.

Of course some of these things can be worked around with SSL and/or SASL
methods but as I mentioned above, it depends on the local security policy.

> And if my users are stupid enough to -want- to display their passwords
> on-screen, there's not much I can do to stop them.

Sure - but you can limit the chances of it being exposed accidentally;  it all
comes down to whether the user or the "organisation" feels more threatened by
passwords leaking and people authenticating themselves fraudulently.

> > Exactly!  This is similar to how Novell's NLDAP front-end to NDS works (as
> > a user I can set my own password and I can authenticate using my password,
> > but I still can't retrieve the userPassword attribute at all).
> 
> This could easily be an NDS restriction.  If the LDAP<->NDS gateway
> can't retrieve the password, it can't pass it on.

As far as I can see, NDS itself has no "password" attribute (ironically, it
does have a "previously used passwords" attribute!) and that's essentially why
no "userPassword" attribute appears through the NLDAP interface;  either way,
it's an example of an LDAP server that is able to implement that particular
security policy (can use/set password, can't see it).

> (Of course, it would only return your own entry, since you presumably only
> have 'compare' access against the others.) 

As an authenticated user, you can't see your own password.

Cheers..


dave