Users, user groups, and permissions

Hosts manage monitored entity (host) information and are used to group basic information-gathering units—items. User accounts in Zabbix control access to monitored information.

Authentication methods

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:

• 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.
• 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.
• Internal: With this method, users are authenticated using Zabbix's internal store of users and passwords. We will use this method.

Creating a user

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.

Tip

By granting access permissions to the guest user, it is possible to allow anonymous access to resources.

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:

• Alias: Enter monitoring_user. This is essentially a username.
• Name: Enter monitoring. In this field, you would normally enter the user's real name.
• Surname: Enter user. Obviously, this field normally contains the user's real surname.
• Groups: Just like hosts, user accounts can be grouped. A user must belong to at least one group, so let's assign our new user to some group at least temporarily. Click on the Add button next to the Groups field, and mark the checkbox next to Zabbix administrators. Then, click on Select:
  
• Password: Choose and enter a password, and then retype it in the next field.
• Language: The frontend has translations in various levels of maturity, and each user can choose their own preference. We'll leave this at English (en_GB):
  

  Tip

  If a language you would like to use is not listed, it might still be there—just incomplete. See Appendix B, Being Part of the Community, for more details on how to enable it and contribute to Zabbix translations.

• Theme: The Zabbix frontend supports theming. Currently, there are only two themes included, though. We'll leave the theme to be System default (which is Blue):
  
• Auto-login: Marking this option will automatically log the user in after they have logged in at least once manually. Automatic login is performed with browser cookies. We won't be using automatic login for this user.
• Auto-logout: You can make a particular account automatically log out after a specific time of inactivity. The minimum time period that can be set is 90 seconds, and the maximum is about 166 minutes. There is no need to set automatic logout here.

  Tip

  What's more, at the time of writing this, this option does not work as expected and should not be relied on.

• Refresh: This is the time in seconds between page refreshes when in the Monitoring section. While smaller values might be nice to look at when first setting up and having items with short check intervals, they somewhat increase the load on the server, and if the page contains a lot of information, then it might sometimes not even finish loading before the next refresh kicks in. Let's set this to 60 for this user—after all, they can always refresh manually when testing something. Note that some pages do not perform a full page refresh; instead, they just reload some elements on that page. A graph page, for example, only reloads the graph image.
• Rows per page: Each user can have an individual maximum rows-per-page setting. If the returned data exceeds this parameter, the interface splits the data into multiple pages. We won't change this parameter.
• URL (after login): A user might wish to always see a specific page after logging in—be it the overview, trigger list, or any other page. This option allows the user to customize that. The URL entered is relative to the Zabbix directory, so let's make this user always see Monitoring | Triggers when they log in, by entering tr_status.php here.

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.

Tip

There's also a Media tab. There, users can have various media assigned so that Zabbix knows how to alert them. Media types include e-mail addresses or numbers to send SMS messages to. We will discuss notification functionality in Chapter 7, Acting upon Monitored Conditions.

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:

• Zabbix User: These are normal users that only have access to the Monitoring, Inventory, and Reports sections in the Main menu
• Zabbix Admin: These users, in addition to the previous three sections, have access to the Configuration section, so they are able to reconfigure parts of Zabbix
• Zabbix Super Admin: These users have full access to Zabbix, including the Monitoring, Configuration, and Administration sections

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.

Creating user groups

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:

• Group name: Enter Our users.
• Users: Here, we can add users to the group we are creating. Our current installation has very few users, so finding the correct username with all users displayed is easy. If we had many users, we could use the Other groups dropdown to filter the user list and more easily find what we are looking for. Select monitoring_user and click on the button.
• Frontend access: This option allows us to choose the authentication method for a specific group. It allows a configuration where most users are authenticated against LDAP, but some users are authenticated against the internal user database. It also allows us to set no GUI access for some groups, which can then be used for users that only need to receive notifications. We'll leave this option at System default.

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.

• Enabled: With a single option, all the users in this group can be disabled or enabled. As the predefined groups might tell you, this is a nice way to easily disable individual user accounts by simply adding them to a group that has this checkbox unmarked. We want our user to be able to log in, so this option will stay marked.
• Debug mode: This option gives users access to frontend debug information. It is mostly useful for Zabbix developers. We will discuss debug mode in Appendix A, Troubleshooting.

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.

Note

It is important to keep in mind that, at this time, a Zabbix user that has write access granted will not be able to configure things in the frontend, but they will get write access through the API. This could cause security issues. We will discuss the API in Chapter 21, Working Closely with Data.

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:

• Alias: Enter advanced_user.
• Name: Enter advanced.
• Surname: Enter user.
• Groups: Click on Add, mark the checkbox next to Zabbix administrators, and click on Select.
• Password: Enter a password in both fields. You can use the same password as for monitoring_user to make it easier to remember.
• Refresh: Enter 60.
• URL (after login): Let's have this user view a different page right after logging in. Event history might do—enter events.php here.

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:

• Group name: Enter Important SNMP hosts
• Hosts: Filter the Other hosts listbox with the Group dropdown to display SNMP devices, select snmptraps, and then click on the button

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.

Permissions and maintenance

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:

• Zabbix admins may create new maintenance entries and include host groups and hosts they have write permissions on
• Zabbix admins may edit existing maintenance entries if they have write permissions on all the hosts and host groups included in those maintenance entries