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