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 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.

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 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.

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 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

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 relies on the WebLogic Server for external Authentication methods. For this reason, Enterprise Manager 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.

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 pre-configured 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. See Security Features and External Authorization using External Roles.

Password Profile

When creating an Administrator (go to Setup, select Security, click 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.

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

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 comes with predefined roles to manage a wide variety of resource and target types.

• External Roles

  Enterprise Manager 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.

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

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 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.

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.

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 Advanced Privilege Settings on top of Target Privileges table to see the advanced privileges in the table.

• EM CLI support is also available for this new feature. 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.

  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).

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.

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.