[Freeipa-users] confused by ldapsearch results

[Martin Kosek]

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: admin at 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 at ...
> 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
> 
>