2.1 Novell Audit System Components

Novell Audit has a highly modular architecture. Product functions are strategically divided among several different components to protect data integrity, optimize system performance, and provide maximum flexibility. Depending on usage and system resources, these components can be located on a single server or distributed across multiple servers.

The full auditing system consists of the following components:

The Platform Agent, Secure Logging Server, and data store are the central components in this structure. To log events from system applications to the data store, Novell Audit uses a client/server model. The Platform Agent, as the client piece, receives all log data from the system applications. It securely transmits this data to the Secure Logging Server, which then writes the information to the data store.

Figure 2-1 Architecture Overview

Separating the Platform Agent from the actual logging function provides the following advantages:

The remaining Novell Audit component includes two reporting applications: iManager and Novell Audit Report. These supplementary tools allow you, as the administrator, to tap vital data from the system.

The following sections provide a discussion of each component in the Novell Audit architecture.

2.1.1 Platform Agent

The Platform Agent (logevent) is the client portion of the Novell auditing system. The Platform Agent receives logging information and system requests from authenticated applications and transmits the information to the Secure Logging Server. The Platform Agent must be installed on every server running applications that log events to Novell Audit.

For more information on program binaries, see Section I.1, Program Files and Directories. For more information on how applications authenticate with Novell Audit, see Section 9.1, Authenticating Logging Applications.

If the connection between the Platform Agent and the Secure Logging Server fails, applications continue to log events to the local Platform Agent, just as they always do. The Platform Agent simply switches into Disconnected Cache Mode and the Cache Module writes all logged events to the local cache until the connection is restored. The switch into Disconnected Cache Mode is completely transparent to the logging applications. For more information, see Disconnected Mode Cache.

Figure 2-2 The Platform Agent’s Disconnected Mode Cache

Supported Applications

Currently, the Platform Agent can receive log events from the following:

  • Novell eDirectory™ 8.7.3 and higher
  • Novell Identity Manager 2.0 and higher
  • NetMail® 3.5 and higher
  • iChain® 2.2 SP1
  • BorderManager® 3.8
  • NetWare 5.0 and higher
  • NetWare® NSS File System
  • NetWare Traditional File System
  • Windows 2000
  • Windows 2000 Server SP4 or later
  • Windows XP Professional and Home Editions
  • Windows 2003 Server

NOTE:Before an application can log events to Novell Audit, it must be able to authenticate with the system and report events in the auditing system’s required format. For more information on the authentication process, see Section 9.1, Authenticating Logging Applications. For more information on event structure, see Section A.1, Event Structure.

Supported Platforms

The Novell Audit architecture requires that the Platform Agent be locally installed on every server running applications that log events to Novell Audit.This design ensures secure, uninterrupted logging because the logging applications are insulated from external communication failures.

The Platform Agent is supported on the following platforms:

  • Open Enterprise Server 1.0 SP1 (NetWare and Linux)
  • NetWare 6.5
  • Windows 2000
  • Windows 2000 Server SP4 or later
  • Windows XP Professional and Home Editions
  • Windows 2003 Server
  • SUSE Linux Enterprise Server 9
  • Red Hat Linux 3 AS and ES
  • Solaris* 8, 9, and 10

Platform Agent Configuration

The Platform Agent is not configured through eDirectory. Instead, the Platform Agent’s configuration settings are stored in a simple, text-based configuration file (logevent.cfg). This makes the Platform Agent small, unobtrusive, and self-contained—that is, it has no external dependencies so it is always available to receive logged events. Storing the Platform Agent’s configuration in a text-based file also allows the Platform Agent to eventually run on platforms that do not have eDirectory support.

The logevent file stores the host name or IP address of the logging server, the Disconnected Mode Cache directory, port assignments, and other related information. For more information on Platform Agent configuration settings, including a sample logevent file, see Logevent.

2.1.2 Secure Logging Server

The Secure Logging Server (lengine) is the server component in the Novell auditing system.The Secure Logging Server manages the flow of information to and from the Novell auditing system—that is, 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. For more information on program binaries, see Section I.1, Program Files and Directories.

Figure 2-3 Secure Logging Server

The Secure Logging Server supports the following platforms:

  • Open Enterprise Server 1.0 SP1 (NetWare® and Linux*)
  • NetWare 6.5
  • Windows* 2003 Server
  • Windows 2000 Server SP4 or later
  • SUSE® Linux Enterprise Server 9
  • Red Hat* Linux 3 AS and ES
  • Solaris* 8, 9, and 10

    IMPORTANT:Solaris 8 requires GCC 3.3 and zlib 1.2.3 to function as a Secure Logging Server. Without GCC3.3, applications fail to authenticate to the logging server. The resulting error in nproduct.log is, Failed SSL Handshake.

The Secure Logging Server configuration is stored in eDirectory. The Logging Server object contains all the configuration settings for the Secure Logging Server. Consequently, the logging server must have access to eDirectory and the Logging Server object before it can launch the Secure Logging Server. For more information, see Section 4.2, Configuring the Secure Logging Server

NOTE: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.

The Secure Logging Server provides the following services:

Figure 2-4 The Secure Logging Server Services

A description of each service follows.

Event Management

The Event Manager receives all incoming data from the Platform Agents and directs the information to the appropriate service. It also routes outgoing information from the logging server to the appropriate Platform Agent.

This mode of operation is very efficient. Indeed, the Event Manager service is designed to maximize system efficiency and performance. Depending on the Secure Logging Server’s cache settings and hardware resources, the Event Manager can handle more than 30,000 events per second. For information on configuring the Secure Logging Server’s cache, see Logging Server Object Attributes .

Logging Service

The Logging Service is the only Novell Audit component that can write to the data store. This design protects log data from unauthorized record modification, insertion, or deletion.

To ensure that the auditing system maintains accurate records, the Event Manager delivers all incoming data directly to the Logging Service. All events and requests must be recorded in the data store before the Event Manager sends them to the Monitoring or Notification services.

Write times vary per storage option. On a P4 Xeon* class server, the Logging Service can write approximately 30,000 events per second to a flat file in a file system or 5,000 events per second to a MySQL database.

Using the logging server’s channels, the Logging Service can write events to the following storage devices:

  • JDBC-enabled database
  • JMS
  • Flat file in the file system
  • MySQL database
  • Oracle database
  • Syslog database
  • Microsoft SQL Server database

NOTE:Although you can actually use any channel to log events, for performance reasons we recommend that you only log to the Syslog, MySQL, Oracle, Microsoft SQL Server, or File channels for your primary data store.

For more information on configuring these channels, see Section 6.0, Configuring System Channels.

Notification Service

The Notification Services provides two types of notification: filtered and heartbeat notification. Filtered notification tells you when a specific event has occurred; heartbeat notification tells you when an event has not occurred.

In both cases, the Notification Service identifies the event and routes it to specific channels. For example, the Notification Service can send a notification event to a system administrator’s mailbox or cell phone using the SMTP channel, route the event to the network management system as an SNMP trap, or write the event to a flat file in the file system or to a Syslog, MySQL, Oracle, or SQL Server database.

Both filtered and heartbeat notifications are configured in eDirectory using Notification Filter and Heartbeat objects. These objects define event criteria and designate which Channel objects are used to provide event notification. For more information, see Notification Objects.

Logging and Notification Channels

The Secure Logging Server uses channels to log events and provide event notification. For example, to e-mail events, the logging server uses the SMTP channel; to log events to an Oracle* database, the logging server uses the Oracle channel; and so forth.

Novell Audit currently supports the following channels:

CVR (Critical Value Reset)

File

Java*

JDBC*

JMS

Microsoft* SQL Server

Monitor

MySQL*

Oracle (Available on NetWare using the Java JDBC channel driver.)

SMTP

SNMP

Syslog

Third-party channels can be easily incorporated into this structure. For more information, see the Novell Audit SDK.

Channels are configured in eDirectory using Channel objects. Each Channel object stores the information the logging server needs to use its associated channel. For further information, see Channel Objects.

Figure 2-5 The Secure Logging Server Channels

2.1.3 Data Store

Using its available channel drivers, Novell Audit can log events to the following storage devices:

  • JDBC-enabled database
  • Flat file in the file system
  • MySQL database
  • Oracle database
  • Microsoft SQL Server database
  • Syslog database

Novell Audit protects log data from record modification, insertion, or deletion by allowing only one program component, the Logging Service, to write events to the data store. Novell Audit also limits read access to log data by controlling which applications can request log information through the auditing system. However, the security of the data store itself is up to you and the security mechanisms provided by the database. Although Novell Audit maintains an internal security perimeter around the data store, it is possible for individuals or applications to directly access the data store outside the boundaries of the auditing system. Therefore, file system rights, directory rights, and the database’s internal security features must be carefully configured to secure your log data.

For further information, see Section 4.3, Configuring the Data Store .

2.1.4 Reporting Applications

Novell Audit provides two tools that can be used to generate reports from MySQL, Microsoft SQL Server, and Oracle data stores.

NOTE:Any standardized syslog reporting tool can be used to generate reports from syslog data stores.

  • Novell Audit Report is a Windows-based, ODBC-compliant application that can generate reports from Oracle and MySQL data stores. It includes predefined reports and can be integrated with Crystal Reports* to provide full custom reporting capabilities.
  • iManager is a browser-based, JDBC-compliant application that can generate reports from MySQL data stores.
  • LETrans is a command line utility that translates raw text log files into human-readable form. It also includes the ability to query an ODBC data source on your Windows machine, then translate and format the output.

For more information on generating reports with these tools, see Section 8.0, Generating Queries and Reports. Any standardized syslog reporting tool can be used to generate reports from syslog data stores.

Figure 2-6 Novell Audit Reporting Tools