Fix description: unhashed password was introduced to give an
opportunity to get the unhashed password to plugins. But it
is not always needed. If it is not, it is preferable to
disable the functionality.
{{{
1) Ticket #402 "unhashed#user#password in entry extension"
switched the way how the unhashed password is stored.
It used to be put in the attribute list in the entry.
The #402 patch changed it to store in the entry extension.
To provide the migration period, it has been stored in
the both places. This patch is disabling the old
attribute list method.
2) Introducing a config parameter nsslapd-unhashed-pw-switch
to cn=config. The parameter takes 3 values:
on - unhashed password is stored in the entry extension
and logged in the changelog.
nolog - unhashed password is stored in the entry extension
but not logged in the changelog.
off - unhashed password is not stored in the entry extension.
3) As reported in the ticket #577 "Attribute name unhashed#user
#password is not valid per RFC 4512", the pseudo attribute
type is violating the RFC. Once, disabling to store it in
the attribute list in the entry, the OID is not needed in
the schema any more. Thus, the pseudo attribute type is
eliminated from the schema.
}}}

git patch file (master) (not including the generated files by autoconf)
0001-Ticket-561-disable-writing-unhashed-user-password-to.patch

How will this work in a replicated environment? For example, a supplier that doesn't use unhashed#user#password replicating to a consumer that does? Or vice versa?

Replying to [comment:5 rmeggins]:

How will this work in a replicated environment? For example, a supplier that doesn't use unhashed#user#password replicating to a consumer that does? Or vice versa?

If a supplier does not send an unhashed password, it is not available on a consumer. So, for the case 1, both does not store the unhashed password in the changelog even if the consumer is hoping to handle it. (assuming 2-way MMR, M1 and M2) For the case 2, M2 logs the password in the changelog and send it to M1. But M1 does not log it in the changelog. This case 2's behaviour looks the same as before when the unhashed password was available only one host (except it is really being sent).

Replying to [comment:6 nhosoi]:

Replying to [comment:5 rmeggins]:

How will this work in a replicated environment? For example, a supplier that doesn't use unhashed#user#password replicating to a consumer that does? Or vice versa?

If a supplier does not send an unhashed password, it is not available on a consumer. So, for the case 1, both does not store the unhashed password in the changelog even if the consumer is hoping to handle it. (assuming 2-way MMR, M1 and M2)

We will need to make it clear that the unhashed password needs to be enabled for certain situations, such as using winsync. We might have the case where M1<->M2 are configured for replication, and M2 has a sync agreement with AD. We will need the unhashed password to be replicated for password changes to sync properly when they are initiated on M1.

Replying to [comment:8 nkinder]:

Replying to [comment:6 nhosoi]:

Replying to [comment:5 rmeggins]:

How will this work in a replicated environment? For example, a supplier that doesn't use unhashed#user#password replicating to a consumer that does? Or vice versa?

If a supplier does not send an unhashed password, it is not available on a consumer. So, for the case 1, both does not store the unhashed password in the changelog even if the consumer is hoping to handle it. (assuming 2-way MMR, M1 and M2)

We will need to make it clear that the unhashed password needs to be enabled for certain situations, such as using winsync. We might have the case where M1<->M2 are configured for replication, and M2 has a sync agreement with AD. We will need the unhashed password to be replicated for password changes to sync properly when they are initiated on M1.

Shall we open a doc bug? Anyway, the new config param needs to be doc'ed...

Reviewed by Rich (Thank you!!)

Pushed to master: commit c4bd52e

Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=918715

Thanks to Mark for pointing out the error/warning.

I see these compiler warnings on master:
../ds/ldap/servers/plugins/replication/cl5_api.c: In function ‘_cl5WriteMod’:
../ds/ldap/servers/plugins/replication/cl5_api.c:2520: warning: implicit declaration of function ‘config_get_unhashed_pw_switch’
Is this related to your fix?

Fix description: configuration parameter getter APIs are not
advertised to plugins. This patch slapi_config_get_unhashed_
pw_switch which is available among plugins.

git patch file (master) -- fixing a compiler warning introduced by the previous patch
0001-Fixing-a-compiler-warning-introduced-by-Ticket-561-d.patch

Looks good. Ack.

Reviewed by Mark (Thank you, again!!)

Pushed to master: commit 1d4f3ca

389-ds-base is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in 389-ds-base's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/389ds/389-ds-base/issues/561

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.