[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: ppolicy and sync replication



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.


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.

This statement makes no sense, since there is no syncrepl overlay for the consumer.


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. [...]"

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.


[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.


Cheers, Craig

-- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/