Change the Audit Log Resilience Levels

On a busy server, the audit log can grow quickly and, in some cases, can exceed the amount of space available for storing the audit data.

The ActivID AS might have sufficient data space available to continue its normal operations despite the failure of the audit log.

If the audit log has been overrun because of underestimating the space required for it, certain operations can continue working despite the fact that those calls will not be logged.

When the audit fails (for an authentication or administration operation), ActivID AS behavior depends on the configuration of the Resilience to Audit Log Failure properties (ALLOW_XXX_TO_PROCEED_WITHOUT_AUDIT_<DOMAIN>):

  • If the Resilience to Audit Log Failure is allowed:
  1. Write Audit log value to the following file:

    <ACTIVID_HOME>/ActivID_AS/servers/server_<n>/logs/activid-server-audit.log.<domain>

  1. Proceed as normal.

  • If the Resilience to Audit Log Failure is denied:
  1. Write Audit log value to the following file:

    <ACTIVID_HOME>/ActivID_AS/servers/server_<n>/logs/activid-server-audit.log.<domain>

  1. Prevent the operation.

If, during execution of the ActivID AS, the audit log begins to fail, use the following procedure to change the Resilience to Audit Log Failure (RALF) settings at runtime.

Note: You can configure this behavior separately for each security domain.

For each security domain configured on the ActivID AS instance, two properties can be added to the <ACTIVID_HOME>/ActivID_AS/applications/resources/common/activid.properties file (illustrated with DOMAIN1 as the security domain):

Note:
  • If the ALLOW_XXX properties are not defined, then the default value is DENY so both authentications and other configuration processes will fail if the audit log has failed.

  • As all operations require authentication, ALLOW_AUTHENTICATION must be set to ALLOW if you also set ALLOW_ADMINISTRATION to ALLOW.