When you use the Common Auditing Service, you must configure the
server-specific Common Auditing Service client to record specific audit events.
All audit events can contain the following information:
v The machine name and application that generates the event. The machine name is recorded by using the location element. The application name is recorded by using the component and subcomponent elements.
v The time when the event was generated. The time is recorded by using the timestamp (creationTime), startTime, and endTime elements.
v The type of event. The event type is recorded by using the eventType element. v The user who triggered the event. The user information is recorded by using the
appUserName, domain, location, locationType, and sessionId elements. The sessionId element is a unique identifier that is associated with the session of which the event was part. This unique ID (sometimes called a session index) can be used to correlate a particular resource access event with an earlier
authentication event.
v The outcome of the operation. The outcome is recorded by using the result and failureReason elements. The outcome distinguishes successful and unsuccessful operations. For example, most attempts to authenticate a user are successful, because the user provides valid authentication data. However, when an
authentication is unsuccessful, the origin of the failure might be that someone is attempting to impersonate another user.
In addition to this information, each event type might record more information about the event. For more information about the elements that can be recorded in an audit event, see Part 6, “Audit events,” on page 223.
Type of audit events
The configuration of the server determines which audit events are recorded. Security Access Manager uses the following Common Auditing Service events: v AUDIT_AUTHN v AUDIT_AUTHN_CREDS_MODIFY v AUDIT_AUTHN_TERMINATE v AUDIT_AUTHZ v AUDIT_MGMT_CONFIG v AUDIT_MGMT_POLICY v AUDIT_MGMT_REGISTRY v AUDIT_MGMT_RESOURCE v AUDIT_PASSWORD_CHANGE v AUDIT_RESOURCE_ACCESS v AUDIT_RUNTIME
Common Auditing and Reporting Service provides the following events. However, Security Access Manager does not take advantage of them:
v AUDIT_AUTHN_MAPPING v AUDIT_COMPLIANCE v AUDIT_DATA_SYNC
v AUDIT_RUNTIME_KEY v AUDIT_WORKFLOW
AUDIT_AUTHN_CREDS_MODIFY events provide information about modifications credentials for a user identity.
AUDIT_AUTHN
AUDIT_AUTHN events provide information about authentication. The record includes the following information:
v The type of authentication used. For example, the record might show
basicAuthRFC2617for an HTTP basic authentication or show certificate for a public key authentication.
v The user who requested authentication.
v Whether the authentication was successful. If the authentication failed, the record shows the reason for the failure. For example, the record might show that the account was locked out because of repeated password authentication
failures.
AUDIT_AUTHN_CREDS_MODIFY
AUDIT_AUTHN_CREDS_MODIFY events provide information about modifications of credentials for a user identity.
AUDIT_AUTHN_TERMINATE
AUDIT_AUTHN_TERMINATE events provide information about when a user ends a session. The record includes information about the user whose session is ending and the reason why that session is ending. Sessions can end for many reasons, including a log out by a user, an administrator action to end a session for a user, or a timeout.
Note: When you use the session management server for session storage, configure
the session management server to generate the AUDIT_AUTHN_TERMINATE events. Because WebSEAL and the Web server plug-in cannot determine when the session ends, they cannot generate the AUDIT_AUTHN_TERMINATE event.
AUDIT_AUTHZ
AUDIT_AUTHZ events provide information about authorization decisions.
A WebSEAL record includes the following information:
v The user who attempted access. For example, the record might show joe as the user.
v The object that the user attempted to access. For example, the record might show /WebSEAL/www.example.com-default/index.htmlas the object.
v The permission that is needed for access. For example, the record might show r for read permission.
v The access decision. For example, the record might show permitted or denied as the access decision. The access decision is not necessarily final. The ultimate decision depends on the application that is making the authorization check.
Consider the situation when user joe attempts to access the index.html web page. Joe has the permission to access this object, but he might still be denied access. Assume that the policy associated with the object requires clients to use an
encrypted transport to view the object. If Joe attempts to access the object by using the HTTP transport protocol, he is denied access although the outcome of the access record shows permitted.
Plug-in for Web Servers does not generate AUDIT_AUTHZ events.
Application-level authorization results generate AUDIT_RESOURCE_ACCESS events.
AUDIT_MGMT_CONFIG
AUDIT_MGMT_CONFIG events provide information about configuration and other management operations for a server. These events apply to the policy server and policy proxy server only.
AUDIT_MGMT_POLICY
AUDIT_MGMT_POLICY events provide information about security policy management operations, such as the creation of an access control list, protected object policy, or an authorization rule. These events apply to the policy server and policy proxy server only.
AUDIT_MGMT_REGISTRY
AUDIT_MGMT_REGISTRY events provide information about the users and groups in the user registry, such as creating users and groups or modifying properties for users and groups. These events apply to the policy server only.
AUDIT_MGMT_RESOURCE
AUDIT_MGMT_RESOURCE events provide information about resource
management operations. These events apply to the policy server and policy proxy server only.
AUDIT_PASSWORD_CHANGE
AUDIT_PASSWORD_CHANGE events provide information about a password change. These events are generated when users change their passwords or when an administrator changes the password.
Plug-in for Web Servers generates AUDIT_PASSWORD_CHANGE events only for user-initiated password changes, not administrator-initiated password changes.
AUDIT_RESOURCE_ACCESS
AUDIT_RESOURCE_ACCESS events provide information about access to a resource, such as a file or HTTP request or response events outside of AUDIT_AUTHZ events.
AUDIT_RUNTIME
AUDIT_RUNTIME events provide information about servers. These events are generated when a server starts or stops. Runtime events can also include heartbeat events that verify whether a server is running, and statistical events.
Audit events by server
Each Security Access Manager server supports different audit events. The following list shows which Common Auditing Service events can be used with each Security Access Manager server:
Policy and policy proxy server
The policy server and the policy proxy server can generate the following events that can be recorded by the Common Auditing Service:
v AUDIT_AUTHN v AUDIT_MGMT_CONFIG v AUDIT_MGMT_POLICY v AUDIT_MGMT_REGISTRY v AUDIT_MGMT_RESOURCE v AUDIT_RUNTIME Authorization server
The authorization server can generate the following events that can be recorded by the Common Auditing Service:
v AUDIT_AUTHZ v AUDIT_RUNTIME
WebSEAL
Each WebSEAL instance can generate the following events that can be recorded by the Common Auditing Service:
v AUDIT_AUTHN
v AUDIT_AUTHN_TERMINATE v AUDIT_PASSWORD_CHANGE v AUDIT_RESOURCE_ACCESS v AUDIT_RUNTIME
For definitive information about whether a WebSEAL server allowed access to a resource, use AUDIT_RESOURCE_ACCESS events.
Plug-in for Web Servers
Each Web server plug-in can generate the following events that can be recorded by the Common Auditing Service:
v AUDIT_AUTHN v AUDIT_AUTHN_CREDS_MODIFY v AUDIT_AUTHN_TERMINATE v AUDIT_PASSWORD_CHANGE v AUDIT_RESOURCE_ACCESS v AUDIT_RUNTIME
Plug-in for Web Servers does not generate AUDIT_AUTHZ events. The results for application-level authorization generate
AUDIT_RESOURCE_ACCESS events.
Plug-in for WebLogic server
The Plug-in for WebLogic server does not generate events that can be recorded by the Common Auditing Service.
Session management server
Each instance of the session management server can generate the following events that can be recorded by the Common Auditing Service:
v AUDIT_AUTHN
v AUDIT_AUTHN_TERMINATE v AUDIT_AUTHZ
Chapter 15. Common Auditing Service for C-based Security
Access Manager servers
If you are using a C-based Security Access Manager server, use the Common Auditing Service embedded C client to send audit events to the Common Auditing Service audit server. Event configuration for the C client is controlled with the server-specific auditing configuration files. To start sending events to the audit server, you must generate the initial configuration files and parameter settings by running the amauditcfg utility. The required procedure is described in
“Configuring to send audit events through the C client.”
After you generate the initial configuration file settings by using the amauditcfg utility, use the pdadmin config modify command to change settings in the
configuration files. Do not use an ASCII editor to modify a configuration file. For information about modifying configuration files, see “Using the config modify command for auditing” on page 145.
Configuring to send audit events through the C client
To start the sending of events to the Common Auditing Service audit server through the C client, use the amauditcfg utility.
About this task
The amauditcfg utility configures a Security Access Manager server to start (or stop) by using Common Auditing Service.
The amauditcfg utility generates the server-specific auditing configuration files that are described in “Common Auditing Service configuration files” on page 142. After these files are generated, use the pdadmin config modify command to change one or more configuration settings in the files.
For complete information about using the amauditcfg utility, including how to enable secure communications with the audit server, see “amauditcfg” on page 415.
Procedure
v The following example shows a simple way to use the amauditcfg utility to configure the use of Common Auditing Service:
amauditcfg -action config -srv_cfg_file configuration_file -audit_srv_url url
v The following example shows how to use the amauditcfg utility to configure the default WebSEAL server. The WebSEAL server is on an AIX system. Use the configuration to set up Common Auditing Service over a secure (SSL) connection:
/opt/PolicyDirector/sbin/amauditcfg -action config \ -srv_cfg_file /opt/pdweb/etc/webseald-default.conf \
-enable_ssl yes -audit_key_file /certs/WSclient.kdb -audit_stash_file \ /certs/WSclient.sth -enable_pwd_auth yes -audit_id root \
-audit_pwd da21cars -audit_srv_url \
http://carsserver.example.com:9443/CommonAuditService/services/Emitter
Gathering system information. Parsing the command line. Validating the information.
Configuring the server for common auditing and reporting services. Configuration completed successfully.
Common Auditing Service configuration files
Running the amauditcfg utility generates the following configuration files to control the configuration of the Common Auditing Service C clients.
These configuration files are used for auditing and statistics purposes:
pdaudit.pdmgr.conf
Configure the Common Auditing Service for the Security Access Manager policy server. Do not confuse this configuration file with the ivmgrd.conf configuration file.
pdaudit.pdproxymgr.conf
Configure the Common Auditing Service for a Security Access Manager policy proxy server. Do not confuse this configuration file with the pdmgrproxyd.confconfiguration file.
pdaudit.pdacld.conf
Configure the Common Auditing Service for the Security Access Manager authorization server. Do not confuse this configuration file with the ivacld.conf configuration file.
pdaudit.instance-webseald-host.conf
Configure the Common Auditing Service for a specific instance of a Security Access Manager WebSEAL server. Do not confuse this configuration file with the webseald-instance.conf configuration file.
pdaudit.webpi.conf
Configure the Common Auditing Service for a Security Access Manager Plug-in for Web Servers. Do not confuse this configuration file with the pdwebpi.confconfiguration file.
pdaudit.appsvr.conf
Configure the Common Auditing Service for any Security Access Manager resource managers. Do not confuse this configuration file with the
aznAPI.conf configuration file.
For more information about these configuration files, see “Configuration file reference” on page 377.
Policy server: Configuration Settings
Running the amauditcfg utility sets the following entries in the pdaudit.pdmgrd.conf configuration file:
[cars-filter] auditevent=authn auditevent=mgmt_config auditevent=mgmt_policy auditevent=mgmt_registry auditevent=mgmt_resource auditevent=runtime
Policy proxy server: Configuration Settings
Running the amauditcfg utility sets the following entries in the pdaudit.pdproxymgrd.confconfiguration file:
[cars-filter] auditevent=authn auditevent=mgmt_config auditevent=mgmt_policy auditevent=mgmt_registry auditevent=mgmt_resource auditevent=runtime
Authorization server: Configuration Settings
Running the amauditcfg utility sets the following entries in the pdaudit.pdacld.conf configuration file:
[cars-filter] auditevent=authz auditevent=runtime
WebSEAL: Configuration settings
Running the amauditcfg utility sets the following entries in the pdaudit.webseald-instance.confconfiguration file:
[cars-filter] auditevent=authn auditevent=authn_creds_modify auditevent=authn_terminate auditevent=authz auditevent=password_change #auditevent=runtime
Note: The default audit settings that are defined by the amauditcfg utility are probably inappropriate for a WebSEAL server configuration. In particular, authz (AUDIT_AUTHZ) events do not provide definitive information about whether access was allowed to a particular resource. For definitive access information, use the resource_access (AUDIT_RESOURCE_ACCESS) event.
For information about audit configurations for WebSEAL, see “Configurations for WebSEAL.” For information about adding or modifying event types, see “Using the config modify command for auditing” on page 145.
Configurations for WebSEAL
Configuring the level of auditing for WebSEAL depends on your business needs and policies. The following levels of auditing are samples of levels that you can set in the pdaudit.webseald-instance.conf configuration file:
Level 1 auditing
Audit only unsuccessful authentication events. The configuration file must contain the following details:
[cars-filter]
auditevent=authn,outcome=unsuccessful
Level 2 auditing
Increases the level of auditing from Level 1 to include all authentication events. The configuration file must contain the following details:
[cars-filter] auditevent=authn
Level 3 auditing
Increases the level of auditing from Level 2 to include all sessions. The configuration file must contain the following details:
[cars-filter] auditevent=authn
auditevent=authn_terminate
Level 4 auditing
Increases the level of auditing from Level 3 to include unsuccessful access events. The configuration file must contain the following details:
[cars-filter] auditevent=authn
auditevent=authn_terminate
auditevent=resource_access,outcome=unsuccessful
Note: An HTTP request is considered unsuccessful if any of the following
conditions is true:
v An authentication failure occurred. v An authorization failure occurred.
v The request dispatch from WebSEAL to the junction failed. v The HTTP response code is not a 2xx or 3xx code.
If none of these conditions is true, the request is considered successful.
Level 5 auditing
Increases the level of auditing from Level 4 to include all access events. The configuration file must contain the following details:
[cars-filter] auditevent=authn
auditevent=authn_terminate auditevent=resource_access
This level of auditing generates the most events. Because of the volume of events, this configuration might not be practical. If the WebSEAL server does not receive heavy traffic, this configuration might be practical.
Plug-in for Web Servers: Configuration settings
Running the amauditcfg utility sets the following entries in the pdaudit.pdwebpi.confconfiguration file:
[cars-filter] auditevent=authn #auditevent=authn_creds_modify auditevent=authn_terminate auditevent=authz auditevent=password_change #auditevent=resource_access auditevent=runtime
Note: Although the amauditcfg utility sets the authz event (AUDIT_AUTHZ),
Plug-in for Web Servers does not generate this type of event. Results of application-level authorization generate resource_access
(AUDIT_RESOURCE_ACCESS) events. Make appropriate changes by using the
config modify command. For information about adding or modifying event types,
Using the config modify command for auditing
To change a setting in an auditing configuration file, use the pdadmin config
modifycommand. Do not change the contents of any configuration file by using an
ASCII editor.
Before you use the pdadmin config modify command, log in locally with the
pdadmin login –l command.
For information about these commands, see “config modify” on page 405 and “login” on page 409.
Starting event auditing
To start Common Auditing Service auditing, change the server-specific configuration file.
Procedure
1. Log in locally.
2. Set the doAudit entry to yes in the [cars-client] stanza of the server-specific configuration file.
Enter the following command:
config modify keyvalue set config_file cars-client doAudit yes
For example, to enable Common Auditing Service auditing for an AIX policy server, enter the following command:
config modify keyvalue set /opt/PolicyDirector/etc/audit/pdaudit.pdmgr.conf \ cars-client doAudit yes
Stopping event auditing
To stop Common Auditing Service auditing, change the server-specific configuration file.
Procedure
1. Log in locally.
2. Set the doAudit entry to no in the [cars-client] stanza of the server-specific configuration file.
Enter the following command:
config modify keyvalue set config_file cars-client doAudit no
For example, to stop Common Auditing Service auditing for an AIX policy server, enter the following command:
config modify keyvalue set /opt/PolicyDirector/etc/audit/pdaudit.pdmgr.conf \ cars-client doAudit no
Adding event types to the event filter
After you enable event auditing, you can add events to be forwarded to the Common Auditing Service audit server.
Procedure
1. Log in locally.
2. Append an auditevent entry with the new event type to the [cars-filter] stanza of the server-specific configuration file.
config modify keyvalue append config_file cars-filter auditevent type
For example, to add runtime event auditing for an AIX policy server, enter the following command:
config modify keyvalue append /opt/PolicyDirector/etc/audit/pdaudit.pdmgr.conf \ cars-filter auditevent runtime
For example, to add resource access event auditing to an AIX WebSEAL server, enter the following command:
config modify keyvalue \
append /opt/PolicyDirector/etc/audit/pdaudit.default-webseald-aix.ibm.com.conf \ cars-filter auditevent runtime
Removing event types from the event filter
After you enable event auditing, you can stop events from being forwarded to the Common Auditing Service server.
About this task
To remove an event, remove the auditevent entry for that event type from the [cars-filter] stanza of the server-specific configuration file.
Procedure
1. Log in locally.
2. Enter the following command:
config modify keyvalue remove config_file cars-filter auditevent type
For example, to remove authorization event auditing from an AIX policy server, enter the following command:
config modify keyvalue remove /opt/PolicyDirector/etc/audit/pdaudit.pdmgr.conf \ cars-filter auditevent authz
For example, to remove the authorization event auditing from an AIX WebSEAL server, enter the following command:
config modify keyvalue \
remove /opt/PolicyDirector/etc/audit/pdaudit.default-webseald-aix.ibm.com.conf \ cars-filter auditevent authz
Enhancements to improve audit event data throughput and minimize
data loss
To minimize the loss of audit events, specify the following configuration options for Common Auditing Service:
v Provide a separate file system for cache files.
v Monitor this file system regularly to determine whether more space is needed, or if the Common Auditing Service audit server needs attention.
v Ensure that a reasonable value is used for the tempStorageFullTimeout property. This property specifies the number of seconds that the application waits before