Re: Access Rights in SLAPD.CONF

[Hanasaki <hanasaki@microlink.net>]

How does the server know where to get the userid/pass to authenticate against?
Is there a specific schema that needs to be adhered to?

Keith Keller wrote:

> On 30 Apr, David J N Begley wrote:
>
> > What's actually the purpose of "by * compare"?  I mean, I'm using:
> >
> >   defaultaccess  read
> >   access         to attr=userpassword
> >                  by self write
> >                  by * none
> >
> > and authenticated binds to the directory still work without any problems.
>
> This is just a guess, but since authentication is done in order,
> if a user binds (or attempts to bind) as him/herself, then s/he
> falls under the "by self" scheme, and thus can bind successfully.
> It seems like a vicious circle, since to gain access to the
> userpassword, the user needs to authenticate, but in order to
> authenticate, the user needs access to the userpassword.  Presumably
> (?) the server knows to do a compare only until the compare actually
> matches, then knows to bind as that user and allow access to
> the userpassword.  But that's all pure speculation.
>
> > Unfortunately the UMich SLAPD Admin guide isn't too clear on distinguishing
> > the differences between "none", "compare", "search", "read" and "write"
> > (beyond the bleedin' obvious which no doubt leaves everything open to
> > interpretation - not good for ACLs).
>
> Dunno.  I feel like the definitions are clear enough, but not
> separate enough.  For example, giving "write" also gives "read",
> which gives "search", which gives "compare".  What if I want
> my users *only* to write and compare, not read?  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.
>
> On a side note, are there any plans for encrypted password
> support in OpenLDAP?  I feel this is important for the sanity
> of the end users--if their password is stored as plain text,
> then an administrator can go read it and then do evil things
> in their name.  Granted, the admin can change the password
> and do evil things anyway, but then at least theoretically
> there's some sort of record that there was a password change.
> And again, the current configuration does not allow passwords
> to be write-only, so giving an admin write (which s/he must
> have) also gives read to the userpassword (which s/he should
> not have).
>
> -- Keith
> kkeller@dspeed.net