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

[Nathan Kinder]

On 05/04/2012 10:45 AM, Rich Megginson wrote:
> On 05/04/2012 11:25 AM, Rich Megginson wrote:
>> 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?
It makes sense to use lastknownparent here.
>
> 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 - should we change this behavior too?
It seems like this should be consistent with how we behave when an entry 
is moved out of scope on the AD side (unlink but not delete).
>
>>
>> -- 
>> 389-devel mailing list
>> 389-devel at lists.fedoraproject.org
>> https://admin.fedoraproject.org/mailman/listinfo/389-devel
>
> -- 
> 389-devel mailing list
> 389-devel at lists.fedoraproject.org
> https://admin.fedoraproject.org/mailman/listinfo/389-devel