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