How come failed authentications aren't ....

[Andy Bakun]

"Christopher R. Hertel" wrote:

> I'd rather see something that works with the current DEBUG system.  DEBUG
> also writes to syslog, if enabled by the sysadmin.  Adding the patch
> described below does add some usefull functionality, at the expense of
> having to manage yet another log output mechanism.

That is if you consider the debug output to be useful logging information.  I
rarely look at it.  At one time, back in the 1.9.x days, I had the log files linked
to /dev/null and set to level 0.  The debug logs are just that, debug logs.
Unfortunately, there is no way within the current samba debug log setup to specify
which kinds of events you want to see, only that you want more increasingly verbose
information.  And changing this is going to be a big job, which is why I think
samba required a non-debugging related auditing output mechanism.

> There is code with Samba 2.0.x that can convert DEBUG output into HTML.

I considered using this, but in order to get all the events you want, you may have
to set a debug level relatively high, and have the disk storage to keep all those
logs around in order to do post processing.  I consider this to be a bigger draw
back than having to manage yet another log output mechanism, especially considering
that if you are using debug logs for some kind of usage tracking, you can disable
them if you want to use this auditing.  This auditing system I wrote allows you
specify exactly what you want to see, without having to do a lot of post processing
(unless you want to put the auditing output into a database or something, in which
case, you will still have to do post processing, but it'll be easier because there
is less unrelated junk in the input).

> My next goal with this (when I have time, which isn't right now I'm
> 'fraid) is to integrate this with Swat and add some filtering and sorting
> capabilities.

My goals with the auditing code is to remove the dependancy on syslog and write
flat files directly (at the expense of allowing multiple logging sources into one
sink), and allow greater freedom in the output format to ease post processing.

> Don't get me wrong, though.  I've had my share of complaints with the
> DEBUG system and other Samba mechanisms.  The importance of working
> within the system to change it has been made clear to me.  ;)

Don't get me wrong either.  I needed something to keep track of what all the users
were doing, failed logons, who deleted what file and stuff like that.  I also need
this auditing information to stay around for a relatively long time (upwards of
over a year in some cases), and modifying the debugging system in samba would have
required more changes to samba than I was willing to make.  I consider the
debugging system to be logging what _samba_ is doing, while I needed to log what
the _users_ are doing.

This is where we disagree.  I think the required changes to the debugging system to
support auditing is beyond the scope of the debugging system, and that kind of
change requires a new mechanism.

Andy.