+++ 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 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:

--- Additional comment from rmeggins 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:
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.

--- Additional comment from rmeggins on 2011-04-30 13:49:41 EDT ---

Created attachment 495988 [details]
0001-Bug-700145-userpasswd-not-replicating.patch