1. Administrator's Guide
  2. Getting Started with Oracle Audit Vault and Database Firewall
  3. Configuring Audit Vault Server

4 Configuring Audit Vault Server

Learn about configuring Audit Vault Server.

4.1 About Configuring Audit Vault Server

Learn about configuring Audit Vault Server.

This chapter explains how to perform the initial Audit Vault Server configuration.

Note:

Audit Vault Server and Database Firewall are software appliances. You must not make changes to the Linux operating system through the command line on these servers unless you are following procedures as described in the official Oracle documentation or you are working under the guidance of Oracle Support.

The main steps involved in the configuration process are as follows:

  1. Perform the initial configuration tasks at the Audit Vault Server. For example, confirm system services and network settings, and set the date and time.

  2. (Optional) Configure the Audit Vault Agents.

  3. (Optional) Define resilient pairs of servers for high availability.

  4. (Optional) Add each Database Firewall at Audit Vault Server.

  5. (Optional) Configure Oracle Audit Vault and Database Firewall to work with third party Security Information Event Management (SIEM) products that can read from Syslog.

  6. (Optional) Configure Microsoft Active Directory or Open LDAP.

  7. Check that the system is functioning correctly.

See Also:

4.2 Changing the UI (Console) Certificate for Audit Vault Server

Learn how to change the UI certificate for Audit Vault Server.

When you first access the Audit Vault Server console, you see a certificate warning or message. To avoid this type of message, you can upload a new UI certificate signed by a relevant certificate authority.

Prerequisite

Log in to Audit Vault Server console as a super administrator. See Using Audit Vault Server Console for more information

To change the UI certificate for the Audit Vault Server:

  1. Click Settings.
  2. Click the Security tab in the left navigation menu.
  3. Click the Certificate sub-tab on the main page.
  4. Click Console Certificate.
  5. Click Generate Certificate Request.

    The Generate Certificate Request dialog is displayed with the Common Name for the certificate.

  6. If you want to change the common name that is displayed, then click Change.

    The certificate warnings are based on the common name used to identify Audit Vault Server. To suppress the warning when you access Audit Vault Server console using its IP address instead of the host name, also check Suppress warnings for IP based URL access.

  7. Complete the form and enter content in the mandatory fields.
  8. Click Submit and Download.
  9. Save the .csr file and then submit this file to a certificate authority. Ensure that the certificate contains the following details. The COMMON NAME field is filled by default.
    COMMON NAME
    ISSUER COMMON NAME
  10. After the certificate authority issues a new certificate, upload it by returning to the Console Certificate sub tab, and then click Upload Certificate.

Note:

You may need to install the public certificate of the Certificate Authority in your browser, particularly if you are using your own public key infrastructure.

The certificate is valid for a specific duration as listed in the table below:

4.3 Specifying Initial System Settings and Options on Audit Vault Server (Required)

Learn how to specify initial system settings and options on Audit Vault Server.

4.3.1 Specifying the Server Date, Time, and Keyboard Settings

Learn how to specify the Audit Vault Server date, time, and keyboard settings.

Super administrators can change the Audit Vault Server date, time, and keyboard settings. It is important to ensure that the date and time that you set for Audit Vault Server are correct. This is because events that the server generates are logged with the date and time at which they occur according to the server's settings. In addition, archiving occurs at specified intervals based on the server's time settings.

About Timestamps

Audit Vault Server stores all data in UTC. Timestamps are displayed as follows:

  • If you are accessing data interactively, for example using the Audit Vault Server console or AVCLI command line, then all timestamps are in your time zone. In the UI, the time zone is derived from the browser time zone. If you are using AVCLI, then the time zone is derived from the "shell" time zone (usually set by the TZ environment variable).

  • If you log in to Audit Vault Server as root or support, then timestamps are displayed in UTC, unless you change the TZ environment variable for that session.

  • If you are looking at a PDF or XLS report that is generated by the system, then the timestamps displayed reflect the Time Zone Offset setting in the Audit Vault Server Manage link (see procedure below).

    WARNING:

    Do not change the Audit Vault Server database time zone through any configuration files. Doing so causes serious problems in Audit Vault Server.

Prerequisite

Log in to Audit Vault Server console as super administrator. See Using Audit Vault Server Console for more information.

Set the Server Date, Time, and Keyboard Settings

  1. Click Settings tab.

  2. Click on the System tab in the left navigation menu.

  3. In the Configuration tab on the main page:

  4. For Oracle AVDF 20.3 and later, click the Time & Keyboard tab in the System Settings dialog box.

  5. From the Timezone Offset drop down list, select your local time in relation to Coordinated Universal Time (UTC). Timezone Offset is used in non-interactive scheduled PDF or XLS reports. The time set here is converted to local time and is displayed in Event Time field of the report.

    For example, -5:00 is five hours behind UTC. You must select the correct setting to ensure that the time is set accurately during synchronization.

    Note:

    To change the time only for the console and to the specific user session, follow the steps in Changing the Time Zone. This functionality is available starting with Oracle AVDF release 20.6.

  6. From the Keyboard drop down list, select the keyboard setting.

  7. In the System Time field, select Set Manually or Use NTP.

    Selecting NTP synchronizes time with the average of the time recovered from the time servers specified in the NTP Server 1/2/3 fields.

  8. Select Use NTP, and then select Synchronize Periodically to start using the NTP Server time.

    If you do not enable time synchronization in this step, then you can still enter NTP Server information in the steps below and enable NTP synchronization later.

  9. Optionally select Synchronize Once After Save, to synchronize the time once when you click Save.

  10. In the NTP Server 1, NTP Server 2, and NTP Server 3 sections enter the IP addresses or names of your preferred time servers.

    If you specify a name, then the DNS server that is specified in the Services dialog under System tab is used for name resolution.

  11. Click Test Server to display the time from the server.

    Click Apply Server to update the Audit Vault Server time from this NTP server. The update will not take effect until you click Save.

  12. Click Save.

Note:

  • In case of high availability environment the steps above change the time only on the primary Audit Vault Server.
  • In case of NTP, specify the IP address of the default gateway and a DNS server to enable time synchronization.

Set the Time on Secondary Audit Vault Server

In case of high availability environment it is important that the primary and secondary Audit Vault Servers must have same time. Follow the steps below to manually set the time on the secondary Audit Vault Server.

For Oracle AVDF 20, follow these steps:

  1. Log in to the secondary Audit Vault Server as root user.

  2. Run the following commands:

    systemctl stop monitor
    systemctl stop controller
    systemctl stop dbfwdb
    systemctl stop asmdb

  3. Set the date and time by running the following command:

    date -s "Day Month DD HH:MM:SS UTC YYYY"

    For example:

    date -s "Fri Jun 02 07:51:17 UTC 2021"

  4. Run the following commands:

    systemctl start asmdb
    systemctl start dbfwdb
    systemctl start controller
    systemctl start monitor
  5. Verify the high availability status. It should be High Availability mode is enabled.

For Oracle AVDF 12.2, follow these steps:

  1. Log in to the secondary Audit Vault Server as root user.

  2. Run the following commands:

    /etc/init.d/monitor stop
    /etc/init.d/controller stop
    /etc/init.d/dbfwdb stop
    /etc/init.d/asmdb stop

  3. Set the date and time by running the following command:

    date -s "Day Month DD HH:MM:SS UTC YYYY"

    For example:

    date -s "Fri Jun 02 07:51:17 UTC 2021"

  4. Run the following commands:

    /etc/init.d/asmdb start
    /etc/init.d/dbfwdb start
    /etc/init.d/controller start
    /etc/init.d/monitor start
  5. Verify the high availability status. It should be High Availability mode is enabled.

See Also:

4.3.2 Changing the Time Zone

Learn how to change the time zone in the Audit Vault Server console only for the active session.

The time can be changed in the Audit Vault Server console only for the active session. This is limited only for the console (User Interface). This functionality is available starting with Oracle AVDF release 20.6. Follow these steps:

  1. Log in to the Audit Vault Server console as Administrator, Super Auditor, Auditor, or Readonly Auditor.
  2. Click the drop down icon next to the user name in the top right corner. For example, Admin or Auditor user icon.
  3. Click Change Timezone option.
  4. In the Change Timezone dialog, select your time zone in relation to Coordinated Universal Time (UTC).
  5. Click Save.

    Note:

    • The time zone changed here is applicable only to the user's active session. The timestamps in the Audit Vault server console also reflect the selected time zone.
    • This time zone changed here is not reflected in the non-interactive (PDF/ XLS) reports. To change the time in the reports, follow the steps mentioned in Specifying the Server Date, Time, and Keyboard Settings.

4.3.3 Specifying Audit Vault Server System Settings

Learn about configuring Audit Vault Server system settings.

4.3.3.1 Changing the Primary Audit Vault Server Network Configuration

The Oracle Audit Vault and Database Firewall (Oracle AVDF) installer configures the initial network settings for Audit Vault Server during installation. You can change the network settings after installation.

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click the Settings tab.
  3. Click System in the left navigation menu.
  4. Under Configuration, click Network Settings.
  5. In the Network Settings dialog box, edit any of the following fields:
    • Host Name: Enter the fully qualified domain name of the Audit Vault Server. The host name must start with a letter, can contain a maximum of 64 characters, and cannot contain spaces.

      Note:

      • Changing the host name reconfigures the Audit Vault Server automatically. After changing the host name and clicking Save, the system prompts for confirmation and reconfigures the Audit Vault Server. The Audit Vault Server console is unavailable for a minimum of 10 minutes. After this, the updated host name appears in the Network Settings dialog box.
      • In Oracle AVDF releases 20.1 to 20.6, you can't change the host name in a high availability environment. If you need to change the host name, unpair the Audit Vault Servers, change the host name, and pair them again.
      • In Oracle AVDF release 20.7 and later, you can change the host name of the primary and standby Audit Vault Servers by using the primary Audit Vault Server console.

    • IP Address: If you need to update the IP address of the Audit Vault Server that was set during the installation, enter the new IP address.

      The IP address is static and must be obtained from the network administrator. The specified IP address may need to be added to routing tables to enable traffic to go between the Audit Vault Server and Database Firewalls.

      Note:

      If you have a high availability configuration, then you need to unpair the primary and standby Audit Vault Servers before changing the IP address, network mask, and gateway. After you update the network settings on the primary or standby Audit Vault Server, pair the two servers again. After you complete the pairing process, redeploy the Audit Vault Agents to ensure that they are updated with the new settings for the primary and standby Audit Vault Servers.
    • Network Mask: Enter the subnet mask of the Audit Vault Server.
    • Gateway: Enter the IP address of the default gateway (for example, to access the management interface from another subnet). The default gateway must be on the same subnet as the Audit Vault Server.
    • Link properties: Don't change the default setting unless your network has been configured to not use autonegotiation.
  6. Click Save.
  7. Complete the following post-configuration steps:
    1. If the audit trails are not configured to start automatically, start them manually. See Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server.
    2. Reconfigure the resilient pair of Database Firewalls if you previously configured them. See Configuring High Availability for Database Firewalls.
    3. If you changed the IP address of the Audit Vault Server, update the IP address information in the Database Firewall configuration. See Specifying the Audit Vault Server Certificate and IP Address.
    4. If you changed the IP address of the Audit Vault Server, redeploy the Audit Vault Agents. See Deploying the Audit Vault Agent.
4.3.3.2 Changing the Standby Audit Vault Server Network Configuration

Learn how to change the standby Audit Vault Server network configuration.

Starting with Oracle AVDF release 20.7, the network settings of the standby Audit Vault Server can be configured using the primary Audit Vault Server console.

To configure the standby Audit Vault Server network settings:

  1. Log in to the primary Audit Vault Server console as a super administrator.
  2. Click Settings tab.
  3. Click System tab in the left navigation menu.
  4. Under the Configuration sub tab in the main page, click Network Settings.
  5. In the Network Settings dialog, the Settings sub tab is selected by default. Click Standby Server radio button.
  6. Edit the Host Name. The host name must be a fully qualified domain name of Audit Vault Server. The host name can contain maximum of 64 characters, and cannot contain spaces. The host name of the standby Audit Vault Server cannot be the same as the primary.
  7. Click Save.

    The following confirmation dialog is displayed:

    This operation reconfigures the standby Audit Vault Server. This process takes at least 10 minutes. Do you want to continue?

  8. Click OK.

    Note:

    During this time, the standby Audit Vault Server is unavailable for a minimum of 10 minutes. An error message is displayed in the Network Settings and System Settings dialog on the Audit Vault Server console for failing to reach the standby Audit Vault Server.

    See Also:

4.3.3.3 Configuring or Changing the Audit Vault Server Services

Learn how to configure and change the Audit Vault Server sevices.

To configure the Audit Vault Server services:

  1. Log in to the Audit Vault Server console as a super administrator.
  2. Click Settings tab.
  3. Click System tab in the left navigation menu.
  4. In the Configuration section on the main page:
  5. Under the DNS tab, turn on the button and enter the IP address in the specific fields. Enter the IP addresses of up to three DNS servers on the network. Audit Vault Server uses these IP addresses to resolve host names. Keep the fields disabled if you do not use DNS servers. Enabling these fields could degrade system performance if you use DNS servers.

    Note:

    The Client Host (host name of the client) value is displayed in the reports only if the DNS is configured here.
  6. In the dialog, click Web/SSH/SNMP tab.
  7. Complete the following fields as necessary:

    Caution:

    When allowing access to Oracle Audit Vault and Database Firewall you must be careful to take proper precautions to maintain security.

    • Web Access: If you want to allow only selected computers to access the Audit Vault Server console, select IP Addresses and enter specific IP addresses in the box, separated by spaces. Using the default value All allows access from any computer in your site.
    • SSH Access: You can specify a list of IP addresses that are allowed to access the Audit Vault Server through SSH, from a remote console by selecting IP Addresses and entering them in this field, separated by spaces. Using the value All allows access from any computer in your site. Using the value Disabled prevents SSH access from any computer.
    • SNMP Access: You can specify a list of IP addresses that are allowed to access the network configuration of Audit Vault Server through SNMP by selecting IP Addresses. Then enter them in this field, separated by spaces. Selecting All allows access from any computer. If you disable this, it prevents SNMP access. The SNMP community string is gT8@fq+E.
  8. Click Save. A message is displayed.
  9. Click OK in the confirmation dialog.

    See Also:

    Protecting Your Data for a list of recommendations and precautions to maintain security

4.3.3.4 Changing the Standby Audit Vault Server System Settings

Learn how to change the system settings for the standby Audit Vault Server.

Starting with Oracle AVDF release 20.7, the system settings of the standby Audit Vault Server can be changed using the primary Audit Vault Server console.

To configure the standby Audit Vault Server system settings:

  1. Log in to the primary Audit Vault Server console as a super administrator.
  2. Click Settings tab.
  3. Click System tab in the left navigation menu.
  4. Under the Configuration sub tab in the main page, click System Settings.
  5. In the System Settings dialog, the DNS sub tab is selected by default. Click Standby Server radio button.
  6. Enter the IP address in the specific fields. Enter the IP addresses of up to three DNS servers on the network. Audit Vault Server uses these IP addresses to resolve host names. Keep the fields disabled if you do not use DNS servers. Enabling these fields could degrade system performance if you use DNS servers.
  7. In the System Settings dialog, click on the Web/SSH/SNMP tab.
  8. Click Standby Server radio button.
  9. Complete the Web/SSH/SNMP fields as necessary. The requirements are similar to the primary Audit Vault Server as mentioned in the previous topic.
  10. Click Save.

    The following confirmation dialog is displayed:

    This operation reconfigures the standby Audit Vault Server. This process takes at least 2 minutes. Do you want to continue?

  11. Click OK.

    See Also:

    Protecting Your Data for a list of recommendations and precautions to maintain security

4.3.3.5 Changing IP Addresses of Active and Registered Agents

Learn about changing the IP addresses of active and registered Agents.

Use this procedure to change the IP address of a live registered Agents without affecting the functionality of the Audit Vault Agent.

Prerequisites

  1. Stop all audit trails managed by the specific Audit Vault Agent. See section Stopping, Starting, and Autostart of Audit Trails in Oracle Audit Vault Server for more information.

  2. Stop Audit Vault Agent before changing the IP address of the target server. See section Stopping, Starting, and Other Agent Operations for more information to stop the Audit Vault Agent.

To change the IP address of a live registered Agent

  1. Change the IP address of the machine on which agent is installed.
  2. Change the IP address of the previously registered Agent entity of Oracle Audit Vault and Database Firewall using the Audit Vault Server console or Audit Vault command-line interface.
  3. Run the following to start the Audit Vault Agent with the -k option:
    agentctl start -k
  4. Enter an Activation Key.
  5. Start Audit Trails.

See Also:

Changing the IP Address on a Single Instance of the Database Firewall Server

4.3.3.6 Updating the Audit Vault Server IP Address in the NTP Configuration File

After updating the Audit Vault Server IP address, if you're using Network Time Protocol (NTP), you need to update the /etc/ntp.conf file.

Prerequisite

Update the Audit Vault Server IP address. See Changing the Primary Audit Vault Server Network Configuration.

Procedure

  1. Log into the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. Click the System in the left navigation menu.
  4. Under Configuration, click System Settings (Manage in Oracle AVDF 20.2 and earlier).
  5. For Oracle AVDF 20.3 and later, click the Time & Keyboard tab in the System Settings dialog box.

  6. Select Set Manually.

    This updates /etc/ntp.conf.

  7. Check the /etc/ntp.conf file to verify that the IP address has changed.

  8. In the System Settings dialog box, select Use NTP and enter the NTP server IP addresses or names.

    For details on the field values, see Specifying the Server Date, Time, and Keyboard Settings.

  9. Click Save.

4.3.4 Configuring Audit Vault Server Syslog Destinations

Learn how to configure Audit Vault Server syslog destinations.

Use the following procedure to configure the types of syslog messages to send from Audit Vault Server. The message categories are Debug, Info, or System. You can also forward Alert messages to the syslog.

Configuring Syslog enables integration with popular SIEM vendors such as Splunk, IBM QRadar, LogRhythm, ArcSight and others.

Note:

Syslog message is sent to the destination machine. The message is not written to the Audit Vault Server /var/log/message file.

Prerequisites

  • Log in to the Audit Vault Server console as a super administrator. See Using Audit Vault Server Console for more information.

  • Ensure that the IP addresses provided for syslog destinations are on a different host than the Audit Vault Server.

  1. Click the Settings tab.
  2. Click on System tab in the left navigation menu.
  3. Under the Configuration section, click Connectors.
  4. In the Connectors dialog, click on Syslog tab.
  5. Complete the fields, as necessary:

    • Syslog Destinations (UDP): Use this box if you are using User Datagram Protocol (UDP) to communicate syslog messages from Audit Vault Server. Enter the IP address of each machine that is permitted to receive the syslog messages, separated by spaces.

    • Syslog Destinations (TCP): Use this box if you are using Transmission Control Protocol (TCP) to communicate syslog messages from Audit Vault Server. Enter the IP address and port combinations of each server that is permitted to receive the syslog messages, separated by spaces.

    • Syslog Categories: You can select the types of messages to be sent to Syslog as follows:

      • Alert: Alerts based on alert conditions that an Oracle Audit Vault and Database Firewall auditor specifies.

        To forward Oracle Audit Vault and Database Firewall alerts to syslog. In addition to this setting, the Oracle Audit Vault and Database Firewall auditor must configure alert forwarding.

      • Debug: Engineering debug messages (for Oracle support use only).

      • Info: General Oracle Audit Vault and Database Firewall messages and property changes.

      • System: System messages generated by Oracle Audit Vault and Database Firewall or other software that has a syslog priority level of at least INFO.

  6. Click Save.
  7. Repeat the initial system settings and options set on the second Audit Vault Server, in case of high availability.

    See Also:

4.3.5 Configuring Custom Ports on Network Interfaces

Learn how to configure custom ports on network interfaces in standalone and high availability environment.

Oracle Audit Vault and Database Firewall requires TCP and TCPS based external SQL access. By default, the TCP and TCPS ports are 1521 and 1522 respectively. Oracle Audit Vault and Database Firewall supports the configuration of more than one set of custom ports. User-defined ports are also used for SQL connections. As a super administrator user you can specify a custom TCP and TCPS port for SQL communication on Oracle Audit Vault Server. Custom ports can be configured for network interfaces in standalone and high availability environment. Upon configuring a custom port, SQL communication is enabled and added to the network configuration.

Follow these instructions while performing backup and restore operations. If you configured a custom port before performing the backup operation, then the port should remain as you configured it during the restore operation.

To configure custom ports on a primary network interface:

Note:

The commands in the procedure below must be executed only on the primary Audit Vault Server in a high availability environment.
  1. Log in to the appliance as root user.
  2. Switch user to oracle.
  3. Use SQL*Plus and connect as super admin user by entering the ID and password as follows.
    <super-admin>/<password>

    Note:

    • Other users cannot configure custom ports. If this operation is attempted by another user, then a message is displayed on the SQL*Plus that there are insufficient privileges for the user.
    • Only root users can access error or debug logs.
  4. To configure custom ports and related operations, run the following commands:
    Operation Command
    To configure custom TCP and TCPS ports on the Audit Vault Server. 
    exec management.server.custom_listener_ports(<tcp_custom_port>, <tcps_custom_port>);
    To disable default ports (1521, 1522) on the Audit Vault Server. 
    exec management.server.disable_std_listener_port_access;

    After disabling the default listener ports:

    • The ports will not be disabled at the listener level.
    • Listener will listen on the custom ports in addition to the default ports. However, the default ports will only be accessbile from the local AVDF server and will be blocked for access from any remote clients.
    • The AVDF database will only be accessible through the new custom ports from any remote clients.

    Upon configuring a new custom port, ensure all the Audit Vault Agents are updated with the new port. After all the Agents are updated, ensure the trails continue to run after the Agents are updated with the new custom ports. The standard ports must be disabled after this verification. If standard ports are disabled before the Agents are updated, then those Agents stop running and need to be manually updated. This can be done by updating the connect string in the av/conf/bootstrap.prop file of the Agent home directory.

    Tip:

    In a high availability environment:
    • The same ports are configured on the standby Audit Vault Server
    • The TCPS port configured on the standby is same as primary server during pairing. Else, pairing results in an error.
  5. To disable custom ports, run the following commands:
    Operation Command
    To rollback custom ports and restore ports 1521 and 1522 as the default ports exec management.server.enable_std_listener_port_access

    After the standard ports are enabled again, do not disable the custom ports in immediate succession as this may disrupt the communication between the Audit Vault Agent and the Audit Vault Server. In such an event, the Audit Vault Agents have to be reinstalled. Before disabling the custom port and changing back to default ports, ensure the Audit Vault Agents are updated and are in RUNNING state.

    To disable custom ports exec management.server.disable_custom_listener_port_access

4.4 Configuring the Email Notification Service

Learn about configuring the email notification service.

4.4.1 About Email Notifications in Oracle Audit Vault and Database Firewall

Learn about Oracle Audit Vault and Database Firewall email notifications.

An auditor can configure Oracle Audit Vault and Database Firewall to send users email notifications when alerts or reports are generated. To do this, you must configure an SMTP server to enable email notifications. The email notifications can be sent in text format to mobile devices or they can be routed through an SMS gateway.

Note:

  • You can configure one SMTP (or ESMTP) server for Oracle Audit Vault and Database Firewall.
  • You can configure Oracle Audit Vault and Database Firewall to work with both unsecured SMTP servers as well as with secured and authenticated SMTP servers.

See Also:

Oracle Audit Vault and Database Firewall Auditor's Guide for information about configuring alerts and generating reports.

4.4.2 Configuring Email Notifications

To configure email notifications, you need to configure an SMTP server.

  1. Log in to the Audit Vault Server console as a super administrator.

    See Using Audit Vault Server Console for more information.

  2. Click the Settings tab.
  3. Click System in the left navigation menu.
  4. Under Configuration, click Connectors.
  5. In the Connectors dialog box, enter the IP address of the SMTP server in SMTP Server Address.
  6. In the SMTP Port field, enter the SMTP server port.
  7. In the From Name field, enter the user name to be used as the sender of the email.
  8. In the From Address field, enter the sender's address that appears in the email notifications.
  9. If this SMTP server requires credentials, then select Require Credentials, and enter a user name and password.
  10. If this SMTP server requires authentication, then select Require Secure Connection, and select the authentication protocol (SSL or TLS).
  11. Click Register to register the SMTP server.
  12. (Optional) Enter the email address and click Test to test the email configuration.
  13. Click Save.

4.5 Configuring Archive Locations and Retention Policies

Learn about configuring archive locations and retention policies.

Note:

Remember the following rules while archiving and restoring tablespaces:

  • The restore policy must follow the guidelines in this section.

  • Check the tablespace that needs to be archived and the corresponding tablespace that needs to be purged as explained in the policy.

  • Restoring data into empty tablespaces is not possible. Check accordingly.

  • In case the tablespace enters the delete period, it is deleted automatically from Oracle Audit Vault Server.

  • Every tablespace is uniquely identified using the name of the month that it moves offline and the month that it is purged. The tablespaces are created automatically based on the policies that you create.

  • When the retention policy changes, the new policy is applied to the incoming data in the following month. It does not affect the existing tablespaces which adhere to the old policy.

  • You can archive the tablespace when it enters the offline period.

  • After restoring the tablespace, it is actually online. After you release the tablespace, it goes offline. You must rearchive the tablespace after it is released.

4.5.1 About Archiving and Retrieving Data in Oracle Audit Vault and Database Firewall

Learn about archiving and retrieving data in Oracle Audit Vault and Database Firewall.

Data files are archived as part of an information lifecycle strategy. Oracle Audit Vault and Database Firewall release 20.1.0.0.0 supports automatic archival of a job only for NFS configured locations. When the online period of the data on the tablespace expires, it is automatically archived without your intervention. You have a choice to enable automatic archival during a fresh installation of Oracle Audit Vault and Database Firewall in release 20.1.0.0.0. Or, you can manually archive jobs with the desired settings.

When you upgrade to Oracle Audit Vault and Database Firewall release 20.1.0.0.0 from an older release, the system continues to use manual archiving. You have to enable automatic archiving of jobs post upgrade.

You can switch between automatic and manual job archiving. If there is a job in progress during the switch over, then the change occurs after the active job is completed. A suitable message is displayed to the user. After you switch to automatic archiving, all of the existing NFS locations are configured into an automatic archiving list. They are listed under Manage Archive Locations. If the space in archive location is full or inaccessible, then automatic archiving chooses the next archive location from the list. The automatic archival functionality runs on a daily basis and archives the data that is available for archiving.

Note:

After you enable automatic archiving, manual archiving is disabled. When upgrading to a newer version in release 20.1.0.0.0, the system continues to use either the automatic or the manual archiving that you configured prior to the upgrade.

You create retention policies and archive locations so that the archived data is transferred in accordance with your policies. Oracle recommends that you archive regularly in accordance with your company's policy.

Automatic archival is supported only on Network File Systems (NFS). Oracle recommends that you use NFS to transfer data to an archive location. If you use Secure Copy (SCP) or Windows File Sharing (SMB) to transfer data to an archive location, then your data files are first copied to a staging area in Oracle Audit Vault Server. Therefore, you must ensure that there is sufficient space in your file system. Otherwise, the data file copying may fail. Transferring large files using SCP or SMB may take a long time.

What Is a Retention Policy?

Retention policies (also called archive policies) determine how long data is retained in Oracle Audit Vault Server, when data is available for archiving, and for how long archived data can be retrieved to Oracle Audit Vault Server. An administrator creates these policies and an auditor assigns a specific policy to each target as well as to scheduled reports. The settings that you can specify in a policy are as follows:

  • Months Online: The audit data is available in Oracle Audit Vault Server for the number of months online that you specify. During this period, data is available for viewing in reports. When this period elapses, the audit data files are available for archiving, and are no longer visible for reports. When the administrator archives these data files, the data is physically removed from Oracle Audit Vault Server.

  • Months Archived: The archived audit data can be retrieved to Oracle Audit Vault Server for the number of months specified in Months Archived. If you retrieve the data during this period, then it will be available again in reports. When the months archived period expires, the data can no longer be retrieved to Oracle Audit Vault Server.

Note:

Retention times are based on the event time (time it is generated). If the auditor does not select a retention policy for a target or scheduled report, Audit Vault Server uses the default retention policy (12 months for online retention, and 12 months in archives).

Example

Suppose your retention policy is:

  • Months Online: 2

  • Months Archived: 4

With this retention policy, audit data that is generated during the last two months is available in Audit Vault Server. Data that is older than two months is available for archiving, and is no longer visible in reports. Archived data is available to retrieve for four months. This data is older than two months but newer than six months, and can be retrieved from the archives to Oracle Audit Vault Server. Data that is older than six months is no longer available.

Updating Retention Policies Assigned to Targets

Changing the retention policy will not apply to already collected data. It will be applied to new data and in some cases can take a month for it to be applied. The cases where it takes a month is because of the optimization we have to pre-create underlying data partitions.

For example, if it is currently April and the current policy is six months online and six months in archive and then the policy is modified to be 12 months online and 12 months in archive on April 28th, the data collected in May will use the original six months online and six months in archive policy. However, starting in June the data collected will have the new 12 months online and 12 months in archive retention policy.

When new Data Collected is Older than Retention Policy Limits

When you collect audit data for a newly configured target, or from a new audit trail on an existing target, the data collected from that target may be older than the Months Online period. In fact, the data may be even be older than the Months Archived period.

For instance, suppose your retention policy is the same as the above Example. Now suppose you begin collecting audit data from a newly configured target. If some of this data is over six months old, it is older than the months online period and the months archived period combined. In this case, Oracle Audit Vault and Database Firewall automatically drops any newly collected audit records that are older than six months.

However, if some of this audit data is older than two months but newer than six months, that is, it falls within the months archived period, then Oracle Audit Vault and Database Firewall does one of the following:

  • If this is an audit trail for a newly configured target, then Oracle Audit Vault and Database Firewall automatically archives that data as the audit trail is collected.

  • If this is a new audit trail for an existing target, then Oracle Audit Vault and Database Firewall attempts to archive these records automatically as the audit trail is collected. However, you may have to make required data files available during this process.

Note:

In case the archive location is not defined, once the months online period expires and before the completion of offline period, the audit data for the specific target is moved offline. The data remains on the Audit Vault Server and can be retrieved and viewed in the Reports section of the Audit Vault Server console. This is applicable for the default and user defined archival and retention policy.

See Also:

Handling New Audit Trails with Expired Audit Records for information to make required data files available

4.5.2 Defining Archive Locations

You need to define one or more locations as destinations for archive files before you can start an archive job. An archiving destination specifies the archive storage locations and other settings.

Oracle recommends that you use NFS to transfer data to an archive location. If you use Secure Copy (SCP) or Windows File Sharing (SMB) to transfer data to an archive location, then your data files are first copied to a staging area in the Audit Vault Server. Therefore, you must ensure that there is sufficient space in the file system. Otherwise the data file copying may fail. Transferring large files using SCP or SMB may take a long time.

Note:

The backup functionality does not back up archived files. The data files in the archive location are not backed up by avbackup because they may be located on a remote file system. In case those files are on NFS mount point, then they are accessible after restoring on a new system with the same mount points that were previously configured.
  1. Log in to the Audit Vault Server as an administrator.

    See Using Audit Vault Server Console for more information.

  2. Click the Settings tab.
  3. Click Archiving in the left navigation menu.
  4. Click Manage Archive Locations.
  5. Click the Create button, and complete the fields. See the following field descriptions for more information.
  6. Click Save.
  1. Log in to the Audit Vault Server as an administrator.

    See Using Audit Vault Server Console for more information.

  2. Click the Data Retention tab.
  3. Click the Remote Archiving tab in the left navigation.
  4. Click the Create button, and complete the fields. See the following field descriptions for more information.
  5. Click Save.
Field Value
Transfer Method

Select the method to transfer data from Oracle Audit Vault Server to the machine that archives the data:

  • Secure Copy (SCP): Select if the data is archived by a Linux machine.

  • Windows File Sharing (SMB): Select if the data is archived by a Windows machine.

  • Network File System (NFS): Select if you're using a network file share or NAS.

If you do not select a transfer method, then the archive files will be retained in Event Data in the Audit Vault Server.
Location Name Enter the name of the archiving destination. This name appears as the archiving destination when you start an archive.
Remote Filesystem

If you use the NFS transfer method, then you can select an existing file system, or one will be created automatically based on the details of this archive location.

Note:

In a standalone system, you can use the AVCLI utility to register a remote file system. Then you can select this file system in the Audit Vault Server console. This is not possible in a high availability environment. In a high availability environment, you create the archive locations through the Audit Vault Server console by selecting the Create New Filesystem option.

See Downloading and Using the AVCLI Command Line Interface for details about using the AVCLI utility.

Address Enter the host name or IP address of the NFS server that the Audit Vault Server uses for archiving. If you use the Windows File Sharing transfer method, then specify the IP address.
Export Directory

If you use the NFS transfer method, then enter the export directory of the NFS server. For example, you can create this directory in the /etc/exports file of the NFS server. Ensure that the oracle user (User ID: 503) has appropriate read and write permissions to this directory.

Note:

Special characters (such as $, #, and !) are not allowed in export directory names.
Path Enter the path to the archive storage location. Enter a path to a directory (not a file) and follow these requirements for each transfer method:
  • Secure Copy (scp): If there is no leading slash character, the path is relative to the user's home directory. If there is a leading slash, the path is relative to the root directory.
  • Windows File Sharing (SMB): Enter the share name, followed by a forward slash and the name of the folder. For example: /sharename/myfolder.

  • Network File System (NFS): Enter the path relative to the export directory. For example, if the export directory is /export_dir and the full path to the directory that you want to designate as an archive location is /export_dir/dir1/dir2, then enter /dir1/dir2 in the Path field. To put archives directly in the NFS server's export directory, enter / (forward slash) for the path.

    Click the Test button to validate the NFS location.

Port

This is the port number that secure copy (scp) uses or the Windows file share service on the machine that archives the data. You can normally use the default port number.

If you selected Windows file sharing (SMB) as the transfer method, then use port 445.
Username Enter the account name on the machine to which the archive data will be transferred.
Authentication Method

If you use secure copy (scp) as the transfer method, then you can select Password Authentication and enter the login password.

If you use a Linux machine, then you can select Key-based Authentication. If you use key-based authentication, then the administrator of the remote machine must ensure that the file that contains the RSA key (~/.ssh/authorized_keys) has permissions set to 664.

Password and Confirm Password If you use Windows file sharing (SMB), or if you selected the password authentication method, then enter the login password for the machine that archives the data.
Public Key This field appears if you selected key-based authentication. Copy this public key and add it to the public keys file on the machine that archives the data. For example, add the key in ~/.ssh/authorized_keys.

Related Topics

4.5.3 Creating and Deleting Archive and Retention Policies

Learn about creating and deleting policies.

4.5.3.1 Creating Archive and Retention Policies

You can create retention policies (also called archive policies) that an Oracle Audit Vault and Database Firewall (Oracle AVDF) auditor can apply to targets.

  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. Click Archiving in the left navigation menu.
  4. Click Manage Policies.
  5. Click Create.
  6. Enter a name for the policy.
  7. In the Months Online field, enter the number of months to retain audit data on the Oracle Audit Vault Server before the data is marked for archiving.
  8. In the Months Archived field, enter the number of months to retain audit data in the archive location. After this time the data will be purged.
  9. Optional - Starting with Oracle AVDF Release 20.7, if you're signed in as a super administrator you can set the policy as the default by selecting Set as default.
  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Data Retention tab.
  3. Click Retention Policies in the left navigation menu.
  4. Click Create.
  5. Enter a name for the policy.
  6. In the Months Online field, enter the number of months to retain audit data on the Oracle Audit Vault Server before the data is marked for archiving.
  7. In the Months Archived field, enter the number of months to retain audit data in the archive location. After this time the data will be purged. The default value is 6.
  8. Optional - If you're signed in as a super administrator you can set the policy as the default by selecting Set as default.
  9. Click Save.

Months Online

When a target uses an assigned retention policy, the audit data will be available online in the Audit Vault Server for the specified amount of months before moving to the archive location.

Note:

After the months online period expires, the data is no longer visible in reports. Data is removed from the online view and is available in the archive location. You can't delete the online data manually.

Months Archived

When a target uses an assigned retention policy, the audit data will be available in the archive location for the specified amount of months before being purged. While it is in the archive location it is available to be retrieved back online to the Audit Vault Server.

Note:

See Setting a Data Retention (Archiving) Policy for instructions on assigning retention policies.

4.5.3.2 Deleting Archive and Retention Policies

You can delete user-defined retention policies (also called archive policies) that are not assigned to any target databases.

  1. Log in to the Oracle Audit Vault Server console as an administrator.
  2. Click the Settings tab.
  3. Click Archiving in the left navigation menu.
  4. Click Manage Policies.
  5. Under User-defined Policy, select the policy to delete.
  6. Click Delete.
  1. Log in to the Audit Vault Server console as an administrator.
  2. Click the Data Retention tab.
  3. Click Retention Policies in the left navigation menu.
  4. Select a minimum of one user-defined retention policies from the list.
  5. Click Delete.
  6. Click Ok in the dialog box to confirm deletion of the selected policies.

4.5.4 Viewing Archived Datafiles

Learn how to view archived datafiles.

  1. Log in to the Audit Vault Server console as administrator.
  2. Click the Settings tab.
  3. Click the Archiving tab in the left navigation menu.

    This page lists the archived datafiles with the following details:

    Note:

    • A super administrator can view datafiles pertaining to all targets. An administrator can view datafiles only for the targets they have access to.
    • This functionality of viewing the archived datafiles is available starting with Oracle AVDF release 20.6.

4.5.5 Running Archive and Retrieval Jobs

Learn how to run archive and retrieval jobs.

See "Archiving and Retrieving Audit Data".

4.6 Managing Archival and Retrieval in High Availability Environments

Learn how to manage archival and retrieval in high availability environments.

Oracle Audit Vault and Database Firewall supports archiving. Prior to release 12.2.0.11.0, archiving was configured only on the primary Audit Vault Server and there was no ability to configure archiving on the standby server. After a failover, archive locations had to be manually set on the former standby (new primary). Starting with release 12.2.0.11.0, you can now configure NFS archive locations on both the primary and standby Audit Vault Servers, reducing the amount of manual work that needs to be performed following a failover.

Oracle Audit Vault and Database Firewall release 12.2.0.11.0 and later ensures that the primary and secondary Audit Vault Servers have the same number of NFS archive locations. This is crucial for archiving and file management functionality to work effectively in a high availability environment.

Note:

  • Any user with admin privileges can perform archival and retrieval tasks.
  • It is recommended that NFS archive locations for primary and secondary Audit Vault Servers are on separate NFS servers.
  • It is recommended to have these NFS servers within the same Data Center as the Audit Vault Server. As in the NFS server for primary Audit Vault Server should be in the same data center and NFS server for secondary Audit Vault Server should be in the same data center.
  • NFS is a mount point on the Audit Vault Server. If you want to replace NFS server, then make sure the Audit Vault Server does not access the mount point.

Prerequisite

Ensure that all of the Prerequisites for Configuring High Availability for Audit Vault Servers are satisfied before configuring high availability.

After you complete the high availability pairing, the NFS locations pertaining to both the primary and secondary Audit Vault Servers are displayed under Manage Archive Locations of the primary Audit Vault Server console. These NFS locations include those created on both the primary and secondary Audit Vault Servers before and after configuring high availability. The names of these NFS locations have the primary location name or the name defined while creating the location once high availability is configured. The Audit Vault Server console provides details of the host, export directory, and destination path for both the primary and secondary Audit Vault Servers.

Note:

Oracle Audit Vault and Database Firewall release 20.1.0.0.0 supports automatic archival on both primary and secondary Audit Vault Servers. If automatic archival is enabled on the primary Audit Vault Server, it is enabled on the corresponding secondary Audit Vault Server as well. The Audit Vault Server console displays the archive locations of the primary host with their mapped corresponding secondary locations.

Upgrade and archiving functionality in high availability environment

Archiving functionality is disabled during the upgrade process only when there are datafiles archived to the NFS locations. Upon completion of the upgrade process the admin user must enable the archive functionality to start archiving.

Updating or Deleting NFS locations

The super admin can update or delete the NFS locations after high availability pairing of primary and secondary Audit Vault Servers. The NFS locations on both the primary and secondary Audit Vault Servers can be updated or deleted. In case the datafiles are archived, the location cannot be updated or deleted. The Location Name and the Primary Server Path or the Secondary Server Path can be updated in case high availability is enabled. However, the NFS mount point is internal and cannot be changed.

See Also:

4.7 Defining Resilient Pairs for High Availability

Learn how to define resilient pairs for high availability.

You can define resilient pairs of Oracle Audit Vault Servers, Oracle Database Firewalls, or both.

When you define a resilient pair of Oracle Audit Vault Servers, you must perform all of the configuration tasks. These tasks include adding database firewalls to the server and registering the targets on the primary Oracle Audit Vault Server.

See Also:

High Availability in Oracle AVDF

4.8 Registering Database Firewall in Audit Vault Server

Use this procedure to register an Database Firewall with the Audit Vault Server.

Prerequisites

To register Database Firewall in Audit Vault Server:

  1. If there is a resilient pair of Audit Vault Servers, then log in to the primary server.
  2. Click the Database Firewalls tab.

    The Firewalls page displays the currently registered firewalls and their statuses.

  3. Click Register.
  4. Enter a Name for Database Firewall and its IP Address.
  5. Click Save.

    Note:

    • If a message indicates that there is a problem with the certificate, then ensure that the date and time settings are identical on both Database Firewall and Audit Vault Server.

    • If the following error message is encountered, then check the Audit Vault Server certificate is copied properly to the Database Firewall. Also check the date and time settings are identical on both the Database Firewall and Audit Vault Server.

      OAV-46981 Unable to connect to Database Firewall with IP

4.9 Testing Audit Vault Server System Operations

Learn about testing Audit Vault Server system operations.

Verify that your system is fully operational before beginning your normal, day-to-day operations.

Prerequisite

Log in to Audit Vault Server as an administrator. See Using Audit Vault Server Console for more information.

To test your system's operation:

  1. Check the date and time settings of Audit Vault Server.
  2. Click the Settings tab.
  3. Click on the System tab in the left navigation menu.
  4. Under Monitoring section in the main page, click Diagnostics.
  5. Click the Run Diagnostics button to run a series of diagnostic tests and review the results.

    These diagnostics include testing:

    • Existence and access permissions of configuration files

    • File system sanity

    • Network configuration

    • Status of various processes that are required to run on the system. For example, database server processes, event collection process, Java framework process, HTTP server process, and so on.

  6. You can use the Download Diagnostics button to download the diagnostic results for further analysis.
  7. You can use the Clear Diagnostic Logs button to clear the current set of diagnostic logs on the Audit Vault Server.
  8. Click the Home tab, and check the status of Database Firewalls and Targets.

4.10 Configuring Fiber Channel-Based Storage for Audit Vault Server

Learn about configuring fiber channel-based storage for Audit Vault Server.

Audit Vault Server supports fiber channel-based storage. You can configure this storage during installation by performing this procedure.

To configure fiber channel-based storage for Audit Vault Server:

  1. Install Audit Vault Server on the local disk of your server. During installation, Audit Vault Server attempts to use all of the disks in your system. Use the configuration tools for the fiber channel controller such as Fast!UTIL, to ensure that other disks are not accessible.

    Note:

    • If the other disks are accessible, then they are formatted and erased during installation.

    • Audit Vault Server looks for the devices with the names of sd*, xvd*, hd*, cciss*, fio* in /sys/block. The installation succeeds if the fiber channel disks are exposed as one of these block devices.

    • The device xvd* is not supported for multipath.

    • The first disk must be a local disk with a minimum of 300 GB available space. If the available space is less than 300 GB, then the boot partition is allocated to a SAN fiber channel disk which is not supported. It is recommended that the sizes of the other disks be greater than that of the first disk.

  2. If you are using fiber channel-based storage, then perform the following remaining steps after your installation has successfully completed to ensure that Oracle Automatic Storage Management uses the active path. Otherwise, reboot your system to complete the configuration process.

    Note:

    Fiber channel-based storage with multipath is supported by Oracle Audit Vault and Database Firewall release 20.1 and onwards.

4.11 Fiber Channel Based Multipath in Oracle AVDF

Learn about support for multipath in Oracle AVDF.

Oracle Audit Vault and Database Firewall 20.1 and later supports fiber channel based storage with multipath. The redundant paths in multipath can enhance performance and utilize features like dynamic load balancing, traffic shaping, automatic path management, and dynamic reconfiguration. The connection to the disk can be made through two fiber channel ports.

Here are some important aspects of multipath in Oracle AVDF:

  • It is not supported with ISCSI storage.
  • It does not support the device xvd*.
  • Multipath is supported only for Audit Vault Server installation.
  • Multipath is not supported for Database Firewall installation.
  • It does not support removable block devices. Check for removable block devices in the system as they can lead to installation failure.

Note:

In case there are removable block devices in the system, the following error may be encountered during Audit Vault Server installation:

ERROR: Failed to check if the disk is in multipath
Traceback (most recent call last):
  File "/run/install/repo/partitions.py", line 386, in <module>
    main()
  File "/run/install/repo/partitions.py", line 372, in main
    write_partition_table( None )
  File "/run/install/repo/partitions.py", line 322, in write_partition_table
    part_table = generate_partition_table_data(dev_list)
  File "/run/install/repo/partitions.py", line 243, in generate_partition_table_data
    raise RuntimeError("No disks detected")
RuntimeError: No disks detected

4.12 Adding Network Address Translation IP Addresses to Audit Vault Agent

You can add Network Address Translation (NAT) IP addresses to Audit Vault Agent.

Network Address Translation (NAT) is a method of remapping one IP address space into another. This is done by modifying network address information in the IP header of packets when they are in transit across traffic routing devices. Use this procedure to manually add the NAT IP address of the Audit Vault Server to the Audit Vault Agent.

In some deployments, Audit Vault Servers are within NAT networks. The Agents are deployed in a network outside of the NAT configured network with actual IP addresses of Audit Vault Server. In such cases, the Agents cannot reach Audit Vault Server.

In this case, you can add the NAT IP address and port mapping information to the dbfw.conf file of Audit Vault Server. This ensures adding an extra connection string in the Agent's bootstrap.prop file so that Agents can be deployed in both NAT and non NAT networks. This functionality is available from Oracle AVDF 12.2.0.8.0 and later.

Use Cases

Case Configuration Type Description

Case 1

Audit Vault Server configuration without high availability.

  • There is only one Audit Vault Server. This server is behind NAT.

  • Agents in this set up can either connect to Audit Vault Server directly without NAT, or connect to the Audit Vault Server through NAT.

  • Agents connecting to Audit Vault Server directly, use IP address and port of Audit Vault Server.

  • Agents connecting to Audit Vault Server through NAT use the IP address and port of Audit Vault Server.

Case 2

Audit Vault Server configuration with high availability.

  • Both the primary and secondary Audit Vault Servers are behind the same NAT. The primary NAT IP address and secondary NAT IP address is the same. The primary NAT port and secondary NAT port are different.

  • Agents in this set up can either connect to Audit Vault Server directly without NAT, or through NAT.

  • Agents connecting to Audit Vault Server directly use the IP address and port of Audit Vault Server. In case of a failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

  • Agents connecting to Audit Vault Server through NAT use the IP address and port of the primary Audit Vault Server. In case of failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

Case 3

Primary and secondary Audit Vault Servers with different NAT IP addresses.

  • Both the primary and secondary Audit Vault Servers are behind two different NAT IP addresses. The primary NAT IP address and secondary NAT IP address are different. The primary NAT port and secondary NAT port can be the same or different.

  • Agents in this setup can either connect to Audit Vault Server directly without NAT or through NAT.

  • Agents connecting to Audit Vault Server directly use the IP address and port of the Audit Vault Server. In case of failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

  • Agents connecting to the Audit Vault Server through NAT use the IP address and port of the primary Audit Vault Server. In case of failover of the primary Audit Vault Server, the Agents continue to connect to the secondary Audit Vault Server using the IP address and port of the secondary Audit Vault Server.

To add the NAT IP address of Audit Vault Server into Audit Vault Agent, follow these steps:

  1. Log in to the Audit Vault Command Line Interface (AVCLI) as the admin or oracle user.
  2. Take a backup of the configuration file before proceeding:
    cp /usr/local/dbfw/etc/dbfw.conf /usr/local/dbfw/etc/dbfw.conf.backup
  3. Edit the dbfw.conf file to include the NAT IP address in the Audit Vault Server as follows:
    NAT_PRIMARY_IP_ADDRESS=<xx.yyy.zzz.aaa>
NAT_PRIMARY_AGENT_PORT_TLS=<12345>
NAT_PRIMARY_AGENT_PORT=<12346>
  4. Save the changes.
  5. Regenerate the agent by running the following command:
    avca configure_bootstrap
    After this, all of the Agents downloaded contain one of the strings with the NAT IP address. To verify, check the contents of the bootstrap file at /var/lib/oracle/dbfw/av/conf/bootstrap.prop which should be as follows:
    SYS.CONNECT_STRING999=(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS=(PROTOCOL=TCP)(HOST=10.240.114.167)(PORT=13031))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)))
SYS.SSL_CONNECT_STRING999=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCPS)(HOST=10.240.114.167)(PORT=13032))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)(SERVER=DEDICATED))(SECURITY= (SSL_SERVER_CERT_DN="DC=com,CN=avserver,OU=db,O=oracle")))
  6. The above case is applicable in Case 1 that is mentioned in the table above. In Case 2 and Case 3, Audit Vault Server is in high availability mode. In these cases, you need to configure the dbfw.conf file with an additional set of parameters as follows:
    NAT_PRIMARY_IP_ADDRESS=<xx.yyy.zzz.aaa>
NAT_PRIMARY_AGENT_PORT_TLS=<12345>
NAT_PRIMARY_AGENT_PORT=<12346>
NAT_SECONDARY_IP_ADDRESS=<xx.yyy.zzz.ccc>
NAT_SECONDARY_AGENT_PORT_TLS=<56789>
NAT_SECONDARY_AGENT_PORT=<12678>
  7. Save the changes.
  8. After this, the Agent’s bootstrap.prop file is configured with a high availability connect string to include the above set of IP addresses and ports. To verify this, check the contents of the bootstrap file at /var/lib/oracle/dbfw/av/conf/bootstrap.prop which should be as follows:
    SYS.CONNECT_STRING999=(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=<NAT_PRIMARY_AGENT_PORT>)(PORT=<NAT_PRIMARY_AGENT_PORT>)))

(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)))(DESCRIPTION=(ENABLE=BROKEN)(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCP)(HOST=<NAT_SECONDARY_IP_ADDRESS>)(PORT=NAT_SECONDARY_AGENT_PORT>)))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB))))

SYS.SSL_CONNECT_STRING999=(DESCRIPTION_LIST=(LOAD_BALANCE=off)(FAILOVER=on)(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCPS)(HOST=<NAT_PRIMARY_IP_ADDRESS>)(PORT=<NAT_PRIMARY_AGENT_PORT_TLS>)))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)(SERVER=DEDICATED))(SECURITY= (SSL_SERVER_CERT_DN="DC=com,CN=avserver,OU=db,O=oracle")))(DESCRIPTION=(ADDRESS_LIST=(LOAD_BALANCE=on)(ADDRESS=(PROTOCOL=TCPS)(HOST=<NAT_SECONDARY_IP_ADDRESS>)(PORT=<NAT_SECONDARY_AGENT_PORT_TLS>)))(CONNECT_DATA=(SERVICE_NAME=DBFWDB.DBFWDB)(SERVER=DEDICATED))(SECURITY=(SSL_SERVER_CERT_DN="DC=com,CN=avserver,OU=db,O=oracle"))))