Learn more about these different git repos.
Other Git URLs
https://bugzilla.redhat.com/show_bug.cgi?id=795044 (Red Hat Enterprise Linux 6)
When using the Tivoli? Directory Server LDAP client, you can use the 'ldapchangepwd' utility to modify a user's password. However, if you are using non-Tivoli Directory Server LDAP client then you can change the userpassword as shown below. Consider an example where you have a user 'cn=user,o=sample' with the password as 'passw001rd' and you need to update that password to 'passw007rd'. To do this, issue the following command: ldapmodify -p <port> -D <bindDN> -w <bindPassword> -i <input file> dn: cn=user,o=sample changetype: modify delete: userpassword userpassword: <old password value> - add: userpassword userpassword: <new password value>
After the thorough evaluation we decided that this issue will not be addressed for several reasons:
_comment0: After the through evaluation we decided that this issues will not be addressed for several reasons:
Sorry, we need to reopen this. The reasons it was closed WONTFIX are in fact not correct. Dmitri unfortunately had left the conversation we were having on the topic before all of the facts became clear.
To clarify: the request does NOT involve providing too many privileges. LDAP servers that implement this password-change mechanism do not require us to perform the hashing and we are not bypassing password policies.
What happens is that we present a plaintext password to replace the existing one and the LDAP server traps this with a pre-operation plugin which checks the password against password policies and then hashes it internally.
Thus, there is no security issue here. It is still less preferable than the password-change extended operation (primarily because the exop can communicate failure reasons whereas the modify-only approach can only return a generic error).
So this probably IS something we should implement (for compatibility with old LDAP servers).
resolution: wontfix => status: closed => reopened
I should clarify the above. Dmitri's statements came from bad information that I had fed him previously. I didn't have a chance to correct them before he closed the ticket. In re-reading my comment, it sounds like I was assigning blame to him, which was not the case.
Fields changed
milestone: NEEDS_TRIAGE => SSSD 1.11 beta
proposed_priority: => Optional
This ticket has been evaluated for inclusion into SSSD 1.10 release and was decided to be excluded since it does not match the main goals and themes of the release. It might be considered for later releases.
milestone: SSSD 1.11 beta => SSSD 1.12 beta
FYI: This issue came up on !FedoraForum today: http://forums.fedoraforum.org/showthread.php?p=1622203
_comment0: FYI: This issue came up on FedoraForum today: http://forums.fedoraforum.org/showthread.php?p=1622203 => 1357141943277002 design: => design_review: => 0 fedora_test_page: => selected: =>
changelog: => mark: => 0 priority: major => minor review: => 0 sensitive: => 0
We don't plan on implementing non-extop password changes unless patches are contributed (and I would oppose them either way I guess..at least the format with ldap_modify that pam_ldap used)
milestone: SSSD 1.14 beta => SSSD Deferred
Metadata Update from @dpal: - Issue set to the milestone: SSSD Patches welcome
Metadata Update from @pbrezina: - Issue assigned to pbrezina
Metadata Update from @jhrozek: - Custom field design_review reset (from 0) - Custom field mark reset (from 0) - Custom field patch reset (from 0) - Custom field review reset (from 0) - Custom field sensitive reset (from 0) - Custom field testsupdated reset (from 0) - Issue close_status updated to: None - Issue set to the milestone: SSSD 2.2 (was: SSSD Patches welcome)
Metadata Update from @jhrozek: - Custom field design_review reset (from false) - Custom field mark reset (from false) - Custom field patch reset (from false) - Custom field review reset (from false) - Custom field sensitive reset (from false) - Custom field testsupdated reset (from false) - Issue close_status updated to: Fixed - Issue status updated to: Closed (was: Open)
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/2356
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.