Unsupported content


This version of the product is in limited support. However, the documentation is available for your convenience. You will not be able to leave comments.

Managing access rights and capabilities for specific cases

While for most objects of the BMC Client Management database security on the capabilities and access levels can be defined in the same way, there are some exceptions to the rule, which are detailed as follows.

Permissions for administrators

The administrators, their groups and their capabilities have specific requirements regarding their security settings for both the capabilities as well as in the definition of their access.

Default capabilities

The capabilities defined for the operation with administrators, administrator groups and capabilities are the same. This means, that there is no distinction between working on an individual administrator or on working with a group. It also includes working on the capabilities through their specific node. For example, if an administrator is assigned the capability to manage administrators, he will also be able to create administrator groups and he can also modify or delete these groups as well as modify their capabilities, through the Capabilities tab or through the Capabilities node.

Default access rights

As you can see on the console neither the Administrators nor the Administrator Groups node have a Security tab. Access rights must therefore be defined individually through the Security Profile node or the Security tab of the respective administrator or administrator group.

Permissions required to administrate an object

When a new administrator is created in the database, he is automatically added to his own Security tab with the following access rights defined: Read Allow and Write Deny . Through this the newly created administrator is able to see himself in the console and to check his capabilities, for example, but he cannot make modifications to any of his settings.

When an administrator is to modify access rights to a specific object he must have the following capabilities and rights:


The Device Topology node is not an object in the database and as such does not have a specific Security tab defining its accessibility and it cannot be included in the Security Profile either. It will thus always be part of the directory tree of every administrator, even if some of them cannot see anything under the top node. To view devices under this node:

  • The administrator has at least the View Devices capability. The administrator must have at least read access to the devices. Be aware that he needs read access to the complete hierarchy to these devices, that is, to the master as well as all the relay hierarchy under which the devices are located.

To provide your administrator with read access to all devices in the system in the Device Topology node, the following steps must be executed.

Permissions for accessing devices and device groups

Devices and device groups are a specific case, because devices cannot be seen or accessed in any way if the corresponding permissions, capabilities and access rights, have not been accorded to the device groups they are a member of.


Contrary to the administrators and their groups, devices and device groups have separate capabilities which must be assigned. Assigning the capabilities for device groups follows the general rules, but if devices are to be viewed/managed as well you need to specify these capabilities separately as well. Device groups also have an extra capability, Populate , which must be defined when the content of the group is concerned, such as when you manually add or remove a device from a group or when the group is to be dynamically managed through a query or a directory server.

Access Rights

Devices can be accessed under two different nodes: the Device Topology and the Device Groups nodes. How to define the access to the devices in the Device Topology is explained in the following paragraph, and can be sufficient for a specific type of administrator. However, in other cases, it might be useful for administrators to be able to access their devices via the Device Groups node. For this to be possible, you need to assign at least read access to the Device Groups top node as well as any other device group (including its hierarchy structure to access the respective group) the administrator needs to access.

Permissions for discovering assets

The Asset Discovery presents the following specific situations.

Permissions for launching the scanning wizard

To be able to launch the scanning wizard an administrator needs to have the Asset Discovery view capabilities on scan configurations, target lists and devices as well as the manage and assign capability on scan configurations.

The wizard can either use existing objects to execute or they can create new ones. Be aware, that to create new objects you need the manage capability for the top node of the respective object or at least one of its folders. By default objects created with the wizard will be located directly under the object‘s top node. If you do not have access to this node the new object will be created in the first folder for which you do have access rights. Otherwise, that is, if you do not have access to any of the objects of the type the object created via the wizard will be stored under the Lost and Found node.

Permissions for defining the scan targets

Target lists in Asset Discovery can consist of devices known to the database, thus with defined security and devices without CM agent . Once a scan is executed on a target list the vulnerability inventory will be available via the console and the administrator, who created the scan can see the inventory for all the devices he was not expressly forbidden the access. As yet unknown devices without CM agent will be added to the database now with the status 'scanned' and no security defined, and any administrator with read access on the respective target list and thus the target devices can view the scan results.

Permissions for defining a device as as a scanner

To define a device as a scanner or remove it from this functionality the Manage capability as well as Write access rights one the respective device are required.

As scans are assigned to their scanner and not to a top node of this type, when removing a device as a scanner all scans assigned to this scanner will also be removed. The administrator therefore also must have the capability Scan - Manage , as well as the Write access rights to all scans and folders defined under the respective scanner.

This version of the documentation is no longer supported. However, the documentation is available for your convenience. You will not be able to leave comments.