Thank you, I only have some minor requests for clarifications. On Tue, Feb 19, 2019 at 11:33:47AM +0100, Pavel Březina wrote: > https://pagure.io/SSSD/docs/pull-request/77 > > .. highlight:: none > > Change password on LDAP server that does not support Password Mofify > Extended Operation > ======================================================================================= > > Related ticket(s): > ------------------ > https://pagure.io/SSSD/sssd/issue/1314 > > > Problem statement > ----------------- > Some directory servers either do not support Password Mofify Extended > Operation > (OID 1.3.6.1.4.1.4203.1.11.1, RFC 3062) for password change or this feature > is > disabled by default. SSSD is unable to perform password change on such > servers. > Even though we recommend to upgrade to servers that supports this feature, > there are still users that will benefit from SSSD being able to change > password without it.
I would prefer more details here. The two servers that are often cited are IBM Tivoli and Oracle Directory server. I don't know if it's just the older versions of these servers all even recent ones, at least I know that with some Oracle server versions, you can enable the extended operation but it is not enabled by default. > > Use cases > --------- > * A user wants to change his/her password against LDAP that does not > support > Password Modify Extended Operation. > > Overview of the solution > ------------------------ > Provide new configuration option ``ldap_pwmodify_exop`` that will default > to true (use extended operation for password change). I would personally prefer an option like "ldap_pwmodify_mode" that would default to 'exop' and would add a new mode 'ldap_modify'. Then if someone asks us in some time to add some other esoteric mode, we could just add a new value to an existing option. Of course better names for the option or its values are welcome. > If this options is set > to false, SSSD will use simple LDAP modify operation instead of extended > operation. It should be explicitly said here that even though the modify operation would use the plain text password, the servers typically hash the userPassword attribute. You might want to even link explicitly to e.g. https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahy/rzahypwdencrypt.htm which says "After the server is configured, any new passwords (for new users) or modified passwords (for existing users) are encrypted before they are stored in the directory database. Subsequent LDAP searches will return a tagged and encrypted value." to make it even clearer that the password will not be stored in the cleartext on the directory side. > > Implementation details > ---------------------- > When a password change is requested, ``sdap_pam_chpass_handler_send`` is > called. > This request first authenticates the user with current password and then in > ``sdap_pam_chpass_handler_auth_done`` tries to change it with extended > operation > by calling ``sdap_exop_modify_passwd_send``. At this point we should check > the value of ``ldap_pwmodify_exop`` option and decide whether to continue > with > extended operation or use ``ldap_modify_ext`` instead. I would prefer if both the design page explicitly said that the connection that verified the current password is used to change the password, not the connection used for ID lookups. It would also be nice to explicitly say in the man page that the user must be allowed to write to the userPassword attribute of their object. I honestly don't know if that's the case with the extended operation or if the servers do some magic behind the scenes. > > Information on how to change the password using simple LDAP modify operation > can be found `here > <https://www.ibm.com/support/knowledgecenter/SSVJJU_6.3.0/com.ibm.IBMDS.doc/admin_gd202.htm>`_ > > Configuration changes > --------------------- > * New option: ``ldap_pwmodify_exop`` > > How To Test > ----------- > Set ``ldap_pwmodify_exop`` to false and try to change user's password. We should also write a test.. > > Authors > ------- > * Pavel Březina <pbrez...@redhat.com> > _______________________________________________ > sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org > To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org > Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org _______________________________________________ sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-le...@lists.fedorahosted.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedorahosted.org/archives/list/sssd-devel@lists.fedorahosted.org
