Configuring and Using Target Credentials

The following topics are discussed in this section:

Credential Subsystem
Pluggable Authentication Modules (PAM) Support
Sudo and Powerbroker Support

During a Zero Downtime (ZDT) maintenance period, no credentials can be created, updated, or deleted by using the EM CLI commands create_credential_set, delete_credential_set, and update_credential_set. Additionally, in the same maintenance period, the monitoring credentials cannot be set or cleared using either the Enterprise Manager console or the EM CLI commands set_monitoring_credential and clear_monitoring_credential.

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.

Credentials are encrypted and stored in Enterprise Manager. 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: 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:

In Enterprise Manager, from the Setup menu, select Security, then select Named Credentials.
On the Named Credentials page, click Create.
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.
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.
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 Enterprise Manager, 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.
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. 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:

Create the Named credentials using the steps mentioned in Creating Named Credentials.
On the Named Credentials page, select the credential, and then click Edit.
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:

From the Setup menu, select Security and then Preferred Credentials. The Preferred Credentials page displays.
Choose a target type from the list.
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.

User/Target	User 2	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 Enterprise Manager, follow these steps:

In Enterprise Manager, from the Setup menu, select Security, then select Preferred Credentials. The Preferred Credentials page displays.
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.
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 Enterprise Manager, follow these steps:

In Enterprise Manager, from the Setup menu, select My Oracle Support, and then, click Set Credentials.
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 Enterprise Manager 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 Enterprise Manager 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

This section covers the following topics:

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.

From the Setup menu, select Security, then select Named Credentials.
On the Named Credentials page, click Create. The Create Credential page displays.
Enter a Credential Name. For example, SSHCRED1.
Select Host from the Authenticating Target Type drop-down menu.
Select SSH Key Credentials from the Credential Type drop-down menu.
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.
From the Credential Properties region, enter a UserName. This username is a valid OS user that resides on both the Host and the OMS.
From the Credential Properties region, click Browse for Public Key and Private Key to upload the generated public key/private key files.
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 user name 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:

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

The Agent Preferred Credentials Setting page displays. See 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.
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 Enterprise Manager, 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 Enterprise Manager.

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

Log in to a system as OSUSER1
Authenticate using OSUSER1's password
Launch sudo to become OSUSER2
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'.

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

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

To set Privilege Delegation from the Enterprise Manager console:

From the Setup menu, select Security, then select Privilege Delegation.
On the Manage Privilege Delegation Settings page, select the host name, and then click Edit. This Edit Host Privilege Delegation dialog displays.
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.
Click Save.

Setting Privilege Delegation Templates from Enterprise Manager

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.

In Enterprise Manager, from the Setup menu, select Security, then select Privilege Delegation. The Manage Privilege Delegation page displays.
Click the Templates tab to display the Manage Privilege Delegation Templates page.
Click Create. The Create Template dialog displays.
Select a privilege delegation type, either Sudo or PowerBroker.
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 Enterprise Manager 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.

In Enterprise Manager, from the Setup menu, select Security, then select Preferred Credentials.. The Preferred Credentials page displays.
On the Manage Privilege Delegation Settings page, from the Related Links section, click Preferred Credentials.
Select Host from the Target Type list and click Manage Preferred Credentials. The Host Preferred Credentials page displays.
From the Target Preferred Credentials region, select the host, and then click Set.
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.
After registering the credentials as preferred credentials, from the Enterprise menu, select Jobs, and then click Job Activity.
On the Job Activity page, from the Create Job list, select OS Command, and click Go.
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.
In the Parameters tab, for Command, specify the command id.
Click Submit.
On the Job Activity page, click the job name you just created. Enterprise Manager displays the status of the job. Click the status column to view its results.

Enterprise Manager 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 Enterprise Manager console, Enterprise Manager makes a secure shell (SSH) connection to the machine where the Agent is installed in order to carry out the operation. The 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:

From the Setup menu, select Security, then select Privilege Delegation. The Manage Privilege Delegation screen is displayed
Select a host from the table and click Edit. The Edit Host Privilege Delegation Settings dialog displays.
Select a privilege delegation type (Sudo or PowerBroker).
Enter the privilege delegation command to be used and, in the case of PowerBroker, the optional Password Prompt.
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 Enterprise Manager console. From the Setup menu, choose Security and then Privilege Delegation.

Configuring and Testing OCI Credentials

To enable access to Oracle Cloud Infrastructure (OCI) from Oracle Enterprise Manager (OEM), you must configure and test OCI account credentials as global named credentials. This is the first step to ensure that the credentials are properly configured, functional, and ready for managing OCI resources through OEM.

First, define a global named credential for your Oracle Cloud Infrastructure account. Next, test if it is successful in establishing a connection with Oracle Cloud Infrastructure.

Define a Global Named Credential in Enterprise Manager for OCI in Oracle Enterprise Manager Administrator's Guide
Test OCI Credentials

Test OCI Credentials

The OCI credentials used for connecting with Oracle Cloud Infrastructure from Enterprise Manager are saved as named credentials in Enterprise Manager. You can test the proper working of the credentials by testing the connectivity to OCI by specifying the required parameters as follows:

Locate your OCI credentials in the Named Credentials page. From Enterprise Manager menu, click Setup, select Security, and navigate to Named Credentials. The Named Credentials page opens.
Select the named credentials that correspond to the OCI credentials that you want to test, and click Test.

The Test Options dialog box opens.
Enter the Realm Domain for accessing the OCI account, for example, oraclecloud.com. Alternatively, click the search icon and select one from the options available.
Enter the Region Identifier for the region in which your OCI account data is available, for example, us-phoenix-1. Alternatively, click the search icon and select one from the options available.
In the Connection From section, select one of the below connection configurations:
- Oracle Management Server: Select this option to use the agent installed in the OMS host to communicate with OCI to perform the test.
- Oracle Management Agent: If you select this option, the Agent field is activated. Click the search icon to select the agent. The Select Agent dialog box opens. From the list of agents available, select the right registered EM agent to test the connection.
Optionally, if you want to use a proxy to communicate with OCI, then in the HTTP Proxy Settings section, enable the check box Use Proxy.
- In the Host field, enter the proxy server host name or its IP address.
- In the Port field, enter the port number associated with the proxy configuration.
Click Test to validate the connection. Enterprise Manager uses the specified parameters to attempt communication with OCI and display the test result.

A successful test confirms that the credentials are correctly configured and operational. If the test fails, error message provides guidance on whether it is due to incorrect credentials or network connectivity.