4.2 Configuring the Secure Logging Server

The Secure Logging Server, the server component in the Nsure auditing system, is implemented in the shared library, lengine. For more information on program binaries, see Section H.1, Program Files and Directories.

The Secure Logging Server manages the flow of information to and from the Nsure auditing system. It receives incoming events and requests from the Platform Agents, logs information to the data store, monitors designated events, and provides filtering and notification services. It can also be configured to automatically reset critical system attributes according to a specified policy.

The Secure Logging Server is configured through eDirectory. The Logging Server object in eDirectory stores all the properties and attributes for the Secure Logging Server. Consequently, the server must have access to eDirectory and the Logging Server object before it can launch the Secure Logging Server.

To minimize server reaction time and ensure high system performance, you should create a local replica of the Logging Server object and its associated objects on the logging server.

4.2.1 Creating the Logging Server Object

On NetWare, Linux, and Solaris systems, the Logging Server object can be created automatically in the Logging Services container during installation or it can be created manually anywhere in the tree after installation. Which option you choose depends, to a degree, on your system design.

NOTE:The Windows installation program automatically creates the Logging Server object in the Logging Services container.

Locating the Logging Server object in the Logging Services container is ideal for organizations that need a simple, easy-to-manage logging system. It also suits organizations that are implementing Nsure Audit as an auditing solution and, for security reasons, want to centrally manage their systems. Using the Configure Logging Server option, these systems are immediately operational after install.

Conversely, to facilitate distributed system administration, Logging Server objects can be created and managed outside the Logging Services container. In fact, in distributed environments, Logging Servers and their associated objects should be created in a context assigned to their administrator. To create Logging Server objects outside of the Logging Services container, you must manually create the objects using iManager.

For information on creating objects in your respective administrative tool, see Section 3.0, Nsure Audit iManager Plug-in.

4.2.2 Logging Server Objects

The Logging Server object represents the physical server where you have installed the Secure Logging Server. However, because the Logging Server object is specific to Nsure Audit, it does not replace the NCP Server object. Instead, each Logging Server object is associated with a host NCP Server object.

The Logging Server object is represented as a container with server attributes: it can contain Nsure Audit objects and it stores all the properties and attributes for the Secure Logging Server.

The following table provides an explanation of the Logging Server object's attributes.

Attribute

Description

Configuration

 

Host Server

The distinguished name of the NCP Server object associated with the current logging server.

Click the Object Selector button to select the Host Server in the tree.

Driver Directory

The directory in which the channel drivers (lgd*) are located.

The default channel driver directories are as follows:

  • sys:\system\ (NetWare)
  • \program files\novell\nsure audit\ (Windows)
  • /opt/novell/naudit/ (Linux)
  • /opt/NOVLnaudit/ (Solaris)

Log Channel

The Channel object the logging server uses to create the central data store.

Click the Object Selector button to select the Channel object in the tree.

WARNING:The JDBC and Java channels do not work on NetWare 5.x. These channels require JVM 1.4.2 which is not compatible with NetWare 5.x. Attempting to run either the JDBC or Java channel on NetWare 5.x abends the server.

Secure Logging Certificate File

The path and filename for the Logging Server Certificate.

This attribute enables the logging server to use a custom certificate created with the AudCGen utility. If this field is left blank, the logging server uses the default embedded certificate.

IMPORTANT:Nsure Audit only recognizes certificates that are generated with the AudCGen utility. For information on generating custom certificates, see Section 10.3, Creating the Secure Logging Certificate.

NSure Audit uses certificates to authenticate client connections. The logging server only accepts connections from applications that have a valid Logging Application Certificate.

For general information on how certificates are used in Nsure Audit, see Section 10.0, Security and Non-Repudiation.

Secure Logging Privatekey File

The path and filename for the Secure Logging Certificate's private key file.

If this field is left blank, the logging server assumes the private key is included with the certificate and uses the path and filename for the Secure Logging Certificate.

Again, this is only required if you do not use the Nsure Audit program's embedded certificates.

IMPORTANT:Nsure Audit only recognizes certificates and private keys that are generated with the AudCGen utility. For more information, see Section 10.3, Creating the Secure Logging Certificate.

Containers

IMPORTANT:The logging server scans these containers only at startup. Therefore, if you add a container, you must restart the logging server. For information on restarting the Secure Logging Server, see Section G.3, Secure Logging Server Startup Commands.

Application Containers

The Application containers supported by the current Logging Server object.

Application containers provide a reference point through which the logging server can locate Application objects. Application containers must be included in this list for the logging server to locate their associated Application objects. For more information on Application containers and objects, see Application Objects.

The Application container in Logging Services is added to this list by default.

Notification Containers

The Notification containers supported by the current Logging Server object.

Notification containers provide a reference point through which the logging server can locate Notification Filter and Heartbeat objects. Notification containers must be included in this list for the logging server to locate their associated Notification objects. For more information, see Notification Objects.

The Notification container in Logging Services is added to this list by default.

Channel Containers

The Channel containers supported by the current Logging Server object.

Channel containers provide a reference point through which the logging server can locate Channel objects. Channel containers must be included in this list for the logging server to locate their associated Channel objects. For more information on Channel containers and objects, see Configuring System Channels.

The Channel container in Logging Services is added to this list by default.

Memory

The memory configuration settings allow you to optimize your logging server's performance. You should adjust these settings based on logging traffic and the amount of memory available to your system. Reasonable values depend on your network.

In organizations that require high-performance logging, these parameters should be set high enough to accommodate peak loads.

For organizations that must minimize potential data loss, these settings should be very small. Although this might slow performance, it minimizes the amount of data that might be lost in the event of server failure.

If incoming log events exceed the amount of memory you have allocated on your logging server, the Platform Agents temporarily write events to their Disconnected Mode Caches until the logging server clears its cache. This prevents any logged events from being lost.

Minimum

The amount of memory the server automatically allocates at boot time to handle logging processes.

Because allocating additional memory on the fly can slow down code execution, this setting should represent the minimum amount of memory needed to handle your system's baseline level of logging traffic. Pre-allocating the minimum amount of memory required by your system reduces additional blocking delays when the system is under high load and facilitates faster processing of incoming events.

Normal

The amount of memory the server can immediately allocate if logging traffic exceeds the Minimum memory setting.

Maximum

The maximum amount of memory that can be allocated to logging processes.

Setting a maximum prevents Nsure Audit from monopolizing the server's resources. Ideally, this should be set close to the Normal memory setting.

If logging traffic exceeds the Normal memory setting, the server incrementally increases the logging cache 4 KB at a time. (4 KB is the amount of memory required to process a single event.) When the Maximum memory allocation is reached, the server begins dropping Platform Agent connections. If the logging server drops its connection, the Platform Agent simply logs events to its Disconnected Mode Cache, thereby ensuring no information is lost. When free cache is available, the logging server once again accepts Platform Agent connections.

Status

This option allows you to enable or disable the Secure Logging Server. By default, the logging server is enabled.

If you mark the Disabled option, you must either restart the server or manually unload the Secure Logging Server for this setting to become effective. Thereafter, the server cannot launch the Secure Logging Server (lengine) until you mark Enabled.

For information on unloading the logging server, see Section G.3, Secure Logging Server Startup Commands.

4.2.3 Configuring Multiple Secure Logging Servers

By default, the installation program creates the Secure Logging Server in the Logging Services container. The logging server then reads its channel and notification configuration information from the Channels.Logging Services and Notifications.Logging Services containers and loads the channels and notifications located within these containers.

If you want to provide system redundancy or load balancing in your logging system, you can create multiple Secure Logging Server objects for servers on the same platform in the default Logging Services container. In this way, all the logging servers load the same channels and send data to the same database.

However, if you want to log data to different databases (such as in a WAN environment); load different channels and notifications on each logging server; if you have an extremely large eDirectory tree; or if you are running Nsure Audit Secure Logging servers on multiple platforms, we recommend that you create separate eDirectory organizational units as containers for each Secure Logging Server’s configuration object.

If you want a combination of both configurations—for example, you want to provide system redundancy or load balancing in a WAN environment—you can create multiple eDirectory organizational units with multiple Secure Logging Server objects.

The following sections review how to implement multiple Secure Logging Servers in your logging system based on whether you want to locate the Secure Logging Server objects in the same container, different containers, or a combination of both:

Creating Multiple Secure Logging Server Objects in a Single eDirectory Container

IMPORTANT:Creating multiple Nsure Audit Secure Logging Server objects in a single eDirectory container works best if the objects are use the same platform. If you create multiple Nsure Audit Secure Logging Server objects from different platforms in the same container, it can mix the servers’ configuration information. If you are running Nsure Audit Secure Logging servers on multiple platforms, we recommend that you create separate eDirectory organizational units as containers for each Secure Logging Server’s configuration objects. For more information, see Creating Secure Logging Server Objects in Different eDirectory Containers.

To provide redundancy in your logging system:

  1. Create multiple Secure Logging Server objects in the default Logging Services container so that all the logging servers load the same channels and send data to the same database.

  2. Configure the Platform Agents to shut down and start logging to another log server if the Secure Logging Server goes down.

    To configure the Platform Agents to connect to multiple logging servers in a failover manner:

    1. Add the IP address of each failover logging server to the LogHost entry in the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file.

    2. List the logging servers in the order you want to use them in the event of a failover.

      The Platform Agents connect to the servers in the order specified in the configuration file. Therefore, if the first logging server goes down, the Platform Agent tries to connect to the second logging server, and so on.

    3. Separate each IP address in the LogHost entry with commas. For example, LogHost=192.168.0.1,192.168.0.3,192.168.0.4.

  3. For a failover configuration, you might also consider running the database server on a server separate from the logging servers.

The logevent configuration files can also be modified for load balancing. A Nsure Audit logging server can log approximately about 5,000 events per second on a P4 Xeon class server to a MySQL database; however, the database is capable of processing much more data than that. If you run multiple logging servers with the same configuration from the same eDirectory container, all logging servers log to the same location and process the same notification list. As a group, the logging servers can then log much more data to the data store.

To configure load balancing:

  1. Modify the LogHost entry in the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file for each Platform Agent so that it logs to a different Secure Logging Server.

    For example, one Platform Agent sends data to 192.168.0.1, while another Platform Agent sends data to 192.168.0.3. In this way, you can maximize the number of events that can be logged to your data store.

Creating Secure Logging Server Objects in Different eDirectory Containers

Creating separate eDirectory organizational units as containers for each Secure Logging Server’s configuration objects is an effective option under the following circumstances:

  • If you want to log data to different databases (such as in a WAN environment)
  • If you want to load different channels and notifications on each logging server
  • If you have an extremely large eDirectory tree
  • If you are running Nsure Audit Secure Logging servers on multiple platforms

The following sections review how to configure multiple Secure Logging Servers in different eDirectory containers.

Creating Multiple Containers for Audit Configuration Objects

The ability to create organizational units is not a function of the Nsure Audit install utility. It must be done with iManager or another eDirectory management utility.

The following steps outline the process required to separate the Nsure Audit containers.

IMPORTANT:This procedure assumes that you installed Nsure Audit with the default containers.

  1. Within iManager, create a new organizational unit for Nsure Audit objects (such as NAudit or Logging Services).

  2. (Optional) If you are running Secure Logging Servers on multiple platforms, create organizational units for each platform——that is, NetWare, Windows, Linux, and Solaris— under the Naudit or Logging Services container.

  3. Verify that eDirectory is healthy by checking replica synchronization.

    For more information, see TID10060600, NDS / eDirectory Health Check Procedures - Cross Platform.

  4. Use iManager's Partitions and Replica Management task to create partitions for all subcontainers and objects under the default Logging Services container—that is Channel, Application, Notification, and Logging Server objects—in preparation to move these objects.

  5. Use iManager's Partitions and Replica Management task to move the Channel, Application, Notification, and Logging Server objects to the new organizational unit created in Step 2.

  6. Use iManager's Partitions and Replica Management task to merge the partitions for the Channel, Application, Notification, and Logging Server objects back into the parent partition.

  7. Use iManager's Rights tasks to add the Logging Server object as a Trustee of its parent organizational unit.

    If you are running Secure Logging Servers on multiple platforms, the parent organizational unit is the associated platform container (NetWare, Windows, Linux, or Solaris).

    Modify Trustees dialog

    Each Secure Logging Server object needs Read and Compare attribute rights and Compare entry rights for its parent container and contents.

  8. To verify that Audit is functioning correctly, unload lengine at the server, then reload it.

  9. Remove the default Logging Services container at the root to prepare for the next Secure Logging Server installation.

    After you remove the default Logging Services container, the tree is ready for you to install the next Secure Logging Server.

  10. When the installation programs asks, Use Default Container? Y during subsequent Secure Logging Server installations, choose N and select the organizational unit you created in Step 2.

Configuring the Secure Logging Server to Use Custom Containers

To configure a logging server to use a custom channel container:

  1. Click the Roles and Tasks button iManager Roles and Tasks button on the iManager toolbar.

  2. In the Roles and Tasks view, click Directory Administration > Create Object > Nsure Audit Channel Container > OK.

  3. On the Create Nsure Audit Channel Container page, specify a channel name and context, then click OK.

    For the context, browse to and select the appropriate Logging Server object in the tree.

  4. In Roles and Tasks, click Auditing and Logging > Logging Server Options, browse to and select the Logging Server object, then click OK.

  5. Click the Channels tab or select Channels from the drop-down menu, depending on your browser.

  6. Click Container Actions > Add Container.

  7. On the Object Selector page, browse to the new container you created in the logging server container.

  8. To remove the original Channels container from the logging server configuration, go to the Channels page, select the Channels check box, then click Container Actions > Remove Container.

  9. Repeat this process for each logging server.

To configure a logging server to use a custom notification container:

  1. In iManager, click Roles and Tasks > Directory Administration > Create Object > Nsure Audit Notification Container > OK.

  2. On the Create Nsure Audit Notification Container page, specify a notification name and context, then click OK.

    For the context, browse to and select the appropriate Logging Server object in the tree.

  3. In Roles and Tasks, click Auditing and Logging > Logging Server Options; browse to and select the Logging Server object, then click OK.

  4. Click the Notifications tab or select Notifications from the drop-down menu, depending on your browser.

  5. Click Container Actions > Add Container.

  6. On the Object Selector page, browse to and select the new container created in the logging server container.

  7. To remove the original Notifications container from the logging server configuration, select the Notifications check box in the Notifications page, then click Container Actions > Remove Container.

  8. Repeat this process for each logging server.

Creating Multiple Secure Logging Server Objects in Multiple eDirectory Containers

If you want to provide system redundancy or load balancing in a large eDirectory tree or a WAN environment, you must configure multiple Secure Logging Server objects in multiple eDirectory containers.

The following steps outline the general process required to implement this configuration:

  1. Identify the Secure Logging Servers that should load the same channels and send data to the same location.

  2. Create a custom Channels container in the default Logging Services container for each server group.

    For information on creating a custom Channels containers, see Creating Multiple Containers for Audit Configuration Objects.

  3. Add the Secure Logging Server objects in each server group to the Trustees List for their associated Channels container.

    Modify Trustees dialog

    Each Secure Logging Server object needs Read and Compare attribute rights and Compare entry rights for the Channels container and its contents.

  4. Configure each Secure Logging Server object’s channel configuration so it references the server’s associated Channel container.

  5. Remove the original Channels.Logging Services container object from each Secure Logging Server object’s channel configuration.

  6. Configure the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file for each Platform Agent so that it logs events to a specific server group.

    To configure the Platform Agents to connect to multiple logging servers in a failover manner:

    • Add the IP address of each failover logging server to the LogHost entry in the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file.
    • List the logging servers in the order you want to use them in the event of a failover.

      The Platform Agents connect to the servers in the order specified in the configuration file. Therefore, if the first logging server goes down, the Platform Agent tries to connect to the second logging server, and so on.

    • Separate each IP address in the LogHost entry with commas. For example, LogHost=192.168.0.1,192.168.0.3,192.168.0.4.

    To configure load balancing:

    • Modify the LogHost entry in the logevent.conf (Linux and Solaris) or logevent.cfg (NetWare and Windows) file for each Platform Agent so that it logs to a different Secure Logging Server in the server group.

      For example, one Platform Agent sends data to 192.168.0.1, while another Platform Agent sends data to 192.168.0.3. In this way, you can maximize the number of events that can be logged to each server group’s data store.

4.2.4 Configuring a Secure Logging Server with More Than One IP Address

Secure Logging Servers with more than one IP address have problems running Nsure Audit because MDB does not know which IP address to use with eDirectory. You can point Nsure Audit to a specific IP address using an MDB configuration file.

The required filename and path for the MDB configuration file is as follows:

Table 4-3 MDB Configuration File

Platform

Directory

NetWare

sys:\etc\mdb.cfg

Windows

\windows\mdb.cfg

Linux

/etc/mdb.conf

Solaris

/etc/mdb.conf

To point Nsure Audit to a specific IP address for eDirectory, the MDB configuration file must store the following parameter:

driver=mdbds referral=eDirectory_IP_ Address 

For example,

driver=mdbds referral=192.168.123.45.