Zabbix SSO with SAML and LDAP guide

Why teams move Zabbix logins onto SSO and what makes it harder than it looks

Zabbix supports internal, HTTP, LDAP, SAML and MFA authentication, and LDAP and SAML can provision Zabbix user accounts just in time, on first login. That means a security or identity team can move frontend sign-in under the corporate directory without asking every operator to be created by hand. The harder part is that the change touches more than the login page, and most of the work sits in deciding who gets what once they are in.

Identity is not handled the same way across the three places where Zabbix accepts requests. The web frontend authenticates users through the configured method, the API and the database each have their own access paths, and local accounts can remain in the database alongside directory users. Before cutover, map every route an operator, automation job or integration uses to reach Zabbix, and confirm which of those routes will still accept a local password after SSO is enabled. An account that works in the browser but is left behind for the API is a common source of surprises.

Group-to-role mapping decides what a user can see and change. A directory group that maps to the wrong Zabbix user group can expose hosts from another team, or block an on-call engineer from acknowledging a problem. Build the mapping from a written inventory of Zabbix user groups, host group permissions and the roles each team needs, then test it with one account per role. Confirm with your Zabbix configuration how a user who belongs to several directory groups is resolved, and decide what happens to a user whose directory group is removed. Those decisions should be made by the owners of the monitored systems, not inferred from directory names.

Local break-glass accounts must survive an identity outage. If the LDAP server, the SAML identity provider or the MFA service is unavailable, operators still need a way to reach the frontend and fix monitoring, and the same is true during an incident that the monitoring itself is reporting. Keep at least one local administrator with a strong, separately stored credential, test that it works on each Zabbix node and on the proxies' management path, and record who can use it and how its use is logged. Confirm the exact fallback behaviour of your chosen authentication method and version in the Zabbix authentication documentation before you rely on it.

Plan the rollout as a sequence rather than a single switch. Start with a test instance that mirrors your directory structure, verify provisioning, group mapping, MFA prompts and break-glass access, then enable the method for a pilot group before the whole organization. Agree in writing who owns the directory groups, who approves role changes, and how deprovisioned users are removed from Zabbix, because just-in-time provisioning creates accounts but does not by itself remove the access they hold.

Which Zabbix settings and external services are involved

Zabbix SSO touches several settings at once. The frontend authentication method decides which login path applies, while the identity provider, group mapping, provisioning and MFA each shape who gets in and what they can do. Design them together, then check each one against the documentation for your exact Zabbix version.

Authentication method settings

In the Zabbix frontend, the authentication settings choose the default login method and whether LDAP or SAML is enabled. Zabbix lists internal, HTTP, LDAP, SAML and MFA as its authentication methods, and the choice determines which login path your users follow. Confirm how the default method, the internal fallback and any per-group overrides behave in your version, because a wrong default at cutover can lock out every user.

LDAP or SAML identity provider

This external system verifies passwords and issues the login assertions Zabbix trusts. For LDAP, the team configures the directory server, bind account, search base and the user attributes Zabbix queries. For SAML, it configures the entity identifiers, signing and encryption certificates, and the attribute names the identity provider sends. Confirm which options your version exposes, which certificate formats it accepts and how certificate rotation should be handled before go-live.

User group and role model

Zabbix controls access through user groups, which carry host group permissions, and user roles, which set what an account can do in the frontend and API. Identity provider groups must be mapped to these Zabbix groups so that each login lands with the correct permissions. Confirm the mapping syntax and role assignment rules in your version, and test with a least-privilege account before mapping any administrative group.

Just-in-time provisioning

With just-in-time provisioning enabled, Zabbix creates a user account on the first successful LDAP or SAML login, so administrators do not have to pre-create each user. The team must decide whether group membership refreshes on every login and how accounts are handled when a person leaves the directory. Confirm the provisioning options and their defaults for your version, since they determine who keeps access after offboarding.

MFA method

Zabbix lists MFA as its own authentication method, so a second factor sits on top of the primary login path. The team must choose an MFA method supported by the version it runs, confirm how users enroll, and decide whether it applies to all users or only to administrators. Test enrollment, lost-device recovery and how MFA affects API access, which may not follow the browser login path.

Local admin recovery account

Keep one internal Zabbix administrator account that does not depend on LDAP, SAML or MFA. If the identity provider, a certificate or the MFA service fails, this account is the way back into the frontend to correct the settings. Store its credentials under your break-glass procedure, limit who can use it, and confirm in your version's documentation that the internal method stays available while SSO is enabled.

Choosing between LDAP, SAML and MFA for Zabbix logins

This table compares the four decisions a CISO or identity lead signs off for Zabbix frontend access: LDAP bind, SAML, just-in-time provisioning and where MFA is enforced. Read each row for when the option fits and what it asks of directory, certificate and account operations. The main takeaway is that the authentication method and the account lifecycle should be decided together, because they determine who keeps access after a leaver or role change.

Decision	Option	Operational cost	When it fits
Authentication source	LDAP bind against a directory	Service bind account, directory access rules, TLS to the directory, and group lookups that must stay accurate	Users already live in an on-premises directory and the Zabbix frontend sits on the same trusted network
Authentication source	SAML against an identity provider	Certificate and metadata rotation, IdP application setup, and clock and audience checks when signing keys change	You want one federated login across tools and the identity provider already enforces your password and session policy
Account creation	Just-in-time provisioning	Mapping rules for groups and roles must be maintained, and accounts created at first login need a periodic review for orphaned users	Large or changing user population where pre-creating every account would add ongoing manual work
Account creation	Pre-created accounts	Manual or scripted account creation and removal, with a separate review to catch users who should no longer have access	Small, stable user groups, or where auditors expect every account to be approved before first use
MFA enforcement	MFA at the identity provider	Depends on the IdP's SAML session handling and step-up settings, so confirm how Zabbix sessions reflect the IdP's MFA result	Your IdP already runs MFA for all applications and you want one enrollment and recovery process
MFA enforcement	MFA configured in Zabbix	Zabbix becomes a second place to manage MFA enrollment, recovery and support requests, with its own audit trail to review	Zabbix is reached through a path where the IdP is not in the login flow, or a specific Zabbix MFA requirement must be met
Fallback access	Keep the internal login for a small break-glass set	Accounts and credentials to protect, test and review on a schedule, plus a documented procedure for when the directory or IdP is down	Any deployment where a directory or IdP outage must not lock out the monitoring team

How to build Zabbix SSO in the right order

This sequence moves Zabbix frontend login from local accounts to SAML or LDAP without locking out administrators or granting access by accident. Each step closes with a test that proves the change works before the next one starts.

Confirm the Zabbix version and authentication methods
Start by recording the Zabbix version in production and in the test environment, and confirm both are on a line that still receives support under the vendor's life cycle policy. Check which authentication methods that version offers for the frontend, including internal, LDAP, SAML and MFA, and note any differences between the test and production builds. The platform team and the security lead should sign off on this record together. The step is done when both environments report the same version and the team has a written list of the methods it intends to use.
Prepare a break-glass admin account
Before any external authentication is enabled, create a local Zabbix administrator account that does not depend on LDAP, SAML or MFA. Store its credentials in the organization's approved secrets vault, limit who can retrieve them, and document the procedure for using it. Keep the internal login method available so this account can always sign in, even if the identity provider is down or misconfigured. The step is done when someone other than the author signs in with the break-glass account on the test instance and the attempt appears in the audit log.
Configure the directory or identity provider connection
Connect Zabbix to the LDAP directory or SAML identity provider in the test instance, using the settings your identity team supplies for endpoints, certificates, bind accounts and attribute names. Confirm the exact configuration fields and certificate handling against the Zabbix version you confirmed earlier, since these details vary by release. Keep the service account read-only and scoped to the users who need Zabbix access. The step is done when a test user from the directory reaches the Zabbix login page and completes authentication against the provider, with the result recorded in the Zabbix log.
Map identity groups to Zabbix user groups and roles
Translate the directory or identity provider groups into Zabbix user groups and roles, starting from the least-privilege model your monitoring team has agreed on. Map each identity group to one role, and document which groups grant read-only access, which grant configuration rights and which grant no access at all. Review nested groups and attributes that could widen access unintentionally. The step is done when a test user in a mapped group signs in and sees the expected role, and a low-privilege test user is denied an action that requires higher rights, such as editing a host or changing global settings.
Enable just-in-time provisioning on a test instance
Turn on just-in-time provisioning in the test instance so Zabbix creates a user account on first successful login through LDAP or SAML, using the group mapping from the previous step. Decide in advance how accounts for leavers will be disabled, because provisioning creates accounts but does not by itself remove them when someone leaves. Run the flow with at least one new test identity that has never signed in before. The step is done when that identity logs in for the first time, receives an account with the mapped role, and the account is visible in the user list with the expected group membership.
Add MFA to the login flow
Add the multi-factor method your identity team has chosen, and confirm that Zabbix's MFA setting works with the chosen SAML or LDAP method rather than assuming it does. Test enrollment, the second factor prompt, and what happens when a user's factor is lost or reset. Check that the break-glass account has its own recovery path that does not depend on the new factor. The step is done when a test user is challenged for the second factor on every login, a failed second factor blocks access, and the failed attempt is written to the audit log.
Cut over with a documented rollback path
Schedule the production change with the owners of Zabbix, the identity provider and the service desk, and agree the rollback trigger before the change starts. Enable the external login method in production while keeping the break-glass account and the internal method available, then run the same login, role, denial and failed-login tests used on the test instance. Keep the rollback steps written down and rehearsed, so the team can revert the authentication method without rebuilding the instance. The step is done when the production tests pass, the failed login appears in the logs, and the rollback has been confirmed as executable.

What drives the effort and cost of Zabbix SSO

This table lists the factors that move the effort of a Zabbix SSO build with SAML or LDAP, why each one matters, and how to keep it contained in a written scope. Read each row as a question to answer before asking for a quote. The main takeaway is that directory cleanliness, certificate ownership and the number of Zabbix nodes usually matter more than the login protocol itself.

Driver	Why it changes effort or cost	How to keep it down
User populations and roles	Each population (staff, contractors, read-only operators, service accounts) needs its own mapping from identity groups to Zabbix user groups and roles. More populations mean more mapping rules and more test cases.	Agree the list of populations and target roles before build. Limit the first release to the roles your monitoring team needs and add others later.
Directory group hygiene	Mapping depends on group names and membership in the identity provider or LDAP directory. Nested, duplicated or unowned groups add investigation and rework.	Ask the identity team to confirm a small set of monitoring groups with clear owners. Exclude legacy groups from the mapping scope.
SAML metadata and certificate ownership	The identity team must supply metadata, sign-on URLs and signing certificates. Certificate rotation after go-live needs a documented owner, or logins fail when a certificate expires.	Name the owner of metadata exchange and certificate rotation in the scope. Ask for a rotation procedure and a test login in the non-production environment first.
LDAP bind and search design	Bind account choice, search base, user filters and TLS settings each need validation against the directory. Errors often appear only with real user accounts.	Request a read-only bind account and a tested search filter from the directory team. Confirm how TLS certificates are issued and trusted.
Number of Zabbix instances or HA nodes	Each frontend or server node that shares one configuration must receive the same authentication settings and be tested. Native server HA means several nodes share one database, so configuration changes apply across the cluster.	Make configuration changes once in a shared database and test login on every frontend node. Confirm the node count and load balancer layout in the scope.
MFA requirements	Adding MFA changes the login flow, depends on the method chosen (Zabbix supports MFA as an authentication method), and may need help desk procedures for lockouts and enrollment.	Decide whether MFA applies to all users or only administrators. Confirm the MFA provider and enrollment process before build, and document recovery steps.
Just-in-time provisioning rules	Accounts created on first login through LDAP or SAML need default groups, media settings and disable rules. Unclear rules create stale accounts and audit questions.	Write the provisioning and deprovisioning rules down before build. Ask for a test showing how a removed user loses access.
Testing across environments	Each environment needs its own IdP or directory connection, test users and evidence of login, role mapping and logout. Repeated test cycles after each change add time.	Ask for a test matrix covering each population and role, run in a non-production environment first. Confirm who signs off each environment and who performs the production check.

How SSO differs for single node, HA and air-gapped Zabbix

A single Zabbix server with one web frontend is the simplest place to test SAML or LDAP login and to cut over. Because one frontend handles every login, the team can validate the identity configuration end to end before users depend on it. The work centers on one directory connection or one identity provider metadata exchange, plus a fallback path for administrators.

Test accounts first: Sign in with a standard user and an administrator from each identity group before changing the default authentication method.
Keep an emergency local administrator: Retain an internal authentication account so the team can recover access if the directory or identity provider is unavailable.
Verify the directory connection: Confirm the bind account, search base and group filter return the expected users on first login.
Cut over in a planned window: Switch the frontend authentication method during a scheduled change, with a documented rollback step.
Review provisioned accounts: Check the user accounts created on first login and the user groups and roles assigned to them.

Confirm with your own environment which directory or identity provider attributes carry group membership, because that determines whether the group mapping works without manual edits.

How to test that Zabbix SSO works and fails safely

The test plan should prove two things before go-live: users who should get in can log in with the right group and role, and every other attempt fails closed with a clear message and a record. Run each case in a staging Zabbix frontend connected to a test identity provider or a test directory OU, using the same authentication method you will use in production. If both SAML and LDAP are enabled, run the cases separately for each, because the mapping and error paths differ. For every case, record the expected result, the actual result, the Zabbix user and group state afterwards, and the audit log entry, so the evidence can go into the change record.

Start with successful logins, one per mapped group, and confirm each user lands in the Zabbix user group and role you mapped. Then test a user who belongs to no mapped group. The expected result is a denied login with no Zabbix account left in a usable state. Next, test just-in-time provisioning: the first login should create the user with the expected group membership, and a second login should reuse that account instead of creating a duplicate. Confirm with the Zabbix administrator which attributes populate the account, because mapping depends on what your IdP or directory sends. Finally, move a test user to a different directory group and confirm the Zabbix role changes at the next login, with the old role removed.

Disable one directory account and expire a second one, then attempt login with each. Zabbix should refuse both attempts. Check what happens to a session that was already open when the account was disabled, and confirm which timeout governs it: the Zabbix session settings, the IdP session lifetime, or both. For MFA enforcement, attempt login without the second factor and confirm it is rejected. Repeat this for every path that can reach the frontend, including any route that still permits internal authentication, because one unenforced path defeats the control. Ask your identity team to confirm how the MFA policy is applied in the IdP, not only in Zabbix.

Simulate an identity provider or directory outage in staging by blocking the IdP metadata endpoint or the LDAP connection from the frontend host. Then log in with the break-glass account. Confirm that it works, that its use is logged, and that the credential is held by named administrators under a documented retrieval procedure. Check that the login page shows a clear error for SSO users rather than a blank page or a stack trace. When connectivity returns, confirm SSO logins work again and find out whether your configuration requires a restart or a configuration reload to recover. Record that step as a test result too.

Define safe failure before testing so that pass or fail is not a judgment call made during the test. A safe failure has three properties: no anonymous or guest access to monitoring data, a clear error message to the user that does not reveal whether an account exists, and an audit trail entry that shows the attempt, the authentication method and the reason where Zabbix records it. Check the audit log in the Zabbix frontend and confirm whether your central logging or SIEM receives those events. Ask your security team which events must reach the SIEM and how quickly, then include those checks in the go-live review.

How to lock down Zabbix identity and access

Zabbix SSO creates three places where access can be granted too broadly or kept alive too long: the identity provider, the directory, and the Zabbix frontend itself. The five controls below cover the points where a misconfiguration most often gives someone more access than intended. Confirm each setting against the Zabbix authentication documentation for your version before go-live.

Map directory groups to least-privilege roles

Group mapping decides which Zabbix user type and user group each directory group receives at first login. Confirm that no broad directory group, such as a general IT or all-staff group, maps to a Zabbix Super admin role by default. Test each mapping with a sample account from every group, and check the resulting permissions in the frontend as well as the mapping table. Review the mappings after every directory reorganization, because group membership changes flow straight into Zabbix access.

Protect the break-glass account

Keep at least one local Zabbix account that does not depend on SAML or LDAP, so administrators can sign in if the identity provider or directory is unavailable. Store its password in a separate vault entry with restricted access, and do not use the account for daily work. Alert on every login to it and review each event, because any use of this account should be explainable from a recorded incident or change.

Secure SAML certificates and LDAP bind credentials

The SAML signing certificate and the LDAP bind account password are both trust anchors for login. Keep them in a secrets store with access logging, out of configuration files and shared documents. Use a read-only directory account for LDAP binds, and schedule SAML certificate renewal before expiry, because an expired certificate stops all SSO logins. Confirm the renewal owner and the procedure for swapping the certificate in Zabbix.

Restrict frontend and API access by network

SSO does not stop a request that arrives from an untrusted network, so limit which networks can reach the Zabbix web frontend and the API endpoint. Place the frontend behind a reverse proxy or firewall rules that match your administrator and monitoring networks. Verify that the API is reachable only from the systems that need it, and retest the restriction after any change to the proxy, load balancer or firewall policy.

Review deprovisioning of just-in-time accounts

Just-in-time provisioning creates a Zabbix account at first login, but disabling the directory user does not remove that Zabbix account. Confirm how your process disables or deletes the Zabbix user, whether through a scheduled review or an automated call, and test it with a leaver. Compare the Zabbix user list against current directory group membership on a regular schedule, and record who approved each exception.

What to monitor, document and review after SSO goes live

Once SAML or LDAP login is live, the most useful ongoing task is watching the login path itself. Collect failed logins from the Zabbix frontend and from the identity provider, and alert on bursts of failures for one account or one source, not only on single events. Track every change to authentication settings in Zabbix, including the LDAP server, bind account, search base, SAML entity and attribute settings, and the default authentication method. A small change to a search base or an attribute name can lock out an entire group with no obvious error on the Zabbix side. Confirm which login and configuration events your Zabbix version records in its audit log and whether they reach your central logging platform, because the audit log only protects you if someone reviews it.

Directory changes are the most common reason a working SSO setup starts granting the wrong access. When teams are renamed, merged or moved, the group-to-role mappings in Zabbix can silently stop matching anything, or match groups that now hold people who should not have administrator rights. Review the mappings on a fixed schedule and after each reorganization that touches the identity source. Certificates and credentials need the same discipline. Record the expiry date of the SAML signing certificate that your identity provider uses and of any Zabbix SAML certificate in use, and schedule the rotation well before expiry. Do the same for the LDAP bind account password, and confirm with your directory team who can rotate it and how the change will be tested in Zabbix before the old credential is removed.

Test the break-glass login on a schedule, and treat a failed test as an incident. The break-glass path is a local Zabbix account with a strong password and, where your policy requires it, MFA, kept for the case when the identity provider or directory is unavailable. Check that the account still works, that its password is stored where the authorized staff can reach it, and that the login is logged and alerted on when used. Back up the Zabbix configuration, including the authentication settings, on the same cycle as the database backups, and test that a restore brings the authentication configuration back. Before each Zabbix upgrade, add a login regression test to the upgrade plan, covering SAML, LDAP, MFA and the break-glass account, because authentication behavior can change between releases and the upgrade window is when a lockout is hardest to diagnose.

Document three things before go-live and keep them current. The first is the mapping matrix, which lists each identity-provider group or directory group, the Zabbix user group and role it maps to, the host group permissions that follow from it, and who approved the mapping. The second is the owner of each identity source, meaning the named people responsible for the identity provider, the LDAP directory, the Zabbix authentication configuration and the MFA enrollment process, along with who can approve changes to each. The third is the recovery runbook, which sets out the steps to restore login when SAML or LDAP fails, how to use the break-glass account, who to call, and how to roll back an authentication change. Ask your Zabbix implementation partner or internal team to walk through the runbook once a year against the live system, so the document reflects the configuration that actually runs.

Questions buyers ask before setting up Zabbix SSO

What drives the cost of setting up Zabbix SSO?

The cost follows the written scope, and the main drivers are the number of identity sources, how complex the group-to-role mapping is, and whether MFA is part of the work. Zabbix open source has no license fee, no device limits and no feature gates, so the spend is on people and infrastructure. DeployOpen is paid for planning, configuring, testing, documenting and handing over the setup. Your organization pays its own staff time from the identity, directory, network and monitoring teams, plus any MFA product licenses you already hold or need to buy. Most of the cost is one-time. Ongoing costs come from maintaining mappings, rotating certificates and supporting the platform. Ask any quote to itemize the identity sources, the roles to map, the test environments and the handover materials.

How long does Zabbix SAML or LDAP setup usually take?

Duration depends on how many identity sources you connect, how your directory groups are structured, and how many environments need testing. A single LDAP directory with a simple group model is less work than a SAML setup that must match attributes and groups from an identity provider and test several login paths. Approvals from identity and security teams often set the pace more than the Zabbix configuration itself. No figure is given here because the honest answer depends on your environment. Ask for a timeline in the written scope, with the milestones for test login, group validation, the cutover from local login and handover. Check that the plan leaves room for your change approval process.

What does the identity and network team need to provide for Zabbix SSO?

The identity team supplies the login integration details, and the network team confirms the paths the Zabbix frontend needs. For SAML, the identity provider administrator registers Zabbix as an application, supplies metadata and certificates, and defines the attributes and group claims that Zabbix will read. For LDAP, the directory team provides a read-only bind account, the base distinguished names for users and groups, and the attributes that identify each user. The network team confirms that the Zabbix frontend can reach the identity provider or directory over the required ports, that DNS resolves correctly, and that TLS certificates are trusted. Agree on who owns certificate renewal before go-live, because expired certificates are a common cause of login failures.

Can our internal team set up Zabbix SSO without a partner?

Yes, an internal team with Zabbix administration skills and access to the identity provider or directory can do the work, and the decision depends on capacity and risk tolerance. Zabbix lists LDAP, SAML and MFA among its authentication methods, and just-in-time provisioning can create user accounts on first login through LDAP or SAML, so the features exist in the product. The difficulty lies in mapping groups to roles correctly, testing edge cases and writing the runbook. Ask yourself whether someone on the team has done this before and whether they can test it in a non-production environment first. A partner may help where there is no time for trial and error, or where the setup must be documented for audit evidence. DeployOpen plans, implements and documents this work inside your own infrastructure, under a fixed scope agreed in writing.

Should we use SAML or LDAP for Zabbix login?

Choose SAML when your identity provider is the system of record for sign-in and supports SAML, and choose LDAP when your user and group data lives in a directory that the Zabbix frontend can reach. With SAML, the identity provider handles the password check and often the MFA step, and Zabbix trusts the assertion it receives. With LDAP, Zabbix checks credentials against the directory, so the directory must be reachable and the bind account must be managed carefully. Both support just-in-time provisioning according to the Zabbix authentication documentation. Many organizations already run a central identity provider, which often makes SAML the simpler path to keep consistent with other applications. Confirm the options available in your Zabbix version and your identity provider before deciding, because the group and attribute handling differs between the two.

How is multi-factor authentication added to Zabbix login?

Zabbix lists MFA as one of its authentication methods, so MFA is configured as part of the login design rather than bolted on afterward. In practice, many teams enforce MFA at the identity provider for SAML logins, so every application behind that provider gets the same second factor. For LDAP, the design must decide where the second factor is checked and which factor types are supported in your Zabbix version. Confirm the supported factor types, the enrollment process for users, the recovery process for lost devices and whether MFA applies to API access as well as the web interface. Test the full login path with a non-administrative user and an administrator before enforcing it for everyone. Record the decisions in the runbook, because auditors and security teams will ask how the second factor is enforced.

What happens to existing local Zabbix accounts after SSO is enabled?

Local accounts keep working unless you change their authentication method, so the cutover plan must decide what happens to each one. Zabbix supports internal authentication alongside the external methods, and you can set authentication per configuration, so local accounts are not removed automatically when SSO goes live. Keep at least one tested local administrator as an emergency path in case the identity provider or directory is unavailable, store its credentials securely and restrict its use. Review the existing accounts, decide which users move to SSO, which accounts are service or break-glass accounts, and which should be disabled after the cutover. Confirm in your version's documentation how a user who exists both locally and through just-in-time provisioning is handled before you run the migration.

Does a Zabbix upgrade change or break the SSO configuration?

An upgrade can change authentication behavior or settings, so re-test SSO in staging after every version change before the production upgrade. Zabbix 7.0 LTS received full support until 30 June 2027 and limited support until 30 June 2029, and Zabbix 6.0 LTS limited support ends on 28 February 2027, so many estates will move to a newer line within the next few years. Read the release notes for each target version, check the supported database versions and confirm how your SSO settings migrate. Keep a copy of the working configuration, including the mappings and certificate references, so you can restore it quickly. Plan the upgrade order with the server, proxies and agents in mind, and include login tests for both an administrator and a standard user in the change plan. Ongoing support and upgrade work can be covered under a retainer if you want the same team to carry the configuration forward.

How DeployOpen scopes, builds and hands over Zabbix SSO

DeployOpen scopes Zabbix SSO as a fixed-scope engagement, with the identity provider, LDAP directory and Zabbix frontend settings agreed in writing before work starts. The build covers SAML or LDAP login, just-in-time provisioning, group and role mapping and MFA, all inside your own infrastructure. Ongoing support is available as a retainer.

How we scope

The written scope names the identity provider, LDAP directory or both, and the Zabbix frontend users affected.
Scope also records the Zabbix version you run, since authentication options can differ between releases.
Fixed-scope engagements are agreed in writing before work starts, with deliverables and timelines listed in the scope.

How we build

Configure the LDAP or SAML authentication method in the Zabbix frontend, tested against a non-production user first.
Set just-in-time provisioning so accounts appear on first login, and map identity groups to Zabbix user groups and roles.
Add MFA where the chosen design requires it, and test each role mapping with accounts that hold different access levels.

How we hand over

Documentation covers the identity provider settings, LDAP bind details held by your team, and the group-to-role mapping table.
Test evidence records login paths, failed login behavior, provisioning results and which accounts received which roles.
Knowledge transfer walks your administrators through rotating certificates, changing group mappings and reviewing local fallback accounts.

How we support

Ongoing support after go-live is available as a retainer, covering changes to identity providers and directory structures.
Zabbix upgrades can change authentication behavior, so SSO settings are retested as part of any version move.
Confirm with Zabbix which support tier fits your operations, since vendor support is separate from DeployOpen's own services.

Zabbix SSO with SAML and LDAP