Audit Trail
An audit trail consists of
- An NDS® Audit File object
- A sequence of audit data files
The Audit File object and its Novell Directory ServicesTM (NDSTM) properties define the audit configuration and the rights of other NDS entities to access the Audit File object and its audit files. Refer to Audit File Object for more information.
The sequence of audit data files include the current audit file (where data is currently being recorded), up to 15 old online audit files, and a sequence of offline audit files.
As shown in Figure 1, each audit file consists of an audit header followed by a sequence of audit records, where each record contains information about a specific audit event. Refer to Audit File Formats for definitions of volume, container, and external audit file formats.
Figure 1
General Structure of Audit File
The complete audit trail consists of a sequence of audit records that potentially extends from the first audit event recorded on an offline audit file to the last audit event recorded on the current audit file. The audit file header includes a creation timestamp that determines the position of each audit file in the sequence.
Each audit record is timestamped with the originating server's local time. Events on different servers are synchronized by NDS time synchronization mechanisms, which usually maintain times on multiple servers to within a second of each other.
Audit records can logically be divided into two types:
- Audit history records, which record such management actions as examining or configuring the audit trail
- Audit event records, which record user actions that were audited by the NetWare server or an external client
Audit history and audit event records are physically stored together in audit data files. However, AUDITCON provides separate facilities to examine the two types of records.
Audit history records are always recorded if auditing is enabled; you cannot use preselection (advance specification of the events, users, and files to be audited) to avoid recording audit history records.
A NetWare server manages the types of audit trails shown in Table 1.
Table 1. NetWare Audit Trails
Volume audit trails |
A volume audit trail is associated with a single volume on a single server. The audit data is stored in the volume on that server. The volume audit trail contains audit history events for the volume audit trail, plus security-relevant events recorded by the server's operating system (mount volume, for example) and file server software (file open and file deletion, for example). The audit configuration (rules for generating audit events and other items) is specified by volume, so that auditing can be enabled for one volume and disabled for another volume. Volume audit events can be preselected based on event type, user identity, and (for certain file system events) on filename. In addition to the events that can be recorded in each volume audit trail, the SYS: volume audit trail can also record events detected by the server's operating system. These include console events, such as loading NLMTM programs and defining SET parameters. Because the server does not provide a mechanism for logging in administrators at the server console, console auditing must be supported by a manual log that identifies which administrator is using the server console. |
Container audit trails |
Container audit trails record security-relevant Novell Directory Services (NDS) events performed in the associated NDS container object, as well as audit history records for the audit trail. Because NDS is a distributed database, container audit trails are associated with the distributed NDS container object and not with any specific server (as with volume audit trails). Container audit trails (but not necessarily all events in the audit trail) are replicated to each partition holding the audited container object. The audit configuration is specified separately for each audited NDS container object. Preselection of container audit events can be configured in one of two ways: event only (this is the default) or auditor by user as well as by event. Auditing of a particular container object (an Organization object, for example) does not imply auditing of subcontainers within the audited container (its Organizational Unit objects, for example). |
External audit trails |
The server provides external audit trails that can be used by trusted clients to store audit data on the server. External audit trails also contain audit history records. Preselection of client-generated audit records is performed by the client before submission of audit records to the server. The NetWare server sees the external audit information as a stream of un-interpreted data; interpretation of the audit events is performed solely by the client Trusted Computing Base (TCB). |
Figure 2 shows an example of these audit trails on a two-server network. Each of the audit trails is maintained, configured, and controlled separately. Each server can have its own volume audit trail and each NDS container can have its own container audit trail.
Server 1 has eight audit trails: volumes SYS:, BETA:, and GAMMA:; containers ACME, SALES.ACME, and LAB1.ENGR.ACME; and external client audit trails EXT1 and EXT2.
Server 2 has six audit trails; volumes SYS:, ALPHA:, and ZETA:, and containers ACME, SALES.ACME, and LAB1.ENGR.ACME.
NDS is a global network database. The description of a particular server having a container audit trail assumes that the container exists in an NDS partition that is replicated on that server.
If a container is in a partition that is found only on Server One, then Server Two would not have a copy of that container audit trail.
Figure 2
Examples of NetWare Audit Trails
