Samba Logging for Audit Trails

We at Northrop Grumman recently decided to replace the Microsoft Windows 2000 server on one of our networks with a Linux server running Samba. The primary motivations for replacing the Windows server with Linux were:

In addition to configuring Samba as a primary domain controller, modifications were made to the Samba source code to meet the security requirements of our network. This article briefly describes how to install and configure Samba and then explains in detail how to modify Samba source code to produce log entries required for audit trails.

Our networks must be configured to meet corporate and customer requirements regarding security. Among the various security requirements that must be met, administrators need to have the ability to audit activity on the network. The required information gathered and logged for these audits is referred to as an audit trail and include the following information: successful logins, logouts, failed logins and password changes.

Most operating systems generate log files with this information, but it may be scattered in a number of different files and contain more information than is necessary. We also wanted to centralize this information so network administrators do not have to examine the logs on every computer on the network. Configured properly, a Windows 2000 server logs the above information for all machines connected to the network, in addition to reporting a myriad of extraneous information. This additional information makes security audits longer, more error-prone and also occupies a lot of disk space when archived.

In order to use Linux and Samba as the primary domain server for Windows 2000 clients, Samba has to duplicate the logging capabilities of the Windows 2000 server. Once Samba was configured for the network, it seemed the only way to meet the logging requirements was to modify the Samba source code. An additional benefit of modifying the source code was the ability to have only the necessary information recorded in the log files. The replacement of the Windows 2000 server with Samba would not have been possible had Samba been a closed-source, proprietary product.

The Linux server initially arrived with Red Hat 8.0 and Samba already installed. The first step was to download the tarred and compressed version of Samba 2.2.8a from the Web site, www.samba.org. Once downloaded, Samba was installed by running the following commands as root:

tar cvfz samba-2.2.8a.tar.gz
cd samba-2.2.8a/source
./configure
make
make install

The Samba executables, smbd and nmbd, were installed under the /usr/local/samba/bin directory. The Red Hat installation had placed these executables under the /sbin directory. Using the newly created Samba executables requires changing the Samba startup script /etc/init.d/samba. The current Samba dæmons should be stopped first by running the command /etc/init.d/samba stop.

The /etc/init.d/samba file then is edited such that the commands for starting smbd and nmbd are changed from /sbin/smbd -D to /usr/local/samba/bin/smbd -D and /sbin/nmbd -D to /usr/local/samba/bin/nmbd -D. The new dæmons are then started with the command /etc/init.d/samba start.

Once the new dæmons are installed successfully, Samba needs to be configured by setting parameters in the smb.conf file. For the 2.2.8a distribution, the default location of this file is /etc/samba. The smb.conf file consists of sections denoted by square brackets, and each section names a share or service. The following example shows some of the parameter values set under the global section to create a Primary Domain Controller for Windows clients:

[global]
netbios name = SambaServer
workgroup     =  NETDOMAIN
domain master = yes
local master = yes
preferred master =yes
os level =  65

For authenticating users on the network, the following parameters also need to be set under the global section:

encrypt passwords = yes
security = user
domain logons = yes

Finally, for Windows 2000 clients, the domain admin group and add user script global parameters need to be set as well:

domain admin group = root
add user script = /usr/sbin/useradd -d /dev/null \
                    -g 100 -s /bin/false -M %u

Public and private shares for Window clients are created by adding new sections.

Public:

[share]
path = /home/share
read only = no
browseable = yes
guest ok = no
create mode = 0770
comment = Shared Folder
hide dot files = yes

Private:

[homes]
path = /home/%u
read only = no
browseable = no
guest ok = no
map archive = yes
create mode = 0750
comment = Home Directories
hide dot files = yes

To verify that the parameters are correct in the smb.conf file or to debug configuration problems, use the testparm command. For debugging problems with Samba in general, the log files log.smbd and log.nmbd under the /var/log/samba directory are invaluable. The parameter log level in the global section of the smb.conf file determines the amount of detailed information Samba writes to the log files, with level 0 being the most general and 10 being the most detailed. Each logging level contains the messages from that level, in addition to the logging messages below it. For example, a logging level of 5 contains messages from level 5, plus those from levels 0 through 4.

Listing 1 is an example from the log.smbd file. The first line in a typical entry in the log file contains the date and time the event occurred, the source file name, the function name and the line number where the message was generated. The second line contains the action that occurred, the domain and client name and a short message describing the logging event. Later in this article, we examine how these messages are generated in the Samba source code.