[Date Prev][Date Next]
Re: ppolicy and syncrepl aclaration
Buchan Milne wrote:
On Tuesday 30 June 2009 00:35:47 Howard Chu wrote:
In my opinion, this feature should be removed from the spec and replaced
with an incremental delay instead.
Removing it will (AFAIK) mean that implementations supporting the spec (alone)
will not be compliant with many IT security policies supporting SAOX. Whether
the policies were written with good understanding, or just by feature sets
available in other software, is irrelevant IMHO.
Fair enough, we leave it in. Yet another victory for stupid checkbox software.
I.e., when any login attempt fails,
start adding delays before processing subsequent attempts from the same
client (or for the same user).
In a widely distributed environment, it makes little sense to replicate a
password failure incident to servers located halfway around the world.
However, at present, this does occur. Password failures and lockout on a
syncrepl provider are replicated to any of its consumers. However, the
password failure incident is not replicated to the providers provider, so if
the account has not been locked out on the ultimate master, it is inconvenient
to unlock the account. Additionally, password failures that were recorded on
consumers are not guaranteed to be cleared ...
As before, the spec doesn't address how to handle this situation, and as far
as I can tell it avoids it precisely because it is such a pain to get right,
and there really isn't even a clear definition of what "getting it right"
looks like. Since password failures can be recorded at any of the servers
you're essentially in a multimaster scenario, with all of the race conditions
and inconsistencies that entails. The only way to avoid it is to force all
consumers to chain all Bind requests to their master. That would again defeat
the purpose of load-balancing authentications.
I guess in the short term we can add an option to have ppolicy perform its
failure updates through the frontend, instead of calling the backend as it
does now. That would give the frontend the opportunity to generate an
update-referral, which the chain overlay could then forward back to the provider.
-- Howard Chu
CTO, Symas Corp. http://www.symas.com
Director, Highland Sun http://highlandsun.com/hyc/
Chief Architect, OpenLDAP http://www.openldap.org/project/