Admin logging SoC project requirements

[Gerald (Jerry) Carter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Michael Krax wrote:

> I have a little bit trouble locating the spots where 
> to place calls to admin_log().
> 
> Canidates in the second case are (ordered from lowest 
> to highest level, as far as I understand it):
> 
> * add_smbfilepwd_entry() in pdb_smbpasswd.c (and 
>   equivalents in the other backends)
> 
> * smbpasswd_add_sam_account() in pdb_smbpasswd.c
>   and all the other backends
> 
> * pdb_add_sam_account() in pdb_interface.c (what about 
>   create_user()?)
> 
> * in the admin block in _samr_create_user() in srv_samr_nt.c
>   *and* in local_password_change() in passdb.c

The trick is to catch events at the lowest common
denominator so there is only one code path to maintain.
For user's this would probably be in pdb_add_sam_account().
The RAP and RPC code paths think down to here.

> So we keep this in mind, I do start with the 
> "user-added"- and the "machine-account-invalid" type
> of events; if there is time I'd like  looking into
> auditing, too.

That's fine.  But for the success of the SoC based
project, I think only the plumbing and logging a minimum
number of admin events (to verify functionality)
is acceptable.

> Apparently the eventlog framework Marcin Porwit worked upon 
> is now in Samba3.  Integration with it would be (for now) by
> way of syslog, ie.:

Yes.  See the HOWTO at http://wiki.samba.org/index.php/Event_Logging.
Centeris sets this up for you via their Likewise console.
You can download betas from www.centeris.com if you want to
avoid the initial hassle of setting Eventlogging up for yourself.

> admin_log() -> writes to syslog (or whatever configured) -> syslog (or
> other backend storage) is parsed and "eventlogadm" is called
> (as in http://www.samba.org/~jerry/Samba-EventLog-HOWTO.txt)
>   # tail -f /var/log/messages |\
>   	my_program_to_parse_into_eventlog_records |\
> 	eventlogadm SyslogLinux
> 
> Later on, there should be direct support for eventlog in adminlog.

This is a bit of a philosophical issue.  If the admin log
interface writes directly to the eventlog tdbs then those
eventlogs are not long strictly caches of logs stored elsewhere.
I prefer personally to log via syslogd and have some script
import the data from there into the tdbs.

> Reading your example about the missing DC credentials 
> I noticed that you were also providing some hints to
> the admin how to solve the problem.  I'm not quite sure
> if the admin log should provide such information.  But:
>
> A solution could be to provide an external collection 
> with (more or less) detailed information on a certain
> error.  In that case, we need a unique id for every
> logging event (my example does not do this yet).

That was my next suggestion.  Unique event IDs are a must
in either case I think.

> So there are two different prototypes for the admin_log function (please
> ignore the different parameters in the sample patch, it was a first try):
> 
> 1.
> void admin_log(int eventType,  /* determines the syslog facility */
> 	       int priority, /* as in syslog(...) */
>                const char *format_str, ...);
> 
> eventType corresponds to something like ADMIN_LOG_TYPE_AUTH,
> ADMIN_LOG_TYPE_PRINT... We could pass all *AUTH messages to syslog
> facility AUTHPRIV, all others to SYSLOG (that's what I mean with
> "determine").
> 
> 2. 
> void admin_log(int uniqueEventId, const char *format_str, ...);
> /* uniqueEventId references an array containing all the other 
>    information (eventType, priority etc.) necessary */
> 
> A compromise between the two options would be to join the argument list
> so that we do not need a uniqueEventId but can provide one.

These look pretty good.  I think it is a good idea to
combine the two prototypes though.  Couple of questions.

* Should we all an admin to turn off a class of eventTypes
  (log auth but not printing)?  I'm inclined to always log.

* I think we need both event type and ID (perhaps as bit
  masks on how NTSTATUS codes are done in win32).

* I don't really think that we need to use multiple syslog
  facilities.  I could be persuaded otherwise but I'm more
  inclined to use LOCAL_7 or something.  The reason is there
  is not always a one-to-one mapping between our event type
  and a syslog facility.




cheers, jerry
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org

iD8DBQFEe7bvIR7qMdg1EfYRApq2AKCfCpEI9SHeOvZXczqeROoBTd5wdQCgssVc
w67EEPz+sx2L2UnrjpgFhkM=
=SGs9
-----END PGP SIGNATURE-----