> ## Documentation Index
> Fetch the complete documentation index at: https://docs.oleria.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Zabbix

> Connect your Zabbix server to Oleria to continuously discover who can change your monitoring: users, user groups, roles, host group and template group access, API tokens, and audit log activity.

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](/integrations/overview.md#sync-model).

## 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](mailto: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:

| Permission | What it adds |
| :- | :- |
| User type **Super admin** (required) | Every user, group, and token on the server. Oleria checks it when you connect and before every sync. |
| `user.get`, `mediatype.get` (required) | Users and their email addresses. |
| `authentication.get`, `mfa.get`, `userdirectory.get` (required) | MFA, SSO, and sign-in method for each user. |
| `usergroup.get` (required) | User groups, their members, and their host group and template group permissions. |
| `role.get` (required) | Roles. |
| `token.get` and the **Manage API tokens** role action (required) | API tokens. |
| `hostgroup.get`, `templategroup.get`, `host.get` (required) | Host groups, template groups, and hosts. |
| `auditlog.get` | Activity, the creation, last sign-in, and last password change dates, and token rotation dates. Without it, the activity sync reports an error, those dates stay empty, and everything else still syncs. |

If the role denies a required method, the sync reports an error.

Write permissions, only if you want Oleria to take [remediation actions](#remediation-actions):

| Permission | What it allows |
| :- | :- |
| `user.update` | Adding and removing user group members, disabling and enabling users, and changing a user's role. |
| `usergroup.update` | Revoking a user's host group or template group access. |
| `user.create` and `user.delete` | Creating and deleting users. |
| `usergroup.create` and `usergroup.delete` | Creating user groups. |
| `token.update` and the **Manage API tokens** role action | Disabling API tokens. |

## 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**

| Field | Notes |
| :- | :- |
| Zabbix URL | Required. The HTTPS address of your Zabbix frontend, including any path such as `/zabbix`. For example, `https://zabbix.example.com/zabbix`, or `https://<name>.zabbix.cloud` for a Zabbix Cloud node. It can't contain credentials, a query, or a fragment. You can't change it after you connect. |
| API token | Required. The API token you created. When you edit the integration, the field is labeled **API token (optional)**. |

**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.

> [!NOTE]
>
> 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.

| Action | What it does | Revert | Zabbix permissions |
| :- | :- | :- | :- |
| Add user to group / Remove user from group | Adds or removes a user in a user group. The user's other group memberships stay as they are. | Yes - applies the opposite change. | `User type: Super admin`, `role.get`, `user.get`, `usergroup.get`, `user.update` |
| Disable user account | Adds the user to a user group whose status is **Disabled**. Oleria uses the **Deprovisioned users group** from your Zabbix authentication settings, or, if none is set, the disabled user group with the lowest ID, such as the built-in **Disabled** group. If no disabled user group exists, the action fails. | Yes - removes the user from that group. Group memberships the user gained since stay. | `User type: Super admin`, `role.get`, `user.get`, `authentication.get`, `usergroup.get`, `user.update` |
| Enable user account | Removes the user from every user group whose status is **Disabled**. | Yes - adds the user back to those groups. | `User type: Super admin`, `role.get`, `user.get`, `authentication.get`, `usergroup.get`, `user.update` |
| Revoke access to a resource | Removes a host group's or template group's permission from the user groups that grant it to the user, only when the user is the only member of each of those groups. Otherwise Oleria refuses and names the groups, because the change would also remove access for the other members. Access to a single host comes from its host groups, so revoke the host group instead. Super admins have access to everything, so the action is refused for them. If one of the user's groups denies the host group or template group, Zabbix already refuses the access, so nothing changes. | Yes - restores the groups' previous permission. | `User type: Super admin`, `role.get`, `user.get`, `usergroup.get`, `usergroup.update` |
| Add user to role / Remove user from role | Sets the user's role. A Zabbix user holds one role, so adding a role replaces the current one. Removing it leaves the user with no role, and such a user can sign in only through LDAP or SAML. | Yes - restores the previous role. | `User type: Super admin`, `role.get`, `user.get`, `user.update` |
| Create user | Creates a user with the username and email you enter, in the user groups you choose, and with no role. Unless you ask Oleria to activate the user, it adds them to the disabled user group. Oleria sets the password you enter, or generates one, and never shows or stores it. The user can't sign in with a password until you give them a role with **Add user to role**. If the username already exists, the action fails. It also fails if Zabbix has no email media type or, unless you activate the user, no disabled user group. | Yes - deletes the user. | `User type: Super admin`, `role.get`, `user.get`, `usergroup.get`, `mediatype.get`, `authentication.get`, `user.create`, `user.delete` |
| Delete user | Deletes the user. Oleria never deletes the user the connection runs as. | No - Zabbix deletes the user permanently. | `User type: Super admin`, `role.get`, `user.get`, `user.delete` |
| Create group | Creates a user group. If a group with that exact name already exists, nothing changes. | Yes - deletes the group if it still has no members. | `User type: Super admin`, `role.get`, `usergroup.get`, `usergroup.create`, `usergroup.delete` |
| Disable NHI | Disables an API token so it stops authenticating. | Yes - re-enables the token, and the same token works again. | `User type: Super admin`, `role.get`, `token.get`, `token.update`, **Manage API tokens** role action |

**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](mailto:support@oleria.com).


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.