This chapter provides information about managing Oracle Virtual Directory logging and auditing. It contains the following sections:
You can use Oracle Enterprise Manager Fusion Middleware Control and the Oracle WebLogic Scripting Tool (WLST) as the interface to manage Oracle Virtual Directory logging. This section includes the following sections on managing Oracle Virtual Directory logging:
Oracle Enterprise Manager Fusion Middleware Control enables you to list, search, and configure log files across Oracle Fusion Middleware components. You can view log files from Oracle Enterprise Manager Fusion Middleware Control or download log files and view them using another tool.
The Oracle Fusion Middleware Administrator's Guide for complete information on logging using Oracle Enterprise Manager Fusion Middleware Control.
The following items must supplement the information in the Oracle Fusion Middleware Administrator's Guide as they are specific to Oracle Virtual Directory logging:
When setting log levels for Oracle Virtual Directory using Oracle Enterprise Manager Fusion Middleware Control, the following log levels do not apply to and have no effect on Oracle Virtual Directory:
NOTIFICATION: 16 (CONFIG)
TRACE: 16 (FINER)
Log messages are written to the access.log file only when logging is set to NOTIFICATION:1 (INFO) level. You can increase the log level to ERROR:1 (SEVERE) or WARNING:1 (WARNING) to disable information from being written to the access.log file.
As a general guideline, Oracle recommends setting the log level for Oracle Virtual Directory to the least amount of information as possible for your environment.
List loggers and levels using
Get (view) the level for a logger using
Set the level for a logger using
List log handlers using
Configure log handlers using
Lists known logs using
Search and display the contents of logs using
For complete information about managing Oracle Virtual Directory logging using WLST, refer to the following documents:
To manage the granular message logging functionality described in this section, manually edit the appropriate XML files and then restart the Oracle Virtual Directory server.
You cannot manage granular message logging using Fusion Middleware Control or WebLogic Scripting Tool (WLST).
A default implementation of
java.util.logging.Filter StringMatchFilter is included in Oracle Virtual Directory. This default implementation supports the following two parameters:
StringToBeMatched: Enables you to specify one or more DIT/Strings.
AcceptOnMatch: This boolean enables you to include or exclude the log messages based on matching the list of DIT/Strings specified.
java.util.logging.Filter implementation and its parameters can be specified in the server.os_xml file. The following is an example
logFilter configuration for
StringMatchFilter class to exclude the log messages containing string
<logFilters> <filter className="com.octetstring.vde.util.StringMatchFilter"> <param name="StringToBeMatched" value="c=us" /> <param name="AcceptOnMatch" value="false" /> </filter> </logFilters>
To include the log messages, set
true and the log messages will contain the DIT specified in the
logFilter configuration. To exclude the log messages, set
false and the log messages will not contain the DIT specified. To enable
StringMatchFilter, configure it as a filter for either Logger or Handler defined in the
ovd-logging.xml file. The following is an example configuration to specify the filter for
<logging_configuration> <log_handlers> <log_handler name='OVDHandler' class='oracle.core.ojdl.logging.ODLHandlerFactory' filter='com.octetstring.vde.util.StringMatchFilter'> <property> ... </property> </log_handler> </log_handlers> <loggers> ... </loggers> <logging_configuration>
adapters.os_xml files are located in the following directory:
Oracle Virtual Directory utilizes the Common Audit Framework of the Oracle Application Server 11g infrastructure for compliance, monitoring, and analytics purposes. You can use Oracle Enterprise Manager Fusion Middleware Control and WLST as the interface to the Common Audit Framework to manage Oracle Virtual Directory auditing. This section contains the following sections on managing Oracle Virtual Directory auditing:
Audit data collection and storage
The auditing procedure for most Oracle Fusion Middleware components, including Oracle Virtual Directory, is similar and explained in detail in the Oracle Fusion Middleware Application Security Guide. The following is an overview of the procedure for auditing Oracle Virtual Directory using Oracle Enterprise Manager Fusion Middleware Control:
From the Oracle Virtual Directory menu, select Security, then Audit Policy Settings.
From the Audit Policy list, select Custom to configure your own filters, or one of the filter presets, None, Low, Medium, or High.
To audit only failures, click Select Failures Only.
To configure a filter, click the Edit icon next to its name. The Edit Filter dialog for the filter appears.
Specify the filter condition using the buttons, selections from the menus, and strings that you enter. Condition subjects include Initiator, Target, Remote IP, and Resource. Condition tests include -contains, -contains_case, -endswith, -endswith_case, -eq, -matches, -ne, -startswith, and -startswith_case. Enter values for the tests as strings. Parentheses are used for grouping and AND and OR for combining.
To add a condition, click the Add icon.
When you have completed the filter, click OK.
The Oracle Fusion Middleware Application Security Guide for complete information about auditing Oracle Virtual Directory using Oracle Enterprise Manager Fusion Middleware Control.
Getting (viewing) audit policy using
Setting audit policy using
Listing (viewing) audit events using
For complete information about managing Oracle Virtual Directory auditing using WLST, refer to the following documents:
For components that manage their audit policy locally, such as Oracle Virtual Directory, you must include an MBean name as an argument to the command. The name for an Audit MBean is of the form:
The Audit MBean in the preceding example should be one continuous string. It is shown on two lines in this document because of space/width limitations in this document.
You must ensure the MBean has the current server configuration before you make any changes to attributes. To do that, you must use the wlst
invoke() command to load the configuration from Oracle Virtual Directory server to the MBean. After making changes, you must use the
invoke() command to save the MBean configuration to the Oracle Virtual Directory server and then use the
invoke() command to load the updated configuration from Oracle Virtual Directory server to the MBean. This process ensures the Oracle Virtual Directory server and the MBean are synchronized. To use
invoke() in this way, you must navigate to the Root Proxy MBean in the tree. The name for a Root Proxy MBean is of the form:
Here is an example of a
wlst session using
java weblogic.WLST connect('username','password','t3://WEBLOGIC_HOST:WEBLOGIC_ADMIN_PORT') custom() cd('oracle.as.management.mbeans.register') cd('oracle.as.management.mbeans.register:type=component,name=ovd1,instance= instance1') invoke('load',jarray.array(,java.lang.Object),jarray.array(,java.lang.String) setAuditPolicy(filterPreset='None',addSpecialUsers="cn=user2,cn=users,dc=oracle,dc =com",removeSpecialUsers='cn=user1,cn=users,dc=oracle,dc=com',on='oracle.as.ovd:ty pe=component.auditconfig,name=auditconfig,instance=instance1,component=ovd1') custom() cd('oracle.as.management.mbeans.register') cd ('oracle.as.management.mbeans.register:type=component,name=ovd1,instance= instance1') invoke('save',jarray.array(,java.lang.Object),jarray.array(,java.lang.String) invoke('load',jarray.array(,java.lang.Object),jarray.array(,java.lang.String)
Oracle Virtual Directory audits and records configuration change-related events for the following components:
Proxy user DN and IP address where the operation was performed
Oracle Directory Services Manager 184.108.40.206.0 sends client IP address and user DN information to Oracle Virtual Directory 220.127.116.11.0 during all key operations so that these operations can be audited. The new APIs in this Oracle Directory Services Manager release only support the configuration and management of the Oracle Virtual Directory 18.104.22.168.0 release.
Operation name and type (add, delete, or modify)
Timestamp when event occurred
Affected configuration type (ACL, adapter, auditing, listener, logging, or server)
Old configuration versions (what was the version of the configuration before it changed)
Exact differences between old and new versions of a configuration
These configuration change-related events are audited in the WebService API layer and then recorded in the audit repository.
Oracle Virtual Directory also integrates JMX technology to manage and audit configuration change operations. The JMX MBeans bypass the WebService admin API, which moves the auditing service to a lower level and enables tracking for all configuration change activities and records the operation events whether they succeed or fail.
The Oracle Virtual Directory configuration management classes and WebService APIs contain methods that track the IP address from where an operation was performed and pass that IP address, along with some useful security auditing information, to the audit logic.
For each configuration, there is a corresponding configuration management class. The configuration XML files are mapped to a management class as follows:
|Configuration XML File||Auditing Configuration Management Class|
When you make changes to a configuration, Oracle Virtual Directory records a copy of the original configuration version in the auditing repository and records the differences between the old version and the new configuration.
Oracle Virtual Directory auditing tries to record granular changes about which configuration parameters have changed, including a record of the original value and the new value. If this information is not available, Oracle Virtual Directory records the full configuration file, including the old version and the new version, using the following conventions:
The DN and, if available, the IP address where the operation was performed.
Name and type of the configuration changed.
Timestamp when the event occurred.
Exact configuration details.
For example, if you added a new ACL, adapter, or listener, the event would be logged into the audit repository as follows:
NN added WHAT configuration on DD:HH. The added configuration is: CONF DETAIL.
If you modified an existing ACL, adapter, or listener or changed the auditing, logging, or server configuration settings, the event would be logged into the auditing repository as follows:
NN updated WHAT configuration on DD:HH. The configuration is changed from OO to WW.