+++ This bug was initially created as a clone of Bug #700145 +++
Created attachment 495269 [details]
audit logs for the passwd command and luma, in the master and a slave
Description of problem:
I'm using luma to modify users passwords, until 389-ds-base 1.2.6
everything worked ok. but with 220.127.116.11 the updated password isn't
propagating to the 389-ds slaves. AD gets updated correctly. Using 389-console or passwd to change the password works ok.
Also is only the userpassword attribute that fails to replicate to the slaves. I tried with others and they get updated on all servers.
auditing the process, I found that luma deletes the userpasswd attibute
and adds it again. 389-console and passwd only modifies the attribute.
I have 4 ldap servers (1 master, 3 slaves) and 1 AD server.
Version-Release number of selected component (if applicable):
Always when we change a password using Luma
Steps to Reproduce:
1. start luma, add the master server, use cn=directory manager to connect
2. using the browser, go to an user, and edit the password
3. save the changes.
Password is updated in the master and AD but not in 389-ds slaves
password is updated in all servers
--- Additional comment from email@example.com on 2011-04-29 17:31:15 EDT ---
The problem is happening because we are replicating the unhashed#user#password attribute. The consumer gets this sequence:
The code in entry_wsi_apply_mod attempts to apply the delete, but since the attribute does not exist, it returns LDAP_NO_SUCH_ATTRIBUTE and the entire modify operation is rejected. The server removes unhashed#user#password before doing database operations in the non-replicated case, but in the replicated case it is assumed we can just apply the operations as they are given by the supplier.
/* Remove the unhashed password pseudo-attribute prior */
/* to db access */
- if (pw_change)
- slapi_mods_init_passin (&smods, mods);
- remove_mod (&smods, unhashed_pw_attr, &unhashed_pw_smod);
- slapi_pblock_set (pb, SLAPI_MODIFY_MODS,
- (void*)slapi_mods_get_ldapmods_passout (&smods));
+ slapi_mods_init_passin (&smods, mods);
+ remove_mod (&smods, unhashed_pw_attr, &unhashed_pw_smod);
+ slapi_pblock_set (pb, SLAPI_MODIFY_MODS,
+ (void*)slapi_mods_get_ldapmods_passout (&smods));
If this is a replicated op, pw_change will never be true, but we still need to remove unhashed#user#password before we pass the operation to the backend.
--- Additional comment from firstname.lastname@example.org on 2011-04-30 13:49:41 EDT ---
Created attachment 495988 [details]
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Password changes did not replicate across clustered servers because the method used to pass the changes to slave nodes was rejected on the slave nodes. This issue has been corrected, and password changes now replicate as expected
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory, and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.