OpenLDAP telepítése (Wheezy)

Innen: AdminWiki

Ebben a leírásban az OpenLDAP szervert "általános használatra" telepítjük. Directory backend sokféle célra használható; pl. adatbázis háttérként fájlszerver, levelező szerver vagy hálózatvezérlő számára, vagy akár általános single sign-on authentikációs címtár megvalósításaként. Mindezekhez az OpenLDAP egy adatbázis réteget biztosít, melynek telepítése és beállítása bizonyos mértékig független a konkrét felhasználástól.

Az LDAP elméleti alapjairól ld. ezt a wikilapot: LDAP alapok

Telepítés

A házirend szerint telepített és beállított szervergépre az OpenLDAP szervert (slapd) Debian csomagból telepítjük:

apt-get install slapd ldap-utils # + unixodbc(!) + könyvtárak

A telepítő kér egy jelszót az LDAP adminisztrátor (valójában az első, felhasználói címtár adminisztrátora) számára. Relatív erős, véletlen jelszót pl. a

pwgen -n -s -c 12 1

paranccsal generálhatunk. A csomagtelepítést követően a /usr partíciót írhatóan csatoljuk újra:

mount -o remount,rw /usr

és töltsük le, majd könyvtárhelyesen tömörítsük ki a legutóbbi kiadású openldap-addons.tgz csomagot! A csomag jelenleg a következőket biztosítja:

  • openldap-dump script az OpenLDAP szerver konfigurációjának és felhasználói adatbázisainak mentésére;
  • a fenti scriptet napi egyszeri alkalommal lefuttató cronjob.

A telepítést követően csatoljuk vissza a /usr partíciót read-only módban:

mount -o remount /usr

Beállítások

Egy OpenLDAP szerver több, egymástól független DIT alfát megvalósító címtárat kezelhet, és az adatbázis-kezelésre különböző backendeket használhat. A telepítő két címtárat hoz létre:

  • egy konfigurációs címtárat (database #0) az LDAP szerver saját beállításai számára, LDIF backenddel;
  • egy általános célú, felhasználói címtárat (database #1) HDB (hierarchical database, a Berkeley database módosítása) backenddel, amelynek gyökere egy Organisation osztályú csomópont lesz dn: dc=MYDOMAIN, dc=ORG azonosítóval (a használt domain nevet a hostname -d kimenetéből véve), és amelyben egyetlen gyermek elem van, az LDAP adminisztrátort reprezentáló simpleSecurityObject, organizationalRole osztályú dn: cn=admin, dc=MYDOMAIN, dc=ORG azonosítójú elem.

Ebben a leírásban elsősorban az LDAP szerver saját beállításaival foglalkozunk, a felhasználói címtárat egyelőre békén hagyjuk.

Kezelőfelület

Az OpenLDAP jelenlegi verziójában a slapd konfigurációja már nem a /etc/ldap/slapd.conf beállító állományban található, hanem egy LDIF backend-ű LDAP adatbázisban (ez a "nullás" adatbázis, amely logikailag a cn=config base DN alatt érhető el, fizikailag a /etc/ldap/slapd.d alatti könyvtárszerkezet *.ldif állományaiban lakik - ezekre az állományokra a fájlrendszerben csak az openldap:openldap Linux felhasználónak és csoportnak van írási és olvasási joga). A telepítő ezt az adatbázist (címtárat) automatikusan létrehozza és kezdeti értékekkel is feltölti.

Az adatbázisban tartott konfiguráció lehetővé teszi, hogy alkalmas LDAP klienssel (akár grafikus felületen, táveléréssel), a szervergépre történő konzolos belépés nélkül is lehessen módosítani az LDAP kiszolgáló beállításait (amennyiben a beállítás nem igényli a slapd újraindítását), de a konfigurációs adatbázist kezelhetjük és módosíthatjuk hagyományosabb módon, parancssori eszközökkel is.

Parancssoros kezelés

Ebben a leírásban az LDAP szerver konfigurációját parancssorból, root-ként fogjuk elvégezni, nagyjából úgy, mintha a /etc/ldap/slapd állományban szerkesztenénk; csak nem szövegszerkesztőt használunk, hanem LDAP kezelő segédprogramokat.

A csomagból telepített OpenLDAP konfigurációs adatbázisában szerepel az alábbi ACL bejegyzés:

dn: olcDatabase={0}config,cn=config
[...]
olcAccess: {0}to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
[...]

amely teljes írási-olvasási hozzáférést biztosít ehhez az adatbázishoz a root (uid=0, gid=0) Linux felhasználónak. Emiatt a root-ként kiadott

ldapsearch -b "cn=config" -QY EXTERNAL -H ldapi:/// [...]  # Keresés a cn=config adatbázisban (Linux felhasználóként authentikálva)
ldapadd    -QY EXTERNAL -H ldapi:/// -f [...]              # Hozzáadás adatbázishoz (Linux felhasználóként authentikálva)
ldapmodify -QY EXTERNAL -H ldapi:/// -f [...]              # Módosítás adatbázisban (Linux felhasználóként authentikálva)
ldapdelete -QY EXTERNAL -H ldapi:/// -f [...]              # Törlés adatbázisból (Linux felhasználóként authentikálva)

parancsok minden külön jelszókérés nélkül lefutnak. Példaképpen a teljes konfigurációt (LDIF formában, kommentek nélkül - ld. -LLL paraméter) az alábbi paranccsal listázhatjuk ki:

ldapsearch -b "" -s base + -LLL -QY EXTERNAL -H ldapi:/// | less  # Root DSE (dn=""), minden attribútum
ldapsearch -b "cn=config"  -LLL -QY EXTERNAL -H ldapi:/// | less  # Konfigurációs adatbázis

A parancssoros kezelésre ezeket a segédprogramokat úgy fogjuk használni, hogy a konkrét módosításokat egy-egy ideiglenes LDIF állományban írjuk le, és a szükséges add/modify/delete parancsot root-ként, ezzel az ideiglenes állománnyal, mint -f [...] paraméterrel fogjuk meghívni. Ügyeljünk az alábbi formázási szabályokra:

  • az LDIF állománynak nem szabad üres sorral kezdődnie;
  • az állományon belül az elválasztóként alkalmazott üres sor új objektumot kezd (így egy LDIF-fel több objektum is módosítható);
  • a sor elején egyetlen "-"-et tartalmazó elválasztó sor ugyanazon objektum többszörös adatmódosítását jelzi;
  • a sor eleji egyetlen(!) space folytatósort jelöl.

Grafikus kezelőfelület

Ez a rész kihagyható, ha nem kívánjuk távolról, grafikus kezelőfelületen konfigurálni magát az LDAP szervert (a grafikus felület kényelmesebb lehet a manuálisan megírt LDIF-ek használatánál). Ez a rész a felhasználói címtárak (amelyeket az LDAP szerver szolgáltatni fog) esetleges távelérésére nem vonatkozik, azt később fogjuk beállítani.

A címtár(ak), így a konfigurációs adatbázis adatainak kezelése elvégezhető különböző grafikus felületet nyújtó kliensprogramokkal is (ingyenes és szabad szoftver LDAP kliensek pl. Windows alatt az LDAPAdmin, Linux desktop környezetben a GQ client vagy a LUMA). Mivel a szervergépen grafikus felület nincsen, ezeket távoli kliensgépen fogjuk futtatni, és az LDAP szerverhez valamilyen (TCP/IP) távelérést engedélyezünk.

TCP/IP account beállítása

Mivel a parancssori kezelésnél említett hozzáférés a root Linux felhasználó számára TCP/IP-n nem engedélyezett, szükséges valamilyen, a cn=config címtárhoz teljes hozzáférést biztosító authentikáció. Telepítéskor ugyan létrejön az erre alkalmas cn=admin,cn=config LDAP adatbázis account:

dn: olcDatabase={0}config,cn=config
[...]
olcRootDN: cn=admin,cn=config

azonban alapértelmezésben nincs hozzá jelszó beállítva. Készítsünk egy random jelszót (szöveges és SSHA hash formában) pl. az alábbi parancsokkal:

PW=$(pwgen -n -s -c 12 1); echo $PW; slappasswd -s $PW -h {SSHA}; PW=  # Nem kerül a history-ba, csak a képernyőre :-)

tCVXD2E63mmH
{SSHA}M4Zoa7pJd06DZm0L4Ke5tPloC0a+MSsA

Jegyezzük fel a szöveges jelszót, majd egy ideiglenes LDIF állományban írjuk elő ennek használatát a {0}config,cn=config adatbázis root jelszavaként (ügyeljünk a generált hash pontos bemásolására (NE használjuk a példa adatait!):

mcedit /root/tmp/ldap-mod.ldif

dn: olcDatabase={0}config,cn=config
changetype: modify
add: olcRootPW
olcRootPW: {SSHA}M4Z[...]SsA

Hajtassuk végre a módosítást és ellenőrizzük, hogy bekerült-e a konfigurációs adatbázisba:

ldapmodify -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-mod.ldif

# Ellenőrzés: olcRootPw szerepel, értéke a hash
ldapsearch -b "cn=config" -LLL -QY EXTERNAL -H ldapi:/// -s one "olcDatabase={0}config"

# Ha sikeres, ez már nem kell
rm  /root/tmp/ldap-mod.ldif

Ezután már TCP/IP protokollal is tudunk lekérdezéseket futtatni. Próbaképpen ismételjük meg a fenti lekérdezést a localhoston, TCP/IP protokollal és az imént beállított authentikációval:

ldapsearch -b "cn=config" -LLL -D "cn=admin,cn=config" -W -h localhost -s one "olcDatabase={0}config"

A feljegyzett jelszó begépelése után az előzővel megegyező eredményt kell látnunk. A fenti típusú TCP/IP lekérdezéseket a root-tól különböző Linux felhasználók is sikeresen végre tudják hajtani, akár táveléréssel is.

Távelérés beállítása

A táveléréshez védett belhálózat esetén a tűzfalon engedélyezzük a titkosítatlan LDAP forgalmat, egyébként állítsunk be valamilyen védett, titkosított hozzáférést. A grafikus kliensen a kapcsolódás paramétereit az alábbiak szerint állítsuk be:

base DN:      cn=config
felhasználó:  cn=admin,cn=config
jelszó:       A fentebb beállított jelszó szöveges formában

Siker esetén az alábbiakhoz hasonló képernyőképeket kaphatunk (rákattintva teljes méretű):

SSH-tunnelezett LDAP cn:config hozzáférés, Ubuntu 12.04 LTS + gSTM + LUMA
Fájl:Ldapadmin-tunnel-config.png
SSH-tunnelezett LDAP cn:config hozzáférés, Windows 7 + PuTTY + LDAPAdmin


Naplózás beállítása

A konfigurációs adatbázisban a naplózás szintjét (olcLogLevel) emeljük none-ról stats-ra. Ehhez készítsünk egy LDIF állományt:

mcedit /root/tmp/ldap-mod.ldif

dn: cn=config
changetype: modify
replace: olcLogLevel
olcLogLevel: stats

Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):

ldapmodify -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-mod.ldif
ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(cn=config)" olcLogLevel

dn: cn=config
olcLogLevel: stats

rm /root/tmp/ldap-mod.ldif

Megjegyzés: a slapd tevékenységének naplózása általában nem szükséges (a monitorozást másképpen oldjuk meg), de hasznos lehet hibakutatás esetén. Üzemszerű használat esetén a terjedelmes logolás a teljesítményt leronthatja (mint pl. a mysqld esetén), így production környezetben a naplózást a beüzemelés után kikapcsolhatjuk.

Alapértelmezésben a slapd üzenetei a logcheck által ellenőrzött /var/log/syslog-ba mennek - ezt célszerű megváltoztatni, és a slapd számára külön logot definiálni. Ehhez szerkesszük meg a /etc/syslog-ng/syslog-ng.conf állományt, és írjunk elő egy külön destination-t az LDAP szerver által használt local4 facility naplózására:

-rw-r--r-- root root /etc/syslog-ng/syslog-ng.conf

[...]
##############
# Destinations
##############
[...]
# OpenLDAP slapd separate logging
destination d_ldap
    { file ("/var/log/ldap/slapd.log" owner(root) group(adm)); };

[...]
##############
# Filters
##############
[...]
# OpenLDAP slapd separate logging
filter f_ldap
    { facility(local4); };

[...]     
#############
# Log paths
#############
[...]
# OpenLDAP slapd separate logging
log { source(s_src); filter(f_ldap); destination(d_ldap); flags(final); };

[...]

Készítsük el az új logok könyvtárát:

mkdir -m 750 /var/log/ldap

és a változtatásokat a syslog-ng és a slapd újraindításával érvényesítsük:

/etc/init.d/syslog-ng restart; /etc/init.d/slapd restart; tail -f /var/log/ldap/slapd.log

Láthatjuk, hogy az LDAP szerver újraindításáról már csak az új logba került bejegyzés. Gondoskodjunk az új log(ok) rotálásáról:

-rw-r--r-- /etc/logrotate.d/ldap

/var/log/ldap/*.log {
    daily
    rotate 7
    compress
    missingok
    create 0640 root adm
}

Logcheck módosítások

Az OpenLDAP futása során normálisan is keletkező logsorokat érdemes kivenni a logcheck kimenetéből.

  • DIGEST-MD5 common mech free üzenetek

Egy hiba miatt a localhost-ról, root-ként kiadott lekérdezéseink a fenti hibasort írják a /var/log/auth.log-ba; ezeket érdemes teljesen kiszűrni:

touch /etc/logcheck/ignore.d.server/openldap-addons
chown root:logcheck /etc/logcheck/ignore.d.server/openldap-addons
chmod 640 /etc/logcheck/ignore.d.server/openldap-addons
mcedit /etc/logcheck/ignore.d.server/openldap-addons
-rw-r----- root logcheck /etc/logcheck/ignore.d.server/openldap-addons

^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ ldap[[:alnum:]]+:( \[ *[[:digit:]]+\.[[:digit:]]+\])? DIGEST-MD5 common mech free
^\w{3} [ :[:digit:]]{11} [._[:alnum:]-]+ slap[[:alnum:]]+:( \[ *[[:digit:]]+\.[[:digit:]]+\])? DIGEST-MD5 common mech free

TODO!

A slapd bejegyzése a Tiger által ismert démonok közé

A slapd-nek állandóan futnia kell, valamint jogosan figyel a 389-es és (SSL esetén) a 636-os tcp portokon. Mindezek ellenőrzésére az alábbi módosításokat jegyezzük be a /etc/tiger/tigerrc állományba:

-rw------- root root /etc/tiger/tigerrc

[...]
Tiger_Listening_ValidUsers='[...]|openldap'
[...]
Tiger_Listening_ValidProcs='[...]|slapd'
[...]
Tiger_Running_Procs='[...] /usr/sbin/slapd'

Az LDAP lekérdezések átengedése a bástyagép tűzfalán

Ha az OpenLDAP szerver csak helyi (localhost) használatban van, illetve ha minden lekérdezés SSH tunnelen vagy VPN-en keresztül történik, akkor az LDAP forgalmat külön nem kell a bástyagép tűzfalán átengedni. Ha közvetlen LDAP forgalom szükséges, akkor azt mind a bejövő, mind a kimenő szabályok között engedélyezzük az érintett zóna (általában a trusted belhálózat - trs) felé:

-rw-r----- root root /etc/shorewall/rules

[...]
# RULES HANDLING INCOMING CONNECTIONS
[...]
# Public services
[...]
#LDAP/ACCEPT    trs    fw
LDAPS/ACCEPT    trs    fw
[...]

# RULES HANDLING OUTBOUND CONNECTION
[...]
#LDAP/ACCEPT    fw      trs
LDAPS/ACCEPT    fw      trs
[...]

A beállítást a tűzfal újraindításával érvényesítsük:

invoke-rc.d shorewall restart

Titkosított hozzáférés

Tekintettel arra, hogy az LDAP alapértelmezésben titkosítatlan kommunikációt használ, a localhoston kívüli hozzáféréseket ajánlatos titkosított csatornán lebonyolítani. Ennek egyik módja a forgalom SSH tunnelezése - ez a megoldás az alkalmazástól lényegében független -, a másik lehetőség az alkalmazásszintű TLS/SSL titkosítás és az ldaps protokoll (TCP: 636) használata.

  • Az SSH tunnel a szerver oldalon kényelmesebb (mert az LDAP beállításokkal, kulcsgenerálással, stb. nem kell külön foglalkozni) és kicsit biztonságosabb, mert a tunnel kiépítéséhez (azaz ahhoz, hogy egyáltalán eljusson a szolgáltatásig) a kliensnek kulccsal kell rendelkeznie - kulcs hiányában még esetleges OpenLDAP exploitokkal sem lehet megtámadni a szolgáltatást. A kliens használata azonban kényelmetlenebb, mert valamilyen külső alkalmazással kell megnyitni és fenntartani a tunnelt.
  • Az LDAPs használata esetén szükség van szerver oldali kulcsgenerálásra (és -frissítésre), viszont a kliensen külső alkalmazást futtatni nem kell, a titkosítás az LDAP démon és kliens "belügye".

Interneten keresztüli hozzáférésre illetve adminisztrációra inkább az SSH-tunnelt érdemes használni (véd az exploitok ellen), valamelyest védett helyi hálózati lekérdezésekre az LDAPs protokollt (gyorsabb, kliens oldalon egyszerűbb, de mégsem lehallgatható). Titkosítatlan LDAP lekérdezést csak a localhoston vagy teljesen izolált hálózat (pl. elzárt helységben közvetlenül összekötött szervergépek) esetén, illetve izolált környezetben történő tesztelésnél engedélyezzünk.

LDAPs szolgáltatás beállítása

Ez a rész kihagyható, ha nem használunk LDAPs szolgáltatást!

A kiszolgáló hitelesítéséhez szükségünk lesz egy (self-signed) kiszolgáló tanúsítványra. Ehhez lépjünk be egy átmeneti könyvtárba (pl. /root/tmp) és adjuk ki az alábbi parancsokat:

cd /root/tmp
export DAYS=360 FQHN="FULLY.QUALIFIED.HOSTNAME" 
echo $FQHN $DAYS # Biztos, ami biztos :-)

openssl genrsa -out $FQHN.key 1024 # Private key
chmod 600 $FQHN.key

openssl req -new -key $FQHN.key -out $FQHN.csr # Aláírandó tanúsítvány - töltsük ki az alábbiak szerint:
#   Country Name (2 letter code) [AU]:HU
#   State or Province Name (full name) [Some-State]:Budapest
#   Locality Name (eg, city) []:Budapest
#   Organization Name (eg, company) [Internet Widgits Pty Ltd]:MY COMPANY
#   Organizational Unit Name (eg, section) []:Directory Services
#   Common Name (eg, YOUR name) []:FULLY.QUALIFIED.HOSTNAME
#   Email Address []:sysadmin@MYDOMAIN
#   Extra attributumok üresen hagyhatóak.

openssl x509 -req -days $DAYS -in $FQHN.csr -signkey $FQHN.key -out $FQHN.crt # Írassuk alá
mv $FQHN.crt $FQHN.pem # Nevezzük át

A kitöltésnél ügyeljünk arra, hogy a FQHN egyezzen meg a tanúsítvány Common Name mezejével! Ezzel létrehoztunk egy egy évig érvényes self-signed tanúsítványt. Adjuk ezt az openldap user és group tulajdonába és másoljuk a /etc/ldap könyvtárba:

chown openldap:openldap $FQHN.pem; cp $FQHN.pem /etc/ldap/$FQHN.pem 
chown openldap:openldap $FQHN.key; cp $FQHN.key /etc/ldap/$FQHN.key
# Ezek már nem kellenek
rm $FQHN.csr $FQHN.key $FQHN.pem

Írjuk elő a slapd számára a tanúsítvány használatát - ehhez készítsünk egy LDIF állományt a cn=config objektum számára:

mcedit /root/tmp/ldap-mod.ldif

dn: cn=config
changetype: modify
add: olcTLSCACertificateFile
olcTLSCACertificateFile: /etc/ldap/FQHN.pem
-
add: olcTLSCertificateFile
olcTLSCertificateFile: /etc/ldap/FQHN.pem
-
add: olcTLSCertificateKeyFile
olcTLSCertificateKeyFile: /etc/ldap/FQHN.key

Figyelem: ne felejtsük el a FQHN behelyettesítését!

Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):

ldapmodify -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-mod.ldif

ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(olcDatabase={1}hdb))" | less

rm /root/tmp/ldap-mod.ldif

Írjuk elő továbbá, hogy a slapd titkosítás nélkül csak a localhoston figyeljen (TCP:389), minden más forrás felől csak titkosítva (TCP:636 illetve Un*x socketként):

-rw-r--r-- root root /etc/default/slapd

[...]
SLAPD_SERVICES="ldap://127.0.0.1:389/ ldaps:/// ldapi:///"
#SLAPD_SERVICES="ldap:/// ldapi:///"
[...]

A beállításokat a slapd újraindításával érvényesítsük:

invoke-rc.d slapd restart

és ellenőrizzük a figyelést:

netstat -tanu | grep -e "\(:389\|:636\)"

tcp        0      0 0.0.0.0:636             0.0.0.0:*               LISTEN     
tcp        0      0 127.0.0.1:389           0.0.0.0:*               LISTEN     
tcp6       0      0 :::636                  :::*                    LISTEN

Ellenőrizzük a TLS/SSL kapcsolódást az alábbi paranccsal, amely sikeres kapcsolódás esetén megjeleníti többek között a szervertanúsítvány adatait is:

openssl s_client -connect localhost:636 -showcerts

CONNECTED(00000003)
[...]
    Verify return code: 18 (self signed certificate)

Klienssel kapcsolódás - nem megy...

SSH tunnelezés előkészítése

Ez a rész kihagyható, ha nem használunk SSH tunnelezést!

Tunnelezés esetén a kapcsolódás előtt a kliens authentikál a szerveren (többlet biztonság), az adatforgalmat a tunnel védi a lehallgatás ellen, és a tűzfal beállításokat sem kell módosítani, mert a forgalom az egyébként engedélyezett SSH porton keresztül halad.

A tunnelt kizárólag kulccsal (PPK authentikációval) fogjuk megnyitni az openldap helyi (Linux rendszer-) felhasználó nevében; ehhez készítsük elő az elfogadott publikus kulcsokat tároló állományt:

mkdir -m 700 /var/lib/ldap/.ssh
chown openldap:openldap /var/lib/ldap/.ssh
touch /var/lib/ldap/.ssh/authorized_keys2
chown openldap:openldap /var/lib/ldap/.ssh/authorized_keys2
chmod 400 /var/lib/ldap/.ssh/authorized_keys2
chattr +i /var/lib/ldap/.ssh/authorized_keys2

A távoli hozzáférést egy grafikus LDAP klienssel felszerelt, a telepítés alatti szervert SSH-n elérő gépen ki is próbálhatjuk. Ehhez készítsünk egy (lehetőleg erős jelszóval védett) DSA kulcspárt, és a publikus kulcsot (az immutable bit átmeneti levétele után) másoljuk a /var/lib/ldap/.ssh/authorized_keys2 állományba.

Szükség esetén (pl. PuttyGen által készített kulcsnál) a kulcsot konvertáljuk OpenSSH formátumba:

ssh-keygen -i -f putty_kulcs >openssh_kulcs.pub

A kulcs elején helyezzük el az alábbi korlátozásokat:

-r-------- openldap openldap /var/lib/ldap/.ssh/authorized_keys2

[...]from="IP.IP.IP.IP",command="/bin/false",no-pty,no-X11-forwarding,no-agent-forwarding,no-port-forwarding,permitopen="127.0.0.1:389",permitopen="localhost:389" ssh-dss AAAA[...] opcionalis_comment

Ezzel a kulcs használatát a 389-es port továbbítására korlátoztuk. A from korlátozás elhagyható, ha a kliens számára nincs állandó IP címünk.

Nyissuk meg a kliensgépen a tunnelt egy helyi port (pl: local:10389) és a távoli hoston a localhost:389 összerendelésével, ezután tesztképpen a

telnet localhost 10389 # vagy amelyik portot megadtuk

paranccsal kapcsolódhatunk az LDAP szerverhez, illetve a grafikus kliensprogramban szerverként a localhost:10389 megadásával a címtárban valódi LDAP műveleteket végezhetünk.

SSH-tunnelezett GQ LDAP kliens beállítása Ubuntu desktopon
PuTTY és LDAPadmin kliens beállítása Windows környezetben

Sikeres teszt esetén ne felejtsük el visszazárni a /var/lib/ldap/.ssh/authorized_keys2 állományt:

chattr +i /var/lib/ldap/.ssh/authorized_keys2

Monitorozás

Az OpenLDAP szerver rendelkezik egy olyan modullal (monitor backend, back_monitor), amelyik lehetővé teszi a használati statisztikák és teljesítményadatok gyűjtését és lekérdezését; ezen kívül figyelhetjük közvetlenül a backend adatbázis teljesítménymutatóit illetve a vonatkozó TCP/IP kapcsolatok paramétereit. Mindezeket alkalmas Munin pluginokkal tehetjük áttekinthetővé.

A monitor használatához:

  • be kell töltenünk a back_monitor modult;
  • engedélyeznünk kell a monitor adatbázist;
  • célszerű létrehozni egy, a monitor adatbázishoz dedikáltan hozzáférő auditor felhasználót.

TODO!

A monitor modul betöltése

Készítsünk egy LDIF állományt, amely a konfigurációs adatbázisban előírja a modul betöltését:

mcedit /root/tmp/ldap-add.ldif

# Load monitoring backend module
dn: cn=module,cn=config
objectClass: olcModuleList
cn: module
olcModulepath: /usr/lib/ldap
olcModuleLoad: back_monitor

Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):

ldapadd -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-add.ldif
ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b cn=config "(|(cn=config)(objectClass=olcModuleList))" | less

rm /root/tmp/ldap-add.ldif

A monitor adatbázis elkészítése

A monitor adatbázis nem valódi címtár, hanem egy frontend, amely az OpenLDAP szerver aktuális állapotjelzőit címtár formában prezentálja, így ehhez az adatbázishoz csak olvasható hozzáférést lehet kiadni. Meggondolandó, hogy az OpenLDAP szerver állapotába betekintést engedünk-e mindenkinek, aki egyébként képes lekérdezést futtatni ezen a szerveren, vagy korlátozzuk ezt a lehetőséget. Ebben a leírásban csak a root Linux felhasználónak és egy speciális, jelszóval védett LDAP adatbázis accountnak (cn=auditor,cn=monitor) fogunk ilyen jogosultságot kiadni. Ez utóbbi számára készítsünk egy random jelszót (szöveges és SSHA hash formában) pl. az alábbi parancsokkal:

PW=$(pwgen -n -s -c 12 1); echo $PW; slappasswd -s $PW -h {SSHA}; PW=  # Nem kerül a history-ba, csak a képernyőre :-)

WVDPZLYJL8NY
{SSHA}+OjMch4VxNcORw4iljLt1ZUdroIiNzos

Jegyezzük fel a szöveges jelszót, majd készítsünk egy LDIF állományt, amely létrehozza az adatbázist és beállítja a fenti jogosultságokat. Ügyeljünk a generált hash pontos bemásolására (NE használjuk a példa adatait!):

mcedit /root/tmp/ldap-add.ldif

# Create monitoring database
dn: olcDatabase=monitor,cn=config
objectClass: olcDatabaseConfig
olcDatabase: monitor
# Actually commented: read access to everyone - use with caution!
#olcAccess: to dn.base="" by * read
# Full (technically r/o) access for Linux root
olcAccess: to * by dn.exact=gidNumber=0+uidNumber=0,cn=peercred,cn=external,cn=auth manage by * break
# Full (technically r/o) access for an LDAP account.
RootDN: cn=auditor,cn=monitor
RootPW: {SSHA}+Qj[...]zos

Futtassuk le és ellenőrizzük az eredményt (siker esetén az LDIF állomány törölhető):

ldapadd -QY EXTERNAL -H ldapi:/// -f /root/tmp/ldap-add.ldif
ldapsearch -LLLQY EXTERNAL -H ldapi:/// -b "cn=config" "(olcDatabase=monitor)"

rm /root/tmp/ldap-add.ldif

Monitor gyorsteszt

Az alábbi lekérdezések megfelelően authentikálva terjedelmes monitor kimenetet, névtelenül pedig hibaüzenetet eredményeznek.

ldapsearch -LLL -QY EXTERNAL -H ldapi:/// -b "cn=monitor" + "*" | less                   # root Linux felhasználóként
ldapsearch -LLL -D "cn=auditor,cn=monitor" -W -h localhost -b "cn=monitor" + "*" | less  # megfelelő LDAP database accounttal, jelszóval
ldapsearch -LLL -x -h localhost -b "cn=monitor" + "*"                                    # anonym lekérdezésre: No such object

Megjegyzés: amennyiben a konfigurációs adatbázis (pl.grafikus felületen történő) távelérését állítottuk be, ugyanezen a kapcsolaton keresztül a monitor távlekérdezése is megvalósítható az alábbi beállításokkal:

base DN:      cn=monitor
felhasználó:  cn=auditor,cn=monitor
jelszó:       A fentebb beállított jelszó szöveges formában

Munin beállítása a monitor adatbázishoz

A Munin működéséhez szükségesek a libnet-ldap-perl és munin-plugins-extra csomagok:

apt-get install libnet-ldap-perl munin-plugins-extra # ha még nem lennének telepítve

A Munin plugin bekapcsolásához linkeljük a munin-plugins-extra csomaggal települő slapd_ plugint, és másoljuk át a hozzá tartozó beállító állományt:

ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_statistics_bytes
ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_connections
ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_operations
ln -s /usr/share/munin/plugins/slapd_ /etc/munin/plugins/slapd_waiters

A Munin számára hozzáférést kell adnunk a monitor adatbázishoz. A szükséges adatokat egy beállító állományban adjuk meg a /etc/munin/plugin-conf.d könyvtárban. Mivel ez az állomány jelszót tartalmaz, a könyvtárban szokásos jogosultságokat szigorítva csak a munin group számára tesszük olvashatóvá:

touch /etc/munin/plugin-conf.d/slapd
chown root:munin /etc/munin/munin/plugin-conf.d/slapd
chmod 640 /etc/munin/plugin-conf.d/slapd
mcedit /etc/munin/plugin-conf.d/slapd

Állítsuk be a lekérdezésre jogosult LDAP database account paramétereit:

-rw-r----- root munin /etc/munin/plugin-conf.d/slapd

[slapd_*]
    env.binddn cn=auditor,cn=monitor
    env.bindpw SZÖVEGES_JELSZÓ

majd indítsuk újra a munin-node-ot:

invoke-rc.d munin-node restart

Gyorstesztként a szokásos módon, telnet-tel ellenőrizzük a telepített pluginok lekérdezhetőségét.

A Berkeley adatbázis backend monitorozása

TODO!

TCP/IP kapcsolatok monitorozása

TODO!

OpenLDAP mentés beállítása

Jelenleg az OpenLDAP mentéseket a helyi gépen készített, időzített (ldapsearch illetve slapcat alapú) LDIF dumpokkal valósítjuk meg, szükség szerint ezeket távoli gépekre Amanda taskok viszik el (természetesen bármilyen más file backup rendszer is használható). A mentések a teljes konfigurációt (a frontend és monitor adatbázisok kivételével) és a teljes felhasználói adattartalmat felölelik, napi rendszerességgel, automatizálva készülnek (a Debian ettől függetlenül menti a /var/lib/ldap könyvtárat is, ez azonban bináris formátum; pl. költöztetés esetén az LDIF talán jobban használható).

A mentéshez szükséges scriptet és cronjobot az openldap-addons tarball-lal már telepítettük, illetve létrehoztuk a /var/backups/openldap könyvtárat is. A napi mentés tesztképpen történő lefuttatásához (root-ként) adjuk ki az alábbi parancsot:

/usr/local/sbin/openldap_dump /var/backups/openldap >>/var/log/ldap/openldap-dump.log 2>&1

és ellenőrizzük, hogy a /var/backups/openldap könyvtárban létrejött-e a mentés, illetve nézzünk bele a /var/log/ldap/openldap-dump.log naplóba is.

Az openldap_dump script használható egyes (sorszámukkal hivatkozott) adatbázisok (root-ként végzett) manuális lementésére is, pl. az alábbi parancsok:

cd /root/tmp        # Munkakönyvtár
openldap_dump 0 .   # Konfigurációs adatbázis
openldap_dump 1 .   # Az első felhasználói címtár

külön-külön mentik a konfigurációs adatbázist (database #0) és az első felhasználói címtárat (database #1) az aktuális munkakönyvtárba. A script minden adatbázisról két dumpot is megkísérel elkészíteni: egyet a slapcat használatával az erre alkalmas adatbázisok esetén (bdb vagy hdb backend-űek, illetve a konfigurációs adatbázis), egyet pedig az ldapsearch használatával (ha a database suffix meg van adva). Ha egyik metódus sem használható, nem készül dump, és figyelmeztetést kapunk.

Replikáció

Master szerepkör beállítása

Slave szerepkör beállítása

Karbantartási feladatok

Irodalom