[389-devel] One Way AD Sync

[Nathan Kinder]

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