Using Samba to test OpenLDAP's dirsync client implementation

[Garming Sam]

On 15/01/19 1:19 AM, Howard Chu wrote:
>>> For example, if we are in the middle of retrieving incremental changes
>>> from one DC in the domain and it becomes unresponsive, in AD we can
>>> use the cookie received from one DC to poll another in the same
>>> domain, with unpredictable results (it is possible to return entries
>>> that have already been sent, for example, or even do a full sync).
>>> Does Samba behave the same way?
>> I think you'd have to explain much more in detail what the procedure
>> you've enacted is. I'm not sure about how similar this code is to
>> standard DRS (RPC) in Samba, or how much your client behaves in a
>> similar manner.
> The question is how it behaves for failover. Supposedly if you have
> a primary and secondary DC in a domain, the dirsync cookie from the
> primary can be used against the secondary without triggering a total
> from-scratch resend of the DB.

Hi Howard,

I would expect that to work as intended (as AD does). Most of the
relevant state is encoded in the cookie itself in a vector of all the
domain controllers. One edge case though, might be when the domain
controllers haven't necessarily been made aware of each other yet.

Normally repeated entries over the DRS replication mechanism are
entirely expected. There is code to prevent returning duplicates in some
cases, but it only works against a single DC -- I presume it must also
be used in dirsync.

USN 1000 on DC 1 = USN 2000 on DC 2
USN 1500 on DC 1 = USN 2100 on DC 2

The vector (or rather a sequence of sent vectors) allows you to equate
locally generated USN across the network. But intermediate states can't
be arbitrarily mapped, because changes can be applied in different
orders for instance. The equivalence between the two is often only in
reference to a subset on one or both of the domain controllers.

USN 1250 on DC 1 = USN ??? on DC 2

It really has no choice but to go back to the earlier mapping and resend
a bunch of objects.


Cheers,

Garming

>>> Also, how does Samba operate when a single-valued attribute has been
>>> deleted from an entry? AD seems to return the same entry without any
>>> noticeable changes, which makes it impossible to detect which
>>> attribute has been removed. I looked at dirsync.py but didn't see a
>>> test for that scenario, perhaps it is somewhere else?
>> Your guess is as good as mine on this.
> For now this operation is omitted from our test script, because AD
> gives no useful information in this circumstance.
>