Skip to main content
Zabbix is an open-source monitoring platform for servers, networks, and applications. Connect your Zabbix server to Oleria to see every Zabbix user with their MFA and SSO status, the user groups and roles they hold, which host groups and template groups each user group can read or change, and the API tokens that can act on the server. Oleria connects to Zabbix 7.0 or later, self-hosted or on Zabbix Cloud, with a Zabbix API token. Oleria reads access to host groups, template groups, and the hosts in them. It doesn’t model templates, items, triggers, or other monitoring configuration. Changes to them appear in the audit log activity.

​
What Oleria discovers

Once connected, Oleria continuously discovers and maps the following from your Zabbix server:
  • Accounts - every Zabbix user, whether they sign in with an internal password, LDAP, or SAML. Each account shows the user’s name, email address, status, role, and whether they’re an administrator (a role of user type Admin or Super admin). It also shows whether their role allows API access, their MFA requirement and method (TOTP or Duo Universal Prompt), their SSO status, and their sign-in method. A user is disabled when any of their user groups disables its members. The built-in guest user appears as an anonymous user, with MFA and SSO shown as not applicable. Oleria takes each user’s creation date, creator, last sign-in, and last password change from the audit log.
  • Non-human identities - API tokens, shown as personal access tokens linked to the user each token belongs to and acts as. Each token shows its creator, creation date, expiry, last-used date, and when its secret was last generated. Each one is paired with a credential that shows whether the token is active, disabled, or expired, and when it was last rotated.
  • Groups - user groups and their members. Built-in groups, such as Disabled and Zabbix administrators, are marked as built-in. Groups that require MFA are marked when MFA is turned on for the server.
  • Roles - user roles and the users who hold each one. Zabbix gives every user exactly one role. Each role shows its user type and a summary of its UI, API, and action access. The four installer roles are marked as standard, and the rest as custom.
  • Resources - host groups, template groups, and hosts. Each host appears inside every host group it belongs to. Oleria shows which user groups have Read-only or Read-write access to each host group and template group. Roles of user type Super admin get Read-write access to every host group and template group, because Zabbix gives Super admins full access regardless of group permissions.
  • Authentication settings - whether MFA and SAML SSO are turned on for the server, the sign-in methods available, and the minimum password length. When SAML SSO is on, Oleria links Zabbix to the app in your identity provider through the SAML entity ID.
  • Activity - events from the Zabbix audit log, with the client IP address. This includes sign-ins, sign-outs, and failed sign-ins, and changes to users, passwords, user groups, roles, API tokens, MFA methods, user directories, and authentication settings. Other configuration changes are included too. Each event reads as a sentence, such as “Admin added host group Web servers”, and events on a host, host group, or template group link to it in Zabbix.
Oleria refreshes this data on its regular sync schedule.

​
Prerequisites

  • Zabbix 7.0 or later. Oleria refuses earlier versions.
  • A Zabbix user with the Super admin user type, to create the API token and, if needed, a role.
  • A Zabbix frontend that Oleria can reach over HTTPS from the internet. Oleria refuses private and loopback addresses.
  • Admin access to the Oleria workspace.
Each Oleria integration covers one Zabbix server. If you have several, add one integration for each.

​
Set up an API token in Zabbix

1

Choose a user for Oleria

In Zabbix, go to Users -> Users and select or create the user Oleria connects as. A dedicated user is recommended. On the user’s Permissions tab, select a role of user type Super admin, such as the built-in Super admin role.The user type must be Super admin. Zabbix shows other user types only their own user, groups, and tokens, so Oleria refuses tokens of any other user type rather than sync a partial inventory.
2

Allow the API methods

The built-in Super admin role allows every API method. If you use a custom role that restricts API methods, go to Users -> User roles, open the role, and allow the methods in the tables below.
3

Create the API token

Go to Users -> API tokens and create an API token for the user you chose. Copy the token before you close the dialog. Zabbix shows it only once. If you set an expiry date, update the token in Oleria before it expires.
4

Let Oleria reach your Zabbix frontend

Contact support@oleria.com to allowlist the hostname of your self-hosted server or Zabbix Cloud node (https://<name>.zabbix.cloud). For a Zabbix Cloud node, also add Oleria’s egress IP addresses to the node’s access filters. Support can give you the current list.
Read permissions, for discovery: If the role denies a required method, the sync reports an error. Write permissions, only if you want Oleria to take remediation actions:

​
Connect Zabbix to Oleria

1

Open the integration

Go to your Oleria workspace, select Integrations, then select the Zabbix tile.
2

Complete the connection form

3

Authenticate

Select Authenticate. Oleria checks that it can reach the Zabbix API, that the server runs Zabbix 7.0 or later, and that the token belongs to a user of type Super admin, then saves the integration.

​
Verify the integration

Confirm Zabbix appears on the Connected tab of your Oleria Integrations page with a status of Healthy. After the first sync completes, you can review the discovered users, groups, roles, host groups, and tokens in your Oleria workspace. The integration’s Capabilities tab shows Read users, Read groups, and Read roles with the Zabbix permissions each one needs, and checks them against your token.
If you replace the API token in Zabbix, update it in Oleria by editing the integration. Leave API token (optional) blank to keep the stored token.

​
Remediation actions

Beyond discovery, Oleria can act on Zabbix access to remediate risk. Remediation needs the write permissions described above. Before an action runs, Oleria checks that the token’s user is a Super admin and that its role allows every method the action uses, and reports any that are missing. If the user or token is already in the requested state, nothing changes, except where noted below. Disable NHI supports API tokens, the only non-human identities Zabbix has. Oleria won’t remove the user the connection runs as from a group, or disable, delete, or change the role or access of that user. It also won’t disable any API token of that user, because Zabbix stores tokens hashed, so Oleria can’t tell which of them the connection uses.

​
Known limitations

  • Deny permissions aren’t shown as access. A user group’s Deny permission on a host group or template group creates no access in Oleria, and Oleria records the denied groups on the user group. A user who is in both a Read-write group and a Deny group for the same host group still appears to have access, even though Zabbix refuses it.
  • Effective permissions by user type aren’t modeled. Zabbix lets a user of type User only read, even through a Read-write group, and applies template group permissions only to Admin and Super admin types. Oleria shows group permissions as configured.
  • Tag filters and service permissions aren’t modeled. Tag-based filters that narrow a user group’s host access, and the IT service permissions in roles, aren’t shown.
  • Templates aren’t inventoried. Access to a template follows its template group.
  • Email addresses come from media. Zabbix has no email field on users. Oleria uses the user’s first enabled email media, so users without one show no email address.
  • Dates come from the audit log. Zabbix doesn’t store when a user was created, last signed in, or last changed their password, or when a token’s secret was generated. Oleria takes these dates from the audit log, so they’re available only within the retention your Zabbix housekeeping settings keep. Users created by the Zabbix installer, such as Admin, have no creation date. A token’s last-used date comes from Zabbix directly.
  • Token activity appears as the token’s user. Zabbix doesn’t record whether an action was made through the frontend or with an API token. Group membership changes are logged as updates to the user.
  • No service accounts. Zabbix has no service account type. Users who only call the API appear as ordinary accounts, and their tokens appear as non-human identities.
  • Directory users can be changed back. For users provisioned from LDAP or SAML, Zabbix can rewrite their user groups the next time they sign in or are provisioned, which can undo a group action.
  • Revoking shared group access isn’t supported. When a user’s access comes from a user group that other users share, revoke it by removing the user from the group.
  • One server per integration. Add one integration for each Zabbix server.

​
Contact us

For questions about this integration, contact us at support@oleria.com.