Bug 700145
| Summary: | userpasswd not replicating | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Retired] 389 | Reporter: | Yonathan Dossow <dossow> | ||||||
| Component: | Replication - General | Assignee: | Rich Megginson <rmeggins> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Viktor Ashirov <vashirov> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 1.2.8 | CC: | amsharma | ||||||
| Target Milestone: | --- | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 701057 (view as bug list) | Environment: | |||||||
| Last Closed: | 2015-12-07 16:59:20 UTC | Type: | --- | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 1721695, 1721697, 1721700, 1721701, 1721705, 1721708, 1721709, 1721711, 1721712, 1721715, 1721716, 1874195, 1920717 | ||||||||
| Bug Blocks: | 639035, 656390, 701057 | ||||||||
| Attachments: |
|
||||||||
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! |
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: