Skip Headers
Oracle® Audit Vault and Database Firewall Administrator's Guide
Release 12.1.2

E27776-18
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Index
Index
Go to Master Index
Master Index
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

B Plug-in Reference

Topics

About Oracle AVDF Plug-ins

Oracle AVDF supports different types of secured targets by providing a plug-in for each secured target type. Oracle AVDF ships with a set of plug-ins out-of-the-box. These plug-ins are packaged and deployed with the Audit Vault Server.

You can also develop your own plug-ins, or get new available plug-ins, and add them to your Oracle AVDF installation. For more information on this topic, see "Deploying Plug-ins and Registering Plug-in Hosts".

This appendix contains high-level data for each plug-in shipped with Oracle AVDF. The appendix also contains look-up information you will need to complete the procedures for registering secured targets and configuring audit trails. These procedures link directly to the relevant section of this appendix.

Note:

Oracle AVDF also supports Oracle Big Data Appliance as a secured target. For details, see Oracle Big Data Appliance Owner's Guide.

Plug-ins Shipped with Oracle AVDF

This section describes each plug-in shipped with Oracle AVDF.

See Oracle Audit Vault and Database Firewall Installation Guide for the latest detailed platform support for the current release.

In addition, you can find platform information for prior releases in Article 1536380.1 at this website: https://support.oracle.com

This section contains:

Out-of-the Box Plug-ins at a Glance

Oracle AVDF out-of-the-box plug-ins support the secured target versions listed in Table B-1. Click the link for each secured target to get detailed information.

Table B-1 Out-of-the-Box Plug-ins and Features Supported in Oracle AVDF

Secured Target Version Audit Trail Collection Audit Policy Creation, Entitlement Auditing Stored Procedure Auditing Audit Trail Cleanup Database Firewall
Host Monitor Database Interrogation

Oracle Database

9i

       

Yes

   

Oracle Database

10g, 11g, 12c

Yes

Yes
(except Unified Audit Policies)

Yes

Yes

Yes

Yes

Yes

Microsoft SQL Server

2000

Yes

 

Yes

Yes

Yes

   

Microsoft SQL Server

2005

Yes

 

Yes

Yes

Yes

Yes (on Windows 2008)

Yes

Microsoft SQL Server

2008, 2008 R2

Yes

 

Yes

Yes

Yes

Yes (on Windows 2008, 2008 R2)

Yes

Microsoft SQL Server

2012

Yes

   

Yes

Yes

Yes

 

Sybase ASE

12.5.4 to 15.7

Yes

 

Yes

 

Yes

Yes

 

Sybase SQL Anywhere

10.0.1

   

Yes

 

Yes

Yes

Yes

IBM DB2 for LUW

9.x

Yes

 

Yes

 

Yes

Yes

 

MySQL

5.0, 5.1

   

Yes

 

Yes

Yes

 

MySQL

5.5, 5.6

Yes
Versions
5.5.29 to 5.6.12

 

Yes

Yes

Yes

Yes

 

Oracle Solaris

Version 10 and 11, on SPARC64 and x86-64 platforms

Yes

           

Oracle Solaris - other versions, see Note below.

Yes

           

Oracle Linux - Version 5

Versions OL 5.8, with auditd package 1.8 (run rpm -q audit to get audit package version)

Yes

           

Oracle Linux - Version 6

Version OL 6.0 with auditd package 2.0 (run rpm -q audit to get audit package version)

Yes

           

Oracle Linux - Version 6

Versions OL 6.1 to OL 6.4 with auditd package 2.2.2 (run rpm -q audit to get audit package version)

Yes

           

Microsoft Windows

Microsoft Windows Server 2008, and 2008 R2, on x86-64

Yes

           

Microsoft Active Directory

Version 2008, and 2008 R2 on 64 bit

Yes

           

Oracle ACFS

12c Release 1 (12.1)

Yes

           

Note:

Audit data can also be collected from Solaris version 2.3 or later (contact Oracle Support for guidance).

Oracle Database

Table B-2 lists features of the Oracle Database Plug-in.

Table B-2 Oracle Database Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.oracle

Secured Target Versions

Oracle 10g, 11g, 12c Release 1 (12.1)

Secured Target Platforms

Linux/x86-64

Solaris /x86-64

Solaris /SPARC64

AIX/Power64

Windows /86-64

HP-UX Itanium

Setup Script(s)

Yes. See "Oracle Database Setup Scripts" for instructions.

Secured Target Location (Connect String)

jdbc:oracle:thin:@//hostname:port/service

Collection Attribute(s)

ORCLCOLL.NLS_LANGUAGE
ORCLCOLL.NLS_TERRITORY
ORCLCOLL.NLS_TERRITORY
ORCLCOLL.MAX_PROCESS_TIME
ORCLCOLL.MAX_PROCESS_RECORDS
ORCLCOLL.RAC_INSTANCE_ID
ORCLCOLL.HEARTBEAT_INTERVAL
ORCLCOLL.HEARTBEAT_INTERVAL

See Table B-15 for details.

AVDF Audit Trail Types

TABLE

DIRECTORY

TRANSACTION LOG

SYSLOG (Linux only)

EVENT LOG (Windows only)

NETWORK

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

For TABLE audit trails: sys.aud$, Sys.fga_log$, dvsys.audit_trail$, vunified_audit_trail

For DIRECTORY audit trails: Full path to directory containing AUD or XML files.

For SYSLOG audit trails: Full path to directory containing the syslog file.

For TRANSACTION LOG, EVENT LOG and NETWORK audit trails: no trail location required.

Audit Trail Cleanup Support

Yes. See "Oracle Database Audit Trail Cleanup" for instructions.


Microsoft SQL Server

Table B-3 lists the features of the Microsoft SQL Server plug-in.

Table B-3 Microsoft SQL Server Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME\av\plugins\com.oracle.av.plugin.mssql

Secured Target Versions

2000, 2005, 2008, 2008 R2, 2012

Secured Target Platforms

Windows/x86-64

Setup Script(s)

Yes. "Microsoft SQL Server Setup Scripts" for instructions.

Secured Target Location (Connect String)

jdbc:av:sqlserver://hostname:port

Collection Attribute(s)

None

AVDF Audit Trail Types

DIRECTORY

EVENT LOG

NETWORK

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

For DIRECTORY audit trail: *.sqlaudit files, or *.trc (trace) files. Examples:

directory_path\*.sqlaudit

directory_path\prefix*.sqlaudit

directory_path\prefix*.trc

For prefix, you can use any prefix for the .trc or *.sqlaudit files.

#C2_DYNAMIC and #TRACE_DYNAMIC are only supported for SQL Server 2000, 2005, and 2008 versions.

For EVENT LOG audit trail:

  • application

  • security (SQL Server 2008 and 2012 only)

Audit Trail Cleanup Support

Yes. See "SQL Server Audit Trail Cleanup" for instructions.


Sybase ASE

Table B-4 lists the features of the Sybase ASE plug-in.

Table B-4 Sybase ASE Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.sybase

Secured Target Versions

12.5.4 to 15.7

Secured Target Platforms

All platforms

Setup Script(s)

Yes. See "Sybase ASE Setup Scripts" for instructions.

Secured Target Location (Connect String)

jdbc:av:sybase://hostname:port

Collection Attribute(s)

None

AVDF Audit Trail Types

TABLE

NETWORK

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

SYSAUDITS

Audit Trail Cleanup Support

No


Sybase SQL Anywhere

Table B-5 lists the features of the Sybase SQL Anywhere plug-in.

Table B-5 Sybase SQL Anywhere Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.sqlanywhere

Secured Target Versions

10.0.1

Secured Target Platforms

All platforms

Setup Script(s)

Yes. See "Sybase SQL Anywhere Setup Scripts" for instructions.

Secured Target Location (Connect String)

jdbc:av:sybase://hostname:port

Collection Attributes

None

AVDF Audit Trail Types

NETWORK (used for host monitoring only)

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

Not required

Audit Trail Cleanup Support

No


IBM DB2 for LUW

Table B-6 lists the features of the IBM DB2 for LUW plug-in.

Table B-6 IBM DB2 for LUW Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.db2

Secured Target Versions

9.x

Secured Target Platforms

All platforms

Setup Script(s)

Yes. See "IBM DB2 for LUW Setup Scripts" for instructions.

Secured Target Location (Connect String)

jdbc:av:db2://hostname:port

Collection Attribute(s)

av.collector.databasename (case sensitive) - (Required) Specifies the IBM DB2 for LUW database name.

AVDF Audit Trail Types

DIRECTORY

NETWORK

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

Path to a directory, for example: d:\temp\trace

Audit Trail Cleanup Support

No


MySQL

Table B-7 lists the features of the MySQL plug-in.

Table B-7 MySQL Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.mysql

Secured Target Versions

For Database Firewall: 5.0, 5.1, 5.5, 5.6.

For audit data collection: 5.5.29 to 5.6.12

Secured Target Platforms

Linux/x86-64

Windows 2008, 2008 R2 64-bit

Setup Script(s)

Yes. See "MySQL Setup Scripts".

Secured Target Location (Connect String)

jdbc:av:mysql://hostname:port/mysql

Collection Attribute(s)

av.collector.securedTargetVersion - (Required) Specifies the MySQL version.

av.collector.AtcTimeInterval - (Optional) Specifies the audit trail cleanup file update time interval in minutes. Default is 20.

AVDF Audit Trail Types

DIRECTORY

NETWORK

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

The path to the directory where converted XML files are created when you run the MySQL XML transformation utility. See "(Required for MySQL) Running the XML Transformation Utility".

Audit Trail Cleanup Support

Yes. See "MySQL Audit Trail Cleanup" for instructions.


Oracle Solaris

Table B-8 lists the features of the Oracle Solaris plug-in.

Table B-8 Oracle Solaris Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.solaris

Secured Target Versions

Version 10 update 6 or later, Version 11, on SPARC64 and x86-64 platforms

Secured Target Platforms

Solaris/x86-64

Solaris/SPARC64

Setup Script(s)

No

Secured Target Location (Connect String)

hostname (fully qualified machine name or IP address)

Collection Attribute(s)

None

AVDF Audit Trail Types

DIRECTORY

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

hostname:path_to_trail

The hostname matches the hostname in the audit log names, which look like this:

timestamp1.timestamp2.hostname

Audit Trail Cleanup Support

No


Oracle Linux

Table B-9 lists the features of the Oracle Linux plug-in.

Table B-9 Oracle Linux Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.linux

Secured Target Versions

  • OL 6.1 - 6.4 with auditd package 2.2.2

  • OL 6.0 with auditd package 2.0

  • OL 5.8 with auditd package 1.8

Run rpm -q audit to get the audit package version.

Secured Target Platforms

Linux/x86-64

Setup Script(s)

No. However, the following user/group access rights are needed to start Linux audit trail:

If the agent process is started with root user, no changes to access rights are needed.

If the agent process is started with a user other than root:

  1. Assign the group name of the Agent user (the one who will start the Agent process) to the log_group parameter in the /etc/audit/auditd.conf file.

  2. The Agent user and group must have read and execute permissions on the folder that contains the audit.log file (default folder is /var/log/audit).

  3. Restart the Linux audit service after you make the above changes.

Secured Target Location (Connect String)

hostname (fully qualified machine name or IP address)

Collection Attribute(s)

None

AVDF Audit Trail Types

DIRECTORY

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

Default location of audit.log (/var/log/audit/audit*.log) or any custom location configured in the /etc/audit/auditd.conf file

Audit Trail Cleanup Support

No


Microsoft Windows

Table B-10 lists the features of the Microsoft Windows plug-in.

Table B-10 Microsoft Windows Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME\av\plugins\com.oracle.av.plugin.winos

Secured Target Versions

Microsoft Windows Server 2008, and 2008 R2

Secured Target Platforms

Windows/x86-64

Setup Script(s)

No

Secured Target Location (Connect String)

hostname (fully qualified machine name or IP address)

Collection Attribute(s)

None

AVDF Audit Trail Types

EVENT LOG

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

security (case-sensitive)

Audit Trail Cleanup Support

No


Microsoft Active Directory

Table B-11 lists the features of the Microsoft Active Directory plug-in.

Table B-11 Microsoft Active Directory Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME\av\plugins\com.oracle.av.plugin.msad

Secured Target Versions

2008, and 2008 R2 on 64 bit

Secured Target Platforms

Windows/x86-64

Setup Script(s)

No

Secured Target Location (Connect String)

hostname (fully qualified machine name or IP address)

Collection Attribute(s)

None

AVDF Audit Trail Types

EVENT LOG

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

directory service or security (case-sensitive)

Audit Trail Cleanup Support

No


Oracle ACFS

Table B-12 lists the features of the Oracle ACFS plug-in.

Table B-12 Oracle ACFS Plug-in

Plug-in Specification Description

Plug-in directory

AGENT_HOME/av/plugins/com.oracle.av.plugin.acfs

Secured Target Versions

12c Release 1 (12.1)

Secured Target Platforms

Linux/x86-64

Solaris/x86-64

Solaris/SPARC64

Windows 2008, 2008 R2 64-bit

Setup Script(s)

No

Secured Target Location (Connect String)

hostname (fully qualified machine name or IP address)

Collection Attribute(s)

av.collector.securedtargetversion - (Required) Specify the Oracle ACFS version.

AVDF Audit Trail Types

DIRECTORY

See Table B-13 for descriptions of audit trail types.

Audit Trail Location

The path to the directory containing XML audit files. For example, for a file system mounted at $MOUNT_POINT, the audit trail location is:

$MOUNT_POINT/.Security/audit/

Audit Trail Cleanup Support

No


Data Collected for Each Audit Trail Type

When you configure an audit trail for a secured target, you select the type of audit trail in the Audit Trail Type field. The audit trail type depends on your secured target type. Table B-13 describes the types of audit trails that can be configured for each secured target type.

Refer to the product documentation for your secured target type for details on its auditing features and functionality. Refer to the following documentation for Oracle products:

Table B-13 Audit Trail Types Supported for Each Secured Target Type

Secured Target Type Trail Type Description

Oracle Database

TABLE

Releases 10.1.x, 10.2.x, 11.x, and 12.x

Collects from the following audit trails:

  • Oracle Database audit trail, where standard audit events are written to the SYS.AUD$ dictionary table

  • Oracle Database fine-grained audit trail, where audit events are written to the SYS.FGA_LOG$ dictionary table

  • Oracle Database Vault audit trail, where audit events are written to the DVSYS.AUDIT_TRAIL$ dictionary table

Oracle Database

DIRECTORY

Releases 10.1.x, 10.2.x, and 11.x

Collects data from the following audit trails:

  • On Linux and UNIX platforms: The Oracle database audit files written to the operating system (.aud) files, and syslog files (but not compressed syslog files)

  • On Windows platforms: The operating system Windows Event Log and operating system logs (audit logs) XML (.xml) files

Oracle Database

TRANSACTION LOG

Enterprise Edition Releases 10.2.0.3 and later, 11.1.0.6 and later

11.2 for REDO connection

Collects audit data from logical change records (LCRs) from the REDO logs. If you plan to use this audit trail type, you can define the data to audit by creating capture rules for the tables from which the Transaction Log trail type will capture audit information. See Oracle Audit Vault and Database Firewall Auditor's Guide for more information.

Note: For Oracle Database 12c, the Transaction Log audit trail is only supported when not using a PDB/CDB.

Oracle Database

SYSLOG

Collects Oracle audit records from syslog files on Linux and Unix platforms only

Oracle Database

EVENT LOG

Collects Oracle audit records from Microsoft Windows Event Log on Windows platforms only

Oracle Database

NETWORK

Collects network traffic (all database operations using a TCP connection). Used for host monitor.

Microsoft SQL Server

DIRECTORY

Collects audit data from C2 audit logs, server-side trace logs, and sqlaudit log files

Microsoft SQL Server

EVENT LOG

Collects audit data from Windows Event Logs. For Microsoft SQL Server 2008 and 2012, collection from the Security Event Log is also supported.

Microsoft SQL Server

NETWORK

Collects network traffic (all database operations using a TCP connection). Used for host monitor.

Sybase ASE

TABLE

Collects audit data from system audit tables (sysaudits_01 through sysaudits_08) in the sybsecurity database

Sybase ASE

NETWORK

Collects network traffic (all database operations using a TCP connection). Used for host monitor.

Sybase SQL Anywhere

NETWORK

(For host monitoring only) Collects network traffic (all database operations using a TCP connection).

IBM DB2 for LUW

DIRECTORY

Collects audit data from ASCII text files extracted from the binary audit log (db2audit.log). These files are located in the security subdirectory of the DB2 database instance.

IBM DB2 for LUW

NETWORK

Collects network traffic (all database operations using a TCP connection). Used for host monitor.

MySQL

DIRECTORY

Collects XML-based audit data from a specified location

MySQL

NETWORK

Collects network traffic (all database operations using a TCP connection). Used for host monitor.

Oracle Solaris

DIRECTORY

Collects Solaris Audit records (version 2) generated by the audit_binfile plug-in of Solaris Audit

Linux

DIRECTORY

Collects audit data from audit.log

Windows OS

EVENT LOG

Collects audit data from Windows Security Event Log

Microsoft Active Directory

EVENT LOG

Collects audit data from Windows Directory Service, and Security Event Logs

Oracle ACFS

DIRECTORY

Collects audit data from ACFS encryption and ACFS security sources.


Scripts for Oracle AVDF Account Privileges on Secured Targets

This section contains:

About Script for Setting up Oracle AVDF Account Privileges

You must set up a user account with appropriate privileges on each secured target for Oracle AVDF to use in performing functions related to monitoring and collecting audit data. Oracle AVDF provides setup scripts for database secured targets. Depending on the type of secured target, the scripts set up user privileges that allow Oracle AVDF to do the following functions:

  • Audit data collection

  • Audit policy management

  • Stored procedure auditing

  • User entitlement auditing

  • Database interrogation

  • Audit trail cleanup (for some secured targets)

When you deploy the Audit Vault Agent on a host computer (usually the same computer as the secured target), the setup scripts for creating the user permissions for Oracle AVDF are located in the following directory (Linux example below):

$AGENT_HOME/av/plugins/com.oracle.av.plugin.secured_target_type/config/

Oracle Database Setup Scripts

The Oracle AVDF setup scripts for an Oracle Database secured target,
oracle_user_setup.sql and oracle_drop_db_permissions.sql, are located in the following directory (Linux example below):

$AGENT_HOME/av/plugins/com.oracle.av.plugin.oracle/config/

These scripts are used to set up or revoke user privileges on the Oracle Database in order for Oracle AVDF to do the following functions:

  • Audit data collection

  • Audit policy management

  • Stored procedure auditing (SPA)

  • User entitlement auditing


To set up or revoke Oracle AVDF user privileges on an Oracle Database secured target:

  1. Create a user account for Oracle AVDF on the Oracle Database. For example:

    SQL> CREATE USER username IDENTIFIED BY password

    You will use this username and password when registering this Oracle Database as a secured target in the Audit Vault Server.

  2. Connect as user SYS with the SYSDBA privilege. For example:

    SQL> CONNECT SYS / AS SYSDBA

  3. To set up Oracle AVDF user privileges, run the setup script as follows:

    SQL> @oracle_user_setup.sql username mode

    • username: Enter the name of the user you created in Step 1.

    • mode: Enter one of the following:

      • SETUP: To set up privileges for managing the Oracle Database audit policy from Oracle AVDF, and for collecting data from any audit trail type except the REDO logs. For example, use this mode for a TABLE audit trail in Oracle AVDF.

      • REDO_COLL: To set up privileges for collecting audit data from the REDO logs. Use this mode only for a TRANSACTION LOG audit trail in Oracle AVDF.

      • SPA: To enable stored procedure auditing for this database

      • ENTITLEMENT: To enable user entitlement auditing for this database

  4. If Database Vault is installed and enabled on the Oracle database, log in as a user who has been granted the DV_OWNER role do the following:

    1. Grant the Oracle AVDF user the DV_SECANALYST role on this Oracle Database. For example:

      SQL> GRANT DV_SECANALYST TO username;
      

      For username, enter the user name you created in Step 1.

      The DV_SECANALYST role enables Oracle AVDF to monitor and collect audit trail data for Oracle Database Vault, and run Oracle Database Vault reports.

    2. For REDO_COLL mode (TRANSACTION LOG audit trail) only, execute one of these procedures depending on your Oracle Database version:

      For Oracle Database 12c:

      SQL> GRANT DV_STREAMS_ADMIN TO username;
      

      For username, enter the user name you created in Step 1.

      For all other supported Oracle Database versions:

      SQL> EXEC DBMS_MACADM.ADD_AUTH_TO_REALM('Oracle Data Dictionary', 'username', null, dbms_macutl.g_realm_auth_participant);
      SQL> COMMIT;
      

      For username, enter the user name you created in Step 1.

  5. To revoke Oracle AVDF user privileges, connect to this database as user SYS with the SYSDBA privilege, and run the following script:

    SQL> @oracle_drop_db_permissions.sql username mode

    • username - Enter the name of the user you created in Step 1.

    • mode - Enter one of the following:

      • SETUP: To revoke privileges for managing the Oracle Database audit policy from Oracle AVDF, and for collecting data from any audit trail type except the REDO logs.

      • REDO_COLL: To revoke privileges for collecting audit data from the REDO logs.

      • SPA: To disable stored procedure auditing for this database

      • ENTITLEMENT: To disable user entitlement auditing for this database

Sybase ASE Setup Scripts

This section contains:

About the Sybase ASE Setup Scripts

The following scripts are provided for configuring necessary user privileges for Oracle AVDF in a Sybase ASE secured target:


sybase_auditcoll_user_setup.sql
sybase_auditcoll_drop_db_permissions.sql
sybase_spa_user_setup.sql
sybase_spa_drop_db_permissions.sql

The scripts are located in the following directory (Linux example below):

$AGENT_HOME/av/plugins/com.oracle.av.plugin.sybase/config/

These scripts allow Oracle AVDF to perform the following functions for Sybase ASE:

  • Audit data collection

  • Stored procedure auditing (SPA)

Setting Up Audit Data Collection Privileges for a Sybase ASE Secured Target

To set up or revoke audit data collection privileges on a Sybase ASE secured target:

  1. Create a user account for Oracle AVDF in Sybase ASE with the user name
    avdf_sybuser. For example:

    sp_addlogin avdf_sybuser, password

    You will use the user name av_sybuser and password when registering this Sybase ASE database as a secured target in the Audit Vault Server.

  2. Run the setup sybase_auditcoll_user_setup.sql script as follows:

    isql -S server_name -U sa -i sybase_auditcoll_user_setup.sql
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

  3. When prompted for a password, enter the system administrator password.

  4. To revoke the Oracle AVDF user privileges, run the sybase_auditcoll_drop_db_permissions.sql script as follows:

    isql -S server_name -U sa -i sybase_auditcoll_drop_db_permissions.sql
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • When prompted for a password, enter the system administrator password.

Setting Up Stored Procedure Auditing Privileges for a Sybase ASE Secured Target

To set up or revoke stored procedure auditing privileges on a Sybase ASE secured target:

  1. If you have not already done so, create a user account for Oracle AVDF in Sybase ASE with the user name avdf_sybuser. For example:

    sp_addlogin avdf_sybuser, password

    You will use the user name av_sybuser and password when registering this Sybase ASE database as a secured target in the Audit Vault Server.

  2. Run the sybase_spa_user_setup.sql script as follows:

    isql -S server_name -U sa -i sybase_spa_user_setup.sql
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

  3. When prompted for a password, enter the system administrator password.

  4. To revoke the SPA user privileges, run the sybase_spa_drop_db_permissions.sql script as follows:

    isql -S server_name -U sa -i sybase_spa_drop_db_permissions.sql
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • When prompted for a password, enter the system administrator password.

Sybase SQL Anywhere Setup Scripts

The Oracle AVDF setup scripts for a Sybase SQL Anywhere secured target,
sqlanywhere_spa_user_setup.sql
and sqlanywhere_spa_drop_db_permissions.sql, are located in the following directory (Linux example below):

$AGENT_HOME/av/plugins/com.oracle.av.plugin.sqlanywhere/config/

These scripts are used to set up or revoke user privileges on the SQL Anywhere database for Oracle AVDF to do stored procedure auditing (SPA).

To set up or revoke stored procedure auditing for a SQL Anywhere secured target:

  1. Log in to the database as a user who has privileges to create users and set user permissions.

  2. Run the sqlanywhere_spa_user_setup.sql script as follows:

    isql -S server_name -U sa -i sqlanywhere_spa_user_setup.sql -v username="username" password="password"
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • username: Enter the name of the user you want to create for Oracle AVDF to use for SPA. Enclose this user name in double quotation marks.

    • password: Enter a password for the Oracle AVDF SPA user you are creating. Enclose the password in double quotation marks.

    After running the script, the user is created with privileges for SPA.

  3. When prompted for a password, enter the system administrator password.

  4. To revoke these privileges and remove this user from the database, run the
    sqlanywhere_spa_drop_db_permissions.sql as follows:

    isql -S server_name -U sa -i sqlanywhere_spa_drop_db_permissions.sql -v username="username"
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • username: Enter the name of the user you want to create for Oracle AVDF to use for SPA. Enclose this user name in double quotation marks.

    • When prompted for a password, enter the system administrator password.

Microsoft SQL Server Setup Scripts

This section contains:

About the SQL Server Setup Script

The Oracle AVDF setup scripts for a Microsoft SQL Server secured target,
mssql_user_setup.sql and mssql_drop_db_permissions.sql, are located in the following directory:

AGENT_HOME\av\plugins\com.oracle.av.plugin.mssql\config\

The scripts set up or revoke user privileges for Oracle AVDF to perform the following functions for SQL Server:

  • Audit data collection

  • Stored procedure auditing (SPA)

Setting Up Audit Data Collection Privileges for a SQL Server Secured Target

To set up or revoke Oracle AVDF user privileges for audit data collection:

  1. Create a user account for Oracle AVDF in SQL Server. For example:

    In SQL Server 2000:

    exec sp_addlogin 'username', 'password'
    

    In SQL Server 2005, 2008, 2012:

    exec sp_executesql N'create login username with password = ''password'', 
    check_policy= off'
    
    exec sp_executesql N'create user username for login username'
    

    You will use this user name and password when registering this SQL Server database as a secured target in the Audit Vault Server.

  2. Run the mssql_user_setup.sql script as follows:

    sqlcmd -S server_name -U sa -i mssql_user_setup.sql -v username="username" mode="AUDIT_COLL" all_databases="NA" database="NA"
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • username: Enter the name of the user you created in Step 1.

  3. When prompted for a password, enter the system administrator password.

  4. To revoke audit data collection privileges run the
    mssql_drop_db_permissions.sql script as follows:

    sqlcmd -S server_name -U sa -i mssql_drop_db_permissions.sql -v username="username" mode="AUDIT_COLL" all_databases="NA" database="NA"
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • username: Enter the name of the user you created in Step 1.

    • When prompted for a password, enter the system administrator password.

Setting Up Stored Procedure Auditing Privileges for a SQL Server Secured Target

To set up or revoke Oracle AVDF user privileges for stored procedure auditing:

  1. If you have not already done so, create a user account for Oracle AVDF in SQL Server. For example:

    In SQL Server 2000:

    exec sp_addlogin 'username', 'password'
    

    In SQL Server 2005 and 2008:

    exec sp_executesql N'create login username with password = ''password'', 
    check_policy= off'
    
    exec sp_executesql N'create user username for login username'
    

    You will use this user name and password when registering this SQL Server database as a secured target in the Audit Vault Server.

  2. Run the mssql_user_setup.sql script as follows:

    sqlcmd -S server_name -U sa -i mssql_user_setup.sql -v username="username" mode="SPA" all_databases="Y/N" 
    database="NA/database_name"
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • username: Enter the name of the user you created in Step 1.

    • Y/N: Enter Y if all databases should be audited for stored procedures. Enter N to specify one database name in the database parameter.

    • NA/database_name: If you entered Y for all_databases, enter NA. If you entered N for all_databases, enter the database name that should be audited for stored procedures.

  3. When prompted for a password, enter the system administrator password.

  4. To revoke SPA privileges run the mssql_drop_db_permissions.sql script as follows:

    sqlcmd -S server_name -U sa -i mssql_drop_db_permissions.sql -v username="username" mode="SPA" all_databases="Y/N" 
    database="NA/database_name"
    
    • server_name: Only use this argument if the database is remote. Enter the name of the remote server or its IP address. If you are running the script locally, then omit the -S server_name argument.

    • sa: Enter the system administrator user name.

    • sa_password: Enter the system administrator password.

    • Y/N: Enter Y if SPA privileges for all databases should be revoked. Enter N to specify one database name in the database parameter.

    • NA/database_name: If you entered Y for all_databases, enter NA. If you entered N for all_databases, enter the database name for which SPA privileges should be revoked.

    • When prompted for a password, enter the name of the user you created in Step 1.

IBM DB2 for LUW Setup Scripts

This section contains:

About the IBM DB2 for LUW Setup Scripts

The Oracle AVDF setup scripts for a DB2 secured target,
db2_auditcoll_user_setup.sql and db2_spa_user_setup.sql, are located in the following directory (Linux example below):

$AGENT_HOME/av/plugins/com.oracle.av.plugin.db2/config/

These scripts are used to set up or revoke user privileges on the DB2 database for Oracle AVDF to do the following functions:

  • Audit data collection

  • Stored procedure auditing (SPA)

Setting Up Audit Data Collection Privileges for IBM DB2 for LUW

To set up or revoke Oracle AVDF user privileges for audit data collection:

  1. Create a new user account in DB2 to be used by Oracle AVDF for audit data collection.

    You will use this user name and password when registering this DB2 database as a secured target in the Audit Vault Server.

  2. In the $AGENT_HOME/av/plugins/com.oracle.av.plugin.db2/config/ directory, locate the db2_auditcoll_user_setup.sql script and open it for editing.

  3. In the script, put the user name of the account from Step 1 in the grant statement, then save the modified script.

  4. Execute the modified script as follows:

    $> db2 -tvf db2_auditcoll_user_setup.sql

  5. To revoke audit collection privileges:

    1. Modify the db2_auditcoll_drop_db_permissions.sql script as in Step 3 above.

    2. Run the script as follows:

      $> db2 -tvf db2_auditcoll_drop_db_permissions.sql

Setting Up SPA Privileges for an IBM DB2 for LUW Secured Target

To set up or revoke Oracle AVDF user privileges for stored procedure auditing:

  1. Create a new user account in DB2 to be used by Oracle AVDF for stored procedure auditing.

    You will use this user name and password when registering this DB2 database as a secured target in the Audit Vault Server.

  2. In the $AGENT_HOME/av/plugins/com.oracle.av.plugin.db2/config/ directory, locate the db2_spa_user_setup.sql script and open it for editing.

  3. In the script, put the user name of the account from Step 1 in the grant statement, then save the modified script.

  4. Execute the modified script as follows:

    $> db2 -tvf db2_spa_user_setup.sql

  5. To revoke SPA privileges:

    1. Modify the db2_spa_drop_db_permissions.sql script as in Step 3 above.

    2. Run the script as follows:

      $> db2 -tvf db2_spa_drop_db_permissions.sql

MySQL Setup Scripts

The Oracle AVDF setup scripts for a MySQL secured target,
mysql_spa_user_setup.sql
and mysql_spa_drop_db_permissions.sql, are located in the following directory (Linux example below):

$AGENT_HOME/av/plugins/com.oracle.av.plugin.mysql/config/

These scripts are used to set up or revoke user privileges on the MySql database for Oracle AVDF to do stored procedure auditing (SPA).

To set up or revoke stored procedure auditing for a MySql secured target:

  1. Log in to MySQL as a user who can create users and set user privileges.

  2. Create a user for stored procedure auditing. For example:

    create user 'username'@'hostname' identified by 'password'

    You will use this user name and password when registering this MySQL database as a secured target in the Audit Vault Server.

  3. In the $AGENT_HOME/av/plugins/com.oracle.av.plugin.mysql/config/ directory, locate the mysql_spa_user_setup.sql script and open it for editing.

  4. Modify the script to provide the same values for username, hostname, and password that you used in Step 1.

  5. Execute the mysql_spa_user_setup.sql script.

  6. To revoke SPA privileges:

    1. Modify the mysql_spa_drop_db_permissions.sql script as in Step 4 above.

    2. Execute the mysql_spa_drop_db_permissions.sql script.

Audit Trail Cleanup

Some Oracle AVDF plug-ins support audit trail cleanup. This section describes the available audit trail cleanup (ATC) utilities:

Oracle Database Audit Trail Cleanup

This section contains:

About Purging the Oracle Database Secured Target Audit Trail

You can use the DBMS_AUDIT_MGMT PL/SQL package to purge the database audit trail.

The DBMS_AUDIT_MGMT package lets you perform audit trail cleanup tasks such as scheduling purge jobs, moving the audit trail to a different tablespace, setting archive timestamps in the audit trail, and so on. You must have the EXECUTE privilege for DBMS_AUDIT_MGMT before you can use it.

Oracle Database 11g Release 2 (11.2) or higher, includes the DBMS_AUDIT_MGMT package and its associated data dictionary views installed by default. If your secured target database does not have this package installed, then you can download the package and data dictionary views from My Oracle Support, from the following Web site:

https://support.oracle.com

Search for Article ID 731908.1.

For details about using the DBMS_AUDIT_MGMT PL/SQL package and views, refer to the following Oracle Database 11g Release 2 (11.2) documentation:

Scheduling an Automated Purge Job

Oracle AVDF is integrated with the DBMS_AUDIT_MGMT package on an Oracle Database. This integration automates the purging of audit records from the AUD$ and FGA_LOG$ files, and from the operating system .aud and .xml files after they have been successfully inserted into the Audit Vault Server repository.

After the purge is completed, the Audit Vault Agent automatically sets a timestamp on audit data that has been collected. Therefore, you must set the USE_LAST_ARCH_TIMESTAMP property to TRUE to ensure that the right set of audit records are purged. You do not need to manually set a purge job interval.

To schedule an automated purge job for an Oracle Database secured target:

  1. Log in to SQL*Plus on the secured target database as a user who has been granted the EXECUTE privilege for the DBMS_AUDIT_MGMT PL/SQL package.

    For example:

    sqlplus tjones
    Enter password: password
    
  2. Initialize the audit trail cleanup operation.

    In the following example, the DEFAULT_CLEANUP_INTERVAL setting runs the job every two hours:

    BEGIN
     DBMS_AUDIT_MGMT.INIT_CLEANUP(
      AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
      DEFAULT_CLEANUP_INTERVAL    => 2 );
    END;
    /
    
  3. Verify that the audit trail is initialized for cleanup.

    For example:

    SET SERVEROUTPUT ON
    BEGIN
     IF
       DBMS_AUDIT_MGMT.IS_CLEANUP_INITIALIZED(DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL)
     THEN
       DBMS_OUTPUT.PUT_LINE('Database and OS audit are initialized for cleanup');
     ELSE
       DBMS_OUTPUT.PUT_LINE('Database and OS audit are not initialized for cleanup.');
     END IF;
    END;
    /
    
  4. Use the DBMS_AUDIT_MGMT.CREATE_PURGE_JOB procedure to create and schedule the purge job.

    In this procedure, ensure that you set the USE_LAST_ARCH_TIMESTAMP property to TRUE, so all records older than the timestamp can be deleted.

    The following procedure creates a purge job called CLEANUP_OS_DB_AUDIT_RECORDS that will run every two hours to purge the audit records.

    BEGIN
      DBMS_AUDIT_MGMT.CREATE_PURGE_JOB (
       AUDIT_TRAIL_TYPE            => DBMS_AUDIT_MGMT.AUDIT_TRAIL_ALL,
       AUDIT_TRAIL_PURGE_INTERVAL  => 2,
       AUDIT_TRAIL_PURGE_NAME      => 'CLEANUP_OS_DB_AUDIT_RECORDS',
       USE_LAST_ARCH_TIMESTAMP     => TRUE );
    END;
    /
    

SQL Server Audit Trail Cleanup

If the SQL Server audit trail has collected data from a trace or sqlaudit file and that file is inactive, then you can clean up this file. The SQL Server audit trail writes the names of the SQL Server audit text files to a plain text file with the .atc extension. The .atc file resides in the AGENT_HOME\av\atc directory on the computer on which the agent is installed.

To manually clean up files that Oracle AVDF has completed extracting audit records from:

  1. Go to the AGENT_HOME\av\plugins\com.oracle.av.plugin.mssql\bin directory of the computer where the Audit Vault Agent is installed.

    Ensure that the AGENT_HOME environment variable is correctly set to the directory path where the agent.jar file is extracted.

  2. Run the following utility:

    SQLServerCleanupHandler secured_target_name
    

    For example:

    SQLServerCleanupHandler mssqldb4
    

    If you do not set the AGENT_HOME environment variable, you can provide the agent home location in the command line using the following syntax:

    SQLServerCleanupHandler -securedtargetname secured_target_name agent_home_location
    

    For example:

    SQLServerCleanupHandler mssqldb4 c:\AV_agent_installation
    

    Important: If the name of the Audit Vault Agent installation directory contains spaces, enclose the name in double quotes, for example "C:\Agent Directory".

To automate the cleanup of SQL Server trace files, you can use the Windows Scheduler.

Note:

If the SQL Server trace definition is redefined or reinitialized, then you must ensure that the file names of the trace files do not overlap with trace files that were created earlier.

For example, suppose you start SQL Server with a trace definition in which the trace files names use the following format:

c:\serversidetraces.trc
c:\serversidetraces_1.trc
c:\serversidetraces_2.trc
...
c:\serversidetraces_259.trc

Then you restart the SQL Server with a new trace definition. This new trace definition must use a different file name from the current trace files (for example, the current one named c:\serversidetraces.trc). If you do not, then when you purge the audit trail, the new trace files that have same names as the old ones will be deleted.

MySQL Audit Trail Cleanup

To run the MySQL audit trail cleanup utility:

  1. On the host machine, go to the directory
    AGENT_HOME\av\plugins\com.oracle.av.plugin.mysql\bin

  2. Run the following command:

    MySQLServerCleanupHandler.bat secured_target_name AGENT_HOME

    The above command has the following variables:

    • secured_target_name - the name of the MySQL secured target

    • AGENT_HOME - the path to the directory where the Audit Vault Agent is deployed.

Procedure Look-ups: Connect Strings, Collection Attributes, Audit Trail Locations

This section contains reference information you will need to complete procedures in this manual for registering secured targets and configuring audit trails. The procedural steps include links to the following sections:

Secured Target Locations (Connect Strings)

When registering a secured target in the Audit Vault Server console, you enter a connect string in the Secured Target Location field (see "Registering or Removing Secured Targets in the Audit Vault Server"). Use a connect string format from Table B-14 depending on the secured target type.

Note: A connect string is not required for a Database Firewall-only deployment.

Table B-14 Secured Target Connect Strings (for Secured Target Location Field)

Secured Target Type Connect String

Oracle Database

jdbc:oracle:thin:@//hostname:port/service

Sybase ASE

jdbc:av:sybase://hostname:port

Sybase SQL Anywhere

jdbc:av:sybase://hostname:port

Microsoft SQL Server

jdbc:av:sqlserver://hostname:port

IBM DB2 for LUW

jdbc:av:db2://hostname:port

MySQL

jdbc:av:mysql://hostname:port/mysql

Oracle Solaris

hostname (fully qualified machine name or IP address)

Oracle Linux

hostname (fully qualified machine name or IP address)

Microsoft Windows

hostname (fully qualified machine name or IP address)

Microsoft Active Directory Server

hostname (fully qualified machine name or IP address)

Oracle ACFS

hostname (fully qualified machine name or IP address)


Collection Attributes

This section contains:

About Collection Attributes

Some types of secured targets have optional or required audit trail collection attributes. You can specify collection attributes when registering or modifying a secured target in the Collection Attributes fields. See "Registering or Removing Secured Targets in the Audit Vault Server".

The following secured target types do not require collection attributes:

  • Microsoft SQL Server

  • Sybase ASE

  • Oracle Solaris

  • Windows

  • Linux

  • Microsoft Active Directory Server

Oracle Database Collection Attributes

You can specify collection attributes for a DIRECTORY audit trail for Oracle Database. Table B-15 describes the collection attributes you can use if you select DIRECTORY as the Audit Trail Type when registering an Oracle Database secured target in Oracle AVDF.

Table B-15 Collection Attributes for DIRECTORY Audit Trail for Oracle Database

Attribute Name and Description Required? Default Comments

ORCLCOLL.NLS_LANGUAGE

The NLS language of the data source

Yes: If the started audit trail cannot establish a connection to the Oracle secured target (e.g., secured target is not running)

No: If the started audit trail is able to connect to the Oracle secured target and get these parameter values from the secured target (e.g., the secured target is running when the trail is started)

NA

The value is not case sensitive.

ORCLCOLL.NLS_TERRITORY

The NLS territory of the data source

Yes: If the started audit trail cannot establish a connection to the Oracle secured target (e.g., secured target is not running)

No: If the started audit trail is able to connect to the Oracle secured target and get these parameter values from the secured target (e.g., the secured target is running when the trail is started)

NA

The value is not case sensitive.

ORCLCOLL.NLS_CHARSET

The NLS character set of the data source

Yes: If the started audit trail cannot establish a connection to the Oracle secured target (e.g., secured target is not running)

No: If the started audit trail is able to connect to the Oracle secured target and get these parameter values from the secured target (e.g., the secured target is running when the trail is started)

NA

The value is not case sensitive.

ORCLCOLL.MAX_PROCESS_TIME

The maximum processing time, in centiseconds, for each call to process the audit trail

No

600

A valid value is an integer value from 10 to 10000. Cannot be reconfigured at run time.

Indicates the maximum time for which the collection process records before sending a batch of records to the Audit Vault Server. If the value is too low it can affect performance. If the value is too high, it will take a longer time to stop the audit trail.

ORCLCOLL.MAX_PROCESS_RECORDS

The maximum number of records to be processed during each call to process the audit trail

No

1000

A valid value is an integer value from 10 to 10000.

Cannot be reconfigured at run time.

Indicates the maximum number of records processed before sending a batch of records to the Audit Vault Server. If the value is too low it can affect performance. If the value is too high, it will take a longer time to stop the audit trail.

ORCLCOLL.RAC_INSTANCE_ID

The instance ID in an Oracle RAC environment

No

1

 

ORCLCOLL.HEARTBEAT_INTERVAL

The interval, in seconds, to store the metric information

No

60

Cannot be reconfigured at run time.

This interval determines how frequently metric information is updated. If the value is too low it creates overhead for sending metrics to the Audit Vault Server. If the value is too high it will skew the average metric information.

ORCLCOLL.NT_ORACLE_SID

The Oracle SID name on a Microsoft Windows systems

No

No default

The value is not case sensitive. If no value is specified then the audit trail queries the value from the secured target.


IBM DB2 for LUW Collection Attribute

Table B-16 describes the collection attribute required when you register an IBM DB2 for LUW secured target in Oracle AVDF.

Table B-16 Collection Attribute for IBM DB2 for LUW Database

Attribute Name and Description Required? Default Comments

av.collector.databasename

The IBM DB2 for LUW database name

Yes

NA

This parameter is case sensitive.


MySQL Collection Attributes

Table B-17 describes the required and optional collection attributes when you register a MySQL secured target in Oracle AVDF.

Table B-17 Collection Attributes for MySQL Database

Attribute Name and Description Required? Default Comments

av.collector.securedTargetVersion

The MySQL database version

Yes

NA

 

av.collector.AtcTimeInterval

Specifies a time interval, in minutes, at which the audit trail cleanup time is updated

No

20

Example: If this value is 20, the audit trail cleanup time is updated every 20 minutes. Audit log files that have a time stamp before the audit trail cleanup time will be cleaned from the source folder when you run the audit trail cleanup utility. See also "MySQL Audit Trail Cleanup".


Oracle ACFS Collection Attributes

Table B-18 describes the collection attribute required when you register an Oracle ACFS secured target in Oracle AVDF.

Table B-18 Collection Attribute for Oracle ACFS

Attribute Name and Description Required? Default Comments

av.collector.securedtargetversion

The version number of Oracle ACFS

Yes

NA

Five integer values separated by dots, for example 12.1.0.0.0.


Audit Trail Locations

When you configure an audit trail for a secured target in the Audit Vault Server, you must specify a Trail Location (see "Adding an Audit Trail in the Audit Vault Server"). The trail location depends on the type of secured target. Use the format below that corresponds to your secured target type.

Important: Trail locations are case sensitive. To avoid duplicate data collection, we recommend that you provide the entire trail location either in all capital letters or all small letters.

Note: If you selected DIRECTORY for Audit Trail Type, the Trail Location must be a directory mask.

Table B-19 Supported Trail Locations for Secured Targets

Secured Target Type Supported Trail Locations

Oracle Database

For TABLE audit trails: sys.aud$, Sys.fga_log$,
dvsys.audit_trail$
, v$unified_audit_trail

For DIRECTORY audit trails: Full path to directory containing AUD or XML files.

For SYSLOG audit trails: Full path to directory containing the syslog file.

For TRANSACTION LOG, EVENT LOG and NETWORK audit trails: no trail location required.

Microsoft SQL Server

For DIRECTORY audit trail: *.sqlaudit files, or *.trc (trace) files. Examples:

directory_path\*.sqlaudit

directory_path\prefix*.sqlaudit

directory_path\prefix*.trc

For prefix, you can use any prefix for the .trc or *.sqlaudit files.

#C2_DYNAMIC and #TRACE_DYNAMIC are only supported for SQL Server 2000, 2005, 2008, 2012.

For EVENT LOG audit trail:

  • application

  • security (SQL Server 2008 and 2012 only)

Sybase ASE

SYSAUDITS

IBM DB2 for LUW

Path to a directory, for example: d:\temp\trace

MySQL

The path to the directory where converted XML files are created when you run the MySQL XML transformation utility. See "(Required for MySQL) Running the XML Transformation Utility".

Oracle Solaris

hostname:path_to_trail

The hostname matches the hostname in the audit log names, which look like this:

timestamp1.timestamp2.hostname

Microsoft Windows

security (case-insensitive)

You can use any case combination in the word security. However, once you start collecting a trail using a particular case case combination, you must use the same combination in subsequent collections, otherwise, a new audit trail will start collecting records from the start of the security event log.

Microsoft Active Directory Server

directory service or security (case-insensitive)

You can use any case combination in the words directory service or security. However, once you start collecting a trail using a particular case combination, you must use the same combination in subsequent collections, otherwise, a new audit trail will start collecting records from the start of the security event log.

Oracle ACFS

The path to the directory containing XML audit files. For example, for a file system mounted at $MOUNT_POINT, the audit trail location is:

$MOUNT_POINT/.Security/audit/

Linux

Default location of audit.log (/var/log/audit/audit*.log) or any custom location configured in the /etc/audit/auditd.conf file