Admin logging SoC project requirements

Michael Krax mk-samba at krax.net
Wed May 31 13:32:09 GMT 2006


On Mon, May 29, 2006 at 10:07:27PM -0500, Gerald (Jerry) Carter wrote:

Jerry,

> > I have a little bit trouble locating the spots where 
> > to place calls to admin_log().
[...]
> > * 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.

I would certainly prefer that.  But in 
NTSTATUS pdb_add_sam_account(struct samu *sam_acct) 
we do not have any information about the requesting user.  That is
contained in struct pipes_struct passed to
NTSTATUS _samr_create_user(pipes_struct *p, SAMR_Q_CREATE_USER *q_u,
			   SAMR_R_CREATE_USER *r_u)

That was why I suggested this function (see below for a list of
information to log).

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

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

There are at least three possibilites:

* admin log = on / off (or destination: syslog)

* admin log event types = all -or- auth printing passdb etc.

* admin log level = info warn error (+ audit_failure audit_success)
  The last two values correspond to the EventLog documentation.

The first does not raise any questions (I hope).  The third one will be
implemented using bitmapped #defines (0x01 info, 0x02 warning, 0x04
error and so on).

Implementation for the second choice listed is more difficult, but every
event type should be assigned a number and the module could generate a
list of event type numbers at samba startup so that it could be
implemented fairly efficient.  I would agree that it is not one of the
first things to code, but I would not exclude it from the beginning.

Ie.: 
#define ADMIN_LOG_EVENTTYPE_AUTH 0x0001
#define ADMIN_LOG_EVENTTYPE_PRINT 0x0002
#define ADMIN_LOG_EVENTTYPE_PASSDB 0x0003
and so on

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

ACK.

> * 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.

I was not convinced by my suggestion, but neither was I by the
opposite.  I will use only one syslog facility.


I made a short list of all the information which should go into one log
entry, ie should be passed to admin_log().  I hope it is okay that I
looked closely at the Event Manager's dialogue and the (Samba) EventLog
documentation.  Making those distinctions, it is possible to provide
some more specific information for other output targets.

- User
  Should be the local user name, if not available the remote user.
  It should be visible if the user was authenticated.

- Machine
  The idea is to log the remote machine name

- Log Level (Information, Warning, Error) = syslog priority; and 
  Audit Success, Audit Failure (see EventLog)

- Event Type (ie. Source as in Subsystem, Service etc.) and
  Event ID 
  both are 16 bit values passed as uint32.  There could be some generic
  event ids (out of memory for example) so that the system could provide
  some generic help in case that type<<16|id is not found.

- Description

(the following two are set by admin_log/syslog:)
- Timestamp
- OS and version (bitmasked)?

and additionally, perhaps:
- Category (could help to filter entries, but I cannot see a useful
  category)
- NTSTATUS code returned (could be included in description)


Basic formatting of a syslog entry could be:
[date-localhost-prefix] 0x03340003 \\MACHINE USER Description 
with 0x03340003 being the event type<<16|id; \\MACHINE could be omitted.

In that way, the string is (with some effort) machine parseable.

Questions:

* Should the event type be printed as text?
  [date-localhost-prefix] 0x03340003 \\MACHINE USER (Event-type-as-text) Description

* I suggest that the description should contain information about the 
  event id and the NTSTATUS code.  There could be a special call
  admin_log_ntstatus (..., NTSTATUS returncode) appending the error
  string to the log entry.

* Shall I create a header file defining all the event types and ids?
  (okay, defining them *all* is up to the community :-)


As for the milestones, is the rather general timeline I provided for the
application okay for this week
(http://userpage.fu-berlin.de/~krax/soc/samba.html)?  I would rather
write some code (prototypes, sample header files) and specify milestones
based upon that, but I am not sure that I will achieve it till Friday.

Ciao,
Michael

-- 
Michael Krax
Phone +49(0)30.76765923  Mobile +49(0)163.7325923


More information about the samba-technical mailing list