On 05/21/2015 07:50 AM, Martin Kosek wrote:
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.
correct. It was https://bugzilla.redhat.com/show_bug.cgi?id=979508
and behaviour matches the spec in 13.3.3.3:
https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Access_Control-Creating_ACIs_Manually.html#Creating_ACIs_Manually-Defining_Permissions
For the other problem, there is not enough information to judge. If two
entries are in different subtrees also different acis could apply, we
need the full set of acis, the full search and eventuallay access
control logging (nsslapd-errorlog-level: 128)
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
