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