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

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.

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.

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.

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.

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

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

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

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.

Oracle-defined Roles: Enterprise Manager 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 roles predefined by Oracle, see Oracle-defined 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 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 with 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 consist of 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

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, for example, 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.

1. Create a target group. On the console go to Targets, select Groups from the menu.
2. Click Create from the menu and select Group.
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. Click Add button, and select the Database Instance targets from the list. Click Select.
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 Next.
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 Add. 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, only modify the DBAGroup privilege for this Role, leaving the WLSGroup, with the default View privilege. Select the pencil icon, next to View in the Manage Target Privilege Grants column. Click Continue.
15. Click the privilege Full, and click Continue.
16. The new privilege will be displayed. Click Next.
17. Click Next on the Resource Privilege page.
18. Select the Administrators you want to grant this role, DBA-ROLE too. Click Next.
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.

1. Create a group of targets. In the console, go to Targets, select Groups from the menu.
2. Click Create and select Group from the drop down menu.
3. Enter the name of your new target group, for this use case, you can enter 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. Click Add and select the targets from the list.
5. Click 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. Navigate to the roles page, go to the Setup, Security, Roles page.
8. Click Create button.
9. In the General page, type the name of the new Role, DEV-ROLE, click Next.
   
   

   

   
   
10. Click Next on the Roles page.
11. In the Target Privileges page, scroll down to the Target Privileges section. Click Add. The available targets are displayed. Select the Group Target Type, to improve the search. Select the group we just created, DevGroup. Click Select.
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. Select the pencil icon, next to View in the Manage Target Privilege Grants column.
13. Click the privilege Connect Target Read-Only, and scroll to the bottom of the page. Click Continue.
14. The new privilege is displayed. Click Next.
15. Click Next on the Resource Privilege page.
16. Select the administrators you want to grant this role, DEV-ROLE too. Click Next.
17. Review the setting of your new role DEV-ROLE.
18. Next, 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. Navigate to Setup, Security, Named Credential.
19. Click Create.
20. Enter the user name and password information that this named credential will use to log onto the database. The following information is selected:

    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 user name and password for the target type specified above.

    Scope: Global - For this use case, this user name and password will apply to every database. Click Test and Save.

21. Enter a valid test target name, and click Test and Save.
22. The new named credential is displayed. To grant this named credential to a one of the development Engineers, click Manage Access.
23. Click Add Grant.
24. Select the development engineers who must use this named credential. Click Select.
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 will not beable to perform any write operation to the databases. If the user attempts to perform a write operation on any database, the following error is displayed in Enterprise Manager:

    Failed to commit: Enterprise Manager stops you from performing the task because you are performing this operation using a READONLY connection.

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.