On Tuesday 30 June 2009 00:35:47 Howard Chu wrote:
Buchan Milne wrote:
> On Tuesday 16 June 2009 10:45:00 Jordi Espasa Clofent wrote:
>> According to
>> the "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."
>> ¿Is it means that of I've one provider and two consumers, the changes
>> made in ppolicy statements in provider are not sync againt the consumers
>> as other kind entries/attributes are?
>> I need to know because of I've change my userPassword in provider and:
>> * I can use without problems the new password using the provider
>> * I cannot use the new password against the two consumers.
> userPassword is *not* a "state-related attribute", please see 'man
> Note, that what this does mean is that you may be locked out on one
> slave, but not the others (and maybe not the provider), and simple
> reset-ing the password on the master may not be sufficient to unlock the
> account on the slaves, and the pwdAccountFailureTime attributes may not
> be cleared, meaning one more failed authentication may lock the account
> on a slave (especially in a load-balanced environment).
As I've noted before, the ppolicy draft specification doesn't address how
ppolicy state should behave in a replicated environment. The spec is also
still only a draft, not finalized. Experience with this version of the
draft implementation will probably be useful in shaping the final spec.
As others have also commented, locking out an account due to X number of
incorrect logins is generally a bad idea; it offers a trivial avenue for
denial-of-service and doesn't actually deter brute force password attacks.
Regardless of whether it is a bad idea or not, many financial rules require
this kind of security control. While making provision for other defences
against brute-force password available would be beneficial, my requirement for
ppolicy is to implement SAOX-supporting requirements (since we are listed on
the NYSE) according to our organisations IT security policies which have been
signed off at board level, which mandates lockout after a specified number of
failures. If OpenLDAP is not able to do this in future, that will mean we will
not be allowed to do authentication of services for employees against OpenLDAP
(as we do at present).
In my opinion, this feature should be removed from the spec and
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.
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 ...
Indeed, attempting to do so will likely result in greater DOS all
the infrastructure. IMO failure tracking should be node-local; logs of such
events can be forwarded to a central security auditing point but that
should be a separate mechanism from the general purpose directory.
I suppose in a load-balancing environment you need all of the servers in
the pool to be kept in sync, but then you're losing the benefit of doing
load balancing. (I.e., instead of dividing the workload amongst the
servers, you're requiring all of the workload to be duplicated on all the
But, the current implementation results in all the slaves in the load-balanced
pool being out of sync with each other regarding password policy events, as
password failures are not replicated, nor lockout, nor clearing of password
In my case, I have over 1 million entries on most of my LDAP servers, and 150
accounts which can do simple binds and are in a database with ppolicy. I
really couldn't care about a few more writes per hour for ppolicy attributes
across the slaves, when I have 10 per second for the other 1 million entries.
A practical problem I had (when we had lots of contractors in, who seem to
forget their passwords a lot) was that most of the slaves in the load balanced
pool ended up having pwdMaxFailure-1 pwdFailureTime attributes on them, so one
more failure on most of the slaves would lock the account out. To unlock the
account, I had to add pwdAccountLockedTime on the master as it was on the
slave on which the account was locked out (as not all slaves had it), then
delete it and/or reset the password. But, I would still be left with
pwdFailureTime attributes on most of the slaves ...