Oracle® Fusion Middleware Administrator's Guide for Oracle Virtual Directory 11g Release 1 (11.1.1) E10046-06 |
|
![]() Previous |
![]() Next |
This chapter provides information about managing Oracle Virtual Directory logging and auditing. It contains the following topics:
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 topic 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.
See: The Oracle Fusion Middleware Administrator's Guide for complete information on logging using Oracle Enterprise Manager Fusion Middleware Control. |
Logging Considerations Specific to Oracle Virtual Directory
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.
Audit logs are created for search operations only when the search requests the userPassword attribute.
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.
You can use WLST to perform Oracle Virtual Directory logging management tasks, including:
List loggers and levels using listLoggers
Get (view) the level for a logger using getLogLevel
Set the level for a logger using setLogLevel
List log handlers using listLogHandlers
Configure log handlers using configureLogHandler
Lists known logs using listLogs
Search and display the contents of logs using displayLogs
See: For complete information about managing Oracle Virtual Directory logging using WLST, refer to the following documents:
|
Message logging can be controlled using the java.util.logging.Filter
implementation class and through the logLevel attributes specified for each adapter configuration in the in adapters.os_xml file.
Note: 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.
A 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 c=us
:
<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 AcceptOnMatch
to true
and the log messages will contain the DIT specified in the logFilter
configuration. To exclude the log messages, set AcceptOnMatch
to 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 LogHandler
:
<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>
Note: The server.os_xml, ovd-logging.xml, and adapters.os_xml files are located in the following directory:ORACLE_INSTANCE/config/OVD/config/COMPONENT_NAME/ |
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 topic contains the following sections on managing Oracle Virtual Directory auditing:
You can use Oracle Enterprise Manager Fusion Middleware Control to perform Oracle Virtual Directory auditing tasks, including managing:
Audit policies
Audit data collection and storage
Audit reports
The auditing procedure for most Oracle Fusion Middleware components, including Oracle Virtual Directory, is similar and explained in detail in the Oracle Fusion Middleware 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, or Medium.
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.
See: The Oracle Fusion Middleware Security Guide for complete information about auditing Oracle Virtual Directory using Oracle Enterprise Manager Fusion Middleware Control. |
You can use WLST to perform Oracle Virtual Directory auditing tasks, including:
Getting (viewing) audit policy using getAuditPolicy
Setting audit policy using setAuditPolicy
Listing (viewing) audit events using listAuditEvents
See: 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:
oracle.as.ovd:type=component.auditconfig,name=auditconfig,instance=INSTANCE, component=COMPONENT_NAME
Note: 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:
oracle.as.management.mbeans.register:type=component,name=COMPONENT_NAME,instance=INSTANCE
For example:
oracle.as.management.mbeans.register:type=component,name=ovd1,instance=instance1
Here is an example of a wlst
session using setAuditPolicy()
and invoke()
:
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:
ACLs (acls.os_xml)
Adapters (adapters.os_xml)
Listeners (listeners.os_xml)
Server (server.os_xml)
The audit log records include the following information for each auditing event:
Proxy user DN and IP address where the operation was performed
Note: Oracle Directory Services Manager 11.1.1.4.0 sends client IP address and user DN information to Oracle Virtual Directory 11.1.1.4.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 11.1.1.4.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 |
---|---|
acls.os_xml is | com.octetstring.vde.config.AclsCfg |
adapters.os_xml | com.octetstring.vde.config.AdaptersCfg |
listeners.os_xml | com.octetstring.vde.config.ListenersCfg |
server.os_xml | com.octetstring.vde.config.ServerCfg |
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:
Convention | Description |
---|---|
NN | The DN and, if available, the IP address where the operation was performed. |
WHAT | Name and type of the configuration changed. |
DD:HH | Timestamp when the event occurred. |
CONF DETAIL | Exact configuration details. |
OO | Old configuration. |
WW | New configuration. |
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.