Further testing confirms that the filter for the ACL is not being applied correctly when rwm is used. Turning the rewriteEngine off has no effect. All lines referring to rwm must be commented.
Interestingly, performing the query without specifying any attribute succeeds. All allowed attributes are returned.
ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)"
# extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: ALL #
# 2, accounts, cune dn: qmailUID=2,ou=accounts,o=cune objectClass: pilotPerson objectClass: qmailUser objectClass: PureFTPdUser cn: Test Entry sn: Entry uid: Test.Entry accountStatus: active mail: test.entry@cune.org userClass: stu
# search result search: 2 result: 0 Success
Specifying an allowed attribute or no attributes (1.1) causes the query to fail. For example,
ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" cn
ldapsearch -D "qmailGID=306,ou=accounts,o=cune" -w password \ -E 2.16.840.1.113730.3.4.2 -b "ou=accounts,o=cune" "(uid=Test.Entry)" 1.1
# extended LDIF # # LDAPv3 # base <ou=accounts,o=cune> with scope subtree # filter: (uid=Test.Entry) # requesting: cn #
# search result search: 2 result: 32 No such object
# numResponses: 1
Removing the filter from the ACL allows the query to succeed.
access to dn.subtree="ou=accounts,o=cune" attrs=cn,entry,mail,objectClass,sn,uid,userClass,accountStatus by dn="qmailGID=306,ou=accounts,o=cune" read by peername.ip=127.0.0.0%255.255.255.0 read by peername.ip=10.0.0.0%255.255.192.0 read by * none
In summary, slapd is unable to apply the filter for an ACL correctly when rwm is being used and an attribute (or no attributes) is specified with the query.