Keeping Enterprise Manager Secure

3 Keeping Enterprise Manager Secure

This chapter provides guidelines for keeping Enterprise Manager secure.

This chapter provides instructional guidelines for keeping Enterprise Manager secure.

Guidelines for Secure Infrastructure and Installations

Securing your Oracle Enterprise Manager deployment involves securing all layers of the stack starting with the underlying operating system (OS) on which the OMS and Repository reside all the way up to the Enterprise Manager components themselves. These recommendations will increase overall security as well as prevent certain DoS attacks.

Secure the Infrastructure and Operating System

Harden the machines themselves by removing all unsecure services such as rsh, rlogin, telnet, and rexec on Linux platform (for the list of unsecure services and how to remove them on different platforms, please refer to the CIS benchmarks). It is also recommended to stop non-essential services, this minimizes the ‘attack footprint' of the host and reduces resource consumption by services that are not required, freeing up system resources to deliver the best performance from the OMS.

Restrict OS access by supporting only indirect or impersonation-based access to all Oracle Homes by using utilities such as sudo or PowerBroker. Protect the WebLogic Server Home directory, especially the domain directory which contains configuration files, security files, log files and other Java EE resources for the WebLogic domain. Grant only one OS user who runs WebLogic Server the access privilege to the directory.

Ensure that all the Oracle Homes are patched with the latest CPU (Critical Patch Update). This is a recommended best practice for securing the Oracle Management Service, Repository, Agents and managed targets. Setup your My Oracle Support credentials to detect new Security Alerts and CPUs from the Patch Advisor. With the default Security Recommendations for Oracle Products compliance standard, when a target is missing the latest Security patches, a compliance standard violation will be triggered. In addition, the Secure Configuration for Host should be associated to the hosts of the OMS and Repository. There are additional compliance standards for Database and WLS that can be applied depending on your level of security. Review the Oracle Enterprise Manager Cloud Control Administrator's Guide section on Compliance for more information on available compliance standards and how to associate targets.

The OMS runs on top of the Oracle WebLogic Server. Most of the best practices for securing Oracle WebLogic Server are applicable for securing the OMS as well. Refer to the Oracle Fusion Middleware Securing a Production Environment for Oracle WebLogic Server section Securing Oracle WebLogic Server for additional information.

Ensure that the OMS, Repository and Agent are monitored for filesystem space. The OMS writes a lot of information to log and trace files, and proper space needs to be available for successful operation and troubleshooting. The Agent also relies on filesystem space for log and trace files as well as collecting target metrics.

Best Practices for Securing the Infrastructure and Operating System

Remove unsecure services and stop non-essential services on all infrastructure components
Restrict OS access and protect critical files and directories
Apply latest OS security patches
Adhere to security Compliance Standards and apply latest Oracle CPU patches to all components (OMS, Repository and Agent)
Monitor filesystem space for OMS, Repository and Agent

Securing the Oracle Management Repository

In addition to the above recommendations, steps are necessary to secure the Oracle Management Repository. Since the Oracle Management Repository resides within an Oracle database, a number of the best practices for securing the Oracle database itself are applicable to securing the Repository as well. For best practices on Oracle database security, please refer to the Oracle Database Security Checklist.

The above document also covers certain Operating System level steps that need to be performed to secure the database. Following are additional recommendations to be implemented in the Enterprise Manager deployment.

Enable Advanced Security Option

Enable Advanced Security Option (ASO) between the OMS and Repository to ensure that the data between the OMS and Repository is secure both from confidentiality and integrity standpoints. In addition to the ASO configuration required on the Repository database, you will need to configure the OMS and Agent to connect to a secure Repository database. The detailed instructions for implementing ASO for Enterprise Manager can be found in the Enterprise Manager Security section of the Oracle Enterprise Manager Cloud Control Administrator's Guide.

Please refer to the Oracle Database Advanced Security Administrator's Guide to obtain detailed information about ASO.

Restrict Network Access

Restrict network access to the host on which the Repository resides by putting the repository database behind a firewall and checking network IP addresses. The Listener should be configured to accept requests only from OMS nodes by adding the following parameters into TNS_ADMIN/protocol.ora file:

tcp.validnode_checking =YES
tcp.excluded_nodes = (list of IP addresses)
tcp.invited_nodes = (list of IP addresses), list all OMS nodes here)

The first parameter turns on the feature whereas the latter parameters respectively deny and allow specific client IP addresses from making connections to the Oracle listener. Please refer to the Secure the Network Connection section of the Oracle Database Security Guide for more information.

Audit SYS actions

Audit all SYS (schema) operations at the database level by setting AUDIT_SYS_OPERATIONS = TRUE.

Use the operating system syslog audit trail to minimize the risk that a privileged user, such as a database administrator, can modify or delete audit records stored in an operation system trail if the database version of Repository is 10gR2 or after.

For 10gR2 DB, refer to the Auditing documentation to obtain more information about syslog audit trail.
For 11g DB, set AUDIT_SYS_LEVEL initialization parameter appropriately to use syslog audit trail. Refer to the 11g documentation for details.

Securing User Accounts

Users should log in to the Console with their own individual accounts, and not use the SYSMAN user. SYSMAN is the schema owner and is more privileged than Enterprise Manager Super Administrators. Multiple users should be granted Super Administrator to reduce the need for SYSMAN access. One strong reason for creating multiple Super Administrator accounts is to ensure one user maintains account access in case another user becomes locked out by a dictionary/brute force attack. The Super Administrator privilege should be limited to users who truly need all the permissions that Super Administrator gives them.

In some cases, you may wish to prevent SYSMAN from logging into the console by executing the following SQL statement on the Repository database as the SYSMAN user:

UPDATE MGMT_CREATED_USERS 
SET SYSTEM_USER='-1' 
WHERE user_name='SYSMAN'

After disabling SYSMAN from logging into console, you can enable it by executing:

UPDATE MGMT_CREATED_USERS 
SET SYSTEM_USER='1' 
WHERE user_name='SYSMAN'

Use password profiles to enforce the password control of Enterprise Manager Administrators while Repository-based authentication is used. There is an out-of-box password profile MGMT_ADMIN_USER_PROFILE with the following parameter settings for Enterprise Manager Administrators:

FAILED_LOGIN_ATTEMPTS=10
PASSWORD_LIFE_TIME=180
PASSWORD_REUSE_TIME=UNLIMITED
PASSWORD_REUSE_MAX=UNLIMITED
PASSWORD_LOCK_TIME=1
PASSWORD_GRACE_TIME=7
PASSWORD_VERIFY_FUNCTION=MGMT_PASS_VERIFY

The out-of-box password verification function MGMT_PASS_VERIFY will ensure that the password cannot be same as username, its minimum length is 8, and it must have at least one alphabet, digit and punctuation character. You can create customized password profiles with different values to meet your special requirements, for example, a new password verification function to meet a stricter password complexity requirement.

Change SYSMAN and MGMT_VIEW users' password on a regular basis using only the method documented in the Security section of the Oracle Enterprise Manager Cloud Control Administrator's Guide. The documented command (update_db_password()) helps you change the SYSMAN related passwords in the OMS and in the repository database. If you do not execute this command properly, the OMS may fail to start due to inconsistent passwords for one of the many accounts. You will be prompted for the old and new SYSMAN passwords.

When changing the MGMT_VIEW password, you can select “-auto_generate" to generate a random password that no one will know. The MGMT_VIEW password is used only by the Reporting system and should not be used for login, therefore the auto_generate flag can ensure the password is not known.

To avoid the service interruption due to the lockout of internal users, SYSMAN and MGMT_VIEW users are associated with MGMT_INTERNAL_USER_PROFILE upon install. The password parameters are all set to UNLIMITED. In addition, to avoid sessions hanging or taking a long time due to resource consumption limit, MGMT_INTERNAL_USER_PROFILE's kernel parameters are set to default, which is unlimited as well.

Secure and Backup the Encryption Key

The Encryption Key is the master key that is used to encrypt/decrypt sensitive data, such as passwords and preferred credentials, stored in the Repository. The key itself is originally stored in the Repository and removed automatically once the installation is done. It only needs to be in the Repository during an upgrade. By storing the key separately from the Enterprise Manager schema, we ensure that the sensitive data such as Preferred Credentials remain inaccessible to the schema owner and other SYSDBA users (privileged users who can perform maintenance tasks on the database). Keeping the key outside of the Enterprise Manager schema will ensure that sensitive data remain inaccessible while Repository backups are accessed. Further, the Enterprise Manager schema owner (SYSMAN) should not have access to the OMS Oracle Homes to prevent reading or overwriting the emkey. See the Oracle Enterprise Manager Cloud Control Administrator's Guide for more detailed information about Enterprise Manager's Cryptographic Support and the emkey. Follow the process outlined below to secure the encryption key.

Backup the encryption key to a file by running the following command and keep the encryption file on a separate machine securely, restrict access to only the OMS software owner. If the encryption key is lost or corrupted, the encrypted data in the repository is unusable.

$ emctl config emkey –copy_to_file_from_credstore –emkey_file emkey.ora

The encryption key is required to be in the Repository for some operations such as Enterprise Manager patches and upgrades.

Remove the key from the Repository once the operation is done.

$ emctl config emkey –remove_from_repos

Best Practices for Securing the Oracle Management Repository

Enable Advanced Security Option on the Repository database and configure OMS and Agent
Restrict network access to known targets
Grant Super Administrator privilege to select administrators and do not log in with SYSMAN account
Enable strong password profiles and change application related account passwords regularly
Secure and backup the encryption key

Securing the Oracle Management Agent

For better security during agent installation, agents should be deployed using Enterprise Manager Enterprise Manager's Agent Deploy which uses the secure SSH protocol. When manually deploying Agents, to protect against the possibility of users installing unauthorized agents, use one-time registration passwords that have a reasonable expiry date instead of persistent registration passwords. Registration passwords can be created in the Console or by using the emctl secure setpwd command.

Install the agent as a separate user from OMS installation and support only impersonation based access to this account such as sudo or PowerBroker post installation to prevent unauthorized changes.

Secure Communication

There are several ways to secure the communication between OMS and agent, including firewalls, the OMS secure-lock feature, enabling TLSv1, enabling strong cipher suites and certificates. The following section looks at these in more detail.

Best Practices for Securing the Oracle Management Agent

Utilize the Enterprise Manager Agent Deployment method for Agent installations.
Use a one-time registration passwords with expiry dates
Install the Agent as a separate user from OMS or Targets

Note:

Agents on remote servers need to be installed as a separate OS user of the targets on that server, however, this does not apply to chained Agents. A chained Agent cannot be installed as a separate user because it gets installed along with the OMS.

Enable ICMP

Enterprise Manager uses the industry-standard Internet Control Message Protocol (ICMP) echo request to check status of target host machines if the agent has not uploaded or responded in a timely fashion or at expected intervals. If ICMP is disabled, the target will appear to be down. Firewall should be configured to allow ICMP to prevent false down target alerts.

A Beacon is a target that allows the Management Agent to remotely monitor services. A Beacon can monitor one or more services at any point in time. ICMP and User Datagram Protocol (UDP) are also used to transfer data between Beacon targets that allow an Agent to monitor services and the network components you are monitoring. If there is a firewall or ACL between the Web application components and the Beacons you use to monitor those components, you must configure it to allow ICMP, UDP, and HTTP traffic.

Configure Oracle Management Agent for Firewalls

When the host where the agent resides is protected by a firewall, you need to configure the agent to use a proxy, or configure the firewall to allow incoming communication from the OMS. To configure the firewall you must determine the port assigned to the agent and whether communication is HTTP or HTPS. You can find this information by running emctl status agent.

To configure the proxy set the following properties using the Enterprise Manager Console to edit the Agent properties or emctl setproperty agent and restart the agent. The proxy realm, user and password may not be required in all environments.

$ emctl setproperty agent -name REPOSITORY_PROXYHOST -value test01.example.com 
$ emctl setproperty agent -name REPOSITORY_PROXYPORT -value 80 
$ emctl setproperty agent -name REPOSITORY_PROXYREALM –value <value if needed> 
$ emctl setproperty agent -name REPOSITORY_PROXYUSER –value <value if needed> 
$ emctl setproperty agent -name REPOSITORY_PROXYPWD –value <value if needed>

Configure Oracle Management Service for Firewalls

In cases where the Oracle Management Service is behind a firewall, configurations will be needed to allow proxy communications to the agents or incoming communication through the firewall.

If the agents that are behind the firewall are in different domains, you can configure the proxy to allow communication for those agents and use the dontProxyFor parameter to identify the agents within the firewall. To configure the proxy on the Management Service set the following properties using emctl set property. The proxy realm, user and password may not be required in all environments.

$ emctl set property -name REPOSITORY_PROXYHOST -value test01.example.com 
$ emctl set property -name proxyPort -value 80 
$ emctl set property -name dontProxyFor –value ".example.com"

To configure the firewall to allow inbound communication from the agents for metric uploads, the firewall must be configured to accept HTTP/HTTPS traffic on the upload ports. The default ports are 4889 (HTTP) and 1159 (HTTPS). If your ports were customized you'll need to use those ports.

If there is a firewall between your browser and the Enterprise Manager Console, you must configure firewall to allow the console to receive HTTP/HTTPS traffic over port 7788/7799 (defaults). You can validate your port by looking at the URL you access the Console with.

https://test01.example.com:7799/em

Additional component installations such as JVMD and APD have additional port requirements. Default ports are 9702/9703 (http/https). For more information please see the documentation specific to the component.

To manage the database targets that are configured behind firewalls, you must allow Oracle Net traffic on the listener ports (typically 1521 but often customized). For more information regarding configuring Oracle Databases for firewalls see the Oracle Database 2 Day + Security Guide.

Security Console

The Security Console is available to Super Administrators only and provides all security related configuration information in one location, allowing you to view, analyze, and optimize security for your managed environment. To access the Security Console, from the Setup menu, select Security, and then Security Console.

When the Security Console first displays, it is divided into two main windows, the menu window on the left hand side and the information window on the right hand side.

The Security Console contains both static (text) and dynamic information. The text is to provide quick, high level context to the data, it is not intended as a replacement to your documentation.

The Security Console is categorized into the following security areas:

Overview

The overview section gives a high level description of each of the Security Console categories.

Pluggable Authentication

The Pluggable Authentication section is further divided into two tabs. An "Overview" tab and a "Configuration" tab.

Pluggable Authentication Overview

The Overview section contains text from the documentation, however, it is not meant as a replacement for the documentation. Enterprise Manager Authentication is the process of determining the validity of the user attempting to access Enterprise Manager. The authentication feature is available across the different interfaces such as the Enterprise Manager console and the Enterprise Manager Command Line Interface (EM CLI). Oracle Enterprise Manager 13c relies on the WebLogic Server for external Authentication methods. For this reason, Enterprise Manager 13c can be authenticated using any authentication method supported by Oracle WebLogic Server.

This section also identifies the Authentication schemes supported by Enterprise Manager, for more information please see Security Features, Configuring Authentication.

Pluggable Authentication Configuration

This section displays the current configuration information in your enterprise relating to Authentication.

Authentication Configuration

Authentication Mode: This parameter provides information on the various pluggable authentication schemes configured in your Enterprise Manager environment.

External User Support Enabled: Displays if you have external user authentication enabled. If using any authentication other than "repository" authentication, this will display "yes".

Auto-provisioning supported: The status of auto-provisioning is also displayed. Auto-provisioning allows for an externally authenticated user to log into Enterprise Manager without being preconfigured within Enterprise Manager and the information is transferred from the authentication application. It requires that the OMS property oracle.sysman.core.security.auth.autoprovisioning be set. For more information please see Security Features, External Authorization using External Roles.

Password Profile

When creating an Administrator (Setup->Security->Administrators menu) you enter the type of password profile you want that user to use during login. This table gives a count of the number of users in Enterprise Manager which have been assigned the various password profiles. For more information on password profiles see Securing User Accounts.

Fine-grained Access Control

Enterprise Manager implements granular privileges to control access to targets, and other resources, allowing administrators to better segregate their duties. For example, consider the provisioning designer and provisioning operator job responsibilities. The former has greater responsibilities (creates components in the Software Library) than the latter (submits deployments). Fine-grained access control explains the privileges and roles and how they serve to provide various levels of access control to different applications, groups, services and targets within Enterprise Manager. Information about the Administrators last login to the system, their number of privileges and roles granted and recommendations on best practices relating to appropriate usage of roles and privileges can be found in this section.

The Fine-grained Access Control area is divided into five tabs, An Overview, Administrators tab, Privileges tab, Roles tab and Privilege Propagation Aggregates tab.

Overview

Giving the same level of access to all systems to all administrators is dangerous, but individually granting access to tens, hundreds, or even thousands of targets to every new member of the group is time consuming. With Enterprise Manager's administrator privileges and roles feature, this task can be performed within seconds, instead of hours. Authorization controls the access to the secure resources managed by Enterprise Manager via system, target, and object level privileges and roles.

This section describes Enterprise Manager's Authorization model including user classes, roles, and privileges assigned to each user class. The following topics are described:

Classes of Users
Privileges and Roles

Classes of Users

Oracle Enterprise Manager supports different classes of Oracle users, depending upon the environment you are managing and the context in which you are using Oracle Enterprise Manager. There are three administrator access categories:

Super Administrator: Powerful Enterprise Manager administrator with full access privileges to all targets and administrator accounts within the Enterprise Manager environment. The Super Administrator, SYSMAN is created by default when Enterprise Manager is installed.The super administrator account can manage all other administrator accounts and set up all administrator credentials. The super administrator can:
- Create Enterprise Manager privileges and roles
- Perform the initial setup of Enterprise Manager, for example, defining e-mail configurations and defining global notifications rules
- Add targets to Enterprise Manager
- Perform any action on any target in the system
Administrator Regular Enterprise Manager administrator.
Repository Owner Database administrator for the Management Repository. This account cannot be modified, duplicated, or deleted.

Privileges and Roles

User privileges provide a basic level of security in Enterprise Manager. Privileges can be divided into two categories: Target Privileges and Resource Privileges

A role is a collection of Enterprise Manager resource privileges, or target privileges, or both, which you can grant to administrators or to other roles. These roles can be based upon geographic location (for example, a role for Canadian administrators to manage Canadian systems), line of business (for example, a role for administrators of the human resource systems or the sales systems), or any other model.

Out-of-Box Roles

Enterprise Manager Cloud Control 13c comes with predefined roles to manage a wide variety of resource and target types.
External Roles

Enterprise Manager Cloud Control 13c can be integrated with external authorization source like Active Directory by defining External roles.
Private Role
- Secure privileges like FULL_CREDENTIAL,FULL_JOB etc which are not granted to Super Administrators by default, can be granted to a private role.
- Private roles can not be converted into System Roles. Creator of a private role handles the life cycle of it.
- Private roles can be granted to administrators 'WITH_ADMIN' option from Enterprise Manage command line interface (EMCLI) which will enable administrators to grantor revoke private roles to/from other administrators.

Fine-grained Access Control Administrators

This lists all the Administrators current created in Enterprise Manager, and also lists the date and time in which they last logged in.

Fine-grained Access Control Privileges

This lists the top five administrators with the number of privileges directly granted to them. Administrators with high numbers of privileges indicate an inefficient use of privileges and should be directed to use roles instead. It is recommended that an Administrator be granted the minimum number of privileges necessary to perform their task. For more information on privileges and roles, see section 2.2.3, "Managing Privileges with Privilege Propagating Groups".

This section also displays all the Target and Resource Privileges available in Enterprise Manager, whether the privilege can be applied to a single target, a specific target, a target type and if that privilege contains another privilege.

Fine-grained Access Control Roles

This section allows us to view the top 5 Administrators with the Highest Number of Roles, if the number of role grants is high, it points to an inefficient role hierarchy, suggesting that roles could be combined for efficient manageability.

Roles with the Highest Number of Nested Roles can also be displayed here.

Fine-grained Access Control Privilege Propagation in Aggregates

An aggregate target is a target that consists of one or more member targets, such as groups and systems. Enterprise Manager support two type of aggregate targets based on privilege propagation mechanism:

Normal aggregate target - If any privilege is granted on aggregate target, only view privilege will be propagated to its members
Privilege Propagating aggregate target - If any privilege is granted on aggregate target then the same privilege will be propagated to its members

The following features are supported in case of target privileges on Aggregate Targets:

Separation between the privilege grants on aggregate target and its members
Along with the default existing behavior of propagating the same privilege on members, User can choose to have one privilege grant on aggregate target and another on its members.User can also choose to have no privilege on members.
In case of non privilege propagating aggregate targets by default only view will be granted to the members where as in case of privilege propagating aggregate targets whatever privilege is specified by the administrator that will be granted appropriately.
This feature is available from User and Role management pages as well as Target Access Page in the user interface.On these pages click on "Advanced Privilege Settings" button on top of Target Privileges table to see the advanced privileges in the table.
EM CLI support is also available for this new feature.Please check EM CLI help for existing relevant verbs for more details on the usage.

Consider the following snapshot of the target privileges for a given administrator:

Privileges listed under column “Manage Target Privilege Grants" are applicable to the Group as well as the members.
Privileges listed under column “Manage Aggregate Only Privilege Grants" are applicable only on the Group.
Privileges listed under column “Manage Member Only Privilege Grants" are applicable only on the members.

In the following example PPG_DB_group1 is a privilege propagating group of database targets. PPG_HOST_group2 is a privilege propagating group of host targets. NORMAL_group1 is a non-privilege propagating group.

Table 3-1 Target Privileges and Privilege Propagation

Name	Type	Manage Target Privilege Grants	Manage Aggregate Only Privilege Grants	Manage Member Only Privilege Grants
PPG_DB_group1	Group	View	Configure Target	Blackout Target
PPG_HOST_group2	Group	None	Configure Target	None
NORMAL_group1	Group	None	Blackout Target	View
NORMAL_group1	Host	Host	Not Applicable	Not Applicable

Consider the first row in the above table. This configuration means that the given user has View privilege on group PPG_group1 as well as the members. Along with that it has Configure Target privilege only on the group PPG_group1 and Blackout Target privilege only on members. This means that the current user in the picture can create Blackout on the members of group PPG_group1 but cannot do so on the group itself and it can configure PPG_group1 but cannot configure the members. The user has View on group as well as the members.
Consider the second row.PPG_HOST_group2 is a privilege propagating group. This configuration means that the given user has Configure Target privilege only on the group PPG_group2 and it does not have even View on members.
In the third row one can see a non privilege propagating group where the user is having Blackout Target privilege on the group and View privilege on the members.
Note that the two new advanced privileges column values are not applicable in case of non aggregate target like host target.

Note that the above mentioned feature is applicable to all Aggregate Targets in general. The above example shows one of Aggregate Target type (Group).

Secure Communication

This section provides a high-level overview of Secure Communication terms and protocols used within Enterprise Manager. You can also view the current status of secured Enterprise Manager components, their certificate issuers, and details.

Secure Communication Overview

Enterprise Manager Framework Security implements the following types of secure connections between the Enterprise Manager components:

HTTPS and Public Key Infrastructure (PKI) components, including signed digital certificates, for communications between the Management Service and the Management Agents.
Oracle Advanced Security for communications between the Management Service and the Management Repository.

Enabling Security for the Oracle Management Service

To enable Enterprise Manager Framework Security for the Management Service, you use the emctl secure oms utility, performs the following actions:

Generates a Root Key within your Management Repository. The Root Key is used during distribution of Oracle Wallets containing unique digital certificates for your Management Agents.
Modifies your WebTier to enable HTTPS channel between your Management Service and Management Agent.
Enables your Management Service to accept requests from Management Agents using Enterprise Manager Framework Security.

Securing the Oracle Management Agent

When you install the Management Agent on a host, you must identify the Management Service that will be used by the Management Agent. To enable Enterprise Manager Framework Security for the Management Agent, use the emctl secure agent utility.

Restricting HTTP Access to the Management Service

It is important that only secure Management Agent installations that use the Management Service HTTPS channel are able to upload data to your Management Repository and Cloud Control console is accessible via HTTPS only.

Managing Agent Registration Passwords

Enterprise Manager uses the Agent Registration password to validate that installations of Oracle Management Agents are authorized to load their data into the Oracle Management Service.

The Agent Registration password is created during installation when security is enabled for the Oracle Management Service. You can add/edit/delete registration passwords directly from the Enterprise Manager console.

Enabling Security for the Management Repository Database

You enable security for the Management Repository by using Oracle Advanced Security.

Secure Communication Current Configuration

Agent Certificate Details: Displays secured agents along with their certificate details, including the algorithm, its strength, when it was created, when it expires and when the agent was secured.

Number of Unsecured Agents: Indicates the number of Agents in your enterprise that are currently operating unsecured.

Number of Expired Registration Passwords: Indicates the number of Agents which have stopped running due to an expired certificate.

Certificate Authority Details: Lists the certificates being used in your Enterprise Manager installation.

OMS Secure Configuration: Details the Enterprise Manager configuration and communication with the Management Services and indicates the secure configuration details of each, including the console and upload certificate details along with the SLB details.

Database Encryption Configuration

Following are the configuration details about encryption between the OMS and Management Repository/Target Database. The list of encryption algorithms and the checksum algorithms that the client supports are mentioned below. For more details refer to the section "Enabling Security for the Management Repository Database" above.

Encryption Algorithms Supported: Lists all the encryption algorithm details supported.
Encryption Algorithm In Use: Lists the current Algorithm being used.
Checksum Algorithm Supported: Lists the check-up Algorithm currently supported (Only SHA(x) is supported).
Checksum Algorithm in use: Lists the Algorithm currently in use.

Credentials Management

Credentials like user names and passwords are typically required to access targets such as databases, application servers, and hosts. Credentials are encrypted and stored in Enterprise Manager. Beginning with Enterprise Manager 13c, the credential subsystem supports, in addition to basic username-password, strong authentication schemes such as PKI, SSH keys and Kerberos. SSH key based host authentication, used by jobs, deployment procedures and other Enterprise Manger subsystems, is now supported.

By using appropriate credentials, you can:

Collect metrics in the background as well as real-time
Perform jobs such as backup, patching, and cloning
Perform real-time target administration such as start, and stop
Connect to My Oracle Support

Based on their usage, credentials can be classified into the following categories:

Named Credentials
Monitoring Credentials
Preferred Credentials

Credentials Management Current Configuration

Encryption Key: The Encryption Key is the master key that is used to encrypt/decrypt sensitive data, such as passwords and preferred credentials that are stored in the Repository. The key is originally stored in the Repository and is removed from the Repository and copied to the Fusion Middleware managed Credential Store during installation of the first OMS.

Credentials Management Usage Statistics

The Usage Statistics tab provides credential usage information.

Comprehensive Auditing

Comprehensive Auditing shows the current auditable operations and whether they have been configured for external backup to disk. Statistics on the top five most used operations are also displayed, as well as the most active Administrators.

All operations performed by Enterprise Manager administrators, such as creating users, granting privileges, starting a remote job like patching or cloning, need to be audited to ensure compliance with the contracted internal controls of a service organization.

Non-repudiation is the central tenet of auditing. Enterprise Manager Comprehensive auditing provides a tamper-free audit trial of all critical operations.

From the Usage tab, you can view:

Current Auditing Configuration
Specific Audit Operations
Audit Usage Statistics (Top 5 Operations in the last 7 days and Top 5 Administrators in the last 7 days)

Active User Session Count

Active User Session Count shows information related to the session management, such as session timeout, max and active sessions per user count.

All authenticated open user sessions can be viewed from this area.

From the Active User Session Count area, you can view:

Session Settings (Session Timeout, Maximum Number of Sessions Allowed Per User, Permitted Number of Active Sessions )
Active Sessions

Best Practices Analysis

Based on observations of information in the above categories, best practices advice is indicated in this section and covers areas such as management of the repository encryption key and auditing operations management. You can quickly view Enterprise Manager security configuration adherence to recommended Oracle security protocols. In addition, suggested best practices are provided based on the specifics of your Enterprise Manager environment.

From the Best Practices Analysis area, you can view:

Pluggable Authentication: Best practice advice tailored to the pluggable authentication scheme of your environment.
Fine-grained Access Control: Best practice advice pertaining to role and privilege management.
Secure Communication: Best practices regarding secure communication between the Management Service, Agent, and Enterprise Manager console.

Guidelines for SSL Communication

This section covers the following SSL Guidelines:

Ensure TLSv1.2 Protocol is Enabled

Transport Layer Security (TLS) is a cryptographic protocol used to increase security over computer networks by providing communication privacy and data integrity between applications. Although it is technically the successor of SSL, TLS is generically referred to as SSL. Beginning with Enterprise Manager 13c, TLSv1.2 is enabled by default.

In the case of Enterprise Manager, these secure communication channels are between various components of the Enterprise Manager framework. For Enterprise Manager 13c, the TLSv1.2 protocol is supported on the infrastructure communication channels including:

Oracle Management Services to 13c Agent
13c Agent to Agent
EMCLI to Oracle Management Services
Browser to Admin Server/Managed Server Console
Oracle Management Services to Server Load Balancer
13c Agent to Always-On Monitoring Application
Oracle Management Services to My Oracle Support
13c Agent to Fusion Middleware Target
Oracle Management Services to Fusion Middleware Target

Enabling Oracle Management Service to Database Communication on TLS1.2

You can also configure TLSv1.2 communication channels between the OMS and target databases, which include the Enterprise Manager Management Repository.

For specific instructions on enabling TLSv1.2 communication between the Oracle Management Service and the Management Repository, see Configure TLSv1.2 for Communication with the Enterprise Manager Repository.
For information on configuring TLSv1.2 communication with target Oracle databases, see Secured Communication (TCPS) Access to Databases.

Enabling Always-On Monitoring Communication on TLS1.2

The Always-On Monitoring application provides the ability to monitor critical target status and metric alerts when the Oracle Management Service is unavailable. The service continuously monitors critical targets through the Enterprise Manager Agent and can be easily configured to send email notifications for these events to administrators. For information on configuring TLSv1.2 for communication between the Always-On Monitoring (AOM) application and AOM Repository, and between the AOM application and Enterprise Manager Repository, refer to Configuring the Always-On Monitoring Application for Secure Communication Using the TLSv1.2 Protocol in the Enterprise Manager Administrator’s Guide.

Locking Down the Oracle Management Service to Use the TLSv1.2 Protocol Only

In order to restrict Oracle Management Services communication to use the TLSv1.2 protocol only:

Stop the Oracle Management Services. From the command line, run the following:

<OMS_ORACLE_HOME>/bin/emctl stop oms
Set the OMS communication protocol: From the command line, run the following:

<OMS_ORACLE_HOME>/bin/emctl secure oms -protocol TLSv1.2
Enter the following command to restart the OMS:

$ emctl start oms

Enabling TLS in Mixed Version Environments

If you are installing a Enterprise Manager Cloud Control 13c for the very first time, all of the aforementioned communication channels will use TLSv1.2 by default. If you have an existing Enterprise Manager deployment and you want to enable TLS, you need to be aware that older Agents do not support TLSv1.2..

If there are 12c Agents in the environment which are not yet upgraded to 13c, the communication between the Agent and Oracle Management Service will default to SSL. To configure a 12c Agent to support only TLS v1.0 protocol while the Agent listens as a server, edit the Agent properties in the Enterprise Manager console or run emctl setproperty at the command line. For example:

$ emctl setproperty agent -name allowTLSOnly -value true

To edit multiple Agents simultaneously, from the Setup menu, choose Manage Cloud Control and then Agents. From the list, select the Agents you want to modify and then click Properties. This will create a job definition where you specify the Agent property that needs to be changed. On the Parameters page, set the minimumTLSVersion property to TLSv1.2. The change will be applied to all selected Agents.

Once the changes have been made, you must bounce the Management Agent(s) in order for the changes to take effect.

Leave Communication in Secure-Lock Mode

Secure and Lock the OMS and Agents

The Oracle Management Service and Oracle Management Agents can run in non-secure (HTTP) or secure (HTTPS) modes. The recommendation is to always use secure mode, hence the default installation will automatically secure-lock the OMS. The secure-lock mode takes security one step further in requiring that agents communicate only through HTTPS port (HTTP port is locked). This ensures that the OMS-Agent communication is always encrypted and mutually authenticated. All requests from un-secure agents are rejected by the OMS. Similarly, any un-secure request from the OMS is rejected by the agent. This helps safeguard the management system from any malicious ‘man-in-the-middle' attack happening from within the infrastructure.

If your installation was done before Oracle Enterprise Manager 10g Release 5, you may be required to secure-lock your OMS manually. In the case of upgrades, if the pre-upgrade environment is secured, the upgrade retains the secure mode but does not secure-lock the OMS. If the pre-upgrade environment is already secure-locked, the upgrade retains the secure-lock mode between OMS and Agent.

To check the secure status of the OMS and secure-lock the communication between OMS and agent run the command and restart the OMS:

$ emctl status oms –details 
Oracle Enterprise Manager Cloud Control 13c Release 12.1.0.3.0 
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. 
Enter Enterprise Manager Root (SYSMAN) Password : 
Console Server Host : test01.example.com 
HTTP Console Port : 7790 
HTTPS Console Port : 7803 
HTTP Upload Port : 4890 
HTTPS Upload Port : 4904 
OMS is not configured with SLB or virtual hostname 
Agent Upload is locked. 
OMS Console is locked. 
Active CA ID: 1 
Console URL: https://test01.example.com:7803/em 
Upload URL: https://test01.example.com:4904/empbs/upload 
…

$ emctl secure lock –upload 
Oracle Enterprise Manager Cloud Control 13c Release 12.1.0.3.0 
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. 
Enter Enterprise Manager Root (SYSMAN) Password : 
Agent Upload is locked. Agents must be secure and upload over HTTPS port. Restart OMS.

Note that once OMSs are running in secure-lock mode, unsecure agents will not able to upload any data to the OMSs. To check the status and secure the agent issue the following, you will be prompted for the registration password:

$ emctl status agent –secure 
Oracle Enterprise Manager 13c Cloud Control 12.1.0.1.0 
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. 
Checking the security status of the Agent at location set in <AGENT_LOCATION>/em12/agent/agent_inst/sysman/config/emd.properties... Done. 
Agent is secure at HTTPS Port 3872. 
Checking the security status of the OMS at https://test01.example.com:4904/empbs/upload/... Done. 
OMS is secure on HTTPS Port 4904

$ emctl secure agent 
Oracle Enterprise Manager 13c Cloud Control 12.1.0.1.0 
Copyright (c) 1996, 2013 Oracle Corporation. All rights reserved. 
Agent successfully stopped... Done. 
Securing agent... Started. 
Enter Agent Registration Password : 
Agent successfully restarted... Done. 
EMD gensudoprops completed successfully 
Securing agent... Successful.

To ensure the console access from the client browser is secure over SSL/TSL, the console must be locked as well. From Oracle Enterprise Manager 10g Release 5 installations are secure-locked by default. In the case of upgrades, if the pre-upgrade environment is not secure-locked, after the upgrade you need to run the following command to secure-lock the console access:

$ emctl secure lock –console

Modify Cipher Configuration if Required

A cipher suite is a combination of cryptographic parameters that define the security algorithms and key sizes used for authentication, key agreement, encryption, and integrity protection. Cipher suites protect the integrity of a communication. For example, the cipher suite called SSL_RSA_WITH_AES_128_CBC_SHA uses RSA for key exchange, AES with a 128-bit key, CBC, and SHA for bulk encryption. A cipher suite is a combination of cryptographic parameters that define the security algorithms and key sizes used for authentication, key agreement, encryption, and integrity protection. Cipher suites protect the integrity of a communication. For example, the cipher suite called SSL_RSA_WITH_AES_128_CBC_SHA uses RSA for key exchange, AES with a 128-bit key, CBC, and SHA for bulk encryption.

In Enterprise Manager, ciphers are configured for the following end points:

Oracle Management Services (OMS) Console end point
OMS Upload end point
Agent end point
WebLogic end point

Ciphers Supported for OMS Console and Upload End Points

Ciphers supported for OMS Console and Upload end points depends on the ciphers supported and exposed by Oracle HTTP Server (OHS), the web server front-ending the OMS server. The ciphers supported by the OHS web server is listed in Table 1: Cipher Suites Supported in the OMS Console and Upload End Points,

A subset of the OHS-supported ciphers are set as default in the configuration files available within the EMGC_DOMAIN home and is used for OMS Console and Upload end points. The default set of OHS-supported ciphers used for the OMS Console and Upload end points are listed in the table Table 3-2.

In order to modify the default cipher suites for OMS Console end points, edit the SSLCipherSuite property in the following ssl.conf file and add/modify from the list of OHS-supported ciphers list.

For a typical multi-OMS scenario:

Modify the following file on the primary OMS server:

<WEBTIER_INSTANCE_HOME>/user_projects/domains/EMGC_DOMAIN/config/fmwconfig/components/OHS/ohs1/ssl.conf
Modify the following file on each of the additional OMS servers:

<WEBTIER_INSTANCE_HOME>/user_projects/domains/EMGC_DOMAIN/config/fmwconfig/components/OHS/instance/ohs1/ssl.conf.emctl_secure

In order to modify the default cipher suites for the Upload end point, edit the SSLCipherSuite property in the following httpd_em.conf file and add/modify from the list of OHS supported ciphers.

For a typical multi-OMS scenario,

Modify the following file on primary OMS server:

<WEBTIER_INSTANCE_HOME>/user_projects/domains/EMGC_DOMAIN/config/fmwconfig/components/OHS/ohs1/moduleconf/httpd_em.conf
Modify the following file on each additional OMS server:

<WEBTIER_INSTANCE_HOME>/user_projects/domains/EMGC_DOMAIN/config/fmwconfig/components/OHS/instance/ohs1/moduleconf/httpd_em.conf.emctl_secure

Any modification of cipher suites for the OMS console and Upload end points requires a restart of the OMS, including the Admin server.

Table 3-2 Cipher Suites Supported in the OMS Console and Upload End Points

OHS Supported Cipher Suites	OMS Default: Console	OMS Default: Upload
SSL_RSA_WITH_AES_128_CBC_SHA	No	Yes
RSA_WITH_AES_128_CBC_SHA256	No	Yes
SSL_RSA_WITH_AES_256_CBC_SHA	No	Yes
RSA_WITH_AES_256_CBC_SHA256	No	Yes
ECDHE_RSA_WITH_AES_128_CBC_SHA	No	Yes
ECDHE_RSA_WITH_AES_256_CBC_SHA	No	Yes
RSA_WITH_AES_128_GCM_SHA256	No	Yes
RSA_WITH_AES_256_GCM_SHA384	No	Yes

Ciphers Supported for Agent End Points

Ciphers supported for Agent EMD_URL / end points ( if it is enabled in Agent’s JDK) are listed in Table 2. A subset of these supported ciphers are set as defaults on the agent end points. The table also shows which ciphers for the Agent EMD_URL /end point are enabled by default.

In order to override the default cipher suites used by the agent , edit the SSLCipherSuites property in emd.properties to include the ciphers from the list of supported ones. Optionally, you can use the setproperty command as follows:

$ emctl setproperty agent -name SSLCipherSuites -value <values>

Table 3-3 Cipher Suites Supported on the Agent End Point

Supported Cipher Suites	Agent Default
RSA_WITH_AES_128_CBC_SHA	Yes
RSA_WITH_AES_128_CBC_SHA256	Yes
RSA_WITH_AES_256_CBC_SHA	No
RSA_WITH_AES_256_CBC_SHA256	Yes
ECDHE_RSA_WITH_AES_128_CBC_SHA	No
ECDHE_RSA_WITH_AES_128_CBC_SHA256	Yes
ECDHE_RSA_WITH_AES_256_CBC_SHA	No
ECDHE_RSA_WITH_AES_256_CBC_SHA384	Yes
DHE_RSA_WITH_AES_128_CBC_SHA	No
DHE_RSA_WITH_AES_128_CBC_SHA256	Yes
DHE_RSA_WITH_AES_256_CBC_SHA	No
DHE_RSA_WITH_AES_256_CBC_SHA256	Yes

Notes:

AES_256 ciphers will only work if the Agent JKS has unlimited strength policy file corresponding to the Agent Java version currently installed on the system. For instance, 13.2 agents using Java 7,download unlimited strength policy file from http://www.oracle.com/technetwork/java/javase/downloads/jce-7-download-432124.html. Unzip and copy local_policy.jar & US_export_policy.jar in to <agent_base_directory>/agent_13.2.0.0.0/oracle_common/jdk/jre/lib/security.
All cipher suites using SHA256 & above will only work for TLS1.2. See Ensure TLSv1.2 Protocol is Enabledfor information on making sure the end point is configured on TLS1.2.
For SSL handshake to happen on a particular cipher suite, it should be enabled on both client and server. For example, if the communication from agent to OMS Server should happen on 'ECDHE_RSA_WITH_AES_128_CBC_SHA' cipher suite, then this cipher suite should be configured on both agent (client) and OMS Upload end point(server).

Ciphers Supported for WebLogic End Points

WebLogic end point uses the ciphers provided by the underlying JDK by default. In order to change the default ciphers, refer to the official guide on Fusion Middleware Administering Security for Oracle WebLogic Server 12.1.3.

Third Party Certificates

Use a certificate from well-known Certificate Authority (CA) to secure OMS-Agent communication and console access to take advantage of the well-known trusted certificates with different expiry and key size.

Oracle Wallets

Oracle has introduced the concept of a wallet, which is a password-protected container used to store authentication and signing credentials, including private keys, certificates, and trusted certificates needed by SSL.

To secure the console using a custom certificate authority, you need to create a wallet location and secure the console against that wallet location. For more information on creating a wallet, see the Oracle Fusion Middleware Administrator's Guide.

Creating an Oracle Wallet

The following example shows you how to create and add a certificate to an Oracle wallet.

Create the wallet container:

Note:

Currently, only single sign-on (SSO) wallets are supported.

S /u01/app/oracle/middleware/oracle_common/bin/orapki wallet create -wallet /home/oracle/labs/mywallet -auto_login_only

Add a certificate to the wallet: When creating the wallet you must specify the Common Name (CN) as the hostname of the machine where the OMS is installed or the SLB name, if the OMS is behind an SLB. In this example, the OMS is behind an SLB, test.example.com.
```
S /u01/app/oracle/middleware/oracle_common/bin/orapki wallet add -wallet /home/oracle/labs/mywallet -dn 'CN=test.example.com, OU=Oracle, O=Oracle University, L=Boise, ST=ID, C=US' -keysize 2048 -self_signed -validity 3650 -auto_login_only
```
Set the required environment variables for the existing Weblogic domain. They must be set before using orapkiles:
```
 $ . setDomainEnv.sh
```

View the certificates in the wallet:

S /u01/app/oracle/middleware/oracle_common/bin/orapki wallet display -wallet /home/oracle/labs/mywallet

Best Practices for Securing Communication

Here is a summary of the best practices for securing communication:

• Enable ICMP for ping check validation

• Configure firewalls as appropriate in your environment

• Secure and lock the OMS and Agents

• Configure strong cipher suites for the OMS and Agent

• Secure upload and console virtual HTTPS hosts with third party certificates

Guidelines for Authentication

Enable External Authentication

Enterprise Manager Cloud Control 13c offers multiple methods of authentication. In addition to the predefined methods, a customized provider/module can be plugged in to Cloud Control authentication. The default system authentication method is the standard Repository based authentication. Additional predefined methods include:

Oracle Single Sign-On (OSSO)
Enterprise User Security (EUS)
Integration with Oracle Access Manager Single Sign-On (OAM SSO)
Direct LDAP integration (Oracle Internet Directory, Microsoft Active Directory)
Security Assertion Markup Language (SAML)

Refer to "Configuring Authentication" for detailed information about how to configure Enterprise Manager to use the pre-defined providers.

Using one of the extended authentication modules enables you to take advantage of centralized identity management across the enterprise. Doing this allows you to rely on the external identity management system for password security compliance, password changes and resets. To create a user in Enterprise Manager with external authentication, you select the “external" flag upon creation. During creation of every new user in Enterprise Manager you are prompted for that users mode of Authentication, via an external Identity store such as Oracle Access Manager (OAM), LDAP or Oracle Internet Directory (OID), or internally via Enterprise Manager Repository.

When the account is deleted from the identity management system, it will no longer authenticate in Enterprise Manager but still needs to be manually removed. Ideally, a script or job could be run to remove the user from Enterprise Manager once removed from the identity management system.

When using external Authentication, Enterprise Manager allows the creation of external roles which map to the identity management systems groups by name (i.e. Enterprise Manager role “DBA" maps to LDAP group “DBA"). Thus allowing synchronized user access and privileges based on external group membership.

Target authentication provides access to the host, database or application targets managed through Enterprise Manager. Using strong target authentication methods, named credentials and configuring database password profiles are a few ways to ensure secure target authentication.

To ensure target authentication security, choose strong host and database authentication methods. Credentials for target access are encrypted and stored in Enterprise Manager. With Enterprise Manager Cloud Control 13c, strong authentication such as SSH-keys for host and Kerberos tickets for database are now supported. These credentials can be used by jobs, deployment procedures and other subsystems.

Best Practices for Authentication

Integrate with corporate identity management system for enterprise wide authentication
Use external roles to automatically assign privileges to users based on external group membership
Automate user creation/deletion based on external group membership using EMCLI
Utilize strong authentication methods (SSH for host, Kerberos for database)
For local accounts set up password policies

Guidelines for Authorization

Authorization is the act of validating the privileges and permissions of an authenticated subject. To avoid exploiting authorization, you must implement a policy of segregation of duties. This means no one person should be given responsibility for more than one related function.

Enterprise Manager users may vary widely among a company, and they may have very different roles and purposes.

Enterprise Manager 13c comes with several out-of-the-box roles that provide role based authentication for various operational roles. Segregation of Operator, Designer and Administrator functions for Patching, Provisioning, Cloud, Compliance, and Plug-ins allow more granular authentication for users. Use the Create Like feature to further enhance or restrict as required for your operations.

Note:

Performing a Create Like operation on an existing role enables the newly created role to contain all of the privileges of the original role.

With using Role Based Access Control (RBAC), privilege management becomes easier; managing role grants is simpler than managing privilege grants. For a complete list of the out-of-the-box roles see the Privileges and Roles section of the Oracle Enterprise Manager Cloud Control Administrator's Guide.

With Enterprise Manager 13c we have the ability to specify target privileges and resource privileges. Target privileges allow an administrator to perform operations on a target. Some of the new target privileges include Connect to any Viewable Target, Execute Command Anywhere, Execute Command as any Agent and more. The target privileges can be assigned for all targets or for specific targets. Resource privileges grant access to a function, button or page within Enterprise Manager. Some of the new resource privileges include Backup Configurations, Cloud Policy, Compliance Framework, Enterprise Manager Plug-in, Job System, Patch Plan, Self Update and Template Collection. For a complete list, see "Configuring Privileges and Role Authorization". With these new privileges, it's much easier to implement the Principal of Least Privilege by creating specific roles with very fine grained privileges assigned that match the job duties.

An extended auditing system makes it easy to monitor the privilege grants on a regular basis and also keep track of which users exercised what privileges. Some of the key privilege related auditable actions are listed here:

Grant job privilege
Grant privilege
Grant role
Grant target privilege
Grant system privilege
Revoke job privilege
Revoke privilege
Revoke role
Revoke target privilege
Revoke system privilege

Super Administrators have special privileges on targets, reports, templates and jobs. See the Classes of Users for more details. The Super Administrator privilege should be granted with caution. Use the following query to get the list of Super Administrators:

SELECT grantee FROM MGMT_PRIV_GRANTS WHERE PRIV_NAME = ‘SUPER_USER'

Best Practices for Privilege and Role Management

Create meaningful roles and grant roles to users instead of granting privileges to users.
Grant only the minimum set of privileges a user needs for carrying out his/her responsibilities by granting the fine-grained privileges/roles only when needed.
Audit privilege and role actions for complete monitoring and accountability.
Limit the number of Super Administrators

Use Principle of Least Privileges for Defining Roles/Privileges

The fine granularity of privileges provided in Enterprise Manager allows for the Principle of Least Privileges to be implemented, this recommends that an Administrator must only be able to access the information or resources that are necessary for legitimate purposes.

Use Privilege Propagation Groups

Using groups and systems to organize your targets helps reduce security administration overhead. There are two types of groups available in Enterprise Manager 13c that help simplify privilege management and authorization. By granting roles to groups, instead of users and using privilege propagating groups, you can reduce the direct grants and ensure users have access to the targets as needed.

Privilege Propagating Groups simplify the privilege assignment, revocation, and administration along with group management by propagating the assigned privileges to all members of the group. For example, a user can be granted access to a privilege propagating group Sales, and they in turn receive access to all targets within that group.

Administration Groups are privilege propagating groups that automate the application of monitoring settings to targets upon joining the group. Targets cannot be assigned directly to the group, rather they are automatically added based on membership criteria.

Systems are also privilege propagating and allow you to group all related targets of a particular application or function into a system.

Best Practices for Groups and Systems

Create meaningful roles and grant roles to users instead of granting privileges to users.
Grant only the minimum set of privileges a user needs for carrying out his/her responsibilities by granting the fine-grained privileges/roles only when needed.
Utilize privilege propagating groups and systems to reduce administration overhead

Guidelines for Auditing

Enterprise Manager has additional auditing that is available for purposes of tracking and validating infrastructure actions performed in Enterprise Manager, including jobs and credentials accessed. Basic and infrastructure auditing is enabled by default for Enterprise Manager 13c.

To enable audit for a subset of audited operations, please use the following EMCLI verb:

$ emcli update_audit_settings -audit_switch="ENABLE/DISABLE" -operations_to_enable="name of the operations to enable,for all operations use ALL" -operations_to_disable="name of the operations to disable, for all operations use ALL"

For example to audit only logon/logoff you would issue:

$ emcli update_audit_settings –audit_switch="ENABLE" –operations_to_enable="LOGIN;LOGOUT"

Refer to the section "Configuring and Managing Audit" for the list of operations that are audited by Enterprise Manager.

In Enterprise Manager 13c, there are over 150 options for auditing. The following command will show you the list of operations that can be audited by Enterprise Manager:

$ emcli show_operations_list

The following example shows the output of this command.

$ ./emcli show_operations_list
Operation ID                      Operation Name               Infrastructure Operation                    
ADD_AGENT_REGISTRATION_PASSWORD   Add Registration Password         NO
ADD_CS_TARGET_ASSOC               Add Standard-Target Association   NO
AGENT_REGISTRATION_PASSWORD_USAGE Registration Password Usage       NO
AGENT_RESYNC                      Resync Agent                      NO
AG_AUD_CREATE                     Create Administration Groups      NO
AG_AUD_DELETE                     Delete Administration Groups      NO
AG_AUD_MODIFY                     Modify Administration Groups      NO
APPLY_TEMPLATE                    Apply Monitoring Template         NO
APPLY_UPDATE                      Apply Update                      YES  
ATTACH_MEXT                       Attach Metric Extension           NO

Once audit is enabled, the audit records are kept in MGMT$AUDIT_LOG view in the Repository. Use Enterprise Manager Cloud Control Console to monitor the audit data as user with Super Administrator, click Setup -> Security -> Audit Data.

The externalization service via EMCLI verb update_audit_settings externalizes the audit data from the Repository to an external file system on a regular basis. Make sure there is enough space in the directory for the audit log files.

$ emcli update_audit_settings -file_prefix=<file_prefix> -directory_name=<directory_name> -file_size = <file size> -data_retention_period=<period in days>

The following example shows that the audit data will be retained in the Repository for 14 days and once exported the data will be stored in the OS directory that corresponds to database directory AUDIT with filenames prefixed with gc12_audit, and the file size will be 50M bytes each:

$ emcli update_audit_settings -externalization_switch=ENABLE -file_prefix=gc12_audit -directory=AUDIT -file_size=50000000 -data_retention_period=14

Achieve separation of duties by restricting the access to the directory where the externalized audit data is stored. No Enterprise Manager users should have access to the externalized audit data.

Best Practices for Auditing

Formalize the audit process by setting up an Audit Review schedule or integrating with an Audit tool such as Audit Vault for notifications and alerts.
Externalize the audit service and secure the files created

Guidelines for Managing Target Credentials

Preferred Credentials simplify access to managed targets by storing target login credentials in the Management Repository. Users can access an Enterprise Manager target that recognizes those credentials without being prompted to log into the target. Preferred credentials are set on a per user basis, thus ensuring the security of the managed enterprise environment. Default credentials can be set for a particular target type as well as target credentials for a particular target. The target credentials override the default credentials.

Do not set preferred credentials for group/common accounts such as SYSMAN. If preferred credentials are set for common accounts, then the accountability of the use of these credentials is lost. The following SQL statements can be used to report the list of users who have the preferred credentials set:

SELECT t.target_name,tc.user_name,tc.credential_set_name FROM MGMT_TARGET_CREDENTIALS tc, MGMT_TARGETS t WHERE tc.target_guid=t.target_guid

SELECT t.target_name,tc.user_name, tc.set_name FROM EM_TARGET_CREDS tc, MGMT_TARGETS t WHERE tc.target_guid=t.target_guid and tc.user_name = 'SYSMAN'

Credentials can be stored as Named Credentials and then privileges granted to other users to use, update or own the credentials. These credentials can be used for jobs, patching or other administration tasks on specific targets or globally. Eligible credential types include username/password, SSH-key for host and Kerberos for database. This method allows administrators to configure Named Credentials for privileged access and grant to specific users. Auditing tracks Named Credential creation, modification and usage.

Named Credentials provide a secure mechanism in Enterprise Manager to allow for separation of privilege management from privilege delegation for targets. Using Named Credentials an organization can separate the management of the specific username/password/authentication details from the actual authority to use these credentials. This is an essential tool in modern, secure organizations where there needs to be certainty that a malicious user cannot conduct operations outside Enterprise Manager using a set of known credentials obtained from inside Enterprise Manager. Additionally, the management of a central set of Named Credentials removes a significant burden on the proliferation of credentials information across many Enterprise Manager administrators and also therefore reduces the likelihood of these being used outside the Enterprise Manager environment or helps prevent against the accidental publication of credentials.

Automate Monitoring and Non-monitoring User Credential Password Management

Password lifecycle management plays a crucial role in maintaining a secure database (DB) environment. This becomes a burden when dealing with hundreds or perhaps thousands of databases. This typically involves changing the password for a user and then updating all Enterprise Manager configurations that use this password for monitoring or managing a database.

Enterprise Manager lets you use the job system to automate database password change/rotation tasks for both monitoring and non-monitoring database users with the respective jobs: Change the Password for the Database Monitoring User and Change the Password for a Database User. Both job types let you schedule jobs on Oracle Database and Cluster Database instances.

You can either explicitly specify a new password or optionally auto-generate a new password using either the current password or an explicitly specified Reference Password as the basis for auto-generation. Once Enterprise Manager changes the password to a generated one, this auto-generated password will not be known to anyone but Enterprise Manager and its components, e.g., the agent. Any target-scoped named credentials for the user will also be updated. The user-defined password option typically makes sense for a one-time scheduled job since manually having to run this job periodically will not effectively change the password across job runs. Having Enterprise Manager auto-generate random passwords is more effective from a security standpoint.

Note:

This job does not have the ability to understand password policy updates and new security standards and expects the specified password (when Auto-Generate is selected as No) or reference password to be compliant with current password policies in effect on the databases. When using Yes (Based on Current Password) the expectation is that the current password is compliant with the password policies in effect.

IMPORTANT: Both jobs, (Change the Password for the Database Monitoring User and Change the Password for a Database User), support users in Data Guard environments with SYSDBA and SYSDG privileges except the SYS user itself. To change the password on the standby database, it relies on the Oracle Database 12.2 and higher feature of auto-propagating passwords from the primary database to the standby database. It does not support changing monitoring passwords for Data Guard environments with either a Far Sync or Snapshot Standby database.

Warning Regarding Data Guard Environments

If there is a significant (> 1 minute) apply lag to any standby instance, the standby instance may be briefly shown as down in Enterprise Manager after the job completes until the new password is updated on the standby via redo log apply.

Automatic Password Management works for the following situations:

Beginning with Oracle Enterprise Manager 13c Release 5 Update 4 (13.5.0.4)

Monitoring users for DB targets, DBSNMP and custom (Non-DBSNMP)
Non-monitoring user with NORMAL on the Enterprise Manager repository target

Beginning with Oracle Enterprise Manager 13c Release 5 Update 6 (13.5.0.6)

Monitoring and non-monitoring users with SYS* (SYSDBA, SYSDG, etc.) roles, including DB users with SYS roles for the Enterprise Manager repository target.

Note:
This feature is also available with Oracle Enterprise Manager 13c Release 4 Update 18 (13.4.0.18).

Beginning with Oracle Enterprise Manager 13c Release 5 Update 12 (13.5.0.12)

Support specifying a Reference Password which can be used (instead of the current password) as a basis for password auto-generation

This section discusses the following topics:

Automate Monitoring User Password Management

You can automate password management for users (monitoring only) that discovered database instances in Enterprise Manager console via the Change the Password for the Database Monitoring User job type.

When an Oracle database is installed, a DBSNMP user is provisioned out-of-the-box that is primarily used for monitoring that database from Enterprise Manager. The DBSNMP username and password are used both during discovery and for collecting metrics from the Enterprise Manager agent. DBSNMP is also used when collecting metrics that show up on the database home page in the Enterprise Manager console. Alternatively, you may choose to use a different user (Non-DBSNMP) as the database monitoring user.

Password rotation is a normal part of the security policy for all users, and this typically applies to the DBSNMP user or any other dedicated monitoring user as well. This task usually involves changing the password for this database user (DBSNMP or Non-DBSNMP) and then updating all Enterprise Manager configurations that use this password for monitoring/administrating that database. A new password can be user-specified or auto-generated by Enterprise Manager.

IMPORTANT: The password change job should be used for DBSNMP (or other monitoring users) configured with the Normal Role, SYSDBA, or SYSDG and where Enterprise Manager is the only product/user attempting to access the actual database as this user. See Automate Monitoring and Non-monitoring User Credential Password Management for more information.

Required Target Privileges

It is recommended that the Enterprise Manager user running this job be the user that initially discovered these database targets or else needs to have at least the following Enterprise Manager target privileges on the database/cluster.

CONFIGURE_TARGET
CONNECT_TARGET
BLACKOUT_TARGET
EDIT_CREDENTIAL (monitoring and any saved named credentials)

Note:
The EDIT_CREDENTIAL privilege is required because the job blacks out the targets and updates the credentials/monitoring configuration both on the target and in Enterprise Manager as well as updating any named credentials for this database user in Enterprise Manager.

Configuring and Scheduling the Job

From the Enterprise menu, choose Job and then Activity. On the Activity page, click Create Job. The Select Job Type dialog displays.

Choose the Change the Password for the Database Monitoring User job type and click Select.
Define the job by specifying the required attributes (Job Name, Description, etc.) as well as selecting list of targets on which to schedule/run the job.

Note:
Instead of selecting a list of targets, you could also create a dynamic group and select the group. When selecting a dynamic group, all instances of type Oracle Database and Cluster Database present in the group will have the monitoring user passwords updated when the job is executed.

If there are a large number of targets being selected, it is recommended to specify a reasonable number of Maximum Parallel Executions for your environment (around 3) so that all of these jobs are not executed in parallel. Running large numbers of jobs in parallel will not only overload the job system, but also cause your targets to be in blackout concurrently.
Specify a New Password if you do not want Enterprise Manager to auto-generate a password as shown below.

Auto-Generate New Password must be set to No. Enter the new password. If the new password and confirmation do not match, an inline error message will appear and you will not be able to submit the job.

If no parameters are specified in the Parameters tab, then a new password will be generated. Auto-generated passwords are only known to and managed by Enterprise Manager.

There are two explicit options for Auto-Generate New Password. Initially, auto-generating a new password used only the format of the current password as the basis for generating a new one. Beginning with Enterprise Manager 13c Release 5 Update 12 (13.5.0.12), there is now an additional option to auto-generate a new password based on the reference password. This means that you can enter a sample password in the provided field and Enterprise Manager will use the format of the sample as the basis for auto-generating a new password.

Note:
When selecting Auto-Generate New Password: Yes (Based on Reference Password) you must ensure your sample/reference password is compliant with your current enterprise's password policies for Enterprise Manager to auto-generate a new compliant password. This option is useful for when your password policy changes (e.g., minimum password length increases) and the current password is no longer compliant and thus needs to be changed.
Define a schedule for this job. This would typically be the interval after which the monitoring user password needs to be changed as per the password profile defined for the database.

Click Submit.

Viewing the job run output (executions per target)

You can view the status/output of the password change job by clicking on the job name in the Job Activity table as shown below.

Automate Non-monitoring User Password Management

For custom non-monitoring database users, you can use the Change the Password for a Database User job type to automate password management. This task usually involves changing the password for this database user and then updating all Enterprise Manager configurations that use this password for monitoring/administrating that database. For more information, see Automate Monitoring and Non-monitoring User Credential Password Management.

Note:

Custom monitoring credentials (based on user-defined credential sets) will also be updated if these credentials are defined for the user specified in the job parameters.

In order to execute this job type, you must have the following Enterprise Manager privileges.

CONNECT_TARGET
CONFIGURE_TARGET
EDIT_CREDENTIAL

Note:
This privilege is required for the target-scoped Named Credential on the target for the user specified in the job parameter.
CREATE_JOB

Note:
This privilege is needed to create and submit the job.

This job requires the username to be specified as an input argument to the job and expects a named credential with a valid current password to be defined on the database target(s) on which the job is invoked.

Configuring and Scheduling the Job

From the Enterprise menu, choose Job and then Activity. On the Activity page, click Create Job. The Select Job Type dialog displays.
Choose the Change the password of the Database User job type and click Select.
Define the job by specifying the required attributes (Job Name, Description, etc.) as well as selecting list of targets on which to schedule/run the job.

Note:
Instead of selecting a list of targets, you could also create a dynamic group and select the group. When selecting a dynamic group, all instances of type Oracle Database and Cluster Database present in the group will have the database user passwords updated when the job is executed.

If there are a large number of targets being selected, it is recommended to specify a number reasonable for your environment (around 3) so that all of these jobs are not executed in parallel. Running large numbers of jobs in parallel will not only overload the job system.
Define the job type Parameters. In this case the Database User is the user whose password needs to be changed/rotated. The job will check for the existence of ONE and only ONE Named Credential defined on each of the database instances defined for the job. The job will generate an error if there are no Named Credentials or more than one Named Credentials defined for this user on a DB target that is specified for the job. An error will also occur if this user is the default Monitoring user for the DB target.
Specify a New Password if you do not want Enterprise Manager to auto-generate a password as shown below.

Auto-Generate New Password must be set to No. Enter the new password. If the new password and confirmation do not match, an inline error message will appear and you will not be able to submit the job.

If no parameters are specified in the Parameters tab, then a new password will be generated. Auto-generated passwords are only known to and managed by Enterprise Manager.

There are two explicit options for Auto-Generate New Password. Initially, auto-generating a new password used only the format of the current password as the basis for generating a new one. Beginning in Enterprise Manager 13c Release 5 Update 12 (13.5.0.12), there is now an additional option to auto-generate a new password based on the reference password. This means that you can enter a sample password in the provided field and Enterprise Manager will use the format of the sample as the basis for auto-generating a new password.

Note:
When selecting Auto-Generate New Password: Yes (Based on Reference Password) you must ensure your sample/reference password is compliant with your current enterprise's password policies for Enterprise Manager to auto-generate a new compliant password. This option is useful for when your password policy changes (e.g., minimum password length increases) and the current password is no longer compliant and thus needs to be changed.
Define a schedule for this job. This would typically be the interval after which the monitoring user password needs to be changed as per the password profile defined for the database.

Click Submit.

Best Practices for Credentials

Use EMCLI to automate routine password changes on privileged named credentials, this allows one administrator to know and update the password for granted users.
Utilize named credentials when setting preferred credentials to simplify credential management.
Do not set preferred credentials for group/common accounts such as SYSMAN.

Oracle Enterprise Manager FIPS140-2 Settings

Starting with Release Update 21, Oracle Enterprise Manager, 13c Release 5 can run compliant with the Federal Information Processing Standard Publication 140-2, (FIPS 140-2). Follow the steps in the sections below to make sure all EM components run in FIPS mode:

Prerequisites:

As a prerequisite, please ensure you have installed the latest OMS patch. For detailed instructions, please see MOS Doc ID 2776765.1.

Oracle HTTP Server in FIPS Mode

Secure OMS with AES encrypted wallet

All wallets have to be AES encrypted (orapki from 12.1 encrypts ewallet.p12 using AES, MOS Doc ID 2198551.1) with a key size of 2048.

WebLogic in FIPS mode allows only generating an agent certificate with a 2048 bit key. Agent certificates are created with the same key size as OMS CA certificate. Follow the bellow steps to create a new OMS CA certificate with a 2048 bit key, and re-secure all agents:
1. Check if OMS CA certificate is longer than 2048 bits:
```
<OMS_HOME>/bin/emcli login -username=sysman
<OMS_HOME>/bin/emcli sync
emcli get_ca_info
```
  Sample output:
```
Info about CA with ID: 1
CA is not configured
Signature algorithm : sha512
Key strength : 1024
DN: CN=example.com,C=US,ST=CA,L=EnterpriseManager on example.com,OU=EnterpriseManager on example.com,O=EnterpriseManager on example.com
Serial# : -4357905706800919315
Valid From: Tue Apr 14 07:43:33 PDT 2020
Valid Till: Sat Apr 13 07:43:33 PDT 2030
Number of Agents registered with CA ID CA ID 1 is 1
```
  If the OMS CA certificate has a key that is shorter than 2048 bits, create a new OMS CA following the instructions in step 4 below.
2. Create OMS wallets:
  
  If OMS is already secure with 3rd party certificate (with 2048 bits keysize) then the new AES wallet can be converted or created with the same private key and certificate.
  - To convert a wallet to AES:
```
orapki wallet convert -wallet <wallet_path> -compat_v12 -pwd <wallet_password>
```
  If Certificate key size is 1024, create new wallet for the OMS console:
  - From the OMS console, go to OMS upload , and with WebLogic use the orapki tool with -compat_v12 option
  Note:
  For more information regarding how to configure the OMS with SSL certificates, please see Doc ID 2202569.1.
3. If the wallet is newly created, add Root CA certificate to trust store:
```
<OMS_HOME>/bin/emctl secure oms -trust_certs_loc $WALLET_BASE/rootCA/cert.pem
```
  If you have SLB configured, run this command instead:
```
<OMS_HOME>/bin/emctl secure oms -host <SLB hostname> -secure_port <port> -slb_port <port> -slb_console_port <port> -trust_certs_loc $WALLET_BASE/rootCA/cert.pem
```
  Note:
  Don't bounce the OMS, until completing the steps below.
4. If key strength of OMS CA certificate is less than 2048 bits (in step 1), then create new CA:
```
<OMS_HOME>/bin/emctl secure createca -key_strength 2048
```
  Sample output:
```
Oracle Enterprise Manager  

Copyright (c) 1996, 2024 Oracle Corporation.  All rights reserved.

Creating CA... Started.

Enter Enterprise Manager Root (SYSMAN) Password :

Successfully created CA with ID 2
```
5. Secure all agents
  
  Secure all agents irrespective of the OMS wallet being newly created or not, as the OMS CA has been regenerated with a 2048 bits size.
  
  Using the emcli command, you can also secure multiple agents together.
```
<AGENT_HOME>/bin/emctl secure_agents
        [-agt_names="agt1;agt2;..."] [-agt_names_file="<file>"]
```
6. Secure OMS with AES encryption
```
<OMS_HOME>/bin/emctl secure oms -wallet $WALLET_BASE/em_cert -trust_certs_loc $WALLET_BASE/rootCA/cert.pem
```
  If you have SLB configured, run this command instead:
```
<OMS_HOME>/bin/emctl secure oms -host <SLB hostname> -wallet $WALLET_BASE/slb_cert -secure_port <port> -slb_port <port> -slb_console_port <port> -trust_certs_loc $WALLET_BASE/rootCA/cert.pem
```
7. Secure OMS Console with AES encryption
```
<OMS_HOME>/bin/emctl secure console -wallet $WALLET_BASE/em_cert
```
  If you have SLB configured, run this command instead:
```
<OMS_HOME>/bin/emctl secure console -wallet $WALLET_BASE/slb_cert -host <SLB HostName>
```
8. Secure Weblogic with AES encrypted wallet
```
<OMS_HOME>/bin>emctl secure wls -wallet $WALLET_BASE/em_cert
```
9. Repeat the step g-h on all OMS
10. Restart the OMS
  
  Primary first and then the secondary ones, one at a time:
```
emctl stop oms -all
```
```
emctl start oms
```

Enable FIPS mode flag

Add SSLFIPS ON inside <IfModule ossl_module> in the following files:

Note:

Do not add SSLFIPS ON inside the file in <VirtualHost>

In primary OMS:

$DOMAIN_HOME/config/fmwconfig/components/OHS/ohs1/ssl.conf
$DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs1/ssl.conf

In additional OMS (replace ohs2 to appropriate ohs instance):

$DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs2/ssl.conf
$DOMAIN_HOME/config/fmwconfig/components/OHS/instances/ohs2/ssl.conf.emctl_secure (if exists)

Example:

Go to:

 $INSTANCE_HOME/user_projects/domains/GCDomain/config/fmwconfig/components/OHS/ohs1/ssl.conf

Update the ssl.conf file as below:

# Some MIME-types for downloading Certificates and CRLs SSLFIPS ON

EM Repository Database in FIPS Mode

Transparent Data Encryption (TDE) and DBMS_CRYPTO PL/SQL package program

Configure:

To configure Transparent Data Encryption and the DBMS_CRYPTO PL/SQL package program units to run in FIPS mode, set the DBFIPS_140 initialization parameter to TRUE.

sqlplus / as sysdba

SQL>SELECT name,value FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';

DBFIPS_140

FALSE

SQL>ALTER SYSTEM SET DBFIPS_140 = TRUE SCOPE=SPFILE ;

SQL> shutdown immediate

SQL> startup

SQL> SELECT name,value FROM SYS.V$PARAMETER WHERE NAME = 'DBFIPS_140';

DBFIPS_140

TRUE

SQL> exit

Test

select DBMS_CRYPTO.hash(UTL_RAW.CAST_TO_RAW ('TestString'), 2) from dual;

second param is Hash algorithm

HASH_MD4 (128 bit hash)     1

HASH_MD5 (128 bit hash)     2

HASH_SH1 (160 bit hash)     3

HASH_SH256                      4

HASH_SH384                     5

HASH_SH512                     6

Above query (MD4, MD5 hash) works in  non FIPS mode (DBFIPS_140=FALSE) and fails in FIPS mode (DBFIPS_140=TRUE)

SSL Transport Security
1. Create DB Wallet
  
  To create a new wallet, from the OMS console, go to OMS upload , and with Weblogic use the orapki tool.
2. Configure SSL Communication
  Add SSLFIPS_140=TRUE flag in
```
$DB_HOME/ldap/admin/fips.ora
```
  For more information on configuring SSL communication, see Configure TLSv1.2 for the Enterprise Manager Repository.
3. Restart Listener
```
$DB_HOME/bin/lsnrctl stop
```
```
$DB_HOME/bin/lsnrctl start
```
Configure EM to use TCPS listener

For more information on configuring EM to use TCPS listener, see Configuring the Oracle Management Service to connect to the TLSv1.2-enabled Enterprise Manager Repository.

Oracle WebLogic Server

Add RSA JSSE and RSA JCE provider

Add RSA providers at the top and move other existing providers down accordingly in the <OMS_HOME>/oracle_common/jdk/jre/lib/security/java.security file:

security.provider.1=com.rsa.jsafe.provider.JsafeJCE
security.provider.2=com.rsa.jsse.JsseProvider
security.provider.3=sun.security.provider.Sun
security.provider.4=sun.security.rsa.SunRsaSign
security.provider.5=sun.security.ec.SunEC
security.provider.6=com.sun.net.ssl.internal.ssl.Provider
security.provider.7=com.sun.crypto.provider.SunJCE
security.provider.8=sun.security.jgss.SunProvider
security.provider.9=com.sun.security.sasl.Provider
security.provider.10=org.jcp.xml.dsig.internal.dom.XMLDSigRI
security.provider.11=sun.security.smartcardio.SunPCSC

Add FIPS compliant TrustStore and provider Jars in class path

Follow these steps to add the two .jar files in Web-Logic and Node Manager, from $ORACLE_HOME/wlserver/server/lib:

<OMS_HOME>/wlserver/server/lib/jcmFIPS.jar

<OMS_HOME>/wlserver/server/lib/sslj.jar

Add the FIPS configuration in <EM_INSTANCE_BASE/user_projects/domains/GCDomain/bin/startEMServer.sh after the EXT_POST_CLASSPATH="<omshome>/sysman/jlib/emagentPermissions.jar" export EXT_POST_CLASSPATH line:

JAVA_OPTIONS="-Doracle.net.isFipsMode=true -Dcom.sun.net.ssl.enableECC=false ${JAVA_OPTIONS} "
export JAVA_OPTIONS

PRE_CLASSPATH="<OMS_HOME>/wlserver/server/lib/jcmFIPS.jar:<OMS_HOME>/wlserver/server/lib/sslj.jar:${PRE_CLASSPATH}"

Example domain home:

/u01/app/Oracle/gc_inst/user_projects/domains/GCDomain/bin/startEMServer.sh

Add FIPS configuration in $DOMAIN_HOME/bin/startNodeManager.sh above the # start node manager ... line:

JAVA_OPTIONS=" -Dcom.sun.net.ssl.enableECC=false ${JAVA_OPTIONS} "
PRE_CLASSPATH="<OMS_HOME>/wlserver/server/lib/jcmFIPS.jar:<OMS_HOME>/wlserver/server/lib/sslj.jar"

export JAVA_OPTIONS
export PRE_CLASSPATH

Start Node Manager:
```
$DOMAIN_HOME/bin/startNodeManager.sh
```
Re-create Trust store and Key store with Password based encryption with a FIPS compliant algorithm, such as aes-256-cbc, using openssl.

Update the PKCS12 wallet under <EM_INSTANCE_BASE/em/omrWallets/<trustStore> and <EM_INSTANCE_BASE/em/omrWallets/<keyStore> with the trust and key of the newly updated PKCS12 wallet.

openssl pkcs12 -in ewallet.p12 -out cert.pem <genrate pem file from already generated wallet under trsuststore and keystore >

openssl pkcs12 -keypbe aes-256-cbc -certpbe aes-256-cbc -export -in <path to .pem file and file name> -out <path to .pfx file and file name>

Example domain home:

/u01/app/Oracle/gc_inst/em/omrWallets

Bounce all components:
```
emctl stop oms -all
emctl start oms
```

Oracle EM Agent in FIPS Mode

Agent Communication

The table lists the default ciphers supported by the Oracle EM Agent. As some of the ciphers are not FIPS compliant, add the ciphers explicitly in the agent emd.properties file, and bounce the agent to be FIPS compliant:

SSLCipherSuites=ECDHE_ECDSA_WITH_AES_128_GCM_SHA256:ECDHE_ECDSA_WITH_AES_256_GCM_SHA384:ECDHE_RSA_WITH_AES_128_GCM_SHA256:AES_128_CCM_8_SHA256:AES_128_CCM_SHA256:AES_128_GCM_SHA256:AES_256_GCM_SHA384:DHE_DSS_WITH_AES_:28_GCM_SHA256:DHE_DSS_WITH_AES_256_GCM_SHA384:DHE_RSA_WITH_AES_128_GCM_SHA256:DHE_RSA_WITH_AES_256_GCM_S:A384:ECDHE_RSA_WITH_AES_256_GCM_SHA384:DH_DSS_WITH_AES_128_GCM_SHA256:DH_DSS_WITH_AES_256_GCM_SHA384:TLS:DH_RSA_WITH_AES_128_GCM_SHA256:DH_RSA_WITH_AES_256_GCM_SHA384:ECDH_ECDSA_WITH_AES_128_GCM_SHA256:ECDH_EC:SA_WITH_AES_256_GCM_SHA384:ECDH_RSA_WITH_AES_128_GCM_SHA256:ECDH_RSA_WITH_AES_256_GCM_SHA384:DHE_DSS_WITH_AES_128_CB:_SHA:DHE_DSS_WITH_AES_128_CBC_SHA256:DHE_DSS_WITH_AES_256_CBC_SHA:DHE_DSS_WITH_AES_256_CBC_SHA256:DHE_:SA_WITH_AES_128_CBC_SHA:DHE_RSA_WITH_AES_128_CBC_SHA256:DHE_RSA_WITH_AES_256_CBC_SHA:DHE_RSA_WITH_AES_256_:BC_SHA256:ECDH_ECDSA_WITH_AES_128_CBC_SHA:ECDH_ECDSA_WITH_AES_128_CBC_SHA256:ECDH_ECDSA_WITH_AES_256_CBC_S:A:ECDH_ECDSA_WITH_AES_256_CBC_SHA384:ECDH_RSA_WITH_AES_128_CBC_SHA:ECDH_RSA_WITH_AES_128_CBC_SHA256:EC:H_RSA_WITH_AES_256_CBC_SHA:ECDH_RSA_WITH_AES_256_CBC_SHA384:ECDHE_ECDSA_WITH_AES_128_CBC_SHA:ECDHE_ECDSA_W:TH_AES_128_CBC_SHA256:ECDHE_ECDSA_WITH_AES_256_CBC_SHA:ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:ECDHE_RSA_WITH_:ES_128_CBC_SHA:ECDHE_RSA_WITH_AES_128_CBC_SHA256:ECDHE_RSA_WITH_AES_256_CBC_SHA:ECDHE_RSA_WITH_AES_256_CBC:SHA384:RSA_WITH_AES_128_CBC_SHA:RSA_WITH_AES_128_CBC_SHA256:RSA_WITH_AES_128_GCM_SHA256:RSA_WITH_AES_2:6_CBC_SHA:RSA_WITH_AES_256_CBC_SHA256:RSA_WITH_AES_256_GCM_SHA384

Cipher	FIPS
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256	YES
TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384	YES
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256	YES
TLS_AES_128_CCM_8_SHA256	YES
TLS_AES_128_CCM_SHA256	YES
TLS_AES_128_GCM_SHA256	YES
TLS_AES_256_GCM_SHA384	YES
TLS_CHACHA20_POLY1305_SHA256	NO
TLS_DHE_DSS_WITH_AES_128_GCM_SHA256	YES
TLS_DHE_DSS_WITH_AES_256_GCM_SHA384	YES
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256	YES
TLS_DHE_RSA_WITH_AES_256_GCM_SHA384	YES
TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256	NO
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384	YES
TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256	NO
TLS_DH_DSS_WITH_AES_128_GCM_SHA256	YES
TLS_DH_DSS_WITH_AES_256_GCM_SHA384	YES
TLS_DH_RSA_WITH_AES_128_GCM_SHA256	YES
TLS_DH_RSA_WITH_AES_256_GCM_SHA384	YES
TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256	YES
TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384	YES
TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256	YES
TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384	YES
TLS_DH_DSS_WITH_AES_128_CBC_SHA	NO
TLS_DH_DSS_WITH_AES_128_CBC_SHA256	NO
TLS_DH_DSS_WITH_AES_256_CBC_SHA	NO
TLS_DH_DSS_WITH_AES_256_CBC_SHA256	NO
TLS_DH_RSA_WITH_AES_128_CBC_SHA	NO
TLS_DH_RSA_WITH_AES_128_CBC_SHA256	NO
TLS_DH_RSA_WITH_AES_256_CBC_SHA	NO
TLS_DH_RSA_WITH_AES_256_CBC_SHA256	NO
TLS_DHE_DSS_WITH_AES_128_CBC_SHA	YES
TLS_DHE_DSS_WITH_AES_128_CBC_SHA256	YES
TLS_DHE_DSS_WITH_AES_256_CBC_SHA	YES
TLS_DHE_DSS_WITH_AES_256_CBC_SHA256	YES
TLS_DHE_RSA_WITH_AES_128_CBC_SHA	YES
TLS_DHE_RSA_WITH_AES_128_CBC_SHA256	YES
TLS_DHE_RSA_WITH_AES_256_CBC_SHA	YES
TLS_DHE_RSA_WITH_AES_256_CBC_SHA256	YES
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA	YES
TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256	YES
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA	YES
TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384	YES
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA	YES
TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256	YES
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA	YES
TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384	YES
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA	YES
TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256	YES
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA	YES
TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384	YES
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA	YES
TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256	YES
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA	YES
TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384	YES
TLS_RSA_WITH_AES_128_CBC_SHA	YES
TLS_RSA_WITH_AES_128_CBC_SHA256	YES
TLS_RSA_WITH_AES_128_GCM_SHA256	YES
TLS_RSA_WITH_AES_256_CBC_SHA	YES
TLS_RSA_WITH_AES_256_CBC_SHA256	YES
TLS_RSA_WITH_AES_256_GCM_SHA384	YES
TLS_RSA_WITH_CAMELLIA_128_CBC_SHA	NO
TLS_RSA_WITH_CAMELLIA_256_CBC_SHA	NO

AgentCrypto's symmetric key algorithm is AES-128, which is FIPS compliant

Steps to Add a New Additional OMS in FIPS Mode

Revert to wls certificate only in primary OMS:
- ```
emctl secure wls -use_demo_cert
```
- Bounce primary OMS
Install OMS software in the new machine
- Follow the steps described in Installing Additional Oracle Management Services in Silent Mode. As a software-only install, deploy the plug-ins,and apply all the patches you applied on the first OMS.
Copy wallet to the new OMS machine

Add RootCA into java truststore

export ORACLE_HOME=<OMS_HOME>

keytool -importcert -file <WalletPath ROOTCA>/cert.pem -alias emreprootca -keystore 
$ORACLE_HOME/oracle_common/jdk/jre/lib/security/cacerts -storepass "<password>"

Export the configuration details from the first OMS and copy the bka file to new OMS machine
```
$<ORACLE_HOME>/bin/emctl exportconfig oms -dir <absolute_path_to_directory>
```

Run OMSCA command

$<ORACLE_HOME>/bin/omsca recover -ms -backup_file <absolute_path_to_bka_file> [-AS_HTTPS_PORT <port> -MSPORT <port> -MS_HTTPS_PORT <port> -EM_NODEMGR_PORT <port> -EM_UPLOAD_PORT <port> -EM_UPLOAD_HTTPS_PORT <port> -EM_CONSOLE_PORT <port> -EM_CONSOLE_HTTPS_PORT <port> -config_home <absolute_path_to_instance_dir> -EM_INSTANCE_HOST <second_oms_host_name>] -nostart

This command is the same as the one in step 8 from Installing Additional Oracle Management Services in Silent Mode with additional -nostart flag.

Repeat all the steps in the above Oracle HTTP Server section in the new OMS except startup.
Repeat all the steps in the above Oracle Web-Logic server section in the new OMS except startup.
Start new OMS using the following steps:
```
emctl stop oms -all
emctl start oms
```
Resecure primary OMS to use custom certificate.