Users Guide

Action Tracked Information
Add/remove user to role User name, old/new value of role name
Add/remove user User name
The event logs are kept in the log le. You can nd the log le(s) in: <InstallDir>\OpenManagePowerCenter\logs\Audit.log.x. Where x is the
incremental number, if applicable (shown below.)
The total size of all audit log les is limited to 20 MB. Power Center keeps up to three audit log les of approximately 6.67 MB each. If a
new log causes the le size to exceed the limitation for a single log le, Power Center renames the log le to a new name and stores the
new log in a new log le with the original le name.
When generating an audit log le, the naming rules are as follows:
• audit.log — The rst audit log le name. This le always logs the latest actions.
• audit.log.1 — The second audit log le name. This is copied from audit.log when it exceeds the le size limitation.
• audit.log.2 — The third audit log le name. This is copied from audit.log.1 when audit.log exceeds the le size limitation.
Managing certicates
Power Center uses Keytool— a key and certicate management utility from the Java Runtime Environment (JRE)—to generate a key pair
(a public key and an associated private key) that is used to create a self-signed certicate during installation.
Keytool is installed at <InstallDir>\external\jre\bin\keytool.exe. The private key and the self-signed certicate are stored in the keystore le
at <InstallDir>\keystore.ssl. The self-signed certicate expires three months after installation.
NOTE
: It is strongly recommended to update the private key and self-signed certicate.
You can manage Power Center certicates in Keytool. Common scenarios include:
• Scenario 1 — Generate a key pair and self-signed certicate. During Power Center installation, a key pair and self-signed certicate are
generated for the Power Center server.
NOTE
: When you delete an entry from the keystore le, make sure you leave at least one key pair entry in the keystore
le; otherwise, Power Center does not work.
• Scenario 2 – Replace the self-signed certicate with a signed certicate issued by a Certication Authority (CA). A certicate signed by
a CA is more likely to be trusted by the Web browsers. To sign your certicate by a CA, do the following:
• Generate a Certicate Signing Request (CSR) and submit to the CA.
• Import a certicate for your CA.
• Import the Certicate Reply from the CA.
• Scenario 3 – Import a new Trust Certicate. Some devices (for example, chassis and the exposed management interface through WS-
MAN) or web service providers may provide a certicate for Power Center validation when establishing communication. If you validate
the certicate and Power Center fails to verify it by building a trust path from the trust certicate in the keystore le, then
communication fails. In this scenario, you may need to import a new trust certicate to make sure a trust path can be built to verify the
certicate.
For more information on how to manage certicates, see Keytool documentation.
Security
113