Admin logging SoC project requirements

[Michael Krax]

On Sat, May 27, 2006 at 03:29:31PM -0500, Gerald (Jerry) Carter wrote:

Jerry,

> >> Here are some of the requirements I'd like to discuss
> >> regarding the admin logging.   The logging should
[...]

This being an ongoing discussion, the concepts presented are flexibly
(to avoid: chaotic).  I will provide a summary after the concepts get
more stable (so all but Jerry can stop reading now if they are not 
interested in details).  But I learned today that posting to the 
mailing list is preferred :-)

> I was thinking more of "User foo added a new printer"
> or "New user biddle created by DOMAIN\Administrator".
> Very similar to the Windows event IDs.

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

Advantage of using the low level functions is that there is a more
precise error description possible.  But these informations are already
provided by the debugging code.  So I would go for the last choice.

> Auditing is kind of an interesting thing altogether.
> I'm not sure how much we should focus on this
> initially.  The thing is that auditing is controlled
> by Windows clients setting System ACLs on objects.
> once the logging plumbing is in place, it will make
> support for SACLs easier.

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.
> 
> >> 3. warn of potential problems and possibly advise
> >>    on how to correct them
> >
> > That's on a configuration level, I suppose.
> 
> Here's an example I as thinking of.  If Samba (as a
> member server), gets an "access denied" when trying to
> connect to the DC using its machine account credentials,
> the admin should be warned that the server might need
> to be rejoined to the domain.

Okay, I tried to locate the right place for a call to the
"admin_log"-function.  I'd locate it in auth/auth_domain.c in
check_ntdomain_security (see attached patch in pseudo-code).
The parameters do not correspond to what I discuss below.  Perhaps
admin_log() should be called by the caller of check_ntdomain_security,
but I think that would be too generic.

I also looked into last year's discussion:
http://lists.samba.org/archive/samba-technical/2005-June/041672.html

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

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.

> I don't think you should be responsible for figuring
> out everything that should be logged but rather
> to provide the plumbing that we need for logging
> in the first place.  That way we can add new events
> as they arise.  I think the best logging is learned
> from experience with real systems.

So I will start a new thread (in a few days) asking for some
suggestions. 


*Advanced help*

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

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.

Tomorrow, I'm going to look into configuration options.

Ciao,
Michael

-- 
Michael Krax
Phone +49(0)30.76765923  Mobile +49(0)163.7325923
-------------- next part --------------
Index: auth/auth_domain.c
===================================================================
--- auth/auth_domain.c	(Revision 15881)
+++ auth/auth_domain.c	(Arbeitskopie)
@@ -324,6 +324,19 @@ static NTSTATUS check_ntdomain_security(
 					dc_name,
 					dc_ip);
 		
+	/* support for administrative logging -- sample */
+	if (!NT_STATUS_IS_OK(nt_status)) {
+		admin_log(ADMIN_LOG_TYPE_AUTH,
+			  ADMIN_LOG_NTSTATUS(nt_status),
+			  "domain_client_validate: unable to validate password "
+                          "for user %s in domain %s to Domain controller %s. "
+                          "Error was %s.\n", user_info->smb_name,
+                          user_info->domain, dc_name, 
+                          nt_errstr(nt_status));
+			  /* error description is taken from debug
+			   * message in domain_client_validate */
+	}
+
 	return nt_status;
 }