Enable the security auditing subsystem
Security auditing will not be performed unless the audit security subsystem has been enabled. Global security must be enabled for the security audit subsystem to function, as no security auditing occurs if global security is not also enabled.
Before enabling security auditing subsystem, enable global security in the environment.
The recording of auditable security events is achieved by enabled the security auditing subsystem. Follow these steps to enable the security auditing subsystem.
- Click Security > Security auditing.
- Select Enable security auditing. The Enable security auditing check box is not selected by default. This check box must be selected to allow security auditing to be performed with the configurations that have been specified in the audit.xml file.
The audit.xml file is used to store the audit subsystem configurations. Changes to the security auditing subsystem should be made with the user interface or the wsadmin utility. This file should not be edited manually.
- Select the action from the Audit subsystem failure action dropdown menu to be perform when an audit subsystem failure occurs. Notifications configured to warn of a security auditing subsystem failure will not be posted if the No Warning option is selected for this field. If we select either the Log warning or the Terminate server option, then you must also configure a notification for the action to be performed.
- Select the Auditor ID from the dropdown menu. The auditor role is needed to make changed to the security auditing configurations. By default, when auditing is first enabled, the primary administrator is also given the auditor role. The primary administrator can then add the auditor role to other users. After the auditor role is added to other users, the auditor role can be removed from the administrator to create a separation of authority between the auditor and the administrator. The Auditor ID is the user considered to be the primary auditor.
- Optional: Select Enable verbose auditing. When an auditable event is recorded, a default set of audit data is included in the audit data object and recorded to the repository. An additional set of audit data is made available by enabling verbose auditing.
- Click Apply.
- Restart the application server. The application server must be restarted before the changes go into effect.
Results
The successful competition of these steps results in the security auditing subsystem being enabled.
What to do next
After enabling the security auditing subsystem, refinements can be made to the configuration. We might want to modify the access control of the audit subsystem to separate the authority of the administrator from the authority of the auditor. If no changes to the access control are needed, then we can configure the types of auditable security events should be recorded. To configure the types of events that are recorded, click Event type filters.
Subtopics
- Security Auditing detail
The Security auditing subsystem can be enabled and configured from this panel, by users assigned the auditor role.
- Context object fields
Each auditable event has an associated set of information that is available for logging. This information is grouped into specific context objects. The context objects that are available for logging a specific event are specified by the event type. This topic details the information that exists for each context object and specifies whether the information is logged by default or is only logged when the verbose logging option is enabled.
Related tasks
Audit the security infrastructure Enable security auditing Configure security audit subsystem failure notifications