Hi,
I have these ACLs in place:
olcAccess: {0}to dn.base="dc=teckids,dc=org" by group.exact="cn=ldapadmin,ou=Groups,dc=teckids,dc=org" manage by dn="cn=admin,dc=teckids,dc=org" manage by self read continue by * auth break olcAccess: {1}to dn.base="ou=Mailinglists,dc=teckids,dc=org" by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" read continue by * break olcAccess: {2}to attrs=userPassword,shadowLastChange,loginShell by self write continue by anonymous auth continue by * break olcAccess: {3}to dn.subtree="ou=People,dc=teckids,dc=org" attrs=cn,uid,loginShell,homeDirectory,uidNumber,gidNumber,gecos by dn="cn=nslcd,dc=teckids,dc=org" read continue by * break olcAccess: {4}to dn.subtree="ou=People,dc=teckids,dc=org" attrs=uid,mailLocalAddress,mailRoutingAddress by dn="cn=postfix,dc=teckids,dc=org" read continue by * break olcAccess: {5}to dn.subtree="ou=Members,ou=People,dc=teckids,dc=org" attrs=employeeNumber by dn.subtree="ou=Board,ou=Members,ou=People,dc=teckids,dc=org" read continue by * none stop olcAccess: {6}to dn.subtree="ou=Members,ou=People,dc=teckids,dc=org" by dn.subtree="ou=Members,ou=People,dc=teckids,dc=org" read continue by * break olcAccess: {7}to dn.subtree="ou=Groups,dc=teckids,dc=org" by dn="cn=nslcd,dc=teckids,dc=org" read continue by * break olcAccess: {8}to dn.subtree="ou=Domains,dc=teckids,dc=org" by dn="cn=postfix,dc=teckids,dc=org" read continue by * break olcAccess: {9}to attrs=cn,uid,userPassword by * auth break
But still, even a simple bind fails because it somehow does not get the auth privileges defined in the first stanza.
The ACL log says: http://paste.ubuntu.com/7544324/
What did I miss?
Cheers, Nik
Huh,
But still, even a simple bind fails because it somehow does not get the auth privileges defined in the first stanza.
now this is exciting:
Testing with slapacl shows that my ACLs are, in fact, alright. But still they do not match when asked. For example:
# slapacl -v -b cn=nslcd,dc=teckids,dc=org entry: =rscxd […]
This pretty much tells me: what you are alowed to do here is "read", right?
But:
# slapacl -v -b cn=nslcd,dc=teckids,dc=org entry/read read access to entry: DENIED
Now this strikes me as odd… isn't it supposed to return success here?
That happens for each and every field in my directory…
For me this looks like a bug, but maybe I am doing somwthing entirely wrong?
-nik
Hello Dominik,
On 29.05.2014 20:14, Dominik George wrote:
# slapacl -v -b cn=nslcd,dc=teckids,dc=org entry/read read access to entry: DENIED
For me this looks like a bug, but maybe I am doing somwthing entirely wrong?
Look close: Read access to "entry" denied.
The ACLs you posted don't allow access to the "entry" pseudo attribute: ====8<====8<====8<====8<==== There are two special pseudo attributes "entry" and "children". To read (and hence return) a target entry, the subject must have read access to the target's "entry" attribute. [...] The complete examples at the end of this section should help clear things up. ====8<====8<====8<====8<==== http://www.openldap.org/doc/admin24/access-control.html
kind regards,
Christian Marg
openldap-technical@openldap.org
-
Christian Marg -
Dominik George