Re: Access Rights in SLAPD.CONF

[patl@phoenix.volant.org]

> > 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..

How about when the 'other user' isn't really a user at all?  For example,
an IMAP daemon might use LDAP for authentication.  Instead of attempting
to bind to the LDAP server as the end user being authenticated, it might
have it's own entry, with appropriate access restrictions.

> > 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.  :-)

Absolutely.  The Admin Guide needs to go into much more detail about
how the access controls work.  Not only to explain exactly what is
possible at each level; but also to clarify how the rule matching
works when 'filter' and 'attrs' keywords are present.

> > 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.

Strong encryption and password aging should eliminate that as a
practical worry.  Although, I'd really like to see SSL/TLS support
in slapd.  (I know, external gateways can be used.  But that doesn't
make it possible for the LDAP server to authenticate based on client
certificates.)

If sniffing is a problem, then you should also have to worry about
an LDAP connection being hijacked by spoofed packets after the
authentication is complete.  In which case, it doesn't matter that
the Bad Guys couldn't get at the password.  (Something else that
SSL/TLS would prevent.)

> 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.

That's a problem with NLDAP/NDS.  Complain to Novell.



-Pat