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@xxxxxxxxxxxxxxxxxxxxxxx > https://admin.fedoraproject.org/mailman/listinfo/389-devel > -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
