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?
Thanks.
Darren
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 the entry 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
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
openldap-technical@openldap.org
-
Darren Hildebrand -
Jonathan Clarke