[389-devel] winsync syncs deletions of AD entries that are out of scope

[Rich Megginson]

This came up during extended testing for 
https://fedorahosted.org/389/ticket/355

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).

Question: In light of 355 changing the behavior - should we use 
lastknownparent to see if the tombstone is out of the scope of the 
agreement, and not delete the DS entry if so?