[prev in list] [next in list] [prev in thread] [next in thread] 

List:       fedora-directory-devel
Subject:    Re: [389-devel] One Way AD Sync
From:       Rich Megginson <rmeggins () redhat ! com>
Date:       2010-11-05 23:20:03
Message-ID: 4CD49123.2070204 () redhat ! com
[Download RAW message or body]

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

--
389-devel mailing list
389-devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/389-devel
[prev in list] [next in list] [prev in thread] [next in thread]