[Date Prev][Date Next]
Re: OpenLDAP Statistics
On 11/25/2011 03:01 PM, Felip Moll wrote:
I am new to this list and I would like to ask you a question regarding
The fact is that I have an OpenLDAP server that receive a lot of operations
every day. I have different kind of services that make use of LDAP and bind
to this server.
In a particular case, there are an ou=Users that contain approx. 200 users
with their attributes. I am using also a private LDAP schema developed by
me in which I have some extra attributes.
Recently we have managed an audit promoted by our government in which a lot
of security items had been checked and corrected if had found some issue.
One of this security checks was about the management
of user passowrds and an other regarding to user accounts. The first one
could be satisfied by implementing the ppolicy overlay in LDAP. 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.
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,
1. For each service, whenever a bind from a user has done to LDAP, send a
ldapmodify operation for this user and if the bind was successful, write in
user.lastBind the timestamp. If it was not, increment failedBinds++.
It implies the modification of each service, taking in account that all has
to be documented, that in many services the implementation is not trivial,
and also taking care of the upgrades of the services. In conclusion, a lot
of work and
constant modifications and checks.
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.
For each entry processed:
- Delete it from the ldap accesslog tree.
- Check if the reqResult was 49 (invalid creds.) or 0 (success).
- If it was 49, ldapsearch the reqDN who made the bind request, and read
his failedBins attribute. Increment it in one, and send a ldapmodify to the
user and with the new value of failedBinds.
You can use "LDAP Modify-Increment Extension" (RFC4525) instead.
- If it was 0, ldapmodify the reqDN setting the lastBind as reqEnd.
I programmed it in C++ and ldapc++ library, and it works. But the fact is
that I am not convinced of this solution. It saved us from the audit but
for the future there are some problems to take into account:
- Deleting the ldap entry every time it's read is bad, because then we
cannot use the overlay for delta syncrepl.
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).
Dipartimento di Ingegneria Aerospaziale
Politecnico di Milano