[389-devel] One Way AD Sync

[Rich Megginson]

Nathan Kinder wrote:
> On 11/05/2010 08:24 AM, Rich Megginson wrote:
>> Nathan Kinder wrote:
>>   
>>> Please review these design notes for implementing one way AD sync.  In
>>> particular, I'm concerned about the possible inconsistencies that can
>>> arise from directly modifying a synced entry on the DS side.  Does 
>>> using
>>> access control seem sufficient for avoiding these inconsistencies?
>>>
>>>      
>> How would you use access control?
>>    
> You would certainly want to change the default self-modify ACI to 
> prevent a user from changing any of the values for synced attributes.  
> It is very likely that you would not want to allow anyone other than 
> "cn=Directory Manager" to modify any synced attributes just to prevent 
> accidentally causing an inconsistency.  One could use the targetfilter 
> keyword to only apply an ACI to the synced entries if they happen to 
> be mixed with non-synced entries in the DIT.
>
> It is probably worth coming up with examples of ACIs that one could 
> use to prevent inconsistencies.
I'd like to get some feedback from users about how they would see such a 
thing working.

Is your proposal for one way sync from AD->DS?  What about one way from 
DS->AD?
>>> If these notes look OK, I'll get everything posted up on the 389 wiki.
>>>
>>> Thanks,
>>> -NGK
>>>
>>> One Way Sync
>>>
>>> Some deployments would prefer that AD sync is only performed in one
>>> direction.  More specifically, updates will be pulled from AD, but
>>> changes to DS will not be pushed back to AD.  Ideally, one would
>>> restrict direct updates to synchronized entries in DS by configuring
>>> access control.
>>>
>>> To implement one-way sync, we need to add a new configuration attribute
>>> to the sync agreement entry.  This attribute will be named "oneWaySync"
>>> and will default to "false" if it is not specified to maintain 
>>> backwards
>>> compatibility.  When this attribute is set to "true", updates will only
>>> go in the AD->DS direction.
>>>
>>> If one way sync is enabled and changes are made to a synced entry on 
>>> the
>>> DS side, a replication session with AD will be started.  In this
>>> session, we will not send any updates, but we will send the Dirsync
>>> control to AD to pull any updates.  This will result in an 
>>> inconsistency
>>> in the modified entry between AD and DS.  This inconsistency will be
>>> resolved the next time any update is made to the entry on the AD side
>>> since we compare the entire entry between AD and DS when we receive a
>>> change via Dirsync.  To avoid these inconsistencies, it is recommended
>>> to not allow direct updates to synced attributes in entries on the 
>>> DS side.
>>>
>>> Another inconsistency that can occur is if a synced entry is directly
>>> deleted from DS.  This deletion is not sent to AD.  In this case, an
>>> update to the entry on the AD side will result in the entry being added
>>> back to DS.  The direct deletion of synced entries on the DS side 
>>> should
>>> be avoided to prevent these inconsistencies.
>>>
>>> Inside of the replication plug-in, we simply skip sending updates in
>>> both the total and incremental replication protocol sessions when using
>>> a one way sync agreement.  We don't want to change the RUV
>>> implementation for a one way sync agreement, so we will just
>>> fast-forward the RUV that we maintain for the AD system as if we had
>>> successfully sent the changes.
>>> -- 
>>> 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
>>    
>