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.
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel