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