Re: (ITS#8185) Clarification/enhancement request: purging stale pwdFailureTime attributes

[subbarao@computer.org]

On 08/14/2015 10:38 AM, Howard Chu wrote:
> subbarao@computer.org wrote:
>> In the particular situation that's prompting this request, it's not just
>> two or three values -- for one entry it was over 38000 values that had
>> accumulated over time! (and generally high values for many other 
>> entries).
>
> If you have entries with tens of thousands of Bind failures being 
> recorded, you have a security monitoring problem. The limit applied by 
> the patch for this ITS will only mask the problem. The fact that your 
> security auditors haven't already noticed these tens of thousands of 
> Bind failures and stopped them at their source means you've got a 
> major vulnerability in your network security.

Hi Howard, what's happening here is that an application account's 
password has expired, and its owners have neglected to change the 
password. Meanwhile, the old password remains hardcoded in the 
application, which continues to issue BIND requests that fail. The 
functionality of this particular application isn't mission-critical -- 
it may even be deprecated at this point by another application, so it's 
likely not a priority for the account owners given everything else on 
their plates.

In this customer environment, the monitoring of password failures has 
historically been done outside of LDAP, and focuses on user accounts 
which tend to have higher privileges. LDAP application accounts (which 
tend to have minimal privileges) aren't treated the same. These bind 
failures may get cleaned up at some point during a periodic review of 
application accounts with expired passwords, but it's not likely to 
happen soon, given the lower level of risk/impact.

Given that the bind failures themselves aren't causing a problem (the 
system as a whole has ample capacity), the only operations-impacting 
issue is the continually increasing entry size. So for this customer 
environment, I feel the best approach for now is to simply purge the 
stale failure timestamps (which I would prefer to do with a standard 
OpenLDAP configuration setting than with an external script).

As I mentioned in an earlier message, I see the slapo-ppolicy man page 
as being friendly to this feature request: "Excess timestamps beyond 
those allowed by pwdMaxFailure may also be purged." From my perspective, 
it's a valuable hygienic feature for environments such as this one.

Regards,

     -Kartik