"passwd" by root for user fails with sssd,pam, ldap

Tue Jul 23 14:39:47 UTC 2013

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/23/2013 01:20 AM, Gordon Messmer wrote:
> On 07/22/2013 02:18 PM, Augustin Wolf wrote:
>> Okay, it isn't safe to store root password in a file. By all my 
>> administrator heart I agree. But I don't see why you have to
>> store it in a plain text file. Could you please expand on that?
> 
> Because that's how LDAP works.  In order to change a password, 
> generally, you need to connect and authenticate as an admin or
> connect and authenticate as the user whose password will be
> changed.
> 
> That means that either you need the admin's DN and plain-text
> password in a file (like the older PAM LDAP does) or you need the
> user to enter their own password (like both sssd and PAM LDAP do).
> 

The LDAP protocol requires that the bind username and password be sent
in plaintext across the wire. (This is also why SSSD doesn't allow
LDAP auth without an encrypted tunnel, because the protocol is unsafe
otherwise). So you could store it in an obfuscated form on the disk,
but it has to be a reversible encryption with the key readily
available on the machine. This basically moves you from "plaintext
password" to "hidden plaintext password easily readable by a
script-kiddy". Not much improvement.

>> You can point what user is SSSD using, by customizing
>> "ldap_default_bind_dn", there's also password for LDAP Manager in
>> "ldap_default_authtok" - as far as I understand this is the user
>> that is performing all the actions via LDAP server.
> 
> It's used for searches, generally when your directory doesn't
> allow anonymous searches.
> 

Yes, this is setting up the bind account for SSSD itself to look up
users, groups, etc. It doesn't perform ANY write operations back to
LDAP at all. The only time SSSD ever modifies the LDAP server is
during a password change operation, and then it's done only with the
credentials of the user changing their password.

>> It does work when I'm changing password as a user using "passwd",
>> right?
> 
> "It" consists of connecting to the LDAP server with the password
> given by the user.  "It" can't work for an administrator because
> there's no password to give to the directory.
> 

When you're a user running 'passwd', your user is prompted for his or
her current password and that is used to bind to LDAP. It does *not*
use the ldap_default_bind_dn here. Your user traditionally has
privilege to change their own password.

>> Btw. plain-text passwords: There's option "ldap_sasl_authid",
>> that from what It seems is using Kerberos keytab (which is
>> encrypted). (Unfortunately using it in my case it didn't help at
>> all.)
> 
> I believe that's used for searches as well.
> 

Yeah, this is essentially the SASL variant of ldap_default_bind_dn and
ldap_default_authtok. It has all of the same limitations on its
privileges that they do.

>> There are also other plain text password vulnerabilities: 
>> [root at ldap ~]# grep bindpw /etc/* /etc/nslcd.conf:bindpw
>> somesecretpass /etc/pam_ldap.conf:bindpw somesecretpass 
>> /etc/sudo-ldap.conf:bindpw somesecretpass and: /etc/ldap.secret
> 
> None of those are provided by sssd.  The developers who wrote the 
> software which uses those files don't share the same concerns that
> the sssd developers have.
> 

And even in those situations, most of those are still read-only and
designed just to bypass limitations of anonymous bind. Well-designed
LDAP servers provide minimal information to anonymous logins, so in
order to really see useful information you need to have a real user
(or machine user).

> By the way: Stephen Gallagher is one of the sssd developers, so
> you should probably take his word when he tells you what sssd does
> and doesn't do.
> 

I advise people never to take me without a grain of salt. Keeps me
honest :)

>> Despite it - having logged in to root account gives full control
>> over system. One can change "rootpw" in /etc/openldap/slapd.conf
>> (or olc* directory style config) and change users password using
>> ldappasswd using admin DN and skipping ACL.
> 
> ...which is what Stephen suggested that you do.  LDAP is a network 
> service, and as such the "root" user has not special privileges.
> root's privileges are more or less limited to the filesystem.
> 

Actually, you don't even need to set rootpw there, because the
'ldappasswd' command will always prompt you for the password for the
rootdn when you're attempting to change a different user's password.
This is fine and acceptable, because you are being *challenged* and
have to prove that you really are the LDAP admin user. The fact that
you happen to be root on one machine connected to LDAP is *not*
sufficient to prove that you have privilege to change other users'
passwords. That would be a security hole, since anyone who gained root
access to one of the machines would be able to change the password of
any other user (possibly as part of a complex attack to gain access to
a highly-privileged user).

So this is why I recommend the user of ldappasswd if you want to reset
another user's password (side note: you don't even need to be root for
this; you can just present the admin credentials to ldappasswd as a
standard user). It's also why we don't (and won't) support this
misfeature in SSSD.

>> I'm heading to using LDAP as an backend database for Kerberos. As
>> far as I got all users are in LDAP, different branches of LDAP
>> directory and I'm having great trouble to find comfortable way of
>> managing them. Wouldn't be possible ask root for administrative
>> password before changing user password, and don't store it
>> anywhere ?
> 
> With ldappasswd, yes.
> 

If you want, you're welcome to file an RFE at
https://fedorahosted.org/sssd (FAS login) if you would like to see us
add functionality to pam_sss.so to challenge you for an LDAP admin
username and password if you try to do 'passwd otheruser' on the
command-line, but I'll tell you right now that the SSSD team will
almost certainly put it on the back-burner because other tools
(ldappasswd, kpasswd) already do an excellent job of it.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.13 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlHulbMACgkQeiVVYja6o6NzcQCePTOPa/uxwM2nTqpykRUkcvgb
k/MAn2CKLVcuBzF2eJqdGKzKv8+GZED1
=UQXn
-----END PGP SIGNATURE-----