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 1.2.8.2 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): 389-console-1.1.4-1.el5 389-admin-1.1.16-1.el5 389-ds-console-1.2.5-1.el5 389-ds-base-libs-1.2.8.2-1.el5 389-ds-base-1.2.8.2-1.el5 389-admin-console-1.1.7-1.el5 How reproducible: 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. Actual results: Password is updated in the master and AD but not in 389-ds slaves Expected results: password is updated in all servers Additional info:
The problem is happening because we are replicating the unhashed#user#password attribute. The consumer gets this sequence: delete: unhashed#user#password - add: unhashed#user#password unhashed#user#password: value 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.
Created attachment 495988 [details] 0001-Bug-700145-userpasswd-not-replicating.patch
Rich, I applied the patch to the src.rpm and I can confirm that now is working well. Thanks for your help!
To ssh://git.fedorahosted.org/git/389/ds.git c74a13d..74e8152 master -> master commit 74e81521ccc3913e8672cdd5713f832a2c6a09c3 Author: Rich Megginson <rmeggins> Date: Fri Apr 29 15:44:04 2011 -0600 Reviewed by: nkinder, nhosoi (Thanks!) Branch: master Fix Description: The problem is happening because we are replicating the unhashed#user#password attribute. The consumer gets this sequence: delete: unhashed#user#password - add: unhashed#user#password unhashed#user#password: value 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. pw_change is never set in the replicated case, so the consumer never removes unhashed#user#password. The solution is to just remove unhashed#user#password even if pw_change is not set. If the attribute is not in the mods list, remove_mod is a no-op. Platforms tested: RHEL6 x86_64 Flag Day: no Doc impact: no To ssh://git.fedorahosted.org/git/389/ds.git ef51110..0c7024f 389-ds-base-1.2.8 -> 389-ds-base-1.2.8 commit 1feebbd2cb12aac834f4101bbfb4171f751950b9 Author: Rich Megginson <rmeggins> Date: Fri Apr 29 15:44:04 2011 -0600
(In reply to comment #3) > Rich, I applied the patch to the src.rpm and I can confirm that now is working > well. > > Thanks for your help! Thanks for verifying the patch!