> 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.

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. 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.

>> There's option "ldap_sasl_authid", >> that from what It seems is using Kerberos keytab (which is >> encrypted) > 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.

> 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 :)

>> 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. 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. >> 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.