Thanks! That's exactly what I was missing, looks like some default changed between OpenLDAP 2.3 and 2.4. I added the correct search permissions as you suggested and that got it working.
Darren
On 01/11/2010 2:02 PM, Jonathan Clarke wrote:
Le 01/11/2010 17:56, Darren Hildebrand a écrit :
I'm having a problem with access control lists in slapd.conf. The filter doesn't seem to be working in OpenLDPA 2.4.23 using syntax that worked in 2.3.43. I've simplified my tests down to a single ACL rule just to see if it's working, and this is what I'm finding:
I'm trying this ACL:
access to dn.subtree="ou=users,dc=companyname,dc=com" filter="(objectClass=person)" by * read
I tried an anonymous search using this command:
ldapsearch -h 1.2.3.4 -x -b ou=users,dc=companyname,dc=com
And it returned the following:
# search result search: 2 result: 32 No such object
I tried the same with the same ACL as above with the filter set to "(uid=*)", and got the same problem (note that all users have a uid value set). However, I tried with the filter set to "(objectClass=*), and it returned all users as I would expect.
Has anything changed with ACL syntax between OpenLDAP 2.3 and 2.4? Or do you see any problems with the syntax of my ACL line above?
Yes, from slapd.access(5):
The search operation, requires search (=s) privileges on theentry pseudo-attribute of the searchBase (NOTE: this was introduced with OpenLDAP 2.4). Then, for each entry, it requires search (=s) privileges on the attributes that are defined in the filter. The resulting entries are finally tested for read (=r) privileges on the pseudo-attribute entry (for read access to the entry itself) and for read (=r) access on each value of each attribute that is requested.
So you likely need something like this too: access to dn.base="ou=users,dc=companyname,dc=com" attrs="entry" by * search
However, I'm not entirely sure why you're allowed to do the search when using the "(objectClass=*)" filter, even though you don't have access to the above-mentioned entry pseudo-attribute...
Jonathan