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.
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). If this options is set to false, SSSD will use simple LDAP modify operation instead of extended operation.
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.
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.
Authors ------- * Pavel Březina pbrezina@redhat.com
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/rzahypwden... 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 pbrezina@redhat.com
sssd-devel mailing list -- sssd-devel@lists.fedorahosted.org To unsubscribe send an email to sssd-devel-leave@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.o...
On 2/19/19 10:03 PM, Jakub Hrozek wrote:
Thank you, I only have some minor requests for clarifications.
I updated the text.
Problem statement
[...]
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.
I was not able to find any mention of this exop in IBM server documentation so I suppose it is not supported. Oracle server supports it but I was not able to find the default state.
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 Modify 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.
Two example servers are IBM Tivoli Directory Server that does not support this operation and Oracle Directory Server that may not have it 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_mode``. This option can be set to one of two values: ``exop``, ``ldap_modify`` having ``exop`` to be the default value. This will give us the ability to extend SSSD with another method for password change in the future if it is ever needed.
If this option is set to ``exop`` then SSSD use Password Modify extended operation to change the password as it does now. If the value is ``ldap_modify`` then ldap_modidy operation will be used to change the password.
Even though the ldap_modify operation uses a plain text password, the servers typically encrypts the userPassword attribute.
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.
`Quote from IBM Tivoli DS documentation https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahy/rzahypwdencrypt.htm`_: "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."
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.
Both operations use the connection that verified the current password not connection that is used for ID lookups. Therefore the user that wants to change his/her password must be allowed to write to the userPassword attribute of their object.
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_mode`` with possible values ``exop`` (default) and ``ldap_modify``.
How To Test ----------- * Set ``ldap_pwmodify_exop`` to false and try to change user's password.
Authors ------- * Pavel Březina pbrezina@redhat.com
On Wed, Feb 20, 2019 at 11:54:31AM +0100, Pavel Březina wrote:
On 2/19/19 10:03 PM, Jakub Hrozek wrote:
Thank you, I only have some minor requests for clarifications.
I updated the text.
Thank you, there are just some typos here and there, but in general I think the page looks good. I'll let some grace period pass so others can also submit their opinion, then I'll merge the page.
Problem statement
[...]
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.
I was not able to find any mention of this exop in IBM server documentation so I suppose it is not supported.
Yes, I think so, too.
Oracle server supports it but I was not able to find the default state.
Me neither, I just know from some RH support cases that at least some versions didn't enable this control by default.
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 Modify 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.
Two example servers are IBM Tivoli Directory Server that does not support this operation and Oracle Directory Server that may not have it 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_mode``. This option can be set to one of two values: ``exop``, ``ldap_modify`` having ``exop`` to be the default value. This will give us the ability to extend SSSD with another method for password change in the future if it is ever needed.
If this option is set to ``exop`` then SSSD use Password Modify extended operation to change the password as it does now. If the value is ``ldap_modify`` then ldap_modidy operation will be used to change the password.
~~~~~ typo
Even though the ldap_modify operation uses a plain text password, the servers typically encrypts the userPassword attribute.
s/encrypts/hashes/?
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.
Duplicate paragraph (now with hashed instead of encrypts :-))
`Quote from IBM Tivoli DS documentation https://www.ibm.com/support/knowledgecenter/en/ssw_ibm_i_71/rzahy/rzahypwdencrypt.htm`_: "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."
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.
Both operations use the connection that verified the current password not connection that is used for ID lookups. Therefore the user that wants to change his/her password must be allowed to write to the userPassword attribute of their object.
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_mode`` with possible values ``exop`` (default) and ``ldap_modify``.
How To Test
- Set ``ldap_pwmodify_exop`` to false and try to change user's password.
You should change this paragraph to mention the ldap_modify, not true/false
On 2/20/19 1:01 PM, Jakub Hrozek wrote:
On Wed, Feb 20, 2019 at 11:54:31AM +0100, Pavel Březina wrote:
On 2/19/19 10:03 PM, Jakub Hrozek wrote:
Thank you, I only have some minor requests for clarifications.
I updated the text.
Thank you, there are just some typos here and there, but in general I think the page looks good. I'll let some grace period pass so others can also submit their opinion, then I'll merge the page.
Fixed. Thank you.
sssd-devel@lists.fedorahosted.org