Re: ppolicy and syncrepl aclaration

[Buchan Milne <bgmilne@staff.telkomsa.net>]

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