Bug 1109188 - dereferencing control failure against openldap server
Summary: dereferencing control failure against openldap server
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: sssd
Version: 6.6
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Jakub Hrozek
QA Contact: Kaushik Banerjee
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-06-13 12:31 UTC by Kaushik Banerjee
Modified: 2014-10-14 04:48 UTC (History)
7 users (show)

Fixed In Version: sssd-1.11.6-12.el6
Doc Type: Bug Fix
Doc Text:
No Documentation Needed
Clone Of:
Environment:
Last Closed: 2014-10-14 04:48:40 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1375 normal SHIPPED_LIVE sssd bug fix and enhancement update 2014-10-14 01:06:25 UTC

Description Kaushik Banerjee 2014-06-13 12:31:09 UTC
Description of problem:
Unable to lookup groups with dereferencing control enabled on openldap server

Version-Release number of selected component (if applicable):
sssd-1.11.6-1.el6

How reproducible:
Always

Steps to Reproduce:
1. ldapsearch against the openldap server returns:

# ldapsearch -x -LLL -h <ldapserver> -b 'dc=example,dc=com' -D "cn=Manager,dc=example,dc=com" -w XXXXX -E 'deref=member:uid' cn=ref_grp1
dn: cn=ref_grp1,ou=qagroup,dc=example,dc=com
# member: <uid=drefuser1>;uid=drefuser1,dc=example,dc=com
# member: <uid=drefuser2>;uid=drefuser2,dc=example,dc=com
# member: <uid=drefuser3>;uid=drefuser3,dc=example,dc=com
# member: <uid=drefuser4>;uid=drefuser4,dc=example,dc=com
# member: <uid=drefuser5>;uid=drefuser5,dc=example,dc=com
# member: <uid=drefuser6>;uid=drefuser6,dc=example,dc=com
# member: <uid=drefuser7>;uid=drefuser7,dc=example,dc=com
# member: <uid=drefuser8>;uid=drefuser8,dc=example,dc=com
# member: <uid=drefuser9>;uid=drefuser9,dc=example,dc=com
# member: <uid=drefuser10>;uid=drefuser10,dc=example,dc=com
# member: <uid=drefuser11>;uid=drefuser11,dc=example,dc=com
# member: <uid=drefuser12>;uid=drefuser12,dc=example,dc=com

objectClass: extensibleObject
objectClass: groupOfNames
gidNumber: 10001
cn: ref_grp1
member: uid=drefuser1,dc=example,dc=com
member: uid=drefuser2,dc=example,dc=com
member: uid=drefuser3,dc=example,dc=com
member: uid=drefuser4,dc=example,dc=com
member: uid=drefuser5,dc=example,dc=com
member: uid=drefuser6,dc=example,dc=com
member: uid=drefuser7,dc=example,dc=com
member: uid=drefuser8,dc=example,dc=com
member: uid=drefuser9,dc=example,dc=com
member: uid=drefuser10,dc=example,dc=com
member: uid=drefuser11,dc=example,dc=com
member: uid=drefuser12,dc=example,dc=com


2. Configure sssd.conf with the following in domain section:
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
enumerate = FALSE
debug_level = 0xFFF0
ldap_uri = ldap://<ldapserver>
ldap_search_base = dc=example,dc=com
ldap_schema = rfc2307bis
ldap_group_object_class = groupOfNames

3. Lookup group ref_grp1
# getent group ref_grp1; echo $?
2

Actual results:
Lookup via sssd fails. Domain log shows:

(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0400): Search result: Protocol error(2), Dereference control: attribute decoding error
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding error
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_deref_search_done] (0x0040): dereference processing failed [5]: Input/output error
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_nested_group_deref_direct_done] (0x0020): Error processing direct membership [5]: Input/output error
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_nested_done] (0x0020): Nested group processing failed: [5][Input/output error]
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_id_op_done] (0x0200): communication error on cached connection, moving to next server
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_id_op_done] (0x4000): too many communication failures, giving up...
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_id_op_done] (0x4000): releasing operation connection
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_handle_release] (0x2000): Trace: sh[0x1025ae0], connected[1], ops[(nil)], ldap[0x1010a50], destructor_lock[0], release_memory[0]
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [remove_connection_callback] (0x4000): Successfully removed connection callback.
(Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,Group lookup failed

Expected results:
Group lookup should work

Additional info:

Comment 2 Lukas Slebodnik 2014-06-13 16:12:14 UTC
(In reply to Kaushik Banerjee from comment #0)
> (Fri Jun 13 08:18:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done]
> (0x0400): Search result: Protocol error(2), Dereference control: attribute
> decoding error

This error message is printed after calling the function ldap_parse_result from openldap. The returned error code from this function is LDAP_PROTOCOL_ERROR.
Do you have installed the same version of package openldap on server and client?

Comment 4 Kaushik Banerjee 2014-06-16 08:02:40 UTC
(In reply to Lukas Slebodnik from comment #2)
> Do you have installed the same version of package openldap on server and
> client?

On 6.6 client:
# rpm -q openldap
openldap-2.4.39-7.el6.x86_64

And, I am using rhel6.5 server

Comment 7 Lukas Slebodnik 2014-06-16 17:02:34 UTC
I can see the same behaviour with rhel6.5 client.
# service sssd start
[  OK  ] sssd: [  OK  ]

# rpm -q sssd openldap
sssd-1.9.2-129.el6.x86_64
openldap-2.4.23-32.el6_4.1.x86_64

# getent group ref_grp1
# echo $?
2

# grep "Dereference control" /var/log/sssd/sssd_LDAP.log 
(Mon Jun 16 12:58:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0400): Search result: Protocol error(2), Dereference control: attribute decoding error
(Mon Jun 16 12:58:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding error
(Mon Jun 16 12:58:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0400): Search result: Protocol error(2), Dereference control: attribute decoding error
(Mon Jun 16 12:58:53 2014) [sssd[be[LDAP]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding error

Comment 8 Dmitri Pal 2014-07-17 13:04:46 UTC
Upstream ticket:
https://fedorahosted.org/sssd/ticket/2383

Comment 9 Jakub Hrozek 2014-07-25 13:37:12 UTC
    master:
        dfb2960ab251f609466fa660449703835c97f99a
        b5242c146cc0ca96e2b898a74fb060efda15bc77
        87ff519b472568b19809963ca860d2182e874fcd 
    sssd-1-11:
        842f9303f53b7d17214ed390203ed9e14203055a
        641585186fdd6401451ed06b971ec8e3cee4d610
        b7ce30e5889a42e64f1867db42400266ecaba9c9

Comment 11 Kaushik Banerjee 2014-07-31 12:27:30 UTC
Dereferencing still fails against openldap. I see the following in hte domain log:

(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_has_deref_support] (0x0400): The server supports deref method OpenLDAP
(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_deref_search_send] (0x2000): Server supports OpenLDAP deref
(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_x_deref_search_send] (0x0400): Dereferencing entry [cn=ref_grp1,ou=qagroup,dc=example,dc=com] using OpenLDAP deref
(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed [95]: Operation not supported
(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_deref_search_done] (0x0040): dereference processing failed [95]: Operation not supported
(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_nested_group_deref_direct_done] (0x0020): Error processing direct membership [95]: Operation not supported
(Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_nested_group_process_done] (0x2000): Members of group [cn=ref_grp1,ou=qagroup,dc=example,dc=com] will be processed individually

Comment 15 Jakub Hrozek 2014-08-09 10:49:00 UTC
Kaushik found out additional fix is needed. Moving to ASSIGNED.

Comment 16 Lukas Slebodnik 2014-08-14 08:58:13 UTC
(In reply to Kaushik Banerjee from comment #11)
> Dereferencing still fails against openldap. I see the following in hte
> domain log:
> 
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_has_deref_support]
> (0x0400): The server supports deref method OpenLDAP
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_deref_search_send]
> (0x2000): Server supports OpenLDAP deref
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_x_deref_search_send]
> (0x0400): Dereferencing entry [cn=ref_grp1,ou=qagroup,dc=example,dc=com]
> using OpenLDAP deref
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_x_deref_search_done]
> (0x0100): sdap_get_generic_ext_recv failed [95]: Operation not supported
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_deref_search_done]
> (0x0040): dereference processing failed [95]: Operation not supported
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]]
> [sdap_nested_group_deref_direct_done] (0x0020): Error processing direct
> membership [95]: Operation not supported
> (Thu Jul 31 08:19:22 2014) [sssd[be[LDAP]]] [sdap_nested_group_process_done]
> (0x2000): Members of group [cn=ref_grp1,ou=qagroup,dc=example,dc=com] will
> be processed individually

After long discussion in upstream, we agreed it is an expected behaviour.
sssd returns correct result for group ref_grp1. There is just problem with old version of OpenLDAP server, which cannot handled critical flag for some supportedControls

The reason why the deref control is executed with critical flag is that we expect to get it back on reply, or it should fail and individual lookups should be performed on the group.

Comment 17 Lukas Slebodnik 2014-08-14 09:00:40 UTC
As you can see from following output, DEREF is supported by openldap server, but does not work with critical flag. 
 
sh-4.2$ ldapsearch -LLL -h 172.17.0.9 -x -b "" -s base supportedControl 
dn: 
supportedControl: 1.3.6.1.4.1.4203.666.5.16 
supportedControl: 2.16.840.1.113730.3.4.18 
supportedControl: 2.16.840.1.113730.3.4.2 
supportedControl: 1.3.6.1.4.1.4203.1.10.1 
supportedControl: 1.2.840.113556.1.4.319 
supportedControl: 1.2.826.0.1.3344810.2.3 
supportedControl: 1.3.6.1.1.13.2 
supportedControl: 1.3.6.1.1.13.1 
supportedControl: 1.3.6.1.1.12 
 
sh-4.2$ grep "1.3.6.1.4.1.4203.666.5.16" /usr/include/ldap.h 
#define LDAP_CONTROL_X_DEREF                    "1.3.6.1.4.1.4203.666.5.16" 
 
sh-4.2$ ldapsearch -x -LLL -h 172.17.0.9 -b 'dc=example,dc=com' -E '!deref=member:cn,uid' cn=ref_grp1 
+cn,uid 
Critical extension is unavailable (12) 
Additional information: critical control unavailable in context

#the same error message is in sssd log file.

 
sh-4.2$ ldapsearch -x -LLL -h 172.17.0.9 -b 'dc=example,dc=com' -E 'deref=member:cn,uid' cn=ref_grp1 
+cn,uid 
dn: cn=ref_grp1,ou=qagroup,dc=example,dc=com 
# member: <cn=Dref_User1>;<uid=drefuser1>;uid=drefuser1,dc=example,dc=com 
 
# member: <cn=Dref_User2>;<uid=drefuser2>;uid=drefuser2,dc=example,dc=com 
 
//snip 
 
sh-4.2$ echo $? 
0

Comment 18 Kaushik Banerjee 2014-08-14 09:07:29 UTC
Ok. In that case, fallback to individual lookup against old openldap server users is acceptable.
I'll also test with the newer openldap server.

Thanks, Lukas.

Comment 19 Kaushik Banerjee 2014-08-19 16:12:14 UTC
Verified with sssd version 1.11.6-20.el6

All memberof dereferencing tests pass against openldap-servers-2.4.39-8.el6(rhel6.6) and falls back to individual lookup against openldap-servers-2.4.23-32.el6_4.1(rhel6.5)

Comment 20 errata-xmlrpc 2014-10-14 04:48:40 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1375.html


Note You need to log in before you can comment on or make changes to this bug.