What needs to be configured to give an Asset Admin user access to view and modify a CI?

A customer requested information explaining what configuration is required to
provide read / write access to a user configured with the Asset Admin permission
group.

Product
BMC Atrium CMDB 2.x
Environment
All
Solution
To give someone access to BMC Atrium CMDB, you must create an AR System user for them on the server where BMC Atrium
CMDB is installed. You can then make that user a member of multiple groups and assign those groups to roles that allow them
access to different parts of the application and its data. The application is designed with two primary deployable application roles
that are central to the permission model. These two are CMDB Data View and CMDB Data Change. These two roles are defined
in the CMDB 2.1 Installation and Configuration Guide as:
CMDB Data View: View class instances. Works in conjunction with the CMDBRowLevelSecurity and CMDBWriteSecurity
attributes.
CMDB Data Change: View, create, and modify class instances. Works in conjunction with the CMDBRowLevelSecurity attribute.
The ITSM applications contain pre-defined groups, such as Asset Admin, which are configured with specific access in mind. An
Asset Admin user is provided access to:
Write access to manage CIs
Relate one CI to another CI
Manage inventory
Write access to manage contracts
Manage configurations
Manage costs
Bulk update functions
Schedule functions
Does not provide access to purchasing or receiving
The following are key elements to understand after Asset Management has been installed and a user has been created with the
Asset Admin permission group.
1. The CMDB Data Change Group contains a computed group mapping including the Asset Admin permission
2. The CMDB Data Change role, from the Roles form, is mapped to the CMDB Data Change Group
3. CTM:People records are configured with 'Unrestricted Access' or for explicit operating companies such as 'My Company'. Each
of these entries, either individual companies or Unrestricted Access, have related group entries.
The CMDB Data View and CMDB Data Change roles do not completely control access to instances (CI's) in BMC Atrium CMDB.
They control access to the contents of instances in general. But to view or modify a specific instance, a user must also have rowlevel
security to that instance. Row-level security is controlled by an attribute that exists on every class. There is also an attribute
that controls write security.
If a user is configured as an Asset Admin they have the CMDB Data Change role due to the out of the box ITSM mapping
discussed above. To view and modify a CI this user also needs to have one of the group id's to which they belong in the
CMDBRowLevelSecurity field. When a CI is created the CMDBRowLevelSecurity field is populated with "Unrestricted Access"and the Group ID for the associated Company to which the submitter belongs. It is also possible to include the group id's of
support group entries in the CMDBRowLevelSecurity field. Here is a basic example that will provide the "asset_admin" user read /
write access to a CI.
1. Login as an Administrator (such as Demo) and open BMC.CORE:BMC_ComputerSystem
2. Create a new CI called cs_perm_test in BMC.ASSET with no data values in the CMDBRowLevelSecurity field
3. Login to a second User Tool as an ITSM administrator (appadmin is provided out of the box)
4. Create a new user called asset_admin from the Application Administration Console and assign the Asset Admin permission
group. Configure this user without Unrestricted Access to ensure that they only see CI's for a specific company or support group.
5. Login to the User Tool as the asset_admin user
6. Access the Asset Management Console
7. Perform a search using the Manager Console Search Criteria for Status = All Assets, CI Type = Computer System and Role =
All
8. Notice that the cs_perm_test Computer System is not presented in the list of CI's.
9. Return to the first User Tool session (AR Administrator login) and open the User record for asset_admin
10. Copy the group id of one of the companies or support groups. An example would be the 1000000001 entry for My Company.
Additional entries could exist for support groups to which this user belongs such as 1000000002 for My Company->IT Support
Organization->Internal Support
11. Search BMC.CORE:BMC_ComputerSystem for the CI named cs_perm_test.
12. Paste the group id copied in step 10 into the CMDBRowLevelSecurity field and save the CI
13. Return to the asset_admin User Tool session and refresh the Manager Console Search. The cs_perm_test CI should now be
visible in the Asset Console.
14. Highlight cs_perm_test and select the View button
15. Update the TokenId attribute with any character value and save the CI.
This procedure should demonstrate that an Asset Admin users can view and modify any CI for which a group entry exists in the
CMDBRowLevelSecurity field to which they belong. It is also possible to assign default group ids to the CMDBRowLevelSecurity
(and CMDBWriteSecurity) field using the BMC.CORE.CONFIG:BMC_DefaultAccountPermissions form.
Question
How does the BMC.CORE.CONFIG:BMC_DefaultAccountPermissions form work?
Answer
This is an example to demonstrate the information provided in the CMDB 2.1 Installation and Configuration Guide pages 60 - 61.
This section documents how an administrator can specify the default permissions assigned on Submit (not modify) for CMDB
CI's. Additional information regarding the architecture is also provided in the CMDB 2.1 Concepts and Best Practices Guide
pages 93 - 94.
scenario 1
========
1. Assume in your BMC.CORE.CONFIG:BMC_DefaultAccountPermissions Form, you have an entry with these values:
ASSIGNRowLevelSecurity: 1000002554
ASSIGNWriteSecurity: 1000002554
MATCHAccountID: East
MATCHAppliedToClassId: BMC_ComputerSystem
2. Create a new BMC.CORE:BMC_ComputerSystem CI with an AccountID value of "East" and Click [SAVE]. Search for this CI
and you should see both the RowLevelSecurity and the WriteSecurity have a value of "1000002554". This is because the CMDB
assigns ClassId of "BMC_ComputerSystem" which matches the value found in the MATCHAppliedToClassId entry. Also key to
this assignment is the AccountID of "East" which matches the entry found in MATCHAccountID.
3. Create a new CI for BMC_Printer (a child of BMC_ComputerSystem) with an AccountID value of "East" and Click [SAVE].
Search for this CI and you should NOT see the RowLevelSecurity and the WriteSecurity have a value of "1000002554". This is
because the CMDB assigns a ClassId of "BMC_PRINTER", which does NOT agree with MATCHAppliedToClassId value from
BMC.CORE.CONFIG:BMC_DefaultAccountPermissions.
scenario 2
========
1. Assume in your BMC.CORE.CONFIG:BMC_DefaultAccountPermissions Form, you have an entry with these values:
ASSIGNRowLevelSecurity: 1000002554
ASSIGNWriteSecurity: 1000002554
MATCHAccountID: East
MATCHAppliedToClassId: default
2. Create a new CI for BMC_Printer (a child of BMC_ComputerSystem) with an AccountID value of "East" and Click [SAVE].
Search for this CI and you should see both the RowLevelSecurity and the WriteSecurity have a value of "1000002554". This is
because MATCHAppliedToClassId is default, meaning only the AccountID will be compared with MATCHAccountID, ClassId
does not have to match.
It is important to note that scenario 2 only applies if it is the best match for a specific CI. Page 94 of the CMDB 2.1 Concepts and
Planning Guide displays a chart outlining the precedences for matching BMC.CORE.CONFIG:BMC_DefaultAccountPermission
entries. The 'Best' match will always be applied on submit if multiple matches are located.