User groups allow to group users both for organizational purposes and for assigning permissions to data. Permissions to viewing and configuring data of host groups and template groups are assigned to user groups, not individual users.
It may often make sense to separate what information is available for one group of users and what - for another. This can be accomplished by grouping users and then assigning varied permissions to host and template groups.
A user can belong to any number of groups.
To configure a user group:
The User group tab contains general group attributes:
All mandatory input fields are marked with a red asterisk.
Parameter | Description |
---|---|
Group name | Unique group name. |
Users | To add users to the group start typing the name of an existing user. When the dropdown with matching user names appears, scroll down to select. Alternatively you may click the Select button to select users in a popup. |
Frontend access | How the users of the group are authenticated. System default - use default authentication method (set globally) Internal - use Zabbix internal authentication (even if LDAP authentication is used globally). Ignored if HTTP authentication is the global default. LDAP - use LDAP authentication (even if internal authentication is used globally). Ignored if HTTP authentication is the global default. Disabled - access to Zabbix frontend is forbidden for this group |
LDAP server | Select which LDAP server to use to authenticate the user. This field is enabled only if Frontend access is set to LDAP or System default. |
Multi-factor authentication | Select which multi-factor authentication method to use to authenticate the user: Default - use the method set as default in MFA configuration; this option is selected by default for new user groups if MFA is enabled; <Method name> - use selected method (for example, "Zabbix TOTP"); Disabled - MFA is disabled for this group; this option is selected by default for new user groups if MFA is disabled. Note that if a user belongs to multiple user groups with MFA enabled (or at least one group has MFA enabled), the following authentication rules apply: if any group uses the "Default" MFA method, it will authenticate the user; otherwise, the first method (ordered alphabetically) will be used for authentication. |
Enabled | Status of user group and group members. Checked - user group and users are enabled Unchecked - user group and users are disabled |
Debug mode | Mark this checkbox to activate debug mode for the users. |
The Template permissions tab allows specifying user group access to template group (and thereby template) data:
The Host permissions tab allows specifying user group access to host group (and thereby host) data:
Click on to choose the template/host groups (be it a parent or a nested group) and assign permissions to those. Start typing the group name (a dropdown of matching groups will appear) or click on Select for a popup window listing all groups to be opened.
Then use the option buttons to assign permissions to the chosen groups. Possible permissions are the following:
If the same template/host group is added in several rows with different permissions set, the strictest permission will be applied.
Note that a Super admin user can enforce nested groups to have the same level of permissions as the parent group; this can be done in the host/template group configuration form.
Template permissions and Host permissions tabs support the same set of parameters.
Current permissions to groups are displayed in the Permissions block, and those can be modified or removed.
If a user group has Read-write permissions to a host and Deny or no permissions to a template linked to this host, the users of such group will not be able to edit templated items on the host, and template name will be displayed as Inaccessible template.
The Problem tag filter tab allows setting tag-based permissions for user groups to see problems filtered by tag name and value:
Click on to choose the host groups. To select a host group to apply a tag filter for, click Select to get the complete list of existing host groups or start typing the name of a host group to get a dropdown of matching groups. Only host groups will be displayed, because problem tag filter cannot be applied to template groups.
Then it is possible to switch from All tags to Tag list in order to set particular tags and their values for filtering. Tag names without values can be added, but values without names cannot. Only the first three tags (with values, if any) are displayed in the Permissions block; if there are more, those can be seen by clicking or hovering over the icon.
Tag filter allows separating the access to host group from the possibility to see problems.
For example, if a database administrator needs to see only "MySQL" database problems, it is required to create a user group for database administrators first, then specify "target" tag name and "mysql" value.
If "target" tag name is specified and value field is left blank, the user group will see all problems with tag name "target" for the selected host group. If All tags is selected, the user group will see all problems for the specified host group.
Make sure tag name and tag value are correctly specified, otherwise, the user group will not see any problems.
Let's review an example when a user is a member of several user groups selected. Filtering in this case will use OR condition for tags.
User group A | User group B | Visible result for a user (member) of both groups | ||||
Tag filter | ||||||
Host group | Tag name | Tag value | Host group | Tag name | Tag value | |
Databases | target | mysql | Databases | target | oracle | target:mysql or target:oracle problems visible |
Databases | set to: All tags | Databases | target | oracle | All problems visible | |
Not configured in the Problem tag filter | Databases | target | oracle | target:oracle problems visible |
Adding a filter (for example, all tags in a certain host group "Databases") results in not being able to see the problems of other host groups.
A user may belong to any number of user groups. These groups may have different access permissions to hosts or templates.
Therefore, it is important to know what entities an unprivileged user will be able to access as a result. For example, let us consider how access to host X (in Hostgroup 1) will be affected in various situations for a user who is in user groups A and B.
“Read-write” permissions have precedence over “Read” permissions.