Novell Documentation: NetWare 6 - Controlling Access to Online Audit Data

Controlling Access to Online Audit Data

The server provides two separate methods for controlling access to online audit configuration data and recorded audit files:

NDS^® provides an Audit File object for each audit trail that defines the access rights to the audit configuration and audit data. Audit File Object describes the NDS object property rights that mediate access to the audit trail. The server checks the Audit File object's NDS rights when you try to access an audit trail or make changes to the Audit File object properties. If this check succeeds, the user can access the audit trail. This is the only approach that is permitted for NetWare^® servers.

For compatibility with previous releases, NetWare also supports an optional password-based access control method. This option is enabled on individual servers by setting the ALLOW AUDIT PASSWORDS console parameter. If audit passwords are enabled at the server console, the single-level audit password controls access to all aspects of the audit trail.

You can also configure the audit file to use dual-level passwords, where the first level password is required to view the audit data and the audit configuration, and the second level password is required to change the audit configuration.

The default value for ALLOW AUDIT PASSWORDS is OFF, meaning that access to the audit data is controlled solely by the Audit File object's object property rights.

However, administrators can configure servers to permit the use of audit passwords. Such configuration is done on a server-by-server basis, so that mixed configurations are possible---some servers using the Audit File object rights-based access controls and other servers using audit passwords.

When an audit utility (AUDITCON, for example) creates an Audit File object, the server gives the creator the following rights:

The Supervisor right [Entry Rights] to the Audit File object

The Write right to the Access Control List property

AUDITCON also assigns additional rights. The following rights are assigned to the creator of the Audit File object:

Read and Write rights to the Audit Policy property

The Read right to the Audit Contents property

These rights allow the auditor who created the Audit File object to read audit files, change the audit configuration data, and assign access rights to other auditors. If you are working in a single-auditor environment, this might be sufficient for your needs. You (or any other user with the Write rights to the Audit File object Access Control List property) can use NetWare Administrator (NWADMIN), or other utilities to define rights for other auditors.

NOTE: See your client documentation for information on the availability of NetWare Administrator in your client evaluated configuration.

You can have three logical groupings of rights. (These rights groupings are conceptual; you can organize rights any way you find convenient.)

Audit Viewers (who are responsible for reviewing audit trails, looking for anomalies, and generating reports)

Audit Administrators (who are responsible for the tasks of Audit Viewers and are also responsible for configuring the audit subsystem and performing audit data backup and recovery)

Audit Sources (which are client NTCB partitions that append audit records to server audit trails)

Table 3 shows the rights required for each of these three groups.

Table 3. Auditor Access Profiles

Auditor Access Profile	NDS-Based Access	Password-Based Access
Audit Viewer	R to Audit File object Audit Policy R to Audit File object Audit Contents	Level 1 password
Audit Administrator	R to Audit File object Audit Policy W to Audit File object Audit Policy R to Audit File object Audit Contents	Level 2 password
Audit Source (a specific volume, container, or external source)	W to Audit File object Audit Contents R to Audit File object Audit Path	N/A

Auditor Access Profile

NDS-Based Access

Password-Based Access

Audit Viewer

R to Audit File object Audit Policy

R to Audit File object Audit Contents

Level 1 password

Audit Administrator

R to Audit File object Audit Policy

W to Audit File object Audit Policy

R to Audit File object Audit Contents

Level 2 password

Audit Source (a specific volume, container, or external source)

W to Audit File object Audit Contents

R to Audit File object Audit Path

N/A

The server checks whether you have the appropriate rights when performing each action and refuses to perform the action if you don't have those rights. If you revoke access rights to an auditor who is already accessing an audit file, these changes do not take effect until the auditor tries to reestablish access to the volume or container audit trail.

AUDITCON doesn't modify rights to the Access Control List property. You can use NetWare Administrator to assign other users rights to the Access Control List property.

See your client documentation for information on the availability of NetWare Administrator and in your client evaluated configuration.

WARNING: Do not give untrusted users (individuals who are not auditors or administrators) any rights to the Audit File object (or its properties) except the Browse right.

There is more than one way to establish these rights. You could create several Organizational Role objects for each grouping of related audit trails.

For example, you might have an object called Engineering Partition Audit Viewer that would be a trustee with the Read right to the Audit Policy and Audit Contents properties of the Audit File object associated with each container in the Engineering partition.

Another object called Engineering Partition Audit Administrator could be a trustee with the Read and Write rights to the Audit Policy and Audit Contents properties of the Audit File object for each of the same containers.

Individual administrators could then be made security equivalent to whichever Organizational Role object is appropriate for their responsibilities. Alternately, individual users could be made trustees of those Audit File objects that they are responsible for managing.

There is no requirement to divide up the rights to audit files. In some organizations, a group of administrators has the authority to manage all aspects of the organization, including audit management. In this case, all individuals in that group might have the Supervisor right to the root of the Directory tree, with no Inherited Rights Filters to block rights. In this scenario, there is no need to directly assign rights to properties of an Audit File object, since the administrators will gain those rights through inheritance.

WARNING: The server does not provide any locking mechanism to prevent multiple auditors from simultaneously attempting to change volume, container, or external audit configuration data. If this occurs, the last auditor to write the audit configuration might overwrite changes made by other auditors. If you have more than one auditor who has rights to modify the audit configuration, you must institute procedural methods to control access to the Audit File object, such as selecting a single replica of the Audit File object and making all changes to that replica.