Kis cégeknél, ahol kevés ember fér hozzá a zabbixhoz, tökéletesen elég a beépített felhasználó kezelés.
Ahogy nő a vállalat, mind létszámban, mind alkalmazások számában, egy idő után elkerülhetetlen lesz a központi címtár használata. Ez lehet windows környezetben az Active Directory, opensource rendszereknél pedig valamilyen LDAP szerver.
Emlékeim szerint a zabbix 2012 óta támogatja az LDAP alapú hitelesítést, ám a 6.2-s verzió egyik újdonsága, hogy már több címtárat is tudsz vele használni. A 6.4-es óta pedig elérhetővé vált a JIT.
Vegyünk fel egy vagy több címtár szervert
Teljesen mindegy, hogy LDAP szervert, vagy AD-t akarunk használni, a hozzáadás menete ugyanaz. A különbség a paraméterekben lesz, ezt pedig képekkel fogom illusztrálni.
Kezdjük egy LDAP szerverrel
Menjünk az Users -> Authentication menüpontra, felül válasszuk ki az LDAP settings fület, pipáljuk ki a Enable LDAP authentication lehetőséget, és kattintsunk az Add linkre:
Nagyon fontos, hogy én a saját szervereim beállításait tudom megmutatni, mint működő példákat, egészen biztos, hogy az általad elérhető LDAP/AD szerverek ettől el fognak térni! Ne másold le betűről betűre, mert nálad ebben a formában nem fog működni!
Így néz ki egy 389ds LDAP szerver beállítása:
Így pedig egy zentyal féle samba által megvalósított AD:
Végül egy valódi Microsoft AD:
Miután a saját paramétereid alapján hozzáadtál egy címtárat, csinálj egy tesztet a jobb alsó sarokban található Test gomb megnyomásával:
Ha ezt a hibaüzenetet kapod, akkor vagy elgépelted a jelszót, vagy (mint nálam) nem létezik a kérdéses felhasználó. Nézzük meg egy létezővel is a tesztet:
Hogyan működik a zabbix felhasználó kezelése?
Felvettünk egy címtárat, sikeresen teszteltük, ám ettől még nem tudunk vele belépni. Aki odafigyelt, észrevehette, hogy bár felvettünk egy LDAP szervert, mégse fogja használni a zabbix, mivel a Default authentication gyárilag Internalon áll: 
Két lehetőségünk is van, de mindegyikben az a közös, hogy a felhasználókat nekünk kell felvenni a zabbixba.
1. verzió: alapértelmezett az Internal DB
Ebben a változatban minden felhasználót a zabbix authentikál, akiket LDAP-ból szeretnénk authentikálni, azt külön kell „jeleznünk”. Én ezt úgy oldom meg, hogy létrehozok egy felhasználói csoportot, ahol beállítom a kívánt LDAP szervert, és belerakom azokat a felhasználókat, akiket LDAP-ból szeretnék authentikálni. Users -> User groups -> Create user group:
A tesztelek1 már korábban létre volt hozva, eddig a zabbixban létrehozott jelszóval tudott belépni, mostantól viszont már csak az LDAP-ban beállított jelszóval!
Ez a módszer akkor lehet jó, ha már van egy belakott zabbixod, és nincs nagy felhasználó mozgás (törlés/létrehozás), de mégis szeretnél bizonyos embereket LDAP-ból azonosítani.
2. verzió: alapértelmezett az LDAP azonosítás
Ebben az esetben minden létrehozott felhasználó jelszavát az LDAP-ból szedi. Természetesen itt is van kivétel. Gyárilag létezik egy Internal nevű felhasználói csoport, akinek a tagjai (admin és guest) minden esetben a zabbixtól kapják a jelszót:
Tételezzük fel, hogy minden zabbix felhasználót LDAP-ból authentikálunk, ám van egy vagy több olyan felhasználónk, akik nem részei a céges LDAP címtárnak, mert mondjuk külsős fejlesztők. Őket csak tegyük bele az Internal csoportba, és a zabbix fogja tárolni a jelszavukat. Emiatt van az admin felhasználó is ebben a csoportban, hogyha véletlenül elérhetetlen lenne az LDAP szerver, akkor is be tudjunk lépni a zabbixba, mondjuk átállítani az LDAP szervert egy másikra 🙂
3. verzió: több LDAP szervert akarunk használni
Értelemszerűen több LDAP szervert kell rögzítenünk, amikből lesz egy alapértelmezett. Lehetnek Internal felhasználóink (pl admin, guest), és lehetnek olyan felhasználóink, akik nem az alapértelmezett címtárból jönnek.
Mikor lehet erre szükség? Például akkor, ha a céged egy másik céget felvásárol (vagy fordítva), és a két cég címtára nincs egyesítve. Ilyenkor az 1. verzióban bemutatott felhasználói csoportnál beállítjuk az új cég LDAP szerverét, mindenki mást pedig az alapértelmezett LDAP-ból authentikálunk.
Bemutatom egy képpel az authentikáció menetét
Elnézést az angol szavak miatt, a képet egy zabbix blogról vettem kölcsön.
A felhasználó begépeli a felhasználó nevét és jelszavát, a zabbix ellenőrzi az adatbázisát, ha nincs benne, akkor jön a hibaüzenet. Ha benne van, akkor megkérdezi az LDAP szervertől, hogy jó-e a jelszava. Ha rossz, jön a hibaüzenet. Ha jó, akkor belépteti a felhasználót.
Sokat beszéltem az előnyökről, mik a hátrányok?
- hiába használunk LDAP/AD szervert a felhasználóink authentikációjára, kézzel kell rögzíteni mindenkit a zabbixban, van olyan cégméret, ahol ez már teher lehet
- akiket LDAP-ból authentikálunk, azoknak a zabbix felületén nem lehet jelszót változtatni:
Mi a megoldás?
A korábban említett JIT, ami egy mozaikszó, a Just In Time rövidítése. A zabbix támogatja a just in time kiépítést, amely lehetővé teszi felhasználói fiókok létrehozását a zabbixban, amikor egy külső felhasználó először hitelesíti és létrehozza ezeket a felhasználói fiókokat.
Magyarul, soha többé nem kell kézzel zabbix felhasználót létrehozni. Ha létezik a címtárban, és jól adtuk meg a jelszavát, akkor létrehozza automatikusan a zabbix felhasználót miközben bejelentkezünk a webes felületre.
Ez jól hangzik, hogyan kell beállítani?
Menjünk az Users -> Authentication menüpontra, állítsuk be a Default authentication-t LDAP-ra, vegyük fel a Disabled csoportot a Deprovisioned users group-hoz:
Menjünk az LDAP settings fülre, és pipáljuk be az Enable JIT provisioning opciót:
Nyissuk meg azt az LDAP szervert, ahol ezt a funkciót szeretnénk használni:
- engedélyezzük a JIT kiépítést
- a csoport nevek attribútuma
- a felhasználói csoporttagság attribútuma
- a felhasználónév attribútuma
- a vezetéknév attribútuma
- a felhasználói csoport leképezés
- médiatípus leképezés
Ezekre azért van szükség, mivel a zabbixban már nem veszünk fel felhasználókat, ezért a szükséges adatokat az LDAP-ból fogjuk kiszedni. A 2; 3; 4; 5. pont egyedi attribútum, erre nincs tuti recept, bele kell nézni az LDAP szerverbe a jó megoldás kedvéért. A 6. pontban mondjuk meg, hogy melyik LDAP csoport melyik zabbix csoportnak felel meg, és milyen role tartozik hozzá. Végül a 7. pont felel a média típusok beállításáért (pl email, sms, IM), a példámban a felhasználók email címét veszi ki az LDAP-ból.
Honnan tudjuk, hogy jó attribútumokat állítottunk be?
Mi sem egyszerűbb, végezzünk itt is tesztet, ha rossz adatokat adunk meg, itt is jön a megszokott hibaüzenet:
Ha jó adatokat adunk meg, de rossz valamelyik attribútum (tipikusan a csoport), akkor ezt látjuk:
Mind a három érték üres lesz (No value).
Végül, ha minden rendben van, akkor a felhasználóhoz tartozó értékekkel lesz feltöltve a teszt ablak:
Lépjünk be egy LDAP felhasználóval, aki sosem létezett a zabbixban, majd nézzük meg a zabbix felhasználókat. Én a tesztelek4 nevű felhasználóval léptem be:
A Provisioned oszlop eddig nem tartalmazott adatot, most az a dátum szerepel benne, amikor bekerült a zabbixba a tesztelek4 nevű felhasználó. Alapesetben 1 óra a szinkronizálási idő, azaz, ha törlődik az LDAP-ból a tesztelek4 felhasználó, akkor 1 órán belül a zabbixból is törlődni fog. Legalábbis ezt állítja a szűkszavú dokumentáció.
Ha megnézzük a zabbixban a tesztelek4 felhasználót, pár érdekességet felfedezhetünk:
Már nem csak jelszót nem tudunk változtatni, hanem több fontos dolgot sem, lásd a szürke mezőket.
Bemutatom ennek is a folyamatábráját
A felhasználó begépeli a felhasználó nevét és jelszavát, a zabbix ellenőrzi az LDAP adatbázisát, ha nincs benne, akkor jön a hibaüzenet. Ha benne van, akkor megkérdezi az LDAP szervertől, hogy jó-e a jelszava. Ha rossz, jön a hibaüzenet. Ha jó, akkor ellenőrzi a csoport tagságait. Ha nincs érvényes csoport tagsága, jön a hibaüzenet. Ha van, létrehozza a zabbixban is a felhasználót, majd beengedi a weboldalra..
Mi ennek a módszernek a hátránya?
Sajnos ez sem tökéletes, bár ez nem éppen műszaki jellegű hiba. Abban az esetben, ha nem a zabbix üzemeltetéséért felelős ember/csapat menedzseli a címtárat, előállhat olyan eset, hogy az LDAP/AD üzemeltetője létrehoz magának egy felhasználót, azt beteszi a zabbix-admin csoportba, majd korlátlan hatalma lesz a zabbix felett. Ezt a kockázatot úgy lehet csökkenteni, hogy a zabbix adminokat továbbra is kézzel kezelitek, és nem LDAP-ból veszitek.