Hi list, I have a user management in LDAP, as it works fine for user (can login, do `passwd` to change his password, etc.) But, root cannot change users password otherwise as via ldapmodify. Is it normal behavior, or do I have some configuration errors? For now, LDAP ACL was "turned off" - every user has manage permission, I will change this as soon as root can change user password. SELlinux was also turned off to eliminate it's potential interference. Iptables was "turned off", as well.
Configs, logs, etc are in here: http://fpaste.org/26708/ Thanks in advance, Augustyn
On 20/07/2013, at 9:58 AM, Augustin Wolf augustynwilk@gmail.com wrote:
Hi list, I have a user management in LDAP, as it works fine for user (can login, do `passwd` to change his password, etc.) But, root cannot change users password otherwise as via ldapmodify. Is it normal behavior, or do I have some configuration errors? For now, LDAP ACL was "turned off" - every user has manage permission, I will change this as soon as root can change user password. SELlinux was also turned off to eliminate it's potential interference. Iptables was "turned off", as well.
Configs, logs, etc are in here: http://fpaste.org/26708/ Thanks in advance, Augustyn -- users mailing list users@lists.fedoraproject.org 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
Each user will have permission on their own ldap object they bind to, to change their passwords. Root may not be able to bind to ldap, or roots object doesn't have the acl to modify the password attr on the user's object.
What ldap server are you using? You may consider contacting thier mailing lists for help. They will know more abput their specific acl behaviours and besr practice for this style of password management.
Sincerely,
William
On 20 July 2013 10:52, William Brown william@firstyear.id.au wrote:
For now, LDAP ACL was "turned off" - every user has manage permission,
Each user will have permission on their own ldap object they bind to, to change their passwords. Root may not be able to bind to ldap, or roots object doesn't have the acl to modify the password attr on the user's object.
It is not entirely true. With ACL as above, or commonly used ACL: to userPassword by self write by * auth it is true, but users tend to forgot their passwords, and You don't have to give them write permission to yserPassword attribute. Now there need to be some other way for administrator to reset users passwords. Command "passwd" is most common, and doesn't require admin to remember user DN.
What ldap server are you using? You may consider contacting thier mailing lists for help. [root@ldap ~]# cat /etc/openldap/ldap.conf |grep -ve "^#"|grep -ve "^$"
Configs, logs, etc are in here: http://fpaste.org/26708/
it is openldap. thanks, I will.
Sincerely, William
Thanks for reply
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 07/20/2013 08:43 AM, Augustin Wolf wrote:
On 20 July 2013 10:52, William Brown william@firstyear.id.au wrote:
For now, LDAP ACL was "turned off" - every user has manage permission,
Each user will have permission on their own ldap object they bind to, to change their passwords. Root may not be able to bind to ldap, or roots object doesn't have the acl to modify the password attr on the user's object.
It is not entirely true. With ACL as above, or commonly used ACL: to userPassword by self write by * auth it is true, but users tend to forgot their passwords, and You don't have to give them write permission to yserPassword attribute. Now there need to be some other way for administrator to reset users passwords. Command "passwd" is most common, and doesn't require admin to remember user DN.
What ldap server are you using? You may consider contacting thier mailing lists for help. [root@ldap ~]# cat /etc/openldap/ldap.conf |grep -ve "^#"|grep -ve "^$"
Configs, logs, etc are in here: http://fpaste.org/26708/
it is openldap. thanks, I will.
Sincerely, William
Thanks for reply
This is intentional behavior. SSSD is designed not to allow root on the local system to change the passwords of the centrally-managed users. The reason for this is that we would have to store credentials for an LDAP administrator on the system somewhere in plaintext, which would mean that a rogue admin or attacker could easily gain access to an administrator account.
If you need to admin reset an LDAP user's password, it's much wiser to use ldappasswd instead, because this will force you to present admin credentials (of course, if you're storing the password in /etc/openldap/ldap.conf, you're vulnerable to the same local attack compromising your infrastructure).
On 22 July 2013 18:38, Stephen Gallagher sgallagh@redhat.com wrote: Thanks for participating.
This is intentional behavior. SSSD is designed not to allow root on the local system to change the passwords of the centrally-managed users. The reason for this is that we would have to store credentials for an LDAP administrator on the system somewhere in plaintext, which would mean that a rogue admin or attacker could easily gain access to an administrator account.
If you need to admin reset an LDAP user's password, it's much wiser to use ldappasswd instead, because this will force you to present admin credentials (of course, if you're storing the password in /etc/openldap/ldap.conf, you're vulnerable to the same local attack compromising your infrastructure).
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? 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 does work when I'm changing password as a user using "passwd", right? So it might as well change all users passwords. How using command "passwd" to change user password differs when used by root?
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.) There are also other plain text password vulnerabilities: [root@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 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.
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 ? Just like this is done while unprivileged user is changing password?
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).
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.
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.
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.
There are also other plain text password vulnerabilities: [root@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.
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.
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.
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.
-----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@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.