see https://fedorahosted.org/freeipa/ticket/2688 for the gory details
Instead of deleting, I think we should just log a warning like
"Could not sync the AD entry %s with the DS entry %s, even though they have the same user id (or group id) %s, because the AD entry is out of scope %s of the windows sync agreement"
deleting perfectly good users is bad
Ticket has been cloned to Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=818762
There are some other considerations here: steps: 1) make a ds user and an ad user that are in sync - verify ad changes go to ds and vice versa 2) move the ad user out of scope of the sync agreement 3) verify that sync is not working - verify ad changes don't go to ds and vice versa 4) delete the ad user - the ds user is also deleted
Before the fix for ticket 355, moving the AD entry out of scope would delete the DS entry - but that was problematic - if you mis-configured your sync agreement, all of your DS users could be accidentally deleted
This seems counter-intuitive - the entries are not in sync, yet the deletion is synced. This is because we do not look at the scope of the AD tombstone entry prior to deletion, and test it using is_subject_of_agreement_remote(e,prp->agmt)
We could look at the AD tombstone to see if was in scope - the AD tombstone (with 2008 anyway) provides the attribute "lastknownparent": {{{ (gdb) p e->e_attrs->a_next->a_next->a_next->a_next->a_next $27 = {a_type = 0x7fffc0056bb0 "lastknownparent", a_present_values = { va = 0x7fffc00563b0}, a_flags = 4, a_plugin = 0x6c85a0, a_deleted_values = {va = 0x0}, a_listtofree = 0x0, a_next = 0x7fffc0059450, a_deletioncsn = 0x0, a_mr_eq_plugin = 0x690240, a_mr_ord_plugin = 0x0, a_mr_sub_plugin = 0x0} (gdb) p e->e_attrs->a_next->a_next->a_next->a_next->a_next->a_present_values.va[0] $28 = {bv = {bv_len = 36, bv_val = 0x7fffc0067470 "CN=deletedusers,DC=testdomain,DC=com"}, v_csnset = 0x0, v_flags = 0} }}} So, in this case, if we used lastknownparent, we would see that the entry was outside of the scope of the agreement (the sync subtree is cn=testusers,dc=testdomain,dc=com).
Also note: 1) When we sync deletes from DS to AD, we do check to see if the entry is within the sync scope. 2) When we move a DS entry out of scope, we still delete the corresponding AD entry - we will have to change this too
Linked to Bugzilla bug: https://bugzilla.redhat.com/show_bug.cgi?id=839812 (''Red Hat Enterprise Linux 6'')
set default ticket origin to Community
0001-Ticket-355-winsync-should-not-delete-entry-that-appe.patch 0001-Ticket-355-winsync-should-not-delete-entry-that-appe.2.patch
Added initial screened field value.
c96c3e5..cd7d059 389-ds-base-1.2.11 -> 389-ds-base-1.2.11 commit changeset:64d7791/389-ds-base Author: Rich Megginson rmeggins@redhat.com Date: Wed Aug 22 20:52:24 2012 -0600 ef63c61..6cfc1c0 master -> master commit changeset:94f9cef/389-ds-base Author: Rich Megginson rmeggins@redhat.com Date: Wed Aug 22 20:52:24 2012 -0600
Metadata Update from @rmeggins: - Issue set to the milestone: 1.2.11.12
389-ds-base is moving from Pagure to Github. This means that new issues and pull requests will be accepted only in 389-ds-base's github repository.
This issue has been cloned to Github and is available here: - https://github.com/389ds/389-ds-base/issues/355
If you want to receive further updates on the issue, please navigate to the github issue and click on subscribe button.
subscribe
Thank you for understanding. We apologize for all inconvenience.
Metadata Update from @spichugi: - Issue close_status updated to: wontfix (was: Fixed)
Login to comment on this ticket.