Full_Name: Matthew Backes Version: 2.4, head OS: all URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (76.88.99.93)

When using multiple masters replicating from each other with ppolicy enabled, bind failure events fail to propagate the pwdFailureTime changes. The pwdFailureTime's appear on the directory receiving the change and contextCSN updates, but the replica-side disregards the event.

In syncprov.c:1646:

/* Don't do any processing for consumer contextCSN updates */ if ( SLAP_SYNC_SHADOW( op->o_bd ) && op->o_msgid == SLAP_SYNC_UPDATE_MSGID ) { ldap_pvt_thread_rdwr_wunlock( &si->si_csn_rwlock ); return SLAP_CB_CONTINUE; }

This seems to be designed so that when the local side applies remote changes, the resulting contextCSN update does not get sent back out to any persistent searchers.

Unfortuantely, this path is also taken for the pwdFailureTime as a result of a bad (or good) BIND op on a new connection. This means the change is applied to the directory receving the BIND, but replicas of it in multi-master situations discard the change.

This definitely seems to be the MSGID issue because if the BIND is not the first thing being done, then the pwdFailureTime messages propagate correctly; e.g. if using STARTTLS and then BIND, no replication problem exists.

So... any consensus on the right way to do this test? We could start looking specifically for changes to contextCSN, but that's sort of ugly. A generic don't-replicate-this flag seems like a better approach but looks somewhat invasive.

Matthew Backes Symas Corporation mbackes@symas.com