2:47 a.m.
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
3:07 a.m.
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.
4:19 a.m.
On Tue, 23 Oct 2018 at 11:08, Michael Ströder <michael(a)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
4:32 a.m.
On 10/23/18 1:19 PM, Philip Colmer wrote:
On Tue, 23 Oct 2018 at 11:08, Michael Ströder
<michael(a)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.
5:21 a.m.
On Tue, 23 Oct 2018 at 12:32, Michael Ströder <michael(a)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
3:05 p.m.
Hi Philip,
--On Tuesday, October 23, 2018 2:21 PM +0100 Philip Colmer
<philip.colmer(a)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>
4:45 a.m.
New subject: Antw: Re: Permissions required to perform OU/DN filtering?
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(a)stroeder.com> schrieb am
23.10.2018 um 12:07 in
Nachricht
<155dbd7d-c3f4-fe5e-601e-c2e3d14d0805(a)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.
5:03 a.m.
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.
1616
days inactive
1616
days old
openldap-technical@openldap.org
7 comments
4 participants
participants (4)
-
Michael Ströder -
Philip Colmer -
Quanah Gibson-Mount -
Ulrich Windl