Admin logging SoC project requirements

Gerald (Jerry) Carter jerry at
Tue May 30 03:07:27 GMT 2006

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
Centeris sets this up for you via their Likewise console.
You can download betas from 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
>   # 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
Version: GnuPG v1.4.2 (GNU/Linux)
Comment: Using GnuPG with SUSE -


More information about the samba-technical mailing list