Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

Chapter 6. Auditing and troubleshooting 199

6.1.1 Native auditing configuration

To enable logging, define the logcfg entry in any or all of the following locations:

򐂰 The [ivmgrd] stanza of the Policy Server ivmgrd.conf configuration file.

򐂰 The [ivacld] stanza of the authorization server ivacld.conf configuration file.

򐂰 The [aznapi-configuration] stanza of a WebSEAL server

webseald.instance.conf configuration file.

򐂰 The [aznapi-configuration] stanza of the Plug-in for Web Servers

pdwebpi.conf configuration file.

򐂰 The [aznapi-configuration] stanza of the resource manager aznAPI.conf

configuration file.

For each entry, specify the following:

򐂰 Type of audit event

򐂰 Location of the audit log

򐂰 Maximum file size

򐂰 File flush interval

When defining the logcfg entry in a configuration file, use the following general

format (on a single line) to specify audit event logging:

logcfg = category:{stdout|stderr|file|pipe|remote}

[[parameter[=value]], [parameter[=value]]], ..., [parameter[=value]]]

To enable the recording of audit events, associate an event category with a log

agent (file, pipe, or remote) or associate an event category with a console

destination (stdout or stderr).

With event logging, the concept of a

log agent includes capturing events that are

redirected to destinations other than the local file system. Event logging uses the

following types of log agents, each agent representing an audit trail:

򐂰 Sending events to the console.

򐂰 Configuring file log agents.

򐂰 Configuring pipe log agents.

򐂰 Configuring remote log agents.

The available parameters for the logcfg stanza entry differ by log agent. The

console log agent does not support parameters.

200 Certification Study Guide: IBM Tivoli Access Manager for e-business 6.0

Configuring the event pool category

Events are passed to subscribed log agents asynchronously from the

application-level requests that construct the events. All events enter the common

propagation queue before being forwarded to the subscribed log agents. The

propagation queue is configurable. To configure the propagation queue, define

the logcfg stanza entry using

EventPool as the category name and specify the

configuration parameters without specifying a log agent. You should manage the

propagation queue to support the configuration of log agents. For example, to

limit the amount of memory used to queue events for a remote log agent, you

should constrain the propagation queue with the queue_size parameter:

[aznapi-configuration]

logcfg = EventPool queue_size=number,hi_water=number,

flush_interval=number_seconds

logcfg = category:remote buffer_size=number,path=pathname,

server=hostname,queue_size=number

Parameters for EventPool audit category

The following parameters can be defined for pipe log agents:

flush_interval Configure the flush_interval parameter to limit the amount

of time in seconds that events can remain in the

propagation queue. If the size of the queue does not

reach the high water mark within the specified interval,

events in the queue are forwarded to the log agents. The

default value is 10 seconds. Specifying a value of 0 is

equivalent to setting the value to 600 seconds.

hi_water Configure the hi_water parameter to indicate the

threshold where events in the propagation queue are

forwarded to the log agents. If the size of the queue does

not reach this high water mark within the defined flush

interval, events in the queue are forwarded to the log

agents. The default value is calculated as two-thirds of the

configured queue size. If the queue size is 0 (unlimited),

the high water mark is set to 100 events. If the high water

mark is 1 event, each event in the queue is forwarded

immediately to the log agents. Setting a low value for the

high water mark can have an adverse effect on

performance.

queue_size Because each event in the propagation queue consumes

memory, configure the queue_size parameter to define

the maximum number of events that the propagation

queue can hold. If the maximum size is reached, the

event-producing thread is blocked until space is available