13 Configuring and Managing Auditing

This chapter explains how to perform day-to-day audit administration tasks.

See Also:

Chapter 12, "Introduction to Oracle Fusion Middleware Audit Framework" for background information about auditing in Oracle Fusion Middleware.

Audit Administration Tasks
Managing the Audit Data Store
Managing Audit Policies
Audit Logs
Advanced Management of Database Store

13.1 Audit Administration Tasks

The audit administrator should plan the site's audit setup carefully by following the steps in these areas:

Implementation Planning

This includes planning the type of store to use for audit records, data store configuration details, and so on.

See Section 13.2, "Managing the Audit Data Store" for details.
Policy administration

The administrator must configure the appropriate audit policies to ensure that the required audit events are generated.

This is an ongoing activity since the audit policies must be able to reflect changes to the application environment, addition of components and users, and so on.

See Section 13.3, "Managing Audit Policies" for details.
Reports Management

This includes planning for and configuring audit reports and queries.

See Chapter 14, "Using Audit Analysis and Reporting" for details.
Data Administration

This includes planning/increasing the database size required to store the audit data generated, backing up the audit data and purging the audit data based on company policy.

See Section 13.5, "Advanced Management of Database Store" for details about audit data store administration.

13.2 Managing the Audit Data Store

Out of the box, the audit framework uses the file system to store audit records. In a production environment, however, Oracle recommends that you use a database audit data store to provide scalability and high-availability for the audit framework.

In addition, an audit data store residing in a database allows the audit data to be viewed through Oracle Business Intelligence Publisher with pre-packaged audit reports that are available with that product. Oracle Business Intelligence Publisher is available in the 11g Release 1 (11.1.1) CD pack.

This section explains these audit data store management tasks in detail:

Create the Audit Schema using RCU
Set Up Audit Data Sources
Configure a Database Audit Data Store for Java Components
Configure a Database Audit Data Store for System Components
Tuning the Bus-stop Files
Configuring the Stand-alone Audit Loader

13.2.1 Create the Audit Schema using RCU

To switch to a database as the permanent store for your audit records, you first use the Repository Creation Utility (RCU) to create a database store for audit data.

Note:

The bus-stop files store audit records in the absence of database storage.

This section explains how to create the audit schema. Once the database schema is created, you can:

create a datasource to point to this schema
update the domain configuration to switch the audit data store for audit records (see Section 13.2.3.2, "Configure the Audit Data Store").

Note:

This discussion assumes that RCU and the database is already installed in your environment. See the Installation Guide for more information.

Before You Begin

Before you begin, make sure to collect the details on which database to use, along with the DBA credentials to use.

Configuring the Database Schema

Take these steps to configure a schema for the audit data store:

Go to $RCU_HOME/bin and execute the RCU utility.
Choose Create at the starting screen. Click Next.
Enter your database details and click Next.
Choose the option to create a new prefix, for example IDM.
Also, select 'Audit Services' from the list of schemas.
Click Next and accept the tablespace creation.
Check for any errors while the schemas are being created.

This process will take several minutes to complete.

13.2.2 Set Up Audit Data Sources

As explained in Section 13.2.1, "Create the Audit Schema using RCU", after you create a database schema to store audit records in a database, you must set up an Oracle WebLogic Server audit data source that points to that schema.

Take these steps to set up an audit data source:

Note:

This task is performed with the Oracle WebLogic Server administration console.

Connect to the Oracle WebLogic Server administration console:
```
http://host:7001/console
```
Under JDBC, click the Data Sources link.
The Data Sources page appears. Click New to create a new data source.
Enter the following details for the new data source:
- Name: Enter a name such as Audit Data Source-0.
- JNDI Name: jdbc/AuditDB
- Database Type: Oracle
- Database Driver: Oracle's Driver (Thin XA) Versions: 9.0.1, 9.0.2, 10, 11
If deploying to a managed cluster server, also check AdminServer; this ensures that the data source is listed in the audit data store when switching from file to database store.

Click Next.
The Transaction Options page appears. Click Next.
The Connection Properties page appears. Enter the following information:
- Database Name: Enter the name of the database to which you will connect. This usually maps to the SID.
- Host Name: Enter the hostname of the database.
- Port: Enter the database port.
- Database User Name: This is the name of the audit schema that you created in RCU. The suffix is always IAU for the audit schema. For example, if you gave the prefix as test, then the schema name is test_iau.
- Password: This is the password for the audit schema that you created in RCU.
Click Next.
The next page lists the JDBC driver class and database details. Accept the defaults, and click Test Configuration to test the connection. If you see the message "Connection established Successfully", click Next. If it displays any error, go back and check the connection details.
In the Select Targets page, select the servers where this data source needs to be configured, and click Finish.

13.2.2.1 Multiple Data Sources

For scalability and high availability, you can configure Oracle Real Application Clusters for your audit data.

For details, see:

Setting Up Auditing with a RAC Database Store in the Oracle Fusion Middleware High Availability Guide
Using WebLogic Server to Configure Audit Data Sources and Multi Data Sources in the Oracle Fusion Middleware High Availability Guide
Configuring the JDBC String for the Audit Loader in the Oracle Fusion Middleware High Availability Guide
Using WebLogic Server with Oracle RAC in Oracle Fusion Middleware Configuring and Managing JDBC for Oracle WebLogic Server

13.2.3 Configure a Database Audit Data Store for Java Components

After the schema is created, configuring a database-based audit data store involves:

creating a data source that points to the audit schema you created, and
configuring the audit data store to point to the data source

This section describes the following tasks related to audit data store configuration:

View Audit Data Store Configuration
Configure the Audit Data Store

Note:

These steps configure the audit data store for Java components only. Separate steps are needed to configure the audit data store for system components. See Section 13.2.4, "Configure a Database Audit Data Store for System Components".

By configuring the same database to store audit records for Java components and system components, you can ensure that reports for both types of components can be viewed together.

13.2.3.1 View Audit Data Store Configuration

Note:

This task is performed with Oracle Enterprise Manager Fusion Middleware Control.

To view the current audit data store configuration, navigate to Domain, then Security, then Audit Store.

Description of the illustration audrepos1.gif

This page shows:

whether or not a database is configured as the audit data store. By default a database is not configured, and audit records are stored in bus-stop files.
Datasource JNDI Name - If a database store is configured for audit records, this field shows the JNDI name of the datasource. This field is empty when the audit data store is not configured.
Datasource Name - If a database store is configured for audit records, this field shows the datasource name. This field is not displayed when the audit data store is file-based.
URL - If a database repository is configured for audit records, this field shows the data source URL, which is the connect string used to connect to the database. This field is not displayed when the audit data store is file-based.

See Section 13.2.2, "Set Up Audit Data Sources" for datasource examples.

13.2.3.2 Configure the Audit Data Store

You can change from storing audit records in a file to using a database audit data store.

Take these steps to configure the audit data store:

Navigate to Domain, then Security, then Audit Store. The Audit Store page appears.
Click the searchlight icon next to the Datasource JNDI Name field.
A dialog box appears showing the list of datasources available for audit records in the domain. Select the desired datasource and click OK.
The selected datasource is displayed in the Datasource JNDI Name field. Click Apply to continue, or Revert to abandon the update.

Note:

You can also use the WLST setAuditRepository() command to change the audit data store settings. See Appendix D, Fusion Middleware Audit Framework Reference for details.
Restart all the Oracle WebLogic Servers in the domain. This enables Audit Loader Startup Class present in Oracle WebLogic Server to re-read the configuration.
You can test the changes by setting an audit policy to test event collection. For example, you can set the Medium audit policy for Oracle Platform Security Services. For details, see Section 13.3.1, "Manage Audit Policies for Java Components with Fusion Middleware Control".
Execute a scenario so that auditing can generate an audit event. For example, creating a credential will trigger an audit record based on the policy you configured in Step 6.
Check for errors and exceptions in the server logs
- Check $DOMAIN_HOME/jrfServer_admin.out
- Check $DOMAIN_HOME/servers/$SERVER_NAME/logs/.

13.2.3.3 Deconfigure the Audit Data Store

Since a database is the recommended store for audit records, switching from database to file mode is discouraged. However, Section 13.3.4, "Manage Audit Policies Manually" discusses a property called the audit.repositoryType whose value can be set to 'File' to switch to file storage.

Note:

You cannot use Fusion Middleware Control or WLST to switch from database to file mode; this requires manual configuration as explained in Section 13.3.4, "Manage Audit Policies Manually".

When you switch from database to file, events that were collected in the database are not transferred back to the file system. If this switch is temporary, then the audit events collected in the file are automatically pushed to database when you switch to database store again.

13.2.4 Configure a Database Audit Data Store for System Components

Oracle Process Manager and Notification Server (OPMN) manages several system components running in Oracle WebLogic Server. For these components, the mechanism through which the audit events are pushed from local bus-stop files to the database audit data store is handled by OPMN.

Note:

If your system component runs in a clustered deployment, you must configure the audit data store at each instance of the component so that all instances push out records to the store.

You must execute the following steps in every instance of the component to configure an audit data store:

Note:

These steps configure the audit data store for system components only. Separate steps are needed to configure the audit data store for Java components. See Section 13.2.3, "Configure a Database Audit Data Store for Java Components".

By configuring the same database to store audit records for Java components and system components, you can ensure that reports for both types of components can be viewed together.

Open the opmn.xml file, which resides in

$ORACLE_INSTANCE/config/OPMN/opmn/opmn.xml

Locate the rmd-definitions element, which looks like this:

<rmd-definitions>
         <rmd name="AuditLoader" interval="15">
            <conditional>
            <![CDATA[({time}>=00:00)]]>
            </conditional>
            <action value="exec $ORACLE_HOME/jdk/bin/java -classpath 
 $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: 
 $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: 
 $ORACLE_HOME/jdbc/lib/ojdbc5.jar: 
 $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar: 
 $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar           
                 -Doracle.home=$ORACLE_HOME 
                 -Doracle.instance=$ORACLE_INSTANCE           
                 -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid           
                 -Dauditloader.username=username 
                 oracle.security.audit.ajl.loader.StandaloneAuditLoader"/>
            <exception value="exec /bin/echo 
                PERIODICAL CALL For Audit Loader FAILED"/>
         </rmd>
</rmd-definitions>

Replace the existing RMD definition for audit loader; you need to modify only these values:
- jdbcString - this is the database JDBC connection string; change this from the default string to a valid connection string.
- username
- interval - this is the interval in seconds at which audit records are pushed from the component's bus-stop file to the audit data store.
  
  By default the interval value is set very high (31536000 seconds) so that the audit loader is effectively disabled. Change this to a reasonable interval such as 15 seconds.
  
  Note:
  
  Insert these lines after the <ias-instance> tag is closed.
Save and exit the file.

Ensure that ORACLE_HOME, ORACLE_INSTANCE , and COMMON_COMPONENTS_HOME are defined. For example:

ORACLE_HOME = /u01/oracle/as11_oh
ORACLE_INSTANCE = /u01/oracle/instances/instance 
COMMON_COMPONENTS_HOME = $MW_HOME/oracle_common

Populate the audit data store password in the secret store. This is the password that you have specified when creating the audit schema in RCU:

ORACLE_HOME/jdk/bin/java -classpath 
      $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
      $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
      $ORACLE_HOME/jdbc/lib/ojdbc5.jar:
      $COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
      $COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar 
      -Doracle.home=$ORACLE_HOME -Doracle.instance=$ORACLE_INSTANCE 
      -Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
      -Dauditloader.username=username 
      -Dstore.password=true 
      -Dauditloader.password=password 
      oracle.security.audit.ajl.loader.StandaloneAuditLoader

Enter the appropriate values for jdbcString, username, password.

Note:

The above syntax is relevant to Linux. For Windows, substitute ":" with ";" to separate the jars in the classpath.

Reload OPMN:

 $ORACLE_INSTANCE/bin/opmnctl validate (Validation step to verify edits)
      $ORACLE_INSTANCE/bin/opmnctl reload

Execute a scenario in an audited component to generate an audit event.
Check for errors/events uploaded at $ORACLE_INSTANCE/diagnostics/logs/OPMN/opmn/rmd.out. The output will look like this
```
8/08/26 10:54:24 global:AuditLoader
```

13.2.4.1 Deconfigure the Audit Data Store

Since a database is the recommended store for audit records, switching from database to file mode is discouraged. However, if needed, you can use the same steps that were shown in the preceding task for configuring the audit data store through the opmn.xml file to update the RMD definition to deconfigure the audit data store. Locate the rmd-definitions element and replace the existing RMD definition for audit loader:

Note:

If your system component runs in a clustered deployment, you must deconfigure the audit data store at each instance of the component.

jdbcString - Change the database JDBC connection string back to the default string jdbc:oracle:thin:@host:port:sid.
interval - Set this interval back to the default value of 31536000.

Save and exit the file, and reload OPMN.

13.2.5 Tuning the Bus-stop Files

This section contains topics related to maintaining file-based storage of audit records, including:

bus-stop file locations
file size
directory size

Note:

Manually purging audit files to free up space is not recommended. Instead, use file and directory sizing features to control space, as described below.

Location of Bus-stop Files

Bus-stop files for Java components are located in:

$DOMAIN_HOME/servers/$SERVER_NAME/logs/auditlogs/Component_Type

Bus-stop files for system components are located in:

$ORACLE_INSTANCE/auditlogs/Component_Type/Component_Name

File Size

Java Components

The size of a file for the file storage mode can be managed using the max.fileSize property described in the configuration file jps-config.xml. This property controls the maximum size of a bus-stop file for Java components.

Specify the sizes in bytes as described in Section 13.3.4, "Manage Audit Policies Manually".

System Components

The size of a file for the file storage mode can be set in the auditconfig.xml file. SeeSection 13.3.4.4, "Manually Configuring Audit for System Components".

Note:

If you switch from file to database store for audit data, all the events collected in the audit files are pushed into the database tables and the audit files are deleted.

Directory Size

Java Components

The size of a directory for the file can be managed using the max.DirSize property described in the configuration file jps-config.xml. This property controls the maximum size of a bus-stop directory.

Specify the sizes in bytes as described in Section 13.3.4, "Manage Audit Policies Manually".

System Components

The size of a directory for the file storage mode can be set in the auditconfig.xml file. See Section 13.3.4.4, "Manually Configuring Audit for System Components".

13.2.6 Configuring the Stand-alone Audit Loader

As shown in Figure 12-1, Common Audit Framework's audit loader moves records from bus-stop files to the audit data store. The mechanism driving the audit loader depends on the application environment:

Java EE components and applications deployed in Oracle WebLogic Server use the audit loader functionality provided through the application server.
System components and non-Java applications use the audit loader functionality provided through Oracle Process Manager and Notification Server (OPMN).
Java SE applications, which run outside an application server container, use a stand-alone audit loader.

This section explains how to set up and execute the stand-alone audit loader:

Configuring the Environment
Running the Stand-Alone Audit Loader

13.2.6.1 Configuring the Environment

Before you can run the stand-alone audit loader, you must a) configure certain properties, and b) ensure that the password for the database schema user exists in the secret store.

13.2.6.1.1 Property Configuration

You must configure the following properties:

ORACLE_HOME environment variable
COMMON_COMPONENTS_HOME environment variable
ORACLE_INSTANCE environment variable
auditloader.jdbcString system property
auditloader.username system property

13.2.6.1.2 Password Storage for the Database Schema User

The password for the database schema user is kept in the secret store. Storing the password is a one-time operation for which you use the StandAloneAuditLoader command with the -Dstore.password=true option.

Issue the StandAloneAuditLoader command to store the password as follows:

$ORACLE_HOME/jdk/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar: 
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar 
-Doracle.instance=$ORACLE_INSTANCE 
-Dauditloader.jdbcString=jdbc:oracle:thin:@host:port:sid 
-Dauditloader.username=username 
-Dstore.password=true 
oracle.security.audit.ajl.loader.StandaloneAuditLoader

13.2.6.2 Running the Stand-Alone Audit Loader

Issue the StandAloneAuditLoader command to load audit records as follows:

$ORACLE_HOME/jdk/bin/java 
-classpath $COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.jdbc_11.1.1/ojdbc6dms.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.iau_11.1.1/fmw_audit.jar:
$COMMON_COMPONENTS_HOME/modules/oracle.pki_11.1.1/oraclepki.jar 
-Doracle.home=$ORACLE_HOME
-Doracle.instance=$ORACLE_INSTANCE 
-Dauditloader.jdbcString=jdbc:oracle:thin:host:port:sid 
-Dauditloader.username=username 
oracle.security.audit.ajl.loader.StandaloneAuditLoader

You can schedule this command through a batch or kron job so that audit records are periodically uploaded to the audit data store.

13.3 Managing Audit Policies

What is an Audit Policy?

An audit policy is a declaration of the type of events to be captured by the audit framework for a particular component. For Java components, the audit policy is defined at the domain level. For system components, the audit policy is managed at the component instance level.

For example, an audit policy could specify that all authentication failures should be audited for an Oracle Internet Directory instance.

How Policies are Configured

Oracle Fusion Middleware Audit Framework lets you configure audit policies and provides highly granular controls over the types of events and data being audited. Policies can be configured through the Enterprise Manager UI tool and through the WLST command-line interface.

Policy changes do not require server or instance restart.

The remainder of this section explains how to view, and update audit policy:

Manage Audit Policies for Java Components with Fusion Middleware Control
Manage Audit Policies for System Components with Fusion Middleware Control
Manage Audit Policies with WLST
Manage Audit Policies Manually

See Also:

Section 12.3.2, "Key Technical Concepts" for additional background.
Appendix D, Oracle Fusion Middleware Audit Framework Reference for a list of Java components and system components.
Oracle Fusion Middleware Third-Party Application Server Guide for details about executing audit commands on third-party application servers.

13.3.1 Manage Audit Policies for Java Components with Fusion Middleware Control

The domain Audit Policy Settings page manages audit events for all Java components such as Oracle Identity Federation, and system libraries like Oracle Platform Security Services.

Note:

Audit policy for system components is managed in the component home pages. See Section 13.3.2, "Manage Audit Policies for System Components with Fusion Middleware Control"
See the note at the beginning of Section 13.3, "Managing Audit Policies" titled "Policy Changes Require Server or Instance Restart".

13.3.2 Manage Audit Policies for System Components with Fusion Middleware Control

This section describes how to view and update audit policies for system components that are managed through OPMN.

Notes:

Audit policy for Java components is managed in the domain context. See Section 13.3.1, "Manage Audit Policies for Java Components with Fusion Middleware Control"
See the note at the beginning of Section 13.3, "Managing Audit Policies" titled "Policy Changes Require Server or Instance Restart". Oracle Internet Directory instances do not require a restart.

Audit policy for system components is managed in their home pages. The domain Audit Policy Settings page manages audit events for Java components running in the domain.

13.3.3 Manage Audit Policies with WLST

This section explains how to view and update audit policies using the Oracle WebLogic Scripting Tool (WLST) command-line tool:

View Audit Policies with WLST
Update Audit Policies with WLST
Example 1: Configuring an Audit Policy for Users with WLST
Example 2: Configuring an Audit Policy for Events with WLST
Custom Configuration is Retained when the Audit Level Changes

Note:

When running audit WLST commands, you must invoke the WLST script from the Oracle Common home. See "Using Custom WLST Commands" in the Oracle Fusion Middleware Administrator's Guide for more information.

13.3.3.1 View Audit Policies with WLST

Take these steps to view audit policies with WLST:

Note:

This discussion assumes that you are invoking WLST interactively. For details about WLST and the different options for invoking the tool, see "Getting Started Using the Oracle WebLogic Scripting Tool (WLST)" in the Oracle Fusion Middleware Administrator's Guide.

Connect to the WebLogic Server using the following commands:

java weblogic.WLST
connect('servername', 'password', 'localhost:portnum')

Use the getAuditPolicy command to view the audit policy configuration. For example:
```
wls:/mydomain/serverConfig> getAuditPolicy()
```
For system components:
- obtain the MBean name using the getNonJava EEAuditMBeanName command. See Section C.4.1, "getNonJava EEAuditMBeanName" for details.
- Use the getAuditPolicy command and include the MBean name to view the audit policy configuration. For example:
```
wls:/mydomain/serverConfig> getAuditPolicy
 (on="oracle.security.audit.test:type=CSAuditMBean,name=CSAuditProxyMBean")
```

13.3.3.2 Update Audit Policies with WLST

Take these steps to update audit policies with the Oracle WebLogic Scripting Tool (WLST) command-line tool:

Note:

Connect to the WebLogic Server using the following commands:

java weblogic.WLST
connect('servername', 'password', 'localhost:portnum')

Navigate the bean hierarchy to access the domain of interest. For example, if the domain is called mydomain:
```
wls:/mydomain/serverConfig>
```
Use the setAuditPolicy command to update the audit policy configuration.
For components that manage their policy locally, use the setAuditPolicy command and include an MBean name to update the audit policy configuration.
Explicitly call save after issuing a setAuditPolicy, or importAuditConfig, command.

If you do not invoke save, the new settings will not take effect.

For an example of this call, see Managing Auditing by Using WLST in the Oracle Fusion Middleware Administrator's Guide for Oracle Internet Directory, which demonstrates this call for Oracle Internet Directory auditing.

See Also:

The WLST command reference for details about WLST commands for audit.

13.3.3.3 Example 1: Configuring an Audit Policy for Users with WLST

In this scenario, the domain's current policy audits a user named user1. We would like to add two names, user2 and user3, to the list of users who are always audited, and remove user1 from the list.

The following invocation of setAuditPolicy performs this task:

setAuditPolicy
   (filterPreset="None",addSpecialUsers="user2,user3",removeSpecialUsers="user1")

See Also:

Section C.4.3, "setAuditPolicy"

13.3.3.4 Example 2: Configuring an Audit Policy for Events with WLST

In this scenario, the domain's current policy audits user logout events. We would like to remove the logout events from the policy and instead, audit login events.

The following invocation of setAuditPolicy performs this task:

Note:

This example uses the component type OHS for Oracle HTTP Server. Substitute the relevant component type when using the command.

setAuditPolicy
(filterPreset="Custom",addCustomEvents="OHS:UserLogin",
removeCustomEvents="OHS:UserLogout")

Notice that we had to set the Custom filter preset to add and remove events.

13.3.3.5 Custom Configuration is Retained when the Audit Level Changes

When auditing is configured at the custom audit level, and you subsequently use WLST to switch to a different (non-custom) audit level, the custom audit settings are retained unless you explicitly remove those custom settings.

Note:

This behavior only occurs when using WLST; if you use Fusion Middleware Control to manage audit configuration, the custom audit settings are cleared when you switch from the custom audit level to a different audit level.

An example illustrates this behavior:

Custom audit level is set for a component's policy. An audit filter is specified as part of the configuration.
At run-time, audit data is collected according to the specified filter.
The component's audit policy is now changed from custom audit level to, say, the low audit level using the WLST setauditpolicy command. However, the filter that was set up as part of the custom audit level persists in the audit configuration.
Audit data is now collected based on the low audit level, not the custom level.
The component's audit policy is changed back to custom level. An additional filter is added; this filter is appended to the originally configured filter. Unless the original filter is explicitly deleted, it remains part of the configuration.
At run-time, audit data is collected based on all prevailing filters at the custom level.

13.3.4 Manage Audit Policies Manually

This section explains how to configure auditing policies and other features by manually updating:

the platform configuration file jps-config.xml for Java components
component-specific files for system components

This section contains these topics:

Location of Configuration Files for Java Components
Audit Service Configuration Properties in jps-config.xml for Java Components
Switching from Database to File for Java Components
Manually Configuring Audit for System Components

13.3.4.1 Location of Configuration Files for Java Components

The jps-config.xml domain configuration file can be found at this location:

$DOMAIN_HOME/config/fmwconfig/jps-config.xml

13.3.4.2 Audit Service Configuration Properties in jps-config.xml for Java Components

The Audit Service Configuration in jps-config.xml consists of the properties shown in Table F-9. Taken together, the set of properties and their values are known as the audit policy.

Example jps-config.xml file

Here is a sample file illustrating an audit policy:

<?xml version="1.0" encoding="UTF-8" standalone='yes'?>
<jpsConfig xmlns="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://xmlns.oracle.com/oracleas/schema/11/jps-config-11_1.xsd" schema-major-version="11" schema-minor-version="1">
 
    <serviceProviders>
     <serviceProvider name="audit.provider" type="AUDIT" class="oracle.security.jps.internal.audit.AuditProvider">
     </serviceProvider>
    </serviceProviders>
 
  <serviceInstances>
   <serviceInstance name="audit" provider="audit.provider">
      <property name="audit.filterPreset" value="Low"/>
      <property name="audit.specialUsers" value ="admin, fmwadmin" />
      <property name="audit.customEvents" value ="JPS:CheckAuthorization,          CreateCredential; OIF:UserLogin"/>
      <property name="audit.loader.jndi" value="jdbc/AuditDB"/>
      <property name="audit.loader.interval" value="15" />
      <property name="audit.maxDirSize" value="102400" />
      <property name="audit.maxFileSize" value="10240" />      
      <property name=" audit.loader.repositoryType " value="Db" />      
   </serviceInstance>
  </serviceInstances>
    <jpsContexts default="default">
        <jpsContext name="default">
            <serviceInstanceRef ref="audit"/>
        </jpsContext>
    </jpsContexts>
</jpsConfig>

13.3.4.3 Switching from Database to File for Java Components

In rare instances, you may wish to revert from using a (database) data store to using a file for audit records. This requires manual configuration of the property audit.loader.repositoryType described in Table F-9.

To switch from database to file, set the audit.loader.repositoryType to File.

When you switch from database to file, events that were collected in the database are not transferred back to the file system. If this switch is temporary, the audit events collected in the file are automatically pushed to the database when you switch to a database store again.

13.3.4.4 Manually Configuring Audit for System Components

System components do not use the jps-config.xml file to store the audit configuration. Instead:

Oracle HTTP Server uses the auditconfig.xml file which is located in:

ORACLE_INSTANCE/instance_name/config/OHS/<ohs_name>/auditconfig.xml

Oracle Web Cache uses the auditconfig.xml file which is located in:

ORACLE_INSTANCE/instance_name/config/WebCache/<webcache_name>/auditconfig.xml

Oracle Reports uses the jps-config-jse.xml file which is located in:
```
$DOMAIN_HOME/config/fmwconfig/jps-config-jse.xml
```
Oracle Virtual Directory uses jps-config.-jse.xml file which is located in:
```
ORACLE_INSTANCE/instance_name/config/JPS/jps-config-jse.xml
```
Oracle Internet Directory's audit configuration is stored in the database.

Format of the auditconfig.xml File

Here is the format of the auditconfig.xml file:

<AuditConfig xmlns="http://xmlns.oracle.com/ias/audit/audit.xsd">
  <Filters>
    <!-- FilterPreset can be None,Low,Medium,All or Custom.  Default value: None -->
    <FilterPreset>Low</FilterPreset>
 
    <!-- Comma separated list of special users for whom auditing is always turned on. Default value: no users -->
    <SpecialUsers>u1,u2</SpecialUsers>
 
    <!-- In case of custom, a comma separate list of events that are to be enabled for auditing. Default value: no events -->
    <CustomEvents>e1,e1</CustomEvents>
 
  </Filters>
  <LogsDir>
 
    <!-- Maximum dir size of the log directory (busstop). 0 implies unlimited size. Default value: 0 -->
    <MaxDirSize>0</MaxDirSize>
 
    <!-- Maximum file size of each audit.log file. Default value: 100MB -->
   <MaxFileSize>104857600</MaxFileSize>
 
 </LogsDir>
<AuditConfig>

13.4 Audit Logs

Fusion Middleware Audit Framework provides a set of log files to help with audit administration. You can use these logs to trace errors and for diagnostic purposes when the audit framework is not functioning properly.

This section contains the following topics:

Location of Audit Logs
Audit Log Timestamps

13.4.1 Location of Audit Logs

For a listing of all audit log locations, how to configure the loggers, and how to use the logs to diagnose issues, see Section L.1.1.6, "Audit Loggers".

13.4.2 Audit Log Timestamps

Time stamps in the audit logs are recorded in Coordinated Universal Time. This may differ from the machine time depending on the machine's time zone setting.

13.5 Advanced Management of Database Store

The audit schema is created through the Repository Creation Utility (RCU). This section explains the organization of the audit schema and contains topics related to maintaining the schema.

See Also:

For more information on RCU, see Oracle Fusion Middleware Repository Creation Utility User's Guide.

13.5.1 Schema Overview

The Oracle Fusion Middleware Audit Framework schema consists of the following:

A base table: IAU_BASE
A translation table: IAU_DISP_NAMES_TL
A set of component-specific tables of audit data, for example OVDCOMPONENT, OIDCOMPONENT, JPS and so on

When generated, audit records are stored in a file; if an audit database store is configured, the audit loader stores each audit record in one row of the base table and one row of a component table:

General information (such as Time, EventType, and EventStatus) is written into the base table
component-specific information (such as CodeSource) is written into the component table

Note:

The attribute ComponentType in the bus-stop file determines which component table stores the record.

The audit loader assigns unique sequential numbers to all records during storage.

Here is a sample bus-stop file for Oracle Platform Security Services. By default, this file is maintained in the directory

WebLogic Domain Home/servers/server_name/diagnostics/auditlogs/JPS/audit.log

#Fields:Date Time Initiator EventType EventStatus MessageText HomeInstance ECID RID ContextFields SessionId TargetComponentType ApplicationName EventCategory ThreadId InitiatorDN TargetDN FailureCode RemoteIP Target Resource Roles CodeSource InitiatorGUID Principals PermissionAction PermissionClass mapName key
#Remark Values:ComponentType="JPS"
2008-12-08 10:46:05.492  - "CheckAuthorization" true "Oracle Platform Security Authorization Check Permission SUCCEEDED." - - - - - - - "Authorization" "48" - - "true" - - "(oracle.security.jps.service.policystore.PolicyStoreAccessPermission context=APPLICATION,name=SimpleServlet getApplicationPolicy)" - "file:/oracle/work/middleware/oracle_common/modules/oracle.jps_11.1.1/jps-internal.jar" - "[]" - - - -

Figure 13-1 shows the data in the base table and how it relates to the component-specific tables.

Figure 13-1 Audit Schema

Surrounding text describes Figure 13-1 .

The average record size in the base table IAU_BASE is approximately 0.3 KB. When you plan for tablespace sizing:

use this number as a guideline for the average record size
monitor how audit database size is growing based on the audit policy selected and the level of activity
take into account the period of time for which the audit data is being stored.

13.5.2 Table Attributes

The attributes of the base table and the component-specific tables respectively are derived from these files:

$ORACLE_HOME/modules/oracle.iau_11.1.1/components/generic/generic_events.xml

for the base table, and

$ORACLE_HOME/modules/oracle.iau_11.1.1/components/componentName/component_events.xml

for each component table.

Table 13-1 lists a few important attributes defined in the base table IAU_BASE. The first four attributes are common in that table and all component tables. The primary key is defined as IAU_ID + IAU_TSTZORIGINATING.

See Also:

Section C.3, "The Audit Schema"

Table 13-1 Attributes of Base Table IAU_BASE

Attribute	Description
IAU_ID	A unique sequential number for every audit record
IAU_TstzOriginating	Date and time when the audit event was generated (data type `TIMESTAMP`)
IAU_EventType	The type (name) of the audit event
IAU_EventCategory	The category of the audit event
IAU_EventStatus	The outcome of the audit event - success or failure
IAU_MessageText	Description of the audit event
IAU_Initiator	UID of the user who was doing the operation

Note:

A SEQUENCE, an Oracle database object, is created to coordinate the assignment of sequential numbers (IAU_ID) for audit records.

You can use the listAuditEvents WLST command to get a list of all attribute names for individual component tables.

See Also:

13.5.3 Indexing Scheme

For efficient queries, an index is created by default on the Timestamp (IAU_TSTZORIGINATING) in the base table and on each of the component-specific tables.

The default index in IAU_BASE is named EVENT_TIME_INDEX, and in the component tables it is named tableName_INDEX (such as OVDCOMPONENT_INDEX, OIDCOMPONENT_INDEX, JPS_INDEX and so on).

13.5.4 Backup and Recovery

Compliance regulations require that audit data be stored for long periods. A backup and recovery plan is needed to protect the data.

A good backup plan takes account of these basic guidelines:

Growth rate of Audit Events

The number of audit events generated depends on your audit policy. The number of audit events generated daily determines, in turn, how often you want to perform backups to minimize the loss of your audit data.
Compliance regulations

Consult you organization's compliance regulations to determine the frequency of backups and number of years for which audit data storage is mandatory.
Online or Offline Data Management

Consult you organization's compliance regulations to determine the frequency of backups and the portion of audit data that needs to be easily accessible.

Oracle Database uses Oracle Recovery Manager (RMAN) for backup and recovery. For details, see:

http://www.oracle.com/technology/deploy/availability/htdocs/BR_Overview.htm

http://www.oracle.com/technology/deploy/availability/htdocs/rman_overview.htm

Note:

The translation table, IAU_DISP_NAMES_TL, needs to be backed up only once, since it should not change over time.

13.5.5 Importing and Exporting Data

You can import and export the audit schema to migrate data if you started with multiple audit databases and wish to combine them into a single audit data store, or if you wish to change the database to scale up.

Oracle Database sites can utilize the utilities of Oracle Data Pump to import and export data. For details, refer to:

http://www.oracle.com/technology/products/database/utilities/htdocs/data_pump_overview.html

13.5.6 Partitioning

Not all database systems support partitioning, all the tables in the audit schema are unpartitioned by default.

Since audit data is cumulative and older data is never removed, if you store a high volume of audit data you should consider partitioning the audit schema, as it will allow for easier archiving.

Benefits of partitioning include:

Improved Performance: If a table is range-partitioned by Timestamps, for example, queries by Timestamps can be processed on the partitions within that time-frame only.
Better Manageability: Partitions can be created on separate tablespaces (thus different disks). This enables you to move older data to slower and larger disks, while keeping newer data in faster and smaller disks.

In addition, partitioning makes archival much easier. For example, you can compress a singlve partition rather than having to partition the entire table.
Increased Availability: If a single partition is unavailable, for example, and you know that your query can eliminate this partition from consideration, the query can be successfully processed without needing to wait for the unavailable partition.

13.5.6.1 Partition Tables

In this example, IAU_BASE is used as an example to demonstrate how to convert the unpartitioned tables in the audit schema into partitioned tables.

It is recommended that partitioning is done before using this schema for an audit data store to minimize the application down time.

Note:

Two sample SQL scripts are shipped with the product:

$RCU_HOME/rcu/integration/iau/scripts/convertPartitionedTables.sql (linux) or %RCU_HOME\rcu\integration\iau\scripts\convertPartitionedTables.sql (Windows) converts the base and component tables in audit schema into partitioned tables
$RCU_HOME/rcu/integration/iau/scripts/createPartitionsByQuarter.sql (linux) or %RCU_HOME\rcu\integration\iau\scripts\createPartitionsByQuarter.sql (Windows) creates partitions by quarter for the base and component tables in the audit schema

The partitioning steps are as follows:

Note:

It is recommended that you deactivate the audit loader prior to partitioning. See Section 13.2.4.1, "Deconfigure the Audit Data Store" for details.

Rename the existing unpartitioned table. For example:
```
RENAME IAU_BASE TO IAU_BASE_NONPART;
```

Create a new partitioned table that follows the table structure of the unpartitioned table. This example uses the range-partitioning (by Timestamp) scheme:

CREATE TABLE IAU_BASE
PARTITION BY RANGE (IAU_TSTZORIGINATING)
(
    PARTITION IAU_BASE_DEFAULT VALUES LESS THAN (MAXVALUE)
)
AS SELECT * FROM IAU_BASE_NONPART;

Enable row movement to allow data to automatically move from partition to partition when new partitions are created. For example:
```
ALTER TABLE IAU_BASE
ENABLE ROW MOVEMENT;
```

Create a local prefix index for the partitioned table. For example:

ALTER INDEX EVENT_TIME_INDEX
RENAME TO EVENT_TIME_INDEX_NONPART;
 
CREATE INDEX EVENT_TIME_INDEX
ON IAU_BASE(IAU_TSTZORIGINATING) LOCAL;

Partitions can now be created. In this example partitions are created by calendar quarter:

ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/04/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q1_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;
 
ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/07/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q2_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;
 
ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/10/2008', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q3_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;
 
ALTER TABLE IAU_BASE
SPLIT PARTITION IAU_BASE_DEFAULT AT (TO_DATE('01/01/2009', 'DD/MM/YYYY')) INTO (PARTITION IAU_BASE_Q4_2008, PARTITION IAU_BASE_DEFAULT)
UPDATE INDEXES;

Note:

New partitions should be created periodically for new quarters.

13.5.6.2 Backup and Recovery of Partitioned Tables

Backup and recovery were discussed in Section 13.5.4, "Backup and Recovery". Note that read-only tablespaces can be excluded from whole database backup, so long as a backup copy was created. Thus, you can avoid unnecessarily repeating backups for the partitions of archived data residing on those tablespaces, improving performance.

13.5.6.3 Import, Export, and Data Purge

Import and export were discussed in Section 13.5.5, "Importing and Exporting Data". Keep in mind that with a range-partitioned table it is much more efficient to drop a partition when you want to remove old data, rather than deleting the rows individually.

ALTER TABLE IAU_BASE DROP PARTITION IAU_BASE_Q4_2008;

It is also easy to load a partition of new data without having to modify the entire table. However, you have to remove the default partition of "values less than (MAXVALUE)" first, and add it back once finished, using a command like the following:

ALTER TABLE IAU_BASE ADD PARTITION IAU_BASE_Q4_2008 VALUES LESS THAN ('01-JAN-2009');

Once partitions are created, you can purge/backup a particular partition. Refer to your database documentation for details.

In the database mode, the audit loader automatically manages bus-stop files.

13.5.6.4 Tiered Archival

Partitioning enables individual partitions (or groups of partitions) to be stored on different storage tiers. You can create tablespaces in high-performance or low-cost disks, and create partitions in different tablespaces based on the value of the data or other criteria. It is also easy to move data in partitions between the tablespaces (storage tiers).

Here is an example:

ALTER TABLE IAU_BASE MOVE PARTITION IAU_BASE_Q1_2008
TABLESPACE AUDITARCHIVE UPDATE INDEXES;

Note :

Partitions can be moved only in Range, List, System, and Hash partitioning schemes.

The Oracle Information Lifecycle Management (ILM) Assistant is a free tool that shows you how to partition tables and advise you when it is the time to move partitions. For details, refer to:

http://www.oracle.com/technology/deploy/ilm/index.html