Reinstalace Openldap v CZ.NIC

Jelikož se na začátku roku objevila „výzva“ reinstalovat LDAP, který nám v CZ.NIC běžel na starším OS, řekl jsem si, že takto zajímavou „challange“ nechci minout. A takto natěšený jsem byl zhruba do doby, než mi došlo, že na stejném serveru běží zřejmě „jako bonus“ Freeradius a Radsecproxy s připojením k Eduroamu. Ten se měl samozřejmě přepisovat také, jelikož se syntaxe mezi verzemi Freeradius v2 a v3 v lecčems změnila. Až teprve nyní jsem pochopil a obdivoval trpělivost lidí, kteří tyto věci v CZ.NIC nastavovali přede mnou a je mi jasné, že si s nimi celkem „užili své“. Ale to je jiná kapitola, tento blogpost má být výhradně o instalaci LDAP. Zdůrazňuji, že tento článek pojednává pouze o základním nastavení LDAP.

LDAP neboli „Lightweight Directory Access Protocol“ je adresářový protokol optimalizovaný pro rychlý přístup k datům. Díky jednoduchosti protokolu, použití adresářové (stromové) struktury a databáze, je možné velmi rychle vyhledávat informace o uživatelích a službách. Data do databáze lze také samozřejmě vkládat, modifikovat je a mazat. LDAP umožňuje centralizovaně udržovat data o uživatelích. Díky tomu lze přistupovat ve všech aplikacích, které LDAP podporují, ke stejným údajům. V Linuxu takto například můžeme úspěšně synchronizovat účty uživatelů napříč systémy.

Každý záznam obsahuje jméno „distinguished name“ neboli DN, kterým je konkretní záznam jedinečný. Pomocí DN je zároveň popsána stromová cesta k záznamu. Pod DN jsou pak sdruženy objekty a hlavně attributy, které tvoří jednotlivé záznamy. Příkladem objektu je objectClass, která definuje typ objektu. Objekty jsou již předefinované pomocí schémat, přičemž je také možně zadefinovat si vlastní. Příkladem attributu může být atribut „DC“, kterým lze popsat např. doména „dc=nic,dc=cz“ nebo attribut „O“ popisující organizační jednotku.

# Entry 1: dc=nic,dc=cz
dn: dc=nic,dc=cz
dc: nic
o: CZ.NIC, z.s.p.o
objectclass: top
objectclass: dcObject
objectclass: organization

Data je možné distribuovat textově ve formě .ldif, binární data v .ldif (například různá jazyková nastavení nebo jiný třeba binární, abych tak řekl, „blob“) se ukládá za pomoci kódování, nejčastěji pomocí base64.

Instalujeme

Instalací balíčku pro Openldap (v Debianu balíček slapd) se LDAP již po instalaci automaticky nastaví. Aby to s konfigurací bylo o maličko složitější, od verze Openldap 2.4.23-3 se LDAP nenastavuje pomocí textového souboru (dříve existoval jeden konfigurační soubor „slapd.conf“), ale pomocí příkazů ldapadd, ldapmodify a .ldif vkládaných přímo do databáze.

S příkazy ldapadd, ldapmodify, můžeme pracovat buď s parametrem EXTERNAL. Takto s ním nakládáme tehdy, když si „hrajeme“ s konfigem, tedy vlastním nastavením DB LDAP. Nebo s právy administrátora (nebo jinými právy v závislosti na ACL). Těch používáme zejména při modifikaci uživatelských dat. Pokud byste chtěli pomocí účtu administrátora měnit hodnoty v samotném konfigu LDAP, lze to také nastavit.

Než se pustíme do konfigurace, měli bychom si vysvětlit, jakým způsobem s LDAP pracovat. Po instalaci LDAP bude člověka určitě zajímat, jaké je jeho aktuální nastavení. Pro „omrknutí“ konfigurace používám nástroj ldapsearch z balíčku „ldap-utils“. S jeho pomocí lze snadno odkrýt nejsvrchnější stromovou strukturu nastavení, abychom se podívali, co vše se v databázi nachází. Příkaz pro ldapsearch, jímž si DN konfigu vypíšeme:

# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config dn

dn: cn=config
dn: cn=module{0},cn=config
dn: cn=schema,cn=config
dn: cn={0}core,cn=schema,cn=config
dn: cn={1}cosine,cn=schema,cn=config
dn: cn={2}nis,cn=schema,cn=config
dn: cn={3}inetorgperson,cn=schema,cn=config
dn: olcBackend={0}mdb,cn=config
dn: olcDatabase={-1}frontend,cn=config
dn: olcDatabase={0}config,cn=config
dn: olcDatabase={1}mdb,cn=config

Jak je vidno, tak v konfiguraci LDAP jsou po instalaci použita čtyři schémata. Pokud by vás zajímalo, jaké moduly LDAP aktuálně používá, není nic jednoduššího, než se „ponořit do hloubek“ konfigů, opět s pomocí ldapsearch. Podobným způsobem můžeme „rozvádět“ a zkoumat i další DN z předcházející stromové struktury do nejmenších detailů. Tak například zjistíme, že v defaultní instalaci LDAP nebyly použity žádné rozšiřující moduly kromě vlastního backendu DB (který, jak je vidno, je také zřejmě modulem, i když ne modulem rozšiřujícím, ale databázovým).

# ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=module{0},cn=config

dn: cn=module{0},cn=config
objectClass: olcModuleList
cn: module{0}
olcModulePath: /usr/lib/ldap
olcModuleLoad: {0}back_mdb

Pomocí ldapsearch nemusíme vypisovat pouze části konfigurací, ale můžete ji samozřejmě vypsat celou. Ale to se vystavujete problému, že zde narazíte na schémata, která působí poněkud nepřehledně. Myslím, že zkoumat schémata LDAP, která definoval někdo jiný, není to, co chcete a ostatně to ani dělat nemusíte.

Podobného účinku o výpis konfigurace lze rovněž docílit nástrojem ‚slapcat‘, jen s tím rozdílem, že ‚slapcat‘ vypisuje opravdu vše, včetně údajů o modifikaci a vytváření záznamů. Příkazu ‚slapcat‘ proto spíše než pro výpis konfigurace využijeme pro zálohování (viz. dále).

ldapsearch -Q -LLL -Y EXTERNAL -H ldapi:/// -b cn=config
slapcat -n 0

Zálohujeme

Předtím než začneme s LDAP pracovat, je výhodné si zálohovat počáteční konfiguraci. Záloha se samozřejmě bude hodit tehdy, pokud si v konfiguraci něco rozvrtáte sami svým zkoušením (třeba nefunkčním .ldif souborem se špatnými hodnotami, například při nastavování replikace – tehdy je potřeba opravdu dávat pozor). Nebo tehdy, když se vám v konfiguraci vrtal někdo jiný s povolenými acl právy. Tehdy se vám určitě budou hodit auditlogy, viz. moduly LDAP, a vše nejlépe replikované někam mimo, kde si všechno dohledáte.

S původní funkční zálohou konfigurace lze „rozložený“ LDAP poměrně rychle opravit. Co se týče záloh, určitě bychom měli zálohovat denně. K různým zálohám nastavení LDAP se samozřejmě potom můžete vracet, nebo si na to postavit rychlý skript.

Záloha konfigurace

Doporučuji si nastavit zálohování konfigurace cronem. Zálohovat bychom určitě měli nastavení samotné databáze i samotná data uživatelů. Slapcat s přepínačem „-n 0“ se vztahuje pro výpis konfigurace, „-n 1 .. n“ pro výpisy uživatelských dat v DB. Ale předpokládám, že používání LDAP pro více domén nebude zase tak častý jev. Záloha je ne-invazivní věc, které se nemusíme vůbec bát, jelikož spočívá v prostém vypsaní databáze a uložení do souboru.

0 7 * * * root slapcat -n 0 -l /path/config_ldap_back_$(date -I)_.ldif
0 7 * * * root slapcat -n 1 -l /path/db_ldap_back_$(date -I)_.ldif

Obnovení ze zálohy

Máme tedy zazálohováno, ještě potřebujeme vědět, jak zálohu obnovit. Dejme tomu, že tedy máme dva soubory. Soubor s konfigem Databáze a soubor s uživatelskými daty. Úplně na začátku obnovíme samotný konfig Databáze, k tomu slouží v LDAP příkaz slapadd, který dělá to samé, jako když jsme zálohu ukládali, jen opačným způsobem. Postupujete takto:

service slapd stop
mv /etc/ldap/slapd.d /etc/ldap/slapd.d-`date -I`
mkdir -p /etc/ldap/slapd.d; chown -R openldap:openldap /etc/ldap/slapd.d/
slapadd -n 0 -F /etc/ldap/slapd.d -l /path/config_ldap_back_$(date -I)_.ldif
chown -R openldap:openldap /etc/ldap/
service slapd start

Uživatelská data v Databazi vratíte takto:

mv /var/lib/ldap /var/lib/ldap-`date -I`
mkdir -p /var/lib/ldap; chown -R openldap:openldap /var/lib/ldap/
# pokud mame povolenou replikaci, pridame jeste "-w"
slapadd -n 1 -F /etc/ldap/slapd.d -l /path/db_ldap_back_$(date -I)_.ldif -w
chown -R openldap:openldap /var/lib/ldap/

Přidáváme ldify

Heslo Administrátora

Někdy se může stát, že přijdeme již k hotovému serveru s Openldap, který nakonfiguroval někdo jiný. Tehdy se hodí vědět, jak změnit heslo administrátora. V prvním kroku si vygenerujeme hash hesla, například pomocí slappasswd (z balíčku ldap-utils). Ideální bude použít trochu silnější heslo, než jsem použil v příkladu.

# slappasswd -h "{SSHA}"
New password:
Re-enter new password:
{SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng

Hash hesla, vložíme do LDAP pomocí tohoto ldif:

# ldapmodify -H ldapi:// -Y EXTERNAL -f passwd.ldif

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcRootPW
olcRootPW: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng

Zda-li je heslo vloženo v pořádku, můžeme ověřit operací ldapsearch (hash hesla by se měl shodovat):

# ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "cn=config" "(olcRootPW=*)"

...
olcRootDN: cn=admin,dc=nic,dc=cz
olcRootPW: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng
...

Takto jsme změnili LDAP heslo v sekci „cn=config“. Teď potřebujeme udělat to samé pro účet admina v DB uživatelských dat. Kdybychom to neudělali, mohlo by platit ještě i staré heslo, použijeme .ldif:

# ldapadd -c -h localhost -Z -f passwd.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_admin_heslo"

dn: cn=admin,dc=nic,dc=cz
changetype: modify
replace: userPassword
userPassword: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng

Certifikáty

Pokud máte LDAP „rozjetý“, asi se budete zajímat, jak vaši komunikaci zabezpečit. Určitě nechcete, aby se vám data „toulala“ po síti jen tak v „plain“ textu, ale šifrovaně. Certifikáty navíc zaručují identifikaci, takže u serveru i klienta byste měli mít jistotu, že nekomunikujete s někým, kdo se za jednu ze stran vydává.

Doporučuji zvolit silnější šifrování, ale ne zase takové, aby to „zabilo“ celé vaše CPU, protože dotazů na LDAP muže přijít spousta v relativně krátkém čase. Do konfigu LDAP jsem přidával certifikáty tímto .ldif, ale můžete použít i jiné nastavení:

# ldapadd -c -Y EXTERNAL -H ldapi:// -f cznic_config_certificate.ldif

dn: cn=config
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/ssl/CZ.NIC2-cacert_sha2.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/ssl/ldap.nic.cz-cert_sha2.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/ssl/ldap.nic.cz-key_sha2.pem
-
add: olcTLSDHParamFile
olcTLSDHParamFile: /etc/ldap/ssl/dhparam

dn: cn=config
changetype: modify
replace: olcLocalSSF
olcLocalSSF: 128
-
replace: olcSecurity
olcSecurity: update_ssf=128 simple_bind=128

V Debianu si ještě nezapomeňte povolit v /etc/default/slapd naslouchání na portu 636 pro ldaps:

SLAPD_SERVICES="ldap:/// ldapi:/// ldaps:///"

ACL

Přesné nastavení ACL, jak ho máme v CZ.NIC, sem bohužel dát nemohu. Nicméně kombinací nastavení ACL lze vytvořit dost a dost. Pokud budete potřebovat podrobnosti, doporučuji dokumentaci. Direktiva práv typicky začíná attributem olcAccess, po němž následuje pořadí ACL pravidla, řetězec k čemu se přistupuje, a nakonec kdo přistupuje (přistupujících může být více a jsou odděleni mezerami). Nebojte se být restriktivní, zrovna u ACL je to potřeba, vyhnete se tak v budoucnu nepříjemnostem. Co se týče uživatelů, lze si vystačit s těmito:

  • Uživatel External – pokud si nějakým nedopatřením smažete práva
  • Uživatel Admin – uživatel, pod kterým budete vkládat data
  • Uživatel Reader – tohoto uživatele budete nastavovat v aplikacích, ze kterých budete potřebovat pouze číst (takže typicky skoro všechny)
  • Ostatní (self, auth, *) – můžete například dovolit uživatelům měnit si heslo

Dovolil jsem si vymyslet alespoň příklad nastavení práv, abych vás o toto téma neochudil, viz. .ldif:

# ldapmodify -c -h localhost -Z -f acl.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_admin_heslo"

dn: olcDatabase={1}mdb,cn=config
changetype: modify
replace: olcAccess
olcAccess: {0}to attrs=userPassword by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=admin,dc=nic,dc=cz" manage by dn="cn=reader,dc=nic,dc=cz" read by self write by anonymous auth by * none
olcAccess: {1}to dn.subtree="dc=nic,dc=cz" by dn.exact="gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth" manage by dn="cn=admin,dc=nic,dc=cz" manage by dn="cn=reader,dc=nic,dc=cz" read by * none
olcAccess: {2}to * by * none

S těmito ACL, by se vám mělo podařit vypsat si uživatele ze skupiny People (lze se ptát také pomocí privilegovaného učtu EXTERNAL):

ldapsearch -Z -h localhost -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo_admina" -b ou=People,dc=nic,dc=cz 'uid=zsobotka'
# ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "dc=nic,dc=cz" 'uid=zsobotka'

Doptat se ldapu na skupiny:

ldapsearch -Z -h localhost -x -D "cn=reader,dc=nic,dc=cz" -w "silne_heslo_uzivatele" -b "dc=nic,dc=cz" '(objectClass=posixGroup)'
# ldapsearch -H ldapi:// -LLL -Q -Y EXTERNAL -b "dc=nic,dc=cz" '(objectClass=posixGroup)'

Nebo být sám sobě schopen změnit heslo:

ldappasswd -Z -h  -x -D "uid=zsobotka,ou=People,dc=nic,dc=cz" -w "puvodni_heslo_uzivatele" -a "puvodni_heslo_uzivatele" -s "nove_heslo_uzivatele"

Logování

Neměli bychom zapomenout na nastavení logování. Číslo u olcLogLevel je součtem příslušných „kódů“, které lze debugovat. Rozumný kompromis „ukecanosti“ logů bych zastavil na čísle 256. Pokud budete chtít debugovat, můžete si troufnout i víc. Zde je .ldif:

# ldapmodify -h localhost -Z -f ./logmodify.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo"

dn: cn=config
changetype: modify
delete: olcLogLevel

dn: cn=config
changetype: modify
add: olcLogLevel
olcLogLevel: 256

Rychlost

Při přechodu na MDB byste neměli mít problém s rychlostí. Oproti HDB backendu se rychlost mnohonásobně zvýšila a mimo jiné konzumuje dvakrát méně systémových prostředků. Pokud by ale vašemu LDAP přece jen „docházel dech“, můžete ho zkusit „vytunnit“ těmito DB parametry.

Writemap – použije se zapisovatelná paměť místo paměti pro čtení, čímž zvyšuje rychlost zápisu. Databázi to ale učiní potenciálně zranitelnou na „korupci dat“, v případě nepředvídaného pádu serveru.

Nometasync – přeskakuje se synchronizace metadat. Tento režim je rychlejší než při plné synchronizaci, ale v případě selhání operačního systému může dojít ke ztrátě poslední transakce.

# ldapmodify -c -Y EXTERNAL -H ldapi:// -f speed.ldf

dn: olcDatabase={1}mdb,cn=config
changetype: modify
add: olcDbEnvFlags
olcDbEnvFlags: writemap
-
add: olcDbEnvFlags
olcDbEnvFlags: nometasync

Moduly

Auditlog

Výhody audit logu jsem již zmiňoval, určitě ho všem doporučuji zapnout. Audit.log automaticky sleduje změny, které se v LDAP provádí, a ukládá je v .ldif formě do zadefinovaného souboru. V logu je vidět timestamp změny události, jméno uživatele a ip adresu, ze které změna přišla. Pokud nastane problém, máte možnost si na něj díky auditlogu „posvítit“; nemusíte se bát, že by Vám něco uniklo. Log soubor můžete navíc replikovat rsyslogem na servery, kde jste zvyklí logy koncentrovat.

# ldapadd -c -Y EXTERNAL -H ldapi:// -f auditlog.ldif

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: auditlog.la

dn: olcOverlay=auditlog,olcDatabase={1}mdb,cn=config
objectClass: olcOverlayConfig
objectClass: olcAuditlogConfig
olcOverlay: auditlog
# chmod 755 /var/log/slapd/; chown openldap:openldap /var/log/slapd/
olcAuditlogFile: /var/log/slapd/auditlog.log

Replikace

Replikace umožňuje synchronizovat databázi s uživatelskými daty pro „speciální okolnosti“. Při pádu jednoho ze serverů se rychle „switchne“ provoz na další server. Na každém ze strojů se nastaví stejné rid, různý provider (ip protilehlého serveru) a rozdílné olcServerID. Pokud jste u LDAP nastavili šifrování, měli byste ho zapnout i u replikace, v .ldif například přes starttls. Další podrobnosti ohledně replikace se dají vysledovat z logů a v dokumentaci.

# ldapmodify -c -Y EXTERNAL -H ldapi:// -f cznic_config_replication.ldif

dn: olcDatabase={1}mdb,cn=config
changetype: modify
#add: olcSyncrepl
replace: olcSyncrepl
olcSyncrepl: rid=001 provider=ldap://xxx.xxx.xxx.xxx bindmethod=simple binddn="cn=admin,dc=nic,dc=cz" credentials="silne_heslo_admina" starttls=yes searchbase="dc=nic,dc=cz" schemachecking=on type=refreshAndPersist retry="30 +" network-timeout=5 timeout=30
-
#add: olcMirrorMode
replace: olcMirrorMode
olcMirrorMode: TRUE
-
#add: olcDbIndex
replace: olcDbIndex
olcDbIndex: entryUUID eq
olcDbIndex: entryCSN eq

dn: cn=config
changeType: modify
add: olcServerID
#Make sure you use different olcServerID's for different servers, in example 0, 1
olcServerID: 0

dn: cn=module{0},cn=config
changetype: modify
add: olcModuleLoad
olcModuleLoad: syncprov

Na obou serverech by měl být správně nastaven uživatel, pod kterým bude replikace probíhat. V příkladu je použit účet admin, ale může být i jiný.

Password policy

Password policy (ppolicy) je modul kontrolující „sílu“ uživatelských hesel. Modul zavadí politiku hesel tak, že nepovolí hesla kratší než předem stanovený počet znaků, písmen a čísel. Pomocí modulu můžeme zajistit, aby uživatel neprotáčel stále stejná hesla. Změněné otisky hesel si modul ukládá do vlastní historie v uživatelské DB.

Těchto modulů lze dohledat vice, v LDAP jsem použil modul PqChecker. Domovská stránka projektu je zde. Pokud jste odvážní, můžete ho zkusit zkompilovat. Ale lepší bude stáhnout si rovnou instalační balíček. Ten rozbalí modul „ppolicy.so“ přímo do příslušné cesty. Hodnoty chování ppolicy se nastavují v uživatelské DB, třeba tímto .ldif..

Nastavení zavedení modulu:

# ldapmodify -c -Y EXTERNAL -H ldapi:// -f "pwd_policy01.ldif"

dn: cn=module{0},cn=config
add: olcModuleLoad
olcModuleLoad: ppolicy.so

Nastavení configu pro modul (předtím je ještě potřeba nahrát príslušné schéma z /etc/ldap/schema/ppolicy.ldif):

# ldapadd -c -Y EXTERNAL -H ldapi:// -f "pwd_policy02.ldif"

# ppolicy jeste nastavit v mdb, req. - melo by byt zavedeno schema -> /etc/ldap/schema/ppolicy.ldif
dn: olcOverlay=ppolicy,olcDatabase={1}mdb,cn=config
objectClass: olcPPolicyConfig
olcPPolicyDefault: cn=default,ou=policies,dc=nic,dc=cz

Nastavení parametrů pro tento modul (je už přímo v databázi). Pokud máte například nainstalovaného PhpLdapAdmina, můžete parametry ppolicy měnit přímo tam.

# ldapadd -Z -h localhost -f pwd_policy03.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo"

dn: ou=policies,dc=nic,dc=cz
objectClass: organizationalUnit
objectClass: top
ou: policies

dn: cn=default,ou=policies,dc=nic,dc=cz
cn: default
objectClass: top
objectClass: device
objectClass: pwdPolicy
objectClass: pwdPolicyChecker
pwdAllowUserChange: TRUE
pwdAttribute: userPassword
pwdCheckQuality: 2
pwdCheckModule: pqchecker.so
pwdFailureCountInterval: 300
pwdGraceAuthNLimit: 5
pwdInHistory: 10
pwdLockout: TRUE
pwdLockoutDuration: 180
pwdMaxFailure: 10
pwdMinAge: 0
pwdMinLength: 8

Uživatelská data

Zmiňoval jsem, že databáze uživatelů našeho LDAP čítá přes 12 let historie. Proto když jsem pro potřeby CZ.NIC LDAP instaloval, nepotřeboval jsem vytvářet DB novou, ale použil jsem to, co zde již dávno bylo. Protože však nechci tento blogpost ochudit o to nejzajímavější, přidávám příklad initu s uživatelskými daty.

# ldapadd -Z -h localhost -f user.ldif -x -D "cn=admin,dc=nic,dc=cz" -w "silne_heslo"

dn: dc=nic,dc=cz
dc: nic
o: CZ.NIC, z.s.p.o
objectClass: top
objectclass: dcObject
objectclass: organization

## FIRST Level hierarchy - People
dn: ou=People,dc=nic,dc=cz
ou: People
description: All people in nic.cz
objectClass: top
objectClass: organizationalUnit

# Test user
dn: cn=nstanciu,ou=People,dc=nic,dc=cz
objectClass: person
objectClass: inetOrgPerson
cn: nstanciu
gn: Nicolae
sn: Stanciu
uid: nstanciu
# heslo
userPassword: {SSHA}UVT5FQnKmCoq2X0qXWa7/dw3r+MPHQng
mail: nicolae.stanciu@nic.cz
description: The Example

## FIRST Level hierarchy - Group
dn: ou=Group,dc=nic,dc=cz
ou: Group
description: All groups in nic.cz
objectClass: top
objectClass: organizationalUnit

## FIRST Level hierarchy - Hosts
dn: ou=Hosts,dc=nic,dc=cz
ou: Hosts
description: All hosts in nic.cz
objectClass: top
objectClass: organizationalUnit

O ldapu CZ.NIC

LDAP provozujeme v CZ.NIC spoustu let, za tu dobu byl samozřejmě v rámci obměny software několikrát reinstalován. S reinstalací našeho LDAP se váže jeho přenesení do Ansiblu, respektive napsání role pro něj. Tím snad jeho reinstalaci usnadníme pro další cyklus obměny. V našem tiketovacím systému se nejstarší zmínka o LDAP datuje zhruba 12 let zpět. Je ale možné, že zde je ještě déle. I po tak dlouhé době se ale nedá říci, že je náš LDAP v CZ.NIC co do objemu nějak rozsáhlý. Uživatelských účtů máme zhruba do 200, velikost nacachované databáze je cca 1Gb a počet akceptovaných připojení se denně pohybuje kolem 50 000 dotazů.

Pokud Vás zajímá, co lze v LDAP mít, můžu obecně shrnout, co používáme my. Máme zde samozřejmě definované uživatele včetně jejich skupin. Ve skupinách jsou lidé samotní, sdružené skupiny lidí jsou definované ve vlastních skupinách prostřednictvím memberUid. Kerberos nepoužíváme, takže hesla jsou zahashovaná přímo v DB. Kromě uživatelů, zde máme také hesla schránek našeho mail serveru. Protože naši uživatelé používají Eduroam wifi, máme zde definované servisní skupiny pro Radius, které uživatele třídí do VLAN odpovídajících oddělení, ve kterých pracují a které Freeradius vůči LDAP ověřuje. Pak jsou zde data týkající se Samby, ppolicy modulu, kalendářové účty zasedacích místností SOGo kalendáře a nakonec testovací účty.

Pro replikaci LDAP používáme typ mirror (v našem případě nejsou více než dva LDAP servery potřeba). V případě pádu jednoho ze serverů se ip adresy přepínají na záložní server pomocí Ucarp. Co se týče schémat navíc, máme zde schémata Samby, Radius, SOGa (SOGo Resource Configuration) a PPolicy.

Jako GUI pro rychlé procházení, mazaní a přidávání triviálních věcí, se nám osvědčil dnes už zřejmě nevyvíjený (ale stále funkční) PhpLdapAdmin. Zbylé věci řešíme v rámci našich skriptů, tj. přidávání uživatelů, skupin, změny hesel a dalších věcí, které se vkládají do uživatelské DB pomocí .ldif.

Z ostatních služeb je na LDAP navázané téměř vše, od loginů do systémů a systémových group, přes interní systém pro zaměstnance, až po zaintegrované externí aplikace jako třeba Jabber, kalendářové řešení a mnoho dalších.

Autor:

Zanechte komentář

Všechny údaje jsou povinné. E-mail nebude zobrazen.