userPassword is *not* a "state-related attribute", please see 'man slapo- ppolicy'.

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

Nice :(

I work in load-balanced environment of course, so this supposes a potential and serious problem. Always I have the brute-force option: make the changes in the provider and restart the consumers to force the re-sync.

Once again ... :(

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:

...

Hi,

According to http://www.openldap.org/lists/openldap-software/200701/msg00149.html, 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 slapo- ppolicy'.

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

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 through 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 servers.)

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

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

Regards, Buchan