ppolicy and sync replication

[Craig Squires <csquires@mun.ca>]

This is a followup to a thread from a couple of months ago. The issue is
interaction between ppolicy and syncrepl overlays. The message I want to
start at is:

http://www.openldap.org/lists/openldap-software/200701/msg00131.html

which didn't get a direct reply. Here's a quote of the relevant context:

> From: Sadique Puthen <xenguy@gmail.com>
>
> I did a bit more testing about this.
>
> I set up password policy as below. Only relevant part given.
>
> pwdLockout: TRUE
> pwdMaxFailure: 3
> pwdLockoutDuration: 90
>
> 1 - I did bind to the master server 3 times using wrong password. I
> failed to bind using the right password after that and failed. 
> Expected
> 2- I did bind to the consumer server using the right password. 
> Failed. Expected.

I note that in my experience, for this to work the "overlay ppolicy"
statement in the consumer's slapd.conf must precede the "overlay
syncrepl" statement. Without that, the consumer doesn't seem to respect
the account lock.

> After 90 seconds everything works fine.

At this point I'm having some further problems:

2a- I bind with the right password on the consumer after the lockout
duration and the pwdFailureTime and pwdAccountLockedTime attributes
are deleted on the consumer, as expected. However, related to Sadique's
next step, those attributes still exist on the provider because
obviously no info gets pushed back from the consumer. This isn't
necessarily a problem for me, but the following is:

2b- I bind with the right password on the provider after the lockout
duration and the attributes are now deleted there. But the consumer
now crashes and is not recoverable. Oddly, if I bind incorrectly on
the provider first and then bind correctly the crash does not occur.
With the new incorrect bind after the lockout duration the
pwdAccountLockedTime attribute is deleted while the old pwdFailureTime
attributes are not. They are deleted with the following correct bind. So
there's something specific about the LockedTime attr that's at issue.

I'm running 2.3.34 on RHEL AS4 (both provider and consumer) using Buchan
Milne's RPMs (thanks Buchan!!). The same issue existed in 2.3.31. I
should also note that I'm doing delta syncrepl... and haven't tried this
with regular syncrepl. I've noticed asides at a couple of places in the
archives that suggest that at least some ppolicy related attrs aren't
supposed to be replicated, yet there's some suggestion at others that
they are. In particular, Pierangelo Masarati states, in a reply to the
original message from Sadique, that: "In general, ppolicy related 
state values are not replicated; each replica is on its own as far as 
state-related attributes in enforcing password policy. [...]"

Here's a summary of my provider and consumer slapd.conf files:

Provider:
--------
database        bdb
suffix          "cn=log"
[directory, rootdn, indexes]
overlay syncprov
syncprov-reloadhint true
syncprov-nopresent true
access to *
        by dn="<replicator>" read

database        bdb
[suffix, directory, rootdn, indexes]
overlay syncprov
syncprov-checkpoint 100 10
overlay accesslog
logdb cn=log
logops writes
logsuccess true
overlay unique
unique_attributes <attr1 attr2>
overlay ppolicy
access to dn="<password policy subtree>"
        by dn="<replicator>" read
        by * none
[acls, cachesize, checkpoint, limits]

Consumer:
--------
database        bdb
[suffix, directory, indexes, rootdn]
overlay ppolicy
syncrepl rid=1
       provider=<provider>
       type=refreshAndPersist
       retry="60 10 300 3"
       bindmethod=simple
       starttls=critical
       binddn="<replicator>"
       credentials=<secret>
       searchbase="<provider's suffix>"
       logbase="cn=log"
       logfilter="(&(objectClass=auditWriteObject)(reqResult=0))"
       syncdata=accesslog
overlay syncprov
[acls]

I've tried preventing replication of the two offending attrs via an acl
but that didn't prevent the replication (because they're operational?).

Any help would be much appreciated. I have debug output if required.

[here's the rest of Sadique's message]
> 3- I did bind to the consumer server using the wrong password three 
> times. I failed to bind to the consumer using the right password 
> after that. Failed. Expected
> 4 - I did bind to the master server using the right password. 
> Success. Not expected before elapsing 90 seconds.
>
> I know the consumer server is not supposed to update the master 
> server database, but is there any work around? Does openldap support 
> multi master replication? Is this a limitation. Does this mean a 
> client locked on consumer server - as set by the policy - would be 
> able to bind to the master server overriding the policy.

Cheers, Craig