Hide Forgot
Description of problem: With latest sssd, ldap_default_authtok_type is unset by default, and the sssd clients fails to fetch data from directory server (that requires a binddn). this was not required in the previous sssd version (eg: sssd-1.2.1-28) Version-Release number of selected component (if applicable): sssd-1.5.1-34.el6 How reproducible: Always Steps to Reproduce: 1. Configure sssd with a ldap_default_bind_dn & ldap_default_authtok 2. do not mention ldap_default_authtok_type 3. try to get a user info using id or similar commands. Actual results: id or similar command returns nothing, sssd fails with the following error. [sdap_get_generic_done] (6): Search result: Operations error(1), 00000000: LdapErr: DSID-0C090627, comment: In order to perform this operation a successful bind must be completed on the connection., data 0, vece Expected results: id or similar commands return user info sssd considers "ldap_default_authtok_type" as "password" and use the "ldap_default_authtok" to bind to the directory server.
This is a regression that was introduced when we added the obfuscated password support. Previously, there was only one option, so it was an assumed default (mostly by accident, but we have to support that). This makes it a regression that it is no longer the default. Customers are seeing this issue in production, so I'm proposing it as Urgent.
Output of beaker automation test: :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: :: [ LOG ] :: Test 0002 - Enumerate and Auth user01 over STARTTLS: verifies bz 707282 -> ldap_default_authtok_type not mentioned :::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: Stopping sssd: [ OK ] :: [ PASS ] :: Running 'service sssd stop' :: [ PASS ] :: Running 'rm -fr /var/lib/sss/db/*.ldb' Starting sssd: [ OK ] [ OK ] :: [ PASS ] :: Running 'service sssd start' :: [ PASS ] :: napping for 5 secs... :: [ PASS ] :: Running 'restart_clearing_cache' :: [ PASS ] :: Running 'sleep 5' user01:*:20001:20001:user01:/home/user01:/bin/bash :: [ PASS ] :: user01 user returned as expected. :: [07:33:04] :: Login as user01 to localhost using SSH spawn ssh -q -l user01 localhost echo 'login successful' The authenticity of host 'localhost (::1)' can't be established. RSA key fingerprint is ee:c6:a4:62:b3:ba:26:c7:a6:be:93:7f:68:2f:3f:b9. Are you sure you want to continue connecting (yes/no)? yes user01@localhost's password: Could not chdir to home directory /home/user01: No such file or directory login successful :: [ PASS ] :: Authentication successful, as expected :: [ PASS ] :: Running 'auth_success user01 Secret123' '9f1f8053-9e55-458c-8240-8b00cfa48ec3' Test-0002-Enumerate-and-Auth-user01-over-STARTTLS result: PASS metric: 0 Log: /tmp/beakerlib-3060168/journal.txt Info: Searching AVC errors produced since 1316691169.83 (Thu Sep 22 07:32:49 2011) Searching logs... Info: No AVC messages found. Writing to /mnt/testarea/tmp.LgyWyA
Verified in version: # rpm -qi sssd | head Name : sssd Relocations: (not relocatable) Version : 1.5.1 Vendor: Red Hat, Inc. Release : 52.el6 Build Date: Tue 20 Sep 2011 09:11:03 PM IST Install Date: Wed 21 Sep 2011 03:07:04 PM IST Build Host: x86-010.build.bos.redhat.com Group : Applications/System Source RPM: sssd-1.5.1-52.el6.src.rpm Size : 3550647 License: GPLv3+ Signature : (none) Packager : Red Hat, Inc. <http://bugzilla.redhat.com/bugzilla> URL : http://fedorahosted.org/sssd/ Summary : System Security Services Daemon
Technical note added. If any revisions are required, please edit the "Technical Notes" field accordingly. All revisions will be proofread by the Engineering Content Services team. New Contents: Cause: SSSD incorrectly assumed that if "ldap_default_authtok" is used, "ldap_default_authtok_type" is set to "password" even if it was not explicitly specified in the config file. This assumption happened mostly because "password" was the only allowed value for some time. Later, when support for obcuscated passwords was added, this assumption was no longer true. Consequence: Users who used ldap_default_authtok with no explicit ldap_default_authtok_type were experiencing a regression. Fix: because ldap_default_authtok with no dap_default_authtok_type set worked in the previous versions (even though by accident only), we made "password" the default for "ldap_default_authtok_type" Result: Configurations that don't specify explicit ldap_default_authtok_type behave as if it was set to "password"
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-2011-1529.html