Learn more about these different git repos.
Other Git URLs
I'm configuring sssd for using openldap. Now I have working authentication and programs as id and getent passwd/group. Via ldappasswd I can change user password both as rootDN or user itself. Logged user can change his password by passwd utility. Problem is when root want change user password. Running "passwd userloginname" display "Changing password for user userloginname.", and after ~2 sec delay it ends with "passwd: Authentication token manipulation error". [[BR]] /var/log/secure contain items:
passwd: pam_unix(passwd:chauthtok): username [userloginname] obtained mail passwd: pam_unix(passwd:chauthtok): user "userloginname" does not exist in /etc/passwd mail passwd: pam_sss(passwd:chauthtok): Authentication failed for user userloginname: 4 (System error)
and sssd logs for LDAP domain ends as:
(Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): tevent: Ending timer event 0x8c495d0 "ltdb_callback" (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): cancel ldb transaction (nesting: 3) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): commit ldb transaction (nesting: 2) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): commit ldb transaction (nesting: 1) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_initgr_user] (9): Commit change (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): commit ldb transaction (nesting: 0) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_initgr_user] (9): Process user's groups (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (6): calling ldap_search_ext with [(&(memberuid=userloginname)(objectclass=posixGroup)(cn=*)(gidNumber=*))][ou=users,dc=blah,dc=cz]. (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [objectClass] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [cn] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [userPassword] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [gidNumber] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [memberuid] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (7): Requesting attrs: [modifyTimestamp] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_send] (8): ldap_search_ext called, msgid = 6 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x8b63908], connected[1], ops[0x8c3e3d0], ldap[0x8b63940] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x8b63908], connected[1], ops[0x8c3e3d0], ldap[0x8b63940] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_generic_done] (6): Search result: Success(0), (null) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): tevent: Added timed event "ltdb_callback": 0x8c3f4b8 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): tevent: Added timed event "ltdb_timeout": 0x8c3f580 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): tevent: Destroying timer event 0x8c3f580 "ltdb_timeout" (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): tevent: Ending timer event 0x8c3f4b8 "ltdb_callback" (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_initgr_common_store] (8): Updating memberships for userloginname (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): start ldb transaction (nesting: 0) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [ldb] (9): commit ldb transaction (nesting: 0) (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_get_initgr_done] (9): Initgroups done (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_id_op_connect_step] (9): reusing cached connection (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_id_op_destroy] (9): releasing operation connection (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_id_op_done] (9): releasing operation connection (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [acctinfo_callback] (4): Request processed. Returned 0,0,Success (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: sh[0x8b63908], connected[1], ops[(nil)], ldap[0x8b63940] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_process_result] (8): Trace: ldap_result found nothing! (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sbus_dispatch] (9): dbus conn: 8B5D578 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sbus_dispatch] (9): Dispatching. (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sbus_message_handler] (9): Received SBUS method [pamHandler] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [be_pam_handler] (4): Got request with the following data (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): command: PAM_CHAUTHTOK_PRELIM (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): domain: default (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): user: userloginname (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): service: passwd (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): tty: pts/8 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): ruser: (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): rhost: (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): authtok type: 0 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): authtok size: 0 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): newauthtok type: 0 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): newauthtok size: 0 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): priv: 0 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [pam_print_data] (4): cli_pid: 20530 (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [sdap_pam_chpass_handler] (2): starting password change request for user [userloginname]. (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [be_pam_handler_callback] (4): Backend returned: (3, 4, <NULL>) [Internal Error (System error)] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [be_pam_handler_callback] (4): Sending result [4][default] (Thu Apr 28 14:47:34 2011) [sssd[be[default]]] [be_pam_handler_callback] (4): Sent result [4][default] (Thu Apr 28 14:47:35 2011) [sssd[be[default]]] [sbus_dispatch] (9): dbus conn: 8B57CC0 (Thu Apr 28 14:47:35 2011) [sssd[be[default]]] [sbus_dispatch] (9): Dispatching.
Please, what means cryptic entry
[be_pam_handler_callback] (4): Backend returned: (3, 4, <NULL>) [Internal Error (System error)]
and which are appropriate steps for debugging and adjusting this problem?
I spent lot of time with this issue, but cannot get things moving forward. I'm using sssd-1.5.6.1-1.fc14.i686 and openldap-2.4.23-10.fc14.i686 (at Fedora 14 i686)
SSSD doesn't support letting root change the password on behalf of the user. This is a known limitation. We don't support it because the only way it would work would be for the SSSD configuration to have the DN and password of a user with privilege to change passwords on the LDAP server, which is a serious security risk (especially since it's very easy for a user to gain root on a machine that they have physical access to). We much prefer that if you need this functionality, you use the ldappasswd approach, which requires that the user running the command knows the password for the highly-privileged LDAP user.
However, SSSD is supposed to print a PAM_USER_MESSAGE explaining this when you try, it should not be reporting System Error. That's definitely a bug.
component: SSSD => LDAP Provider milestone: NEEDS_TRIAGE => SSSD 1.6.0 owner: somebody => jzeleny
Replying to [comment:1 sgallagh]:
SSSD doesn't support letting root change the password on behalf of the user. This is a known limitation. We don't support it because the only way it would work would be for the SSSD configuration to have the DN and password of a user with privilege to change passwords on the LDAP server, which is a serious security risk (especially since it's very easy for a user to gain root on a machine that they have physical access to). We much prefer that if you need this functionality, you use the ldappasswd approach, which requires that the user running the command knows the password for the highly-privileged LDAP user. However, SSSD is supposed to print a PAM_USER_MESSAGE explaining this when you try, it should not be reporting System Error. That's definitely a bug.
Hallo Stephen, thank for Your quick response and problem explanation. But, although You write "This is a known limitation", I not knock against this, and sssd/sssd-ldap/sssd.conf man pages have no notice about. It seems as this restiction is implemented somewhere in sssd or its LDAP backend, thus some notice aka "even setting rootdn as ldap_default_bind_dn ..." in their man pages should be helpful. [[BR]] For me is this situation unpleasant, I need possibility for change (by the administrator) user passwords by the PAM mechanism. I hope I can configute this using pam_ldap PADL module for password change, and pam_sss module for authentication.
Thanks for Your help.
Replying to [comment:2 fhanzlik]:
For me is this situation unpleasant, I need possibility for change (by the administrator) user passwords by the PAM mechanism. I hope I can configute this using pam_ldap PADL module for password change, and pam_sss module for authentication.
I'm sorry, but that's really not a feature we're going to provide. It relies on a configuration that is too unsafe (all of your client systems have the password for a user that can change any other user's password). All it would take would be a single successful privilege escalation to root on ANY client machine and all of your users are at risk.
We will probably never support this feature, because we don't want to encourage such poor practices.
I am leaving this bug open ONLY to address the missing error message.
Ok, maybe I'm misunderstanding what you're asking for. Are you asking for:
1)
root$ passwd ldapuser Enter new password for ldapuser: Re-enter new password for ldapuser: Password changed
or are you asking for:
2)
root$ passwd ldapuser Enter password for "cn=Directory Manager": Enter new password for ldapuser: Re-enter new password for ldapuser: Password changed
If the answer is 1), then my point above stands. This is a serious security risk and we won't support it. If you meant 2), however, I apologize and I suppose that's something we could probably add.
Replying to [comment:4 sgallagh]:
> 1) > root# passwd ldapuser > Enter new password for ldapuser: > Re-enter new password for ldapuser: > Password changed
is task which I need - administrator's account management software use PAM (thus it's backend must run with UID=0) for password manipulation. Situation is rather comic - I was inherited LDAP DB with Linux user accounts and because (I think) isn't possible convert its MD5 passwords to /etc/shadow's MD5 salted (nor is possible force users to collectively switch to new passwords), I am compelled to maintain LDAP stuff. Although it is and will be for only one machine, and there is very few (~600) accounts. I would rather prefere simple password/shadow files schema. [[BR]] On previous Fedora (10) version I was using pam_ldap/nns_ldap - which on F14 seems nonfunctional due to some nsswitch problems. Thus I'm playing with sssd - which add, all on one machine, further one extra additional layer :( [[BR]] Password change I have now solved with pam_ldap, and authentication/account/session with pam_sss. Not happy with, but, at least, it works. [BR]
Just FYI: pam_ldap and nss_ldap works just fine in F14, I happened to test it myself yesterday.
Jan
Fields changed
component: LDAP Provider => Documentation
status: new => assigned
patch: 0 => 1
Fixed in: 217d7e2
resolution: => fixed status: assigned => closed
rhbz: => 0
Metadata Update from @fhanzlik: - Issue assigned to jzeleny - Issue set to the milestone: SSSD 1.6.0
SSSD is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in SSSD's github repository.
This issue has been cloned to Github and is available here: - https://github.com/SSSD/sssd/issues/1897
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Login to comment on this ticket.