On Tue, Feb 19, 2013 at 08:22:23PM -0500, 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?
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?
yes, it would be good to know type and version of your LDAP server. In
the meantime you can try to switch of dereference by setting
'ldap_deref_threshold = 0' in you sssd.conf.
bye,
Sumit
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?
> Thanks,
> Scott
>
>
>
>
> _______________________________________________
> sssd-users mailing list
> sssd-users(a)lists.fedorahosted.org
>
https://lists.fedorahosted.org/mailman/listinfo/sssd-users
--
Thank you,
Dmitri Pal
Sr. Engineering Manager for IdM portfolio
Red Hat Inc.
-------------------------------
Looking to carve out IT costs?
www.redhat.com/carveoutcosts/
_______________________________________________
sssd-users mailing list
sssd-users(a)lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-users