[SSSD-users] attribute decoding error is breaking LDAP integration

Jakub Hrozek jhrozek at redhat.com
Wed Feb 20 20:41:41 UTC 2013


On Wed, Feb 20, 2013 at 08:56:10AM -0800, Scott Classen wrote:
> 
> Well I got SSSD and LDAP working so I thought I'd post something here for posterity's sake.
> 
> 
> On Feb 19, 2013, at 5:22 PM, Dmitri Pal wrote:
> 
> > On 02/19/2013 05:01 PM, Scott Classen wrote:
> >> Hello,
> >> 
> >> sssd appears to bind successfully, but when it tries to fetch user information id balks. Here is a snippit from the log file immediately after the successful bind.
> >> 
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [simple_bind_done] (0x0080): Bind result: Success(0), no errmsg set
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'mymachine' as 'working'
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [set_server_common_status] (0x0100): Marking server 'mymachine' as 'working'
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_get_generic_ext_done] (0x0040): Unexpected result from ldap: Protocol error(2), Dereference control: attribute decoding error
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed [5]: Input/output error
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_deref_search_done] (0x0040): dereference processing failed [5]: Input/output error
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [sdap_nested_done] (0x0020): Nested group processing failed: [5][Input/output error]
> >> (Tue Feb 19 13:49:14 2013) [sssd[be[SIBYLS]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,5,Group lookup failed
> >> (Tue Feb 19 13:49:14 2013) [sssd[nss]] [nss_cmd_getgrgid_dp_callback] (0x0040): Unable to get information from Data Provider
> >> Error: 3, 5, Group lookup failed
> >> Will try to return what we have in cache
> >> 
> >> 
> >> ldpasearch works fine:
> >> 
> >> ldapsearch -x -D "uid=nss,dc=mydomain" -b "dc=mydomain" -w secret "cn=somegroupname" -LL
> >> 
> >> and produces copious information about all the members of "somegroupname"
> >> 
> >> 
> >> this is causing a major headache as a simple ls -l will hang the system.
> >> 
> > 
> > What is the version of SSSD and what kind of directory it uses?
> 
> 
> SSSD version 1.8.0 as distributed through CentOS 6.
> OpenLDAP version 2.4.32 built from source
> 
> 
> > It seems, based on the error message, that LDAP server supplies a deref control that SSSD fails to parse. Is there something special in your LDAP server or something changed recently?
> 
> Nothing has changed with the OpenLDAP server. We do have some special schemas, but I don't think that is the problem
> 
> > LDAP search might work OK because it does not try to process the control.
> > 
> > Is this an issue that suddenly started to happen or it just does not work out of box?
> > In either cases the reason for this is most likely on the server side.
> > Is there any way to get more info from the server side about what kind of control was actually sent?
> 
> 
> So the solution was to add the following line to my sssd.conf file
> 
> enumerate = true
> 
> That's it.
> 
> Everything works now.
> 
> id username returns useful information.
> getent works.
> ls -l works.
> 
> Not exactly sure why enumerate = true would fix my problem? I would expect that the underlying mechanism used to gather user/group information from OpenLDAP would be the same regardless of whether enumeration is turned on or off. My understanding from reading the sssd documentation is that enumeration merely caches the user/group information locally. There must be something else going on that is causes the system to hang when enumeration is set to false/
> 
> Anyways that's as far as I got. I'm happy that things are working now.
> 
> Scott
> 

Hi,

The dereference processing can only work if the attributes
being dereferenced (usually member:) are DNs (DN_SYNTAX_OID). Does your
schema maybe touch the member attributes in any way? Do all your groups
really use the member attribute and not for instance uniqueMember?

Turning the enumeration on merely works around the problem by following
a different code path.


More information about the sssd-users mailing list