Administrative logging service for Samba

[Caleb Jorden]

I am interested in implementing an administrative logging service for 
samba.  This functionality would be similar to the debug logs, but would 
contain activities which a system administrator would be interested in 
knowing.  For example, especially when samba is a domain controller, it is 
imperative that the administrator know when an attack is occurring on his 
or her domain.  There currently does not exist a clean way to ascertain 
this information from the samba logs.  If one turns on debug logging at a 
sufficiently high level, the events can at least be inferred, but not 
without wading through a lot of other information which is not related to 
the administrative events.

I will outline what I have in mind, and I would appreciate any feedback 
that interested parties would have for me about my current plan.

Firstly, the logging service will create a common administrative logging 
interface, probably not significantly different from the DEBUG call 
semantics.  At this point, there are a few ways to proceed.

1. The information could be logged in a string-only form.
        - Example: ADMINLOG("Account %s was administratively locked 
out\n", username);

2. The information could be tagged with a unique eventID.
        - Example: ADMINLOG(ADMINLOG_ACCOUNT_LOCKOUT, "Account %s was 
administratively locked out\n", username);
                (*where ADMINLOG_ACCOUNT_LOCKOUT would be a #define in a 
header which would contain a common mapping of eventIDs<=>names)

3. The information could be tagged with a unique eventTypeID..
        - Example: ADMINLOG(ADMINLOG_SECURITY, "Account %s was 
administratively locked out\n", username);

4. The information could be tagged with both an eventTypeID and an eventID
        - Example: ADMINLOG(ADMINLOG_SECURITY, 
ADMINLOG_SECURITY_ACCOUNT_LOCKOUT,
                                "Account %s was administratively locked 
out\n", username);

I prefer option 4, because it would allow for specific types of logging 
events to be filtered by a configuration option in smb.conf, and would 
allow for specific searches and sorting of results.



Next, the backend of the administrative logging system needs to be 
determined.  A number of options come to mind, most of which are not 
exclusive of the others.

1. The logs could be logged to syslog, with possibly different levels 
based upon the eventID or eventTypeID.

2. The logs could be logged to one or more flat files.

3. The logs could be stored in some sort of binary or XML form readable 
with the Event Viewer RPCs or other tools created for this job.

4. The logs could be stored in a (SQL) database which could be queried for 
specific eventIDs or eventTypeIDs, and the results sorted as desired.

I think that, quite likely, multiple of these options could prove useful. 
I would probably start with option 2, since this would provide an easy way 
to get the system working.  After the system is in place, however, I or 
someone else could add more administrative logging backend modules as 
needed.  I think that it would be useful to have a generic architecture 
from the beginning which would facilitate the easy extension of the 
backend system to different logging destinations.  This is one reason I am 
in favor of having an eventID and an eventTypeID.  That way information 
can be categorized more finely eventually than may be reasonable or 
possible in the first iteration of this project.



One final thing is that I am planning on implementing this in Samba3. Does 
anyone know if such a thing exists yet in Samba4?  I have not looked at 
the Samba4 system yet, since it seems that Samba3 will be the production 
version for quite some time.  However, I would be interested in knowing if 
such a system is in Samba4 so that I might be able to make my system as 
much like it to facilitate the easy transition for administrators to 
Samba4 when the time comes.

I should also note that not all of this design is my own idea.  Parts of 
it have come from a conversation with Jerry Carter, and parts from a 
conversation with Jim McDonough.

So, what does everyone think?  If you were doing it, or having it done, 
how would you like the system implemented?


Respectfully submitted,
Caleb Jorden
cjorden at us.ibm.com