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.  Select monitoring_user and click on the button or just type the name in the box and select the correct user. 
• Frontend access: This option allows us to choose the authentication method for a specific group. It allows for 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 as 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 or Zabbix administrators. 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, Deny, and None.  Our user had no permissions to see anything, so we will want to add some kind of permissions. Click on Select left of the Read-write box. This opens a new window with host groups.

It also provides us with another valuable bit of information. have finally got the essential information together—in Zabbix, permissions can be set for user groups on host groups only.

Mark the checkbox next to Linux servers/SNMP group and click on the Select button.

We can now see that SNMP devices has been added to the Read-write box. Next, click on the Read box. This time, mark the checkbox next to the Linux servers entry, and then click on Add. You will see that Zabbix also adds the Linux servers/Test group but with permissions set to None.  This is because, when we created our Linux servers host group, we had the option to select Apply permissions and tag filters to all subgroups, but we left that box unmarked. If we had marked that option, then all the subgroups from the Linux servers group would have inherited the permissions from the Linux servers group.

The final form should look like this:

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 check-boxes next to them and click on Select. Then, click on Apply. 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 we 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:

• Alias: Enter advanced_user.
• Name: Enter advanced.
• Surname: Enter user.
• Groups: Click on Select, 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 60s.
• URL (after login): Let's have this user view a different page right after logging in. The overview page might do—enter overview.php here.

Now, switch to the Permissions tab and select Zabbix Admin from the User type drop-down. This is will make quite a big 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 on the overview 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 and select all from the Group selection box:

How could there be no hosts available? We set this user as the Zabbix Admin type. should probably 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 Select 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 our 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 Linux servers/Important SNMP hosts
• Configuration | Hosts: Go to host snmptraps and in the Group box, select Linux servers/Important SNMP Hosts

When done, click on Update.

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  Deny box. Click select and select Linux servers/Important SNMP Hosts, 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.