[Freeipa-users] confused by ldapsearch results

[Boyce, George Robert. (GSFC-762.0)[NICS]]

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

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