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.comcn: 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