I'm trying to use the following search filter:
(&(objectClass=organizationalPerson)(!(ou:dn:=external-community))(memberOf=cn=users,ou=mailing,ou=groups,dc=linaro,dc=org))
If I use an admin account, the search works. If I use a restricted account, the search doesn't work. The restricted account is only allowed to retrieve a subset of attributes, e.g.:
add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=organizationalUnit) attrs=entry,description,organizationalStatus,mail,jpegPhoto,@organizationalUnit by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read
add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=inetOrgPerson) attrs=businessCategory,jpegPhoto,labeledURI,roomNumber,modifyTimestamp,employeeNumber,memberOf by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read
(That is only a snippet of our configuration)
What do I need to grant read access to in order to get the search filter to work with restricted accounts?
Thanks.
Philip
On 10/23/18 11:47 AM, Philip Colmer wrote:
I'm trying to use the following search filter:
(&(objectClass=organizationalPerson)(!(ou:dn:=external-community)) (memberOf=cn=users,ou=mailing,ou=groups,dc=linaro,dc=org))> If I use an admin account, the search works. If I use a restricted account, the search doesn't work.
Summary: You have to grant search privilege to all attributes used in the filter and read access to pseudo-attribute 'entry' and all other attributes to be returned in search results.
The restricted account is only allowed to retrieve a subset of attributes, e.g.:
add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=organizationalUnit) attrs=entry,description,organizationalStatus,mail,jpegPhoto,@organizationalUnit by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read
add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=inetOrgPerson) attrs=businessCategory,jpegPhoto,labeledURI,roomNumber,modifyTimestamp,employeeNumber,memberOf by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read
Attribute 'entry' is missing here?
Ciao, Michael.
On Tue, 23 Oct 2018 at 11:08, Michael Ströder michael@stroeder.com wrote:
Summary: You have to grant search privilege to all attributes used in the filter and read access to pseudo-attribute 'entry' and all other attributes to be returned in search results.
Attribute 'entry' is missing here?
Ciao, Michael.
It is, but adding it hasn't fixed the problem, I'm afraid.
For "ou:dn:=external-community" to work, what is the search actually looking at? I tried adding "dn" to the list of attributes to be readable but that then failed to import as a valid configuration.
Regards
Philip
On 10/23/18 1:19 PM, Philip Colmer wrote:
On Tue, 23 Oct 2018 at 11:08, Michael Ströder michael@stroeder.com wrote:
Summary: You have to grant search privilege to all attributes used in the filter and read access to pseudo-attribute 'entry' and all other attributes to be returned in search results.
Attribute 'entry' is missing here?
It is, but adding it hasn't fixed the problem, I'm afraid.
For "ou:dn:=external-community" to work, what is the search actually looking at? I tried adding "dn" to the list of attributes to be readable but that then failed to import as a valid configuration.
You would rather have to grant search access to 'entryDN'.
But sorry, I will not debug your ACLs. You can start slapd with debug level for ACL debuggging.
Example:
slapd -h ... -d stats,acl
This will give you many log lines with details which permission is requested for which entry and attribute.
Ciao, Michael.
On Tue, 23 Oct 2018 at 12:32, Michael Ströder michael@stroeder.com wrote:
You would rather have to grant search access to 'entryDN'.
But sorry, I will not debug your ACLs.
I'm not asking you to debug them.
I was hoping that someone on this list would *know* what access I need to grant in order for "ou:dn" to work.
Yes, I can run slapd in debug mode but this is a production system so that means scheduling a maintenance window in several weeks' time. I was rather hoping to have a solution in place sooner than that thanks to the kind support of this list but, if I don't have it, I'll figure it out for myself.
Philip
Hi Philip,
--On Tuesday, October 23, 2018 2:21 PM +0100 Philip Colmer philip.colmer@linaro.org wrote:
Yes, I can run slapd in debug mode but this is a production system so that means scheduling a maintenance window in several weeks' time. I was rather hoping to have a solution in place sooner than that thanks to the kind support of this list but, if I don't have it, I'll figure it out for myself.
I don't know the answer off the top of my head, but I would imagine you could set up a test/dev server fairly quickly to figure this out? Should be pretty straight forward. If you have the cn=config database enabled, you could change the loglevel to ACL on the fly (just to note).
Warm regards, Quanah
--
Quanah Gibson-Mount Product Architect Symas Corporation Packaged, certified, and supported LDAP solutions powered by OpenLDAP: http://www.symas.com
Hi!
A related interesting question: Are the ACL permissions for attributes needed to do the actual matching of entries, or are they only used to add the attributes of the matched entries to the result set? I was wondering what "entry" actually is, and I imagine if LDAP search could return the count of matching entries only (i.e. no attributes at all), that could be relevant....
Regards, Ulrich
Michael Ströder michael@stroeder.com schrieb am 23.10.2018 um 12:07 in
Nachricht 155dbd7d-c3f4-fe5e-601e-c2e3d14d0805@stroeder.com:
On 10/23/18 11:47 AM, Philip Colmer wrote:
I'm trying to use the following search filter:
(&(objectClass=organizationalPerson)(!(ou:dn:=external-community)) (memberOf=cn=users,ou=mailing,ou=groups,dc=linaro,dc=org))> If I use an admin account, the search works. If I use a restricted account, the search doesn't work.
Summary: You have to grant search privilege to all attributes used in the filter and read access to pseudo-attribute 'entry' and all other attributes to be returned in search results.
The restricted account is only allowed to retrieve a subset of attributes, e.g.:
add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=organizationalUnit)
attrs=entry,description,organizationalStatus,mail,jpegPhoto,@organizationalUn
it
by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read
add: olcAccess olcAccess: to dn.children="dc=linaro,dc=org" filter=(objectClass=inetOrgPerson)
attrs=businessCategory,jpegPhoto,labeledURI,roomNumber,modifyTimestamp,employ
eeNumber,memberOf
by group="cn=binder-group,ou=binders,dc=linaro,dc=org" read
Attribute 'entry' is missing here?
Ciao, Michael.
On 10/23/18 1:45 PM, Ulrich Windl wrote:
A related interesting question: Are the ACL permissions for attributes needed to do the actual matching of entries, or are they only used to add the attributes of the matched entries to the result set?
ACLs also affect the matching.
E.g. in Æ-DIR I have ACLs with val.regex only allowing read access to those memberOf values pointing to group entries explicitly made visible for a system.
I was wondering what "entry" actually is,
My own definition: If read access is granted to 'entry' the entry's DN will be returned in the search result. Which is not quite the same like granting read access to 'entryDN'.
and I imagine if LDAP search could return the count of matching entries only (i.e. no attributes at all), that could be relevant....
Try yourself with the no-op search control.
Ciao, Michael.
openldap-technical@openldap.org
-
Michael Ströder -
Philip Colmer -
Quanah Gibson-Mount -
Ulrich Windl