On 05/20/2015 04:01 PM, Boyce, George Robert. (GSFC-762.0)[NICS] wrote:
> <<
> This worked for me:
> 
> $ ldapsearch -LLL -Y GSSAPI -b cn=users,cn=accounts,dc=example,dc=cm
> "(|(uid=admin)(name=admin))" dn
> SASL/GSSAPI authentication started
> SASL username: ad...@example.com
> SASL SSF: 56
> SASL data security layer installed.
> dn: uid=admin,cn=users,cn=accounts,dc=example,dc=com
> 
> Note that cn is Common Name which is set to the user's full name, in this 
> case likely "George Boyce". So that will never match gboyce.
> 
> Rob
>>>
> 
> Rob,
> 
> Thanks for your example, it had me test my ldap bind which narrows the 
> problem and gives me a workaround.
> 
> I used cn=gboyce to pull my group record, so I expected my test to return two 
> records for my account and my group. And it does when I authenticate as admin 
> as in your test. So the problem is isolated to when I use a dedicated search 
> account. I missed this note on setting up system accounts:
> 
> <<
> Note: IPA 4.0 is going to change the default stance on data from nearly 
> everything is readable to nothing is readable, by default. You will 
> eventually need to add some Access Control Instructions (ACI's) to grant read 
> access to the parts of the LDAP tree you will need.
>>>
> 
> Looks like I need to do just that. :-) 
> 
> 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.

> or returning one entry when each of the terms each returns a unique entry,
seems wrong.
> It does return two entries when both are in the same subtree.

This one sounds strange, CCing Ludwig for reference.

> 
> ###
> ### everything ok when using admin... two records, one from users, one from 
> groups
> ###
> # ldapsearch -Y GSSAPI -b "dc=..." "(|(uid=admin)(cn=gboyce))" dn
> SASL/GSSAPI authentication started
> SASL username: admin@...
> SASL SSF: 56
> SASL data security layer installed.
> # extended LDIF
> #
> # LDAPv3
> # base <dc=...> with scope subtree
> # filter: (|(uid=admin)(cn=gboyce))
> # requesting: dn
> #
> 
> # admin, users, accounts, ...
> dn: uid=admin,cn=users,cn=accounts,dc=...
> 
> # gboyce, groups, accounts, ...
> dn: cn=gboyce,cn=groups,cn=accounts,dc=...
> 
> # search result
> search: 4
> result: 0 Success
> 
> # numResponses: 3
> # numEntries: 2
> 
> ##########################################################################################
> 
> ###
> ### system account (without ACLs) returns simple queries, but not correct 
> results for compound queries in different subtrees
> ###
> 
> ###
> ### different subtrees fails...
> ###
> # ldapsearch -x  -D "uid=LDAPsearch,cn=sysaccounts,cn=etc,dc=..." -w "..." -b 
> "dc=..." "(|(uid=admin)(cn=gboyce))" dn                                       
>                                                                               
>               
> # extended LDIF
> #
> # LDAPv3
> # base <dc=...> with scope subtree
> # filter: (|(uid=admin)(cn=gboyce))
> # requesting: dn
> #
> 
> # admin, users, accounts, ...
> dn: uid=admin,cn=users,cn=accounts,dc=...
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 2
> # numEntries: 1
> 
> ###
> ### same subtree works...
> ###
> # l "(|(cn=admins)(cn=gboyce))" dn
> # extended LDIF
> #
> # LDAPv3
> # base <dc=...> with scope subtree
> # filter: (|(cn=admins)(cn=gboyce))
> # requesting: dn
> #
> 
> # admins, groups, accounts, ...
> dn: cn=admins,cn=groups,cn=accounts,dc=...
> 
> # gboyce, groups, accounts, ...
> dn: cn=gboyce,cn=groups,cn=accounts,dc=...
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 3
> # numEntries: 2
> 
> ###
> ### valid filter from above with extra false term...
> ###
> # l "(|(cn=admins)(cn=gboyce)(name=foobar))" dn
> # extended LDIF
> #
> # LDAPv3
> # base <dc=...> with scope subtree
> # filter: (|(cn=admins)(cn=gboyce)(name=foobar))
> # requesting: dn
> #
> 
> # search result
> search: 2
> result: 0 Success
> 
> # numResponses: 1
> 
> 

-- 
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

Reply via email to