We can do all of the work in this chapter with any installed Zabbix setup. If you haven’t installed Zabbix yet, check out the previous chapter to learn how to do so. We will go through our Zabbix setup to get everything ready for our users to start logging in and using the Zabbix frontend.

To log in to the Zabbix frontend, we are going to need users. Right now, we are logged in with the default user, which is logical because we need a user to create users. This isn’t a safe setup though, because we don’t want to keep using zabbix as a password. So, we are going to learn how to create new users and group them accordingly.

It’s important to choose how you want to manage users in Zabbix before setting up user accounts. If you want to use something such as LDAP or SAML, it’s a smart idea to make the choice to use one of those authentication methods right away, so you won’t have any migration trouble.

Getting ready

Now that we know how the Zabbix UI is structured and how to navigate it, we can start doing some actual configuration. We’ll start out by creating some user groups to get familiar with the process and start using them. This way, our Zabbix setup gets not only more structured but also more secure.

To get started with this, we’ll need a Zabbix server like the one we used in the previous recipes and the knowledge we’ve acquired there to navigate to the correct frontend sections.

Looking at the following figure, we can see how our example company, Cloud Hoster, is set up. We will create the users seen in the diagram to create a structured and solid user setup:

Figure 2.1 – Cloud Hoster department diagram

So, Cloud Hoster has some departments that need access to the Zabbix frontend and others that don’t need it at all. Let’s say we want to give the following departments access to the Zabbix frontend:

• Networking: To configure and monitor their network devices
• Infrastructure: To configure and monitor their Linux servers
• Buying and Inventory: To look at inventory information and compare it with other internal tools

How to do it…

Let’s get started with creating these three groups in our Zabbix UI:

1. To do this, navigate to Users | User groups, which will show you the following page:

Figure 2.2 – The Zabbix User groups window

2. Now, let’s start by creating the Networking group by clicking Create user group in the top-right corner. This will bring you to the following screen:

Figure 2.3 – The Zabbix User groups configuration window

We will need to fill in the information, starting with Group name, which will of course be Networking. There are no users for this group yet, so we’ll skip that one. Frontend access gives us the option to provide authentication; if you select LDAP here, LDAP authentication will be used for authenticating. We will keep it as System default, which uses the internal Zabbix authentication system.

Multi-factor authentication

New to Zabbix 7.0 is the ability to use multi-factor authentication. If we want users to be forced to use this, we can set that up in the user group here. Before doing that, however, make sure to set up multi-factor authentication under Users | Authentication.

3. Now, let’s navigate to the next tab on this page, which is Template permissions:

Figure 2.4 – The Zabbix User groups Template permissions configuration window

Here, we can specify what host groups our group will have access to. There’s a default host group for Network devices already, which we will use in this example.

4. Click Select to take you to a pop-up window with host groups available. Select Templates/Network devices here and it’ll take you back to the previous window, with the group filled in.
5. Select Read-write permissions.
6. We won’t be adding anything else, so click the big blue Add button to finish creating this host group.

Tip

When using Zabbix authentication such as HTTP, LDAP, or SAML, we still need to create our users internally with the right permissions if we do not use JIT user provisioning. To do so, configure your users to match your authentication method’s username in Zabbix and use the authentication method for password management. When using JIT user provisioning, this is not something we have to worry about.

Now we will have a new user group called Networking that is only allowed to read and write to the Templates/Network devices template group:

Figure 2.5 – The Zabbix User groups window

7. Let’s repeat this process to create a new Infrastructure user group, except instead of adding the Templates/Network devices template group, we’ll add the Linux servers host group, like this:

Figure 2.6 – The Zabbix User groups Permissions configuration window with one host group

8. Click Add to save this host group.
9. Repeat the steps again and to add Buying and Inventory user group, we’ll do something differently. We’ll repeat the process we’ve just done except for the part with the permissions. We want Buying and Inventory to be able to read our inventory data, but we don’t want them to actually change our host configuration. Add both the Templates/Network devices template group and Linux servers host group to the user group, but with only Read permissions like this:

Figure 2.7 – The Zabbix User groups Permissions configuration window with two groups

Congratulations! Finishing this means you’ve ended up with three different user groups and we can continue to create our first new users! Let’s get to it.

There’s more...

Zabbix user groups are quite extensive and there is a lot more to it than there seems at first. As the entire permission system is based on what user group(s) and user role you are part of, it is always a good idea to read the Zabbix documentation first: https://www.zabbix.com/documentation/current/en/manual/config/users_and_usergroups/usergroup.

Since Zabbix 6.0, we can create user roles within our Zabbix system. By creating our own user roles in Zabbix, it’s possible to provide additional permission settings. In older Zabbix versions, we had the ability to assign one of three user types:

• Users
• Admin
• Super admin

What these user types did in earlier releases was restrict what Zabbix users could see in the frontend. This was always pre-defined though.

Although these user groups are still in Zabbix, with the addition of user roles that we can create ourselves, we can set up our own frontend-related restrictions, making it possible to only show certain parts of the UI to certain Zabbix users. This is done by limiting access to certain permissions a user group has by default as well as respecting the user group-related permissions.

Getting ready

For this recipe, we will need a Zabbix server, preferably the one set up in the previous recipe. In the previous recipe, we set up different user groups to provide for different permissions on host groups. Completely separate from the user group, we will apply certain user roles to our users to determine what they can see in the UI. Let’s check out how to set up our user roles.

How to do it...

1. First, navigate to the Zabbix frontend and go to Users | User roles. This will show us the default user roles as you know them from older Zabbix versions:

Figure 2.8 – The default Zabbix User roles configuration window

2. Here, we can click on the blue Create user role button in the top-right corner.
3. We’ll set up a new user role called User+ role. This role will be for Zabbix users with only read permissions, but who need more access than just the Monitoring, Inventory, and Reports navigational elements.

Figure 2.9 – The top part of a new Zabbix User role configuration window

4. First things first, make sure to enter User+ role into the Name field.
5. Let’s focus on the part where it states Access to UI elements first. When User is selected for User type, we are not able to add access rights to the user role. So, let’s change the User type by selecting Admin in the dropdown.
6. I specifically want this user role named User+ role to have the ability to access the maintenance page. Setting this up will look like this:

Figure 2.10 – A new Zabbix User+ role with access to Maintenance

7. Make sure to also change the Access to actions section of the form by deselecting Manage scheduled reports as follows:

Figure 2.11 – A new Zabbix User+ role with correct Access to actions settings

8. Last, but not least, click on the blue Add button at the bottom of the form to add this new user role.

How it works...

First, let’s break down the options we have when creating user roles in Zabbix:

• Name: We can set a custom name for our user role here.
• User type: User types still exist in Zabbix 6, although they are now assigned through user roles. There’s still a limit to what can be seen by a certain user type, for example the User type will never have more than read access and the Super admin type is still unrestricted when it comes to permissions.
• Access to UI elements: Here, we can restrict what a user can see on the Zabbix UI when they are assigned to this user role.
• Access to services: Service or SLA monitoring can be restricted here, as we might not want all users to have access to it.
• Access to modules: Custom Zabbix frontend modules are fully integrated into the user role system, meaning we can select what frontend modules a Zabbix user can see.
• Access to API: The Zabbix API can be restricted to certain user roles. For example, you might only want a specific API user role, limiting the rest of the users’ access to the Zabbix API.
• Access to actions: In Zabbix user roles, certain actions can be limited, including the ability to edit dashboards, maintenance API tokens, and more.

Now, let’s look at what we’ve changed between the user role called User role and the user role called User+ role. The default user role called User role has the following access to UI elements:

Figure 2.12 – Default Zabbix user role called User role Access to UI elements

By default, we have three user roles in Zabbix 6, which mirror the available user types. The user role we see here in Name mirrors the user type we have called User. It gives us access to the UI elements seen above, restricting the user role called User role to only be able to see certain things and make no configuration changes.

For example, it’s considered an impactful permission to be able to set Maintenance. Because of course, you could restrict important notifications by setting Maintenance. But here comes the catch, what if you explicitly want a Zabbix user to only be able to read information but still not have access to configuration pages? In Zabbix 5.0, this wasn’t possible because you could only select the User, Admin, or Super admin types, immediately giving access to the entire configuration section when using the Admin and Super admin user types.

Now, let’s see what we did by creating a new user role called User+ role:

Figure 2.13 – New Zabbix user role called User+ role Access to UI elements

Here, we can see what happens if we change the user type to Admin but do not select all the available Access to UI elements. We now have a user role with no access to important configuration pages but with access to Maintenance.

Combining that with the settings for Access to actions, where we added the Create and edit maintenance setting as seen in Figure 2.11, we would have full access to the maintenance settings.

When we assign this role to a user in the next recipe and log in as that user, we will be able to see the following in our Zabbix sidebar:

Figure 2.14 – Custom User role Zabbix sidebar

This, of course, is just one of the many types of configurations we can use. We also have the ability to allow Zabbix users access to menus and options through a number of parameters under a bunch of custom user roles. We are free to set this up however we please, adding a lot of user flexibility within Zabbix.

There’s more...

Zabbix is currently in the process of working out user roles further, meaning that some parts might still be missing or you might see issues with them. As it is a new feature, it is constantly being improved and extended. Check out the Zabbix documentation for more information regarding this feature: https://www.zabbix.com/documentation/6.4/en/manual/web_interface/frontend_sections/users/user_roles

With our newly created user groups and user roles, we’ve taken our first step toward a more structured and secure Zabbix setup. The next step is to actually assign some users to the newly created user groups to make sure they are assigned our new user permissions from the group, as well as making them part of a user role to provide the correct access to UI elements.

Getting ready

To get started, we’ll need the server and the newly created user groups from the last recipe. So, let’s start with the configuration.

We know there are three departments in the Cloud Hoster company that are going to use our Zabbix installation. We’ve created user groups for them, but there are also users in those departments that actually want to use our installation. Let’s meet them:

Figure 2.15 – Cloud Hoster users diagram

These are the users we need to configure for Cloud Hoster to use.

How to do it…

Let’s start creating the users. We will start with our Networking department:

1. Navigate to Users | Users, which will bring us to this page:

Figure 2.16 – The Zabbix Users window

2. This is where all the user creation magic is happening, as we will be managing all of our users from this page. To create our first Networking department user named s_network, click the Create user button in the top-right corner, bringing us to the following screen:

Figure 2.17 – The Zabbix Users configuration window

3. Fill out the Username field to provide us with the username this user will have, which will be s_network.
4. Also, it’s important to add this user to the group we have just created to give our user the right permissions. Click Select and pick our group called Networking.
5. Last but not least, set a secure password in the Password fields; don’t forget it because we will be using it later.
6. After this, move on to the Permissions tab as we won’t be configuring Media just yet:

Figure 2.18 – The Zabbix user Permissions configuration window

7. Select the Role option named Super admin role here. This will enable our user to access all UI elements and see and edit information about all host groups in the Zabbix server.

   The following user roles are available in Zabbix by default:

   Default roles	Description
   User role	The Zabbix User role has access to the visualization aspects of our Zabbix environment. Specifically, the Monitoring, Services, and Inventory and Reporting menus are available. The user will only ever have READ access to templates and hosts and they must be explicitly assigned.
   Admin role	The Zabbix Admin role can additionally manage the configuration of our Zabbix monitoring. Specifically, all the menus that the Zabbix User has access to are available, with the addition of Data collection and Alerts. The user can be assigned READ-WRITE access to templates and hosts and they must be explicitly assigned.
   Super admin role	The Zabbix Super admin role has access to the administrative aspects of our Zabbix environment. Specifically, all the menus that the Zabbix Admin has access to are available, with the addition of Users and Administration. The user will always have READ-WRITE access to all templates and hosts.

8. Let’s repeat the previous steps for the user named y_network, but in the Permissions tab, select the Admin role option as follows:

Figure 2.19 – The Zabbix user Permissions configuration window

After creating these two users, let’s move on to create the infrastructure user, r_ infra. Repeat the steps we took for s_network, changing the Username, of course. Then, add this user to the group and give our user the right permissions. Click Select and pick our group called Infrastructure. It will look as follows:

Figure 2.20 – The Zabbix user configuration window for r_infra

Lastly, make this user another Super admin on the Permissions page.

9. Now, for our last user, let’s repeat our steps, changing the Username and the group in the User tab as follows:

Figure 2.21 – The Zabbix User configuration window for e_buy

10. If you didn’t follow the previous recipe, you can change this user’s Role to User role at the Permissions tab. But if you did follow the previous recipe, we can use the User+ role we created as follows:

Figure 2.22 – The Zabbix user configuration window for e_buy

Setting the user up with the User+ role will also let the e_buy user create maintenance periods.

When you’re done, you’ll end up with the following:

• s_network: A user with access to the Networking user group permissions with the Super admin role
• y_network: A user with access to the Networking user group permissions with the Admin role
• r_infra: A user with access to the Infrastructure user group permissions with the Super admin role
• e_buy: A user with access to the Buying and Inventory user group permissions with either the User role or the User+ role

In this recipe, we will use Security Assertion Markup Language (SAML) authentication, a widely used form of authentication in the IT world. The SAML standard allows us to exchange authorization data between applications, so we can authenticate between our Zabbix application and an authentication provider. We’ll be using this as a form of managing passwords for our Zabbix users. Please note that if you only set up user authentication with passwords with SAML or LDAP, you still have to create users with their permissions manually within Zabbix. To circumvent this, we can also set up Just In Time (JIT) user provisioning since Zabbix 6.4.

Getting ready

To get started with SAML authentication, we will need our configured Zabbix server from the previous recipe. It’s important that we have all the configured users from the previous recipe. We will also need something to authenticate with SAML. We will be using Microsoft Azure Active Directory (AD) SAML.

Make sure to set up users in your Azure AD before continuing with this recipe. You can use your existing AD users for authentication, so you can use this recipe with your existing AD setup.

We will be using the s_network user as an example as well as a new JIT_Admin user group in our Zabbix environment with no permissions set up. The Azure user looks as follows:

Figure 2.23 – The Azure Users and groups window

For JIT user provisioning, we also made sure to make this user part of a new zbx_admin group:

Figure 2.24 – The Azure users group details window

This group is just going to be an empty security group that we will use to assign permissions in Zabbix later:

Figure 2.25 – The Azure group details window

To set up SAML, retrieve your SAML settings from your AD or another SAML provider. To work with Zabbix, we will need the following:

• IdP entity ID
• SSO service URL
• SLO service URL
• Username attribute
• SP entity ID
• SP name ID format

For the JIT user provisioning, we will need the following:

• Group name attribute
• User name attribute
• User last name attribute
• User group mapping

How to do it…

We start with the assumption that you have your Azure AD ready. Let’s see how we can configure SAML using our setup:

1. Let’s navigate to the following URL: https://portal.azure.com/.
2. After logging in, navigate to Azure AD and click on Enterprise Applications.
3. Now click on + New Application to create our new application. At the next window, click on Create your own application:

Figure 2.26 – The Azure enterprise application creation page

4. In the next window, name our new application Zabbix and click on the blue Create button:

Figure 2.27 – The Azure enterprise new application page

5. Select our new application from the list and click on Users and Groups to add the correct users. In our case, this will be s_network:

Figure 2.28 – The Azure enterprise application User addition

6. If we are setting up JIT user provisioning, make sure to also add the zbx_admin group:

Figure 2.29 – The Azure enterprise application Group addition

With JIT user provisioning, adding the group should be enough.

7. You will also have to assign a role. Click on Select a role and add the role you want to use. When using JIT you can use the zbx_admin group, otherwise just add the user as User.

Figure 2.30 – Azure enterprise application role assignment

8. Click on Select and then Assign.
9. Now let’s move on to the SAML settings by clicking on Single sign-on in the sidebar.
10. Now click on SAML on the page shown in the following screenshot and continue:

Figure 2.31 – The Azure enterprise application SAML option

11. Now at 1, we can add the following information, where the black marks are our Zabbix server URL:

Figure 2.32 – The Azure SAML setting 1

12. At 2, fill out the following:

Figure 2.33 – The Azure SAML setting 2

13. 3 will be automatically filled. Click on Download for Certificate (Base64):

Figure 2.34 – The Azure SAML setting 3

14. Log in to the Zabbix server CLI and create a new file with the following command:

    vim /usr/share/zabbix/conf/certs/idp.cert

15. Paste the contents from the file downloaded in step 11 here and save the file.
16. Now back at Azure for 4, we will get the following information:

Figure 2.35 – The Azure SAML setting 4

17. At the Zabbix frontend, go to the Users | Authentication | SAML settings page and fill in the following information:

Figure 2.36 – The Zabbix SAML settings

18. If you also want to use JIT user provisioning, enable it as seen in the previous screenshot as well as fill in the following information:

Figure 2.37 – The Zabbix SAML JIT settings

Important note

I have used the JIT_Admin user group as suggested in the Getting ready part of this recipe. Please use any user group and roles you see fit and make sure to integrate the JIT user provisioning into your own groups and permissions.

19. If you have already created the s_network user and you aren’t going to use JIT user provisioning, go to Users | Users and change the s_network user to include the used Azure domain, for example:

Figure 2.38 – The Zabbix edit user screen for our SAML setup

If you are using JIT user provisioning, you can simply log in with the new user credentials using SAML authentication and it should create the user with the correct credentials.

20. After following these steps, it should now be possible to log in with your user configured in Zabbix and use the password set in Azure AD for this:

Figure 2.39 – The Zabbix login window

How it works…

Zabbix SAML user authentication is by default used to centralize password management. In the past, we were not able to actually assign user groups and permissions to users via this setup. If we set it up without JIT user provisioning we can use it for simple password management.

This way, we can make sure it is easier for users to keep their passwords centralized:

Figure 2.40 – Zabbix SAML authentication diagram

Zabbix communicates with our Azure AD SAML component when we click the Sign in button. The user is then authenticated against your Azure AD user and a confirmation is sent back to the Zabbix server. Congratulations, you are now logged in to your Zabbix server.

However, since Zabbix 6.4 it is also possible to enable JIT user provisioning. This new feature allows us to also assign Zabbix User groups and roles according to user groups on our SAML server. As such, the whole process with JIT user provisioning included looks something like this:

Figure 2.41 – Zabbix SAML JIT authentication diagram

There’s more…

We can do this kind of authentication not only with SAML but also with HTTP and LDAP. This way, you can choose the right form of advanced authentication for your organization.

Check out the Zabbix documentation for more information on the different forms of authentication: https://www.zabbix.com/documentation/current/en/manual/web_interface/frontend_sections/users/authentication

It’s also possible to work with an identity provider such as Okta or OneLogin, among others. This means your options aren’t limited to Azure AD: as long as it supports SAML, you can use it to authenticate against your Zabbix server.

Although a lot of people use SAML in combination with Azure Active Directory, that isn’t always the case. There are loads of different methods of running your user authentication.

One of those methods is using LDAP instead of SAML with, for example, an OpenLDAP server. OpenLDAP provides us with a solid open source implementation to set up a user database with LDAP. The great thing about this is that JIT user provisioning doesn’t just work with SAML, but also with LDAP, meaning we can apply JIT user provisioning here as well.

Getting ready

To get things going, we are going to need an OpenLDAP server set up and ready to go. It is recommended to use your own OpenLDAP environment. There are loads of guides available online to do a solid OpenLDAP implementation as well as a quick start guide for the latest version on the official website: https://www.openldap.org/

Another way to go is spin up a test OpenLDAP environment with Docker. We can use the following command:

docker run -p 389:389 -p 636:636 --name openldap-server --detach oicts/openldap:1.0.0
docker run -p 8081:80 -p 4443:443 --name phpldapadmin --hostname phpldapadmin --link openldap-server:ldap-host --env PHPLDAPADMIN_LDAP_HOSTS=ldap-host --detach osixia/phpldapadmin:0.9.0

Please use this for testing only, since the preceding code might not be using the latest versions anymore.

How to do it…

Once OpenLDAP is set up, we can start to create some users and groups in our new OpenLDAP environment. Let’s get started on that first:

1. We will open the OpenLDAP GUI by navigating to the URL in our browser:

   https://<ip_address_of_server>:4443

2. After logging in, let’s create some new users. First, click on Login on the left-hand side of the window. The default username and password are as follows:

   Login DN: cn=admin,dc=example,dc=org
   Password: admin

3. You should see that we have already created some groups and users for you if you are using our Docker images, as you can see in the following screenshot:

Figure 2.42 – OpenLDAP server groups and users

If you are using your own OpenLDAP environment, make sure to have at least one group and one user for testing.

4. Let’s use these usernames and groups to set up LDAP authentication with JIT user provisioning.
5. Move on to the Zabbix frontend and navigate to Users | Users. First, we’ll give ourselves access at any time even if the default authentication method will be switched to LDAP. Switch the Admin user’s default authentication method to internal by adding them to the Internal group.

Figure 2.43 – Zabbix Admin user settings

6. Click on Update and it should then look like the following screenshot.

Figure 2.44 – Zabbix Admin user with Internal Frontend access

7. Then we will go to Users | Authentication and then LDAP settings. Set up the default authentication method to LDAP and the deprovisioned users group as follows.

Figure 2.45 – Zabbix Default authentication method

8. Next, we’ll click on the LDAP settings tab. This is where we can configure our LDAP server and JIT user provisioning. Let’s start by enabling the ones we would like to use.

Figure 2.46 – Zabbix Default authentication method

When using just LDAP, we will have to create our users manually. By enabling JIT, users will be created and granted the correct permissions automatically.

9. It’s also possible to add multiple LDAP servers in Zabbix now. Let’s add our OpenLDAP server by clicking on Add at Servers.
10. Then, fill in the following.

Figure 2.47 – Zabbix LDAP authentication setup

The default Bind password value is password.

11. If we want, we can also enable JIT provisioning. Enable it and fill in the following.

Figure 2.48 – Zabbix LDAP authentication setup with JIT

12. Now, sign out of the currently logged-in account by clicking the Sign out button in the lower left corner of the sidebar.
13. We should now be able to log in with the user1 LDAP user. The password is password.

Figure 2.49 – Zabbix login window for user1

14. When we log in for the first time, the user will be created with the correct permissions as defined in the JIT user provisioning step. If logged in as a Zabbix super admin, we can see this under Users | Users.

Figure 2.50 – Zabbix LDAP provisioned user

How it works…

As you can see, we can use Zabbix in combination with an LDAP server to make password management easier as a whole. There are two options for us to choose from: using LDAP with or without JIT user provisioning.

When we use Zabbix in combination with an LDAP server, but choose to not use JIT user provisioning, Zabbix will communicate with the LDAP server just to do the password authentication upon pressing the Sign in button.

Figure 2.51 – Zabbix LDAP authentication diagram

However, since Zabbix 6.4 it is also possible to enable JIT user provisioning. This new feature allows us to also assign Zabbix user groups and roles in line with the user groups on our LDAP server. As such, the whole process with JIT user provisioning included looks something like the following:

Figure 2.52 – Zabbix LDAP JIT authentication diagram