2 Secure Installation and Configuration

Describes the role of security in the product.

This chapter describes how to plan an installation and then how to configure the software so that you use the software securely.

Topics

Planning the Deployment

Describes the role of security in the product architecture.

This section outlines the options for a secure installation and describes several recommended deployment topologies for the systems:

Topics

About High Availability

Describes how the product provides High Availability.

The simplest deployment architecture is a single-system deployment in which the Enterprise Controller and a Proxy Controller are installed on the same system. Although the simplicity is appealing, this type of deployment creates a single point of failure and cannot provide high availability because all components are stored on the same computer.

The High Availability configuration uses multiple Enterprise Controllers with Oracle Clusterware and a remote database. The active Enterprise Controller is used for all operations. The standby Enterprise Controllers are configured as backups. If the active Enterprise Controller must be taken offline, make another Enterprise Controller active. One of the standby Enterprise Controllers is also activated if the active Enterprise Controller fails.

Each asset is managed by a specific Proxy Controller. If a Proxy Controller fails or is uninstalled, Oracle Enterprise Manager Ops Center gives you the option to migrate the failed Proxy Controller's assets to another Proxy Controller. At any time, move an asset from one functional Proxy Controller to another Proxy Controller. The destination Proxy Controller must either be connected to the networks of the assets being moved, or be associated with those networks and have them enabled.

Requirements for Enterprise Controller High Availability

Lists the requirements for High Availability.

Use two or more systems of the same model and configured identically:
- Processor class
- Operating system
- Enterprise Manager Ops Center software version, including updates
- Network interfaces that are cabled identically to the same subnets
Use the Edit Asset action to add an asset tag that identifies the active Enterprise Controller and distinguishes it from the standby Enterprise Controller.
Maintain the standby Enterprise Controller's system in the same way as the active Enterprise Controller. The active and standby Enterprise Controllers must use the same version of Enterprise Manager Ops Center software.

Limitations of High Availability

Describes the limitations of the High Availability.

User accounts and data that are not associated with Enterprise Manager Ops Center are not part of the relocate process. Only Enterprise Manager Ops Center data is moved between the active and standby Enterprise Controllers.
Any customizations of the PAM configuration on the primary node must be repeated on the standby node. Oracle Enterprise Manager Ops Center does not replicate PAM configuration.
UI sessions are lost in a relocation.
The Enterprise Controller HA configuration applies only to the Enterprise Controller and not to Proxy Controllers.

See the Oracle Enterprise Manager Ops Center Administration for instructions in configuring and maintaining an High Availability installation.

Overview of Network Configuration

Describes a network configuration in which operations are separated.

Network connections are needed for data operations, for management operations, and for provisioning operations. The minimum configuration, but least secure, is to combine all operations on one network. Separate networks, as shown in Figure 2-1, provide the highest security and the lowest number of points of failure. However, additional network interface cards (NIC) are needed to support this configuration. Network connection (net0) can be physical NIC, a link aggregate, or an IPMP group.

Figure 2-1 Separate Management, Provisioning, Data Networks

Description of "Figure 2-1 Separate Management, Provisioning, Data Networks"

About Infrastructure and Operating Systems

Description of the role of various system administrators in the product architecture.

Oracle Enterprise Manager Ops Center manages and monitors assets in multiple locations and on multiple platforms. The responsibility for securing the network, hardware, and operating system of the server that runs the Enterprise Controller is that server's system administrator. The responsibility for securing the hardware, network, and operating system of Proxy Controllers and all assets falls on the various site system administrators.

About Storage Configuration

Describes how libraries can be configured in the product architecture.

Oracle Enterprise Manager Ops Center stores its data and metadata in Software and Storage Libraries. These libraries can reside in local file systems or on the shares of an NFS server. Because the Enterprise Controller does not mount the NFS share, install the NFS server on a system that is close to the systems that will use the NFS share, that is, the systems that host global zones and Oracle VM Servers.

About a Remote Database

Describes the alternative architecture that uses a separate database to support the product.

This version of the product software provides the capability to use a remote, customer-managed database. The Enterprise Controller interacts with the remote, customer-managed database using the Oracle*Net protocol over TCP/IP.

Oracle Enterprise Manager Ops Center provides scripts to create the database schema and users. Before you install Oracle Enterprise Manager Ops Center, your database administrator creates the database and then runs the createOCSchema_remote.sqlscript to create the Ops Center Schema and to grant the CREATE DATABASE privilege. The database administrator provides the database credentials and the connection information to you and you create the remoteDBCreds.txt file. The file can be located in a directory of your choice on the system that hosts the Enterprise Controller.

When you install the Oracle Enterprise Manager Ops Center software, you use the -remoteDBprops flag and provide the location of the remoteDBCreds.txt file. During installation, the connection between the Enterprise Controller and the remote database is created.

Starting with Release 12.2.2.0.0, you have the option to prevent the remote database's Enterprise Controller application schema from viewing or executing public database objects.

Note:

Preventing access to public database objects might affect other application schemas if they require public privileges.

To add this security enhancement, use the following procedure to execute the update_pub_privs_12.2.2.0.sql script:

Copy the update_pub_privs_12.2.2.0.sql script from the Enterprise Controller's system to the Oracle account on the server where the customer-managed database instance is installed. The script is located in the following location of the Enterprise Controller's system:
- Oracle Solaris OS: /opt/ORCLsysman-db/sql/update/diamond-update2/oracle/
- Linux OS: /opt/orcl/orcl-dbic/sql/update/diamond-update2/oracle/
On the customer-managed database's system, log into the database administrator account.

Execute the script using the following command:

sqlplus / as sysdba @update_pub_privs_12.2.2.0.sql

Typical Deployment

Illustrates a typical product architecture.

Figure 2-2 shows a deployment running the product software in Connected mode and with two Proxy Controllers.

Figure 2-2 Deployment Example

Description of "Figure 2-2 Deployment Example"

Installing Oracle Enterprise Manager Ops Center

Describes installation of the product.

Topics

About Controlling Access

Describes the importance of controlling access to the product.

Install the Enterprise Controller component only on a system where root access is controlled tightly because a root-privileged user must modify or create system services as part of the installation. To install the product on Linux systems, disable the SELINUX setting.

About Substituting CA Certificates for the Default Certificates

Describes the role of certificates in the product architecture.

Oracle Enterprise Manager Ops Center has self-signed certificates that it uses for authentication between its components. Self-signed certificates are certificates that have not been registered with any third-party Certificate Authority (CA), and are therefore not guaranteed by a Certificate Authority. These certificates issue a warning when connecting with a browser and require users to accept the certificate.

To ensure that data being transmitted and received is private and not vulnerable to eavesdropping, a self-signed certificate is sufficient. However, to ensure that the sender and receiver are authentic, substitute the self-signed certificates with Class A or B certificates from a third-party Certificate Authority.

Oracle Enterprise Manager Ops Center 's internal communication occurs between Java components and between Apache components so both types of certificates must be prepared and substituted for the self-signed certificates.

Starting in Release 12.3.1.0, use the Command Line Interface’s security mode to manage certificates. The instructions for invoking and the product’s Command Line Interface are in the Oracle Enterprise Manager Ops Center Command Line Interface, but to summarize:
1. Go to the following location:
  - Oracle Solaris: /opt/SUNWoccli/bin
  - Linux: /opt/sun/occli/bin
2. Invoke the product CLI:
  ./oc -e 'connect'
  If you are connecting to the Enterprise Controller from a remote system, you are prompted for the host name, username, and password.
3. The procedures in this section use the security mode and the jobs mode. When you enter a mode, the system prompt changes to indicate the current mode. To enter security mode, type security on the command line. You can view the man pages for any mode from the command line or in the Oracle Enterprise Manager Ops Center Command Line Interface.
For Java certificates, use the keytool utility, included in the Java Development Kit, to manage the keystore, which stores your server's certificate, and the truststore, which stores the Certificate Authority's certificates.
For Apache certificates, use the Oracle Solaris's OpenSSL utilities to create certificates for mutual authentication between a server and its clients. OpenSSL is a cryptography toolkit that implements the Transport Layer Security (TLS) network protocol. Oracle Enterprise Manager Ops Center does not use any version of SSL. All transactions with the web browser are in TLS.

Use the procedures in this section to substitute private keys with a Certificate Authority's private keys, signed by the Certificate Authority. By substituting the certificates and keys, you change the trust relationship between components. To ensure authentic communication, substitute the keys on the following:

The Enterprise Controller's server
The co-located Proxy Controller
Each additional Proxy Controller

Obtaining a Certificate Authority's Certificate

Procedure for obtaining a certificate from a Certificate Authority.

To substitute the self-signed certificate with a Certificate Authority's certificate, you must obtain the CA's certificate and communicate with the Certificate Authority during the procedure. The following procedure is the general procedure:

Identify the Certificate Authority you want to use and follow their instructions for the specific steps of this general procedure.
Submit a request for a certificate to the Certificate Authority, called a certificate signing request (CSR). The Certificate Authority returns a certificate chain, which consists of a root certificate and its signed certificate.
Download a Chain Certificate from the Certificate Authority.
Verify the certificates' fingerprints. When you add a certificate to the keystore, any transactions using that certificate become trusted. You must be certain that the certificates you received are authentic before you import them. For a Java certificate, use the following command to see the fingerprints and then communicate with the Certificate Authority to compare the fingerprints:
```
keytool -printcert -file <path/filename>
```
Replace existing certificates with the CA certificates, as described in the following sections.

Viewing the Enterprise Controller's Truststore and Keystore

Procedure for displaying information about the Enterprise Controller’s certificates and keys.

To configure secure communications, you can configure the Java keystore and truststore. The keystore stores the host server's private keys and local authority certificate, to provide the credentials for secure transactions. The truststore is similar to the keystore, but it stores certificates from remote servers, which allows the remote server to open a secure transaction.

At any time, use the following command to display the content of the Enterprise Controller's keystore:

keytool -list -v -keystore /etc/cacao/instances/oem-ec/security/jsse/keystore -storepass:file /etc/cacao/instances/oem-ec/security/password

Use the following command to display the content of the Enterprise Controller's truststore:

keytool -list -v -keystore /etc/cacao/instances/oem-ec/security/jsse/truststore -storepass trustpass

Use the CLI security mode at any time to display information about the certificates in any Proxy Controller’s truststore or any asset’s truststore. The following commands display information for each certificate on each asset or Proxy Controller: the alias, the owner, the issuer, the serial number, the creation date, and the period during which the certificate is valid.

localhost/security > list_proxy [-p|--proxy proxyID]

localhost/security > list_asset [-a assetname]

About CA Certificate Expiration

Description of the expiration of certificates.

The certificates from a Certificate Authority expire after a time period they set, usually between one and two years. Make certain you replace the certificates before they expire. If they expire, access is denied.

Verify a Certificate's Expiration Date

Procedure for displaying information about a certificate.

Use the CLI security mode at any time to verify the validity of the certificates in any Proxy Controller’s truststore or any asset’s truststore. You can specify the number of days to check for expiration of the certificate. The following examples check whether the certificate remains valid for the next 180 days.

localhost/security > check_proxy -d 180

localhost/security > check_asset -d 180

A result of OK means the certificate is valid for at least 180 days.

A result of Invalid means the certificate expires in less 180 days.

Replace the Certificate for the Enterprise Controller

Procedure for replacing a certificate on the Enterprise Controller.

You can replace an existing certificate at any time. However, when specifying an alias for a truststore, do not re-use the original alias. You must choose new aliases when replacing certificates because the original certificate and the replacement certificate use the same truststore.

You can change both the certificate and the password for the new keystore or you can change only the certificate and keep the same password for the new keystore.

Navigate to the location of the keystore:
- Oracle Solaris OS: cd /etc/cacao/instances/oem-ec/security/jsse
- Linux OS: cd /etc/opt/sun/cacao2/instances/oem-ec/security/jsse/
Create a new password by creating and then editing the following file:
```
/etc/cacao/instances/oem-ec/security/password
```
Create a new private key in the new keystore. You will be prompted to enter passwords for the key and keystore.
1. Create a new private key. Use the keytool -genkey command, according to its documentation and your site's security policy. The following is an example of the command:
```
keytool -genkey -alias cacao_agent -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -validity 7300 -keystore keystore_new -storepass:file /etc/cacao/instances/oem-ec/security/password -dname CN=ec-`uname -n`
```
  where
  
  -keyalg specifies the algorithm to be used to generate the key pair.
  
  -sigalg specifies the algorithm used to sign the self-signed certificate. This algorithm must be compatible with the algorithm specified by the -keyalg option, as described in the keytool documentation.
  
  -validity specifies the number of days that the certificate remains valid.
  
  -dname specifies the X.500 Distinguished Name to be associated with alias, and is used as the issuer and subject fields in the self-signed certificate.
2. At the prompt to enter the key password for cacao_agent, do not enter any characters. Instead, press the Enter key to set the cacao_agent key password to be the same password as the one used for the keystore. This method is the only way to ensure that the passwords match.
Create a signing request (CSR) using the keytool -certreq command, according to its documentation and your site's security policy. The following is an example of the command:
```
keytool -certreq -keyalg RSA -sigalg SHA256withRSA -alias cacao_agent -file agent.crq -keystore keystore_new -storepass:file /etc/cacao/instances/oem-ec/security/password
```
where:

SHA256withRSA specifies the algorithm used to sign the self-signed certificate.

agent.crq is the name of the file containing the signing request.
Obtain a new certificate from a Certificate Authority, according to the procedure in Obtaining a Certificate Authority's Certificate.

Import the Certificate Authority's root certificate, your_ca, into the new keystore. The root certificate is in the file root.cert.

keytool -importcert -alias your_ca -keystore keystore_new -file root.cert -storepass:file /etc/cacao/instances/oem-ec/security/password

At the prompt to confirm the certificate, enter Yes.
Import the signed certificate into the new keystore. The signed certificate is in the file agent.cert.
```
keytool -importcert -v -alias cacao_agent -file agent.cert -keystore keystore_new -storepass:file /etc/cacao/instances/oem-ec/security/password
```
The output of this command is the message"Certificate reply was installed in keystore", which confirms that the operation completed successfully.

Remove the Certificate Authority's root certificate, your_ca, from the new keystore because it is no longer needed:

keytool -delete -alias your_ca -keystore keystore_new -storepass:file /etc/cacao/instances/oem-ec/security/password

If you are using the EC-HA High Availability feature, copy the new keystore and the updated truststore to the second node system at the same location. If you are using a new password, copy it to the second node system too.

Use the CLI’s security mode to propagate the new certificate to the truststore of all Proxy Controllers:

View the status of the current certificates:

localhost/security > check_proxy

The following example shows that two Proxy Controllers have active certificates.

Proxy Certificates Status:
    Proxy  |  Alias   |      Serial      |Status|Active|
---------------------------------------------------------------
 proxy-1   | cacao_ca |     303b0061     |  OK  |ACTIVE
 proxy-2   | cacao_ca |     303b0061     |  OK  |ACTIVE
 proxy-2   |   sds    | d61bbb3e03e483f9 |  OK  |

Propagate the new certificates to the Proxy Controllers.

localhost/security > push_proxy -k /etc/cacao/instances/oem-ec/security/jsse/keystore_new
-w /etc/cacao/instances/oem-ec/security/password

The operation is reported to you as a Job ID that includes the Enterprise Controller’s name:

Job ID is ec_name.n

Use the jobs mode as a one-line command to follow the progress of the job. This one-line command lets you run a command in a different mode without ending the current mode.
```
localhost/security > cli.jobs.list -C1
```
```
ec_name.n |       SUCCESS       |     root    |     Propagate Satellite Certificates to Proxies  
```

When the job is finished, verify the status of the certificates again. This example shows that all new certificates have been propagated but original certificates are still in use. These certificates remain in use until the active keystore is changed.

localhost/security > check_proxy

Proxy Certificates Status:
  Proxy  |     Alias     |      Serial      |Status|Active|
--------------------------------------------------------------------
 proxy-1 | cacao_agent-1 |     2fe12e10     |  OK  |      
 proxy-1 |    cacao_ca   |     303b0061     |  OK  |ACTIVE
 proxy-1 | cacao_agent-0 |     a479618c     |  OK  |      
 proxy-2 | cacao_agent-1 |     2fe12e10     |  OK  |      
 proxy-2 |    cacao_ca   |     303b0061     |  OK  |ACTIVE
 proxy-2 | cacao_agent-0 |     a479618c     |  OK  |      
 proxy-2 |      sds      | d61bbb3e03e483f9 |  OK  |

Stop the Enterprise Controller.
Rename the existing keystore to identify it as the previous keystore:
```
mv keystore keystore_old
```
Rename the new keystore to identify it as the current keystore:
```
mv keystore_new keystore
```
Set the permissions of the keystore file to 600:
```
chmod 600 keystore
```
Remove the truststore GF
```
rm truststore_gf
```

Rename the directories so that password is in effect and then change its permissions:

mv ../password ../password_old 
mv ../password_new ../password 
chmod 600 ../password_new

Restart the Enterprise Controller. After this start, the new certificates are in use. Remote users of the Command Line Interface must accept the new certificate the first time they connect to the CLI.

If you are using the EC-HA High Availability feature, repeat the same commands on the second node system:

mv keystore keystore_old
mv keystore_new keystore
rm truststore_gf
mv ../password ../password_old 
mv ../password_new ../password 
chmod 600 ../password_new

Use the security mode to remove the original certificates from the Proxy Controllers’ truststores.

Verify that all new certificates are now in use and the original certificates are not used.

localhost/security > check_proxy

The following example shows that the new certificates, starting with cacao_agent, are now the active certificates.

Proxy Certificates Status:
  Proxy  |     Alias     |      Serial      |Status|Active|
--------------------------------------------------------------------
 proxy-1 | cacao_agent-1 |     2fe12e10     |  OK  |ACTIVE
 proxy-1 |    cacao_ca   |     303b0061     |  OK  |      
 proxy-1 | cacao_agent-0 |     a479618c     |  OK  |ACTIVE
 proxy-2 | cacao_agent-1 |     2fe12e10     |  OK  |ACTIVE
 proxy-2 |    cacao_ca   |     303b0061     |  OK  |      
 proxy-2 | cacao_agent-0 |     a479618c     |  OK  |ACTIVE
 proxy-2 |      sds      | d61bbb3e03e483f9 |  OK  |

To remove the old certificates from its truststore, you must remove each one individually. Each operation creates a job with an ID that includes the Enterprise Controller’s name.
```
localhost/security > remove_proxy -s 303b0061
```
```
Job ID is ec_name.YY
```

Verify that each job has been completed.

localhost/security > cli.jobs.list -C1

ec_name.YY | SUCCESS | root | Delete Certificate from Proxies | All known Proxies

Verify the status of the new certificates:

localhost/security > check_proxy

Proxy Certificates Status:
 Proxy   |     Alias     |      Serial      |Status|Active|
--------------------------------------------------------------------
 proxy-1 | cacao_agent-1 |     2fe12e10     |  OK  |ACTIVE
 proxy-1 | cacao_agent-0 |     a479618c     |  OK  |ACTIVE
 proxy-2 | cacao_agent-1 |     2fe12e10     |  OK  |ACTIVE
 proxy-2 | cacao_agent-0 |     a479618c     |  OK  |ACTIVE
 proxy-2 |      sds      | d61bbb3e03e483f9 |  OK  |

Because you import the certificates for the new keys into the Proxy Controller truststore before you switch keys, an SSL error occurs in the Proxy Controller. For a Proxy Controller running version 12.3.0.0.0 version or later, the Proxy Controller recovers automatically in a few minutes. The Proxy Controller reads the truststore, detects the new certificates, and restores communication with the Enterprise Controller.

If the Proxy Controller is running a previous version or you experience a delay or other problem, stop and restart the Proxy Controller to force it to re-read its truststore.

Replace the Certificate for the Proxy Controller

Procedure for replacing a certificate on the Proxy Controller.

You must use a different certificate on the Proxy Controller from the certificate used on the Enterprise Controller. You must use a different certificate on each Proxy Controller.

Do not re-use an existing alias when you add a new certificate to a truststore. Each alias in a truststore must be unique.

Navigate to the keystore:
- Oracle Solaris OS: cd /etc/cacao/instances/scn-proxy/security/jsse
- Linux OS: cd /etc/opt/sun/cacao2/instances/scn-proxy/security/jsse/
Set the permissions of the keystore file to 0266:
```
# umask 0266
```
Create a new private key in the new keystore.
1. Create a new private key. Use the keytool -genkey command, according to its documentation and your site's security policy. Do not include the -keypass option so that a prompt for the password will be displayed. The following is an example of the command:
```
keytool -genkey -alias cacao_agent -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -validity 7300 -keystore keystore_new -storepass:file /etc/cacao/instances/scn-proxy/security/password -dname CN=ec-`uname -n`
```
  where
  
  -keyalg specifies the algorithm to be used to generate the key pair.
  
  -sigalg specifies the algorithm used to sign the self-signed certificate. This algorithm must be compatible with the algorithm specified by the -keyalg option, as described in the keytool documentation.
  
  -validity specifies the number of days that the certificate remains valid.
  
  -dname specifies the X.500 Distinguished Name to be associated with alias, and is used as the issuer and subject fields in the self-signed certificate. If you do not include the distinguished name in the command, the user is prompted for one.
2. At the prompt to enter the key password for cacao_agent, do not enter any characters. Instead, press the Enter key to set the cacao_agent key password to be the same password as the one used for the keystore. This method is the only way to ensure that the passwords match.
Create a signing request (CSR) using the keytool -certreq command, according to its documentation and your site's security policy. The following is an example of the command:
```
keytool -certreq -keyalg RSA -sigalg SHA256withRSA -alias cacao_agent -file agent.crq -keystore keystore_new -storepass:file /etc/cacao/instances/scn-proxy/security/password
```
where:

SHA256withRSA specifies the algorithm used to sign the self-signed certificate.

agent.crq is the name of the file containing the signing request.
Obtain a new certificate from a Certificate Authority for each Proxy Controller, according to the procedure in Obtaining a Certificate Authority's Certificate.

Import the Certificate Authority's root certificate, your_ca, into the new keystore. The root certificate is in the file root.cert.

keytool -importcert -alias your_ca -keystore keystore_new -file root.cert -storepass:file /etc/cacao/instances/scn-proxy/security/password

At the prompt to confirm the certificate, enter Yes.
Import the signed certificate into the new keystore. The signed certificate is in the file agent.cert.
```
keytool -importcert -v -alias cacao_agent -file agent.cert -keystore keystore_new -storepass:file /etc/cacao/instances/scn-proxy/security/password
```
The output of this command is the message"Certificate reply was installed in keystore", which confirms that the operation completed successfully.

Remove the Certificate Authority's root certificate, your_ca, from the new keystore because it is no longer needed:

keytool -delete -alias your_ca -keystore keystore_new -storepass:file /etc/cacao/instances/scn-proxy/security/password

Use the CLI’s security mode to propagate the new certificate to the truststore of all the assets managed by the specified Proxy Controller:

View the status of the current certificates:

localhost/security > check_asset -p proxy-1

The following example shows that the two assets managed by this Proxy Controller have active certificates.

Asset Certificates Status:
   Proxy |  Asset  |     Alias     |  Serial  |Status|Active|
-------------------------------------------------------------------------------
 proxy-1 | asset-1 |    cacao_ca   | 70451d3b |  OK  |ACTIVE
 proxy-1 | asset-2 |    cacao_ca   | 70451d3b |  OK  |ACTIVE

Propagate the new certificates to the truststore of each asset:
```
localhost/security > push_asset -p proxy-1 -k /etc/cacao/instances/scn-proxy/security/jsse/keystore_new
```
The operation is reported to you as a Job ID that includes the Enterprise Controller’s name:
```
Job ID is ec_name.n
```
Use the jobs mode as a one-line command to follow the progress of the job. This one-line command lets you run a command in a different mode without ending the current mode.
```
localhost/security > cli.jobs.list -C1
```
```
ec_name.n | SUCCESS | [Ops Center]| Propagate Proxy Certificates to AC/VC | Propagate Proxy Certificates to AC/VC
  
```

localhost/security > check_asset -p proxy-1

Asset Certificates Status:
   Proxy |    Asset |      Alias      |  Serial  |Status|Active|
---------------------------------------------------------------------------------
 proxy-1 |  asset-1 |  cacao_agent-1  | 2fe12e10 |  OK  |      
 proxy-1 |  asset-1 |     cacao_ca    | 70451d3b |  OK  |ACTIVE
 proxy-1 |  asset-1 |  cacao_agent-0  | a4797cad |  OK  |      
 proxy-1 |  asset-2 |  cacao_agent-1  | 2fe12e10 |  OK  |      
 proxy-1 |  asset-2 |     cacao_ca    | 70451d3b |  OK  |ACTIVE
 proxy-1 |  asset-2 |  cacao_agent-0  | a4797cad |  OK  |

Place the Proxy Controller in maintenance mode to prevent auto-recovery during the remaining steps of this procedure.
Stop the Proxy Controller's internal communication using the following command:
- Oracle Solaris OS: /opt/SUNWxvmoc/bin/proxyadm stop -w
- Linux OS: /opt/sun/xvmoc/bin/proxyadm stop -w
Rename the existing keystore to identify it as the previous keystore:
```
mv keystore keystore_old
```
Rename the new keystore to identify it as the current keystore:
```
mv keystore_new keystore
```

Verify the access rights to the keystore.

ls -l /var/opt/sun/xvm/bui/conf/password

-r--------   1 root     root         199 juin 14 08:18 /var/opt/sun/xvm/bui/conf/password

Remove the truststore GF.
```
rm truststore_gf
```
Restart the Proxy Controller:
- Oracle Solaris OS: /opt/SUNWxvmoc/bin/proxyadm start -w
- Linux OS: /opt/sun/xvmoc/bin/proxyadm start -w

Use the security mode to remove the original certificates from the assets’ truststores.

Verify that all new certificates are now in use and the original certificates are not used.

localhost/security > check_asset -p proxy-1

Asset Certificates Status:
   Proxy |   Asset  |                Alias                |  Serial  |Status|Active|
-----------------------------------------------------------------------------------------------------
 proxy-1 |  asset-1 |            cacao_agent-1            | 2fe12e10 |  OK  |ACTIVE
 proxy-1 |  asset-1 |               cacao_ca              | 70451d3b |  OK  |      
 proxy-1 |  asset-1 |            cacao_agent-0            | a4797cad |  OK  |ACTIVE
 proxy-1 |  asset-2 |            cacao_agent-1            | 2fe12e10 |  OK  |ACTIVE
 proxy-1 |  asset-2 |               cacao_ca              | 70451d3b |  OK  |      
 proxy-1 |  asset-2 |            cacao_agent-0            | a4797cad |  OK  |ACTIVE

To remove the old certificates from its truststore, you must remove each one individually. Each operation creates a job with an ID that includes the Enterprise Controller’s name.
```
localhost/security > remove_asset -p proxy-1 -s 70451d3b
```
```
Job ID is ec_name.tt
```

Verify that each job has been completed.

localhost/security > cli.jobs.list -C1

ec_name.tt | SUCCESS | root | Delete Certificate from assets | All known Proxies

Verify the status of the new certificates:

localhost/security > check_asset -p proxy-1

Asset Certificates Status:
   Proxy |   Asset  |      Alias      |  Serial  |Status|Active|
---------------------------------------------------------------------------------
 proxy-1 | asset-1  |  cacao_agent-1  | 2fe12e10 |  OK  |ACTIVE
 proxy-1 | asset-1  |  cacao_agent-0  | a4797cad |  OK  |ACTIVE
 proxy-1 | asset-2  |  cacao_agent-1  | 2fe12e10 |  OK  |ACTIVE
 proxy-1 | asset-2  |  cacao_agent-0  | a4797cad |  OK  |ACTIVE

Remove the Proxy Controller from maintenance mode

Because you import the certificates for the new keys into the agent truststore before you switch keystores, an SSL error occurs in the agent. Starting with version 12.3.0.0.0 version, the agent recovers automatically in a few minutes. The agent reads the truststore, detects the new certificates, and restores communication with the Proxy Controller.

If the agent is deployed from a previous version or you experience a delay or other problem, stop and restart the agent to force it to re-read its truststore.

Substituting Certificates for the Glassfish Web Container

Procedure for changing the certificates for Glassfish web container.

Oracle Enterprise Manager Ops Center has self-signed certificates that it uses for authentication for its Glassfish web container. The benefit of substituting the self-signed certificates with certificates from a Certificate Authority is that users do not see a warning from the browser about attempting an untrusted connection and do not have to add a security exception to use the product.

To replace the self-signed certificate on a system that has been running Oracle Enterprise Manager Ops Center, use the following procedure:

Stop the Enterprise Controller's internal communication using the following command:
- Oracle Solaris OS: /opt/SUNWxvmoc/bin/ecadm stop -w
- Linux OS: /opt/sun/xvmoc/bin/ecadm stop -w
Navigate to the keystore:
```
cd  /var/opt/sun/xvm/bui/conf
```
Delete the keystore. The keystore is re-created automatically when you create a new private key later in this procedure.
```
rm keystore
```
Delete the Oracle Glassfish Server truststore used by the product's web server. The truststore is re-created automatically when the Enterprise Controller is restarted.
```
rm keystore_truststore_gf
```
Create a new private key, according to your site's security policy. Use the keytool -genkey command, according to its documentation and your site's security policy. Do not include the -keypass option so that a prompt for the password will be displayed. The following is an example of the command for creating the private key:
```
keytool -genkey -alias `uname -n` -keyalg RSA -sigalg SHA1withRSA -keysize 2048 -validity 7300 -keystore keystore -storepass password -dname CN=bui-`uname -n`
```
where

-keyalg specifies the algorithm to be used to generate the key pair.

-sigalg specifies the algorithm used to sign the self-signed certificate. This algorithm must be compatible with the algorithm specified by the -keyalg option, as described in the keytool documentation.

-dname specifies the X.500 Distinguished Name to be associated with alias, and is used as the issuer and subject fields in the self-signed certificate. If you do not include the distinguished name in the command, the user is prompted for one.

-validity specifies the number of days that the certificate remains valid.

-password specifies either the clear text password or the local file named password that contains an arbitrary string used as the keystore password. If you are using a local file named password, then use the -storepass:file <filename> format.

Note:

If you are installing Oracle Enterprise Manager Ops Center version 12.3.2, use the -storepass:file <filename> for the keystore password.
At the prompt for the key password, press the Enter key to set the key password to match the keystore password.

Create a signing request:

keytool -certreq -keyalg RSA -sigalg SHA256withRSA -alias `uname -n` -file bui.crq -keystore keystore -storepass password

If you have verified the certificate you received from the Certificate Authority, as described in Step 4 of the procedure in Obtaining a Certificate Authority's Certificate, you are ready to import it.
Import the certificate that the CA sent to you into the keystore. The certificate is in the file root.cert.
```
keytool -importcert -alias your_ca -keystore keystore -file root.cert -storepass password
```
At the prompt to confirm the certificate, enter Yes.
Import the signed certificate into the keystore. The certificate is in the file bui.cert.
```
keytool -importcert -v -alias `uname -n` -file bui.cert -keystore keystore -storepass password
```
The output of this command is the message"Certificate reply was installed in keystore", which confirms that the operation completed successfully.
Remove the Certificate Authority's root certificate, your_ca, from the keystore because it is no longer needed:
```
keytool -delete -alias your_ca -keystore keystore -storepass password
```
Restart the Enterprise Controller:
- Oracle Solaris OS: /opt/SUNWxvmoc/bin/ecadm start -w
- Linux OS: /opt/sun/xvmoc/bin/ecadm start -w

Replace the Certificate for the Apache UCE Container

Procedure for replacing a certificate on the Apache UCE Container.

Use the following procedure to replace the certificates by accomplishing the following:

Create and propagate the new certificates to the clients of the Apache service.
Stop the Apache service, replace the certificates, and then restart the Apache service.

Copy your local Certificate Authority key and certificate files to a secure location on your server. This is a temporary location.
Rename the Certificate Authority certificate file to server.crt.
Rename the Certificate Authority key file to server.key.

To add the new certificate to the truststore of the client of the Apache Service, define the following variables

SMSF_STORE=/var/opt/sun/xvm/security/jsse/smsfacade/jssecacerts
SMSF_PASS=`awk -F= '/^engine.installcert.passphrase/{print $2}' /var/opt/sun/xvm/persistence/scn-satellite/satellite.properties`
NEW_SERVER_SSL_CRT=<your secure temporary location>/server.crt

For Oracle Solaris OS, define the following variables:

TRUST_STORE=/etc/cacao/instances/oem-ec/security/jsse/truststore
TRUST_PASS=`awk -F= '/^com.sun.cacao.ssl.truststore.password/{print $2}' /etc/cacao/instances/oem-ec/private/cacao.properties`

For Linux OS, define the following variables:

TRUST_STORE=/etc/opt/sun/cacao2/instances/oem-ec/security/jsse/truststore
TRUST_PASS=`awk -F= '/^com.sun.cacao.ssl.truststore.password/{print $2}' /etc/opt/sun/cacao2/instances/oem-ec/private/cacao.properties`

Add the new certificate to the truststore. This example uses sds-2 and 127.0.0.1-2 to show that the aliases must be different from the original aliases. Specify alias names for your convenience or according to your site policy.

keytool -importcert -file $NEW_SERVER_SSL_CRT -alias sds-2 -keystore $TRUST_STORE -storepass $TRUST_PASS -noprompt
keytool -importcert -file $NEW_SERVER_SSL_CRT -alias 127.0.0.1-2 -keystore $SMSF_STORE -storepass $SMSF_PASS -noprompt

Stop the Enterprise Controller and the Proxy Controllers:
- Oracle Solaris OS:
  - /opt/SUNWxvmoc/bin/ecadm stop -w
  - /opt/SUNWxvmoc/bin/proxyadm stop -w
- Linux OS:
  - /opt/sun/xvmoc/bin/ecadm stop -w
  - /opt/sun/xvmoc/bin/proxyadm stop -w
Navigate to the location of the certificate and key files for the Apache web container:
- Oracle Solaris OS: cd /var/opt/sun/xvm/uce/etc.opt/server/uce_server/ssl.crt
- Linux OS: cd /var/opt/sun/xvm/uce/etc/uce_server/ssl.crt
Move the current server.crt file and server.key file from the ssl.crt directory to an alternate, secure location.
Copy your local Certificate Authority files from the secure temporary location to the ssl.crt directory.

Verify the permissions for the server.key file are set to allow only the service user to read the file:

chown uce-sds:uce-sds server.key
chmod 400 server.key

The files now have these permissions:

-r--------  1 uce-sds  uce-sds  1751 Jun 13 13:05 server.key
-rw-r--r--  1 uce-sds  uce-sds  1220 Jun 13 13:05 server.crt

If the server.key file is encrypted and requires a password, edit the following file to echo the password:
- Oracle Solaris OS: /var/opt/sun/xvm/uce/etc.opt/server/uce_server/.sslphrase
- Linux OS: /var/opt/sun/xvm/uce/etc/uce_server/.sslphrase
Restart the Enterprise Controller and Proxy Controllers.
- Oracle Solaris OS:
  - /opt/SUNWxvmoc/bin/ecadm start -w
  - /opt/SUNWxvmoc/bin/proxyadm start -w
- Linux OS:
  - /opt/sun/xvmoc/bin/ecadm start -w
  - /opt/sun/xvmoc/bin/proxyadm start -w
Use the CLI’s security mode to propagate the new UCE certificate to each Agent Controller that needs it.
```
localhost/security > push_uce -p <proxy name>
```

About Installing a Remote Proxy Controller Securely

Description of a secure way to install a Proxy Controller on a remote system.

When installing a Proxy Controller that is not co-located with the Enterprise Controller, do not use the Proxy Controller Deploy action from the browser interface. Instead, copy the Proxy Controller bundle to the target system and then log in as root to install the software. This method removes the need to provide root credentials to the Proxy Controller's system and eliminates the need to enable ssh access from the Enterprise Controller's system to the Proxy Controller's system.

Configuring Oracle Enterprise Manager Ops Center

Lists the tasks for configuring the product.

A privileged user must be enabled for the Oracle Enterprise Manager Ops Center software. Log in as the privileged user to perform the tasks in this section:

About the Connection Mode

Describes the differences between Connected mode and Disconnected mode for a set of tasks.

Connection modes provide a way to keep the product software and all of the asset software current. However, Connected mode requires Internet access and if this access cannot be made secure or if a site's policy does not enable Internet access, the alternative is to run Oracle Enterprise Manager Ops Center in Disconnected mode. Although Disconnected mode might seem to provide the most secure environment, its use relies on manual procedures that can are error-prone without rigorous compliance to procedures and policies. Table 2-1 shows how operations are affected by the connection mode.

Table 2-1 Comparison of Functions in Different Connection Modes

Operation	Connected Mode	Disconnected Mode
Obtain a new version of the product software	Use the Oracle Ops Center Downloads action to create a job that obtains the latest version.	Log in to an Internet-facing system and download the `https://updates.oracle.com/OCDoctor/harvester_bundle-latest.zip` file. Unzip the compressed file and run the `harvester` script to connect to the Oracle Datacenter and create an upgrade bundle. Copy the update bundle to the Enterprise Controller's system.
Upgrade the product software	Use the Upgrade Enterprise Controller action. For each Proxy Controller, use the Update to Latest Available Version action.	For the Enterprise Controller and each Proxy Controller: Log in to each system as root and create a temporary directory. Move the upgrade software from the Internet-facing system to the new directory. Uncompress the file and install the software, according to the instructions in the appropriate installation guide.
Provision an OS and update an existing OS, using the latest image.	Download the operating system software from `http://updates.oracle.com` to a software library.	Obtain the image. Use a CD or DVD to load the operating system software. Log in to an Internet-facing system and download the operating system software from `http://updates.oracle.com` Then use the Upload ISO Images action and the Import Images action to update the contents of the Enterprise Controller's software library.
Provision firmware and update existing firmware, using the latest image.	Download firmware from `http://updates.oracle.com` or vendor sites.	Use a CD or DVD to load the software. Then use the Upload ISO Images action, the Upload Firmware action, and the Import Images actions to update the contents of the Enterprise Controller's software library.
Use Automatic Service Requests (ASR)	After you register the assets in the My Oracle Support database and register a user account as the My Oracle Support user, you have the option to create a service request whenever an incident is reported. In an Automated Service Request, the following information is sent from the Enterprise Controller to My Oracle Support: serial number FRU data site location hardware SNMP trap	Contact My Oracle Support to request service.
Create a Services Request	After you register the assets in the My Oracle Support database and register a user account as the My Oracle Support user, select the Open Service Request action.	Contact My Oracle Support to request service. The Open Service Request action is disabled.
Verify warranties	After you register the assets in the My Oracle Support database and register a user account as the My Oracle Support user, view the warranty of a specific asset or all assets.	Contact My Oracle Support to coordinate warranty records with your own records.

Disable Multiple Logins

Procedure for restricting a user to one login instance.

The default behavior is to allow a user to log in multiple times. This convenience can be a security risk. You can disable simultaneous sessions for an individual user account or for a role, to affect all user accounts that have the role.

Click Setup in the title bar as shown in Figure 2-3.
Click My Preferences to change your account or click Role Preferences to change the role, which affects all user accounts that have that role.

Figure 2-3 Setting User Preferences

Description of "Figure 2-3 Setting User Preferences"
Click User Interface Preferences.
In the Display Preferences section, select the Disable Multiple Sessions checkbox.
Log out and log in again to make the change take effect.

About Securing the Log Files

Describes the product’s log files.

All installation and upgrade log files remain in place to assist in diagnosing any problems with the installation or upgrade. Because their content can be considered sensitive, archive them securely and remove the files after a successful installation or upgrade.

The product installs a diagnostic program,OCDoctor, that gathers logged data, analyzes an installation for common errors, and responds to inquiries. To remove the program at any time, delete its files and directories.

The installation logs are found in the following locations:

Log of the most recent installation or uninstallation: /var/tmp/opscenter/installer.log.latest
Log of previous installation or uninstallation operations: /var/tmp/opscenter/installer.log.xxxx
Log of a specific installation:

/var/opt/sun/xvm/oracle/app/oraInventory/logs/silentInstall<yyyy-mm-dd-hh-mm-sspm>.log
Log of an agent installation: /var/scn/install/log

The log of upgrade actions for the Enterprise Controller and its co-located Proxy Controller is in the file: /var/opt/sun/xvm/update-saved-state/update_satellite_bundle_12.1.n.xxxx/updatelog.txt

The log of upgrade actions for a Proxy Controller that is not co-located is in the file: /var/opt/sun/xvn/update-saved-state/update_proxy_bundle_12.1.n.xxxx/updatelog.txt

About Database Credentials

Describes how the product’s database can be secured.

Database passwords are encrypted in /var/opt/sun/xvm/dbpw.properties, using AES 128-bit encryption. The Advanced Encryption Standard (AES) specification defines one key for both encrypting and decrypting electronic data.

About Securing the Local Database

Describes methods for keeping database secure when it runs on the same system as the Enterprise Controller.

Access to the local database is restricted to processes on the Enterprise Controller. To allow an external host to get access to the database, you must modify the Oracle*Net Listener configuration, as described in Access to Database Data.

You must protect the properties file for the database, /var/opt/sun/xvm/db.properties, because it contains schema names and passwords. Use the most restrictive permission: read-only by file owner.
You must protect the compressed file created when you use the ecadm backup command, as described in About Backing Up and Restoring the Enterprise Controller. This tar file contains the dump of the local database. You must also ensure that the backup file is moved to an alternate location.

About Securing a Remote Database

Describes the methods for securing the database when it runs on a different system from the Enterprise Controller’s system.

You must remove the remoteDBCreds.txt file after installation. The file contains unencrypted credentials for the schema on the customer-managed database, used to configure the connection between the Enterprise Controller and the remote database. The file is located on the system that hosts the Enterprise Controller in a directory chosen by the administrator who installed the software.
If you are upgrading from product version 12c Release 1 (12.1.0.0.0) to a later version and use a remote database, you must also execute the refactorOCPrivs_12.1.x.0.sql script as described in the following section to further tighten security for the schema owner on the remote database.
You must protect the properties file for the database, var/opt/sun/xvm/db.properties, because it contains schema names and passwords. Use the most restrictive permission: read-only by file owner.
You must ensure that a remote database is included in your site's routine backup plan so that the Oracle Enterprise Manager Ops Center data can always be recovered.

Using the refactorOCPrivs_12.1.x.0.sql Script

Procedure for using the SQL script for a customer-managed database.

Use a database administrator account for this procedure.

To obtain the schema names for the remote database, view the /opt/sun/xvm/db.properties file and search for the mgmtdb.appuser and mgmtdb.roappuser values.

Copy the refactorOCPrivs_12.1.x.0.sql script from the Enterprise Controller's system to the Oracle account on the server where the customer-managed database instance is installed. The script is located in the following location of the Enterprise Controller's system:
- Oracle Solaris OS: /opt/ORCLsysman-db/sql/update/delta-update1/oracle/refactorOCPrivs_12.1.x.0.sql
- Linux OS: /opt/orcl-sysman-db/sql/update/delta-update1/oracle/refactorOCPrivs_12.1.x.0.sql
Log in as the database administrator and execute the SQL script, using the following command:
```
sqlplus / as sysdba @refactorOCPrivs_12.1.1.0.sql
```
At the prompts for Ops Center database login and Read-Only Ops Center database login, enter the schema names created when the remote database was created.

Verify the new roles and privileges by running the following SQL statement in a privileged database administrator account:

set pages 0
Select
   lpad(' ', 2*level) || 
   Granted_Role "User, his roles and privileges"
From
  (
-- THE USERS
    Select 
       null  Grantee, 
       UserName Granted_Role
    From 
       Dba_Users
   Where
      UserName Like Upper('&_OC_SYSTEM_SCHEMA%')
-- ROLES TO ROLES RELATIONS 
Union
    Select 
       Grantee,
       Granted_Role
    From
       Dba_Role_Privs
-- THE ROLES TO PRIVILEGE RELATIONS 
 Union
    Select
       Grantee,
       Privilege
    From
        Dba_Sys_Privs
  )
Start With 
   Grantee is null
Connect By 
   Grantee = Prior Granted_Role
/
 
Enter the value for the OC System Database Login (i.e the value for mgmtdb.appuser) at the prompt:
    Enter value for _oc_system_schema: OC <cr>

The following are the new roles and privileges, in addition to those granted when the original schema was created such as CREATE DATABASE LINK.

CREATE TABLE
    CREATE VIEW
    OC_SYSTEM_ROLE
      CREATE CLUSTER
      CREATE INDEXTYPE
      CREATE OPERATOR
      CREATE PROCEDURE
      CREATE SEQUENCE
      CREATE SESSION
      CREATE TRIGGER
      CREATE TYPE

The following are the Read Only roles and permissions.

    CREATE SESSION
    CREATE SYNONYM

Changing the Database Credentials for the Ops Center User

Procedure for changing the credentials of the database that Ops Center uses.

You can change the database password for the Oracle Enterprise Manager Ops Center user on an embedded or customer-managed database. The Enterprise Controller's services must be restarted to use the new password.

Use this procedure to change the credentials:

Create a temporary file containing the new password and secure it with 600 permissions.
For example:
```
# touch /tmp/password
# chmod 600 /tmp/password
# vi /tmp/password
newpassword
```

Use the ecadm command with the change-db-password subcommand and the -p <password file> option to change the database password. When prompted, confirm the Enterprise Controller restart.

For example:

# ./ecadm change-db-password -p /tmp/password
The Enterprise Controller will be restarted after the database password is changed. Continue? (y/n)
y
ecadm:    --- Changed database password, restarting.
ecadm: shutting down Enterprise Controller using SMF...
ecadm: Enterprise Controller services have stopped
ecadm: Starting Enterprise Controller with SMF...
ecadm: Enterprise Controller services have started
#

If you have a high availability configuration, the ecadm command copies the new database properties to each remote cluster node. Enter the root password for each remote cluster node.

For example:

ecadm:    --- Changed database password, restarting.
The DB configuration file must now be copied to each remote cluster node.
You will be prompted for the root password for each node to perform the copy.
Copying to node OC-secondary
Password: password
<output omitted>
ecadm:    --- Enterprise Controller successfully started HA
#

Remove the temporary file containing the new password.
For example:
```
# rm /tmp/password
```

Changing the Database Credentials for the Read-Only User

Procedure for changing the credentials for the database..

You can change the database password for the read-only user on an embedded or customer-managed database. The Enterprise Controller's services must be restarted to use the new password.

Use this procedure to change the credentials:

Create a temporary file containing the new password.
For example:
```
# vi /tmp/password
newpassword
```

Use the ecadm command with the change-db-password subcommand and the -p <password file> and -r options to change the database password. When prompted, confirm the Enterprise Controller restart.

For example:

# ecadm change-db-password -r -p /tmp/password
The Enterprise Controller will be restarted after the database password is changed. Continue? (y/n)
y
ecadm:    --- Changed database password, restarting.
ecadm: shutting down Enterprise Controller using SMF...
ecadm: Enterprise Controller services have stopped
ecadm: Starting Enterprise Controller with SMF...
ecadm: Enterprise Controller services have started
#

If you have a high availability configuration, the ecadm command copies the new database properties to each remote cluster node. Enter the root password for each remote cluster node.

For example:

ecadm:    --- Changed database password, restarting.
The DB configuration file must now be copied to each remote cluster node.
You will be prompted for the root password for each node to perform the copy.
Copying to node OC-secondary
Password: password
<output omitted>
ecadm:    --- Enterprise Controller successfully started HA
#

Remove the temporary file containing the new password.
For example:
```
# rm /tmp/password
```

Disable the Domain Model Navigator

Procedure for disabling the interface to the domain model.

Oracle Enterprise Manager Ops Center provides a Domain Model Navigator to allow Oracle support personnel to gather detailed information about the state of the system. This diagnostic interface is enabled by default and requires user authentication for access. However, because the Domain Model Navigator displays an internal view of the product software, disable the interface on the Enterprise Controller and Proxy Controllers using the following procedure. The agents for assets are not part of the Domain Model Navigator.

Log in to the Enterprise Controller as the root user.
Click Administration in the Navigation pane.
Click Enterprise Controller.
Click Configuration in the center pane.
In the Subsystem field, click Domain Model Navigator. The allowToRun property's default value is true, as shown in Figure 2-4.

Figure 2-4 Property of Domain Model Navigator

Description of "Figure 2-4 Property of Domain Model Navigator"
Click in the Value field to edit it. Change the value to false.
Click the Save Properties icon.
Perform the following procedure on each Proxy Controller:
1. Edit the file /opt/sun/n1gc/lib/XVM_PROXY.properties
2. Add the following line to the file:
```
domain.model.navigator.allow=false
```
3. Stop and restart the Proxy Controller:
```
/opt/SUNWxvmoc/bin/proxadm stop
/opt/SUNWxvmoc/bin/proxadm start
```

Stop and restart the Enterprise Controller:

/opt/SUNWxvmoc/bin/satadm stop
/opt/SUNWxvmoc/bin/satadm start

To investigate an issue with an asset, My Oracle Support might instruct you to view the Domain Model Navigator. To re-enable the Domain Model Navigator, use the same procedure to set the property values to true.

Enable the Domain Model Navigator on the Enterprise Controller

Procedure for enabling the interface to the domain model.

To enable the Domain Model Navigator:

Log in to the Enterprise Controller as the root user.
Click Administration in the Navigation pane.
Click Enterprise Controller.
Click Configuration in the center pane.
Click the Restore Properties icon.
Repeat the following procedure on each Proxy Controller:
1. Edit the file /opt/sun/n1gc/lib/XVM_PROXY.properties
2. Add the following line to the file:
```
domain.model.navigator.allow=true
```
3. Stop and restart the Proxy Controller:
```
/opt/SUNWxvmoc/bin/proxadm stop
/opt/SUNWxvmoc/bin/proxadm start
```

Stop and restart the Enterprise Controller:

/opt/SUNWxvmoc/bin/satadm stop
/opt/SUNWxvmoc/bin/satadm start

Using the Domain Model Navigator

Procedures for locating or changing information in the domain model.

The Domain Model represents Domain Model MBeans, Gear Model MBeans, and Service MBeans and their current states.

To diagnose or correct a problem, you might be directed by My Oracle Support to search for or change information in the domain model. Use the following procedures to complete this task:

Logging Into the Domain Model

Procedure for getting access to the domain model.

In the web browser, navigate to the following:

On the Enterprise Controller's system: https://<hostname>/xvm/

On the Proxy Controller's system: https://<hostname>:21165/xvm/

Searching the Domain Model

Procedure for locating information about assets in the domain model.

The Domain Model Navigator has two tabs: Domain Model/Gear Model page and the JMX Navigator page. Each page contains the definition of assets and some statistics. To locate a specific asset, use the following search tactics:

Match JMX patterns in the name. For example, to search for all cache managers, search for: *:type=*Cach*,*
Use a JMX query:
- PowerOff, which invokes the PoweredOn = false query
- Status Not OK, which invokes the not Status = 'OK' query
- Unreachable, which invokes the Reachable = false query
Create a JMX query. These queries are case-sensitive.

Changing the Domain Model

Lists the operations you can perform on the domain model.

You can perform the following operations. You must provide the root password.

Refresh
Set

WARNING:

An additional operation, Unregister, is available to Oracle Support engineers. Do not attempt to perform this operation unless you are directed by My Oracle Support.

These operations are recorded in the audit log located at /var/cacao/instances/oem-ec/logs/audit-logs.0

Logging Out of the Domain Model Navigator

Procedure for logging out of the domain model securely.

Because you are using the HTTPS protocol, the root credentials are included in each transaction. To log out securely, you must delete the credentials from the browser.

Secure the Agents

Procedure for encrypting the credentials for an Agent Controller.

To encrypt the credentials used to get access to the Agent Controller of an asset:

Check the status of the agent:

/var/opt/sun/xvm/OCDoctor/OCDoctor.sh --update
/var/opt/sun/xvm/OCDoctor/OCDoctor.sh --troubleshoot

Check the prerequisites for encryption and then encrypt the agent password:
```
/var/opt/sun/xvm/OCDoctor/OCDoctor.sh --troubleshoot --fix
```

About Securing the Browsers

Describes a how to make web browsers secure.

To implement transactions securely, Oracle Enterprise Manager Ops Center supports specific communications and security standards and methods such as HTTP, TLS, x.509 certificates, and Java. Most browsers support several of these features but users must configure their browsers properly to take advantage of security capabilities.

Note:

Oracle Enterprise Manager Ops Center does not use any version of SSL. All transactions with the web browser are in TLS. To verify that SSL is not used, use the following command:

openssl s_client -connect IPaddress:port -ssl3

The response includes the status:

SSL routines:SSL3_WRITE_BYTES:ssl handshake failure

Information sent to and from a browser is transmitted in the clear so any intermediate site can read the data and potentially alter it in transit. Oracle Enterprise Manager Ops Center's browsers and servers address this problem in part by using the Secure Sockets Layer to encrypt HTTP transmissions (referred to as HTTP/SSL or HTTPS). This ensures the security of data transmitted from the client to the server. However, because browsers do not ship with client certificates, most HTTPS transmissions are authenticated in only one direction, from server to client. The client does not authenticate itself to the server.

The browser interface uses JavaScript extensively. Take care to protect against JavaScript-based attacks.

About Strong Cipher Encryption

Describes the role of encryption in the product architecture.

When Enterprise Manager Ops Center discovers an asset, it encrypts its transactions with the asset using AES-128 encryption. the strongest AES key available to the asset's platform. The default is AES-256 encryption; the alternatives are AES-192 and then AES-128.

By default, Enterprise Manager Ops Center encrypts its transactions with assets using AES-128 encryption. If an asset's sshd daemon uses a AES-192 or AES-256 encryption, you must also configure the Proxy Controller's system to manage the asset.

Note:

Some locales do not allow the use of strong ciphers. It is the user's responsibility to verify that this level of encryption is allowed under local regulations.

Verifying the Encryption Type

Procedure for determining information about encryption.

To determine the type of encryption used with an asset, view the asset's /etc/ssh/sshd_config file and look for content such as the following in the Ciphers section:

Ciphers aes256-cbc

Configuring Proxy Controllers to Use a Strong Cipher Suite

Procedure for encrypting credentials for a Proxy Controller.

Use the following procedure to download the Java Cryptography Extension (JCE) Unlimited Strength Jurisdiction Policy Files and move them to the systems running a Proxy Controller.

On an Internet-facing system, navigate to http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html.
Click Accept License Agreement.
Click the UnlimitedJCEPolicyJDK7.zip link and download the file.
Unzip the UnlimitedJCEPolicyJDK7.zip file.
Move the local_policy.jar and US_export_policy.jar files to the /usr/jdk/jdk<latest version>/jre/lib/security/ directory on the Proxy Controller.
Restart the system.

Transport Layer Security (TLS)

These sections describe how to increase the level of security provided by the TLS protocol among components of the Oracle Enterprise Manager Ops Center product.

About TLS Versions

The Transport Layer Security protocol provides a foundation for privacy and data integrity between two communicating applications.

The Transport Layer Security protocol now has three versions of increasing security: TLS 1.0, TLS 1.1, and TLS 1.2.

The default version used in Oracle Enterprise Manager Ops Center is TLS 1.0. You can change the version of protocol for all communications if both the communicating application supports the TLS version you want to use. To change the version of protocol for all communications, change the Enterprise Controller’s Glassfish server and each remote Proxy Controller’s Glassfish Serve and change the Apache UCE Container.

Changing the TLS Version for Apache UCE Container

The Transport Layer Security protocol has three versions.

Starting in 12.3.2, the product’s Apache UCE Container supports all three versions of TLS: TLSv1.0, TLSv1.1 and TLSv1.2. Some sites require a higher minimum version. To change the acceptable version of TLS, perform the following procedure on the Enterprise Controller and on each remote Proxy Controller.

Login as root.
Edit the conf/extra/httpd-ssl.conf file.
Locate the line: SSLProtocol -all +TLSv1.2 +TLSv1.1 +TLSv1
To set the protocol to accept only TLS v1.2, change the line to: SSLProtocol -all +TLSv1.2
Restart the Enterprise Controller.
Repeat this procedure on each remote Proxy Controller.

Changing the TLS Version for Glassfish Web Container

The Transport Layer Security protocol has three versions.

Starting in 12.3.2, the product’s Glassfish Web Container supports all three versions of TLS: TLSv1.0, TLSv1.1 and TLSv1.2. The default is TLSv1.0, indicating that Version 1.0 is the minimum accepted level for communication. Some sites require a higher minimum version. To change the acceptable version of TLS, perform the following procedure on the Enterprise Controller and on each remote Proxy Controller.

Note:

Before changing the TLS version used by the Proxy Controller, check if all the Agent Controllers managed by the Proxy Controller can use the TLS version. Agent Controllers that use JDK 6 version lesser than 1.6.115 only supports TLSv1.0.

To see the current minimum version of the TLS protocol, issue the following command:ecadm get-tls-level
TLS configuration : TLSv1.0 enabled, TLSv1.1 enabled, TLSv1.2 enabled
To change the minimum version, use the ecadm set-tls-level -e|--enable 0|1|2 command. The integers refer to the point release of the protocol version, for example, 1 indicates TLSv1.1. To change the minimum version to TLSv1.2, use the following command:
ecadm set-tls-level -e 2

TLS configuration : TLSv1.0 disabled, TLSv1.1 disabled, TLSv1.2 enabled
Repeat this procedure on each remote Proxy Controller.

Viewing the Enterprise Controller's Configuration

Procedure for displaying information about the Enterprise Controller.

To view the Enterprise Controller's configuration:

Select the Enterprise Controller in the Administration section of the Navigation pane.
Click the Configuration tab.
Select one of the following subsystems to display its settings:

Agent Provisioning: Manages the provisioning of Agent Controllers.
Automated Service Requests: Manages the Automated Service Request (ASR) settings.
Database: Manages the database used by Oracle Enterprise Manager Ops Center.
EC Manager: Manages the Enterprise Controller.
Firmware: Manages firmware downloads.
Job Manager: Manages the way that jobs are run.
My Oracle Support (MOS): Manages communications with MOS.
Network/Fabric Manager: Manages networks and fabrics.
OCDoctor: Manages the OCDoctor location and updates.
OS Provisioning: Manages network and fabric settings.
Permission Cache: Manages cache sizes.
Power: Manages energy cost settings.
Proxy Manager: Manages the interactions between the parts of the infrastructure.
Quartz Scheduler: Manages the quartz scheduler.
Role Preferences: Manages role settings.
Update: Manages the location of update libraries.
Zone Controller: Manages the zone management settings.

About Editing the Configuration

Description of the role for changing the configuration..

The Ops Center Admin role is the only role that can modify the configuration properties. Use care in assigning this role to a user.

Note:

Editing configuration properties can have an adverse affect on the stability and performance of the product and is done only if directed by My Oracle Support.

Access to Database Data

Lists the parameters needed to use SQL.

The information in this section is also in Access the Product Database.

This section describes how to view the core product data stored in the Oracle Enterprise Manager Ops Center database using or . Use this information to integrate this product with other applications such as Oracle Enterprise Manager Cloud Control, or to pull data from the Oracle Enterprise Manager Ops Center datastore for analytical applications. To use , you need the following information:

Database host name – The name of the database host is listed in the mgmt.dburl property of the /var/opt/sun/xvm/db.properties file on the Enterprise Controller system. The format for this property is: jdbc:oracle:thin:@<databasehostname>:<listenerPort>/<OracleServiceName>
Read-Only User Name – The Read-Only User name is a schema on the Oracle Enterprise Manager Ops Center Repository that is configured to access Oracle Enterprise Manager Ops Center data using read-only views. When the Enterprise Controller uses an embedded database, the username is OC_RO. When the Enterprise Controller uses a customer-managed database, the schema name is included in the mgmtdb.roappuser property of the /var/opt/sun/xvm/db.properties file.
Read-Only Password – When your Enterprise Controller is configured with the embedded database, the password is randomized at installation. If you do not know the embedded database password, see Changing the Database Credentials for the Read-Only User for information about changing the password. If you are using a customer-managed database and you do not know the password, ask your database administrator for assistance.
Listener Port – The listener port number for the database is listed in the mgmt.dburl property of the /var/opt/sun/xvm/db.properties file on the Enterprise Controller system. The format for this property is: jdbc:oracle:thin:@<databasehostname>:<listenerPort>/<OracleServiceName.
Oracle Service Name – For embedded databases, the service name is OCDB.us.example.com where example is the string oracle. For customer-managed databases, the service name is listed in the mgmt.dburl property of the /var/opt/sun/xvm/db.properties file on the Enterprise Controller system. The format for this property is: jdbc:oracle:thin:@<databasehostname>:<listenerPort>/<OracleServiceName.

Viewing Core Product Data Using Oracle SQL Developer

Procedure for displaying information about the database.

Using Oracle SQL Developer, you can connect to the database using a read-only account and view the schema structures and data.

Modifying Oracle*Net Listener

Procedure for allowing remote access to the embedded database.

To allow an external host to get access to the database, you must modify the Oracle*Net Listener configuration on the Enterprise Controller:

Change to Oracle Enterprise Manager Ops Center's user environment:
```
$ su - oracleoc
```

Edit the sqlnet.ora file:

vi $ORACLE_HOME/network/admin/sqlnet.ora

Disable valid node checking by commenting the following lines:

#tcp.validnode_checking = yes
#tcp.invited_nodes = (localhost,x4150-brm-04)

Save the file and exit.
To use the new version of the file, either restart all services on the Enterprise Controller, or reload the Oracle*Net Listener configuration from the oracleoc user environment.
```
/opt/SUNWxvmoc/bin/satadm stop -w
/opt/SUNWxvmoc/bin/satadm start -w
```
OR
```
$ lsnrctl reload OCLISTENER
```

Opening Oracle*Net to External Access

Procedure for getting access to the embedded database.

If you are using the embedded database, you must open Oracle*Net to enable external access before you can connect to the database.

Log in to the Enterprise Controller system.
Change to the user that owns the Oracle software. For example:
```
$ su - oracleoc
```

Modify the sqlnet.ora file to comment out the two lines beginning with tcp.validnode_checking and tcp.invited_nodes. For example:

$ vi $ORACLE_HOME/network/admin/sqlnet.ora
#tcp.validnode_checking = yes
#tcp.invited_nodes = (localhost,<EnterpriseControllerHostname>)

Use the lsnrctl reload command to reload the listener configuration without stopping the Enterprise Controller services. For example:
```
$ lsnrctl reload OCLISTENER
```

Creating the Connection to the Database

Procedure for configuring access to the database.

You must create a connection to the Enterprise Manager Ops Center database in .

In Oracle SQL Developer, click the New Connection icon in the Connections tab.

Description of the illustration GUID-45C7F44A-6000-4ADA-84CE-D8D9D596BEBF-default.jpg
Enter the connection information, then click Save:
- Connection Name – Enter a name. This name is only used in Oracle SQL Developer.
- Username – Enter the schema name for the read-only user.
- Password – Enter the password for the read-only user.
- Host name – Enter the name of the database host.
- Port – Enter the Oracle*Net Listener port number.
- Service Name – Select the service name option and enter the service name. For embedded databases, the service name is shown in the following figure. For customer-managed databases, the service name is included in the mgmtdb.dburl property in the /var/opt/sun/xvm/db.properties file.
Description of the illustration GUID-7900CAC9-DEE4-45E4-A83F-6751DD9C15D0-default.jpg

Viewing Data From the Database Using Oracle SQL Developer

Procedure for displaying information in the database.

After you create the connection, view product data:

Select the connection you created in the previous procedure. The contents of the target database are displayed.

Description of the illustration GUID-692B0022-4430-49E6-8C5C-1FF115D8A28C-default.jpg
Within the database hierarchy, expand the Other Users section, then select the application user and expand the Views section. If you are using an embedded database, the application user is OC. If you are using a customer-managed database, the application user is included in the mgmtdb.appuser property of the /var/opt/sun/xvm/db.properties file.

The database columns visible to the application user are displayed.

Description of the illustration GUID-29C7B5B7-A0F5-41CA-B90F-D7189192D3EC-default.jpg
View the comment column to find the location of the Javadoc for each column, which explains the usage of the column.

Note:

The SUNWxvmoc-sdk.pkg package, which is included with the product installation media, installs Javadoc. If this package is not installed on your system, use the pkgadd command to install it for Oracle Solaris systems, or the rpm command to install it for Linux systems.

After you get access to the product data, you can integrate the data with other applications, run analytics on the product data, or take other actions that require the data.

Viewing Core Product Data Using SQL*Plus

Procedure for displaying information in the database about assets.

If you have access to the Enterprise Controller system, you can access the database from the command line.

Log in to the Enterprise Controller system.
Run the ecadm sqlplus command. Use the -r option to access the database in read-only mode.

You are connected to the database using the SQL*Plus interface.

Invoke commands using the SQL*Plus syntax.

To see a list of views:

select view_name from user_views where (view_name like 'V_VMB%' or view_name like 'V_VDO%')

To see comments on a specific view:

select comments from user_tab_comments where table_name='<view name from the above list>'

To see comments on all columns of a specific view:

select column_name, comments from user_col_comments where table_name='<view name from the above list>'