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: [email protected] > 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
