Bug 701057 - userpasswd not replicating
Summary: userpasswd not replicating
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: 389-ds-base
Version: 6.1
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Rich Megginson
QA Contact: Chandrasekar Kannan
URL:
Whiteboard:
Keywords: ZStream
Depends On: 700145
Blocks: 639035 389_1.2.8 701554
TreeView+ depends on / blocked
 
Reported: 2011-04-30 17:53 UTC by Rich Megginson
Modified: 2015-09-28 13:29 UTC (History)
6 users (show)

(edit)
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
Clone Of: 700145
(edit)
Last Closed: 2011-12-06 17:48:39 UTC


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHEA-2011:1711 normal SHIPPED_LIVE 389-ds-base bug fix and enhancement update 2011-12-06 01:02:20 UTC

Description Rich Megginson 2011-04-30 17:53:52 UTC
+++ 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@redhat.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:
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@redhat.com on 2011-04-30 13:49:41 EDT ---

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

Comment 4 Laura Bailey 2011-05-17 04:29:46 UTC
    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.
    
    New Contents:
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

Comment 5 errata-xmlrpc 2011-12-06 17:48:39 UTC
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.

http://rhn.redhat.com/errata/RHEA-2011-1711.html


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