Description of problem: sssd is not escaping correctly LDAP searches, and when it receives an error from the LDAP server is going offline Version-Release number of selected component (if applicable): sssd-1.2.1-27.el5 How reproducible: always Steps to Reproduce: I noticed that sssd in some of our servers was going offline with no apparent reason, so bumping up the debug_level I found this in the logs: (Wed Oct 6 07:27:09 2010) [sssd[be[ALMACARONI]]] [be_get_account_info] (4): Got request for [4097][1][name=hacienda\eladio] (Wed Oct 6 07:27:09 2010) [sssd[be[ALMACARONI]]] [sdap_get_generic_send] (3): ldap_search_ext failed: Bad search filter (Wed Oct 6 07:27:09 2010) [sssd[be[ALMACARONI]]] [be_run_offline_cb] (3): Going offline. Running callbacks. A bit of investigation turned up that the query was initiated by winbind, which was running on the server, so it was a matter of changing the "winbind separator" and restarting winbind and sssd to hide the problem. Now is evident that this is a bug in SSSD, where it is sufficient that any user queryiing for a username with an '\' in its name to have SSSD going offline. I reproduced this executing "id hacienda\\eladio"
You note how this can be triggered, so I'm trying to determine the exact vector here. It looks as though samba might be a way to trigger this, so it would be something that could be done remotely? Is it possible to do this via ssh or other remote login mechanisms, or can it only be done locally? Finally, does this require a valid account lookup to trigger? Doing 'id joe\\blow' on my Fedora 13 box yields nothing in /var/log/{secure,messages} (but perhaps this is fixed in newer SSSD).
Indeed on Fedora 13 (sssd-1.3.0) the bahavior is different, trying a ssh connection like "ssh -l joe\\blow localhost" leds to the following messages in the sssd logs: (Fri Oct 29 12:11:12 2010) [sssd[be[LGS.COM.VE]]] [be_get_account_info] (4): Got request for [4097][1][name=joe\blow] (Fri Oct 29 12:11:12 2010) [sssd[be[LGS.COM.VE]]] [fo_resolve_service_send] (4): Trying to resolve service 'IPA' (Fri Oct 29 12:11:12 2010) [sssd[be[LGS.COM.VE]]] [be_resolve_server_done] (4): Found address for server XXXXXX: [YYYYY] (Fri Oct 29 12:11:13 2010) [sssd[be[LGS.COM.VE]]] [sasl_bind_send] (4): Executing sasl bind mech: GSSAPI, user: host/ZZZZZZZ (Fri Oct 29 12:11:13 2010) [sssd[be[LGS.COM.VE]]] [child_sig_handler] (4): child [5751] finished successfully. (Fri Oct 29 12:11:13 2010) [sssd[be[LGS.COM.VE]]] [fo_set_port_status] (4): Marking port 0 of server 'XXXXXX' as 'working' (Fri Oct 29 12:11:13 2010) [sssd[be[LGS.COM.VE]]] [set_server_common_status] (4): Marking server 'XXXXXX' as 'working' (Fri Oct 29 12:11:13 2010) [sssd[be[LGS.COM.VE]]] [sdap_get_generic_send] (3): ldap_search_ext failed: Bad search filter (Fri Oct 29 12:11:13 2010) [sssd[be[LGS.COM.VE]]] [sdap_id_op_done] (5): communication error on cached connection, moving to next server So sssd 1.3.0 still sends the incorrectly escaped username to the ldap server but at least it tries to connect again after receiving the error. On a RHEL 5 system this bug is a sort of a denial of service because any remote user can trigger the offline mode of sssd, and if one does not have the credential cache active is effectively locked out of the box.
(In reply to comment #4) > Indeed on Fedora 13 (sssd-1.3.0) the bahavior is different, trying a ssh > connection like "ssh -l joe\\blow localhost" leds to the following messages in > the sssd logs: Interesting. Can you provide your /etc/pam.d/system-auth and /etc/sssd/sssd.conf configuration files to assist in reproducing? I am unable to reproduce this here (using LDAP+kerberos authentication). Also, those log messages are coming from which file, exactly? A log file in /var/log/sssd/? Thanks.
I tested on Fedora 14, and it actually depends on which character follows the \ in the request. For \e (as in the example in the original comment), it still causes the offline behaviour even on SSSD 1.3.0 and 1.4.0. However, with \b I saw the same as you did above. So the problem does still exist.
For easier references: https://fedorahosted.org/sssd/ticket/639
This bug is fixed in the RHEL 5.7 packages. SSSD is no longer supported in Fedora EPEL.