Zabbix – automatizace správy uživatelů (JIT)

Dnes si společně probereme možnosti autentizace v Zabbixu, ukážeme si příklady jejich nastavení a probereme i výhody a možná úskalí použití jednotlivých metod.

Zabbix

25. 1. 2024

Automatizace správy uživatelů v Zabbixu 7.0

Zhlédnout záznam

Možnosti autentizace v Zabbix

Ve výchozím nastavení používá Zabbix pro všechny uživatele interní ověřování. Lze však použít kombinaci interních účtů a účtů z LDAP (Microsoft Active Directory a OpenLDAP), SAML 2.0 nebo SCIM, případně lze k ověření uživatelského jména a hesla využít i HTTP autentizaci (například Basic Authentication nebo NTLM/Kerberos), oproti ostatním způsobům však v tomto případě není možné použít JIT.

V následujících kapitolách se blíže podíváme na základní nastavení ověřování oproti LDAP (Active Directory), SAML (Azure) i SCIM (Azure).

Ve všech našich příkladech nejprve zapneme autentizaci pomocí LDAP a povolíme JIT provisioning.

V sekci Users -> Authentication -> Authentication nastavíme výchozí ověřování (Default authentication) na LDAP.

Pro položku Deprovisioned user groups pak vybereme skupinu Disabled.

LDAP (Active Directory)

Základní nastavení

Nejprve v sekci Users -> Authentication -> LDAP settings zaškrtneme checkboxy Enable LDAP authentication a Enable JIT provisioning.

Pokud to naše prostředí vyžaduje, pak můžeme také povolit case-sensitive přihlašování, tedy např. uživatelé se stejným jménem a příjmením rozlišení case-sensitive přihlašovacím jménem.

Můžeme také nastavit nižší nebo vyšší četnost s jakou provisioning probíhá, než je hodnota výchozí (1 hodina).

Následně musíme přidat LDAP server a nastavit JIT provisioning, a to tak, že klikneme na odkaz Add nacházející se v sekci Servers.

V následujícím dialogu pak vyplníme veškeré údaje o LDAP serveru, přihlašování k němu (např. pomocí servisního účtu) a údaje potřebné pro procházení strukturou cílového LDAP serveru.

Nejprve nastavíme jméno LDAP serveru, jeho IP adresu nebo hostname, port LDAP služby (standardně 389 pro ldap a 636 pro ldaps), LDAP serverů můžeme mít definováno i více než jen jeden.

Zvolíme cestu, kde má Zabbix v LDAP hledat uživatele a skupiny (BaseDN) a LDAP atribut, který se má hledat (Search attribute), tento bývá standardně sAMAccountName.

Vyplníme cestu v LDAP k uživateli, který je oprávněn se k LDAP připojit (BindDN) a jeho heslo (Bind password).

Pozn.: Z bezpečnostních důvodů doporučujeme na úrovni LDAP serveru zakázat anonymní bind a striktně používat ldaps (tcp/636).

JIT

Nyní přikročíme k nastavení samotného JIT provisioningu a to tak, že zaškrtneme checkbox Configure JIT provisioning, což rozbalí nabídku konfiguračních možností.

Nejprve zvolíme v položce Group configuration jak se mají na úrovni LDAP hledat skupiny. V tomto případě vybereme metodu memberOf, tedy že Zabbix má hledat uživatele a jejich členství ve skupinách.

Následně vyplníme název atributu, který určuje název skupiny (Group name attribute), obvykle je to CN, tedy CommonName.

V položce User group membership attribute doplníme atribut určující členství ve skupinách.

Povšimněte si, že na příkladu níže je tato položka správně vyplněna hodnotou memberof, ačkoliv nápověda v Zabbixu nabízí hodnotu memberOf, tato nápověda je ale chybná!

Edit: Tento bug byl oficiálně reportován a byl opraven v issue [ZBX-22597] resolved issue with LDAP group membership mapping not matching case-insensitive entries. Od verze 6.4.2 to tedy již neplatí a nápověda nabízí správnou hodnotu, kterou doporučujeme výše.

Dalšími položkami jsou atributy určující křestní jméno uživatele (User name attribute) a jeho příjmení (User last name attribute).

Tyto hodnoty jsou v případě Active Directory givenName pro křestní jméno a sn pro příjmení.

Mapování atributů

V sekci „User group mapping“ je nutné zvolit již existující skupinu na úrovni Zabbixu, do které se budou mapovat uživatelé z LDAP.

Skupina se musí jmenovat stejně v Zabbixu i v LDAP a v našem případě je to skupina Zabbix_Super_Admins.

Této skupině pak přiřadíme požadovanou uživatelskou roli, jejíž oprávnění skupina zdědí, jako například zde roli Super admin role.

Pozn.: Pro obě nastavení je povoleno používání zástupných znaků (např. *).

Následující položka Media type mapping mapuje atributy z objektů v LDAP pro potřeby naplnění media typů jednotlivých uživatelů.

Níže můžete vidět příklad mapující například e-mail:

Před uložením konfigurace je možné funkčnost celého nastavení otestovat pomocí tlačítka Test.

V tuto chvíli máme nastavení přihlašování pomocí LDAP včetně JIT provisioningu uživatelů hotové. Konfiguraci můžeme uložit a přihlásit se pomocí svých přihlašovacích údajů do LDAP.

Pokud pro připojení k LDAP serveru používáme „bind“ uživatele a LDAP nastavíme jako implicitní způsob ověřování (jako je tomu zde v našem případě), pak lze provést i jednorázový provisioning, například v případě, že víme o proběhlých změnách na úrovni LDAP a nechceme čekat předdefinovanou dobu četnosti provisioningu automatického.

Vykonat jednorázový, okamžitý provisioning můžeme v sekci Users -> Users. Zde, pod seznamem uživatelů je tlačítko Provision now.

SAML (Azure AD/Microsoft Entra ID)

Základní nastavení

Jak úplně první krok je nutné vytvořit si v Azure novou aplikaci, a to v sekci Enterprise applications -> All applications -> New application, viz následující screenshot.

Zde zvolíme možnost Create your own application.

Objeví se dialog, kde vybereme možnost, že aplikace není součástí nabídky, novou aplikaci si pojmenujeme a volby potvrdíme tlačítkem Create.

V nově vytvořené aplikaci zvolíme Single sign-on metodu SAML.

To nás zavede do možností nastavení SAML, kde u první možnosti Basic SAML Configuration klikneme na odkaz Edit.

Zde je nutné vyplnit Identity ID, což je URL adresa Zabbix frontendu. V našem případě tedy https://student-01.initmax.cz/zabbix.

Následně „Reply URL„, což je místo, kde Zabbix očekává autentizační token, tedy https://student-01.initmax.cz/zabbix/index_sso.php?acs.

Volitelně pak můžeme vyplnit i Logout URL, který je pro náš vzorový Zabbix následující: https://student-01.initmax.cz/zabbix/index_sso.php?sls.

Nastavení uložíme pomocí tlačítka Save a dialogové okno můžeme zavřít.

Objeví se vyskakovací okno s nabídkou otestování našeho nastavení, tento krok prozatím přeskočíme a zvolíme No, I'll test later, protože nastavení ještě není kompletní.

Atributy uživatelů a skupin

V sekci Attributes & Claims zvolíme odkaz Edit.

Zde vytvoříme nastavení pro skupinu pomocí tlačítka Add a group claim.

V dialogovém okně s nastavením skupin zvolíme All groups a vybereme sAMAccountName jako zdrojový atribut (Source attribute).

V pokročilých možnostech nastavení pak zaškrtneme checkbox, kterým si vybereme vlastní jméno pro náš nový „group claim“ a vyplníme námi zvolenou hodnotu, např. groups.

Dále potřebujeme vytvořit nový claim pro username, pro jméno a příjmení a pro média.

Nový claim vytvoříme pomocí tlačítka Add new claim.

Na tomto obrázku můžete vidět příklad parsování zdrojového atributu user.mail pro média typ Email.

Tento atribut je pro nás velice důležitý, jelikož emailovou adresu uživatele následně používáme jako přihlašovací jméno do Zabbixu.

Zde můžete vidět příklad nastavení claims i pro volitelné atributy, jako jméno a příjmení uživatele, jeho telefonní číslo a pushover ID.

Po nastavení všech požadovaných claims můžeme toho okno s nastavením zavřít.

Následně si stáhneme Base64 certifikát, který obsahuje přihlašovací token.

K tomuto účelu slouží odkaz Download v sekci SAML Certificates, jak vidíte na následujícím obrázku.

Předsvědčíme se, že se nám certifikát s přihlašovacím tokenem skutečně stáhl a můžeme přikročit k nastavení na úrovni Zabbixu.

Zabbix

Nejprve v sekci Users -> Authentication -> SAML settings zaškrtneme checkbox Enable SAML authentication.

Pokud to naše prostředí vyžaduje, pak můžeme také povolit case-sensitive přihlašování, tedy např. uživatelé se stejným jménem a příjmením rozlišení case-sensitive přihlašovacím jménem.

Můžeme také nastavit nižší nebo vyšší četnost s jakou provissioning probíhá, než je hodnota výchozí (1 hodina).

Správné hodnoty pro všechna požadovaná pole nastavení SAMLu najdeme v příslušných sekcích webového rozhraní MS Azure.

IdP entity ID je na úrovni Azure pojmenován Azure AD Identifier, hodnotu pro SSO service URL najdeme v Azure pod jménem Login URL, a SLO service URL je pak Logout URL.

Položku Username attribute vyplníme jménem námi vytvořeného claim pro uživatelský e-mail, tedy v našem případě user_email.

SPN pro SP entity ID pak vyplníme hodnotou Application ID z Azure. Tuto hodnotu najdeme ve vlastnostech naší vytvořené aplikace, tedy v menu Properties je to Application ID.

Tuto hodnotu si zkopírujeme a předtím, než ji vložíme do položky SP entity ID, tak je nutné napsat sem prefix spn:, jinak toto nastavení nebude fungovat!

Pro tuto chvíli jsme s nastavením SAMLu hotovi a můžeme ho uložit pomocí tlačítka Update.

Nyní nám ale přihlašování nefunguje, jelikož zatím Zabbix nedisponuje certifikátem obsahujícím autentizační token, který jsme si už z MS Azure stáhli.

Do Zabbixu ho musíme fyzicky dodat. Připojíme se tedy k Zabbix serveru pomocí SSH a nejprve vytvoříme složku pro certifikáty:

mkdir /usr/share/zabbix/conf/certs/

Sem nakopírujeme náš certifikát, například pod názvem AZURE.cer a nastavíme mu korektní oprávnění:

chmod 644 /usr/share/zabbix/conf/certs/AZURE.cer

Následně otevřeme konfigurační soubor Zabbix front-endu:

nano /etc/zabbix/web/zabbix.conf.php

Zde je třeba vyplnit v sekci SAML authentication konfigurační direktivu $SSO['IDP_CERT'] s relativní cestou k našemu certifikátu, tedy v našem případě následovně:

// Used for SAML authentication.
// Uncomment to override the default paths to SP private key, SP and IdP X.509 certificates, and to set extra settings.
//$SSO['SP_KEY'] = 'conf/certs/sp.key';
//$SSO['SP_CERT'] = 'conf/certs/sp.crt';
$SSO['IDP_CERT'] = 'conf/certs/AZURE.cer';
//$SSO['SETTINGS'] = [];

JIT

Nyní přikročíme k nastavení JIT provisioningu, a to opět v sekci Users -> Authentication -> SAML settings, kde zaškrtneme checkboxy Enable JIT provisioning a Configure JIT provisioning.

Otevře se nám nastavení, kde vyplníme požadované položky jmény našich claims, vytvořenými již dříve na úrovni Azure.

Po uložení tohoto nastavení je možné se přihlásit pod svými přihlašovacími údaji pomocí SSO, k tomuto účelu slouží na přihlašovací obrazovce odkaz Sign in with Single Sign-On (SAML), který nás přesměruje na přihlašovací stránku Microsoftu, případně nás rovnou přihlásí.

Že provisioning skutečně funguje je možné ověřit přímo u daného uživatele v sekci Users -> Users.

Ve sloupci Provisioned bude datum a čas, kdy provisioning naposledy proběhl.

Po kliknutí na konkrétního uživatele jsou políčka šedá, jelikož je toto nastavení řídíme centrálně, na úrovni Azure AD.

SCIM (Azure AD/Microsoft Entra ID)

Základní nastavení

Pro nastavení SCIM ho nejprve povolíme. To uděláme zaškrtnutím checkboxu Enable SCIM provisioning ve stejném dialogovém okně s nastavením pro SAML.

Tedy opět v sekci Users -> Authentication -> SAML settings.

Následně si vytvoříme API token se super admin oprávněním.

V sekci Users -> API tokens klikneme na tlačítko Create API token a v dialogovém okně s nastavením tokenu vybereme jméno tokenu a jako uživatele zvolíme lokálního privilegovaného uživatele Admin.

Dále tomuto tokenu zrušíme předdefinovanou dobu platnosti odškrtnutím checkboxu Set expiration date and time.

Zaškrtneme checkbox Enabled, abychom token povolili a takto nastavený token přidáme tlačítkem Add.

Po vytvoření tokenu se objeví stavové okno s popisem tokenu a tokenem samotným, který si zkopírujeme do schránky a následně uložíme.

Nastavení provisioningu

Nyní se vrátíme do Azure a v naší dříve vytvořené aplikaci jdeme do sekce Provisioning a klikneme na tlačítko Get started.

V nastavení provisioningu vybereme mód Automatic a v sekci Admin Credentials vyplníme Tenant URL, v našem případě URL SCIM API v Zabbixu.

Tedy konkrétně https://student-01.initmax.cz/zabbix/api_scim.php a do pole Secret Token vložíme náš uložený token z předcházejících kroků.

Spojení otestujeme pomocí tlačítka Test Connection a pokud je vše v pořádku, tak konfiguraci uložíme.

Mapování atributů

Po uložení konfigurace se objeví možnosti nastavení mapování uživatelů a skupin.

Zde vybereme možnost Provision Azure Active Directory Users.

Dostaneme se do sekce Attribute Mapping, kde musíme přidat vlastní atributy.

Abychom byli schopni zeditovat a přidávat vlastní atributy je nutné zaškrtnout checkbox Show advanced options, který se nachází úplně dole na této stránce.

Posléze klikneme na odkaz Edit attribute list for customappsso.

Tím se dostaneme na list všech atributů naší aplikace a sem si přidáme stejné atributy, jako v předchozích případech a konfiguraci mapování uživatelů uložíme pomocí tlačítka Save.

Již přidané atributy můžete vidět na obrázku níže.

Uložení listu atributů nás vrátí do původní sekce Attribute Mapping, kde je třeba na tyto atributy vytvořit správná mapování. Klikneme tedy na odkaz Add New Mapping.

Pro všechny naše atributy vytvoříme mapování k jejich konkrétnímu protějšku v AD, stejně jako v předcházejících případech.

Níže vidíte příklad pro mapování atributu user_mobile.

Zde pak vidíte seznam všech vyplněných atributů i s jejich správně nastaveným atributem zdrojovým.

Po nastavení mapování všech požadovaných atributů klikneme na tlačítko Save a dialogové okno zavřeme.

Posledním krokem pro nastavení funkčního SCIM je spuštění samotného provisioningu.

Vrátím se zpět na úvodní stránku našeho nově vytvořeného provisioningu do sekce Overview a zde klikneme na tlačítko Start provisioning.

Tímto je nastavení SCIM provisioningu kompletní.

Za zmínku stojí upozornit, že SCIM provisioning má stále jisté limitace.

Například na úrovni Zabbixu sice uživatele vytvoří, ale neumí už je zaktualizovat, ani jim přiřadit konkrétní média.

Dle interních informací přímo ze Zabbixu se toto vývojáři Zabbix v blízké době zlepší a tyto funkcionality implementují.

Edit (8. 3. 2024): Toto je ve verzi Zabbixu 7.0 již opraveno – více v našem článku Verze Zabbix 7.0 LTS je téměř zde.