LDAP

A lap 2010. november 18., 21:30-kori változata

Írta: Fülöp Balázs és Korn András.

1 Mi az LDAP?

• LDAP: Leightweight Directory Access Protocol
• L, mint pehelysúlyú: az X.500 kódnevű protokollcsalád könnyített változata. Az eredeti X.500-at az OSI hálózati modelljére tervezték, így a való életben nem sűrűn találkozhatunk vele.
• D, mint címtárszolgáltatás: elsősorban egy számítógépes hálózat felhasználóit és erőforrásait tartalmazó adatbázis közvetítésére szolgál
• A, mint elérés: támogatja az adatok frissítését, törlését, beszúrását és lekérdezését
• P, mint az elektronikus kommunikáció egyik nyelve: egy TCP/IP felett megvalósított bináris protokoll

1.1 Miből áll egy LDAP-on elérhető címtár?

• A címtárban tárolt bejegyzések egy fát képeznek (directory tree), azaz egy gyökércsomóponttal rendelkező körmentes gráfot.
• A gráf csomópontjai a címszavak vagy bejegyzések (entries), amelyeknek sémától függően vannak kötelező és opcionális attribútumaik.
  • Minden csomópont egy-egy címszó; a közbülsők is és a levelek is.
• A sémák határozzák meg, milyen típusú bejegyzéseket vehetünk fel egyáltalán, és melyiknek milyen attribútumai lehetnek (l. később).
• Minden csomópont rendelkezik egy kitüntetett attribútummal, amely azonosítja a csomópontot a vele egy szinten, közös szülőtől származó csomópontok között - ez az RDN (relative distinguished name).
• A csomópontból a gyökérbe vezető út RDN-jei kiadják a csomópont megkülönböztető nevét - ez a DN (distinguished name).
• Az attribútumok lehetnek többértékűek (ezt is a séma határozza meg).
  • A többértékű attribútum olyan, amiből több is lehet ugyanannak a címszónak (pl. egy embernek lehet több emailcíme, vagy csoportnak több tagja).
• NB: a fa csomópontjai nem objektumok abban az értelemben, ahogyan az objektumorientált programozásnál használják ezt a szót, mert nem társíthatunk hozzájuk műveleteket.

1.2 Milyen műveleteket engedélyez az LDAP?

• Start TLS: titkosítás nélkül indított csatornán titkosított kommunikáció kezdeményezése
• Bind: autentikáció - bizony nem a csatlakozás, az anonim keresések során nem kerül sor bind műveletre
• Search: keresés - lásd később
• Compare: összehasonlítás - nem egy attribútum értékét kérdezzük le, hanem elküldünk egy értéket és megkérdezzük, hogy azzal (vagy annak a jelszó hash-ével) egyezik-e
• Add: új címszó hozzáadása
• Delete: címszó törlése
• Modify entry: címszó attribútumlistájának módosítása
• Modify DN: címszó átnevezése - ez nekem OpenLDAP alatt csak levél típusú csomópontra működött, és annál is csak RDN-re
• Abandon: megkezdett művelet megszakítása
• Unbind: ez viszont már a kapcsolat bontását jelenti (nem a bind ellentettje)
• NB1: egy LDAP kapcsolat során egy kliens több kérést küldhet a szervernek, és a kérések között nem kötelessége megvárni a szerver válaszát (enélkül az abandon értelmét is veszítené)
• NB2: a szerver semmilyen sorrendiséget nem garantál egy válaszon belül az abban szereplő címszavakra, az attribútumaikra, többértékű attribútum esetén az értékekre
• NB3: igen, tényleg hiányzik a tranzakciókezelés

1.3 Mi az LDIF?

• LDIF: LDAP Data Interchange Format
• sima szöveges leírása egy vagy több LDAP címszó kiválasztott attribútumainak
• olyasmi, mint egy SQL dump

dn: cn=wheel,ou=Group,dc=42,dc=hu
cn: wheel
gidNumber: 9999
objectClass: posixGroup
objectClass: top
memberUid: balazs

• ez egy wheel nevű csoport leírása
• NB1: az attribútumok neveiben nem különböztetjük meg a kis- és a nagybetűt (case insensitive)
• NB2: az RDN-t nem elegendő a DN-ben feltüntetni

1.4 Mi a séma?

1.4.1 Bevezetés

• A séma osztályok és attribútumok definíciója.
  • Kicsit olyasmi, mint a relációs adatbázisok "sémája": mezők és típusaik vannak megadva.
  • A mezők (attribútumok) között lehet kötelező és opcionális.
  • Szép formális szintaxis írja le, hogy az egyes attribútumok milyen típusú adatot tárolnak (pl. szám vagy szöveg),
  • és azt, hogy melyik bejegyzésfajtának (osztálynak) milyen attribútumokkal kell rendelkeznie, ill. melyek megengedettek még.
• A bejegyzéstípus neve: objectClass.
  • A létező objectClassok típusát a séma határozza meg.
  • Háromféle objectClass létezik: strukturális (structural), kiegészítő (auxiliary) és absztrakt (abstract).
  • Minden csomópontnak pontosan egy strukturális objectClass-ba kell tartoznia, de lehet tetszőlegesen sok kiegészítő objectClass-ja is (ennek akkor van értelme, ha olyan attribútumokat is szeretnénk hozzá társítani, amelyeket a strukturális objectClass nem tartalmaz).
  • Az absztrakt objectClassok az LDAP alapvető struktúrájához tartoznak, és nincsenek a felhasználó számára érdekes tulajdonságaik (ilyen pl. a "top" objectClass).
    • Ilyen az alias is, ami a DNS CNAME-jének a helyi megfelelője
  • Strukturális objectClass: alapvető tulajdonságcsoportokat tartalmaz, amelyek általában logikailag kizárják egymást.
    • Pl. inetOrgPerson vagy groupOfNames - nem lenne értelme, hogy ugyanaz az entitás mindkét osztályba beletartozzon.
  • Kiegészítő objectClass: csak bizonyos felhasználás számára hasznos új attribútumokat tartalmaz.
    • Pl. a shadowAccount és a posixAccount olyan kiegészítései az account-nak, amik akkor hasznosak, ha unixos felhasználók adatait akarjuk tárolni a címtárban (pl. innen lesz uidNumber, userPassword és shadowLastChange attribútumunk).
  • Minden objectClassnak és attribútumnak van egy ún. OID-ja, ami egy szabványosító testület által kiadott, számokból és pontokból álló globálisan egyedi azonosító (ezért sem egyszerű saját objectClass-t csinálni).
    • Igazából az OID azonosítja az egyes mezőket; nevük csak a megjegyezhetőség érdekében van, és gyakran ugyanahhoz az OID-hoz több név is tartozik. Pl. a userid és az uid név is a 0.9.2342.19200300.100.1.1-es OID-hoz tartozik.
    • Az OID-rendszer teszi lehetővé, hogy a protokoll bináris legyen és mégis együtt tudjanak működni egymással a különböző gyártók LDAP-ot használó termékei.

1.4.2 Részletek

• Az osztályok között van öröklődés.
• Egy attribútum leírása a típusra, formátumra és az illeszthetőség vizsgálatára nézve tartalmaz információt.
  • Pl. megadható, van-e rendezés az attribútum lehetséges értékei között; az uidNumber és a gidNumber pl. ugyan numerikus, de sajnos nem rendezett attribútum, így nem tudjuk egyszerűen megtalálni mondjuk az 1000-nél kisebb UID-val rendelkező felhasználókat.
• Egy attribútumnak lehetnek álnevei (pl. a cn ugyanaz, mint a commonName).
• Az attribútumok lehetnek binárisak (pl. jpegPhoto), ilyenkor az LDIF (l. fent) base64 kódolt változatukat tartalmazza.
• Az objectClass-ok és attribútumok nevei globálisan egyediek (ne azzal kezdjük, hogy sajátot hozunk létre).
  • pl. az inetOrgPerson osztály, amit előszeretettel alkalmaznak személyek leírásához:
  • 2 kötelező attribútummal bír: cn és sn (surname); mindkettőt a person osztálytól örökölte.
  • Opcionális attribútumai: audio, businessCategory, carLicense, departmentNumber, description, destinationIndicator, displayName, employeeNumber, employeeType, facsimileTelephoneNumber, givenName, homePhone, homePostalAddress, initials, internationaliSDNNumber, jpegPhoto, l, labeledURI, mail, manager, mobile, o, ou, pager, photo, physicalDeliveryOfficeName, postOfficeBox, postalAddress, postalCode, preferredDeliveryMethod, preferredLanguage, registeredAddress, roomNumber, secretary, seeAlso, st, street, telephoneNumber, teletexTerminalIdentifier, telexNumber, title, uid, userCertificate, userPKCS12, userPassword, userSMIMECertificate, x121Address, x500uniqueIdentifier.

1.5 Mi az LDAP URL?

• ha egy protokoll nem támogatja az URL-t (unified resource locator) az erőforrások (jelen esetben címszavak) azonosítására, akkor sokkal nehezebb eladni a menedzsmentnek
• csomópontok egy halmazát lehet vele kiválasztani

proto://host:port/DN?attributes?scope?filter?extensions

• proto: ldap, vagy ldaps (LDAP+SSL)
• host: DNS név vagy IP cím
• port: port szám, opcionális (alapértelmezés ldap esetén 389, ldaps esetén 636)
• DN: a keresés kiindulópontjának megkülönböztető neve
  • A DN, mint Distinguished Name, amúgy is fontos fogalom: a címtárban tárolt entitások bármelyikét egyértelműen azonosítja a DN-je. Konstrukciója: az entitás "bázisát" (pl. ou=People,dc=42,dc=hu) egészítsük ki egy olyan attribútummal, amely az adott bázis kontextusában egyértelműen azonosíthatóvá teszi a konkrét entitást (pl. cn=Gipsz Jakab,ou=People,dc=42,dc=hu).
  • Az RDN (Relative DN) az az attribútum, ami egy adott kontextusban egyértelműen azonosít egy entitást. A fenti példában pl. a CN ilyen, mert az ou=People,dc=42,dc=hu alatt (közvetlenül) nem lehet két cn=Gipsz Jakab.
    • Az RDN lehet összetett; ha pl. a cn és a relatedDomain együttesen teszi egyedivé a bejegyzést, akkor a DN lehet mondjuk cn=Gipsz Jakab+relatedDomain=fenchurch.42.hu,ou=People,dc=42,dc=hu. Ebben az esetben a fenchurch.42.hu-hoz és mondjuk a traal.42.hu-hoz tartozhat két különböző Gipsz Jakab.
• attributes: meglepő módon az attribútumok listája, opcionális
• scope: base, ha pontosan egy címszót keresünk; one, ha a DN-ben megadott csomópont közvetlen gyermekei között keresünk; sub, ha egy részfában keresünk - NB: az, hogy melyik az alapértelmezés, implementáció-függő; opcionális
• filter: ez egy keresési szűrő (lásd később), opcionális
• extensions: minden, ami az RFC-ből kimaradt (ja igen, opcionális)

1.6 Hogyan keressünk az LDAP segítségével?

• mivel az LDAP-ot címtárak elérésére fejlesztették, legjobban a kereséseket támogatja (igazából minden más igen körülményes vele)
• telepítsünk egy LDAP klienst - Debian alatt az ldap-utils csomag tartalmazza az OpenLDAP kliensoldali segédprogramjait
• mivel a legtöbb LDAP kliens implementáció az RFC-ben leírt URL formátumot nem támogatja, gyorsan felejtsük el a fentebb ismertetetteket és nézzünk utána a manual-ban a paraméterezésnek

$ ldapsearch -LLL                                         \
             -H ldaps://localhost/                        \
             -b 'ou=People,dc=42,dc=hu'                   \
             -s sub                                       \
             -x                                           \
             '(&(objectClass=inetOrgPerson)(uid=balazs))' \
             mail                                         \
  | grep '^mail:'
mail: ifj.fulop.balazs@42.hu

• -LLL: a legszűkszavúbb, kommentmentes LDIF formátumot kérjük
• -H: LDAP URI megadása (nem URL!)
• -b: a keresés kiindulópontja
• -s: a keresés hatóköre
• -x: SASL nélkül kapcsolódunk
• filter: minden szűrő zárójelek között, logikai operátorok prefix jelöléssel
• attribútumok: egyszerűen, szóközzel elválasztva
• a végén azért áll egy grep, mert a parancs kimenete tartalmazza a DN-t, amire most nem volt szükség

1.7 Skálázható?

• megvalósítástól függ (nyilván alapvetően nem a protokollon múlik a skálázhatóság, hanem a szerveralkalmazáson)
• az OpenLDAP támogatja a master - slave replikákat és a 2.4-es verziótól a multimaster üzemmódot is
  • a korábbi verziókkal is összegányolható a multimaster működés, de a fejlesztők kifejezetten ellenjavallottnak tartják
  • a 2.4-es verzió multimaster működésének leírása egyelőre (2008. január végén) hiányzik az amúgy mostanra elég jónak mondható dokumentációból; helyette az LDAP weekly newsban olvashatunk róla
• felmerülhet a kérdés, hogy érdemes-e minden gépre slave-et rakni - ez jó lehet, mert:
  • tehermentesíti a központi szervert (a keresések és lekérdezések tekintetében)
  • rövidebbek a válaszidők (mivel nem lép fel hálózati késleltetés)
  • ki kell próbálni ;-)

1.8 Végülis mikor jó ez az egész?

• ha az adatbázisműveletek döntő többsége keresés jellegű ÉS
• nincs szükség tranzakciókra ÉS
• adatbázis szinten akarjuk szabályozni a felhasználók hozzáférését (lásd később) ÉS
• nincs szükség idegen kulcsokra és komoly kényszerekre (constraint) VAGY
• ha marhára unatkozunk

2 Hogyan használjuk az OpenLDAP-ot központi konfigurációhoz?

• szükség van egy LDAP szerverre mindenféle *-ldap csomagokra, és sok-sok szkriptelésre

2.1 Hogyan állítsuk be az OpenLDAP szervert?

• Debian alatt a slapd csomag tartalmazza
• konfiguráció: /etc/ldap/slapd.conf

# This is the main slapd configuration file. See slapd.conf(5) for more
# info on the configuration options.

#######################################################################
# Global Directives:

# Schema and objectClass definitions
include         /etc/ldap/schema/core.schema
include         /etc/ldap/schema/cosine.schema
include         /etc/ldap/schema/nis.schema
include         /etc/ldap/schema/inetorgperson.schema
include         /etc/ldap/schema/authldap.schema

# Schema check allows for forcing entries to
# match schemas for their objectClasses's
# Ez az opció eltűnt az OpenLDAP 2.4-ben; alighanem ez lett a default
#schemacheck     on

# ...

TLSCACertificateFile    /etc/ldap/certs/cert.pem
TLSCertificateFile      /etc/ldap/certs/cert.pem
TLSCertificateKeyFile   /etc/ldap/certs/key.pem

sizelimit unlimited

# ...

#######################################################################
# Specific Directives for database #1, of type bdb:
# Database specific directives apply to this databasse until another
# 'database' directive occurs
database        bdb

# The base of your directory in database #1
suffix          "dc=42,dc=hu"

# ...

# Indexing options for database #1
index           objectClass eq
index           cn eq
index           uid eq
index           mail eq
index           dc eq

# ...

access to dn.sub="ou=DNS,dc=42,dc=hu"
        by dn="cn=admin,dc=42,dc=hu" write
        by dn="cn=dnsadmin,ou=system,dc=42,dc=hu" read
        by * none

• fent látható, hogyan kell megadni a tanúsítványt és a privát kulcsot az SSL-es eléréshez
• sizelimit unlimited: ha ezt nem adjuk meg, és az alapértelmezés szerinti 500 találatnál többet tesz ki a felhasználóink száma, egy egyszerű getent passwd nem adja meg a felhasználók teljes listáját
• index: mindenképpen készítsünk a gyakrabban lekérdezett attribútumokhoz indexet, különben egy határon túl nagyon lassú lesz a keresés. Ha utólag adunk meg itt egy indexet, futtassuk a slapindex parancsot az indexek legenerálásához.
• access: ACL-ekkel adhatjuk meg akár címszó szinten, hogy ki mihez fér hozzá - itt egy dnsadmin nevű felhasználó kapott olvasási jogot a DNS részfához
• a fent megadott tanúsítványt akkor használja a slapd, ha megfelelő paraméterrel indítjuk. Ehhez Debian alatt a /etc/default/slapd fájlban adjuk meg a következőt:

SLAPD_SERVICES="ldaps:///"

• érdemes még a /etc/ldap/ldap.conf-ban a kliensek alapértelmezéseit beállítani, így nem kell minden esetben nagyon hosszú paraméterlistát adni az ldapsearch-nek:

BASE    dc=42,dc=hu
URI     ldaps://localhost/
TLS_REQCERT never

• a tanúsítvány-ellenőrzést csak akkor kapcsoljuk ki, ha előfordulhat, hogy az valamiért nem sikerül (pl. loopback interfészen szeretnénk elérni a szervert, és a tanúsítvány CN mezője nem localhost-ot tartalmaz ;-) - jó, belenyúlhatnánk a DNS-be is...)

2.2 Hogyan állítsuk be a központi autentikációt?

• állítsuk be az NSS-t és a PAM-ot - Debian alatt a libnss-ldap és a libpam-ldap csomagokra lesz szükség
• a libnss-ldap egy kész konfigurációval örvendeztet minket (/etc/libnss-ldap.conf), az ncurses varázsló után csak az SSL-t kell beállítani:

#host 127.0.0.1
uri ldaps://127.0.0.1/

• itt érdemes IP címet használni, ha lehet, hogy az NSS ne végezzen névfeloldást
• a /etc/nsswitch.conf fájlt így módosítsuk:

passwd:         files ldap
group:          files ldap
shadow:         files

• a libpam-ldap gyakorlatilag ugyanazt a konfigurációs fájlt használja, csak egy másik példányban (/etc/pam_ldap.conf) - nem baj, ezt is átírjuk:

#host 127.0.0.1
uri ldaps://127.0.0.1/

• végezetül a /etc/pam.d/common-* fájlokat kell módosítani, az alábbi séma szerint:

auth    [success=1 default=ignore]      pam_unix.so     nullok_secure
auth    required                        pam_ldap.so     use_first_pass
auth    required                        pam_permit.so

• a fentit meg kell írni az account, password és session szekciókra is
• NB2: opcionálisan telepíthetünk nscd-t (Name Service Cache Daemon), így az NSS nem fordul minden kéréssel az LDAP szerverhez
• ha minden jól megy és nem felejtettem ki semmit, innentől működik a központi hitelesítés

2.3 Hogyan változtathatják meg a felhasználók a saját jelszavukat?

• Az ldappasswd nem erre való (a látszat ellenére). (Hogy miért nem, az rejtély.)
• Használhatjuk a sima passwd parancsot is, és az majd a PAM segítségével módosítja a jelszót az LDAP-ban.
• A /etc/pam.d/common-password file-ba írjunk valami ilyesmit:

password        sufficient      pam_ldap.so
password        required        pam_unix.so nullok obscure md5

• Hogy miért nem megy az auth-tal analóg módon, az egyelőre nem világos.
• A /etc/pam_ldap.conf fájlban meg kell adni egy felhasználót, aki az összes jelszót képes módosítani, és az ő jelszavát le kell tenni a /etc/pam_ldap.secret és a /etc/libnss-ldap.secret fájlba (mód: 0400, de akkor is...)
• Szintén a pam_ldap.conf-ba írjuk be azt, hogy pam_password exop - ettől a PAM az OpenLDAP által támogatott "password change extended operation" segítségével változtatja meg a jelszót, aminek az a hatása, hogy a jelszót nem plaintextben, hanem hash-elve fogja tárolni az LDAP.
• Jó kérdés, hogy mindezt hogyan befolyásolja, ha SASL-t is használunk, márpedig az OpenLDAP-os dokumentációk eléggé efelé próbálják terelni az embert;
  • viszont látszólag SASL esetén plaintextben kellene tárolni a jelszavakat a szerveroldalon, állítólag azért, hogy az autentikcáció ne legyen érzékeny a lehallgatásra.
  • Ez minket persze nem érint, hiszen úgyis SSL-t használunk, úgyhogy jó nekünk a plaintext autentikáció és a hash-elt jelszó. (A tévedés jogát fenntartom.)

2.4 Hogyan tegyük a DNS-t LDAP-ba?

• 2 lehetőség:
  • olyan DNS szervert használunk, amely alapból támogatja, vagy patchelt Bind9-ünk van
  • körbeszkripteljük a Bind9-et
• az utóbbi a kevésbé triviális, és meg kellett oldanom, íme
• Google: ldap2dns
• letöltés után fordítsuk, telepítsük, az ldap2dns.schema fájlt pedig másoljuk be az LDAP schema könyvtárába, adjuk meg a slapd.conf-ban és indítsuk újra a slapd-t
• írjuk meg azt a szkriptet, ami az LDAP fából ki fogja bányászni a DNS információt, és legenerálja a zónafájlokat:

#!/bin/bash

LDAP2DNS="/usr/bin/ldap2dns"
BINDINIT="/etc/init.d/bind9"
BINDCACHE="/var/cache/bind"

temp=`mktemp -d`
cd "$temp"

"$LDAP2DNS"                              \
  -D "cn=dnsadmin,ou=system,dc=42,dc=hu" \
  -w "talaneztmegseiromide"              \
  -b "ou=DNS,dc=42,dc=hu"                \
  -o "db"                                \
  -H "ldaps://localhost/"

"$BINDINIT" "stop"
rm -f "$BINDCACHE/*"
mv * "$BINDCACHE"
"$BINDINIT" "start"

cd /
rmdir "$temp"

• készítsük el a cn=dnsadmin,ou=system,dc=42,dc=hu felhasználót talaneztmegseiromide jelszóval
• az ou=DNS,dc=42,dc=hu részfa alatt helyezzük el a zónáinkat
• a zónák adminisztrálására kiválóan alkalmas a phpldapadmin

Fájl:ldapadmin.png

2.5 Kikkel működik még?

• Postfix: jól működik és egyszerűen telepíthető az LDAP modulja - az alias-tól az autoBcc-ig mindent LDAP-ba tehetünk
• AMaViS: támogatja az LDAP-ot, felhasználónként lehet a vírus-ellenőrzést be- és kikapcsolni, a fekete- és fehérlista már nem működik (pedig a dokumentáció alapján kellene)
• Samba: a samba.schema telepítése után a sambaSamAccount megvalósításával a személyekhez eltárolhatók a sambaLMPassword és a sambaNTPassword mezők (arra nem jöttem rá, hogy az Samba-nak miért van szüksége két hash-re) - de még ezután is nagyon macerás a beállítása
• Apache: egy nagyon szerény tudású LDAP modullal a VirtualHost-ok kitehetők LDAP-ba - de a DocumentRoot-on kívül ne akarjunk állítgatni semmit...

3 Végezetül

• az LDAP jó dolog, ha az adatbázison végzendő műveletek atomiak, és a keresések vannak túlsúlyban, de...
• ...egy jótanács: soha ne mappelj relációs sémát LDAP-ra ;-)
• egy másik: a rendszerusereket mindig hagyd meg a /etc/passwd-ben, mert:
  • miért legyen mysql felhasználó olyan gépen, ahol nincs mysql szerver?
  • ha egyik gépen letörlöd a mysql-t, és a csomagkezelő viszi a felhasználót is, az miért legyen hatással a többi gépre?

4 Ajánlott irodalom

• ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf - ez egy elég részletes tutoriál-prezentáció az LDAPról; olvasva is érthető (kicsit zavaró, hogy "principal" helyett következetesen "principle"-t ír; ettől vonatkoztassunk el :)

• LDAP Authentication on Debian Sarge HOWTO - kicsit régi HOWTO, de legalább rövid. :) Megtudhatjuk belőle, hogyan bírhatjuk működésre a chsh-t és a chfn-t.

• LDAP for Rocket Scientists - egy online könyv arról, hogy hogy is működik az LDAP (főként az OpenLDAP), mi mire jó benne és mire érdemes használni. Sokkal jobban használható, mint az OpenLDAP saját dokumentációja.