Humm and taking this one step further I'm guessing that the replication account probably needs to see at least the entryUUID and entryCSN for all accounts to make sure that it can see the records it needs to delete. Okay at least I have some direction to go on now.

Jeffrey

On Fri, Jun 1, 2012 at 9:06 AM, Nick Milas <nick@eurobjects.com> wrote:
On 1/6/2012 8:54 πμ, Jeffrey Crawford wrote:

Are you saying that syncprov looks at the account that is bound and sends deletes if a record would become invisible after a modification?

I understand the opposite: syncprov will only send add/delete message based on base/scope/filter and not on ACL-visibility. So in essence Howard says that ACL-based filtering in replication does not result in proper results to consumers.

This is tricky! (I didn't know either.) It means that we should *not* design our replication based on ACL-filtering (which, unfortunately, we have done too), but, on the contrary, that we should design our DIT so that it can cover our replication needs based on consumer base/scope/filter configuration, and we should design/adapt our ACLs with the above rule in mind.

Please confirm the above thoughts.

Thanks,
Nick



--
I fly because it releases my mind from the tyranny of petty things . . .

— Antoine de Saint-Exupéry

Jeffrey E. Crawford
ITS Application Administrator (IDM)
831-459-4365
jeffreyc@ucsc.edu