[Mageia-sysadm] ldap write log

[Michael Scherer]

Le mardi 07 décembre 2010 à 15:05 +0100, Buchan Milne a écrit :
> On Monday, 6 December 2010 19:26:56 Michael Scherer wrote:
> > Hi,
> > 
> > while discussing on irc, we came to the conclusion that it would be nice
> > to get some audit ( by sending mail ) when a user change group, or when
> > a user is promoted.
> 
> Where would we want this audit data to be stored? Only in the DSA ("LDAP 
> server")? Of course, not every single change (e.g. password change by 
> unprivileged user) is going to be of interest. While accesslog overlay can 
> limit what changes you want to see, I think this would prevent us for using it 
> for delta-syncreplication.

In fact, audit may not be the proper name for the idea, as least not for
the start. If we can find a way that do not requires storage, then it
would be better.

> Of course, plain accesslog info is not *that* easy to audit, so we might 
> prefer to have a view of it in CatDap (I've been looking for something to put 
> under "LDAP Admin" :-)).
> 
> > A way to do that would be to use the accesslogs overlay, with a cronjob
> > to get data from it, and to send them by mail and/or store them too, if
> > needed.
> 
> There are other ways, such as syncrepl consumer which evaluates changes, and 
> could notify immediately (via any suitable medium). I have some code for such 
> a tool, but it would need to be more configurable than it is now.

Sound good for this job.

> > Does someone see a problem, or a better idea ?
> > 
> > Obviously, we will need to be careful about what is sent and where, for
> > privacy reason.
> 
> Well, I think we may want to consider two aspects:
> -An automated process that informs relevant people of actions that may warrant 
> further investigation (e.g. "User xxx was promoted to objectClass yyy", or 
> "Member of super-privileged account sustained 100 password failures in 5 
> minutes, and is locked out")
> -A tool which allows searching on events in the case further investigation is 
> warranted

For the moment, the idea is more like the changelog list of package than
to watch suspicious changes. 
Like "user got promoted by admin" "user got added to team foo by admin2"
"user leaved team foo".

Ie, something quite lightweight for the moment, for better
communication.

The auditing goal is a different beast, warranting more details, more
consideration and IMHO more preparation. ( ie, be sure that we manage
the storage issue, the backup, the privacy of the access, a easy way to
audit, define what is suspicious, etc ).

-- 
Michael Scherer