Bug 1109188
| Summary: | dereferencing control failure against openldap server | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 6 | Reporter: | Kaushik Banerjee <kbanerje> |
| Component: | sssd | Assignee: | Jakub Hrozek <jhrozek> |
| Status: | CLOSED ERRATA | QA Contact: | Kaushik Banerjee <kbanerje> |
| Severity: | unspecified | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 6.6 | CC: | dpal, grajaiya, jgalipea, lslebodn, mkosek, pbrezina, preichl |
| Target Milestone: | rc | ||
| Target Release: | --- | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | sssd-1.11.6-12.el6 | Doc Type: | Bug Fix |
| Doc Text: |
No Documentation Needed
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-10-14 04:48:40 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Kaushik Banerjee
2014-06-13 12:31:09 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? (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 |