4.5 Assigning Access Privileges

Access privileges can be viewed and modified in the Operations Server console.

It is helpful to consider a user’s role in the organization when assigning access privileges to element hierarchies and/or individual elements. The following primary roles can be subdivided into additional categories if necessary to match your organization:

System Administrator: Responsible for configuring and maintaining the Operations Center environment, including:
- Defining adapter connections to key components such as databases and remote management systems
- Defining service model hierarchies, automations, and operations,
- Defining custom classes, behavior models, and property pages
- Defining calendars, schedules, and jobs
- Creating custom SQL Views views
- Creating Layout views
- Determining which users should have access to specific element hierarchies
Security Manager: Responsible for enforcing company security policies regarding user access to the system, user identification and authorization, password rules, access privileges, and so on. Also responsible for managing users and groups and enforcing password policies and rules.
End Users: Responsible for analyzing and reporting information collected in Operations Center from various sources. You should organize users who have similar authorization to access data into groups, such as by job function or security clearance level.

Special considerations apply to assigning access privileges to elements in the Access Control hierarchy and to the Groups and Users listed under the Security element. The following sections discuss these considerations:

4.5.1 Assigning Privileges to Elements

When you select an element under Security, Access Control, the access privileges for users and groups display in the Access Control pane of the Portal view. Four distinct access privileges can be assigned: View, Manage, Access, and Define. A fifth option is to not define any access privileges.

Understanding Access Control Privileges

The View, Manage, Access, and Define categories have one of three possible settings:

Granted: The user has the selected level of access to the element
Denied: The user explicitly does not have the selected level of access
Undefined (null/blank): The access level has not been defined.

Use the Undefined setting to avoid conflicts, as explained in Table 4-1.

Check marks identify rights that are granted to different user groups. An X explicitly denies a set of privileges to a user or group.

Table 4-1 summarizes each level of access control privilege. The privileges are distinct, and not cumulative. For example, a user who has View but not Manage privileges can view elements, but cannot update their properties or acknowledge their alarms in the Operations Server console. For a user to have Access, Define, or Manage privileges on an element, they must also have View privileges.

Users must have View privileges to at least one element in the Operations Server console before they can log in to the Business Service Dashboard or the Console:

Table 4-1 Access Control Privileges

Access Privilege	Description
View	The user can view elements, as well as their alarms and properties, and relationships to other elements that the user can view. Note for T/EC adapters: Any user with the View permission can suppress a T/EC alarm; however, this user cannot acknowledge or close the alarm.
Manage	The user can perform nonintrusive actions (such as Ping or TraceRoute) as well as update element information (such as custom properties). Note for T/EC adapters: Any user with the Manage permission can acknowledge or close a T/EC alarm.
Access	The user can access remote managed elements by using “connect to” operations with adapters that support cut-through telnet such as the Event Manager, OpenView, and Netcool^*. An example operation is using the Console capability in the Elements hierarchy.
Define	The user can perform administrative tasks such as adding scripts, sites, and service model elements, as well as creating, deleting, and changing the definition of adapters, service models and SLAs in Operations Center.
Undefined	Not defining access privileges avoids conflicts. For example, the two groups in the following figure have the following permissions at the top (root) Access Control level: The admins group has Define privileges explicitly defined. The users group has undefined Define privileges. Therefore, a member of both groups has Define privileges.

HINT:Save a few mouse clicks by keeping the Portal view open as you move from branch to branch and set permissions.

Assigning Group Access Privileges for an Element

Expand Administration > Security > Access Control, then select an element to assign privileges.
Open the Portal view.
Expand the Access Control panel. The list of groups and users who are assigned access to the element displays in the Access Control Entries table.
To add a group to the table, click the Entry for User/Group drop-down list and select a group name.

Groups are identified by this icon: .
The May radio button is selected by default. Select the check boxes associated with the appropriate permission levels. For example, select View and Manage.
(Optional) To explicitly deny a permission level to a group, click the May Not radio button, then click the permission check boxes.

For example, select May Not and View to deny permission to the group to see an element in Operations Center.
Click Set to apply the selected permissions to the group.

The group is added to the table.
Click Apply to save changes to the Access Control panel.

or

Click Apply to All to remove access privileges assigned to subelements of the currently selected element and force them to inherit the privileges from this parent element.

The Apply to All button resets all access privileges.

After assigning group privileges for an element, check to see if some individual users within the group require different permissions for the element. If so, select the individual user and assign different privileges. These override the group permissions.

Assigning Different Privileges for an Individual User

Expand Administration > Security > Access Control, then select an element to assign privileges.
Open the Portal view.
Expand the Access Control panel.

The list of groups and users who are assigned access to the element displays in the Access Control Entries table.
To add a group to the table, click the Entry for User/Group drop-down list and select a user name.

Users are identified by this icon: .
The May radio button is selected by default. Select the check boxes associated with the appropriate permission levels. For example, select View and Access.
(Optional) To explicitly deny a permission level to a group, click the May Not radio button, then click the permission level check boxes.

For example, select May Not and Manage to deny an individual the ability to update the element in Operations Center. Even if a group to which the user belongs has Manage privileges, the user-level privilege prevails, so the user is denied Manage privileges.

This example shows user-level privileges taking precedence over group privileges. The user tjones can view and access the element, but cannot manage it, even though the user belongs to the auditors group, which does have Manage privileges.

4.5.2 Inheriting Access Privileges

By default, every child element inherits permissions from its parent. The exception is if the child element is specifically assigned privileges that are different from its parent. Elements displayed in boldface in the Access Control hierarchy do not inherit access privileges from their parents. You should define general privileges for all groups and users before making individual assignments. This ensures that all levels properly inherit access privileges.

In Figure 4-2, you can see at a glance that the bolded elements have different security settings than their parents:

Figure 4-2 Explorer Pane

The Apply to All option in the Access Control panel of the Portal view forces the inheritance of permissions set on a parent element to all of its children. Use this feature to replace explicit privileges set on all children of a parent element.

4.5.3 Assigning Permissions to User and Group Elements

Group and user names display under the Security element. An administrator can select any group and change the access privileges of its members to the group itself. For example, you might want to allow only a few users to edit the group membership.

Users should have only View permissions to their own user accounts. For example, the user tjones should have View only permissions to the tjones element, located under Security, Users in the Explorer pane. If users have Define or Manage permissions for their own accounts, they can delete themselves or give themselves access to the client and portal, add themselves to groups, and perform other unauthorized actions.

For similar reasons, users should not have Define or Manage permissions for the groups to which they belong.

IMPORTANT:Never delete the admin or guest user accounts. Do not provide these users with Define permissions on the admin or guest elements because they should not be allowed to delete themselves.

To ensure that administrators do not inadvertently deny themselves access to the group, permissions for the admins group element cannot be edited. Also, admin is not listed in the Explorer pane under Users, because no one should edit the admin account privileges.

The account used for the Operations Center InterConnection adapter connections can have administrative privileges and be a member of the admins group. Remote administration functions are possible over an InterCommunication connection, as described in the Operations Center Server Configuration Guide.