Permission Sets

A permission set represents the permissions for users that access ERA Web Console. They define what the user can do or see in the Web Console. Native users have their own permissions while domain users have the permissions of their Mapped security group. Each permission set has its domain of application (static groups). Permissions which are selected in the icon_section Functionality section will apply over objects in the groups which are set in the icon_section Static Groups section for each user assigned by this permission set. Having access to certain Static Group automatically means access to every one of its subgroups. With proper setting of static groups it is possible to build separated branches for local admins (see the example).

A user can be assigned a permission set even without being able to see it. A permission set is also an object which is automatically stored in the home group of the user who created it. When a user account is created, the user is stored as object in the home group of the creating user. Usually the Administrator creates users, so they are stored in the group All.

Combining of permission sets

The final access user has to an object is the result of the combination of all permission sets assigned to the user. For example, a user has two permission sets, one for homegroup with full permissions and another one for a group with computers, only with permissions Read, Use for Computer & Groups. This user can run all tasks from homegroup on computers in the other group.

In general, a user can run objects from one static group over objects in another static group, if the user has permissions for certain object type in the certain group.

Access Group Filter

access_group

The Access Group filter button enables users to select a static group and filter viewed objects according to the group where they are contained.

admin_AR_permissions

 

validation-status-icon-warning IMPORTANT

Good practice for working with permissions:

Never give access to Server Settings to inexperienced users - only Administrator should have this access.

Consider restricting access to Client Tasks > Run Command - it is a very powerful task that could be abused.

Non-admin level users should not have permissions for Permission Sets, Native Users, Server Settings.

If  a more complicated model of permissions is needed, do not hesitate to create more permission sets and assign them accordingly.

 

Next to permissions to ERA functionality, there can be given Read, Use, Write access to User Groups.

light-bulbEXAMPLE: Duplication

For an object duplication the user needs to have Read permission on the original object and Write permission on his Home Group for this type of action.

John, whose home group is John’s Group, wants to duplicate Policy 1, which was originally created by Larry, therefore the policy is automatically contained in Larry's home group, Larry's Group. This is the recommended way of achieving it:

1.Create a new static group. Name it, for example, Shared policies.

2.Assign both John and Larry with Read permissions for Policies in the group Shared policies.

3.Larry moves Policy 1 to the Shared policies group.

4.Assign John with Write permissions for Policies in his home group.

5.John can now Duplicate the Policy 1 - duplicate will appear in his home group.

light-bulbEXAMPLE: Difference between Use and Write

If Administrator does not want to allow user John to modify policies in the Shared policies group, he would create a permission set with:

Functionality Policies: Read and Use permissions selected

Static Groups: Shared Policies

With these permissions assigned to John, John is able to run those policies but he can not edit them, create new, nor delete them. If an administrator were to add Write permission, John could create new, duplicate, edit and delete policies within the selected static group (Shared policies).