2 Security Features

This chapter covers the following topics:

Configuring Authentication

Enterprise Manager authentication is the process of determining the validity of the user accessing Enterprise Manager. The authentication feature is available across the different interfaces such as Enterprise Manager console and Enterprise Manager Command Line Interface (EM CLI).

Enterprise Manager's authentication framework consists of pluggable authentication schemes that let you use the type of authentication protocol best suited to your environment.

Note:

Oracle Enterprise Manager 13c relies on the underlying WebLogic Server that is part of the OMS stack for external Authentication methods. For this reason, Enterprise Manager 13c can be authenticated using any authentication method that is supported by Oracle WebLogic Server. Note that only some providers have been certified so far although theoretically it should be possible to configure for all.

Supported Authentication Schemes

Enterprise Manager supports the following authentication schemes:

  • Repository-Based Authentication:

    This scheme involves saving the administrator's username and password in the Enterprise Manager repository and performing validation against these saved values whenever a user logs on to the Enterprise Manager console. An Enterprise Manager user created is also a repository (database) user. By using this option, you can take advantage of all the benefits of Oracle database user management that this authentication method provides such as password control through the password profile, enforced password complexity, password life time, and number of failed attempts allowed. During the password grace period, the administrator is prompted to change the password but when the password has expired, it must be changed. For more details, refer to Creating a New Administrator.

  • Oracle Access Manager (OAM) Single Sign-On (SSO) Based Authentication: Oracle Access Manager is the Oracle Fusion Middleware single sign-on solution. The underlying identity stores will be the Enterprise Directory Identity Stores being supported by Oracle Access Manager. This authentication scheme is used for data centers that have standardized on Oracle Access Manager as the central tool for authentication across all enterprise applications. If you want to support protocols such as Kerberos for authentication, you must configure OAM for this. For more information about OAM, see Oracle® Fusion Middleware Administrator's Guide for Oracle Access Manager 13c Release 1 (11.1.1).

  • Enterprise User Security Based Authentication: The Enterprise User Security (EUS) option enables you to create and store enterprise users and roles for the Oracle database in an LDAP-compliant directory server. After the Enterprise Manager repository is configured with EUS, you can configure Enterprise Manager to use EUS as its authentication mechanism as described in Enterprise User Security Based Authentication. You can register any EUS user as an Enterprise Manager administrator.

    In addition to using EUS to authenticate Enterprise Manager administrators, it can also be used to simplify management of database target credentials. EUS helps centralize the administration of users and roles across multiple databases. If the managed databases are configured with EUS, the process of logging into these databases is simplified. When you drill down to a managed database, Enterprise Manager will attempt to connect to the database using Enterprise Manager credentials. If successful, Enterprise Manager will directly connect you to the database without displaying a logon page.

  • LDAP Authentication Options: Oracle Internet Directory and Microsoft Active Directory

    • Oracle Internet Directory (OID) Based Authentication - Oracle Internet Directory is a LDAP v3 compliant directory built on the Oracle database and is fully integrated into Oracle Fusion Middleware and Oracle Applications. Therefore, it is ideally suited for Oracle environments or enterprises with Oracle database expertise. When using an authentication scheme based on OID as the identity store, you can have your applications authenticate users against the OID.

    • Microsoft Active Directory Based Authentication - Microsoft Active Directory is a directory service that provides authentication and authorization functionality in a Windows network. When using a Microsoft Active Directory as an identity store, you can plug in this scheme to have your applications authenticate users against the Microsoft Active Directory.

    Note:

    Enterprise Manager will support external authentication as long as the specific authentication scheme is supported and integrated with the WebLogic Server.

  • RADIUS Synchronous Authentication: This scheme can be enabled by setting a property value using either the command line or the UI:
    1. Open a terminal window and execute the following command:
      $ORACLE_HOME/bin/emctl set property -name oracle.sysman.db.enable_radius_auth -value true
    2. When creating a new credential or editing an existing named credential, click the RADIUS Authentication checkbox.
  • Security Assertion Markup Language (SAML): SAML is a standard that enables seamless, single sign-on (SSO) login into applications. It works by transferring the user’s identity from one place (the identity provider) to another (the service provider) through an exchange of digitally signed XML documents. Oracle Enterprise Manager supports SAML version 2.0.

    To configure Enterprise Manager with SAML-based login, follow these steps:

    1. The Service Provider Configuration requires ldap parameters. Run this command from the OMS Home to create the Service Provider metadata (EMGC_OMS1_sp_metadata.xml) for the primary OMS. For example, an OMS Home may be /u01/app/oracle/middleware.

      <OMS Home>/bin/emctl config auth saml_service_provider -ldap_type oid -ldap_host myhost.example.com -ldap_port 3131 -ldap_principal "cn=orcladmin" -user_base_dn cn=Users -group_base_dn cn=Groups -ldap_credential password -enable_auto_provisioning -use_ssl -cert_file /tmp/cert

      Sample output:

      Oracle Enterprise Manager Cloud Control 13c Release 5
      Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
      Configuring SAML Authentication ... StartedSAML Service Provider configured
      Weblogic configuration file modified
      Configuring SAML Authentication ... Successful
      Configuring LDAP Authentication ... Started
      Successfully validated connection to LDAP server
      Configuring LDAP Authentication ... Successful
      Run 'emctl config auth saml_service_provider' in other OMS(s) and restart all OMS(s) using 'emctl stop oms -all' and 'emctl start oms'
    2. Run the following command only in additional OMS(s):

      emctl config auth saml_service_provider

      Sample output:

      Oracle Enterprise Manager Cloud Control 13c Release 5
      Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
      Configuring SAML Authentication ... Started
      Weblogic configuration file modified
      Configuring SAML Authentication ... Successful
    3. Restart the primary and additional OMS(s):

      emctl stop oms -all
      emctl start oms
    4. Run the following command in the primary OMS:

      emctl config auth export_saml_metadata

      Sample output:

      Oracle Enterprise Manager Cloud Control 13c Release 5
      Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
      Exporting SAML Metadata ... Started
      SAML Service Provider metadata is exported to file
      /ade/u01/oracle/work/user_projects/domains/EMGC_DOMAIN/saml_sp_metadata.xml
    5. Import the Service Provider metadata into your Identity Provider. This varies depending on your provider. For example, if using Configure Oracle Access Management (OAM), login to OAM → Federation → Identity Provider Management → Create Service Provider Partner → Browse and choose the metadata file. Enter the values as shown in the image and then save. Image showing the Service Provider Partners metadata.

    6. Get SAML metadata xml file from Identity Provider and run the following command in the primary OMS:

      emctl config auth import_saml_identity_provider -idp_metadata /tmp/dev_oam_saml_metadata.xml

      Sample output:

      Oracle Enterprise Manager Cloud Control 13c Release 5
      Copyright (c) 1996, 2021 Oracle Corporation. All rights reserved.
      Configuring SAML Authentication ... Started
      SAML Identity Provider configured
      Configuring SAML Authentication ... Successful
      Restart all OMS(s) using 'emctl stop oms -all' and 'emctl start oms'
    7. Restart the primary and additional OMS(s):

      emctl stop oms -all
      emctl start oms

These authentication schemes have been tested in house and some of the external authentication schemes mentioned below can be configured using the emctl config auth utility command, which configures the required WebLogic providers as well as set the required OMS properties.

Authenticating schemes where the emctl utility command configures the WebLogic authentication providers, the command sets the required configuration parameters and leaves most of the other parameters to the default values. Administrators should ensure the configuration parameters of the WebLogic providers are tuned for performance suited to their environment before going into production. This can be done through the WebLogic Administration Console.

For more information regarding configuring SAML for different identity providers, such as Azure Ad, PingID and IDCS, see EM 13.5: Primary Note on SAML 2.0 Configuration and Issues for SSO login (Doc ID 2976397.2).

Creating a New Administrator

Enterprise Manager allows you to create and manage new administrator accounts. Each administrator account includes its own logon credentials as well as a set of roles and privileges that are assigned to the account. You can also assign a password profile to the administrator. You will need to have Enterprise Manager Super Administrator privileges to create and manage new administrator accounts.

To create, edit, or view an administrator account:

  1. From the Setup menu, select Security, then select Administrators. The Administrators page is displayed.
  2. Click the appropriate task button on the Administrators page. The Authentication page is displayed.

    Repository Based Authentication is selected as the default authentication method.

Repository Based Authentication

Repository Based Authentication is the default method of Enterprise Manager Authentication. With this authentication method, a new administrator is created in the repository.

Note:

Repository-based authentication is the default authentication method.

On this page, you can specify the type of administrator account being created and select the password profile. The password cannot be changed by the administrator if the Prevent Password Change toggle is on.

If the Expire Password Now toggle is on, the password for the new administrator account will be set to an expired state. If the password has expired, when the new administrator logs in, the Change Password page is displayed and the administrator is prompted to change the password.

The administrator should enter his current password and the new password and click Apply. He can now start using Enterprise Manager.

Creating a New User (Command Line)

The following examples make User1 an Enterprise Manager user, provide a description for the user, and prevent the password from being changed. Only another Super Administrator can change the password. The profile is set as MGMT_ADMIN_USER_PROFILE.

Example 2-1 Command Line

emcli create_user
      -name="User1"
      -desc="This is temp hire."
      -prevent_change_password="true"
      -profile="MGMT_ADMIN_USER_PROFILE"

Example 2-2 Scripting and Interactive

create_user
      (name="User1"
      ,desc="This is temp hire."
      ,prevent_change_password="true"
      ,profile="MGMT_ADMIN_USER_PROFILE")
Restoring to the Default Authentication Method

The following sections detail how to restore the default Enterprise Manager authentication methods.

Bypassing the Single Sign-On Logon Page

If the OMS is configured with SSO or OAM or some other authentication method, you may want to by-pass the Single Sign-On or OAM authentication under certain circumstances.To bypass the SSO logon page, connect to the following URL:

  1. Connect to https://ms_host:ms_https_port/em

    ms_host & ms_https_port are WLS-managed server's hostname & port#. These parameters can be found in the EM_INSTANCE_HOME/emgc.properties file. They are listed as EM_INSTANCE_HOST & MS_HTTPS_PORT in this file.

  2. Log in using a repository user's credentials.
Restoring the Default Authentication Method
  1. Run the following command on each OMS:

    emctl config auth repos

    Sample command output:

    Oracle Enterprise Manager Cloud Control 13c Release 5
    Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
    Configuring Repos Authentication ... Started
    Configuring Repos Authentication ... Successful
    If you have updated files like httpd.conf (for example, while installing WebGate), rollback them.
    If this is a multi-OMS environment, execute this command on remaining servers.
    After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
    
  2. Run the following commands on each OMS:

    emctl stop oms -all

    emctl start oms

If you have configured OAM SSO, you need to manually un-install Webgate and remove the Webgate directives from Apache httpd.conf.

If you have configured with OSSO, you need to manually remove the OSSO directives from httpd.conf.

Deleting an Administrator

To delete an administrator account:

  1. From the Setup menu, select Security, then select Administrators. The Administrators page is displayed.
  2. Select the administrator that you want to delete, then click Delete.
  3. On the confirmation page, click Yes.

If the administrator has resources assigned the Delete Administrator page appears. Use the Delete Administrator page to specify what happens to administrator-owned objects when removing an administrator from Enterprise Manager. On this page, you can:

  • Delete all administrator-owned objects along with the Enterprise Manager administrator. This will delete the administrator and associated job types, jobs, corrective actions, report definitions, reports, and templates. Blackouts will not be deleted.

  • Reassign objects to another Enterprise Manager administrator. This will assign the administrator's objects to another administrator. The credentials belonging to the administrator will be deleted from the repository before any reassignment takes place.

Usage Tips

Click View Objects to see all objects currently owned by the Enterprise Manager administrator to be deleted.

To reassign the objects to another administrator, enter the name of the new administrator in the New Owner text box, or click the flashlight icon to view a list of available administrators.

Only a super administrator can delete other Enterprise Manager administrators. Enterprise Manager will not allow administrators to:

  • Delete themselves.

  • Delete the management repository owner.

Administrator object reassignments can be handled as follows:

  • Blackouts can be reassigned to any user who has OPERATOR privileges on all targets affected by the blackout.

  • Jobs can be reassigned to any administrator. However, ALL credentials associated with the job will be removed, leaving the job in a Suspended state. This requires the new job owner to explicitly set new credentials. Currently running jobs are allowed to continue running. Once the new job owner sets the credentials, the job will revert to a SCHEDULED state.

  • Corrective Actions can be reassigned to any administrator who has OPERATOR privileges for targets on which the corrective action can operate.

  • Report Definitions can be reassigned to any administrator.

  • Reports can be reassigned to any administrator.

  • Monitoring Templates can be reassigned to any administrator.

Enterprise User Security Based Authentication

Enterprise User Security enables you to create and store Oracle database information as directory objects in an LDAP-compliant directory server such as Oracle Internet Directory (OID) or Microsoft Active Directory. For example, an administrator can create and store enterprise users and roles for the Oracle database in the directory, which helps centralize the administration of users and roles across multiple databases.

See Also:

Database Enterprise User Security Administrator's Guide.

If you currently use Enterprise User Security to mange Oracle users and roles for all your Oracle databases, you can also extend this feature to manage Enterprise Manager administrator accounts. Configuring Enterprise Manager for use with Enterprise User Security simplifies the process of logging in to database targets you are managing with the Oracle Enterprise Manager console.

To configure Enterprise Manager for use with Enterprise User Security:

  1. Ensure that you have enabled Enterprise User Security for your Oracle Management Repository database, as well as the database targets you will be managing with the Cloud Control console. Refer to Oracle Database Advanced Security Administrator's Guide for details.
  2. Using the emctl set property command, set the following property:
    oracle.sysman.emSDK.sec.DirectoryAuthenticationType=EnterpriseUser

    Note:

    For multiple OMS configurations, the command must be run on each OMS.

    For example:

    emctl set property -name oracle.sysman.emSDK.sec.DirectoryAuthenticationType -value EnterpriseUser
    
  3. Stop the Oracle Management Service.

    emctl stop oms -all

    See Also:

    Controlling the Oracle Management Service on page 24‐4

  4. Start the Management Service.

    emctl start oms

The next time you use the Oracle Enterprise Manager console to drill down to a managed database, Enterprise Manager will attempt to connect to the database using Enterprise User Security. If successful, Enterprise Manager will connect you to the database without displaying a logon page. If the attempt to use Enterprise User Security fails, Enterprise Manager will prompt you for the database credentials.

Registering Enterprise Users (EUS Users) as Enterprise Manager Users

After you have configured Enterprise Manager to use Enterprise Users (EUS), you can register existing enterprise users as Enterprise Manager Users and grant them the necessary privileges so that they can manage Enterprise Manager effectively.

You can register existing enterprise users by using:

  • Enterprise Manager Console

  • Enterprise Manager Command Line Interface (EM CLI)

Registering Enterprise Users Using the Enterprise Manager Console

You can use the Enterprise Manager console to register enterprise users by following these steps:

  1. Log in to Enterprise Manager as a Super Administrator.
  2. From the Setup menu, select Security then select Administrators to display the Administrators page. Since Enterprise Manager has been configured to use Enterprise Users, the first page of the Create Administrator wizard will provide the option to create an administrator based on a registered Oracle Internet Directory user or a normal database user.
  3. Select Oracle Internet Directory and click Continue to go to the next page in the wizard.
  4. Enter the name and e-mail address of the Oracle Internet Directory user or click the flashlight icon to search for a user name in the Oracle Internet Directory.
  5. Use the rest of the wizard pages to define the roles, system privileges, and other characteristics of the Enterprise Manager administrator and then click Finish. Enterprise Manager displays a summary page that lists the characteristics of the administrator account.
  6. Click Finish to create the new Enterprise Manager administrator.

    The OID user is now included in the list of Enterprise Manager administrators. You can now verify the account by logging out of the Cloud Control console and logging back in using the OID user credentials on the Single Sign-On logon page.

Registering Enterprise Users Using the Command Line Interface

To register Enterprise Users as Enterprise Manager users using EM CLI, enter the following command:

emcli create_user -name=eususer -type=DB_EXTERNAL_USER

This command registers the eususer as an Enterprise Manager user where eususer is an existing Enterprise User.

Oracle Internet Directory (OID)

You can implement an OID-based authentication scheme to have Enterprise Manager authenticate users against the OID.

Running the emctl config auth oid command on the OMS creates a WebLogic authentication provider of type OracleInternetDirectoryAuthenticator that uses the configuration parameter values specified by the command. Any configuration values not specified retain the default values. Tuning and modification of advanced OID configuration parameters is carried out through the WebLogic Server Administration Console and not the emctl config auth oid command.

Note:

In the event you need to perform LDAP troubleshooting, enable LDAP tracing log file (ldap_trace.logATN) generation from the WebLogic Server Console. For more information, see"Troubleshooting Authentication Issues in Enterprise Manager" .

Prerequisites

Oracle Internet Directory LDAP server is set up and running.

WebLogic Administration Server is up and running.

  1. Run the emctl config auth oid command on each OMS.
    emctl config auth ad -ldap_host <ldap host> -ldap_port <ldap port>
        -ldap_principal <ldap principal> [-ldap_credential <ldap credential>]
        -user_base_dn <user base DN> -group_base_dn <group base DN> [-user_dn <dn>] [-group_dn <dn>]
        [-enable_auto_provisioning] [-auto_provisioning_minimum_role <min_role>] [-minimum_privilege <min_priv>]
        [-use_ssl] [-cert_file <cert>] [-trust_cacerts] [-use_anonymous_bind] [-keystore_pwd keystone_password]
    

    where:

    • ldap_host: LDAP host name

    • ldap_port: LDAP port

    • ldap_principal: The distinguished name (DN) of the LDAP user the WebLogic server should use to connect to the LDAP server.

    • ldap_credential: Password for the user specified by ldap_principal.

    • user_base_dn: The base distinguished name (DN) of the tree in the LDAP directory that contains users.

    • group_base_dn - The base distinguished name (DN) of the tree in the LDAP directory that contains groups.

    • enable_auto_provisioning:If specified, turns on auto provisioning in Enterprise Manager, where external LDAP users do not have to be provisioned manually in Enterprise Manager

    • auto_provisioning_minimum_role <min_role>: if specified, auto provisions only those external users in Enterprise Manager who have the min_role granted to them in LDAP

    • minimum_privilege <min_priv>: If specified, prevents access to Enterprise Manager to users who do not have the min_priv granted to them.

    • use_ssl: Use SSL to connect to the LDAP server

    • cert_file <cert>: Use the passed in LDAP server certificate to establish trust while connecting to LDAP server over ssl. Specify this option if the LDAP server has certificate signed by not well-known (or trusted) Certificate Authority. Note: This expects a single certificate. We do not support importing certificate chains. Please import using keytool utility before running this command.

    • trust_cacerts: Trust the LDAP server's certificate while connecting to LDAP server. This is typically used if certificate is signed by well known CA

    • keystore_pwd <passwd>: The password for the default DemoTrust.jks keystore (if default password has changed) or any custom keystore to which the LDAP server's certificate will be imported as part of validation.

    • use_anonymous_bind: If specified, uses anonymous bind to connect to LDAP server

    Example:

    emctl config auth oid -ldap_host "ldaphost" -ldap_port "3060" -ldap_principal "cn=orcladmin,cn=users,dc=us,dc=oracle,dc=com" -user_base_dn "cn=users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=groups,dc=us,dc=oracle,dc=com" -ldap_credential password
    
  2. Stop the OMS.

    emctl stop oms -all

  3. Restart the OMS.

    emctl start oms

    Note:

    For Enterprise Manager deployments consisting of multiple OMS instances, emctl config auth oid must be run on each OMS. Each OMS must be restarted in order for changes to take effect.

    For more information, see How to authenticate Enterprise Manager Cloud Control with LDAP over SSL

Testing the OID Configuration

Use the WebLogic Server Administration Console (Users and Groups tab) to check whether the OID configuration has been successful. To navigate to this tab, select Home/Summary of Security Realms/myrealm/Users and Groups. From the Users and Groups tab, you should see users and groups showing up from the OID.

Microsoft Active Directory Based Authentication

You can implement Microsoft AD-based authentication scheme to have Enterprise Manager authenticate users against the Active Directory.

Running the emctl config auth ad command on the OMS creates a WebLogic authentication provider of type ActiveDirectoryAuthenticator that uses the configuration parameter values specified by the command. Any configuration values not specified retain the default values. Tuning and modification of advanced AD configuration parameters is carried out through the WebLogic Server Administration Console and not the emctl config auth ad command.

Before running the following procedure, ensure the Active Directory LDAP server is up and running.

  1. Run the emctl config auth oid command on each OMS.
    emctl config auth ad -ldap_host <ldap host> -ldap_port <ldap port>    -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] -user_base_dn <user base DN> -group_base_dn <group base DN>
    

    where:

    • ldap_host: Name of the machine name where Active Directory has been installed.

    • ldap_port: Active port where Active Directory is listening for requests.

    • ldap_principal: The distinguished name (DN) of the Active Directory user the WebLogic server should use to connect to the LDAP server to ensure the user's validity.

    • ldap_credential: Password for the user specified by ldap_principal.

    • user_base_dn: The users specified as the ldap_principal must have read access to this directory. If the users are located in multiple base DNs, enter the highest, most common DN in this field. This field does not accept multiple entries.

    • group_base_dn - The users specified as the ldap_principal must have read access to this directory.

    Example:

    emctl config auth ad -ldap_host "ldaphost" -ldap_port "3060" -ldap_principal "cn=orcladmin" -user_base_dn "cn=users,dc=us,dc=oracle,dc=com" -group_base_dn "cn=groups,dc=us,dc=oracle,dc=com" -ldap_credential "my_ldap_password"
    
  2. Stop the OMS.

    emctl stop oms -all

  3. Restart the OMS.

    emctl start oms

    Note:

    For Enterprise Manager deployments consisting of multiple OMS instances, emctl config auth ad must be run on each OMS. Each OMS must be restarted in order for changes to take effect.

Testing the Microsoft Active Directory Configuration

Use the WebLogic Server Administration Console (Users and Groups tab) to check whether the Microsoft Active Directory configuration has been successful. To navigate to this tab, select Home/Summary of Security Realms/myrealm/Users and Groups. From the Users and Groups tab, you should see users and groups showing up from the Microsoft Active Directory.

External Authorization using External Roles

When configuring Enterprise Manager for external authentication of users, you can also configure it to work with the external authentication provider to manage authorization as well. This is done using external roles. This is useful in many scenarios including, but not limited to, auto-provisioned users where the auto-provisioned user will not have any Enterprise Manager roles granted to them. The idea behind external roles is to create a role in Enterprise Manager with the relevant privileges and have the name of the role match the name of a LDAP group. Users who are part of the LDAP group will automatically be granted privileges in the role once they log on to Enterprise Manager.

To set up external roles, create a role in Enterprise Manager and mark it as external. The name of this role should be the same as an external LDAP group. Set up this role with the necessarily roles and privileges. For example, in Enterprise Manager you can create a role called EM_ADMIN that is marked external. The EM_ADMIN name matches an LDAP group called EM_ADMIN. Assume JohnDoe is a member of the EM_ADMIN LDAP group and is also an Enterprise Manager user. When JohnDoe logs on to Enterprise Manager, he will be granted all the privileges defined in the Enterprise Manager role EM_ADMIN.

Auto Provisioning

Typically the external LDAP users must be created in Enterprise Manager before they can log in to the Enterprise Manager console. Auto provisioning removes that requirement by automatically creating the Enterprise Manager user account upon successful authentication of the user the first time he logs on to Enterprise Manager.

To enable auto provisioning, set the OMS property oracle.sysman.core.security.auth.autoprovisioning to true.

This parameter can be set using emctl or the console.

This allows the external users to login without being first created as an Enterprise Manager user in the Enterprise Manager repository. Their user account gets created automatically upon the first login. Once this property is set, all external LDAP users will be able to login to Enterprise Manager console. If you want to further restrict the auto provisioning feature to a subset of users, such as only to members of certain LDAP groups, then set another OMS property "oracle.sysman.core.security.auth.autoprovisioning_minimum_role". This property should be set to the LDAP group name whose members should be auto-provisioned For example, if set to "EM_ADMIN", only members of that LDAP group called EM_ADMIN will be able to login to Enterprise Manager and have user accounts automatically created in Enterprise Manager.

Using a Different Name to the External Users Display Name

By default, you must log in to Oracle Enterprise Manager with the user name that is displayed in the Weblogic Console >Security Realms >myrealms >Users and Groups >Users list. After authenticating Oracle Enterprise Manager with external providers, the cn values of the external users are listed in Weblogic Console Users list.

In some environments, the cn value is in the form 'FIRST NAME LAST NAME'. If you prefer to use the sAMAccountName or user ID (UID) to login to Oracle Enterprise Manager you must update the provider configurations.

For example, there is a user with the user name 'TEST USER' displayed in the Weblogic Console, but the user wants to login to Oracle Enterprise Manager as 'tuser' which is the sAMAccountName of that user.

Note:

The sAMAccountName is used in this example. To use a UID, replace sAMAccountName with uid in the steps that follow.

  1. In the external provider, check the parameter/properties configured for the external user.

  2. The value of parameter 'cn' is 'TEST USER'.

  3. In the same file, find the parameter that has the value for user as 'tuser' . That parameter may be 'sAMAccountName'.

To use the sAMAccountName of the external users (tuser) to log in to Oracle Enterprise Manager:

  1. Back up the <GCDOMAIN>/config/config.xml file.

  2. On the Weblogic Console, navigate to Security Realms>myrealms>Providers>External Authenticator.

  3. Click Lock and Edit to edit this page.

  4. Click the Provider Specific tab.

  5. Look for the User From Name filter.

  6. Change the value of User From Name from (&(cn=%u)(objectclass=person)) to (&(sAMAccountName=%u)(objectclass=person)).

  7. Look for User Name Attribute.

  8. Change the value of User Name Attribute from cn to sAMAccountName.

  9. Click Save then click Activate Changes.

  10. Restart Oracle Management Server with the -all option:

    <OMS_HOME>/bin>./emctl stop oms -all -force
    <OMS_HOME>/bin>./emctl start oms

  11. Log in to the Weblogic Console >Security Realms >myrealms >Users and Groups >Users list and confirm that the user 'tuser' exist in Users list. Now you can user the user name 'tuser' to log in to Oracle Enterprise Manager.

Updating the Oracle Virtual Directory with User Name Changes

With Oracle Enterprise Manager release 12.1.0.4 and higher, you must perform the following additional steps to update the user name changes in the Oracle Virtual Directory layer:

  1. Backup the <MW_HOME>/oracle_common/common/bin/wlst.sh and <GCDomain>/config/fmwconfig/ovd/default/adapter.os_xml file.
  2. Open the <MW_HOME>/oracle_common/common/bin/wlst.sh file in a text editor and add the following parameter to WLST_PROPERTIES:
    -Dweblogic.ssl.JSSEEnabled=true -Djavax.net.ssl.keyStore=<MW HOME>/wlserver_10.3/server/lib/DemoIdentity.jks
    -Djavax.net.ssl.keyStorePassword=DemoIdentityKeyStorePassPhrase
    -Djavax.net.ssl.trustStore=<MW HOME>/wlserver_10.3/server/lib/DemoTrust.jks
    -Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase
    -Dweblogic.security.SSL.trustedCAKeyStore=<MW HOME>/wlserver_10.3/server/lib/DemoTrust.jks
    -Dweblogic.security.SSL.ignoreHostnameVerification=true 
    

    For example:

    WLST_PROPERTIES="-Dweblogic.ssl.JSSEEnabled=true
    -Djavax.net.ssl.keyStore=/u01/mwr/wlserver_10.3/server/lib/DemoIdentity.jks
    -Djavax.net.ssl.keyStorePassword=DemoIdentityKeyStorePassPhrase
    -Djavax.net.ssl.trustStore=/u01/mwr/wlserver_10.3/server/lib/DemoTrust.jks
    -Djavax.net.ssl.trustStorePassword=DemoTrustKeyStorePassPhrase
    -Dweblogic.security.SSL.trustedCAKeyStore=/u01/mwr/wlserver_10.3/server/lib/DemoTrust.jks
    -Dweblogic.security.SSL.ignoreHostnameVerification=true ${WLST_PROPERTIES}
    -DORACLE_HOME='${ORACLE_HOME}' -DCOMMON_COMPONENTS_HOME='${COMMON_COMPONENTS_HOME}'"
    export WLST_PROPERTIES

    Note:

    If third party or custom certificates are imported to WebLogic Server, you must replace the path in the preceding example with the respective keystores.The custom path is available in the config.xml file.

  3. Launch <MW_HOME>/oracle_common/common/bin/wlst.sh..
  4. Enter the following command to connect to the admin server:
    connect('weblogic','<weblogic password>','t3s://<ADMIN SERVER HOSTNAME>:<ADMIN SERVER PORT>')
    

    For example:

    connect('weblogic','<weblogic password>','t3s://test01.example.com:7102')
    
  5. Enter the following command:
    $addPlugin(adapterName='ADAPTER_NAME',pluginName='changerdn',pluginClass='oracle.ods.virtualization.engine.chain.plugins.changeuserrdn.ChangeUserRDN',paramKeys='replaceValue|fromRDN|toRDN',paramValues='true|cn|sAMAccountName')
    

    Note:

    The name of the LDAP provider on the admin server console must be specified for adapterName parameter in the preceding command.

  6. Enter the following command to stop the OMS:
    <OMS HOME>/bin/emctl stop oms -all -force
    
  7. Ensure no process is running from OMS path.
  8. Enter the following commands to start the admin server and the OMS:
    <OMS HOME>/bin/emctl start oms -admin_only

Mapping LDAP User Attributes to Enterprise Manager User Attributes

When external authentication is enabled, a flashlight icon appears next to the name field in the Create User flow.

Note:

External authentication is enabled when an administrator is first created in Enterprise Manager.

Clicking on the flashlight displays a popup window, giving Enterprise Manager administrators the ability to search for enterprise users in the external LDAP server (for example AD/OID) that have been configured. The user's LDAP attributes are shown as well. This helps the Enterprise Manager administrator to verify external user's attributes before creating them in Enterprise Manager.

When external authentication has been configured, it is often desirable to automatically propagate user information such as email address, department, that is defined for the user in LDAP to the corresponding Enterprise Manager user account. This can be done by setting the OMS property oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings. This property will contain the mapping between the Enterprise Manager user properties and the corresponding LDAP user attributes that will be used to populate the user properties. The mapping between an Enterprise Manager property and an LDAP attribute is expressed in the format <key>={%attribute%}where:

  • key - An Enterprise Manager user property. Values for user properties are:

    USERNAME

    EMAIL

    CONTACT

    LOCATION

    DEPARTMENT

    COSTCENTER

    LINEOFBUSINESS

    DESCRIPTION

    Any other values specified for keys will be ignored.

  • attribute - A user attribute that needs to be fetched from LDAP and is used to set the properties of the user in Enterprise Manager. The attribute should be specified using the following format {%attribute%}, for example {%mail%}

    The value between % should be a valid attribute in the LDAP server. You can also specify literal strings when specifying attribute values, for example:

    DESCRIPTION={%firstname% %lastname% employee}

    In this example, only firstname and lastname will be fetched from LDAP but the description for the user will be "firstname lastname employee". For example, "John Doe employee".

    Another example is CONTACT={telephone number %phone%}. If a comma needs to be specified in the literal string value, it needs to be escaped with "\" For example,

    DESCRIPTION={%lastname% \, %firstname% \, %phone%}

    This will result in a user with description "Doe, John, 212-454-0000". The other characters that need to be escaped with backslash (\), if specified in the literal string, are ':' and '=', so they should be entered as \: or \=.

The OMS property oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings should thus be set to a set of comma separated key-attribute pairs.

As an example, let us assume user JOHNDOE exists in LDAP and has the following attributes:

uid=johndoe,mail=johndoe@example.com,description=EM LDAP Admin,postalcode=90210,department=EnterpriseAdmin,telephone=2124540000,displayname=JohnDoe

If you set OMS property:

oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings to "USERNAME={%uid%},EMAIL={%mail%},CONTACT={%telephone%},DEPARTMENT={%department%},DESCRIPTION={%description%},LOCATION={%postalcode%}" 

then when you select the user from the popup window and hit Ok, the user's attributes are automatically populated in the appropriate fields of the 'Create User' page.

Changing User Display Names in Enterprise Manager

In some LDAP environments, users may have numeric login IDs. Enterprise Manager has the ability to display user-friendly username in when a user logs in using a numeric ID. When they log on to the Enterprise Manager console, the numeric ID is displayed and used everywhere the user's name is shown including audit records. In order to show a more user-friendly name, you can use the OMS property oracle.sysman.core.security.auth.enable_username_mapping to enable the mapping of a an external, more intuitive name than the name shown in Enterprise Manager. You can use emctl to change this property.

emctl set property –name “oracle.sysman.core.security.auth.enable_username_mapping" –value “true" 

You can also set this using the Enterprise Manager console as well. These are dynamic properties and do not require bouncing the Management Service.

Once enabled, an External User ID field will be added that will contain the name or ID used by the user to log on to Enterprise Manager (this name/ID exists as a valid user in LDAP). The Create Administrator page appears.

For example, if external user 123456 wants to log in and johndoe needs to be shown as logged in user, specify 'johndoe' in the Name field.

User 123456 will still log in as that ID as that user exists in the LDAP server as 123456 but the name 'johndoe' will be shown as his user name in the Enterprise Manager console.

The OMS property oracle.sysman.core.security.auth.ldapuserattributes_emuserattributes_mappings can also be used in this environment to automatically populate the user's name and external ID. An extra field called EXTERNALUSERID needs to be set. Using the example above, set the OMS property to the following:

"USERNAME={%displayname%},EXTERNALUSERID={%uid%},EMAIL={%mail%},CONTACT="{%telephone%},DEPARTMENT={%department%},DESCRIPTION={%description%},LOCATION={%postalcode%}"

The features described above are available in EM CLI as well. With the OMS properties set, the EM CLI create_user verb can be used to create users with their LDAP attributes automatically populated.

Configuring Other LDAP/SSO Providers

Oracle Enterprise Manager currently offers native support for Oracle Internet Directory, Oracle Access Manager, Active Directory and Single Sign-On. Native support allows WebLogic Server and Enterprise Manager to be configured for external authentication using the EMCTL command. For more information on configuring Enterprise with Oracle Internet Directory, see"Oracle Internet Directory (OID)", with Active Directory see "Microsoft Active Directory Based Authentication".

LDAP providers need to be marked 'SUFFICIENT' and should be ahead of the Enterprise Manager Repository authenticator in the list of providers.

For SSO providers, please refer to the requirements of the specific SSO provider configuration. Along with configuring the appropriate authentication providers, certain OMS properties have to be set as well in order for Enterprise Manager to work.

For configuring Enterprise Manager with any other type of LDAP server, the following OMS properties need to be set. You can use emctl or the console to set these properties. The properties need to be set for each OMS.

emctl set property -name "oracle.sysman.core.security.auth.is_external_authentication_enabled" -value "true"

  • oracle.sysman.core.security.auth.is_external_authentication_enabled=true.

  • oracle.sysman.emSDK.sec.DirectoryAuthenticationType to LDAP

For configuring Enterprise Manager with any other type of SSO solution, along with configuring the weblogic authentication/identity assertion providers, the following OMS properties need to be set.

  • oracle.sysman.core.security.auth.is_external_authentication_enabled=true

  • oracle.sysman.core.security.sso.type=OTHERSSO

  • oracle.sysman.core.security.sso.logout_url=<whatever value was provided for configuring logout on SSO server>

  • oracle.sysman.emSDK.sec.DirectoryAuthenticationType=SSO

Configuring Single Sign-on based Authentication
Configuring Single-Sign-on with Oracle Access Manager 10g

When using an Oracle Access Manager Single Sign-On authentication scheme, the underlying identity stores will consist of Enterprise Directory Identity Stores supported by Oracle Access Manager. This section provides instructions on how to configure OAM SSO-based authentication schemes.

Prerequisites

Oracle Access Manager is installed.

The Oracle Access Manager Single Sign-On server is configured with Oracle HTTP server, Web Gate, and the Oracle Access Manager Identity Store.

  1. Run the emctl config auth command. This command needs to be executed on all OMSs (Primary and all additional ones).
    emctl config auth oam -oid_host <host> -oid_port <port>
    -oid_principal <principal> [-oid_credential <credential>]
    -user_base_dn <dn> -group_base_dn <dn>
    -oam_host <host> -oam_port <port> [-logout_url <url>] [-is_oam10g] [-user_dn <dn>] [-group_dn <dn>]
    

    Note: Use the -is_oam10g option only if the OAM version is 10g.

  2. Stop each OMS.

    emctl stop oms -all

  3. Restart each OMS.

    emctl start oms

Configuring Single-Sign-on with Oracle AS SSO 10g

If you are currently using Oracle Application Server Single Sign-On to control access and authorization for your enterprise, you can extend those capabilities to the Enterprise Manager console.

By default, Enterprise Manager displays the main logon page. However, you can configure Enterprise Manager so it uses Oracle Application Server Single Sign-On to authenticate your Enterprise Manager users. Instead of seeing the Enterprise Manager logon page, users will see the standard Oracle Application Server Single Sign-On logon page. From the logon page, administrators can use their Oracle Application Server Single Sign-On credentials to access the Oracle Enterprise Manager 13c Cloud Control console.

Note:

  • You can configure Enterprise Manager to use one of the default Oracle Application Server Single Sign-On or Enterprise User Security features, but not both.

  • When Enterprise Manager is configured to use Single Sign-On with Server Load Balancer (SLB), make sure that the correct monitoring settings have been defined.

Partner applications are applications that are designed to delegate authentication to the OracleAS Single Sign-On server. The following sections describe how to configure Enterprise Manager as an OracleAS Single Sign-On Partner Application:

Registering Enterprise Manager as a Partner Application

To register Enterprise Manager as a partner application manually, follow these steps:

  1. Stop all OMSs by running emctl stop oms on each OMS.
  2. Enter the following URL to navigate to the SSO Administration page.
    https://sso_host:sso_port/pls/orasso
    
  3. Log in as orcladmin user and click on SSO Server Administration.
  4. Click Administer Partner Applications and then click Add Partner Application.
  5. Enter the following information on the Add Partner Application page.
    Name: <EMPartnerName>
    Home URL: protocol://em_host:em_port
    Success URL: protocol://em_host:em_port/osso_login_success 
    Logout URL: protocol://em_host:em_port/osso_logout_success
    Administrator Email: user@example.com
    

    Note1: host, port, and protocol refer to the Enterprise Manager host, port and the protocol (http or https) used.

    Note2: The em_host, em_port, email and Enterprise Manager Partner Name must be replaced with the appropriate values and not typed as shown in this example.

  6. Go back to Administer Partner Applications page and click on the Edit icon for <EMPartnerName>.

    Record the values of ID, Token, Encryption Key, Login URL, Single Sign-Off URL, Home URL and write the following in a file osso.txt:

    sso_server_version= v1.2
    cipher_key=<value of EncryptionKey>
    site_id=<value of ID>
    site_token=<value of Token>
    login_url=<value of Login URL>
    logout_url=<value of Single Sign-Off URL>
    cancel_url=<value of Home URL>
    sso_timeout_cookie_name=SSO_ID_TIMEOUT
    sso_timeout_cookie_key=9E231B3C1A3A808A
    
  7. Set the ORACLE_HOME environment variable to WebTier Oracle Home location.

    setenv ORACLE_HOME /scratch/13c/MWHome/Oracle_WT

    Then, run the following:

    $ORACLE_HOME/ohs/bin/iasobf <location of osso.txt> <location of osso.conf>

  8. Run the following command on each OMS:
    emctl config auth sso -ossoconf <osso.conf file loc> -dasurl <DAS URL> [-unsecure] [-domain <domain>]-ldap_host <ldap host> -ldap_port <ldap port> -ldap_principal <ldap principal> [-ldap_credential <ldap credential>] -user_base_dn <user base DN> -group_base_dn <group base DN> [-logout_url <sso logout url>]
    

    where ldap_host, ldap_port, ldap_principal and ldap_credential are the details of SSO's LDAP.

    The sample output for this command is shown below:

    Oracle Enterprise Manager Cloud Control 13c Release 12.1.0.3.0
    Copyright (c) 1996, 2013 Oracle Corporation.  All rights reserved.
    SSO Configuration done successfully. Please restart Admin & Managed Servers.
    
  9. Run the following commands on each OMS:
    emctl stop oms -all
    emctl start oms
Removing Single Sign-On Configuration

To remove the single sign-on configuration, perform the following:

  1. Run the following command on each OMS:
    emctl config auth repos
    

    Sample command output:

    Oracle Enterprise Manager Cloud Control 13c Release 5
    Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
    Configuring Repos Authentication ... Started
    Configuring Repos Authentication ... Successful
    
    

    If you have updated files such as, for example, httpd.conf (when installing WebGate) or any other required files should be backed up prior in order to rolled back during this step.If you are using multi-OMS environment, you must execute emctl config auth repos on the remaining servers.

  2. Bounce all OMSs by issuing the following on each OMS:
    emctl stop oms -all
    emctl start oms

Registering Single Sign-On Users as Enterprise Manager Administrators

After you have configured Enterprise Manager to use the Single Sign-On logon page, you can register any Single Sign-On user as an Enterprise Manager administrator. You can register single sign-on users using:

  • Enterprise Manager Graphical User Interface

  • Enterprise Manager Command Line Interface

Registering Single Sign-On Users Using the Graphical User Interface

You can use the graphical user interface to register single sign-on users by following these steps:

  1. Go the Enterprise Manager Console URL.

    The browser is redirected to the standard Single Sign-On Logon page.

  2. Enter the credentials for a valid Single Sign-On user. Note: This step requires that an SSO user is already registered with Enterprise Manager.

    If no SSO user is yet registered as Enterprise Manager user, you can create them using the following procedure:

    1. Navigate to Enterprise Manager by connecting to the OMS directly. For example, https://oms_host:oms_https_port/em.

    2. Log in as a Repository user.

    3. From the Setup menu, select Security then select Administrator

    4. Create SSO users.

  3. Log in to Enterprise Manager as a Super Administrator.
  4. From the Setup menu, select Security, then select Administrators to display the Administrators page.

    Because Enterprise Manager has been configured to use Single Sign-On, the first page in the Create Administrator wizard now offers you the option of creating an administrator either as an External User or as Repository User.

  5. Select External User Identity Store and advance to the next page in the wizard.
  6. Enter the name and e-mail address of the External User Identity Store user, or click the flashlight icon to search for a user name in the Oracle Internet Directory.
  7. Use the rest of the wizard pages to define the roles, system privileges, and other characteristics of the Enterprise Manager administrator and then click Finish.

    Enterprise Manager displays a summary page that lists the characteristics of the administrator account.

  8. Click Finish to create the new Enterprise Manager administrator.

    The External User Identity Store user is now included in the list of Enterprise Manager administrators. You can now verify the account by logging out of the Cloud Control console and logging back in using the External User Identity Store user credentials on the Single Sign-On logon page.

Registering Single Sign-On Users Using EM CLI

You can use the following EM CLI command to create Single Sign-On users:

emcli create_user -name=ssouser -type=EXTERNAL_USER

This command creates a user with the name ssouser who is authenticated against the single sign-on user.

Argument Description

-name

Name of the administrator.

-type

The type of user. The default value for this parameter is EM_USER. The other possible values are:

  • EXTERNAL_USER: Used for single-sign-on based authentication.

  • DB_EXTERNAL_USER: Used for enterprise user based security authentication.

-password

The password for the newly created administrator.

-roles

The list of roles that can be granted to this administrator.

-email

The list of email addresses for this administrator.

-privilege

The system privileges that can be granted to the administrator. This option can be specified more than once.

-profile

The name of the database profile. This is an optional parameter. The default profile used is DEFAULT.

-desc

The description of the user being added.

-expired

This parameter is used to set the password to "expired" status. This is an optional parameter and is set to False by default.

-prevent_change_password

When this parameter is set to True, the user cannot change the password. This is an optional parameter and is set to False by default.

-input_file

This parameter allows the administrator to provide the values for any of these arguments in an input file. The format of value is name_of_argument:file_path_with_file_name.

Example 1

emcli create_user
         -name="new_admin"
         -email="john.doe@example.com;jane.doe@example.com"
         -roles="public"
         -privilege="view_job;923470234ABCDFE23018494753091111"
         -privilege="view_target;<host>.com:host" 

This example creates an Enterprise Manager administrator named new_admin. This administrator has two privileges: the ability to view the job with ID 923470234ABCDFE23018494753091111 and the ability to view the target <host>.com:host. The administrator new_admin is granted the PUBLIC role.

Example 2

   emcli create_user
         -name="User1"
         -type="EXTERNAL_USER"
         -input_file="privilege:/home/user1/priv_file"

         Contents of priv_file are:
           view_target;<host>.com:host

This example makes user1 which has been created externally as an Enterprise Manager user. user1 will have view privileges on <host>.com:host.

Example 3

   emcli create_user
         -name="User1"
         -desc="This is temp hire."
         -prevent_change_password="true"
         -profile="MGMT_ADMIN_USER_PROFILE"

This example sets user1 as an Enterprise Manager user with some description. The prevent_change_password is set to true to indicate that the password cannot be changed by user1 and the profile is set to MGMT_ADMIN_USER_PROFILE.

Example 4

   emcli create_user
         -name="User1"
         -desc="This is temp hire."
         -expire="true" 

This example sets user1 as an Enterprise Manager with some description. Since the password is set to expire immediately, when the user logs in for the first time, he is prompted to change the password.

Bypassing the Single Sign-On Logon Page

If the OMS is configured with SSO or OAM or some other authentication method, you may want to by-pass the Single Sign-On or OAM authentication under certain circumstances. To bypass the SSO logon page, connect to the following URL:

  1. Connect to https://ms_host:ms_https_port/em

    ms_host & ms_https_port are WLS-managed server's hostname and port. These parameters can be found in the <EM_INSTANCE_HOME>/emgc.properties file. They are listed as EM_INSTANCE_HOST & MS_HTTPS_PORT in this file.

  2. Log in using a repository user's credentials.
Restoring the Default Authentication Method
  1. Run the following command on each OMS:
    emctl config auth repos
    

    Sample command output:

    Oracle Enterprise Manager Cloud Control 13c Release 5
    Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
    Configuring Repos Authentication ... Started
    Configuring Repos Authentication ... Successful
    If you have updated files like httpd.conf (for example, while installing WebGate), rollback them.
    If this is a multi-OMS environment, execute this command on remaining servers.
    After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
    
  2. Run the following commands on each OMS:
    emctl stop oms -all
    emctl start oms

Configuring Enterprise User Security based Authentication

For instructions on configuring Enterprise Manager for use with Enterprise User Security, see "Enterprise User Security Based Authentication".

Restoring to the Default Authentication Method

The following sections provide instructions on restoring the default authentication method used by Enterprise Manager.

Bypassing the Single Sign-On Logon Page

If the OMS is configured with SSO or OAM or some other authentication method, you may want to by-pass the Single Sign-On or OAM authentication under certain circumstances.To bypass the SSO logon page, connect to the following URL:

  1. Connect to https://ms_host:ms_https_port/em

    ms_host & ms_https_port are WLS-managed server's hostname & port#. These parameters can be found in the EM_INSTANCE_HOME/emgc.properties file. They are listed as EM_INSTANCE_HOST & MS_HTTPS_PORT in this file.

  2. Log in using a repository user's credentials.
Restoring the Default Authentication Method
  1. Run the following command on each OMS:
    emctl config auth repos
    

    Sample command output:

    Oracle Enterprise Manager Cloud Control 13c Release 5
    Copyright (c) 1996, 2021 Oracle Corporation.  All rights reserved.
    Configuring Repos Authentication ... Started
    Configuring Repos Authentication ... Successful
    If you have updated files like httpd.conf (for example, while installing WebGate), rollback them.
    If this is a multi-OMS environment, execute this command on remaining servers.
    After that, restart OMS(s) using: 'emctl stop oms -all' and 'emctl start oms'
    
  2. Run the following commands on each OMS:
    emctl stop oms -all
    emctl start oms

Configuring Privileges and Role Authorization

Giving the same level of access to all targets to all administrators is dangerous. Also, 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, these tasks can be streamlined and can easily scale as the enterprise grows. 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 roles and privileges assigned to each user class.

Note:

An administrator without any privileges or assigned targets should not be able to see monitored targets from within Enterprise Manager. When logging in to Enterprise Manager as a new administrator without any roles or privileges assigned, all targets will be displayed (security issue) unless the EXEMPT ACCESS POLICY privilege is revoked for the Enterprise Manager Super Administrator SYSMAN.

The system privilege EXEMPT ACCESS POLICY allows a user to be exempted from all fine-grained access control policies on any SELECT or DML operation (INSERT, UPDATE, and DELETE). This provides ease of use for administrative activities such as installation and import and export of the database through a non-SYS schema.

Also, regardless of the utility or application that is being used, if a user is granted the EXEMPT ACCESS POLICY privilege, then the user is exempt from VPD and Oracle Label Security policy enforcement. That is, the user will not have any VPD or Oracle Label Security policies applied to their data access.

To resolve the issue:

Connect to the Enterprise Manager Repository database as SYS or SYSTEM user and execute the following SQL statement:

SQL> revoke EXEMPT ACCESS POLICY from sysman;

Understanding Users, Privileges, and Roles

When an Enterprise Manager administrator adds a user to the system, the primary consideration must be what does this person need to do in order to perform his job? Once the job for this new user is defined and understood, appropriate privileges must be assigned to this user and access granted to the required systems required to complete the job.

Privileges are ultimately granted to administrators to enable them to manage targets in Enterprise Manager. While you can grant specific privileges to individual administrators, tracking and granting privileges on many targets across many administrators easily becomes error-prone and an administrative burden in itself. Our recommendation is to define and use roles to manage the granting of privileges to administrators.

A role is a user-defined set of privileges typically containing the set of privileges that you want to grant to a team of users. A role can contain other roles as well. For example, you can create a First Line Support role containing the privileges needed for the administrators to view and manage incidents on targets. Once this role is created, you can grant this role to the appropriate administrators who will manage these incidents as part of their job responsibility. If you need to change the set of privileges for your administrators, e.g. add new privileges or remove privileges, then all you need to do is update the role. The updated set of privileges in the role is automatically enabled for the administrators to whom the role has been granted. Likewise if new administrators are added, all you need to do is grant them the appropriate role(s) instead of granting them individual privileges. See "Classes of Users" for more information.

Using roles is one big step towards managing privileges. However, there is still the challenge of having to keep the role updated with privileges on new targets as they are added to Enterprise Manager.

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.

The Enterprise Manager administrators you create and manage in the Enterprise Manager console are granted privileges and roles to log in to the Enterprise Manager console and to manage specific target types and to perform specific management tasks. The default super administrator for the Enterprise Manager console is the SYSMAN user, which is a database user associated with the Oracle Management Repository. You define the password for the SYSMAN account during the Enterprise Manager installation procedure.

By restricting access to privileged users and providing tools to secure communications between Oracle Enterprise Manager 13c components, Enterprise Manager protects critical information in the Oracle Management Repository.

The Management Repository contains management data that Enterprise Manager uses to help you monitor the performance and availability of your entire enterprise. This data provides you with information about the types of hardware and software you have deployed, as well as the historical performance and specific characteristics of the applications, databases, applications servers, and other targets that you manage. The Management Repository also contains information about the Enterprise Manager administrators who have the privileges to access the management data.

You can create and manage multiple Enterprise Manager administrator accounts, or EM users, using the EM interface. Each administrator account includes its own login credentials, as well as a set of roles and privileges that are assigned to the account. There are three classes of users:

  • Super Administrator: A powerful EM user with special access privileges to targets and other user accounts within the Enterprise Manager environment. The Super Administrator SYSMAN is created by default when Enterprise Manager is installed. A Super Administrator can:

    • Perform the initial setup of Enterprise Manager. For example, defining e-mail configurations and defining global notifications rules.
    • Create other administrators.
    • Add and view all targets discovered in Enterprise Manager.
    • Create Enterprise Manager privileges and roles.
    • View all jobs and reports in the system and edit only jobs or reports that it owns.
    • View its own Named Credentials (cannot view Named Credentials created by other EM users or the SYSMAN user). For more details on Named Credentials, see Named Credentials.
    • Manage jobs and deployment procedures that it owns (cannot manage jobs or deployment procedures created by other users).

    Note that secure privileges are not granted to Super Administrators by default, but they can be granted to a private role and that role can be granted to a Super Administrator. For more details, see Private Roles.

  • Administrator: A regular Enterprise Manager administrator.

  • Repository Owner: A database administrator for the Management Repository database. This account cannot be modified, duplicated, or deleted.

The types of management tasks that the administrator can perform and targets that he can access depends on the roles, system privileges, resource privileges, and target privileges that he is granted. The Super Administrator can choose to let certain administrators perform only certain management tasks, or access only certain targets, or perform certain management tasks on certain targets. In this way, the Super Administrator can assign the minimum level of privileges that administrators need to do their job.

Reassigning Objects

To reassign objects from one Enterprise Manager administrator to another in preparation for deleting an administrator:

  1. Navigate to the Setup > Security > Administrators page.e.

  2. Select the administrator to be deleted, then click View to see all objects currently owned by the selected administrator.

  3. To reassign the objects to another administrator, enter the name of the new administrator in the New Owner text box, or click the flashlight icon to view a list of available administrators.

  4. Choose the desired Administrator to whom the objects must be reassigned then complete the operation.

Note:

A super administrator can use the Delete Administrator page to specify what happens to administrator-owned objects when removing an administrator from Enterprise Manager. On this page, a super administrator can:

  • Delete all administrator-owned objects along with the Enterprise Manager administrator

  • Reassign objects to another Enterprise Manager administrator

Note:

Only a Super Administrator can delete other Enterprise Manager administrators. Enterprise Manager will not allow administrators to:

  • Delete themselves

  • Delete the Management Repository owner

Administrator object reassignments can be handled as follows:

  • Blackouts can be reassigned to any user who has OPERATOR privileges on all targets affected by the blackout.

  • Jobs can be reassigned to any administrator. However, ALL credentials associated with the job will be removed, leaving the job in a Suspended state. This requires the new job owner to explicitly set new credentials. Currently running jobs are allowed to continue running. After the new job owner sets the credentials, the job will revert to a SCHEDULED state.

  • Corrective Actions can be reassigned to any administrator who has OPERATOR privileges for targets on which the corrective action can operate.

  • Report Definitions can be reassigned to any administrator.

  • Reports can be reassigned to any administrator.

  • Monitoring Templates can be reassigned to any administrator.

Aggregate Target Privileges

An Aggregate Target type is a target that has one or more member targets, for example groups, systems, or Real Application Cluster. Aggregate target privileges allows an Administrator to grant different levels of privileges to the member targets and to the Aggregate target. For example, an Administrator may want to grant VIEW privilege on the aggregate group level and FULL to each member target within the group. If the administrator does not grant specific privileges on the aggregate and its members, the default is the same privilege for the aggregate and it members.

For example, you can grant VIEW privilege at a group (Aggregate level) and FULL at the member target level. This allows a DBA granted FULL on a member target to perform full life cycle tasks including delete of the target. The DBA has VIEW privilege on the group, preventing him from deleting the group.

You can view/modify these privilege settings when creating or editing an Enterprise Manager administrator. From the Setup menu, select Security, and then select Administrators. Navigate to the Target Privilege page.

At the bottom of the Target Privileges page, you will find the Target Privileges region.

Check the Advanced Privilege Settings option to view settings for the aggregate target types that have been added to the user.

Two additional columns are displayed:

  • Manage Aggregate Only Privilege Grants

  • Manage Member Only Privilege Grants

Click the Edit (pencil) icon to change the privilege grant properties.

Privileges and Roles

Granting users specific privileges provide a basic level of security in Enterprise Manager. They are designed to control access to data and limit the management operations you can perform in Enterprise Manager such as changing monitoring settings or patching targets.

When Enterprise Manager is installed, the SYSMAN user (Super Administrator) is created by default. The SYSMAN Super Administrator can then create other administrator accounts for daily administration work. The SYSMAN account should only be used to perform infrequent system-wide, global configuration tasks.

The Super Administrator should grant the minimum level of privileges required to allow administrators to perform their tasks within Enterprise Manager. For example, the Super Administrator can allow some administrators to view any target and to add any target in the enterprise and other administrators to only perform specific operations such as maintaining and cloning on a target for which they are responsible.

Administrators and Database Privileges

Having DBA privileges on a database allows users to delete other database users, drop tables and perform other administrative operations. Hence, having DBA privileges on a repository database allows an administrator to perform all operations that can be performed as an Enterprise Manager Super Administrator: The administrator is implicitly treated as a Super Administrator. This is similar to OS authentication supported by the database where OS users with "DBA" privileges can connect to the Oracle server and exercise SYSDBA privileges.

If this level of access is not the intended behavior, Oracle recommends using one of the following:

  • The Enterprise Manager repository database needs to be considered as a special database. Do not grant DBA privileges to any users on that database other than to users who have Super Administrator privileges in Enterprise Manager.

  • Set up external authentication and migrate Enterprise Manager users to Active Directory or LDAP. This ensures that there are no shadow database users for Enterprise Manager application users being created and so DBA privileges cannot be granted to Enterprise Manager users.

Note:

Enterprise Manager administrators should not be given DBA privileges.

In situations where an Enterprise Manager Super Administrator has DBA privileges, SYSMAN will NOT be able to convert that user into a regular (non-Super Administrator) administrator until DBA privileges have are removed.

Granting Privileges

A privilege is a right to perform management actions within Enterprise Manager. Privileges can be divided into two categories:

  • Target Privileges

  • Resource Privileges

Target Privileges: These privileges allow an administrator to perform operations on a target. As such, there is a defined hierarchy the categorizes target privileges into the following levels:

  • FULL: Highest level that includes OPERATOR and VIEW

  • OPERATOR: Medium level that permits specific management actions. OPERATOR privilege is also an example of a privilege that can include other privileges. For example, OPERATOR privileges include blackout privileges, and any user granted an OPERATOR target privilege is automatically granted the Blackout Target privilege. See Table C-2 for more information.

  • VIEW: Lowest level permitting only view access to targets.

There are two categories of target privileges:

  • Privileges applicable to all targets. These privileges allow administrators to perform operations on all components with the Enterprise Manager infrastructure.

  • Privileges applicable to a specific target instance. These privileges allow Administrators to perform operations on specific targets in the Enterprise Manager infrastructure.

The Target Privileges page shows a list of privileges granted to all targets. For a detailed list of target privileges, see Privileges..

Resource Privileges: These privileges grant administrator access to a specific functionality within Enterprise Manager. Examples of 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 refer to the Privileges and Roles section of Oracle Enterprise Manager Cloud Control Security Guide.

For example, to grant an administrator the ability to create new named credentials:

  1. From the Setup menu, select Security and then Administrators. The Administrators page displays.

  2. Either edit and existing administrator or create a new administrator to access the Administrator wizard.

  3. Proceed to the Resource Privileges page.

  4. From the Resource Type column, scroll down to Named Credential.

  5. From the Manage Privilege Grants column, click on the corresponding pencil icon. The Resource Type Privileges page displays.

  6. Select the privilege Create new named credential and click Continue to proceed with the administrator creation/edit processes

Fine-grained Access Control

Enterprise Manager implements granular privileges to control access to targets and other resources, enabling 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). From the Security Console, you can view:

  • The list of super administrators

  • Administrators with highest number of direct privileges

  • Target privileges

  • Resource privileges

  • The top five Administrators with the highest number of roles

  • Roles with the highest number of nested roles

Creating Roles

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. Administrators do not want to perform the task of individually granting access to tens, hundreds, or even thousands of targets to every new member of their group.By creating roles, an administrator needs only to assign the role that includes all the appropriate privileges to his team members instead of having to grant many individual privileges. He can divide workload among his administrators by filtering target access, or filtering access to management tasks, or both. You can also configure Enterprise Manager to work with an external authentication provider to manage authorization as well by using external roles. For more information, see "External Authorization using External Roles".

Out-of-Box Roles: Enterprise Manager Cloud Control 13c comes with predefined roles to manage a wide variety of resource and target types. The following table lists some of the roles along with their function. The number and type of roles displayed depend on the number and type of installed plug-ins. For a complete list of out-of-box roles, see Out-of-Box Roles.

Public Roles: Enterprise Manager creates one role by default called Public. This role is unique in that it is automatically assigned to all new non-super administrators when they are created. By default it has no privileges assigned to it. The Public role should be used to define default privileges you expect to assign to a majority of non-super administrators you create. Privileges need not be assigned to Public initially - they can be added at any time. The role may be deleted if your enterprise does not wish to use it. If deleted, it can be added back in later if you later decide to implement it.

Private Roles

Private Roles are a new role type introduced in Enterprise Manager Release 12.1.0.4 and are used to control the granting of sensitive/powerful privileges to administrators or roles. There are certain sensitive privileges which Enterprise Manager does not make available to Super Administrators. Specifically, they are:

  • LAUNCH_DP

  • FULL_DP

  • GET_CREDENTIAL

  • EDIT_CREDENTIAL

  • FULL_CREDENTIAL

  • FULL_JOB

These privileges are particularly sensitive and powerful, which is the reason Enterprise Manager does not grant these privileges to roles. Granting these privileges to roles would also make them available to other Administrators.

To accommodate the granting of these types of privileges in a more secure manner, roles are divided into two categories - system roles and private roles.

  • Private roles are managed by administrators with the "create_role" privilege. Administrators granted the "create_role" privilege (Private Role) will maintain the lifecycle of the named credential and job roles, and will allow an administrator to grant these full job and full credential privileges to other administrators and to roles.

  • System roles define all roles accessible to all Administrators with the "manage_system_role" privilege.

A private role can be granted to other administrators and roles via the Enterprise Manager console and EM CLI using the emcli create_role verb, and made grantable via emcli grant_privs verb.

Example 1:

emcli create_role
     -name="my_private_role"
     -type="EM_ROLE"
     -desc="This is a new private role called my_private_role"
     -roles="role1;role2;role3"
     -privilege="full_job;923470234ABCDFE23018494753091111"
     -privilege="FULL_CREDENTIAL;CRED_NAME=cred1:CRED_OWNER=user2"
     -users="USER1;USER2:WITH_ADMIN"
     -private_role[ Optional ]

This will create my_private_role owned by the logged-in user.

USER1 will be granted this role as WITHOUT_ADMIN option and USER2 will be granted this role as WITH_ADMIN option.

This role will consists FULL_JOB and FULL_CREDENTIAL privileges on respective objects.

The owner of a private role can grant this role to an administrator, and can specify if the other administrator has the right to further grant this private role to another administrator (by using the –WITH_ADMIN option) or to another private role. In effect, the role owner is privately administering access to this role, hence the name "private role." A system role can be granted to a private role, but a private role cannot be granted to a system role.

Verbs where the -WITH_ADMIN option is supported:

create_role -users

modify_role -users

create_user -roles

modify_user -roles

grant_roles -roles

Using Roles to Manage Privileges

Privileges are ultimately granted to administrators to enable them to manage targets in Enterprise Manager. While you can grant specific privileges to individual administrators, tracking and granting privileges on many targets across many administrators easily becomes error-prone and an administrative burden in itself. Our recommendation is to define and use roles to manage the granting of privileges to administrators. A role is a user-defined set of privileges typically containing the set of privileges that you want to grant to a team of users. A role can contain other roles as well. For example, you can create a First Line Support role containing the privileges needed for the administrators to view and manage incidents on targets. Once this role is created, you can grant this role to the appropriate administrators who will manage these incidents as part of their job responsibility. If you need to change the set of privileges for your administrators, e.g. add new privileges or remove privileges, then all you need to do is update the role. The updated set of privileges in the role is automatically enabled for the administrators to whom the role has been granted. Likewise if new administrators are added, all you need to do is grant them the appropriate role(s) instead of granting them individual privileges.

Using roles is one big step towards managing privileges. However, there is still the challenge of having to keep the role updated with privileges on new targets as they are added to Enterprise Manager. Privilege-propagating groups are meant to address this challenge and will be discussed next.

Managing Privileges with Privilege Propagating Groups

To manage the granting of privileges across potentially hundreds or thousands of targets to a large set of administrators, use privilege propagating groups in conjunction with roles. A group is a user-defined collection of targets that you can create in order to manage and monitor the targets collectively as a unit. A privilege propagating group is a special type of group where a privilege that is granted on the group to a user automatically gives him that same privilege to all existing and new members of the group.

Leverage the privilege-propagating nature of Administration Groups

Enterprise Manager administration groups are privilege-propagating in nature. This means that a privilege on the administration group that is granted to a user or a role automatically propagates to all members of the group including any subgroups. If a new target is added to an administration group, then because the administration group is privilege-propagating, the user or role that has privileges on the administration group automatically gets privileges on the newly added target by virtue of it joining the group. No additional work is needed for granting privileges on the new target. Thus granting target privileges is much simpler because all you need to do is a one-time setup of granting privileges on the group to a role.

Create Roles for Different Job Responsibilities

After you have planned the various job responsibilities and mapped these to the corresponding privileges in Enterprise Manager, the next step is to create roles in Enterprise Manager containing privileges required for each job responsibility. In our example below, here are the various roles that need to be created for each job responsibility. Note that when it comes to privileges on targets in the administration group, the recommendation is to grant the privilege on the administration group and not on individual targets in order to leverage the privilege propagating nature of administration groups.

Table 2-1 EXAMPLES OF ROLES YOU CAN CREATE FOR DIFFERENT JOB RESPONSIBILITES*

JOB RESPONSIBILITY ROLE IN ENTERPRISE MANAGER PRIVILEGES IN THE ROLE(MINIMUM SET)

Group Administrator

Responsible for defining group membership and for granting privileges on the group to other administrators.

GROUP_ADMIN_ROLE

Group Administration on the group

Senior Administrator

Responsible for adding and removing targets in Enterprise Manager, and for planning and setting up monitoring settings for targets. He is also responsible for setting up rules related to creating incidents for events and sending notifications.

SENIOR_ADMIN_ROLE

Add Any Target

Create Enterprise Rule Set

Operator on the group

Create on Job System

EM_TC_DESIGNER role

Target Owner

For the targets he owns, he is responsible for setting monitoring settings, responding to events/incidents, and for performing maintenance operations

TARGET_OWNER_ROLE

Operator on the Administration Group(s) that he is managing

Create on Job System

View Any Monitoring Template

View on the Template Collection(s) associated with the group(s) he is managing

First Level Support

Responsible for responding to events/incidents on targets. As part of operational procedures, he is allowed to blackout a target that is down.

FIRST_LEVEL_SUPPORT

Manage Target Events on the appropriate Administration Group(s)

Blackout Target on the appropriate Administration Group(s)

The privileges listed in the table represent the minimum set of privileges in the role. Additional privileges can be added based on other responsibilities. Also note that you will need to have Super Administrator privileges to create roles. Once roles have been defined, you can now grant these roles to your Enterprise Manager administrators. This can be done in several ways:

  • Assign roles while creating/editing an Enterprise Manager administrator.

  • As part of creating/editing a role, you to choose administrators to whom you would like to grant the role.

  • When creating/editing administrators using the Enterprise Manager Command Line tool (EM CLI), you can specify the roles granted to the user. You can also use EM CLI to grant roles directly to an existing user.

As an example, say you want to grant Operator privileges on host targets used by the development team to all members of the development team. You can first ceate a privilege propagating group (Devt-Group) containing the relevant host targets. Then create a role (Devt-Role) and in this role include Operator privileges on Devt-Group. Finally grant the Devt-Role to all members of the development team. This will result in providing all members of the development team Operator privileges on all targets in Devt-Group. As new host targets are added, you can simply add these new targets to Devt-Group and all members of the development team automatically obtain Operator privileges on the newly added targets. The following scenarios provide additional examples of using privilege propagating groups with roles.

We shall step through two use cases which outline when best to use privilege propagating groups, how to create target groups, add member to this group, and assign roles and Administrators to these target groups.

Example1: Granting various teams different levels of access to target groups

Consider a collection of Database Instances and WebLogic Servers within an organization are managed by separate teams within the organization. Both teams are using Enterprise Manager to manage their targets.The DBAs want full access privileges to their Database Instances and view privileges on the WebLogic Servers. Similarly, the WebLogic Server administrators want full privileges on the WebLogic Servers and view privileges on the Database Instances.

To manage privileges across the two teams, first create two privilege propagating groups containing the targets of the respective teams. For example, you can create a target group called DBAGroup containing the database Instances and another target group called WLSGroup containing the Oracle WebLogic Servers. DBAGroup contains the Database Instances that can be modified and managed by DBAs. While the WLSGroup is a group of Web Logic Servers modified and managed by the Web Logic Server administrators . Additionally, the DBAs want to view the Web Logic Server targets and the Web Logic Server technicians want to view the Database Instances. The following steps will show how to set up these target groups, privileges and roles, and how to grant the appropriate roles to the correct Administrator.

Here are the steps to follow:

  1. Create a target group. On the console go to Targets->Groups from the drop down menu.
  2. Click "Create" from the menu and select "Group" from the drop down menu.
  3. Enter the name DBAGroup.

    Enable "Privilege Propagation" group, by checking the box. This allows Administrators to do a one-time grant of privileges on a group to a user and that privilege will automatically be propagated (or applied) to each member of that group.

  4. Add the database targets you want to add to the new database group, DBAGroup. This is done by hitting the "Add" button, selecting the Database Instance targets from the list. Click the "Select" button.
  5. Select "OK".
  6. Your new group, DBAGroup, should be displayed in the list of available groups.
  7. Now create a second privilege propagating group, by repeating the steps 1-6, calling it WLSGroup, and adding the appropriate WebLogice Server targets to this group.
  8. Your second group, WLSGroup, should be displayed in the list of available groups.
  9. Next, create the Roles. A role contains privileges that can be granted to an administrator. Proceed to the Roles page. Go to the Setup->Security->Roles page.
  10. Click Create.
  11. On the Properties page, type the name of your role. In this example we have named it DBA-ROLE. This Role will contain privileges for the DBA team. It will contain Full privilege on all database Instances in the DBAGroup and view privilege on all Web Logic Server Instances in the WLSGroup. Click the "Next" button.
  12. On the Roles page, click Next.
  13. On the "Target Privileges" page, scroll down to the "Target Privileges" section, at the bottom of the page. Click the "Add" button. The list of available targets is displayed. Select the "Group" Target Type, to improve the search. Select the two groups we just created, DBAGroup and WLSGroup.
  14. Our two groups will be displayed. For this role, DBA-ROLE, we want to grant "Full" on all databases in the DBAGroup and grant "View" on all WebLogic server targets in the WLSGroup. As the default privilege is "View" we need only modify the DBAGroup privilege for this Role, leaving the WLSGroup, with the default "View" privilege. This is done by selecting the pencil icon, to the right of "View" in the "Manage Target Privilege Grants" column. Click the "Continue" button.
  15. Click the privilege "Full", select the "Continue" button.
  16. The new privilege will be displayed. Select the "Next" button.
  17. Select the "Next" button on the Resource Privilege page.
  18. Select the Administrators you want to grant this role, DBA-ROLE too. Select the "Next" button.
  19. Review the setting of your new role DBA-ROLE.
  20. Next we create our second Role, WLS-ROLE. This Role will allow users granted this role full privilege on all the WebLogic Servers in WLSGroup and view privilege on all Database Instances in the DBAGroup. Repeat Steps 10-19, naming our second Role WLS-ROLE. Proceed to the review page, as displayed below.
Example 2: Granting developers view access to target database instances.

DBAs within data centers typically provide application developers read-only access to database performance pages in Enterprise Manager in order for them to view firsthand information on the impact of their applications on the underlying database and restrict them from performing any write operations on the database. The DBAs may not want to share database user account information with the developers nor create individual user accounts on every Database Instance.

You can use the 'Connect Target Read-Only' privilege to enable read-only access to a target. To manage the granting of this privilege across many databases to a team of developers, you can create a privilege propagating group, and add the Database Instances to this target group, calling it, for example DevGroup. You create a role, for example DEV-ROLE and grant the privilege, "Connect Target Read-Only" on his Role, in doing so, you assign this Role to each Developer, granting him access to the performance data in those Database Instances. As these engineers do not have individual user accounts on each Database Instance we will create a Named Credential, call it DevCred which contains database user credentials and we will assign this Named Credential to each Developer needing access to the performance data in the Database Instances. The following steps will show you how to set up the target group and assign Roles and Named Credentials to this group.

Here are the steps to follow:

  1. Create a group of targets. On the console go to Targets->Groups from the drop down menu.
  2. Click "Create" and select "Group" from the drop down menu.
  3. Enter the name of your new target group, for this User Case we shall call it DevGroup.
  4. Enable "Privilege Propagation" group, by checking the box. This allows Administrators to do a one-time grant privileges on a group to a user and have that privilege be automatically propagated (or applied) to each member of that group. Add the database Targets you want to add to the group. This is done by hitting the "Add" button and selecting the Targets from the list.
  5. Select "OK".
  6. The new target group, DevGroup, is displayed in the list of available groups.
  7. Next, create a view only Role for the Target DevGroup. A Role is a privilege that is granted to an Administrator. Proceed to the Roles page, go to the Setup->Security->Roles page.
  8. Click "Create" button.
  9. On the General page, type the name of the new Role, DEV-ROLE, click the "Next" button.

    Create role page

  10. Click "Next" on the "Roles" page.
  11. On the "Target Privileges" page, scroll down to the "Target Privileges" section, at the bottom of the page. Click the "Add" button. The available targets are displayed. Select the "Group" Target Type, to improve the search. Select the group we just created, DevGroup. Click the "Select" button.
  12. The target group is displayed. For this role, DEV-ROLE, we want to grant "Connect Target Read-Only" on all databases in the DevGroup. This is done by selecting the pencil icon, to the right of "View" in the "Manage Target Privilege Grants" column.
  13. Click the privilege "Connect Target Read-Only", scroll to the bottom of the page. Select the "Continue" button.
  14. The new privilege is displayed. Select the "Next" button
  15. Select the "Next" button on the Resource Privilege page.
  16. Select the Administrators you want to grant this role, DEV-ROLE too. Select the "Next" button.
  17. Review the setting of your new role DEV-ROLE.
  18. Next we will create a Named Credential. In this case a Named Credential contains the database credentials used to log on to the database. It will be used by the developer to access the database performance pages in Enterprise Manager. Follow the link "Setup"->"Security"->"Named Credential".
  19. Click the "Create" button.
  20. Enter the Username and Password information that this Named Credential will use to log onto the database. We have selected the following information:

    Credential name: DevCred

    Authenticating Target Type: Database Instance -For this Use Case, we are interested in granting access to the development engineers the database Instances in the DevGroup.

    Credential Type: Database Credentials - For this Use Case, we are supplying the username and password for the target Type specified above.

    Scope: Global - For this User Case, this username and password will apply to every Database. Click the "Test and Save" button.

  21. Enter a valid "Test Target Name", and click Test and Save.
  22. Our new Named Credential will be displayed. To Grant this Named Credential to a one of the development Engineers, click Manage Access.
  23. Click the "Add Grant" button.
  24. Select the Development Engineers you wish to use this Named Credential. Click the "Select" button.
  25. The User information is displayed at the bottom of the page. More users may be added, if desired.
  26. When this Development Engineer logs into Enterprise Manager they will have access to view necessary data, such as performance information. However, as expected, they are unable to perform any write operation to the databases. If the user does attempt to perform a write operation on any database, the following error is displayed in Enterprise Manager:

    Failed to commit: Enterprise Manager has blocked you from performing the task as you are performing this operation using a READONLY connection.

Entitlement Summary

The Administrators Entitlement page displays all the privileges and roles granted to that Administrator. This page also summarizes an Administrators access to targets as well as displaying the named credentials and secure resources owned by that Administrator. The following fiture shows an example of the Enterprise Manager Administrator Entitlement page. You can access this page by clicking on the dropdown menu, beside the Administrators name, and clicking Entitlement Summary.

Configuring Secure Communication

This section contains the following topics:

About Secure Communication

Enterprise Manager Framework Security provides safe and secure communication channels between the components of Enterprise Manager. For example, Framework Security provides secure connections between your Oracle Management Service and its Management Agents. Secure communication also protects against network threats such as eavesdropping and ensures confidentiality/integrity by utilizing technologies such as public-key cryptography.

See Also:

Oracle Enterprise Manager Concepts for an overview of Enterprise Manager components.

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.

    See Also:

    For an overview of Public Key Infrastructure features, such as digital certificates and public keys, see the Oracle® Database 2 Day Security Guide.

  • Oracle Advanced Security for communications between the Management Service and the Management Repository.

    See Also:

    Oracle Database Advanced Security Administrator's Guide

Enabling Security for the Oracle Management Service

To enable Enterprise Manager Framework Security for the Management Service, you use the emctl secure oms utility, which is located in the following subdirectory of the Management Service home directory:

<OMS_ORACLE_HOME>/bin

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 Services & Management Agents. An Oracle Wallet is used to store security credentials on Oracle Clients and servers, see oracle Advanced Security Administrators Guide for more information on Oracle Wallets.

  • Modifies your WebTier to enable an HTTPS channel between your Management Service and Management Agents, independent from any existing HTTPS configuration that may be present in your WebTier.

  • Enables your Management Service to accept requests from Management Agents using Enterprise Manager Framework Security.

To run the emctl secure oms utility you must first choose an Agent Registration Password. The Agent Registration password is used to validate that future installation of Oracle Management Agents are authorized to load their data into this Enterprise Manager installation.

To enable Enterprise Manager Framework Security for the Oracle Management Service:

  1. Stop the Management Service, the WebTier using the following command:
    <OMS_ORACLE_HOME>/bin/emctl stop oms
    
  2. Enter the following command:
    <OMS_ORACLE_HOME>/bin/emctl secure oms
    
  3. You will be prompted for the Enterprise Manager Root Password. Enter the SYSMAN password.
  4. You will be prompted for the Agent Registration Password, which is the password required for any Management Agent attempting to establish secure communication with the Management Service. Specify an Agent Registration Password for the Management Service.
  5. Restart the OMS.
  6. After the Management Service restarts, test the secure connection to the Management Service by browsing to the following secure URL using the HTTPS protocol:
    https://hostname.domain:https_console_port/em
    

    Note: The Enterprise Manager console URL can be found by running the "emctl status oms -details" command.

    For example:

    $ emctl status oms -details
    Oracle Enterprise Manager Cloud Control 13c Release 5
    Copyright (c) 1996, 2016 Oracle Corporation. All rights reserved.
    Enter Enterprise Manager Root (SYSMAN) Password :
    ...
    Console URL: https://omshost.example.com:5416/em
    

    If the Management Service security has been enabled successfully, your browser displays the Enterprise Manager login page.

Example 2-3 Sample Output of the emctl secure oms Command

$ emctl secure oms
Oracle Enterprise Manager Cloud Control 13c Release 5
Copyright (c) 1996, 2016 Oracle Corporation. All rights reserved.
Securing OMS... Started.
Enter Enterprise Manager Root (SYSMAN) Password :
Enter Agent Registration Password :
Securing OMS... Successful
Restart OMS
Configuring the OMS with Server Load Balancer

When you deploy a Management Service that is available behind a Server Load Balancer (SLB), special attention must be given to the DNS host name through which the Management Service will be available. Although the Management Service may run on a particular local host, for example test01.example.com, your Management Agents will access the Management Service using the host name that has been assigned to the Server Load Balancer. For example, oracleoms.example.com.

As a result, when you enable Enterprise Manager Framework Security for the Management Service, it is important to ensure that the Server Load Balancer host name is embedded into the Certificate that the Management Service uses for SSL communications. This may be done by using emctl secure oms and specifying the host name using an extra -host parameter as shown below.

Note:

Before running the commands, you must first identify the SLB hostname, port, and ensure that the SLB is configured.

  • Enable security on the Management Service by entering the following command:

    emctl secure oms -host <slb_hostname> [-slb_console_port <slb UI port>] [-slb_port <slb upload port>] [other params]

    Run this command on each OMS. You will need to restart each OMS after running the 'emctl secure oms' command.

  • Create virtual servers and pools on the Server Load Balancer.

  • Verify that the console can be accessed using the following URL:

    https://slb_hostname:slb_console_port/em

  • Re-secure the Agents with Server Load Balancer by using the following command:

    emctl secure agent -emdWalletSrcUrl <SLB Upload or UI URL>

    For example:

    $ <AGENT_HOME>/bin/emctl secure agent -emdWalletSrcUrl https://slb_hostname:slb_upload_port/em

It is possible to configure Oracle Enterprise Manager with one load balancer for upload operations and one for console operations. To do this, the pools at both of the SLBs must be configured with respective ports and the OMS must be secured separately for console and upload operations, using the following commands:

$emctl secure oms -host <slb_hostname>[-slb_port <slb upload port>] [other params] $emctl secure console -host <slb_hostname> other params
Removing a Server Load Balancer Configuration

If you had previously configured the OMS with an SLB using emctl secure oms -host and now want to remove the SLB configuration, run the following command:

emctl secure oms -no_slb

If you had secured Agents using the SLB hostname they will need to be re-secured using the OMS hostname. To re-secure the Agents, run the following command:

emctl secure agent -emdWalletSrcUrl <Upload URL>
Creating a New Certificate Authority

You may need to create a new Certificate Authority (CA) if the current CA is expiring, if you want to change the key strength, or if you want to change the signature algorithm. A unique identifier is assigned to each CA. For instance, the CA created during installation may have an identifier as ID 1, subsequent CAs will have the IDs 2,3, and so on. At any given time, the last created CA is active and issues certificates for OMSs and Agents.

  1. Run the emctl secure createca command on one of the OMS machines.
  2. If there are multiple OMSs in your environment, copy <EM_Instance_Home>/sysman/config/b64LocalCertificate.txt from the machine on which emctl secure createca was run to all other OMS machines at the same location i.e <EM_Instance_Home>/sysman/config/b64LocalCertificate.txt
  3. Restart all the OMSs.

Example 2-4 Creating a New Certificate Authority

emctl secure createca [-host <hostname>] [-key_strength <strength>] [-cert_validity <validity>] [-root_dc <root_dc>] [-root_country <root_country>] [-root_email <root_email>] [-root_state <root_state>] [-root_loc <root_loc>] [-root_org <root_org>] [-root_unit <root_unit>] [-sign_alg <md5|sha1|sha256|sha384|sha512>] [-cert_validity <validity>]
Oracle Enterprise Manager 13c Release 5 Cloud Control
Copyright (c) 1996, 2022 Oracle Corporation.  All rights reserved.
Creating CA... Started.
Successfully created CA with ID 2

Example 2-5 Viewing Information about a Certificate Authority

emcli get_ca_info -ca_id="1;2" -details
Info about CA with ID: 1
CA is not configured
DN: CN=myhost.example.com, C=US
Serial# : 3423643907115516586
Valid From: Tue Mar 16 11:06:20 PDT 2011
Valid Till: Sat Mar 14 11:06:20 PDT 2020
Number of Agents registered with CA ID 1 is 1
myhost.example.com:3872

Info about CA with ID: 2
CA is configured
DN: CN=myhost.example.com, C=US, ST=CA
Serial# : 1182646629511862286
Valid From: Fri Mar 19 05:17:15 PDT 2011
Valid Till: Tue Mar 17 05:17:15 PDT 2020
There are no Agents registered with CA ID 2
Administration Credentials Wallet

The WebLogic Administrator and Node Manager passwords are stored in the Administration Credentials Wallet. This is present in the <MW_HOME>/sysman/config/adminCredsWallet directory. To recreate Administrator Credentials wallet, run the following command on each machine on which the Management Service is running:

emctl secure create_admin_creds_wallet [-admin_pwd <pwd>] [-nodemgr_pwd <pwd>]

Viewing the Security Status and OMS Port Information

To view the security status and OMS port information, use the following command

Example 2-6 emctl status oms -details

Oracle Enterprise Manager Cloud Control 13c Release 2
Copyright (c) 1996, 2016 Oracle Corporation. All rights reserved.
Console Server Host : test01.example.com
HTTP Console Port : 7802
HTTPS Console Port : 5416
HTTP Upload Port : 7654
HTTPS Upload Port : 4473
EM Instance Home : <MW_HOME>/oracle/work/em/EMGC_OMS1
OMS Log Directory Location : <MW_HOME>/oracle/work/em/EMGC_OMS1/sysman/log
OMS is not configured with SLB or virtual hostname
Agent Upload is locked.
OMS Console is unlocked.
Active CA ID: 2
Console URL: https://test01.example.com:5416/em
Upload URL: https://test01.example.com:4473/empbs/upload
 
WLS Domain Information
Domain Name : EMGC_DOMAIN
Admin Server Host : test01.example.com
Admin Server HTTPS Port: 7022
Admin Server is RUNNING
 
Managed Server Information
Managed Server Instance Name: EMGC_OMS1
Managed Server Instance Host: test01.example.com
WebTier is Up
Oracle Management Server is Up
Configuring Transport Layer Security

The Oracle Management Service can be configured in TLSv1, TLSv1.1, and TLSv1.2 modes. By default, all three modes are enabled. To configure the OMS to use only one or two modes, do the following:

  1. Stop the OMS by entering the following command:
    <OMS_ORACLE_HOME>/bin/emctl stop oms
    
  2. Enter a command similar to one of the following commands:

    To restrict the OMS to one particular mode, enter:

    emctl secure -protocol "TLSv1"
    

    To enable more than one mode, use a space delimited list, for example:

    emctl secure oms -protocol "TLSv1.1 TLSv1.2"
    
  3. Restart the OMS with the following command:
    <OMS_ORACLE_HOME>/bin/emctl start oms
    

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, which is located in the following directory of the Management Agent home directory:

<AGENT_INSTANCE_HOME>/bin (UNIX)
<AGENT_INSTANCE_HOME>\bin (Windows)

The emctl secure agent utility performs the following actions:

  • Obtains an Oracle Wallet from the Management Service that contains a unique digital certificate for the Management Agent. This certificate is required in order for the Management Agent to conduct SSL communication with the secure Management Service.

  • Obtains an Agent Key for the Management Agent that is registered with the Management Service.

  • Configures the Management Agent so it is available on your network over HTTPS and so it uses the Management Service HTTPS upload URL for all its communication with the Management Service.

To enable Enterprise Manager Framework Security for the Management Agent:

  1. Ensure that your Management Service and the Management Repository are up and running.
  2. Stop the Management Agent:
    emctl stop agent
    
  3. Enter the following command:
    emctl secure agent
    

    The emctl secure agent utility prompts you for the Agent Registration Password, authenticates the password against the Management Service, and reconfigures the Management Agent to use Enterprise Manager Framework Security.

    Example 2-7 shows sample output of the emctl secure agent utility.

  4. Restart the Management Agent:
    emctl start agent
    
  5. Confirm that the Management Agent is secure by checking the Management Agent home page.

    Note:

    You can also check if the Agent Management is secure by running the emctl status agent -secure command, or by checking the Agent and Repository HTTPS URLs in the output of the emctl status agent command.

    In the Management Agent home page , the Secure Upload field indicates whether or not Enterprise Manager Framework Security has been enabled for the Management Agent.

Example 2-7 Sample Output of the emctl secure agent Utility

emctl secure agent
Oracle Enterprise Manager 13c Release 2 Cloud Control.
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
Securing agent...   Started
Securing agent...   Successful.

Example 2-8 Sample Output of the emctl status agent secure Command

$ emctl status agent -secure
Oracle Enterprise Manager Cloud Control 13c Release 2
Copyright (c) 1996, 2016 Oracle Corporation. All rights reserved.
Checking the security status of the Agent at location set in <MW_HOME>/oracle/work/agentStateDir/sysman/config/emd.properties... Done.
Agent is secure at HTTPS Port 1838.
Checking the security status of the OMS at http://test01.example.com:7654/empbs/upload/... Done.
OMS is secure on HTTPS Port 4473

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.

Note:

If you want to avoid new Agents from being registered with the OMS, delete all registration passwords.'

Using the Cloud Control Console to Manage Agent Registration Passwords

You can use the Cloud Control Console to manage your existing registration passwords or create additional registration passwords:

  1. From the Setup menu, select Security, then select Registration Passwords.
  2. Enterprise Manager displays the Registration Passwords page. Registration password specified during install appears in the Registration Passwords table with description <Initial Agent Registration Password>.
  3. Use the Registration Passwords page to change your registration password, create additional registration passwords, or remove registration passwords associated with the current Management Repository.

When you create or edit an Agent Registration Password on the Registration Passwords page, you can determine whether the password is persistent and available for multiple Management Agents or to be used only once or for a predefined period of time.

For example, if an administrator requests to install a Management Agent on a particular host, you can create a one-time-only password that the administrator can use to install and configure one Management Agent.

On the other hand, you can create a persistent password that an administrator can use for the next two weeks before it expires and the administrator must ask for a new password.

Using emctl to Add a New Agent Registration Password

To add a new Agent Registration Password, use the following emctl command on the machine on which the Management Service has been installed:

emctl secure setpwd [sysman pwd] [new registration pwd]

The emctl secure setpwd command requires that you provide the password of the Enterprise Manager super administrator user, sysman, to authorize the addition of the Agent Registration Password.

As with other security passwords, you should change the Agent Registration Password on a regular and frequent basis to prevent it from becoming too widespread.

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.

To restrict access so Management Agents can upload data to the Management Service only over HTTPS:

  1. Stop the Management Service, the WebTier:
    cd <OMS_ORACLE_HOME>/bin
    emctl stop oms
    
  2. Enter the following command to prevent Management Agents from uploading data to the Management Service over HTTP:
    emctl secure lock -upload

    To lock the console and prevent HTTP access to the console, enter the following command:

    emctl secure lock -console
    

    To lock both, enter either of the following commands:

    emctl secure lock or 
    emctl secure lock -upload -console
    

    To lock both the console access and uploads from Agents while enabling security on the Management Service, enter the following command:

    emctl secure oms -lock [other options]
    
  3. Restart the Management Service, the WebTier, and the other application server components:
    emctl start oms
    
  4. Verify that you cannot access the OMS upload URL using the HTTP protocol:

    For example, navigate to the following URL:

    http://hostname.domain:4889/empbs/upload
    

    You should receive an error message similar to the following:

    Forbidden
    You are not authorised to access this resource on the server.
    

    Note: The HTTP upload port number can be found using the emctl status oms -details command. Search for "HTTP Upload Port"

  5. Verify that you can access the OMS Upload URL using the HTTPS protocol:

    For example, navigate to the following URL:

    https://hostname.domain:4888/empbs/upload
    

    You should receive the following message, which confirms the secure upload port is available to secure Management Agents:

    Http XML File receiver
    Http Recceiver Servlet active!
    

Example 2-9 Sample Output of the emctl secure lock Command

emctl secure lock
Oracle Enterprise Manager 13c Release 2 Cloud Control
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
OMS Console is locked. Access the console over HTTPS ports.
Agent Upload is locked. Agents must be secure and upload over HTTPS port.
Restart OMS

Example 2-10 Sample Output of the emctl secure unlock Command

emctl secure unlock
Oracle Enterprise Manager 13c Release 2 Cloud Control
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
OMS Console is unlocked. HTTP ports too can be used to access console.
Agent Upload is unlocked. Unsecure Agents may upload over HTTP.
Restart OMS

To allow the Management Service to accept uploads from unsecure Management Agents, use the following command:

emctl secure unlock -upload

Note:

  • The OMS need to be stopped before running 'secure unlock', and then restarted afterwards.

  • To unlock the console and allow HTTP access to the console, enter the following command:

    emctl secure unlock -console
    
  • To unlock both, enter either of the following command:

    emctl secure unlock
    emctl secure unlock -console -upload

Note:

The Oracle Management Service is locked (both console & upload) by default beginning with Enterprise Manager 13c.

Enabling Security for the Management Repository Database

This section describes how to enable Security for the Oracle Management Repository. This section includes the following topics:

About Oracle Advanced Security and the sqlnet.ora Configuration File

You enable security for the Management Repository by using Oracle Advanced Security. Oracle Advanced Security ensures the security of data transferred to and from an Oracle database.

See Also:

Oracle Database Advanced Security Administrator's Guide

To enable Oracle Advanced Security for the Management Repository database, you must make modifications to the sqlnet.ora configuration file. The sqlnet.ora configuration file is used to define various database connection properties, including Oracle Advanced Security parameters.

The sqlnet.ora file is located in the following subdirectory of the Database home:

<OMS_ORACLE_HOME>/network/admin

After you have enabled Security for the Management Repository and the Management Services that communicate with the Management Repository, you must also configure Oracle Advanced Security for the Management Agent by modifying the sqlnet.ora configuration file in the Management Agent home directory.

It is important that both the Management Service and the Management Repository are configured to use Oracle Advanced Security. Otherwise, errors will occur when the Management Service attempts to connect to the Management Repository. For example, the Management Service might receive the following error:

ORA-12645: Parameter does not exist

To correct this problem, be sure both the Management Service and the Management Repository are configured as described in the following sections.

Note:

The procedures in this section describe how to manually modify the sqlnet.ora configuration file to enable Oracle Advanced Security. Alternatively, you can make these modifications using the administration tools described in the Oracle Database Advanced Security Administrator's Guide.

Configuring the Management Service to Connect to a Secure Management Repository Database

If you have enabled Oracle Advanced Security for the Management Service database or if you plan to enable Oracle Advanced Security for the Management Repository database, use the following procedure to enable Oracle Advanced Security for the Management Service:

  1. Stop the Management Service:
    <OMS_ORACLE_HOME>/bin/emctl stop oms
    
  2. Add the Enterprise Manager operational properties in the <GC_INST>/em/EMGC_OMS{I}/emgc.properties file. The following table describes the Oracle Advanced Security properties that should be added:

    Table 2-2  Oracle Advanced Security Properties in the Enterprise Manager Properties

    Property Description

    oracle.sysman.core.conn.enableEncryption

    Defines whether or not Enterprise Manager will use encryption between the Management Services and Management Repository. Possible values are TRUE and FALSE. The default value is TRUE. For example:

    oracle.sysman.core.conn.enableEncryption=true

    oracle.net.encryption_client

    Defines the Management Service encryption requirement. Possible values are REJECTED, ACCEPTED, REQUESTED, and REQUIRED.

    The default value is REQUESTED. If the database supports secure connections, then the Management Service uses secure connections, otherwise the Management Service uses insecure connections.

    For example:

    oracle.net.encryption_client=REQUIRED

    oracle.net.encryption_types_client

    Defines the different types of encryption algorithms the client supports. Possible values should be listed within parenthesis. The default value is (AES256).

    For example:

    oracle.net. encryption_types_client= (AES256)

    oracle.net.crypto_checksum_client

    Defines the Client's checksum requirements.

    Possible values are REJECTED, ACCEPTED, REQUESTED, and REQUIRED.

    The default value is REQUIRED.

    For example:

    oracle.net. crypto_checksum_client=REQUIRED

    oracle.net.crypto_checksum_types_client

    This property defines the different types of checksums algorithms the client supports.

    Possible values should be listed within parentheses. The default value is (SHA256).

    For example:

    oracle.net. crypto_checksum_types_client= (SHA256)

  3. Restart the Management Service.
    <OMS_ORACLE_HOME>/bin/emctl start oms
Enabling Oracle Advanced Security for the Management Repository

To ensure your database is secure and that only encrypted data is transferred between your database server and other sources, review the security documentation available in the Oracle Database documentation library.

See Also:

Oracle Database Advanced Security Administrator's Guide

The following instructions provide an example of how you can confirm that Oracle Advanced Security is enabled for your Management Repository database and its connections with the Management Service:

  1. Locate the sqlnet.ora configuration file in the following directory of the database Oracle Home:
    <OMS_ORACLE_HOME>/network/admin
    
  2. Using a text editor, look for the following entries (or similar entries) in the sqlnet.ora file:
    SQLNET.ENCRYPTION_SERVER = REQUESTED
    SQLNET.CRYPTO_SEED = "abcdefg123456789"

    See Also:

    "Configuring Network Data Encryption and Integrity for Oracle Servers and Clients in the Oracle Application Server 10g Administrator's Guide.

  3. Save your changes and exit the text editor.
Enabling Security for a Management Agent Monitoring a Secure Management Repository or Database

After you have enabled Oracle Advanced Security for the Management Repository, you must also enable Advanced Security for the Management Agent that is monitoring the Management Repository:

  1. Locate the sqlnet.ora configuration file in the following directory inside the home directory for the Management Agent that is monitoring the Management Repository:
    AGENT_HOME/network/admin (UNIX)
    AGENT_HOME\network\admin (Windows)
    
  2. Using a text editor, add the following entry to the sqlnet.ora configuration file:
    SQLNET.CRYPTO_SEED = "abcdefg123456789"
    

    The SQLNET.CRYPTO_SEED can be any string between 10 to 70 characters.

    See Also:

    "Configuring Network Data Encryption and Integrity for Oracle Servers and Clients in the Oracle Application Server Administrator's Guide.

  3. Save your changes and exit the text editor.
  4. Restart the Management Agent.

Custom Configurations

Configuring Custom Certificates for WebLogic Server

WebLogic Servers installed as part of Enterprise Manager Cloud control (Administration Server and Managed Servers) are configured with a default identity keystore ( DemoIdentity.jks) and a default trust keystore ( DemoTrust.jks). In addition, WebLogic Server trusts the CA certificates in the JDK cacerts file. This default keystore configuration is appropriate for testing and development purposes. However, these keystores should not be used in a production environment.

Default Demo Certificate configured for WLS has a key length of 512 bits. If Microsoft's Security update for minimum certificate key length (KB2661254) has been applied on the browser m/c, the WebLogic Admin Console will not be accessible on Internet Explorer. If you want to access WebLogic Admin Console using Internet Explorer, please configure custom certificate for WLS.

The following sections step you through configuring custom Weblogic Server certificates:

  1. Create a Java KeyStore or Wallet for each OMS
  2. Import Custom CA Certificates into the Agents Monitoring Trust Store
  3. Configure the Custom Certificate for each WLS

Note:

This procedure is applicable to Enterprise Manager 12c Cloud Control (12.1.0.2) and higher.

Create a Java KeyStore or Wallet for each OMS

  1. Create a java keystore (JKS) for each OMS in the environment.

    Regardless of whether the OMS is configured with a server load balancer or not, specify the OMS machine name for CN (Example: CN=myoms.example.com) while generating the Certificate Signing Request (CSR). The OMS machine name can be found from the value of EM_INSTANCE_HOST property in <EM_INSTANCE_HOME>/emgc.properties.

    Make a note of the keystore password, private key entry's alias, and private key password of each keystore.

    Note: Use only the signature algorithms supported by WLS.

  2. Copy the keystores to corresponding OMS machines or place them in a location accessible from OMS machines.

    Example: The keystores are /scratch/oms1.jks, /scratch/oms2.jks , /scratch/oms3.jks

  3. Write the CA certificates to individual files (one CA certificate per file). Either copy these certificate files to the OMS machines or place them in a location accessible from the OMS machines.

    Example: The filenames are /scratch/ca1cert.cer, /scratch/ca2cert.cer, /scratch/ca3cert.cer

Import Custom CA Certificates into the Agents Monitoring Trust Store

Execute the following steps on Management Agents running on the OMS machines which are installed along with the OMS.

Note:

Only required on Agents installed along with OMS and not on any other Agents.

  1. Stop the Agent

    <Agent_Instance_Home>/bin/emctl stop agent

  2. Import the custom CA certificate into Agent:
    <Agent_Instance_Home>/bin/emctl secure add_trust_cert_to_jks 
    -trust_certs_loc <ca_cert_file>
    -alias <certalias> [-password <montrust_jks_pwd>]
    

    Example:

    <Agent_Instance_Home>/bin/emctl secure add_trust_cert_to_jks -trust_certs_loc /scratch/ca1cert.cer
    -alias ca1certalias [-password welcome]
    

    Repeat this step for each CA involved in issuing the custom certificate.

    Specify different alias each time.

  3. Start the Agent.

    <Agent_Instance_Home>/bin/emctl

Configure the Custom Certificate for each WLS

Execute the following steps on each OMS:

  1. Stop the OMS.

    <OMS_Home>/bin/emctl stop oms

  2. Run the following cmd:
    emctl secure wls
    (-jks_loc <loc> -jks_pvtkey_alias <alias> [-jks_pwd <pwd>] [-jks_pvtkey_pwd <pwd>] | -wallet <loc>)
    Specify jks_loc,jks_pvtkey_alias or wallet 
    

    Example:

    <OMS_OH>/bin/emctl secure wls 
    -jks_loc /scratch/oms1.jks -jks_pvtkey_alias pvtkey1alias
    
    <OMS_OH>/bin/emctl secure wls -wallet /scratch/omswallet
    
  3. Stop the OMS.

    <OMS_Home>/bin/emctl stop oms -all

  4. Start the OMS.

    Note:

    Above steps need to be repeated on all the Management Services.

    <OMS_Home>/bin/emctl start oms

Rolling back the WebLogic Servers to Demonstration Certificate

If you need to switch to using the default WebLogic demonstration certificates, execute the following steps on each OMS.

  1. Stop the OMS.

    <OMS_Home>/bin/emctl stop oms

  2. Run the following command:
    <OMS_Home>/bin/emctl secure wls -use_demo_cert
    
  3. Stop the OMS.

    <OMS_Home>/bin/emctl stop oms -all

  4. Start the OMS.

    <OMS_Home>/bin/emctl start oms

Note:

The above steps need to be excuted on all Management Services.

Configuring Custom Certificates for OMS Console Access

To configure the third party certificate for HTTPS WebTier Virtual Host:

  1. Create a wallet for each OMS in the Cloud. Specify the host name of the machine where the OMS is installed or the Load Balancer Name if the OMS is behind the Server Load Balancer for Common Name.
  2. Run the following command on each OMS and the restart that OMS:
    emctl secure console -wallet <location of custom wallets> -self_signed [-host]

    Note:

    One of the arguments -wallet or -self_signed is mandatory.

    Note:

    Only Single-Sign-On (SSO) wallets are supported.

Configuring Custom Certificates for OMS Upload Access

You can configure the third party certificate for the HTTPS Upload Virtual Host in two ways:

Method I

  1. Create a wallet for each OMS in the Cloud.

  2. While creating the wallet, specify the host name of the machine where the OMS is installed or the Load Balancer Name if the OMS is behind the Load Balancer for Common Name.

  3. Write the certificates of all the Certificate Authorities in the certificate chain (like the Root Certificate Authority, Intermediate Certificate Authority) into a file named trusted_certs.txt.

  4. Download or copy the trusted_certs.txt file to the host machines on which each Agent that is communicating with the OMS is running.

  5. Import the custom CA certificate(s) as trust certificate(s) for Agent by running the following command:

    emctl secure add_trust_cert -trust_certs_loc <location of the trusted_certs.txt file>
    
  6. Restart the Agent.

  7. Secure the OMS and restart it.

    emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
    

Method 2

  1. Create a wallet for each OMS in the Cloud.
  2. Specify the host name of the machine where the OMS is installed or the Load Balancer Name if the OMS is behind the Server Load Balancer for Common Name (CN).
  3. Write the certificates of all the Certificate Authorities in the certificate chain (like the Root Certificate Authority, Intermediate Certificate Authority) into a file named trusted_certs.txt.
  4. Secure the OMS.
    emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
    
  5. Restart the OMS.
  6. Either re-secure the Agent by running the emctl secure agent command (should be run on all Agents) or import the trust points by running the emctl secure command.

    Note:

    The trusted certs file (trusted_certs.txt) should contain only certificates in base64 format and not any special characters or comments..

Secure Communication Setup Tools

The following emctl commands are used to secure various components of the Enterprise Manager infrastructure.

emctl secure oms
emctl secure oms [-reg_pwd <registration password>]
        [-host <hostname>] [-ms_hostname <Managed Server hostname>]
        [-slb_port <SLB HTTPS upload port>] [-slb_console_port <ty6 HTTPS console port>] [-no_slb]
        [-secure_port <OHS HTTPS upload Port>] [-upload_http_port <OHS HTTP upload port>]
        [-reset] [-console] [-force_newca]
        [-lock_upload] [-lock_console] [-unlock_upload] [-unlock_console]
        [-wallet <wallet_loc> -trust_certs_loc <certs_loc>]
        [-key_strength <strength>] [-sign_alg <md5|sha1|sha256|sha384|sha512>]
        [-cert_validity <validity>] [-protocol <protocol>]
        [-root_dc <root_dc>] [-root_country <root_country>] [-root_email <root_email>]
        [-root_state <root_state>] [-root_loc <root_loc>] [-root_org <root_org>] [-root_unit <root_unit>]
Parameter Description

reg_pwd

The Management Agent registration password.

host

The host name to be used in the certificate used by the Oracle Management Service. You may need to use the SLB host name if there is an SLB before the Management Service.

reset

A new certificate authority will be created. All the Agents and Oracle Management Services need to be resecured.

secure_port

Specify this to change HTTPS Upload port on WebTier.

upload_http_port

Specify this to change HTTP Upload port on WebTier

slb_port

This parameter is required when Server Load Balancer is used. It specifies the secure upload port configured in the Server Load Balancer.

slb_console_port

This parameter is required when Server Load Balancer is used. It specifies the secure console port configured in the Server Load Balancer.

no_slb

Remove SLB configuration.

root_dc

The domain component used in the root certificate. The default value is com.

root_country

The country to be used in the root certificate. The default value is US.

root_state

The state to be used in the root certificate. The default value is CA.

root_loc

The location to be used in the root certificate. The default value is EnterpriseManager on <hostname>.

root_org

The organization name to be used in the root certificate. The default value is EnterpriseManager on <hostname>.

root_unit

The organizational unit to be used in the root certificate. The default value is EnterpriseManager on <hostname>.

root_email

The email address to be used in the root certificate. The default value is EnterpriseManager@<hostname>.

wallet

This is the location of the wallet containing the third party certificate. This parameter should be specified while configuring third party certificates.

trust_certs_loc

The location of the trusted_certs.txt (required when third party certificates are used).

key_strength

The strength of the key to be used. Valid values are 512, 1024, 2048, and 4096.

Note: For the IBM AIX Platform, the maximum allowed key_strength is 2048 bits.

cert_validity

The number of days for which the self-signed certificate is valid. The valid range is between 1 to 3650.

protocol

This parameter is used to configure Oracle Management Service in TLSv1-only or SSLv3-only or mixed mode (default). Valid values are the allowed values as per Apache's SSLProtocol directive.

Note: The key_strength and cert_validity parameters are applicable only when the -wallet option is not used.

force_newca

If specified, any Agents that are still configured with an older Certificate Authority are ignored.

ms_hostname

Managed Server's hostname.

sign_alg

Signature algorithm.

lock

Locks the Upload

lock_console

Locks the Console

console

If specified, the certificate is recreated for the HTTPS console port as well.

emctl secure agent

Secures the agent against an OMS. The registration password (or password file) must be provided.

emctl secure agent <registration password> [-passwd_file <absolute path to file>]
emctl secure wls
emctl secure wls (-jks_loc <loc> -jks_pvtkey_alias <alias> | -wallet <loc> | -use_demo_cert)
Specify jks_loc,jks_pvtkey_alias or wallet or use_demo_cert
        [-jks_pwd <pwd>] [-jks_pvtkey_pwd <pwd>]
        -jks_loc : Location of JKS containing the custom cert for Admin & Managed Servers
        -jks_pvtkey_alias : JKS's private key alias
        -jks_pwd : JKS's keystore password
        -jks_pvtkey_pwd : JKS's private key password
        -wallet : Location of wallet containing the custom cert for Admin & Managed Servers
        -use_demo_cert: Configure the demo cert for Admin & Managed Servers
emctl status oms -details
emctl status oms -details

Configuring Third Party Certificates

You can configure third party certificates for:

  • HTTPS Console Users

  • HTTPS Upload Virtual Host

Note:

Only Single Sign-On wallets are supported.

Configuring a Third Party Certificate for HTTPS Console Users

To configure the third party certificate for HTTPS WebTier Virtual Host:

  1. Create a wallet for each OMS. Specify the host name of the machine where the OMS is installed or the Load Balancer Name if the OMS is behind the Server Load Balancer for Common Name.
  2. Run the following command on each OMS and the restart that OMS:
    emctl secure console -wallet <location of custom wallets> -self_signed [-host]

    Note:

    One of the arguments -wallet or -self_signed is mandatory.

    Note:

    Only single-sign-on wallets are supported.

Configuring Third Party Certificate for HTTPS Upload Virtual Host

You can configure the third party certificate for the HTTPS Upload Virtual Host in two ways:

Method I

  1. Create a wallet for each OMS.

  2. While creating the wallet, specify the host name of the machine where the OMS is installed or the Load Balancer Name if the OMS is behind the Load Balancer for Common Name.

  3. Write the certificates of all the Certificate Authorities in the certificate chain (like the Root Certificate Authority, Intermediate Certificate Authority) into a file named trusted_certs.txt.

  4. Download or copy the trusted_certs.txt file to the host machines on which each Agent that is communicating with the OMS is running.

  5. Run the add_trust_cert command on each Agent and then restart that Agent.

    emctl secure add_trust_cert -trust_certs_loc <location of the trusted_certs.txt file>
    
  6. Secure the OMS and restart it.

    emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
    

Method 2

  1. Create a wallet for each OMS in the Cloud.
  2. Specify the host name of the machine where the OMS is installed or the Load Balancer Name if the OMS is behind the Server Load Balancer for Common Name (CN).
  3. Write the certificates of all the Certificate Authorities in the certificate chain (like the Root Certificate Authority, Intermediate Certificate Authority) into a file named trusted_certs.txt.
  4. Restart the OMS after it has been secured.
    emctl secure oms -wallet <location of wallet> -trust_certs_loc <loc of trusted_certs.txt> [any other options]
    
  5. Either re-secure the Agent by running the emctl secure agent command (should be run on all Agents) or import the trust points by running the emctl secure add_trust_cert -trust_certs_loc <location of the trusted_certs.txt file> command. The -trust_certs_loc parameter must contain the path and the filename of the trusted_certs.txt file.

    Note:

    This file must only contain certificates in base64 format and no special characters or empty lines.

Configuring and Using Target Credentials

The following topics are discussed in this section:

  • Credential Subsystem

  • Pluggable Authentication Modules (PAM) Support

  • Sudo and Powerbroker Support

Credential Subsystem

Credentials like user names and passwords are typically required to access targets such as databases, application servers, and hosts. The following flow chart illustrates the typical credential setup workflow.

Figure 2-1 Credential Setup Workflow


Credential flow chartl

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

Credentials are stored within Enterprise Manager as "named" entities. Administrators define and store credentials within Enterprise Manager and refer to the credential by a credential name.The advantages of saving the credentials are:

  • You do not have to expose the credential details to all the users.

  • It saves your time and effort as you do not have to specify the user name and password every time for each Oracle home or host machine, you can instead select a named profile that has used the saved credentials.

Named Credentials can be a username/password pair like the operating system login credentials, or Oracle home owner credentials primarily used for performing operations such as running jobs, patching and other system management tasks. For example, an administrator can store the username and password they want to use for patching as "MyPatchingCreds". He can later submit a patching job that uses "MyPatchingCreds" to patch a production databases.

Typical Scenarios for Using Named Credentials
  • In data centers where only senior DBAs have knowledge of higher privileged credential, sys credentials for database, for example, they can store these credentials in named credential and share these with the junior administrators. Junior administrators can perform their jobs using the named credentials without knowing what the actual credentials are.

  • In data centers where administrators have the same credentials for a target. They can create one named credential containing those credentials and share the named credential with appropriate personnel. This simplifies credential maintenance (changing passwords, for example) by eliminating the need to several copies of named credentials containing the same credentials.

Note:

For a video tutorial on using named credentials, see:

Oracle Enterprise Manager 13c: Create and Use Named Credentials

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5460,1

There are two category scopes of named credentials:

  • Global Named Credential

    A global named credential is an entity, containing authentication information for a target type. A global named credential can be applied to any Enterprise Manager target type at the time of its creation or, at a later time. Global named credentials consist of the credential type (also known as the authentication scheme) and the credential properties (also known as the authentication parameters).

    Each target type may have one or more credential types,

    For example:

    hostA has password based (requiring username/password) and SSH key (requiring public/private key pair) credential type and database instanceA has password based and Kerberos based credential type.

    Credential properties consist of the information needed for the credential type and may also contain parameters, if being used for Privilege Delegation, PDP, for more information about PDP, see the section on Privilege Delegation, for possible commands and parameters.

    As global named credentials are initially set up as independent entities, an Enterprise Manger administrator can associate this type of credential with a target type at a later time.

  • Target Named Credentials

    A target named credential is an entity, containing credential information applied to a specific target. A target named credential can be applied to an Enterprise Manager target and is applied at the time of creation. This entity will also contain a credential type (whether it is username/password or public/private key pair) along with credential parameters (In the case of PDP settings, the location of the PDP utility being used and the parameters and command to be run) for a target type.

Access Control

In order to create a named credential an administrator must have the CREATE_CREDENTIAL privilege. Once the administrator with the CREATE_CREDENTIAL privilege creates a named credential, he is considered the owner of that named credential. The owner of a named credential can share access to the named credential at any time. He is considered the grantor administrator. The administrator granted access to the named credential is the grantee administrator. The owner can share access to the named credential by granting the appropriate level of privilege to one or many grantee administrators. The type of privilege granted by the owner of the named credential depends on the level of access needed by the grantee administrator. The following privilege levels are available for all named credentials:

  • VIEW: The VIEW privilege is the default privilege level. Grantee administrators with VIEW privilege on a named credential will be able to use that named credential to run jobs, patching operations and other system management activities within Enterprise Manager. The grantee administrator will also be able to view the non-sensitive details (for example, SUDO or PowerBroker and the commands being used) and username of the named credential. The grantee administrator will not be able to view any sensitive information of the named credential such as the password and public/private key.

  • EDIT: The EDIT privilege level also contains VIEW level privileges. Grantee administrators with EDIT privilege on a named credential can use that named credential to run jobs, patch operations and other management activities within Enterprise Manager. The grantee administrator will also be able to change the sensitive information such as the password, or the public/private key pair of that named credential. The grantee administrator can change both the Credential Type (such as Host or SSH key) of the named credential as well as the username for the credential. The authenticating target type cannot be changed.

  • FULL: The FULL privilege contains both VIEW and EDIT. Grantee administrators with FULL privilege on a named credential will be able to use that named credential for running jobs, patching operations and other management activities within Enterprise Manager. The grantee administrator will also be able to change the named credential username, sensitive information such as the password or the public/private key pair, and Credential Type (Host, SSH key etc). An administrator with FULL privilege on a named credential will also be able to delete that named credential.

Creating Named Credentials

You must have the Named Credential resource privilege to create named credentials.

To create named credentials, follow these steps:

  1. In Cloud Control, from the Setup menu, select Security, then select Named Credentials.

  2. On the Named Credentials page, click Create.

  3. On the Create Credentials page, in the General Properties section, provide the following details:

    1. Enter a unique Credential Name, and provide a description.

    2. Select Host as the Authentication Target Type, and Host Credentials as the Credential type

    3. Select Global to use the same credentials for all the targets.

  4. On the Create Credentials page, in the Credential Properties section, enter the UserName and Password required to access the host machine, and from the Run Privilege drop down list, do one of the following:

    • Select None, if you are using operating system host credentials (like Oracle) or the Oracle Home Owner credentials.

    • When you do not have access to the operating system host credentials or the root credentials of the host machine, then select Sudo or PowerBroker to SUDO (or pbrun)to the host machine using the credentials of another operating system user. To use the credentials of other users, in the Run As field, you need to enter operating system host credentials (like Oracle) or Oracle Home owner credentials of the host user.


    Image illustrates the menu selection flow.

  5. On the Create Credentials page, in the Access Control section, click Add Grant to grant privileges on the named profile to the selected Administrators or roles. By default the selected Administrator is granted View privilege.

    Note:

    To enable Administrators (or users) to access, and leverage an OMS Agent Filesystem Software Library Location, the owner of the Named Credential must ensure that an explicit View privilege is granted to all the Administrators accesssing the OMS Agent location. To do so, you can either click Add Grant and add the names of the administrators while creating the Named Credential as mentioned in this section, or edit an existing Named Credential to grant privileges to other Administrators (or users) by following these steps:

    1. In Cloud Control, from the Setup menu, select Security, then select Named Credentials.

    2. On the Named Credentials page, click Manage Access.

    3. On the Manage Access page, click Add Grant to add a user, or Change Privilege to edit the privileges of an existing user.

    4. Click Save.

    For example, if you have a Cloud Plug-in installed, and are using the Cloud features in Enterprise Manager, then ensure that the CLOUD_ENGINE_USER is also granted View privileges on credentials associated with Software Library. Since the CLOUD_ENGINE_USER is a hidden user account, the owner of the named credential will not be able to grant him View privileges from the Enterprise Manager UI. To handle this situation, (especially on a Windows host where OMS Agent Filesystem is the recommended approach for setting up Software Library) you can run the following EMCLI commands:

    emcli login -username=<username> -password=<password>
    emcli grant_privs -name=CLOUD_ENGINE_USER -privilege="GET_CREDENTIAL;CRED_NAME=<>:CRDED_OWNER=<>"

    To change the privilege, select the administrator, and click Change Privilege. In the Select Privilege dialog box, change the privilege to Edit or Full, and then click OK.

  6. After entering all the details, click Test and Save. If the host credentials are correct, then the test is successful and the credentials get saved.

Enterprise Manager Administrators will be able to grant privileges to other administrators while creating the credential or by granting the privileges when editing the credential.

From the Named Credential page, you can Create a new named credential, Edit an existing credential, Manage Access (grant/revoke privileges), Delete, Test, View References, or click the Query by Example icon to filter the list of named credentials.

Only the credential owner can manage access their credentials. When a credential owner views references, he can see all references even if not owned by him. Whereas a user who does not own the credential, will see only their own references.

Access Control for Named Credentials

Note:

You must have the Named Credentials resource privilges in order to create a named credential.

The access control model for named credentials adhere to the following rules:

  • Only named credential owners can grant privileges on named credentials they have created to other Enterprise Manager grantee administrators.

  • Enterprise Manager Super Administrators cannot obtain any privileges on a newly created named credential until he is explicitly granted privileges on the named credential.

  • Enterprise Manager administrators regardless of privilege level, cannot see the sensitive fields such as passwords and private keys from the console UI. This is achieved by replacing password with "*" characters.

  • Named credential privileges cannot be assigned to a role. This eliminates back door entry by Enterprise Manager Super Administrators to grant themselves privileges on the credentials for which they do not have explicit access.

  • An Enterprise Manager grantee administrator cannot view other administrators' credentials unless an explicit grant is provided by the owner. Even Enterprise Manager Super Administrators cannot view other users' named credentials by default.

  • Any Enterprise Manager administrator can create his own named credentials and, by default, has FULL privileges on the named credentials owned.

Authentication Scheme

An authentication scheme is the type of authentication supported by a target type. For example, a host can support a username/password-based authentication, Public Key authentication or Kerberos authentication. In fact, each target type in an enterprise may support different authentication schemes. To accommodate the many authentication schemes that can exist in a managed environment, Enterprise Manger allows you to configure the credentials for these authentication schemes.

Note:

All the credentials owned by an Enterprise Manager administrator will be deleted if that administrator is deleted from Enterprise Manager. All references and grants to grantee administrators of that named credential will also be deleted. Since access to a named credential is not granted to a Super Administrator, by default, a super administrator cannot re-assign a named credential owned by another administrator, by default.

Privileged Credentials

Privileged Credentials specify root users' authentication information on a system. Privileged credentials are the root account details used to perform privileged actions like executing root scripts. Privileged credentials are intended for privileged or power users. In Enterprise Manager 11g, each provisioning user required SUDO privileges that had to be explicitly granted. However, in Enterprise Manager 13c, you must set up privileged credentials to perform typical root user actions with SUDO privileges.

Creating Privileged Credentials

To create privileged credentials, follow these steps:

  1. Create the Named credentials using the steps mentioned in "Creating Named Credentials".
  2. On the Named Credentials page, select the credential, and then click Edit.
  3. On the Edit Credential Properties page, in the Credential Properties section, edit the existing UserName and Password required to access the host machine, and from the Run Privilege drop down list, do one of the following:
    • Select None, if you are using operating system host credentials (like Oracle) or the Oracle Home Owner credentials.

    • When you do not have access to the operating system host credentials or the root credentials of the host machine, then select Sudo or PowerBroker to sudo (or pbrun)to the host machine using the credentials of another operating system user. To use the credentials of other users, in the Run As field, you need to enter operating system host credentials (like Oracle) or Oracle Home owner credentials of the host user.

Monitoring Credentials

Monitoring credentials are used only by the Management Agent during the monitoring of specific types of targets. Targets requiring monitoring credentials will be displayed in the console. When targets are added to Enterprise Manager an administrator with the correct privilege will set up the monitoring credentials. An administrator must have the ADD_TARGET privilege to discover a target, and to enter the credentials for that target, he needs the CONFIGURE_TARGET privilege. Monitoring credentials are stored in the repository and propagated to the Agent. If the credentials are not set, the target will appear in the broken or down state, there will also be Metric Collection errors as the Agents will be unable to monitor without credentials.

To create or edit a monitoring credentials, from the Setup menu, choose Security and then Monitoring Credentials.

To modify monitoring credentials, select the desired target type and click Manage Monitoring Credentials. The monitoring credentials page for the selected target type displays. Alternatively, you can also modify monitoring credentials using EM CLI, as shown in the following example.

./emcli set_monitoring_credential -target_name=mytarget.myco.com 
-target_type=host -cred_type=HostCreds -set_name=Bob
-attributes="HostUserName:dwwolf;HostPassword:xxxxx:PDPTYPE:SUDO;RUNAS:root"
Preferred Credentials

Preferred credentials are used to simplify access to managed targets by storing the login information for those targets in the Management Repository. For example, for a database target one may have multiple logins, but store a preferred username/password credential to log in to perform specific operations. With preferred credentials, administrators can access an Enterprise Manager target that recognizes those credentials without being prompted to log in to the target, as the login happens automatically with those preferred credentials. Preferred credentials can also be used to carry out administrative operations using the job system. Unlike named credentials, which defines an independent entity, containing the username/password or public/private key, along with a Credential Type and optional parameters, which can be granted to grantee administrators by a named credential owner, a preferred credential is set up by each administrator for any target that they wish to access in a more convenient way.

To create a preferred credential:

  1. From the Setup menu, select Security and then Preferred Credentials. The Preferred Credentials page displays.
  2. Choose a target type from the list.
  3. Click Manage Preferred Credentials. The Preferred Credentials page for the selected target type displays.

Example: An Enterprise Manager target owner defines two preferred credential sets for a host target: One named HostCredNormal and the other is named HostCredPriv. For simple operations he uses HostCredNormal as it uses a regular user (myusername/password) such as oracle/oracle123. However, he uses HostCredPriv for more privileged operations on that host as it uses the root user (root/rootpasswd). When submitting jobs, depending on the job, he could use either of these credential sets.

  • Default Preferred Credentials: Default credentials are configured for a specific target type and is available for all the targets of that target type. It will be overridden by target preferred credentials.

  • Normal Host Credentials (HostCredNormal in the example). Perform normal administrative operations.

  • Privileged Host Credentials (HostCredPriv in the example). Perform privileged operations requiring root access.

  • Target Preferred Credentials: Target preferred credentials are credentials set for a specific target. Target preferred credentials could be used by applications such as the job system, notifications, or patching. For example, if the administrator chooses to use target preferred credentials while submitting a job, then that target preferred credential set for the target (target credentials) will be used. If the target preferred credential is not present, then the default preferred credential (for the target type) will be used. If the default preferred credentials are not present, the job will fail. If not specified preferred credentials refer to preferred target credentials.

For example, to set the host preferred credentials, from the Setup menu, choose Security and then Preferred Credential. In the Preferred Credentials page, select the Host target type from the table and click Manage Preferred Credentials. The Host Preferred Credentials are displayed.

On this page, you can set both default and explicit preferred credentials for the host target types.

Global Preferred Credentials

Beginning with Enterprise Manager Release 12.1.0.4, preferred credentials can be globally scoped. Global preferred credentials provide a convenient way to implement system-wide credentials by allowing an administrator (with required privileges) to apply these credentials to all users for a specific target or to apply them to all users for a target type.

The following graphic shows the Host Preferred Credentials page. Settings on the My Preferences tab refer to the preferred credentials set by an administrator to apply to a specific target or target type.

Settings on the Global Preferences tab refer to the preferred credentials set by an Administrator (with required privileges) to apply to all users for a specific target or to apply to all users for all target types.

Required Privileges

The following privileges are required to use Global Preferred Credentials:

  • OPERATOR_ TARGET: Required to use a Global Preferred Credential.

  • FULL_TARGET: Required to set target-specific scope at the Global Preferences level.

  • FULL_ANY_TARGET: Required to set target type scope at the Global Preferences level.

Hierarchy of Credential Preference

Preferred credentials are resolved in specific order. User-scoped preferences will always takes precedence. Enterprise Manager first searches at the target level, searching first for the preferred credential for that target name. If not found, it then searches for the target type (default) preferred credential. If these user-scoped preferences are not found, Enterprise Manager then repeats the same search at the Global scope, searching first for the target name preferred credential then target type (default) preferred credential.

Enterprise Manager provides a Credential Hierarchy table that depicts the hierarchy determining which preferred credential is used by the system.

The credential search order is always the same and continues until a preferred credential is found: If credentials are not found at one level, Enterprise Manager moves to the next level in the sequence as shown in the following table.

Table 2-3 Hierarchy of Credential Preference

User/Target User 1 User 2 User 3 ... All Users

Target 1

Target 2

Target 3

Level 1

Level 3

.

.

.

All Targets

Level 2

Level 4

This example illustrates the hierarchy of preferred credentials chosen to complete a job if none is explicitly chosen during job execution. The order in which the preferred credential is chosen is always the same. In this example we will assume the job is running as User 2. The following order is always observed until a preferred credential is set at that level.

  • Level 1 - My Preferences, Target Preferred Credential

  • Level 2 - My Preferences, Default (Target Type) Preferred Credential

  • Level 3 - Global Preferences Target Preferred Credential

  • Level 4 - Global Preferences, Default (Target Type) Preferred Credential

It is assumed that the credential has been tested during setup. If a credential is not set at a specific level, the credential sub-system moves on to the next level (checking from level 1 to level 4) until a credential is found. The first credential found is the credential used for the job. Credentials set at subsequent levels are ignored.

Users preferences (preferred credentials), if set, always override global preferences.

Saving Preferred Credentials for Hosts and Oracle Homes

To save the credentials as preferred credentials in Cloud Control, follow these steps:

  1. In Cloud Control, from the Setup menu, select Security, then select Preferred Credentials. The Preferred Credentials page displays.
  2. On the Preferred Credentials page, select either Host or Oracle Home from the list of target types, and click Manage Preferred Credentials.

    Note: For setting up preferred credentials for virtual server targets, select Oracle VM Server as the target type and click the Set Credentials.

    • If you select Host for provisioning tasks, then the Host Preferred Credentials page appears.

    • On the Host Preferred Credentials page, in the Target Preferred Credentials section, select the host target on which you want to provision, and click Set.

  3. On the Preferred Credentials page, from the table, select either Host or Oracle Home, and click Manage Preferred Credentials.
    • If you select Oracle Home for patching tasks, then the Oracle Home Preferred Credentials page appears.

    • On the Oracle Home Preferred Credentials page, in the Target Preferred Credentials section, select the Oracle home you want to patch. Ensure that you set both Normal and Privileged credentials for the targets selected, and click Set.

Saving Preferred Credentials to Access My Oracle Support

To register the My Oracle Support credentials as preferred credentials in Cloud Control, follow these steps:

  1. In Cloud Control, from the Setup menu, select My Oracle Support, and then, click Set Credentials.
  2. On the My Oracle Support page, provide the My Oracle Support credentials, and click Apply.

Oracle recommends you to register the My Oracle Support credentials as preferred credentials in Cloud Control so that you do not have to explicitly provide the credentials every time you access the My Oracle Support console, which is integrated within the Cloud Control console.

Managing Credentials Using EM CLI

You can manage passwords using EM CLI verbs. Using EM CLI, you can perform such actions as:

  • Change the database user password in both the target database and Enterprise Manager.

    emcli update_db_password -change_at_target=Yes|No -change_all_reference=Yes|No
    
  • Update a password which has already been changed at the host target.

    emcli update_host_password -change_all_reference=Yes|No
    
  • Set preferred credentials for given users.

    emcli set_preferred_credential
    -set_name="set_name"
    -target_name="target_name"
    -target_type="ttype"
    -credential_name="cred_name"
    [-credential_owner ="owner]"
    

    And

    emcli set_preferred_credential
    -set_name="set_name"
    -target_name="target_name"
    -target_type="ttype"
    -credential_name="cred_name"
    [-credential_owner ="owner]"
    
  • Determine if a specific target type has perferred credentials configured for it..

    bin/emcli list -res=PreferredCredentials -bind="TargetType = 'host'
    

For a complete list of credential management verbs, refer to the Enterprise Manager Command Line Interface guide.

Host Authentication Features
Setting Up SSH Key-based Host Authentication

Secure Shell or SSH allows data to be exchanged over the network using a secure channel between two devices. SSH is used primarily on Linux and Unix based systems. SSH was designed as a replacement for FTP, telnet and other unsecure remote shells, which send information, notably passwords in plaintext, leaving them open for interception. The encryption used by SSH provides confidentiality and integrity of data over an insecure network. SSH also protects the system against DNS spoofing attacks. This makes SSH a better choice in production environments over telnet/FTP and other username/password based authentications.

You can configure Enterprise Manager to use SSH while performing management operations, thus allowing Enterprise Manager administrators to leverage the security features provided by SSH along with the management capabilities of Enterprise Manager. When authenticating in this mode, the Agent acts as a Java SSH client and connect to the host using the username/password provided in the credential.

Enterprise Manager allows you to store a public-private key pair for administrators and allows them to view and install the public key on the hosts. Administrators can then submit jobs/patching operations in which they specify the credential that refers to the private key to perform the operation. The OMS passes the private key to the Agent along with the commands and the command parameters. Agent invokes the Java SSH client and attempts to connect to the host using the private key. Since the host already has the public key installed, it identifies the private key and successfully authenticates the Agent's Java SSH client. The Agent can now run the commands through the SSH client on the host to perform the requested operations.The username used in the communication must be a valid OS user on both the host and the OMS. This is the username used in the named credential and not the username of the administrator invoking the operation.

Setup Example Session

To generate, manage, or convert SSH authentication keys, you use the SSH-keygen utility available on UNIX systems. This utility SSH-keygen tool provides different options to create with different strengths RSA keys for SSH protocol version 1 and RSA or DSA keys for use by SSH protocol version 2.

Note:

The procedure shown in this example assumes that you have a firm understanding of SSH setup procedures and user and host equivalence using public private key pair using SSH.

You are now ready to add the credential to Enterprise Manager.

  1. From the Setup menu, select Security, then select Named Credentials.
  2. On the Named Credentials page, click Create. The Create Credential page displays.
  3. Enter a Credential Name. For example, SSHCRED1.
  4. Select Host from the Authenticating Target Type drop-down menu.
  5. Select SSH Key Credentials from the Credential Type drop-down menu.
  6. Ensure that the SSH private key/public key files have been copied to the host on which the browser is running. Doing so makes navigating to the files from within the console easier when you click Browse in the next step.
  7. From the Credential Properties region, enter a UserName. This username is a valid OS user that resides on both the Host and the OMS.
  8. From the Credential Properties region, click Browse for Public Key and Private Key to upload the generated public key/private key files.
  9. Click Test and Save to verify the credentials and save them. The new named credential will appear.

Example 2-11 Setting Up SSH key-based Authentication

$ ssh-keygen -t rsa      

The command options instruct the utility to generate SSH keys (RSA key pair).

Generating public/private rsa key pair.
Enter file in which to save the key (/home/myhome/.ssh/id_rsa):  

The path specified is the standard path to the location where SSH keys are stored ($HOME/.ssh).

Enter passphrase (empty for no passphrase)

Important: passphrase is not supported for use with SSH keys in named credentials.

Enter same passphrase again: (empty for no passphrase)
Your identification has been saved in /home/admin1/.ssh/id_rsa.
Your public key has been saved in /home/admin1/.ssh/id_rsa.pub.
The key fingerprint is:
bb:da:59:7a:fc:24:c6:9a:ee:dd:af:da:1b:1b:ed:7f admin1@myhost2170474

The ssh-regkey utility has now generated two files in the .ssh directory.

$ ls  id_rsa  id_rsa.pub

To permit access to the host without having SSH prompt for a password, copy the public key to the authorized_keys file on that system.

$ cp id_rsa.pub  authorized_keys   

From this point, all keys listed in that file are allowed access.

Next, perform a remote logon using SSH. The system will not prompt you for a password.

$ ssh myhost  
The authenticity of host 'myhost (10.229.147.184)' can't be established.
RSA key fingerprint is de:a0:2a:d5:23:f0:8a:72:98:74:2c:6f:bf:ad:5b:2b.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'myhost,10.229.147.184' (RSA) to the list of known hosts.
Last login: Mon Aug 29 16:48:45 2012 from anotherhost.example.com
$

Note:

To view an instructional video Oracle Enterprise Manager 13c: Create SSH Key Named Credentials, go to:

https://apex.oracle.com/pls/apex/f?p=44785:24:0::NO:24:P24_CONTENT_ID,P24_PREV_PAGE:5724,1
Setting Up Host Preferred Credentials Using SSH Key Credentials

Enterprise Manager provides out-of-box support (12.1.0.4) for the use of SSH key credentials to be available and used as preferred credentials. SSH key credential sets are used to authenticate against targets. The introduction of SSH key credential sets is useful when a username and password credential is unknown or when considering alternative security options. SSH keys use encryption methods which provide more confidentiality and integrity of data over an otherwise potentially insecure network. Providing this support out of the box, eliminates the Administrator from creating a custom SSH key credential and facilitates ease of use.

Note:

SSH Credentials are not supported for Windows operating systems.

To set SSH credentials as preferred credential:

  1. From the Setup menu, select Security and then select Preferred Credentials.
  2. Select the 'Agent' or 'Host' target type and then click Manage Preferred Credential.

    The Agent Preferred Credentials Setting page displays. For more information see the "Preferred Credentials".

    This page will default to the page that was last referenced by the administrator. To set the preferred credential, click the My Preferences tab, as shown in the image below.

  3. Under the Default Preferred Credential region, which sets the preferred credential for all targets of the selected target type, an Agent Target Type was chosen. See above graphic.

    Select Host Credentials and then click Set.

    A dialog displays listing the current choice of available Name Credentials most appropriate for this Agent Target Type. For this Administrator. Select the SSH Credential, and click Save.

The Default Preferred Credential will then display the credential which will be used for all targets of type Host for this Administrator. The below image shows that the Credential Set = Host Credential; the Target Username = test, which indicates the OS user who is used in the Named Credential.

This setting means that all Agent connections, by this administrator, will use this credential set to authenticate with all Agents.

Authenticating host credentials

The Enterprise Manager Agent can use two methods to authenticate OS credentials:

  • Traditional Authentication

  • PAM Authentication

With traditional authentication, credentials submitted by users are compared with entries in the system's password database -- that is, against entries found in /etc/passwd and related files, and in remote extensions to those files as defined by OS-specific configuration such as /etc/nsswitch.conf or /etc/netsvc.conf.

With PAM authentication, the Agent uses a feature of the operating system called PAM, or Pluggable Authentication Modules, to validate the credentials submitted by users. PAM is a framework that allows administrators to specify which of a wide range of authentication mechanisms (such as LDAP, Kerberos, RADIUS) should be used by PAM-aware applications. An application identifies itself to PAM using a service-name. If the administrator has configured a PAM definition for that service-name, then the rules in that definition are applied for that application's authentication requests. If not, then the rules for a special default service-name, "other", are used.

The Enterprise Manager Agent identifies itself to PAM using the service name "emagent". If the administrator has explicitly defined an "emagent" PAM service, then the agent will attempt only PAM authentication -- if the method or methods defined for the "emagent" service do not accept a set of credentials, then the operation associated with those credentials will fail.

If the administrator has not explicitly defined an "emagent" PAM service, then the Agent will first attempt traditional authentication; if that attempt fails, then it will attempt PAM authentication, using the "other" service definition. If either the traditional or PAM authentication attempt succeeds, then the operation associated with the credentials will proceed.

Configuring the PAM "emagent" Service

PAM is a complex and open-ended framework, and general advice on configuring it is beyond the scope of this document. Typically, though, a customer who wants Enterprise Manager to authenticate host credentials using PAM will already have some other service defined to use the same PAM rules, and that other service's definition can form the basis for the emagent one.

For example, suppose a customer's Oracle Enterprise Linux host has already been configured for its SSH daemon to use a mix of Kerberos and local authentication when accepting connections. The SSHD service definition file, /etc/pam.d/sshd, might have the following set of authentication rules:

auth        sufficient    pam_fprintd.so
auth        sufficient    pam_unix.so nullok
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so

Here, if the customer has access to a fingerprint scanner attached to the host, authenticate based on that. If finger print authentication does not work, try traditional authentication. If that fails, and if the user's UID is 500 or higher, try kerberos authentication. If that fails, too, then fail the entire authentication.")

The customer might decide that Enterprise Manager should follow the same authentication process, but exclude the fingerprint-scanner check, since Enterprise Manager will not generally have access to the user's finger when it needs to run a job or collect an authenticated metric. So she would create a new service definition file, /etc/pam.d/emagent, and include all the same "auth" lines as in the SSHD definition above, except for the pam_fprintd.so one:

auth        sufficient    pam_unix.so nullok
auth        requisite     pam_succeed_if.so uid >= 500 quiet
auth        sufficient    pam_krb5.so use_first_pass
auth        required      pam_deny.so 

Details of the authentication methods to be used will vary from customer to customer, and the exact method of configuration will vary from platform to platform. But this general approach to defining an Agent PAM service definition should generally be useful: identify an existing service to use as your base, copy that service's definition, and remove any rules that are not appropriate for Enterprise Manager's use.

Sudo and PowerBroker Support

Privilege Delegation, PDP, allows an administrator to perform privileged activities with the privileges of another user. Enterprise Manager uses two authentication utility tools to achieve Privilege Delegation, they are Sudo and PowerBroker.

Sudo: Sudo allows a permitted user to execute a command as the super user or another user, as specified in the sudoers file. If the invoking user is root or if the target user is the same as the invoking user, no password is required. Otherwise, sudo requires that users authenticate themselves with a password by default. Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5 minutes unless overridden in sudoers). sudo determines who is an authorized user by consulting the /etc/sudoers file. For more information, see the manual page on sudo (man sudo) on Unix. Enterprise Manager authenticates the user using sudo, and executes the script as sudo. For example, if the command to be executed is foo -arg1 -arg2, it will be executed as sudo -S foo -arg1 -arg2.

Note:

The certified SUDO versions are 1.6.7 to 1.6.9. Also, note that SUDO 1.7.2 and higher versions are also supported. The certified PBRUN versions are 4.0.8 and 5.x. Higher versions of these utilities may continue to work unless some fundamental changes have been introduced to their behavior.

PowerBroker: BeyondTrust PowerBroker enables UNIX system administrators to specify the circumstances under which other people may run certain programs such as root (or other important accounts). The result is that responsibility for such actions as adding user accounts, fixing line printer queues, and so on, can be safely assigned to the appropriate people, without disclosing the root password. The full power of root is thus protected from potential misuse or abuse-for example, modifying databases or file permissions, erasing disks, or more subtle damage. BeyondTrust PowerBroker can access existing programs as well as its own set of utilities that execute common system administration tasks. Utilities being developed to run on top of BeyondTrust PowerBroker can manage passwords, accounts, backups, line printers, file ownership or removal, rebooting, logging people out, killing their programs, deciding who can log in to where from where, and so on. They can also provide TCP/IP, Load Balancer, cron, NIS, NFS, FTP, rlogin, and accounting subsystem management. Users can work from within a restricted shell or editor to access certain programs or files as root. See your PowerBroker documentation for detailed setup and configuration information.

Note:

PowerBroker 7.1.1 has been tested and is the recommended minimum version.

Enterprise Manager Privilege Delegation uses these tools (Sudo and PowerBroker), together with the use of Named Credentials, to provide a framework to allow Administrators to perform privileged activities.

There are many operations within an organization, where an administrator will need elevated privileges to perform specific tasks. For example, for all the provisioning and patching tasks in Cloud Control, Named Credentials must be set up for normal operating system user account (oracle) and Named credentials for privileged user accounts (root). If you do not have access to either of these accounts, then you can use SUDO or PowerBroker access to switch users to perform the tasks. Privilege

Delegation offers the following advantages:

  • You have the flexibility to use either SUDO or PowerBroker within the same framework.

  • Using the framework, you can now run PowerBroker in a password-less or password-protected mode.

  • You can create a template with these Privilege Delegation settings and reuse that template for multiple hosts. This not only allows you to standardize Privilege Delegation setting across your enterprise, but also facilitates and simplifies the process of configuring and management of Privilege Delegation Settings.

  • You can use the Privilege Delegation settings not only for deployment procedures, but also for jobs in Cloud Control.

The following example explains the different users in the Privilege Delegation process:

Example: Consider three users:

User1 – called EMUSER, is an Enterprise Manager Admin logged into either Cloud Control or EM CLI

User2 – called OSUSER1, is a target host OS user.

User3 – called OSUSER2, is a target host OS user.

EMUSER has a Named Credential for OSUSER1. In which sudo is configured. The Named credential says run as OSUSER2.

The Internal steps for the Privilege Delegation would be as follows:

  1. Log in to a system as OSUSER1

  2. Authenticate using OSUSER1's password

  3. Launch sudo to become OSUSER2

  4. Run the specified command as OSUSER2.

When the command specified is run. It's as if OSUSER2 has logged in. For example if the “id" command is run, it would display as OSUSER2.

Authentication Utility Tools Configuration

The authentication utility tools supported by Enterprise Manager are sudo and pbrun. These tools reside on the target host with the management Agent and before correct operation, must be configured appropriately. The following section outlines these tools and their associated configuration file.

Administrators can set up sudo or pbrun, based on their configuration file entries to assign specific Enterprise Manager functional privileges to their OS users. The Management Agent uses a trusted executable called nmosudo, using the nmosudo executable the Agent verifies, via a cryptographic handshake, the source of the request. Then based on the configuration files of sudo or pbrun, allows a less privileged user to run nmosudo as a more privileged user.

Enterprise Manager guarantees that the nmosudo executable only honors requests to run remote operation requests from the OMS via the Agent. nmosudo will not run the remote operation if it cannot validate that the request came from the Agent. Thus, it will not be possible for user 'johndoe' to invoke nmosudo directly from the command line and run a Perl script as user 'oracle'.

In Enterprise Manager Cloud Control 12c Release 1 (12.1.0.1) [with or without Bundle Patch 1], nmosudo was located in the agent instance directory. For example, /u01/oracle/agent/agent_inst/bin/nmosudo.

In Enterprise Manager Cloud Control 12c Release 2 (12.1.0.2) and subsequent releases, this location has changed. Now, nmosudo is present in the sbin directory, which is in the agent base directory. For example, /u01/oracle/agent/sbin/nmosudo.

Sudo Configuration

Note:

The certified SUDO versions are 1.6.7 to 1.6.9. Also, note that SUDO 1.7.2 and higher versions are also supported.

For more information, see the man page on sudo (man sudo) on Unix.

Sample entries for the sudo configuration file (/etc/sudoers) are shown below. The general format for the files is as follows:

root ALL=(ALL) ALL

This means that the root user can execute from ALL terminals, acting as ALL users, and run ALL commands.

Sample 1

# Sample /etc/sudoers file should have following entry
# If you do not have access to oracle and root accounts,
# then add the following entries into the file:
#usage:
#[user] [terminal]=[as other user] [command] 

#where: user =  the user
terminal =  terminal from where user can run sudo #    cmd
#  as other user = which user the first user may act #    as
#  command = which commands can be run which using #    sudo
 
johndoe ALL=(oracle) /u01/oracle/agent/sbin/nmosudo *
johndoe ALL=(root) /u01/oracle/agent/sbin/nmosudo *
 
#Where, the user johndoe can access sudo from any terminal #to run as oracle the nmosudo executable with all commands, #passed from the console. 
 

Sample 2

# If you have access to the oracle account,
# but not to the root account,
# then only add the following entry into the file:
johndoe ALL=(root) /u01/oracle/agent/sbin/nmosudo  *
 
#Where, the user johndoe can access sudo from any terminal #to run as root the nmosudo executable with all commands, #passed from the console.

Note:

This example illustrates how the SUDOERS file can be configured to allow users to restrict only a subset of commands.

All commands that are executed thru Enterprise Manager using SUDO will be prefixed with the following:

<AGENT_HOME>/sbin/nmosudo DEFAULT_PLGUIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ ACTION <Command-to-executed-with-args>

Customers can use this to restrict the list of commands they want users to use.

For example, if johndoe is allowed to execute only root.sh as root, the following can be added to the SUDOERS file

johndoe ALL=(root) <AGENT_HOME>/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION root.sh

Sample 3

ALL=(ALL)/u01/oracle/agent/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION perl -e exit 0,/u01/oracle/agent/sbin/nmosudo DEFAULT_PLUGIN DEFAULT_FUNCTIONALITY DEFAULT_SUBACTION DEFAULT_ACTION id

This example allows the user to perform a basic PERL test, and run only id command.
Powerbroker Configuration

BeyondTrust PowerBroker enables UNIX system administrators to specify the circumstances under which other users may run certain programs such as root (or other important accounts). The result is that responsibility for such actions as adding user accounts, fixing line printer queues, and so on, can be safely assigned to the appropriate people, without disclosing the root password. The full power of root is thus protected from potential misuse or abuse-for example, modifying databases or file permissions, erasing disks, or more subtle damage. BeyondTrust PowerBroker can access existing programs as well as its own set of utilities that execute common system administration tasks. Utilities being developed to run on top of BeyondTrust PowerBroker can manage passwords, accounts, backups, line printers, file ownership or removal, rebooting, logging people out, killing their programs, deciding who can log in to where from where, and so on. They can also provide TCP/IP, Load Balancer, cron, NIS, NFS, FTP, rlogin, and accounting subsystem management. Users can work from within a restricted shell or editor to access certain programs or files as root. See your PowerBroker documentation for detailed setup and configuration information.

Note:

PowerBroker 7.1.1 has been tested and is the recommended minimum version.

If you want to use pbrun authentication utility, then before editing a Deployment Procedure, update the /etc/pb.conf file to allow a normal user to switch to another user who has the privileges to run the Deployment Procedure.A sample PowerBroker configuration file (/etc/pb.conf) would contain:

Sample:

if(user=="johndoe") if(command=="/u01/oracle/agent/sbin/nmosudo *" ) 
// /u01/oracle/agent/ Agent Home location
 
 
{   
        switch (requestuser)   
        {      
                case "root":         
                        runuser="root";         
                        break;      
                case "oracle":         
                        runuser="oracle";         
                        break;      
                default:      
                reject;     
        } 
        accept;
}

The above example allows user johndoe to execute all commands passed from the console via nmosudo as root and as oracle. Refer to sudo/PowerBroker documentation for detailed configuration information.

Privilege Needed for Creating a Privilege Delegation

Enterprise Manager allows you to create Privilege Delegation settings either by creating the setting directly on a host target, or by creating a Privilege Delegation Setting Template that you can apply to multiple hosts.

  • VIEW: Administrators with View privileges on these host targets will be able to view those privilege delegation settings.

  • FULL: Administrators with Full privileges on host targets can create privilege delegation settings for that host.

Enterprise Manager Super Administrators can configure privilege delegation settings for any host target.

Creating a Privilege Delegation

The use of Privilege Delegation can be invoked using any of the following methods:

  • Cloud Control console

  • EM CLI

  • Privilege Delegation template

Privilege Delegation Templates: Enterprise Manager allows for a default Privilege Delegation template to be set and also for that template to be applied to multiple hosts. This prevents an Administrator from having to apply a Privilege Delegation setting on a host-by-host basis, especially when the same Privilege Delegation setting is being applied to all host targets. This feature is particularly useful when many host targets have been simultaneously added to Enterprise Manager. This feature is also available via EM CLI by using the set_default_privilege_delegation_setting verb.

Setting Privilege Delegation from Cloud Control

To set Privilege Delegation from the Cloud Control console:

  1. From the Setup menu, select Security, then select Privilege Delegation.
  2. On the Manage Privilege Delegation Settings page, select the host name, and then click Edit. This Edit Host Privilege Delegation dialog displays.
  3. Select Sudo or PowerBroker, and specify the location where SUDO or PowerBroker is located (for PowerBroker, you can optionally provide the password prompt) to configure the host with a Privilege Delegation setting.
  4. Click Save.
Setting Privilege Delegation Templates from Cloud Control

You can apply Privilege Delegation settings on a per host basis or to multiple hosts simultaneously. Enterprise Manager allows you to define a default Privilege Delegation template that applies Privilege Delegation settings to multiple hosts. Templates are particularly useful when many host targets have been added simultaneously to Enterprise Manager. This functionality is also available via EM CLI by using the set_default_privilege_delegation_setting verb. See "Setting Privilege Delegation via EM CLI" for more information.

  1. In Cloud Control, from the Setup menu, select Security, then select Privilege Delegation. The Manage Privilege Delegation page displays.
  2. Click the Templates tab to display the Manage Privilege Delegation Templates page.
  3. Click Create. The Create Template dialog displays.
  4. Select a privilege delegation type, either Sudo or PowerBroker.
  5. Enter a name for the template and specify the location where SUDO or PowerBroker is located (for PowerBroker, you can optionally provide the password prompt), and click Save.

For example, if you select SUDO, and if sudo is located in the /usr/sbin/directory, then in the Sudo Command field you need to enter /usr/sbin/sudo -E -u %RUNAS% %COMMAND%.

Note:

If you do not apply the privilege delegation template to a target, and if you configure a step in the deployment procedure to run in Privilege Delegation mode, then the deployment procedure for that target runs the step in normal mode instead.

Once you have created a privilege delegation setting, you must apply this setting to selected targets. This setting can be applied to one more hosts or to a composite (Group) target (the group must contain at least one host target). You can apply a Privilege Delegation setting using the Cloud Control console. From the Setup menu, choose Security and then Privilege Delegation.

Setting Privilege Delegation via EM CLI

The following examples create a setting named sudo_setting. The setting is of type SUDO, and the Sudo path used is /usr/local/bin/sudo. Sudo arguments are:

-S -u %RUNAS%%COMMAND%

Example 1 - Command-Line

emcli create_privilege_delegation_setting
      -setting_name=sudo_setting
      -setting_type=SUDO
      -settings="SETTINGS:/usr/local/bin/sudo -S -u %RUNAS% %COMMAND%"

Example 2 - Scripting and Interactive

create_privilege_delegation_setting
       (setting_name="sudo_setting",
        setting_type="SUDO",
        settings="SETTINGS:/usr/local/bin/sudo -S -u %RUNAS% %COMMAND%")

The following examples create a setting named pb_setting. The setting is of type POWERBROKER, and the PowerBroker path used is /etc/pbrun. Arguments are:

%RUNAS%%PROFILE%%COMMAND%

Example 3 - Command-Line

emcli create_privilege_delegation_setting
      -setting_name="pb_setting"
      -setting_type="POWERBROKER"
      -settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%"
      -separator="settings=;"
      -subseparator="settings=,"

Example 4 - Scripting and Interactive

create_privilege_delegation_setting
      (setting_name=pb_setting
      ,setting_type=POWERBROKER
      ,settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%"
      ,separator="settings=;"
      ,subseparator="settings=,")

The following examples are similar to examples 3 and 4, except that they also add arguments PASSWORD_PROMPT_STRING and Password.

Example 5 - Command-Line

emcli create_privilege_delegation_setting
      -setting_name="pb_setting"
      -setting_type="POWERBROKER"
      -settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%";
       PASSWORD_PROMPT_STRING,password:"
      -separator="settings=;"
      -subseparator="settings=,"

Example 6 - Scripting and Interactive

create_privilege_delegation_setting
      (setting_name=pb_setting
      ,setting_type=POWERBROKER
      ,settings="SETTINGS,/etc/pbrun %RUNAS% %PROFILE% %COMMAND%";
       PASSWORD_PROMPT_STRING,password:"
      ,separator="settings=;"
      ,subseparator="settings=,")
Testing Privilege Delegation Settings

After creating a privilege delegation template and before applying it to a deployment procedure, Oracle recommends you to test the privilege delegation setting.

The following is an example that describes how you can register your credentials as preferred credentials, and also choose to run as another user, and then test the settings by creating a job that checks whether a command is being as normal user or as another user using privilege delegation mechanism.

  1. In Cloud Control, from the Setup menu, select Security, then select Preferred Credentials.. The Preferred Credentials page displays.
  2. On the Manage Privilege Delegation Settings page, from the Related Links section, click Preferred Credentials.
  3. Select Host from the Target Type list and click Manage Preferred Credentials. The Host Preferred Credentials page displays.
  4. From the Target Preferred Credentials region, select the host, and then click Set.
  5. In the Select Named Credential dialog box, specify the normal user name, the normal password, and the Run as user name that you want to switch over to using the privilege delegation mechanism. Then click Test and Save.
  6. After registering the credentials as preferred credentials, from the Enterprise menu, select Jobs, and then click Job Activity.
  7. On the Job Activity page, from the Create Job list, select OS Command, and click Go.
  8. On the Create OS Command Job page, in the General tab, specify a name for the job. Then, from the Target section, click Add to add the host on which you want to run the OS command.
  9. In the Parameters tab, for Command, specify the command id.
  10. Click Submit.
  11. On the Job Activity page, click the job name you just created. Cloud Control displays the status of the job. Click the status column to view its results.

Cloud Control performs the command as the user referenced in the preferred credential.

Agent Support for PowerBroker

The Enterprise Manager Agent supports privilege delegation using Powerbroker as long as pbrun can be invoked with its STDIN, STDOUT and STDERR not on the TTY. You can verify this by executing the pbrun command configured with the Agent, with its STDIN, STDOUT and STDER redirected to files.

In some PowerBroker configurations with this restriction, you will see pbrun errors with the text:"Cannot read ConfirmUser oracle password: no tty" This error may vary with the version of PowerBroker you are using. In Enterprise Manager, you will see errors from any operations performed through the Agent that require PowerBroker (Jobs, secure fetchlet invocations, credential verification operations etc.). You can find the pbrun command configured with the Agent in the following directory:
/agent_inst/sysman/config/emd.properties
The property name that will hold this command template is: EMPDP_SETTINGS_POWERBROKER. In the following example, the above property defines the following template:
EMPDP_SETTINGS_POWERBROKER=/usr/local/bin/pbrun -u %RUNAS% %COMMAND% 
Starting an Agent Using Sudo or PowerBroker Credentials

When performing Agent control operations (such as starting or stopping the Agent) from the Cloud Control console, Enterprise Manager makes a secure shell (SSH) connection to the machine where the Agent is installed in order to carry out the operation. Beginning with Enterprise Manager Release 12.1.0.4, Agent control operations can be performed using Sudo or PowerBroker credentials. For example, an administrator can navigate to the Agent home page and, from the Agent menu, perform Agent control operations.

Using sudo allows a permitted user to execute a command as the super user or another user, as specified by the security policy, which is defined in the config file for sudo, typically located at /etc/sudoers. If the invoking user is root or if the target user is the same as the invoking user, no password is required. Otherwise, sudo requires that users authenticate themselves with a password by default. Once a user has been authenticated, a timestamp is updated and the user may then use sudo without a password for a short period of time (5 minutes unless overridden in /etc/sudoers). sudo determines who is an authorized user by consulting the /etc/sudoers file, this file can also be configured to specify sudo access to certain commands.

Creating a Privilege Delegation Setting

Enterprise Manager allows you to create privilege delegation settings either by creating the setting directly on a host target, or by creating a Privilege Delegation Setting Template that you can apply to multiple hosts.

Administrators with Full privileges on host targets can create privilege delegation settings for that host. Administrators with View privileges on these host targets will be able to view those privilege delegation settings. Enterprise Manager Super Administrators can configure privilege delegation settings for any host target.

To create a privilege delegation setting directly on a host:

  1. From the Setup menu, select Security, then select Privilege Delegation. The Manage Privilege Delegation screen is displayed
  2. Select a host from the table and click Edit. The Edit Host Privilege Delegation Settings dialog displays.
  3. Select a privilege delegation type (Sudo or PowerBroker).
  4. Enter the privilege delegation command to be used and, in the case of PowerBroker, the optional Password Prompt.
  5. Click Save to apply the settings to the host.

    Once you have created a privilege delegation setting, you must apply this setting to selected targets. This setting can be applied to one more hosts or to a composite (Group) target (the group must contain at least one host target). You can apply a Privilege Delegation setting using the Cloud Control console. From the Setup menu, choose Security and then Privilege Delegation.

Configuring and Using Cryptograhic Keys

To protect the integrity of sensitive data in Enterprise Manager, a signing on verification method known as the emkey is used. 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 emkey is generated during repository creation time and is originally stored in repository database. During installation of the first OMS, emkey is copied to the Credential Store and removed from the repository database, that is emkey is secured out-of-the-box. A backup is created in OMS_ORACLE_HOME/sysman/config/emkey.ora.

If the emkey is corrupted and the backup emkey.ora file is lost, all the encrypted information in repository becomes useless. Hence, it is strongly recommended to create a backup of this file on some other machine, so that in case the OMS machine crashes or emkey gets corrupted, the backed up file can be used for recovering the environment.

When starting up, OMS reads the emkey from Credential Store and repository. If the emkey is not found or is corrupted, it fails to start. By storing the key separately from Enterprise Manager schema, we ensure that the sensitive data such as Named Credentials in the Repository remain inaccessible to the schema owner and other SYSDBA users (Privileged users who can perform maintenance tasks on the database) in the Repository. Moreover, keeping the key separate from the schema will ensure that sensitive data remain inaccessible while Repository backups are accessed. Further, the schema owner should not have access to the OMS/Repository Oracle homes.

Repository Encryption Algorithm

Beginning with Enterprise Manager Cloud Control Release 12.1.0.2, the Advanced Encryption Standard (AES) algorithm is used to encrypt data in the Enterprise Manager Repository. The encryption key size is 256 bits.

Prior to release 12.1.0.2, Triple Data Encryption Standard (3DES) was the encryption algorithm used to encrypt repository data.

Configuring the emkey

The emkey is an encryption key that is used to encrypt and decrypt sensitive data in Enterprise Manager such as host passwords, database passwords and others. The emkey.ora file is a copy of emkey should be kept in a safe location for restoration purposes.

During startup, the Oracle Management Service checks the status of the emkey. If the emkey has been properly configured, the OMS uses it for encrypting and decrypting data. If the emkey has not been configured properly, the following error message is displayed.

Example 2-12 emctl start oms Command

Oracle Enterprise Manager 13c Release 2 Cloud Control
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
emctl start oms
Starting HTTP Server ...
Starting Oracle Management Server ...
Checking Oracle Management Server Status ...
Oracle Management Server is not functioning because of the following reason:
The Em Key is not configured properly. Run "emctl status emkey" for more details.

emctl Commands

The emctl commands related to emkey are given below:

  • emctl status emkey

  • emctl config emkey -copy_to_credstore

  • emctl config emkey -remove_from_repos

  • emctl config emkey -copy_to_file_from_credstore -admin_host <host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>] [-repos_pwd <pwd>] -emkey_file <emkey file>

  • emctl config emkey -copy_to_file_from_repos (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <conn desc>) -repos_user <username> [-repos_pwd <pwd>] [-admin_pwd <pwd>] -emkey_file <emkey file>

  • emctl config emkey -copy_to_credstore_from_file -admin_host <host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>] [-repos_pwd <pwd>] -emkey_file <emkey file>

  • emctl config emkey -copy_to_repos_from_file (-repos_host <host> -repos_port <port> -repos_sid <sid> | -repos_conndesc <conn desc>) -repos_user <username> [-repos_pwd <pwd>] [-admin_pwd <pwd>] -emkey_file <emkey file>

    Examples: Use example 1 if your environment is configured with a service name. for all else use example 2.

    Example 1
    emctl config emkey -copy_to_repos_from_file -repos_conndesc '"(DESCRIPTION=(ADDRESS_LIST=(ADDRESS=(PROTOCOL=TCP)(HOST=<>)(PORT=<>)))(CONNECT_DATA=(SERVICE_NAME=<>)))"' -repos_user <> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file < emkey file>
    
    Example 2
    emctl config emkey -copy_to_repos_from_file -repos_host <host> -repos_port <port> -repos_sid <sid> -repos_user <username> [-repos_pwd <pwd> ] [-admin_pwd <pwd>] -emkey_file <emkey file>
    
emctl status emkey

This command shows the health or status of the emkey. Depending on the status of the emkey, the following messages are displayed:

  • When the emkey has been correctly configured in the Credential Store and Repository, the following message is displayed.

  • When the emkey has been correctly configured in the Credential Store and has been removed from the Management Repository, the following message is displayed.

  • When the emkey is corrupted in the Credential Store and removed from the Management Repository, the following message is displayed.

Example 2-13 emctl status emkey - Example 1

Oracle Enterprise Manager 13c Release 2 Cloud Control
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EmKey is configured properly, but is not secure. Secure the EMKey by running "emctl config emkey -remove_from_repos"

Example 2-14 emctl status emkey - Example 2

Oracle Enterprise Manager 13c Release 2 Cloud Control
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey is configured properly.

Example 2-15 emctl status emkey - Example 3

Oracle Enterprise Manager 13c Release 2 Cloud Control
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey is not configured properly or is corrupted in the credential store and does not exist in the Management Repository. To correct the problem:
1) Get the backed up emkey.ora file.
2) Configure the emkey by running "emctl config emkey -copy_to_credstore_from_file"
emctl config emkey -copy_to_credstore

This command copies the emkey from the Management Repository to the Credential Store.

Example 2-16 Sample Output of the emctl config emkey -copy_to_credstore Command

emctl config emkey -copy_to_credstore
Oracle Enterprise Manager 13c Release 2 Cloud Control  
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey has been copied to the Credential Store.
emctl config emkey -copy_to_file_from_credstore

This command copies the emkey from the Credential Store to a specified file.

Example 2-17 Sample Output of the emctl config emkey -copy_to_file_from_credstore Command

emctl config emkey -copy_to_file_from_credstore -admin_host <host> -admin_port
<port> -admin_user <username> [-admin_pwd <pwd>] [-repos_pwd <pwd>] -emkey_file
<emkey file>
Oracle Enterprise Manager 13c Release 2 Cloud Control  
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey has been copied to file.
emctl config emkey -copy_to_file_from_repos

This command copies the emkey from the Management Repository to a specified file.

Example 2-18 Sample Output of the emctl config emkey -copy_to_file_from_repos Command

emctl config emkey -copy_to_file_from_repos (-repos_host <host> -repos_port <port>
-repos_sid <sid> | -repos_conndesc <conn desc>) -repos_user <username> [-repos_pwd
<pwd>] [-admin_pwd <pwd>] -emkey_file <emkey file>
Oracle Enterprise Manager 13c Release 2 Cloud Control  
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey has been copied to file.

Note: Either repos_host, repos_port, repos_sid OR repos_conndesc needs to be specified.

emctl config emkey -copy_to_credstore_from_file

The command removes the emkey from the repository: It secures the emkey, which is the out-of-the-box configuration.

Example 2-19 Sample Output of the emctl config emkey -copy_to_credstore_from_file Command

emctl config emkey -copy_to_credstore_from_file -admin_host <host> -admin_port <port> -admin_user <username> [-admin_pwd <pwd>] [-repos_pwd <pwd>] -emkey_file <emkey file>
Oracle Enterprise Manager 13c Release 2 Cloud Control  
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey has been copied to the Credential Store.
emctl config emkey -copy_to_repos_from_file

This command copies the emkey from a specified file to the repository.

Example 2-20 Sample Output of the emctl config emkey -copy_to_repos_from_file Command

emctl config emkey -copy_to_repos_from_file (-repos_host <host> -repos_port <port>
-repos_sid <sid> | -repos_conndesc <conn desc>) -repos_user <username> [-repos_pwd
<pwd>] [-admin_pwd <pwd>] -emkey_file <emkey file>
Oracle Enterprise Manager 13c Release 2 Cloud Control  
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey has been copied to the Management Repository. This operation will cause
the EMKey to become unsecure.
After the required operation has been completed, secure the EMKey by running "emctl config emkey -remove_from_repos".
emctl config emkey -remove_from_repos

This command removes the emkey from the repository.

Example 2-21 Sample Output of emctl config emkey -remove_from_repos Command

emctl config emkey -remove_from_repos
Oracle Enterprise Manager 13c Release 2 Cloud Control  
Copyright (c) 1996, 2016 Oracle Corporation.  All rights reserved.
The EMKey has been removed from the Management Repository.

Note:

If the emkey is corrupted in the Credential Store, you will not be able to remove it from the Management Repository.

Install and Upgrade Scenarios

This section explains the install and upgrade scenarios for emkey.

Installing the Management Repository

A new emkey is generated as a strong random number when the Management Repository is created.

Installing the First Oracle Management Service

When the Oracle Management Service is installed, the Installer copies the emkey to Credential Store and removes it from repository (emkey is secured out-of-box).

Upgrading from 10.2 or 11.1 to 12.1

The Management Repository is upgraded as usual. When upgrading the OMS, the omsca (OMS Configuration Assistant) copies the emkey to Credential Store and removes from repository. omsca reads the emkey from emkey.ora file present in the old OMS Oracle Home and copies it to Credential Store.

Recreating the Management Repository

When the Management Repository is recreated, a new emkey is generated. This new key will not be in synchronization with the emkey existing in the Credential Store. Follow these steps to synchronize the key:

  1. Copy the new emkey to Credential Store by using the emctl config emkey -copy_to_credstore command.
  2. Take a backup by entering the emctl config emkey -copy_to_file_from_repos command or the emctl config emkey -copy_to_file_from_credstore command.
  3. Secure the emkey by using the emctl config emkey -remove_from_repos command.

Configuring and Managing Audit

All operations performed by Enterprise Manager users such as creating users, granting privileges, starting a remote job like patching or cloning, need to be audited to ensure compliance with the Sarbanes-Oxley Act of 2002 (SAS 70). This act defines standards an auditor must use to assess the contracted internal controls of a service organization. Auditing an operation enables an administrator to monitor, detect, and investigate problems and enforce enterprise wide security policies.

Irrespective of how the user has logged into Enterprise Manager, when auditing is enabled, each user action is audited and the audit details are stored in a record.

Auditing Credentials

For Enterprise Manager 13c, BASIC auditing is enabled by default, thus creating an audit trail of credentials being created, edited, accessed, associated and deleted. Named credentials are first-class security objects on which privileges can be granted or revoked. This means that multiple Enterprise Manager administrators will be able to use and modify the credential objects. Because credentials are sensitive data that can be used to perform various operations on the systems, there is a need to audit the operations on credentials.

Enterprise Manger supports auditing all credential operation, but first needs to be enabled. The auditing information includes, but is not limited to, the current username, credential name, operation performed, operation status success or failure. The audit logs contain information about the credential owner, action initiator, credential name, user name, and target name, job names along with the date time of the operation. Credential fields like password, private keys are never logged.

The following operations are audited:

  • Creating a Named Credential: Creating new Enterprise Manager credentials will be audited.

  • Editing a Named Credential: Editing a credential may consist of changing the username and/or the sensitive credential attributes. Credential edits may also include changing the authentication scheme for the credential.

  • Delete a Named Credential: Deleting a credential from Enterprise Manager will be audited.

  • Associating a Named Credential: A named credential can be set as a preferred credential for a credential set at the target level or at target type level. The named credential can also be reference directly from a job. All operations involving the setting of the named credentials as preferred credentials and using it in a job or deployment procedure will be audited.

  • Accessing a Named Credential: Enterprise Manager subsystems request credentials from the credential store to perform various system management tasks

Default Audit Actions

By default, whenever a user logs in or out of Enterprise Manager, the action is audited. The following list shows the Enterprise Manager infrastructure operations that are also audited by default.

  • Apply Update

  • Change MGMT_VIEW User Password

  • Change Repository Password

  • Configure Authentication

  • Copy EM Key to Repository

  • Remove EM Key from Repository

  • Create Custom CA

  • Remove Update

  • Secure Console

  • Secure Lock

  • Secure OMS

Configuring the Enterprise Manager Audit System

You can configure the Enterprise Manager Audit System by using the following EM CLI commands:

  • enable_audit: Enables auditing for all user operations.

  • disable_audit: Disables auditing for all user operations.

  • show_operations_list: Shows a list of the user operations being audited.

  • show_audit_settings: Shows the audit status, operation list, externalization service details, and purge period details.

  • update_audit_settings: Updates the current audit settings in the repository.

Configuring the Audit Data Export Service

Audit data needs to be protected and maintained for several years. The volume of audit data may become very large and impact the performance of the system. To limit the amount of data stored in the repository, the audit data must be externalized or archived at regular intervals. The archived audit data is stored in an XML file complying with the ODL format. To externalize the audit data, the EM_AUDIT_EXTERNALIZATION API is used. Records of the format <file-prefix>.NNNNN.xml, where NNNN is a number, are generated. The numbers start with 00001 and continue to 99999.

You can set up the audit externalization service for exporting audit data into the file system by using the update_audit_setting -externalization_switch command.

The externalization of audit system data is performed by the EM Audit Externalization Service job. By default, this job is scheduled to run once daily. You can view current status of this job from the Repository Scheduler Jobs Status area in the Enterprise Manager console, as shown in the following graphic.

To access this page, from the Setup menu, select Manage Cloud Control, and then Repository.

Updating the Audit Settings

The update_audit_settings command updates the current audit settings in the repository and restarts the Management Service.

  • -audit_switch: Enables auditing across Enterprise Manager. The possible values are ENABLE/DISABLE. Default value is DISABLE.

  • -operations_to_enable: Enables auditing for specified operations. Enter All to enable all operations.

  • -operations_to_disable: Disables auditing for specified operations. Enter All to disable all operations.

  • -externalization_switch: Enables the audit data export service. The possible values are ENABLE/DISABLE. Default value is DISABLE.

  • -directory: The database directory that is mapped to the OS directory where the export service archives the audit data files.

  • -file_prefix: The file prefix to be used by the export service to create the file in which audit data is to be stored.

  • -file_size: The size of the file on which the audit data is to be stored. The default value is 5000000 bytes.

  • data_retention_period: The period for which the audit data is to be retained inside the repository. The default value is 365 days.

Example 2-22 Usage of the update_audit_setting command

emcli update_audit_settings
      -audit_switch="ENABLE/DISABLE"
      -operations_to_enable="name of the operations to enable, for all oprtations
       use ALL"
      -operations_to_disable="name of the operations to disable, for all
       oprtations use ALL"
      -externalization_switch="ENABLE/DISABLE"
      -directory="directory_name (DB Directory)"
      -file_prefix="file_prefix"
      -file_size="file_size (Bytes)"
      -data_retention_period="data_retention_period (Days)"

Searching the Audit Data

You can search for audit data that has been generated over a specified period. You can also search for the following:

  • Audit details of a specific user operation or all user operations.

  • Audit details of operations with a Success or Failure status or All operations.

From the Setup menu, select Security and then Audit Data. The Audit Data page is displayed. Specify the search criteria in the fields and click Go. The results are displayed in the Summary table.

To view the details of each record that meets the search criteria, select Detailed in the View drop-down list. To drill down to the full record details, click on the Timestamp.

List of Operations Audited

For a complete list of audit operations supported by Enterprise Manager, use the EM CLI show_operations_list verb.

Example 2-23 EM CLI show_operations_list

> 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                      
SECURITY_AUTH_CONFIG                 Configure Authentication                           YES                     

.

.

.

UPDATE_PASSWORD                      Update Password                           NO                      

Auditing the Infrastructure

Beginning with Oracle Enterprise Manger Cloud Control 12c, basic and Infrastructure auditing is enabled by default for Enterprise Manager. In Enterprise Manager, there are over 150 options for auditing. Audit infrastructure operations are always enabled and cannot be turned off. An enhanced Auditing page makes it easy to quickly view the privilege grants on a regular basis and also keep track of which users exercised what privileges, this improves user accountability. Infrastructure activities are audited out of the box, these include updates, downloads, OMS password changes and emkey copy and removes from the Repository.

Also, the search capability of all Audit actions have been enhanced to improved, via the Cloud Control console, you can search for a subset of Audited operations and filter to see operations from specific client hosts and client types(browser or CLI). This provides more efficient ways for audit officers to locate specific operations of interest.

The following table lists all auditable events. Those auditable events shown as enabled are Infrastructure audit events and are turned on out-of-box and cannot be disabled.

Table 2-4 Auditable Events

Event Enabled/Disabled (By Default)

Apply Update

Enabled

Change MGMT_VIEW User Password

Enabled

Change Repository Password

Enabled

Configure Authentication

Enabled

Copy Enterprise Manager Key to Repository

Enabled

Create Custom CA

Enabled

Enterprise Manager Login

Enabled

Enterprise Manager Logout

Enabled

Remove Enterprise Manager Key from Repository

Enabled

Remove Update

Enabled

Secure Console

Enabled

Secure Lock

Enabled

Secure OMS

Enabled

Secure WebLogic Server

Enabled

Access Named Credential

Disabled

Add Registration Password

Disabled

Add Software Library Storage

Disabled

Add Standard-Target Association

Disabled

Add entity to Template Collection

Disabled

Apply Monitoring Template

Disabled

Associate Template Collection to Admin Group

Disabled

Attach Metric Extension

Disabled

Audit Export Settings

Disabled

Audit Settings

Disabled

Change Connector Settings

Disabled

Change Password

Disabled

Change Preferred Credentials

Disabled

Clear Manual Rule Violation

Disabled

Configure Connector

Disabled

Create Administration Groups

Disabled

Create Change Management Setting

Disabled

Create Connector

Disabled

Create Credential Set

Disabled

Create Custom Configuration Specification

Disabled

Create Custom Configuration Specification Parser

Disabled

Create Custom Target Type

Disabled

Create Facet

Disabled

Create Facet Parameter

Disabled

Create Facet Pattern

Disabled

Create Framework

Disabled

Create Metric Extension

Disabled

Create Monitoring Template

Disabled

Create Named Credential

Disabled

Create Real-time Monitoring Rule

Disabled

Create Resolution state

Disabled

Create Role

Disabled

Create Rule

Disabled

Create Rule Set

Disabled

Create Standard

Disabled

Create Template Collection

Disabled

Create User

Disabled

Database Login

Disabled

Database Logout

Disabled

Database Restart

Disabled

Database Shutdown

Disabled

Database Startup

Disabled

Delete Administration Groups

Disabled

Delete Credential Set

Disabled

Delete Custom Configuration Specification

Disabled

Delete Custom Configuration Specification Parser

Disabled

Delete Facet

Disabled

Delete Facet Parameter

Disabled

Delete Facet Pattern

Disabled

Delete Framework

Disabled

Delete Job

Disabled

Delete Management Connector

Disabled

Delete Metric Extension

Disabled

Delete Monitoring Template

Disabled

Delete Named Credential

Disabled

Delete Real-time Monitoring Rule

Disabled

Delete Registration Password

Disabled

Delete Resolution state

Disabled

Delete Role

Disabled

Delete Rule

Disabled

Delete Rule Set

Disabled

Delete Software Library Entity

Disabled

Delete Software Library Folder

Disabled

Delete Standard

Disabled

Delete Target

Disabled

Delete Template Collection

Disabled

Delete Update

Disabled

Delete User

Disabled

Deploy Custom Configuration Specification

Disabled

Detach Metric Extension

Disabled

Disable Rule

Disabled

Disable Rule Set

Disabled

Disable Standard-Target Association

Disabled

Disassociate Template Collection from Admin Group

Disabled

Download Update

Disabled

Edit Framework

Disabled

Edit Job

Disabled

Edit Monitoring Template

Disabled

Edit Registration Password

Disabled

Edit Rule

Disabled

Edit Rule Set

Disabled

Edit Standard

Disabled

Edit Standard-Target Association

Disabled

Edit Template Collection

Disabled

Enable Rule

Disabled

Enable Rule Set

Disabled

Enable Standard-Target Association

Disabled

Execute Command As Agent

Disabled

File Transfer Job

Disabled

Get File Job

Disabled

Grant Privilege

Disabled

Grant Role

Disabled

Import Facet

Disabled

Import Framework

Disabled

Import Real-time Monitoring Rule

Disabled

Import Rule

Disabled

Import Standard

Disabled

Include Action To Monitor

Disabled

Include Filter Facet

Disabled

Include Monitoring Facet

Disabled

Job Execution

Disabled

Mark informational update as read

Disabled

Modify Administration Groups

Disabled

Modify Change Management Setting

Disabled

Modify Custom Configuration Specification

Disabled

Modify Facet

Disabled

Modify Facet Content

Disabled

Modify Facet Parameter

Disabled

Modify Facet Pattern

Disabled

Modify Metric Settings

Disabled

Modify Named Credential

Disabled

Modify Real-time Monitoring Rule

Disabled

Modify Resolution state

Disabled

Modify Role

Disabled

Modify User

Disabled

Move Software Library Entity

Disabled

Publish Metric Extension

Disabled

Purge Software Library Storage

Disabled

Put File As Agent

Disabled

Put File Job

Disabled

Refresh from Enterprise Manager Store

Disabled

Registration Password Usage

Disabled

Remote Operation Job

Disabled

Remove Action From Monitor

Disabled

Remove Change Management Setting

Disabled

Remove Filter Facet

Disabled

Remove Monitoring Facet

Disabled

Remove Privilege Delegation Setting

Disabled

Remove Software Library Storage

Disabled

Remove Standard-Target Association

Disabled

Remove entity from Template Collection

Disabled

Rename Template Collection

Disabled

Reorder Rule

Disabled

Reorder Rule Set

Disabled

Resume Job

Disabled

Resync Agent

Disabled

Resync Repository

Disabled

Retry Job

Disabled

Revoke Privilege

Disabled

Revoke Role

Disabled

Save Monitoring Settings

Disabled

Set Privilege Delegation Setting

Disabled

Stop Job

Disabled

Submit Job

Disabled

Subscribe Update Type

Disabled

Suppress Violation

Disabled

Suspend Job

Disabled

Target Login

Disabled

Target Logout

Disabled

Undeploy Custom Configuration Specification

Disabled

Unsubscribe Update Type

Disabled

Unsuppress Violation

Disabled

Update Database Password

Disabled

Update Metric Extension

Disabled

Update Password

Disabled

Update is available

Disabled

WebLogic Server Auditable Events

The following WebLogic Server events can be audited:

  • Domain update

  • Domain login

  • Domain logout

To audit these events, enter the following EM CLI command:

emcli update_audit_settings
     -operations_to_enable="WEBLOGIC_DOMAIN_UPDATE_INVOKE;WEBLOGIC_DOMAIN
     _LOGIN;WEB_LOGIC_DOMAIN_LOGOUT" 

Note:

only super administrators have permission to view the audited WebLogic Server data.

Additional Security Considerations

After you enable security for the Enterprise Manager components and framework, there are additional security considerations. This section provides the following topics:

Changing Oracle Account Passwords

This section describes the commands used to change the SYSMAN, MGMT_VIEW, and EUS_ENGINE_USER passwords.

Changing the SYSMAN User Password

The SYSMAN user account is used by the Oracle Management Server to login into the Oracle Management Repository to store and query all activity. The password is stored encrypted. If the SYSMAN password changes at the OMR it must also be changed at the OMS, to ensure proper functioning of Enterprise Manager Cloud Control for all operations. This includes other SYSMAN users such as:

  • SYSMAN_STB
  • SYSMAN_TYPES
  • SYSMANUPGR_OPSS

Note:

From 12c onwards, directly modifying the password for SYSMAN or any other repository user at the Repository Database is not recommended. Hence, ensure that the passwords are changed only using one of the methods listed below.

If the current SYSMAN password is known

  1. Stop all OMS instances running emctl stop oms.

    OMS_Home/bin/emctl stop oms

    If JVMD and/or ADP is configured, stop the JVMD/ADP engines:

    emctl extended oms jvmd stop –all

    emctl extended oms adp stop -all

    Execute the same command on all the OMS machines including the primary OMS machine. Do not include '-all' as the Admin Server needs to be up during this operation.

  2. Modify the SYSMAN password on the primary OMS server (where the Admin server is configured):

    cd <OMS_HOME>/bin

    emctl config oms -change_repos_pwd [-old_pwd <old_pwd>] [-new_pwd <new_pwd>] [-use_sys_pwd [-sys_pwd <sys_pwd>]]

    emctl config oms -change_repos_pwd'

    Command Parameters

    Parameter Description

    -change_repos_pwd

    Used to change the SYSMAN password.

    -old_pwd

    This is the current SYSMAN password.

    -new_pwd

    This is the new password.

    -use_sys_pwd

    This parameter is optional and is used to connect to the database as a SYS user. Use this option if SYSMAN account on the database has expired/locked.

    -sys_pwd

    This is the password for the SYS user. Required only if -use_sys_pwd is specified

    Command Behavior:

    Note:

    The above command will prompt you for the current password of the SYSMAN user and the new password.

    The password will be modified at the Repository Database and the monitoring credentials for the 'OMS and Repository' target.

    Along with the SYSMAN password, this command will modify the password for the EM users (SYSMAN_MDS, SYSMAN_OPSS, SYSMAN_APM, SYSMAN_RO) created in the Repository Database.

    Sample Command Output

    emctl config oms -change_repos_pwd 
    Oracle Enterprise Manager Cloud Control 12c Release 12.1.0.1.0 
    Copyright (c) 1996, 2011 Oracle Corporation. All rights reserved. 
    Enter Repository User's Current Password : 
    Enter Repository User's New Password : 
     
    Changing passwords in backend ... 
    Passwords changed in backend successfully. 
    Updating repository password in Credential Store... 
    Successfully updated Repository password in Credential Store. 
    Restart all the OMSs using 'emctl stop oms -all' and 'emctl start oms'. 
    Successfully changed repository password.
    
  3. Stop the Admin server on the primary OMS machine and re-start all the OMS:

    cd <OMS_HOME>/bin

    emctl stop oms –all

  4. Restart all the Management Services:

    cd <OMS_HOME>/bin

    emctl start oms

If the current SYSMAN password is unknown

  1. Stop all the OMS:

    cd <OMS_HOME>/bin

    emctl stop oms

    Execute the same command on the primary OMS machine as well. Do not include '-all' as the Admin Server needs to be up during this operation.

    In addition, check and complete the following steps:

    • If JVMD and/or ADP is configured, stop the JVMD/ADP engines:

      emctl extended oms jvmd stop -all

      emctl extended oms adp stop -all

  2. Modify the SYSMAN password:

    cd <OMS_HOME>/bin

    emctl config oms -change_repos_pwd -use_sys_pwd -sys_pwd <sys user password> -new_pwd <new sysman password>

    Note:

    The '-use_sys_pwd' is used to connect to the database as a SYS user and modify the SYSMAN password in the Repository database.

    The current SYSMAN password is not prompted for and only the new password needs to be entered. This will allow the reset of the old password to the new password entered.

    The password will be modified at the Repository Database and the monitoring credentials for the 'OMS and Repository' target.

    Along with the SYSMAN password, this command will modify the password for the EM users (SYSMAN_MDS, SYSMAN_OPSS, SYSMAN_APM, SYSMAN_RO) created in the Repository Database.

  3. Stop the Admin server on the primary OMS machine and re-start all the OMS:

    cd <OMS_HOME>/bin

    emctl stop oms -all

    emctl start oms

Changing the MGMT_VIEW User Password

To change the password of the MGMT_VIEW user, you have to use the following command:

emctl config oms -change_view_user_pwd [-user_pwd <user_pwd>] [-auto_generate]
Parameter Description

-change_view_user_pwd

Used to change MGMT_VIEW user's password.

-user_pwd

The new password for theMGMT_VIEW user.

-auto_generate

If this option is specified, the password is auto-generated.

  1. Stop all OMSs.

    <OMS_HOME>/bin/emctl stop oms

  2. On one of the OMSs, run the following command:

    <OMS_HOME>/bin/emctl config oms -change_view_user_pwd [-old_pwd <old_pwd>] [ -new_pwd <new_pwd>]

  3. Restart the AdminServer and all the OMSs.

    emctl stop oms -all

    emctl start oms

When you change the password of the MGMT_VIEW user by using the emctl command, the monitoring credentials for the Management Service target, which is set to MGMT_VIEW, does not get updated. You have to change the password manually.

  1. Go to the Enterprise Manager Console URL.
  2. Enter the credentials for a valid Single Sign-On user.
  3. From the Setup menu, select Security, and then Monitoring Credentials.
  4. Select the Target Type as Oracle Management Service and click Manage Monitoring Credentials.
  5. In the monitoring credentials page for the Oracle Management Service target type, update the password for MGMT_VIEW manually to the new password and save the changes.
  6. Click Save.
Changing the EUS_ENGINE_USER User Password

To change the password of the EUS_ENGINE_USER user if it's not managed by RUEI, you have to connect to the database using SQL*plus and use the password command:

  1. Open a terminal window and connect to the database:

    $ sqlplus EUS_ENGINE_USER@database

  2. Use the password command:
    SQL> password
    Changing password for EUS_ENGINE_USER
    Old password: 
    New password: 
    Retype new password: 
    Password changed

Responding to Browser-Specific Security Certificate Alerts

When you connect to Enterprise Manager via HTTPS, the Management Service presents your browser with a certificate to verify the identity of the Management Service. This certificate has been verified by a third party that your computer trusts. When a Web browser encounters an untrusted certificate, it generates security alert messages. The security alert dialog boxes appear because Enterprise Manager's certificate is issued by a Certificate Authority which the browser does not trust.

You can choose to ignore the warnings and continue with your Enterprise Manager session, or you can import the CA certificates into the browser's list of trusted "root" certificates to eliminate the certificate security alerts in future browser sessions.

Third Party Certificate Workflow

The following high-level steps are involved in setting up Enterprise Manager to use third party certificates.

  • Step 1: Generate a wallet and have it certified by a third party authority such as Entrust, Verisign, Thwate, or DigiCert.
  • Step 2: Configure the custom wallets to each OMS. For instructions, see Configuring a Third Party Certificate for HTTPS Console Users
  • Step 3: Add the certificate to the browser's list of trusted root certificates to eliminate further browser certificate warnings. The following sections describe how to respond to browser-specific security alert dialog boxes when you are using Enterprise Manager in a secure environment. Note: Step 3 is not required for well-known certificate authorities such as Verisign or Entrus.
Responding to the Internet Explorer Security Alert Dialog Box

Security is enabled by default for the Management Service. However, if you have not enabled the more extensive security features of your web tier, you will likely receive the following warning: "There is a problem with this Web site's security certificate." This occurs because Enterprise Manager's certificate is issued by a Certificate Authority which the browser does not trust.

When Internet Explorer displays the certificate warning page, use the following instructions to install the certificate and avoid viewing this page again in future Enterprise Manager sessions:

  1. From the certificate warning page, click Continue to this Web site (not recommended).

    Internet Explorer displays a Security Warning dialog.

  2. Click Yes. Internet Explorer may display a Security Alert dialog if you have not selected In the future, do not show this warning. in a previous Internet Explorer session. Click OK to dismiss the dialog.
  3. The Enterprise Manager console logon page displays.
  4. At the top of the browser, click Certificate Error to display the Certificate pop-up.
  5. Click View Certificates. The Certificates dialog appears.
  6. Click the Certificate Path tab and select the first entry in the list of certificates as shown in the following graphic.

    Graphic shows the certificate dialog.

  7. Click View Certificate to display a second Certificate dialog box.
  8. Click Install Certificate to display the Certificate Import wizard.
  9. Accept the default settings in the wizard, click Finish when you are done.

    Internet Explorer displays a Security Warning asking if you want to install the certificate. Click Yes. Internet Explorer will display a message stating that the certificate was imported successfully.

  10. Click OK to close each of the security dialog boxes and click Yes on the Security Alert dialog box to continue with your browser session.

    You should no longer receive the Security Alert dialog box in any future connections to Enterprise Manager when you use this browser.

Responding to the Mozilla Firefox New Site Certificate Dialog Box

Firefox will also issue a connection warning when Enterprise Manager's certificate is issued by a Certificate Authority which the browser does not trust. When you first attempt to display the Cloud Control console using the HTTPS URL in Mozilla Firefox, you will receive a warning because the connection is untrusted.


graphic shows the connection untrusted message.

When Firefox displays the Untrusted Connection page, use the following instructions to install the certificate and avoid viewing this page again in future Enterprise Manager sessions:

  1. Review the instructions and information. Click I Understand the Risks. Firefox displays additional information and the opportunity to add the certificate.
  2. Click Add Exception... . Firefox displays the Add Security Exception dialog.

    graphic shows the add security excpetion dialog.

  3. Ensure that the Permanently store this exception option is selected.

    You should no longer receive the New Site Certificate dialog box when using the current browser.

  4. Click Confirm Security Exception. The Enterprise Manager console displays.

You will no longer receive the untrusted connection warning in any future connections to Enterprise Manager when you use this browser

Responding to the Google Chrome Security Alert Dialog Box

Google Chrome issues a warning if the security certificate of the Website is not trusted. When you first attempt to display the Cloud Control console using the HTTPS URL in Google Chrome, you will receive a warning because the connection is mistrusted.

When Google Chrome displays the Untrusted Connection page, use the following instructions to install the certificate and avoid viewing this page again in future Enterprise Manager sessions:

Note:

Installing a certificate using this method on Google Chrome may still lead to performance degradation. To solve this issue, the best option is to obtain a trusted certificate from a vendor of your choice.

  1. Click on the crossed out lock pad icon on the left hand side of the URL address bar.
  2. Click Certificate Information in the menu.
  3. Select the Certification Path tab.
  4. Select the OMS host name (a red cross icon).
  5. Click View Certificate.
  6. Select the Details tab.
  7. Click Copy to File...
  8. Save the certificate on your Desktop. For example, you can save it as:
    adc1110000.cer
    
  9. From the Google Chrome menu, go to Tools, click Settings, and then select Show Advanced Settings.
  10. Click Manage Certificates.
  11. Select the Trusted Root Certification Authority tab.
  12. Click Import.

    A wizard guides you through the process of importing the saved certificate.

    A warning window displays a message that the certificate you are importing cannot be verified and asks if you want to continue. Click Yes to proceed.

  13. Check if the saved certificate appears in the Trusted Root Certification Authority table.
  14. Restart the Google Chrome browser and load the Enterprise Manager URL. If the Certificate Error icon is not visible in the address bar, then the certificate is valid and trusted.
Responding to Safari Security Dialog Box

Safari does not support the option to install a certificate individually. To solve this issue, you have to obtain a trusted certificate from a vendor of your choice.

Privileged Access Management Integration

Introduction

Privileged Access Management (PAM) solutions eliminate the need for hard-coded application credentials embedded in applications, scripts, or configuration files, and allow highly sensitive passwords to be centrally stored, logged, and managed within the Vault. This unique approach enables organizations to comply with internal and regulatory compliance requirements of periodic password replacement, and monitor and audit privileged access across all systems, databases, and applications.

PAM solutions help provide secure privileged access to critical assets like database and hosts by centrally managing account passwords. PAM solutions provide access rules for both privileged and non-privileged accounts to control who can use those accounts to log on to your assets. As Enterprise Manager (EM) customers incorporate different PAM providers like CyberArk, Centrify, HashiCorp, Oracle Key Vault, etc. Now, we have an extensible Enterprise Manager credential framework that is integrated with PAM providers. This integration allows you to perform tasks such as active database management, database patching, and running host commands in a manner that is compliant with security compliance policies.

The PAM integration with EM provides:

  • PAM solutions provide an external store where credentials are stored and can serve to extend EM’s credentials framework, thereby offering an abstraction layer through the integration.

  • The database or host credentials that are either stored in the repository or in PAM Store need to be supplied to the subsystems in EM using methods such as Jobs and deployment procedures as required.

  • PAM is a secure system so the integration with EM should support token-based authorization for secure access.

  • Since the credentials for database and hosts are stored in PAM and there are multiple PAM providers in the market, EM provides the ability to register the PAM script to securely retrieve the credentials.

  • A data model to create a mapping that allows to create an EM Credential type out of the attributes of the credential fetched from the credential store.

  • This integration allows you to either create a new PAM based named credentials for EM to retrieve the credentials from an external store or modify an existing named credentials to retrieve the credentials from an external store.

  • EM provides the ability to effectively retrieve the password for databases or hosts from PAM to perform activities such as executing jobs and patching databases using fleet maintenance through EM in a manner compliant with their security policies.

Note:

PAM integration with Enterprise Manager only works with Names Credentials.

The diagram below depicts how EM interacts with PAM to retrieve the credentials for database or host from an external store to carry out functionalities in EM such as executing jobs on host or database and database patching using Fleet Maintenance.


Shematic showing how PAM integrates with Enterprise Manager

Using the PAM integration, EM retrieves database and host credentials that are now stored in the external PAM store. To accomplish this, you need to write the integration script that will be registered in EM with all the PAM attributes. When EM requires the database or hosts credentials for using in workflows like database patching or running jobs, the credential framework interacts with the external PAM provider and retrieves the password for database or hosts and passes that credential object to the underlying workflows.

PAM integration with EM consists of three simple steps for all PAM providers.


PAM integration with EM consists of three simple steps for all PAM providers

Understanding the User Roles

Two types of administrators are involved in the integration of the PAM solution: EM Administrator and PAM Security Administrator. The shared ownership of the PAM integration solution with EM is depicted below:


Shared ownership of the PAM integration solution with EM

PAM Security Administrator Role

A PAM security team should guide the EM administrator team to build a script and provide the necessary parameters required for the script execution. This script is required in order to access the PAM provider using REST end points and retrieve credentials for databases or hosts at runtime. The script can be written in Shell or Perl.

EM Administrator Role

An EM Administrator, predefined in EM, configures the PAM script in Enterprise Manager by running the emcli commands.

Prerequisites

Minimum EM version: Oracle Enterprise Manager 13c Release 5 Update 14 (13.5.0.14).

Configuration

Step 1: Develop a script to access PAM credentials

As a PAM Security Administrator, work with your Security or PAM team to develop a script for PAM tools such as CyberArk, and HashiCorp. This custom script connects to a PAM system and retrieves the necessary credentials. The script must meet the following requirements:

  • Written in Shell or Perl. Binary files are not supported.

  • Can use any method to fetch credentials like REST or command line tool.

  • Each credential stored in the PAM system can be referred to using a unique identifier, called a Credential Key. The Credential Key should also be passed on as an argument to the script. You can decide how the argument should be passed, for example any of the formats listed below:

    sh getcreds.sh -k CredKey
    
    sh getcreds.sh -credkey CredKey
    
    sh getcreds.sh CredKey
  • Credentials or authentication tokens required to authenticate a PAM system should be passed through STDIN as key:value pair, not specified in the script. Use one of the ways as shown below:

    1. Script requires just auth token to authenticate with PAM system: On execution of script it should prompt for auth token which is then passed through STDIN:

      sh getcreds.sh -k CredKey
      authtoken:token
    2. Script requires PAM user and password to authenticate with PAM system: On execution of script it should prompt for PAM User & Password which is then passed through STDIN:

      pamuser:user
      pampassword:password
    3. Script requires PAM user, password, certificate path and certificate key to authenticate with PAM system: On execution of script it should prompt for PAM user & password with certificate details:

      pamuser:user
      pampassword:password
      pamcertpath:path
      pamcertkey:key

      A script built to accept certain input parameters securely through STDIN can be configured as is in Enterprise Manager, so when EM executes the script it passes values for such input parameters through STDIN.

  • The script should fetch and print the credentials in a name:value format as shown below.

    sh getcreds.sh -k EMDB/sysman
    pamuser:user
    pampassword:password

    In above example, EMDB/sysman is the Credential key and user/password is the credential fetched from the PAM system.

  • Script should capture error/exception during execution. The errors should be formatted as string, and should be written to STDERR for EM to read and show it in GUI and in calling subsystem processes.

  • The script will be run in any of the OMS hosts in a multi-oms setup, so all the required software installation and configuration required for script execution should be done on all the OMS hosts.

Step 2: Register the PAM Provider with EM

As an EM Administrator, register the PAM provider with EM using the EM CLI command emcli config_cred_provider.

This is a new verb that allows the credential provider to be configured with the required attributes.

emcli config_cred_provider
[-provider_name=\"provider name\"]
[-provider_type=\"provider type\"]
[-access_cred_type=\"cred type\"]
-params="params"
[-refparams="params"]
[-input_file="FILE:file_path"]
[-separator="separator:attribute_name:character"]
[-subseparator="subseparator:attribute_name:character"]

Options:

  • -provider_name: Name of the provider to configure and should contain only alphabets, numbers, hyphen(-) and underscore(_) and not exceed 64 characters.

  • -provider_type: Credential provider type. Current allowed value is ScriptProvider.
  • -access_cred_type: The type of credential that is required to authenticate against this credential provider.

    Example: In case of using PAM user credentials to authenticate with PAM system then create named credentials of type "Host Credentials using the PAM user and password and provide -access_cred_type="HostCreds" and then map the named credential to PAM provider created using set_credprovider_cred.

  • -params : Comma separated set of name=value pairs. It can be used in conjunction with - input_file to specify tags to file paths that contain longer content.

    Example:

    -params="Command:sh %ScriptFile% -key %CredKey%;StdInVars:CACertLoc,AuthToken;ScriptFileExt:sh;Script:getCyberArkPassword" 
    • Example commands that need to be run to fetch credential from PAM depending on the script type being used:

      • sh %ScriptFile% -key %CredKey%
      • perl %ScriptFile% -k %CredKey%

      ScriptFile and CredKey are mandatory keywords, while %ScriptFile% will be replaced by the script file name (in OMS file system), and %CredKey% will be replaced by the credential key provided while creating the named credential.

    • StdInVars: list of input parameters separated by comma that needs to be passed through standard input

      Example:

      StdInVars:AuthToken;
      StdInVars:CACertLoc,AuthToken;
    • ScriptFileExt: supported script file extensions:

      • sh
      • pl
    • Script: tag pointing to the actual script file path which will be defined in the parameter input_file.
  • -input_file: to specify tag pointing to actual file path.

    Example:

    -input_file="getCyberArkPassword:/u01/app/pam_scripts/getcreds.sh" 
  • -refparams: Comma separated set of name=value pairs. Can be used to map input parameters to integration script to any of three below mentioned OMS properties:

    • "oracle.sysman.core.security.auth.cred_provider_prop1"
    • "oracle.sysman.core.security.auth.cred_provider_prop2"
    • "oracle.sysman.core.security.auth.cred_provider_prop3"

Example:

sh getcreds.sh -k CredKey
pamuser:user
pampassword:password
authtoken:token
./emcli config_cred_provider
-provider_name="CyberArk"
-provider_type=ScriptProvider \
-params="Command:sh %ScriptFile% -k %CredKey%;StdInVars:CACertLoc,AuthToken;ScriptFileExt:sh;Script:getCyberArkPassword"\
-input_file="getCyberArkPassToken:/u01/app/pam_scripts/getcreds.sh"\
-refparams="AuthToken:oracle.sysman.core.security.auth.cred_provider_prop1,CACertLoc:oracle.sysman.core.security.auth.cred_provider_prop2"

Once the script is registered in EM, it is stored in the repository table EM_NC_CREDPROVIDER_PARAMS and you can run a select query to see the data. Here is an example of a query:

SELECT * FROM EM_NC_CREDPROVIDER_PARAMS;

Note:

If you would like to re-create the PAM provider registration with EM, you can use the emcli delete_cred_provider command and then execute the emcli config_cred_provider command to re-create it.

Step 3: Create the Credentials Attributes Mappings

Credentials mappings map the keys in the script output (user and password in this example) to credential attributes like HostUserName and HostPassword. Store an attribute mapping to convert stored attributes to those required by credential type. In order to find the credential type attribute names, run the following command:

emcli get_credtype_metadata -authtargettype=<authenticating target type> -credtype=<credential type>

For example, the following command lists the attribute names for HostCreds credential type and host target type.

emcli get_credtype_metadata -authtargettype=host -credtype=HostCreds

Run the following command to create the credentials mappings:

emcli store_cred_mapping
-mapper_name="mapper name" 
-mapper_desc="mapper description" 
-cred_type="cred type" 
-attributesmap="attributes map"

Options:

  • -mapper_name: Name of mapper.
  • -mapper_desc: Description of mapper
  • -cred_type: Type of credential that this mapping is intended for.
  • -attributesmap: Comma separated set of name=value pairs that maps attributes stored in the credential provider to attributes of the specified credential type.

Here are some examples of mappings for a host and a database:

  • Host

    emcli store_cred_mapping 
    -mapper_name="PAMtoHostCreds" 
    -mapper_desc="Map PAM credential attributes to HostCreds type" 
    -auth_target_type=host -cred_type="HostCreds" 
    -attributesmap="user:HostUserName;pass:HostPassword"
  • Database

    emcli store_cred_mapping 
    -mapper_name="PAMtoDBCreds" 
    -mapper_desc="Map PAM credential attributes to DBCreds type" 
    -auth_target_type=oracle_database 
    -cred_type="DBCreds" 
    -attributesmap="user:DBUserName;pass:DBpassword"

Once the credential mapping is created this information is stored in the EM repository tables EM_NC_CRED_MAPPERS and EM_NC_CRED_MAPPER_COLUMNS.

Here is an example to check in repository database:

SELECT m.mapper_name, m.cred_type_name, mc.storage_attr, mc.cred_attr
FROM EM_NC_CRED_MAPPERS m, EM_NC_CRED_MAPPER_COLUMNS mc 
WHERE mc.mapper_guid = m.mapper_guid
ORDER BY m.mapper_name;

Note:

If you would like to re-create the credential mapping, you can use the emcli delete_cred_mapping command and then execute the emcli store_cred_mapping command to re-create it.

Case 1: If the username is not passed while creating the PAM based named credentials, then it should be returned in the script output as shown below.

Example: If you don’t pass the database username in the attributes while creating PAM based named credentials, then it should be returned in the script and mapped using the store_cred_mapping command for Enterprise Manager to understand.

./emcli create_named_credential 
-cred_name=OEM_SYSPAM -auth_target_type=oracle_database
-cred_type=DBCreds 
-alt_cred_storage 
-cred_provider=PAM360 
-cred_key="HRDB/sys"
-cred_mapping=PAM360toDBCreds 
-attributes="DBRole:SYSDBA"

case 1

./emcli store_cred_mapping 
-mapper_name="PAM360toDBCreds" 
-mapper_desc="Map PAM 360 credential attributes to DBCreds type" 
-auth_target_type=oracle_database
-cred_type="DBCreds"
-attributesmap="user:DBUserName;pass:DBpassword"

Case 2: If the username is passed while creating the PAM based named credential, then the script can be built just to return the password as shown below:

Example: If you pass the DB username in the attributes while creating PAM based named credentials, then only the password can be returned in the script and maped using the store_cred_mapping command for Enterprise Manager to understand.

./emcli create_named_credential 
-cred_name=OEM_SYSPAMD 
-auth_target_type=oracle_database
-cred_type=DBCreds 
-alt_cred_storage 
-cred_provider=PAM360 
-cred_key="HRDB/sys"
-cred_mapping=PAM360toDBCreds
-attributes="DBUserName:sys;DBRole:SYSDBA"

case 2

./emcli store_cred_mapping 
-mapper_name="PAM360toDBCreds" 
-mapper_desc="Map PAM 360 credential attributes to DBCreds type" 
-auth_target_type=oracle_database
-cred_type="DBCreds" 
-attributesmap="pass:DBpassword"

Step 4: Create or Modify the Named Credentials

Starting with Oracle Enterprise Manager 13c Release 5 Update 20 (13.5.0.20) credentials can be created using the CLI or the UI.

To create credentials using the UI, from the Settings drop-down menu, go to Security, and click Named Credentials. Click Create, and select the PAM radio button for the Credential Properties options.

Note:

To have the PAM option available in the UI, make sure to complete steps 2 and 3:

PAM creadentials UI

Follow the steps bellow to create the credentials as an EM Administrator, using the CLI:

  1. Use an EM CLI verb to create the new credentials in EM with an alternate credential storage type. The following example creates the named credential ssh1 based on the SSH key named credentials for host myhost.example.com. It indicates that the credential attributes are stored in the OracleKeyVault credential provider at the location emssh1 and that the mapping named OKVSSHCreds can map the attributes required for the HostSSHCreds credential type.

    emcli create_named_credential 
    -cred_name=ssh1
    -auth_target_type=host 
    -cred_type=HostSSHCreds 
    -target_name="myhost.example.com" 
    -target_type=host
    -cred_scope=instance
    -alt_cred_storage
    -cred_provider=<PAM Provider> 
    -cred_key=emssh1
    -cred_mapping=OKVSSHCreds
  2. Modify the Named Credentials as needed. Similar to create_named_cred, the modify_named_credential verb also takes the additional parameters : alt_cred_storage, cred_provider, cred_key, cred_mapping

    The following example modifies the named credential ssh1 based on the SSH key named credentials for host myhost.example.com. It indicates that the credential attributes are stored in the OracleKeyVault credential provider at the location emssh1 and that the mapping named OKVSSHCreds can map the attributes required for the HostSSHCreds credential type.

    emcli modify_named_credential
    -cred_name=<credential name> 
    -auth_target_type=host
    -cred_type=HostSSHCreds 
    -target_name="myhost.example.com"
    -target_type=host
    -cred_scope=instance
    -alt_cred_storage
    -cred_provider=OracleKeyVault-cred_key=emssh1
    -cred_mapping=OKVSSHCreds

    Examples:

    emcli modify_named_credential 
    -cred_name=ORACLE 
    -cred_type=HostCreds 
    -target_type=host 
    -cred_scope=global 
    -alt_cred_storage 
    -cred_provider=PAM360 
    -cred_key="DBHost/oracle" 
    -cred_mapping=PAM360toHostCreds
    
    emcli modify_named_credential 
    -cred_name=OEM_SYS 
    -cred_type= DBCreds 
    -auth_target_type=oracle_database 
    -cred_scope=global 
    -alt_cred_storage 
    -cred_provider=PAM360 
    -cred_key="HRDB/sys" 
    -cred_mapping=PAM360TODBCREDS

    The credential name, type and owner, and storage provider and key, and mapper name are stored in the EM repository tables EM_NC_CRED_MAPPERS and EM_NC_CREDS.

    Here is an example of a query of this data:

    SELECT c.cred_owner, c.cred_type_name, c.cred_name, c.storage_provider, c.storage_key, m.mapper_name
    FROM EM_NC_CREDS c, EM_NC_CRED_MAPPERS m
    WHERE c.cred_name IN ('MANIDB_SYSMAN', 'DBSNMP_LOCAL')
    AND c.storage_cred_mapper_guid = m.mapper_guid (+)
  3. Validate the stored credential by querying the registered and configured PAM provider. The list_cred_mappings is a new verb that shows the result of the earlier store_cred_mapping requests. The list_credential_providers is a new verb that shows the result of the earlier config_cred_provider request.

    emcli list_credential_providers

    Lists the configured credential providers.

    emcli list_cred_mappings 
    -cred_type="cred_type" [-cred_owner="cred_owner"]

    Lists the configured credential mappings for a given credential type (and optional credential owner).

    Options:

    • -cred_type: lists the credential type for which the mappings are requested

    At the completion of these steps, the PAM provider is registered with EM and either a new credential or a modified existing named credential is set up to use the external storage type.

Configuration of Multi-OMS Environments

PAM integration allows the use of the predefined OMS properties mentioned below to set the input parameters of the integration script. However, these OMS properties are local to each OMS and it is required to set values for the properties on each OMS as needed in the multi-OMS environment.

  • oracle.sysman.core.security.auth.cred_provider_prop1
  • oracle.sysman.core.security.auth.cred_provider_prop2
  • oracle.sysman.core.security.auth.cred_provider_prop3
$ emctl set property 
-name "oracle.sysman.core.security.auth.cred_provider_prop1" 
-value "<value provided by your internal security team>"

The rest of the setup steps should be executed only once from one of the OMS servers:

  1. config_cred_provider (Step 2): should be executed only once from one of the OMS servers, and the script content will be stored in the database as a CLOB. The executable script is created in an internal EM directory on each OMS, whenever a PAM credential is invoked.
  2. store_cred_mapping (Step 3): should be executed only once from one of the OMS servers. The contents of the mapping is stored in the EM repository database, and will be used while processing the script output.
  3. create_named_credential/modify_named_credential (Step 4): should be executed from one of the OMS servers

PAM configurations suported in EM

Case 1

Use global OMS properties to store script input parameters to authenticate with PAM system (In case a dedicated PAM user to be used for authentication with PAM system).

  • "oracle.sysman.core.security.auth.cred_provider_prop1"
  • "oracle.sysman.core.security.auth.cred_provider_prop2"
  • "oracle.sysman.core.security.auth.cred_provider_prop3"

Example:

sh getcreds.sh -k CredKey
pamuser:user
pampassword:password
authtoken:token
./emcli config_cred_provider-provider_name="CyberArk"\
-provider_type=ScriptProvider\
-params="Command:sh %ScriptFile% -k %CredKey%;StdInVars:CACertLoc,AuthToken;ScriptFileExt:sh;Script:getCyberArkPassword"\
-input_file="getCyberArkPassToken:/u01/app/pam_scripts/getcreds.sh"\
-refparams="AuthToken:oracle.sysman.core.security.auth.cred_provider_prop1,CACertLoc:oracle.sysman.core.security.auth.cred_provider_prop2"

Case 2

Use of named credential to store PAM authentication details like PAM User Credentials (In case an individual PAM credentials to be used to authenticate with PAM system).

  1. Script when executed prompts to enter PAM user details:

    sh getcreds.sh 
    -k CredKey
    pamuser:user
    pampassword:password
  2. Create a config cred provider with access cred type as HostCreds:

    ./emcli config_cred_provider-provider_name="CyberArk"\
    -provider_type=ScriptProvider\
    -access_cred_type="HostCreds"\
    -params="Command:sh %ScriptFile% -k %CredKey%;StdInVars:CACertLoc,AuthToken;ScriptFileExt:sh;Script:getCyberArkPassword"\
    -input_file="getCyberArkPassToken:/u01/app/pam_scripts/getcreds.sh"\
    -refparams="AuthToken:oracle.sysman.core.security.auth.cred_provider_prop1"
  3. Create a named credential to store PAM user details:

    emcli create_named_credential 
    -cred_name="PAMCreds" 
    -auth_target_type=host
    -cred_type=HostCreds
    -attributes="HostUserName:pam_username;HostPassword:pam_password"
  4. Set credential to be used for cred provider:

    emcli set_credprovider_cred 
    -provider_name= CyberArk 
    -cred_name="PAMCreds"

Typical Use cases

The PAM integration with EM provides a key benefit for the Database Lifecyle Management capabilities, the patching with Fleet Maintenance in particular. This integration allows the use of named credentials stored with PAM to be used during patching tasks.

Patching with Fleet Maintenance

Here are some examples of use cases you can try using Fleet Maintenance. For more information, see Database Fleet Maintenance

Frequently Asked Questions about PAM Integration with Enterprise Manager

This section provides answers to the following frequently asked questions about PAM Integration with Enterprise Manager

What are the components of a PAM integration script?

PAM Integration Script Includes: Inputs, processing logic and outputs:

  • Inputs: parameters passed to the script by Enterprise Manager.

  • Body: processing logic depends on PAM product/solution.

  • Outputs: script output for Enterprise Manager to read and map to credential object.

As mentioned above, Enterprise Manager only understands PAM integration script inputs and outputs.

  1. Inputs to script are configured while creating the PAM credential provider using the emcli config_cred_provider command.
  2. Map script output to Enterprise Manager credential object using the emcli store_cred_mapping command.
How does Enterprise Manager read errors occurring in the PAM integration script?

Enhance PAM integration script to catch all the errors/exceptions and write all error messages to STDERR for Enterprise Manager to process as shown below:

  • Write to STDERR in the shell script using the syntax:

    echo "error message" 1>&2

Enterprise Manager reads the error messages from the STDERR and shows it in the GUI, and in calling sub system process, susch as jobs and deployment procedures.

Example: Error message written to STDERR will be shown in EM GUI and EM Jobs as shown below.


error example


error example 2

How does the PAM integration script get stored within EM and how does EM handle tamperings of the script?

Step 1: Enterprise Manager supports script in Shell and Perl.

The contents of the script are stored in the repository database as CLOB data when the emcli config_cred_provider command is executed to register the script in EM.

Step 2: When the PAM based named credential is invoked after executing emcli config_cred_provider:

  • It creates the executable integration script stored as CLOB in the EM repository in the internal EM directory.
  • If the script file already exists, EM validates the checksum of the script in the internal directory with the checksum of the script in the form of CLOB data, and if the checksum value is the same for both, then it continues to use the integration script in the path. If not, it creates a new integration script file in the EM internal directory with the new CLOB data for the script execution. Any subsequent PAM credential invocation uses the same integration script file in the path which is already created if it is not tampered by any user, or updated by executing the emcli config_cred_provider.

Any tampering or security breach of the script is addressed within Enterprise Manager using checksum validation as explained above.

How to map the script output to an Enterprise Manager credential object?

Case 1

If the username is not passed while creating the PAM based named credential, then the script output should include username as shown below:

Example: If you don’t pass DB username in the attributes while creating PAM based named credential, then it should be included in the script output and map it using store_cred_mapping command for Enterprise Manager to read it from script output and map it to EM credential object.

./emcli create_named_credential 
-cred_name=OEM_SYSPAM 
-auth_target_type=oracle_database 
-cred_type=DBCreds 
-alt_cred_storage 
-cred_provider=PAM360 
-cred_key="HRDB/sys" 
-cred_mapping=PAM360toDBCreds 
-attributes="DBRole:SYSDBA"
./emcli store_cred_mapping 
-mapper_name="PAM360toDBCreds" 
-mapper_desc="Map PAM 360 credential attributes to DBCreds type" 
-auth_target_type=oracle_database
-cred_type="DBCreds"
-attributesmap="user:DBUserName;pass:DBPassword"

Case 2

If the username is passed while creating the PAM based named credential, then the script can be built just to return the password in the output as shown below:

Example: If you pass the DB username in the attributes while creating the PAM based named credential, then only the password can be returned in the script output, and map it using the store_cred_mapping command for Enterprise Manager to read it from the script output and map it to the EM credential object.

./emcli create_named_credential 
-cred_name=OEM_SYSPAMD 
-auth_target_type=oracle_database
-cred_type=DBCreds 
-alt_cred_storage 
-cred_provider=PAM360 
-cred_key="HRDB/sys"
-cred_mapping=PAM360toDBCreds
-attributes="DBUserName:sys;DBRole:SYSDBA"
./emcli store_cred_mapping 
-mapper_name="PAM360toDBCreds" 
-mapper_desc="Map PAM 360 credential attributes to DBCreds type" 
-auth_target_type=oracle_database
-cred_type="DBCreds" 
-attributesmap="pass:DBPassword"
What are the parameters to be passed in the config_cred_provider emcli command?
emcli config_cred_provider 
[-provider_name=\"provider name\"]
[-provider_type=\"provider type\"] 
-params="params"
[-refparams="params"]
[-input_file="FILE:file_path"][-separator="separator:attribute_name:character"]
[-subseparator="subseparator:attribute_name:character"]

Options:

-provider_name: Name of the provider to configure. Name should contain only alphabets, numbers, hyphen(-) and underscore(_) and not exceed 64 characters.

-provider_type : Optional. Credential provider type. This must be one of the supported provider types: ScriptProvider.

-params : Comma separated set of name=value pairs.

-input_file: to specify tags to file paths that contain longer content.

-refparams: Comma separated set of name=value pairs. Can be used to map PAM provider parameters to OMS properties such as: "oracle.sysman.core.security.auth.cred_provider_prop1".

Note:

config_cred_provider: if executed for the first time, it behaves like a creation, and later executions with the same provider_name behaves like a modification. To modify any of the provider details, execute the emcli config_cred_provider command with the same provider name.

What are the available global parameters to be used with the PAM integration feature in EM?

As part of this feature, Enterprise Manager has three global parameters configured to be used for storing PAM parameters, such as authentication token and authentication details.

Customer can use any of the below pre-configured parameters for the PAM integration.

oracle.sysman.core.security.auth.cred_provider_prop1

oracle.sysman.core.security.auth.cred_provider_prop2

oracle.sysman.core.security.auth.cred_provider_prop3

What are the file permissions to be set on the script to register a PAM provider in EM?

Only read permission are required to be set for the script while executing the emcli config_cred_provider command. EM reads the contents of the script and stores them as CLOB data in the EM Repository.

How to avoid long running times of the PAM integration script?

PAM Integration script should manage to time out the script execution and return an error to avoid dangling jobs and threads in Enterprise Manager.