KMAs generate SNMP information for users who have configured an SNMP agent in the network and defined SNMP Managers in the OKM Manager GUI. If you define at least one SNMP Manager in the OKM Manager GUI, the KMAs sends SNMP Informs to the IP address of that SNMP Manager(s).
v3 supports authentication, using user names and passphrases. Oracle recommends SNMPv3.
v2 does not support authentication and does not use user names and passphrases.
You can configure an SNMP Manager to use either SNMPv3 or SNMPv2. KMAs do not send SNMP informs to SNMP Managers configured to use SNMPv2 if the replication version of the OKM cluster is currently set to 10 or lower.
The following describes SNMP Management Information Base (MIB) information for users who have configured an SNMP agent in their network and have defined SNMP Managers in the OKM Manager GUI. The KMAs use Object Identifiers (OIDs) to send the following information:
Table 7-1 KMA Object Identifiers
| OID Value | Type | Description |
|---|---|---|
|
1.3.6.1.4.1.42.2.22.99.109.1 |
---- |
Generic trap |
|
1.3.6.1.4.1.42.2.22.99.1 |
string |
Date/time |
|
1.3.6.1.4.1.42.2.22.99.2 |
string |
Audit event class |
|
1.3.6.1.4.1.42.2.22.99.3 |
string |
Audit event operation |
|
1.3.6.1.4.1.42.2.22.99.4 |
string |
Audit event condition |
|
1.3.6.1.4.1.42.2.22.99.5 |
string |
Audit event severity |
|
1.3.6.1.4.1.42.2.22.99.6 |
string |
Entity ID |
|
1.3.6.1.4.1.42.2.22.99.7 |
string |
Network address |
|
1.3.6.1.4.1.42.2.22.99.8 |
string |
Message |
|
1.3.6.1.4.1.42.2.22.99.9 |
string |
Audit event solution |
When HMP is enabled then additional MIBs are used and may be downloaded from the KMA for installation in your SNMP Manager. See the section on "Configure the Hardware Management Pack (HMP)" for more information and the list of MIBs.
Available to:
Security Officer
Operator
Auditor
Procedures:
In the left navigation tree, expand System Management, and then select SNMP Manager List. See "Filtering Lists" to filter the list.
For details, highlight an SNMP entry and click Details....
Available to:
Security Officer
Procedures:
If the SNMP agent is using v3:
Create an v3 user before creating an SNMP manager in your OKM cluster. The user should use SHA (not MD5) as the authentication protocol and DES as the privacy protocol. Refer to your SNMP agent documentation for more information.
If the SNMP agent is using v2:
For OKM versions prior to 3.3.2/replication versions prior to 16, you do not need to configure an authentication protocol or create an SNMP user. Only the "public" community for SNMPv2 is supported.
In the left navigation tree, expand System Management, and then select SNMP Manager List. Click the Create...
Complete the following:
SNMP Manager ID — Uniquely identifies the SNMP Manager. This value can be between 1 and 64 (inclusive) characters.
Description — Describes the SNMP Manager. This value can be between 1 and 64 (inclusive) characters. Optional.
Network Address — The SNMP Manager's network address.
Enabled — Select the Enabled check box to indicate SNMP is enabled.
Protocol Version — Select v3 or v2. For more information, see "SNMP Protocol Versions".
User Name — The user name that is used to authenticate the SNMP Manager.
Passphrase — The passphrase that is used to authenticate the SNMP Manager.
Community String — The agent community string. Configuring public or private as valid community strings is a major security risk.
Click Save.
Consult your SNMP agent documentation for information about creating SNMP Users. For example, refer to the Solaris System Management Agent Administration Guide (http://docs.oracle.com/cd/E19253-01/817-3000/index.html) for more information about configuring the agent on a Solaris system. Also, refer to http://www.net-snmp.org/FAQ.html for more information about Net-SNMP.
Available to:
Security Officer
Procedures:
In the left navigation tree, expand System Management, and then select SNMP Manager List.
Double-click an SNMP Manager entry (or highlight an entry and click Details...).
Change the parameters, as required.
Note:
Every time you modify a SNMP Manager's details, you must reenter the passphrase.Click Save.
The HMP feature is available only on Sun Fire X4170 M2, Netra SPARC T4-1 and SPARC T7-1 servers. For more information about HMP, see https://docs.oracle.com/cd/E52095_01/.
You may not want to configure HMP on your KMAs. However, even without an SNMP configuration, there is some benefit to having HMP configured as it enhances the ILOM's ability to report system details. When configured, the HMP will report system details from any enabled protocol v2c SNMP Managers configured in the OKM cluster. Consequently, the same SNMP Manager configuration used by the OKM audit service will be used for those KMAs that have HMP configured. Configuring HMP gives you access to the following:
Event notification of hardware issues before they show up as OKM specific traps or as a KMA outage. These MIBs are configured to allow for enhanced monitoring of the KMA through SNMP SUN-HW-MONITORING-MIB, SUN-HW-TRAP-MIB, SUN-STORAGE-MIB. See "Download the HMP MIBs from the OKM Manager GUI".
Ability to use read-only get operations to the various MIBs provided.
SNMP Receivelets — Oracle Enterprise Manager (OEM) Receivelets can be implemented that turn OKM SNMP informs/traps into OEM alerts.
SNMP Fetchlets — This OEM facility can be used to leverage the MIBs installed with HMP for monitoring KMA host data.
ILOM
O/S Information is displayed on the ILOM Summary Page when HMP is installed. When you are using the ILOM Command Line Interface (CLI), enter:
show /system primary_operating system
Storage Monitoring is enabled when the HMP is installed. Enter the following ILOM CLI command:
show /system/storage
To view storage health information, enter
show /system/storage health
This examines SMART data for the disk(s). Only RAID logical volumes are supported, so no information is shown for volumes on the KMAs in ILOM.
Available to:
Security Officer
Procedures:
Select Hardware Management Pack on the Local Configuration menu.
Within the Hardware Management Pack panel, click Download MIB Bundle.Browse to a download location and then click Start.
Click the Patches & Updates tab.
Click Product or Family (Advanced).
In the Product field, enter Oracle Hardware Management Pack.
In the Release field, select the latest release from the menu.
In the Platform field, select the platform.
(Recommended) Configure the ILOM identification information using the ILOM BUI or CLI. The KMA SNMP daemon logs a warning when these fields are not configured. The subsequent SNMP notifications will contain this information and aid with troubleshooting. The recommended fields to configure are:
SP Hostname
SP System Identifier
SP System Contact
SP System Location
Local Host Interconnect
The Local Host Interconnect settings in Oracle ILOM must be in the Host Managed state (this is the default state). To verify using the ILOM user interface, navigate to ILOM Administration, and then select the Connectivity panel. On the Network tab's page, verify the Local Host Interconnect Status is "Host-Managed" and an IP address is shown, (typically)169.254.182.76.
The ILOM Administration and Notifications must not have an alert rule configured for Alert ID 15, as this will be used when configuring HMP to have faults forwarded. From the ILOM BUI, navigate to ILOM Administration, then select the Notifications panel. On the Alerts tab, check Alert ID 15. From the ILOM CLI, "show /SP/alertmgmt/rules/15".
IPMI must be enabled in the ILOM. For the ILOM BUI see ILOM Administration:ManagementAccess and the IPMI tab.
Available to:
All roles
Procedures:
In the left navigation menu, expand System Management, expand Local Configuration, and then select Current Load. This menu allows you to query load information about the KMA the GUI is connected to. All user roles can access this information.
Available to:
All roles
Auditor and Compliance Officer (can view Agent History, Data Unit History, Data Unit Key History)
Procedures:
From the System Management menu, select Audit Event List. See "Filtering Lists" to filter the list.
To view detailed information, select an Audit Log entry in the list, and then click Details... (or double-click the entry).
To export a report, select Save Report... from the View menu (or press Ctrl-S).
Click Start to initiate the export. If you have filtered the entries in the Audit Event List screen, only those entries are exported. Otherwise, all audit events are exported.
Audit Log - Field Description
Date and time that the Audit Event was created.
The operation that resulted in the creation of the Audit Event record.
Indicates the severity of the condition if the operation was not successful. Possible values are Success (no error), Warning, or Error.
Note:
If the Severity value is Error, the KMA that generated the event also issues an SNMP inform message with the event details.Indicates whether the operation was successful or not. Errors are highlighted in red. Warnings are highlighted in yellow. If you hover the cursor over an error message, a more detailed description of the error is displayed. If the Condition value is Server Busy, the KMA that generated the event also issues an SNMP inform message with the event details.
Detailed information of the Audit Event entry.
If this Audit Event is generated in response to an operation requested by a user, agent, or peer KMA, then this field displays the user-specified identifier of that entity. Otherwise, this field is blank.
If this Audit Event is generated in response to an operation requested by a user, agent, or peer KMA, then this field displays the network address of that entity. Otherwise, this field is blank.
The name of the KMA that generated this audit event. This KMA name is the user-supplied identifier that distinguishes each KMA in a cluster.
The user-supplied identifier that distinguishes each Appliance in a cluster.
Identifies the class of operations to which the Audit Event entry belongs. If the Class value is Security Violation, the KMA that generated the event also issues an SNMP inform message with the event details.
The defined length of time that the Audit Event record is retained. Possible values are:
Long Term — Event records that must be stored for a lengthy time period.
Medium Term — Event records that must be stored for a medium length time period.
Short Term — Event records that must be stored for a short time period.
A system-generated unique identifier that distinguishes each type of Audit Event entry.
A system-generated unique identifier that distinguishes each Audit Event entry.
You can create a system dump for problem resolution and download it to a compressed file on the system where the OKM Manager is running. The downloaded file is in a format that can be opened with compression utilities. The dump does not include any key material or information from which keys can be inferred.
Note:
As best practice, when you work with Oracle Service, create the system dump before you restart the KMA.Available to:
Security Officer
Operator
Procedures:
In the left navigation menu, expand System Management, and then select System Dump.
The dump file is an automatically-generated *.tar.Z file. If desired, click Browse to select a destination path.
Click Start button to begin the download.
You can configure each KMA in the cluster to send messages to one or more remote syslog servers.
If an SNMP Manager is configured and enabled, KMAs will send SNMP informs for particular OKM audit events (such as Error, Server Busy, and Security Violation among others). If an entry for a remote syslog server has been defined for a KMA, then this KMA will also send to the remote syslog server messages for the same set of OKM audit events.
If the Hardware Management Pack feature has been enabled on a Sun Fire X4170 M2 KMA or a SPARC KMA, then hardware faults will also be forwarded.
KMAs running OKM 3.3.2 or later will send the following types of operating system messages:
audit_warn(1M) messages from the Solaris audit service
Operating system messages of the following RFC 5424 facility and severity levels:
Facility = audit, Severity = notice or lower
Facility = local0, Severity = alert or lower
Facility = local7, Severity = info or lower
If KMAs reside in different physical sites, then the Security Officer can choose, for example, to configure KMAs in one site to send messages to a remote syslog server at that site and to configure KMAs in another site to send messages to a remote syslog server in that other site.
The Security Officer can configure a KMA to communicate with the remote syslog server(s) using either a TCP connection that is unencrypted or a TCP connection that is secured using Transport Layer Security (TLS).
TLS uses certificates to authenticate and encrypt the communication between a KMA and the remote syslog server. The KMA authenticates the remote syslog server by requesting its certificate and public key.
Optionally, the remote syslog server can be configured to use mutual authentication. Mutual authentication ensures that the remote syslog server accepts log messages only from authorized clients. When configured to use mutual authentication, the remote syslog server requests a certificate from the KMA to verify the identity of the KMA.
The administrator of the remote syslog server must first acquire and install on that server a certificate that was issued by a Certificate Authority (CA).
The Security Officer must obtain the certificate of the Certificate Authority that issued this server certificate.
The Security Officer must then provide this CA certificate when enabling the remote syslog feature on the KMA.
Note:
This CA certificate is a root CA certificate.The Security Officer must first acquire a certificate that was issued by a Certificate Authority (CA).
The Security Officer must then provide this client (KMA) certificate when enabling the remote syslog feature on that KMA.
The administrator of the remote syslog server must obtain the certificate of the Certificate Authority that issued this client (KMA) certificate and then install this CA certificate on the remote syslog server.
Currently, KMAs can send SNMP Informs for particular OKM audit events, if SNMP managers are defined and enabled. If a Remote Syslog Server is defined, a KMA will send to it syslog messages for the same set of OKM audit events.
Available to:
Security Officer
Procedures:
In the left navigation menu, expand System Management, expand Local Configuration, and then select Remote Syslog.
Click Create...
Enter the following information:
Destination ID of a remote syslog server. This value uniquely identifies the remote syslog server.
Network address (IP address, or if DNS is configured, host name) of the remote syslog server.
Select which network protocol (TCP Unencrypted or TLS) to use for communication with the remote syslog server. If you select TLS (either with server authentication or server and client authentication):
Enter the location of the Certificate Authority (CA) certificate file.
If you plan to use mutual authentication (using both server and client authentication) enter locations for the client (KMA) certificate file and client private key file. You can enter a password if the client private key is password protected.
Note:
Certificate and private key files must be in PEM format.Optionally, enter a port number on which the remote syslog service on the remote syslog server is listening. Port 514 is used by default for TCP Unencrypted, and port 6514 is used by default for TLS.
Use the check box to select whether the remote syslog server is enabled.
Click Save.
Available to:
Security Officer
Procedures:
In the left navigation menu, expand System Management, expand Local Configuration, and then select Remote Syslog.
Select a remote syslog server and click Details...
Update the settings as desired.
Click Save.
If at least one remote syslog server has been created, you can send a test message to all defined remote syslog servers.
Available to:
Security Officer
Procedures:
In the left navigation menu, expand System Management, expand Local Configuration, and then select Remote Syslog.
Select a remote syslog server and click Test.
Enter the text to be included in the test message and click the Test button. The KMA sends the test message to all defined remote syslog servers according to their respective defined settings.