Bug 716980 - winsync uses old AD entry if new one not found
Summary: winsync uses old AD entry if new one not found
Status: CLOSED CURRENTRELEASE
Alias: None
Product: 389
Classification: Retired
Component: Sync Service
Version: 1.2.8
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: ---
Assignee: Rich Megginson
QA Contact: Viktor Ashirov
URL:
Whiteboard:
Keywords:
Depends On:
Blocks: 434915 389_1.2.9 717066
TreeView+ depends on / blocked
 
Reported: 2011-06-27 16:14 UTC by Rich Megginson
Modified: 2015-12-07 16:50 UTC (History)
2 users (show)

(edit)
Clone Of:
: 717066 (view as bug list)
(edit)
Last Closed: 2015-12-07 16:50:02 UTC


Attachments (Terms of Use)
0001-Bug-716980-winsync-uses-old-AD-entry-if-new-one-not-.patch (2.25 KB, patch)
2011-06-27 16:18 UTC, Rich Megginson
nhosoi: review+
Details | Diff

Description Rich Megginson 2011-06-27 16:14:30 UTC
Every time windows sync searches for a windows entry, it stores it as the agreement private raw entry.  In certain cases, such as if winsync attempts to replay a modify operation, and the AD target entry was deleted, winsync will attempt a search to get the AD entry target of the modify operation, and it will fail, and it will leave the old AD target entry in the raw entry field.

One effect of this is to call winsync_plugin_call_pre_ad_mod user or group with the wrong AD entry.

With regular DS there is no problem - the modify operation will fail with err=32 because the AD entry does not exist - this is ok and expected.

This causes problems with IPA winsync because it gets the wrong AD entry.

How to Test:

We can't really reproduce the original problem with regular DS winsync.  So we should just make sure winsync passes all of the regular DS winsync regression tests to make sure this patch doesn't introduce a regression.

Comment 1 Rich Megginson 2011-06-27 16:18:29 UTC
Created attachment 510117 [details]
0001-Bug-716980-winsync-uses-old-AD-entry-if-new-one-not-.patch

Comment 2 Rich Megginson 2011-06-27 17:46:05 UTC
To ssh://git.fedorahosted.org/git/389/ds.git
   7dc1edf..b212b0e  master -> master
commit 958b4cdb50f74d02159924ae36c31bdb6f3ca3be
Author: Rich Megginson <rmeggins@redhat.com>
Date:   Mon Jun 27 10:13:52 2011 -0600
    Reviewed by: nhosoi (Thanks!)
    Branch: master
    Fix Description: Clear out the old raw_entry before doing the search.  This
    will leave a NULL in the raw entry.  winsync plugins will need to handle a
    NULL for the raw_entry and/or ad_entry.
    I also improved an error message.
    Platforms tested: RHEL6 x86_64
    Flag Day: no
    Doc impact: no

Comment 3 Sankar Ramalingam 2011-08-25 11:44:17 UTC
Tested bi-directional sync of user/group/password for add/mod/del operations. No regression observed. Hence marking the bug as verified.

Comment 4 Carsten Grzemba 2014-04-02 06:31:38 UTC
This breaks the current implementation of posix-winsync plugin. Since #47314
failed syncing of modifications on posix attribute from Windows to DS completly.
Before #47314 only acount disable/enable from windows failed.

Test case:
I have setup an winsync replication agreement  with a W2K8R2 AD. There is enabled the SFU for managing the Posix attributes uidnumber, gidnumber, unixshell, unixhomedir, nisdomain, ...
The test failes if I change some of the Posix attributes. These changes will not synched.

The reason is that for #716980 the value for rawentry is reseted before winsync cb is called and for #47314  the cb posix_winsync_pre_ds_mod_user_cb returns immediately if rawentry is NULL.
Before #47314 only account enable/disable have to fail.

sync_acct_disable I took from ipa.
I don't know exactly what is the difference beteween ad_entry and rawentry. Perhaps all works as before if I ignore rawentry in the cb code and use ad_entry instead.


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