HTTP: Users are authenticated with web server HTTP authentication mechanisms. Support for HTTP authentication basically allows the use of any of the authentication methods for Zabbix that the web server supports, and in the case of the Apache HTTPD daemon, there are many. If you like to use HTTP authentication, then click the HTTP settings tab and fill in the necessary information.

LDAP: Users are authenticated using an LDAP server. This can be handy if all enterprise users that need access to Zabbix are already defined in an LDAP structure. Only user passwords are verified; group membership and other properties are not used. A Zabbix user account must also exist for the login to be successful. If you would like to use the LDAP authentication, then you will need to fill in the settings in the LDAP tab and select LDAP from the Authentication page instead of internal.

Internal: With this method, users are authenticated using Zabbix's internal store of users and passwords. We will be using this method.

• User
• User Group
• User Type
• User Role

When granting access to Zabbix frontend, you can do so by creating a dedicated user account (please don’t share accounts). During the creation process, you will be asked to provide an alias (login), password and other stuff. Apart from that, you will need to specify at least one user group this user will belong to.

As you might expect, a user group is a container holding zero or more users. This element is important because it’s used for assigning permissions to host groups. Apart from this, you can set other access policies for a user group, such as authentication backend or whether it has access to the debug mode.

Up until Zabbix 5.0 there were only three types of users: Zabbix user, Zabbix Admin and Zabbix Super Admin. The most notable difference between them is that each user type has access to different sections of the frontend. Please refer to the bellow table for details.

Since Zabbix 5.2 there is yet another thing to consider and that thing is called user roles. The idea behind them is fairly simple: what if we took a user type and removed access to selected parts of the frontend?

Each user role is based on a user type, then during configuration you limit access to given areas of the frontend, ability to execute actions or make API calls. As you can see each new user role can have at most the same privileges that the user type it’s based on

When assigning permissions to a host group there are four access levels to chose from:

• Read-Write
• Read
• Deny
• None

Read-Write and Read do exactly what they advertise. The first one allows for viewing and modification of host group members, the other one allows for viewing only.

In case you’re wondering: without Read access you cannot see related problems, latest data or inventories.

Deny will, well, deny access to a host group. It is especially useful when dealing with nested host groups — you might want do give access to a group with all its subgroups except for one. Then you would set the desired access level to that host group (including subgroups) but set Deny for that specific one. It also plays a significant role when user is a member of multiple groups.

Setting access to None removes the host group from the list. You can treat this as ‘reset to defaults’.

Zabbix

Session-7-Zabbix-Notifications