Permission Sets
A permission set represents the permissions for users that access ESET PROTECT Web Console. They define what the user can do or see in the Web Console. Each permission set has its domain of application (static groups). Permissions which are selected in the Functionality section will apply over objects in the groups which are set in the 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 you can build separated branches for local administrators (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.
Permission sets are additive. If you assign more permission sets to a single user, the sum of all permission sets is the resulting access that the user has.
Combining of more 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.
The Access Group filter button allows users to select a static group and filter viewed objects according to the group where they are contained.
You can use tags for filtering the displayed items.
|
Good practice for working with permissions: •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 and Mapped accounts. •If a more complex model of permissions is needed, do not hesitate to create more permission sets and assign them accordingly. |
|
The Audit log permissions enables the user to view logged actions of all other users and domains, even those related to assets the user does not have sufficient rights to view. |
After setting permissions to ESET PROTECT functionality, you can also assign Read, Use, Write access to User Groups.
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. 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. |
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 cannot edit them, create new, nor delete them. If an administrator were to add Write permission, John could create new, edit and delete policies within the selected static group (Shared policies). |