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 <[email protected]> > 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. >
