Bug 707282

Summary: latest sssd fails if ldap_default_authtok_type is not mentioned
Product: Red Hat Enterprise Linux 6 Reporter: Najmuddin Chirammal <nc>
Component: sssdAssignee: Stephen Gallagher <sgallagh>
Status: CLOSED ERRATA QA Contact: Chandrasekar Kannan <ckannan>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 6.1CC: benl, dpal, grajaiya, jgalipea, jhrozek, jwest, kbanerje, prc, yjog
Target Milestone: rcKeywords: Regression, ZStream
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: sssd-1.5.1-35.el6 Doc Type: Bug Fix
Doc Text:
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"
Story Points: ---
Clone Of:
: 707340 748833 (view as bug list) Environment:
Last Closed: 2011-12-06 16:38:26 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 707340, 708353, 748833    

Description Najmuddin Chirammal 2011-05-24 15:15:28 UTC
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.

Comment 1 Stephen Gallagher 2011-05-24 15:24:33 UTC
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.

Comment 5 Kaushik Banerjee 2011-09-22 12:01:02 UTC
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

Comment 6 Kaushik Banerjee 2011-09-22 12:01:53 UTC
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

Comment 7 Jakub Hrozek 2011-10-26 16:21:47 UTC
    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"

Comment 8 errata-xmlrpc 2011-12-06 16:38:26 UTC
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