#1314 RFE Request for allowing password changes using SSSD in DS which dont follow OID's from RFC 3062
Closed: Fixed 2 years ago by jhrozek. Opened 9 years ago by dpal.

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:

  1. This scheme is insecure as it gives the client too much privileges. This is the same reason why we do not support the shadow passwords in LDAP.
  2. This scheme completely bypasses centrally enforced password policies which is a violation in itself.
  3. This scheme would require SSSD to generate hashes. It is not the responsibility of the client to generate hashes. Client does not know what password hashes need to be generated, it is the server responsibility.

_comment0: After the through evaluation we decided that this issues will not be addressed for several reasons:

  1. This scheme is insecure as it gives the client too much privileges. This is the same reason why we do not support the shadow passwords in LDAP.
  2. This scheme completely bypasses centrally enforced password policies which is a violation in itself.
  3. This scheme would require SSSD to generate hashes. It is not the responsibility of the client to generate hashes. Client does not know what password hashes need to be generated, it is the server responsibility. => 1335446876373239
    blockedby: =>
    blocking: =>
    coverity: =>
    feature_milestone: =>
    resolution: => wontfix
    status: new => closed
    tests: => 0
    testsupdated: => 0
    upgrade: => 0

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

Fields changed

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.

Fields changed

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

Fields changed

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

4 years ago

Metadata Update from @pbrezina:
- Issue assigned to pbrezina

2 years ago

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)

2 years ago

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)

2 years ago

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.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.

Metadata