Nathan Kinder wrote: > On 11/04/2010 03:28 PM, 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? >> >> 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. >> >> > I've made a few changes to the way the "oneWaySync" configuration attribute > works. Instead of only allowing one way sync in the AD->DS direction, it > would be nice to also allow it in the DS->AD direction if desired. Instead > of allowing values of "true" or "false" for "oneWaySync", we would allow > the sync direction to be specified with values of "toWindows" or > "fromWindows". If the "oneWaySync" attribute is set to some other value, > we will log a warning in the errors log stating that we are ignoring the > setting and default to bi-directional sync. > > For the implementation of one way sync in the DS->AD direction, we simply > skip sending the Dirsync control in both the total and incremental update > replication sessions. > Good. Sounds nice and simple. > Feedback on this would be appreciated. > >> 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 > -- 389-devel mailing list 389-devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/389-devel
