[Date Prev][Date Next]
Re: Access Rights in SLAPD.CONF
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