[389-devel] One Way AD Sync

[Rich Megginson]

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