Knowing that the first issue is 'working as designed', I can now focus on exactly how to fix it. In my case, the issue is that a vendor's code is appending "name=..." to its search filter to find a user group.
Thanks, I can troubleshoot the second issue, it isn't a roadblock to my task. On 05/21/2015 07:50 AM, Martin Kosek wrote: > On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote: >> Still the behavior of returning nothing by adding an extra false >> term, > IIRC, this is done on purpose, there was an CVE and as a fix, if you > are querying with an attribute you do not have permission to query > with, you get no answers. correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508 and behaviour matches the spec in 188.8.131.52: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions For the other problem, there is not enough information to judge. If two entries are in different subtrees also different acis could apply, we need the full set of acis, the full search and eventuallay access control logging (nsslapd-errorlog-level: 128) -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project