Re: (ITS#6815) Feature Request: Accesslog filter

[andrew.findlay@skills-1st.co.uk]

On Wed, Feb 23, 2011 at 05:25:28AM -0800, Howard Chu wrote:

> >Extending this idea slightly, would it be possible to have
> >exclusions based on changes to specific attributes? The
> >particular case I have in mind is where accesslog is used to
> >keep a permanent audit log of changes, and ppolicy is also
> >in use, resulting in one audit entry for every login
> >failure. I have one site where a large proportion of the auditlog
> >entries are login failures...
> 
> Perhaps in that case, it would be simpler just to set ppolicy's mods
> to be internal-only and bypass the accesslog overlay. (Currently it
> does this already, if the server is a single-master replica.)

There are all sorts of problems to do with ppolicy and replication...
Bypassing accesslog is an interesting idea, but I can see that people
who use n-failure-lockout might want the lockout events to be
auditable.

I wonder if there might be some benefit to giving such control on a
per-operation basis. Then ppolicy might be configurable to have some
automatic ops logged and others not. It could also be the start of a
way to make ppolicy actions rather more global across a replication
group (e.g. by putting in the ability to queue some ops for replication
back to a master server).

> So far you're talking about two different enhancements - the
> original poster is trying to exclude a set of searches, and you're
> talking about excluding modify ops. I'm not seeing any way yet to
> generalize from here such that all operation types are addressed
> meaningfully, and I don't want to introduce multiple special cases
> to the config language.

Rather than
	logbase <operations> <baseDN>
how about
	logfilter <operations> <LDAP URL>

where the whole clause may be repeated as many times as needed?
The LDAP URL can then specify a search base, a filter, and a list of
attributes of interest.

Extending this to support both inclusion and exclusion clauses might be
harder, as you would then need some way to give them an order of
precedence. The case I mentioned before would need a rule of the form
'dont log this op if the only change concerns the atttribute
pwdFailureTime'. Perhaps a simple list of rules:

logrecord <operations> <LDAP URL>
logignore <operations> <LDAP URL>

... and if anything is left at the end of the list then it gets logged.
The filters would determine whether a log entry would be made at all,
and the attribute lists would determine the content.

Andrew
-- 
-----------------------------------------------------------------------
|                 From Andrew Findlay, Skills 1st Ltd                 |
| Consultant in large-scale systems, networks, and directory services |
|     http://www.skills-1st.co.uk/                +44 1628 782565     |
-----------------------------------------------------------------------