Roles and permissions
Security in BMC Client Management must be set up on two different levels: on the clients and on the console. It is defined through a number of different objects and methods, such as authentication/authorization, encryption, privacy and audits.
Administrators and administrator groups
Security for the console in BMC Client Management is ensured via a number of different methods and objects, one of these are the administrators and administrator groups. Each of these has a capability list which dictates what an administrator can do. The administrator and administrator group nodes and their capability definitions specify the access to the console in general, that is, who can interrogate or manipulate the database and its information.
Administrators
Every user that might need to log on to the CM console must be defined as an administrator in the BCM database with a login name and a password. These administrators can then be restricted in their capabilities to specific object types and operations and grouped accordingly.
Administrator Groups
Administrator Groups are a way of organizing all existing administrators within your system. The structure defined through your groups is individual and freely configurable by the responsible person. Administrators can belong to more than one group. Groups can be created for example according to the following criteria:
- geographical location and the administrator's function there,
- corporate structure and the administrator's position within, or
- assigned capabilities
Access rights and capabilities
The security of the console is enforced through the administrators and administrator groups registered in the BCM database . Each administrator and administrator group has a CCL (Capability Control List) which dictates what it can do. The administrators and administrator groups nodes and their capability definitions specify the access to the console in general, that is, who can interrogate or manipulate the database and its contents. The access of administrators to objects is restricted by an ACL (Access Control List) that includes the following possibilities: READ/WRITE/ASSIGN. The Security Profile node or the Security tab define these access rights for specific objects. When you log on to the console for the first time and go to the Administrators node under the Global Settings node you can see two administrators already been created:
- admin
The admin user is equipped with all permissions and capabilities, that is, it has full access rights on all objects in the database. It cannot be deleted but its password can be modified, however, neither its capabilities nor its static and dynamic objects. It can also be regarded as the superadministrator. - system
The system user is the login used by the master server itself for all database actions which it executes automatically, such as those of the data mover or autodiscovery module. None of its settings can be modified. The icon of this administrator is dimmed to indicate that the account is not activated.
Security considerations
Before you start to create administrators and groups you should sketch your system and the people administrating it as well as establish a list of all tasks to be executed and by whom to define which administrators and groups to create and which capabilities and access rights to assign to them.
Considerations to be taken into account when defining the access rights to the objects for each administrator are the following:
Capabilities
- Which object types is the administrator or group concerned with?
- Which other objects are implicated through the original object, such as when you create or modify queries, do you also need to be able to see the queries' object type?
- What operations is the administrator or group to execute on the object type: only see it or be able to do something with it, such as creating new objects of this type, modify existing ones or deleting them, being able to assign them to object of other types, etc.?
Access Rights
- Which top nodes does the administrator need access to, is it easier to provide access via a group and then populate it accordingly?
- For which objects types is it necessary to create queries to make sure any newly created objects of the type will be accessible by administrators through the dynamic objects?
- To which other object types do you need at least read access, for example, for reports you need at least read access to some queries, devices and device groups, for operational rules and packages you need read access to some device groups and devices.
- No general security is specified for the following main nodes: Administrators , Administrator Groups and Directory Servers , the security is specified via its members. All these nodes are located under the Global Settings.
The table below shows some of the specific features available to each of these roles.
| Roles | |||||
|---|---|---|---|---|---|
| Feature | System Administrator | Security Administrator | Configuration Manager | Application Developers | End users |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|  | |
| Configuring Windows Devices for Device Management |
|
|
|
|
|
| Configuring device settings for power management |
|
|
|
|
|
|
|
|
|
| |
| Configuring agent |
|
|
|
|
|
| Configuring Operational Rules |
|
|
|
|
|
| Setting up inventory |
|
|
|
|
|
| Configuring Financial Asset Management |
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
|
|
|
|
| |
Comments
Log in or register to comment.