On 23 July 2013 16:39, Stephen Gallagher <sgallagh@xxxxxxxxxx> wrote: >> 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). So, unless using command "passwd", will prompt for LDAP admin DN, and password, it won't be secure. > 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. I agree. The only acceptable solution would be one way hash, but this wouldn't be much help, unless OpenLdap supports it. > 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. But it might be modified with LDAP ACL, though. I thought that sssd does modify LDAP records. My mistake. >>> 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 :) I know. During long googling, before creating this thread I found Stephen answers on serverfault.com and linuxquestions.org. I think it's great that someone from redhat does participate in such sites and help to solve some problems. Or simply to tell what was the motivation for certain sssd solutions. > >>> 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. I was thinking about breaking in, when intruder doesn't know the LDAP admin rootpw. On root account it can be easily changed. > 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. As much as this would be comfortable it can be easily replaced by simple bash script, that will execute both ldappasswd and kpasswd for given LDAP admin DN, password and user Thanks for answer. -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
