--On Thursday, September 5, 2019 10:35 AM +0200 Manuela Mandache manuela3mandache@gmail.com wrote:

Le mer. 4 sept. 2019 à 16:00, Quanah Gibson-Mount quanah@symas.com a écrit :

--On Wednesday, September 4, 2019 1:56 PM +0200 Manuela Mandache manuela3mandache@gmail.com wrote:

...

olcAccess: {0}to * by dn.base="cn=admin,cn=config" manage by dn.base="cn=adm  in,dc=example,dc=com" manage by * break olcAccess: {1}to dn.base="" by * read olcAccess: {2}to dn.base=cn=Subschema by * read olcAccess: {3}to dn.subtree="dc=example,dc=com" attrs=userPassword by * auth olcAccess: {4}to dn.subtree="dc=example,dc=com" attrs=entry by * read olcAccess: {5}to dn.subtree="dc=example,dc=com" attrs=cn,mail by * read olcAccess: {6}to * by anonymous none by * read

On what cn=config entry have you set these ACLs?

They're on olcDatabase={2}mdb,cn=config This is the DB containing the actual data of the directory, with olcSuffix: dc=example,dc=com

Given that, I would make the following notes:

a) rootDNs are never subject to ACLs, so the access for cn=admin,cn=config manage in {0} is suspect, as I would infer that is a rootdn.

b) ACL {1} is invalid for this database. It should be set in the dn: olcDatabase={-1}frontend,cn=config database

c) ACL {2} is invalid for this database. See solution listed in (b)

d) ACL {3} should only give auth access to anonymous, not *

e) ACLs 3-5 should be rewritten to drop the dn.subtree="dc=example,dc=com" bit entirely. You're already only setting ACLs for that database, no need to list that restriction. You can also combine ACLs 4 & 5.

olcAccess: {3} to attrs=userPassword by anonymous auth olcAccess: {4} to attrs=entry,cn,mail by * read olcAccess: {5} to * by anonymous none by * read

As for your question in general, I don't think you understand how ACLs work in relation to incoming search requests. The server did exactly what your ACLs said it should do: It provided no information when someone tried to search for data using an attribute that access is not granted to, and correctly returned 0 entries. It sounds as though you expected the connection to be dropped when the search was initiated because it was filtering off of sn. That is now how things work.

Regards, Quanah

--

Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com