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.
Created attachment 510117 [details]
7dc1edf..b212b0e master -> master
Author: Rich Megginson <firstname.lastname@example.org>
Date: Mon Jun 27 10:13:52 2011 -0600
Reviewed by: nhosoi (Thanks!)
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
Tested bi-directional sync of user/group/password for add/mod/del operations. No regression observed. Hence marking the bug as verified.
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.
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.