Re: [pamldap] A way around self write shadowLastChange?

["Pierangelo Masarati" <ando@sys-net.it>]

> The openldap group actually points this type of question to the padl or
> pam type groups because it is specific to authentication using pam.

If you know what access privileges the "shadowLastChange"
must have (that is, what operations a client that uses it
must be allowed to perform), then how to configure
slapd.conf is a(n often asked and answered) OpenLDAP
question.  If you're asking what privileges it should have,
then it's very likely that many readers of this list know
(I don't, sorry), but it's definitely a question for another
list.

>
> In looking at this solution I notice that it contradicts one thing I had
>  been told.  I believe I was told that a user or self must have write
> access to the password attribute and to the shadowLastChange attribute.
> Thus I have configured the following:
>
> access to dn=".*,MyDomain" attr=shadowLastChange
>         by dn="cn=Manager,MyDomain" write
>         by self write
>         by * read
>
> access to dn=".*,MyDomain" attr=userPassword
>         by dn="cn=Manager,MyDomain" write
>         by self write
>         by * read
>
> access to dn=".*,MyDomain"
>         by self write
>         by users auth
>         by * read

Assuming you're giving these attributes the right permissions,
then you can improve your above reported ACLs by writing

access to dn.subtree="MyDomain" attrs=shadowLastChange,userPassword
        by dn.exact="cn=Manager,MyDomain" write
        by self write
        by * read

access to dn.subtree="MyDomain"
        by self write
        by users auth
        by * read

The latter ACL definitely looks braindead (I hope you don't
get offended by this) because "users" (e.g. authenticated
people) can simply "auth", while "*" (e.g. authenticated as
well as non-authenticated people) can also "read".
Unfortunately, (or fortunately, it's a matter of points
of view) ACLs, and ACL "by" clauses, are evaluated in order,
so "users" will only get "auth" permission, while non-users
will get "read" permission, which is higher than "auth".

If "cn=Manager,MyDomain" is the "rootdn", then it implicitly
has "write" permission on the entire tree, so putting it
in ACLs simply slows slapd down when others than "rootdn"
are operating.

Most of these suggestions are clearly written, for instance,
at the end of slapd.access(5), in the "CAVEATS" section.

>
> Are you saying that perhaps I can replace the first stanza with the
> stanza  you provided below?
>
> access to attr=uidnumber,gidnumber,homeDirectory,shadowLastChange
>                  by * read
>                  by * compare
>                  by dn="LDAPManagerDN" write
>                  by dn="LDAPManagerDN" read

This ACL is waaay broken, because the "by * read" line itercepts
everybody, so the remaining three "by" clauses are never used.
Everybody gets to read the attributes, and nobody gets to write
them.  I presume the author will claim that he is able to write
them with "LDAPManagerDN"; then I infer "LDAPManagerDN" is the
"rootdn" in his slapd.conf.

p.

-- 
Pierangelo Masarati
mailto:pierangelo.masarati@sys-net.it