Bug 700145 - userpasswd not replicating
Summary: userpasswd not replicating
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Replication - General
Version: 1.2.8
Hardware: x86_64
OS: Linux
unspecified
medium
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
Depends On: 1721695 1721697 1721700 1721701 1721705 1721708 1721709 1721711 1721712 1721713 1721715 1721716
Blocks: 639035 389_1.2.8 701057
TreeView+ depends on / blocked
 
Reported: 2011-04-27 15:19 UTC by Yonathan Dossow
Modified: 2019-06-18 22:44 UTC (History)
1 user (show)

(edit)
Clone Of:
: 701057 (view as bug list)
(edit)
Last Closed: 2015-12-07 16:59:20 UTC


Attachments (Terms of Use)
audit logs for the passwd command and luma, in the master and a slave (621 bytes, application/x-gzip)
2011-04-27 15:19 UTC, Yonathan Dossow
no flags Details
0001-Bug-700145-userpasswd-not-replicating.patch (2.62 KB, patch)
2011-04-30 17:49 UTC, Rich Megginson
nkinder: review+
Details | Diff

Description Yonathan Dossow 2011-04-27 15:19:21 UTC
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:

Comment 1 Rich Megginson 2011-04-29 21:31:15 UTC
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.

Comment 2 Rich Megginson 2011-04-30 17:49:41 UTC
Created attachment 495988 [details]
0001-Bug-700145-userpasswd-not-replicating.patch

Comment 3 Yonathan Dossow 2011-04-30 21:20:42 UTC
Rich, I applied the patch to the src.rpm and I can confirm that now is working well.

Thanks for your help!

Comment 4 Rich Megginson 2011-05-02 15:50:08 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   c74a13d..74e8152  master -> master
commit 74e81521ccc3913e8672cdd5713f832a2c6a09c3
Author: Rich Megginson <rmeggins@redhat.com>
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@redhat.com>
Date:   Fri Apr 29 15:44:04 2011 -0600

Comment 5 Rich Megginson 2011-05-02 15:50:32 UTC
(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!


Note You need to log in before you can comment on or make changes to this bug.