Brett @Google wrote:
On Thu, Oct 22, 2009 at 5:44 PM, Howard Chu <hyc@symas.com
<mailto:hyc@symas.com>> wrote:
In the case of a local, load-balanced cluster of replicas, where the
network latency between DSAs is very low, the natural coalescing of
updates may not occur as often. Still, it would be better if the
updates didn't happen at all. And in such an environment, where the
DSAs are so close together that latency is low, distributing reads
is still cheaper than distributing writes. So, the correct way to
implement this global state is to keep it distributed separately
during writes, and collect it during reads.
I'd think that to indicate the topology you would create some
administrative name, perhaps a simple string "sales west" or "cluster
one" to indicate a topological region, and you would specify for each
DSA which administrative name or topology it is logically part of. Then
this administrative region name + unique identifier of the principal in
question, could be used as a key to hold a simple locked / unlocked
boolean value on the replica's parent.
I'm not sure you're trying to solve the right problem yet. I'm pretty unconvinced that account lockout is a good solution to anything, in general. That's why I added login rate control to the latest ppolicy draft, where the DSA simply starts inserting delays before responding to failed authc attempts. As I see it, rate control can be managed completely within a single DSA and no state ever needs to be replicated outward on any particular schedule. But at the moment I haven't yet thought about how well this will work in all the possible deployment scenarios.
So once again, what's important here is to analyze what are the types of attacks we expect to see, and how particular defense strategies will behave, and how effectively they will fend off those attacks. Until you've outlined the problems, you don't have any framework for designing the solution.
-- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/