--On Tuesday, June 2, 2020 7:16 PM +0200 Jehan PROCACCIA jehan.procaccia@imtbs-tsp.eu wrote:
not sure it's the best practice , but here's the ACL I set on my provider
There are numerous issues with the ACL set you just provided. I definitely would not use it as a guide on how to do things.
olcAccess: {1}to dn.base="" by * read
This is an ACL that is meant to go into the frontend DB, not the primary DB.
olcAccess: {3}to dn.subtree="dc=mydomain,dc=fr" by dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * break
This ACL will never be used, since ACL{2} already covers your entire tree.
olcAccess: {4}to attrs=userPassword,shadowLastChange by self write by anonymous auth by dn.exact="cn=repuser,ou=dsa,dc=mydomain,dc=fr" read by * none
Same as #3.
olcAccess: {5}to * by self read by * none
Same as #3.
In practice, you only have two functioning ACLs with what you provided:
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break olcAccess: {2}to dn.base="dc=mydomain,dc=fr" by * read
Probably most critical, you've given everyone, including anonymous, read access to the userPassword attribute of every account in your tree.
Regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com