Hide Forgot
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:
(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?
(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
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
Upstream ticket: https://fedorahosted.org/sssd/ticket/2383
master: dfb2960ab251f609466fa660449703835c97f99a b5242c146cc0ca96e2b898a74fb060efda15bc77 87ff519b472568b19809963ca860d2182e874fcd sssd-1-11: 842f9303f53b7d17214ed390203ed9e14203055a 641585186fdd6401451ed06b971ec8e3cee4d610 b7ce30e5889a42e64f1867db42400266ecaba9c9
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
Kaushik found out additional fix is needed. Moving to ASSIGNED.
(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.
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
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.
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)
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