search cancel

When a security role is cloned, users on that cloned security role cannot assign the targets that already existed on the console

book

Article ID: 215649

calendar_today

Updated On:

Products

IT Management Suite

Issue/Introduction

Scenario:


The customer cloned the Symantec Administrator Role. When they cloned this role, they also checked the box for "Update targets".

This cloned security role still have at least Read access to almost everything as the previous Security Role.

When a User that belongs to this cloned Security Role goes to Manage>Computers and checks the available targets, they can see all the targets that the original Security Role had access to.

However, every target has a "lock" icon on them.  

The customer made sure that this cloned Security Role is part of the "Scoping" for each of those desired targets. The process of cloning the security role when the "Update targets" option is selected, automatically added this cloned Security Role into the scoping.

If he tries to modify a target where they have scoping access, the options are grayed out.

When they want to assign a target to a policy, they can't. The option to move them appears grayed out.

 

If they clone any of those targets with a lock icon, they can add them to policies and edit them just fine.


Issue:

Any previously created Targets will not have the proper rights as this cloned Security Role should have since the original security role had access to them.

When logged in as a member of this cloned Security Role, every previously created target is "locked" for use, even when this cloned Security Role is part of Scoping.

Any new target created by a User on this cloned Security Role works for adding them to policies or editing. 

Environment

ITMS 8.5, 8.6

Cause

This behavior is by design. Here is why (the case, when User has partial target scope, i.e. he now belongs to only 1 role out of the 2 roles, that target have scoped to):

Targets only can be modified by users that have full scoping coverage, i.e. users should belong to ALL scopes that target have.

  • This is why there is a "lock" on the icon and the target is not modifiable.
  • Also, a user can NOT assign targets with a broader scope set to his own policies, as the target will include machines, that the User should not see and apply some devastating actions by them.

Resolution

The use of "foreign" targets are "as is" at the moment. 
The only way seems to be cloning the target.

Also, accessing "wider scope" targets is not possible for users, as they can deploy some activities for machines they are not intended to have access to.

Attachments