Hello all,

My previous email address doesn't seem able to communicate with the list anymore... I sent this question yesterday and I don't find it in the September list of submitted subjects - sorry if I got it wrong and I'm double-posting.

On an OpenLDAP directory, the ACLs are

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

For the requests, the behavior is the expected one from user's point of view :

$ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'cn=Name*'
dn: uid=someuid,ou=people,dc=example,dc=com
mail: FirstName.Name@domain.com
cn: Name FirstName

$ ldapsearch -LLL -x -H ldap://myServer:390 -b ou=people,dc=example,dc=com 'sn=Name'

Checking the log, the first requests appears as

2019-09-03T14:22:17.537815+02:00 myServer slapd[4765]: conn=1141654 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55188 (IP=0.0.0.0:390)
2019-09-03T14:22:17.538004+02:00 myServer slapd[4765]: conn=1141654 op=0 BIND dn="" method=128
2019-09-03T14:22:17.538044+02:00 myServer slapd[4765]: conn=1141654 op=0 RESULT tag=97 err=0 text=
2019-09-03T14:22:17.546713+02:00 myServer slapd[4765]: conn=1141654 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(cn=Name*)"
2019-09-03T14:22:17.550421+02:00 myServer slapd[4765]: conn=1141654 op=1 SEARCH RESULT tag=101 err=0 nentries=1 text=
2019-09-03T14:22:17.562783+02:00 myServer slapd[4765]: conn=1141654 op=2 UNBIND
2019-09-03T14:22:17.562835+02:00 myServer slapd[4765]: conn=1141654 fd=13 closed

which is once again the expected behavior.

But the second request generates in the log

2019-09-03T14:22:04.293120+02:00 myServer slapd[4765]: conn=1141645 fd=13 ACCEPT from IP=xxx.xxx.xxx.xxx:55186 (IP=0.0.0.0:390)
2019-09-03T14:22:04.293262+02:00 myServer slapd[4765]: conn=1141645 op=0 BIND dn="" method=128
2019-09-03T14:22:04.293328+02:00 myServer slapd[4765]: conn=1141645 op=0 RESULT tag=97 err=0 text=
2019-09-03T14:22:04.302404+02:00 myServer slapd[4765]: conn=1141645 op=1 SRCH base="ou=people,dc=example,dc=com" scope=2 deref=0 filter="(sn=Name)"
2019-09-03T14:22:04.304850+02:00 myServer slapd[4765]: <= mdb_equality_candidates: (sn) not indexed
2019-09-03T14:22:04.334020+02:00 myServer slapd[4765]: conn=1141645 op=1 SEARCH RESULT tag=101 err=0 nentries=0 text=
2019-09-03T14:22:04.342618+02:00 myServer slapd[4765]: conn=1141645 op=2 UNBIND

It actually looks as if the search was performed first, and the ACLs were checked only afterwards to prevent any return.

As sn is not supposed to be used in the filter, it is not indexed (but we have no control over the requests sent to the directory to prevent the use of unauthorized filters).

Am I misreading the log? And if I'm not, is there some parameter to be set to block the actual search on unauthorized filters?

Thank you, and please let me know if I need to supply more configuration information.

Regards,

Manuela