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