Red Hat Bugzilla – Bug 974033
sssd could not initialize backend when setup with obfuscated_password and a base64 encoded password
Last modified: 2013-06-26 07:11:53 EDT
Description of problem: sssd fails to start sssd_be, sssd_nss and sssd_pam processes when "ldap_default_authtok_type = obfuscated_password" and "ldap_default_authtok = U2VjcmV0MTIz" Version-Release number of selected component (if applicable): sssd-1.5.1-68.el5 How reproducible: Always Steps to Reproduce: 1. Setup the domain section of sssd.conf as given below: [domain/default] ldap_schema = rfc2307 ldap_search_base = dc=example,dc=com id_provider = ldap ldap_id_use_start_tls = False ldap_default_bind_dn = cn=Directory Manager debug_level = 9 ldap_uri = ldap://SERVER cache_credentials = False ldap_tls_cacert = /etc/openldap/cacerts/cacert.asc ldap_default_authtok_type = obfuscated_password ldap_default_authtok = U2VjcmV0MTIz 2. Use a base64 encoded password with parameter "ldap_default_authtok". 3. Start the sssd service and list the processes. # ps -ef | grep sssd root 29742 1 0 19:20 ? 00:00:00 /usr/sbin/sssd -f -D Actual results: SSSD does not initialize all the backend processes. Expected results: Backed process should be running. Additional info: See the relevant log below: (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [krb5_try_kdcip] (4): No KDC found in configuration, trying legacy option (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [ldap_get_options] (9): Found obfuscated password, trying to convert to cleartext. (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [sss_password_decrypt] (8): Read method: 25939 (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [sss_password_decrypt] (8): Read bufsize: 29283 (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [get_crypto_mech_data] (1): Unsupported cipher type (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [ldap_get_options] (1): Cannot convert the obfuscated password back to cleartext (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [load_backend_module] (0): Error (22) in module (ldap) initialization (sssm_ldap_id_init)! (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [be_process_init] (0): fatal error initializing data providers (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [main] (0): Could not initialize backend [22] (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [sbus_remove_watch] (8): 0x18fcf3c0/0x18fcf0b0 (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [remove_socket_symlink] (9): The symlink points to [/var/lib/sss/pipes/private/sbus-dp_default.29819] (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [remove_socket_symlink] (9): The path including our pid is [/var/lib/sss/pipes/private/sbus-dp_default.29819] (Mon Jun 10 19:22:05 2013) [sssd[be[default]]] [remove_socket_symlink] (9): Removed the symlink
Ondra will take a look
Hi, This is caused by misconfiguration, the backend should not start, meaning the sssd itself should fail. *** This bug has been marked as a duplicate of bug 974036 ***
That might not be the issue, please check if the obfuscation works with 5.10. Amith was reporting that the cleartext password worked, but not obfuscated with the latest packages.
The testcase was supposed to fail, the provided obfuscated password is not generated by sss_obfuscate, but directly through base64, and is not right. This case should only detect the following line: [ldap_get_options] (1): Cannot convert the obfuscated password back to cleartext and quit as success, however, it failed. The probable cause is that the main sssd process is not killed, targeting https://bugzilla.redhat.com/show_bug.cgi?id=974036 Setting needinfo flag to clarify we're waiting for the results of next test build (after mentioned BZ 974036 will be VERIFIED)
Amith, I've built the latest packages. Can you check if this bug went away with the latest build?
Jakub, Yes the bug is fixed and i verified BZ- https://bugzilla.redhat.com/show_bug.cgi?id=974036 on the latest build - sssd-1.5.1-69.el5 As expected, SSSD core process fails to start if the sssd.conf is misconfigured.
Great, we can mark it as a duplicate then. Thank you for testing! *** This bug has been marked as a duplicate of bug 974036 ***