Before we look at more detailed user configuration, it might be helpful to know that Zabbix supports three authentication methods. Navigate to Administration | Authentication to taka a look at authentication configuration:

As can be seen here, these are the three authentication methods:

The initial Zabbix installation does not contain many predefined users—let's look at the user list. Navigate to Administration | Users:

That's right; only two user accounts are defined: Admin and guest. We have been logged in as Admin all the time. On the other hand, the guest user is used for unauthenticated users. Before we logged in as Admin, we were guest. The user list shows some basic information about the users, such as which groups they belong to, whether they are logged in, when their last login was, and whether their account is enabled.

Let's create another user for ourselves. Click on the Create user button located in the upper-right corner. We'll look at all available options for a user account, while filling in the appropriate ones:

The final result should look as follows:

If it does, click on the Add button at the bottom.

Now, it would be nice to test this new user. It is suggested that you launch another browser for this test so that any changes are easy to observe. Let's call the browser where you have the administrative user logged in "Browser 1" and the other one "Browser 2." In Browser 2, open the Zabbix page and log in as monitoring_user, supplying whatever password you entered before. Instead of the dashboard, the Monitoring | Triggers page is opened.

Also, the page is notably different than before—the main menu entries Configuration and Administration are missing here. Despite the Host and Group dropdowns both being set to All, no issues are visible, and the dropdowns themselves don't contain any host or host group. Go to Monitoring | Overview. The Group dropdown is set to all, but the Details view claims that there's No data found. Why so?

By default, users don't have access to any systems. When our new user logs in, nothing is displayed in the monitoring section, because we did not grant any privileges, including read-only. We did assign this user to the Zabbix administrators group, but that group has no permissions set by default. Back in Browser 1, click on monitoring_user in the ALIAS column. One minor thing to notice: instead of a Password input field this time a button that says Change password is visible. If you ever have to reset a password for some user, clicking on this button will reveal the password input fields again, allowing a password update along with any other changes that might have been made:

But there's a tab we still haven't used: Permissions. Let's switch to it.

The first thing to notice is the User type dropdown. It offers three user types. We'll leave it at Zabbix User for this user:

For reference, these types have the following meanings:

The following is a section that looks very close to what we are looking for. There are Hosts and Host groups, split among READ-WRITE, READ-ONLY, and DENY permissions:

There's just one problem: there is no way to change these permissions.

A helpful message at the bottom of the page explains why. It says Permissions can be assigned for user groups only.

We conveniently skipped adding or configuring any groups and permissions, so now is a good time to fix that.

Instead of modifying the default user groups, we will add our own. Navigate to Administration | User groups, and take a look at the list of current user groups:

As can be seen, there are already a few predefined groups, giving you some idea of how users could be organized. That organization can be based on system categories, systems, management roles, physical locations, and so on. For example, you might have a group of administrators in headquarters and some in a branch location. Each group might not be interested in the UPS status in the other location, so you could group them as HQ admins and Branch admins. A user can belong to any number of groups, so you can create various schemes as real-world conditions require.

Let's create a new group for our user. Click on Create user group in the upper-right corner. Let's fill in the form and find out what each control does:

If your Zabbix installation uses LDAP for user authentication, setting Frontend access to Internal for a user group will make all users in that group authenticate against the internal Zabbix password storage. It is not a failover option—internal authentication will always be used. This is useful if you want to provide access to users that are not in the LDAP directory, or create emergency accounts that you can pull out of a safe when LDAP goes down. Such an approach will not work with HTTP authentication, as it happens before Zabbix gets to decide anything about the authentication backend.

With the main settings covered, let's switch to the Permissions tab:

Now that's more like it! We can finally see controls for various permission levels. There are three sections, labeled READ-WRITE, READ ONLY, and DENY. Each has buttons named Add and Delete selected, which seem to modify the respective permission. Our user had no permissions to see anything, so we will want to add some kind of permissions to the first two boxes. Click on Add below the READ-WRITE box. This opens a new window with some options.

It also provides us with another valuable bit of information. If you look at the window contents carefully, you'll notice something common for all of these entries: they are all h ost groups. We finally have got the essential information together—in Zabbix, permissions can be set for user groups on host groups only.

Mark the checkbox next to SNMP devices, and click on the Select button.

We can now see SNMP devices added to the READ-WRITE box. Next, click on Add below the READ ONLY box. A popup identical to the previous one will open. This time, mark the checkbox next to the Linux servers entry, and then click on Select.

Now, the READ ONLY box has Linux servers listed. The final form should look like this:

Let's look at the Calculated permissions section, just below the controls we used:

This view shows effective user rights. We can see what the exact access permissions will look like: which hosts will be allowed read and write access, which will have read only, and for which there will be no access at all. This looks about right, so click on the Add button at the bottom. The group will be successfully added, and we will be able to see it in the group list:

Let's get back to Browser 2. Navigate to Monitoring | Latest data. Click on Select next to the Host groups field. Great, both of the groups we selected when configuring the permissions are available. Mark the checkboxes next to them and click on Select. Then, click on Filter. Now, our new user can view data from all the hosts. But we also added write permissions to one group for this user, so what's up with the Configuration menu? Let's recall the user-creation process—wasn't there something about user types? Right, we were able to choose between three user types, and we chose Zabbix user, which, as discussed, was not allowed to access configuration.

To continue exploring user permissions, we'll create another, more powerful user. In Browser 1, go to Administration | Users, and click on the Create user button. Fill in these values:

Now, switch to the Permissions tab and select Zabbix Admin from the User type dropdown. This is will make quite a large difference, as we will soon see:

When done, click on the Add button.

Let's use Browser 2 now. In the upper-right corner, click the logout icon, and then log in as advanced_user. This user will land in the event history page, and this time, we can see the Configuration section. That's because we set the user type to Zabbix Admin. Let's check out what we have available there—open Configuration | Hosts:

How could there be no hosts available? We set this user as the Zabbix Admin type. We probably should look at the user list back in Browser 1:

Here, we can easily spot our mistake—we added advanced_user to the Zabbix administrators group, but we set permissions for the Our users group. We'll fix that now, but this time, we'll use the user properties form. Click on advanced_user in the ALIAS column, and in the resulting form, click on Add next to the Groups field. Mark the checkbox next to Our users, and then click on Select:

When done, click on Update. In Browser 2, simply refresh the host's Configuration tab—it should reveal two hosts, SNMP device and snmptraps, which advanced_user can configure.

Suddenly, we notice that we have granted configuration access to the snmptraps host this way, which we consider an important host that should not be messed with and that neither of our two users should have access to anyway. How can we easily restrict access to this host while still keeping it in the SNMP devices group?

In Browser 1, navigate to Configuration | Host groups and click on Create host group. Enter the following details:

When done, click on Add.

Open Administration | User groups, click on Our users in the NAME column, and switch to the Permissions tab. In the group details, click on the Add button below the DENY box. In the resulting window, mark the checkbox next to Important SNMP hosts, click on Select, and then click on the Update button.

Now is the time to look at Browser 2. It should still show the host configuration with two hosts. Refresh the list, and the snmptraps host will disappear. After our changes, advanced_user has configuration access only to the SNMP device host, and there will be no access to the monitoring of the snmptraps host at all, because we used deny. For monitoring_user, nothing has changed—there was no access to the SNMP devices group before.

The maintenance configuration that we looked at in this chapter follows the rules of host group permissions in its own way. Host group permissions impact the way Zabbix admins can configure maintenance entries: