On Tue, 2007-04-03 at 14:43 -0700, Howard Chu wrote:
Craig Squires wrote:
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:
There is no "syncrepl overlay". (Possibly there should be, but that work got stalled.) The syncrepl consumer is intrinsic to slapd, not a separate overlay.
oops. I meant syncprov. I guess I'm confused about the relation between syncrepl and the syncprov overlay.
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.
This statement makes no sense, since there is no syncrepl overlay for the consumer.
...again, I meant syncprov.
[...]
I think you're running into the same crash I found in ITS#4904, fixed yesterday. The fix will be in 2.3.35. Since it's only a one-line fix, you can easily patch your 2.3.34 source if you need it right away.
Thanks!
[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.
I guess it would be possible to arrange for the consumer to chain the ppolicy updates back to the master. I haven't tried that. OpenLDAP 2.4 has multimaster support so that would be another possibility. We probably should have a config keyword to govern that behavior. In very widely distributed directories it doesn't make sense to replicate login events in one corner of the world to every other installation.
I might have a look at chaining. A keyword would be good. In some distributed authentication contexts it would be nice to be able to track multiple logins across e.g. different applications which happen to use different replicas of the same data.