[Date Prev][Date Next] [Chronological] [Thread] [Top]

Re: OpenLDAP Statistics

Thank you for the tips.

- The LDAP Modify-Increment Extension will be useful to avoid one extra call to ldapsearch.


"Pierangelo Masarati wrote: You could have multiple accesslogs, or you could only check entries that are newer than the last time the daemon ran (e.g. by filtering for operation type and contextCSN)."

- Having multiple accesslogs or not delete the entries will cause to have very long results. In the other hand, the daemon also delete the entries every X time, and it's possible to have a deletion of entries
before a daemon search.


"Michael StrÃder wrote: You might wanna use slapo-lastbind in contrib/ for this."

- slapo-lastbind seems interesting, I will take a look to it. I it works I don't care if I don't register every user failedBinds. I'm concerned about SASL, but for now we are not using it.


"Michael StrÃder wrote: Attribute 'pwdFailureTime' is already maintained by slapo-ppolicy. The count of attribute values is the number of password failures."

- Yes, pwdFailureTime is mantained by slapo-ppolicy but is a global value, not a user value.



Regards,
Felip

2011/11/25 Michael StrÃder <michael@stroeder.com>
Felip Moll wrote:
But in the second
one, the audit people imposed us to have a control of which
accounts were not being used in the last year, and to delete/backup/etc them
if it were the case.

You might wanna use slapo-lastbind in contrib/ for this. This maintains an operational attribute 'authTimestamp' in the user entry which records the last bind time. Unfortunately this seems to only work for LDAP simple binds. With SASL bind the attribute is not updated.


The fact is that I searched for ways of gathering statistics of account usage.
The alternatives that I found were:

First, save the statistics in 2 attributes in each user: lastBind, failedBinds.

Attribute 'pwdFailureTime' is already maintained by slapo-ppolicy. The count of attribute values is the number of password failures.


2. Act on the LDAP server and activate the "overlay accesslog" funcionality.
In this case, monitor every bind operation, then create a daemon that reads
every X time the LDAP accesslog tree and process it.

Yes, this is another option but depending on your deployment the accesslog DB will grow very large very soon if you log all binds.

Ciao, Michael.