LDAP
A Unix/Linux szerverek üzemeltetése wikiből
A lap korábbi változatát látod, amilyen KornAndras (vitalap | szerkesztései) 2010. november 18., 21:52-kor történt szerkesztése után volt.
Írta: Fülöp Balázs és Korn András.
Tartalomjegyzék |
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.
- Abandon: megkezdett művelet (leginkább keresés) megszakítása.
- Unbind: ez viszont már a kapcsolat bontását jelenti (nem a bind ellentettje).
- 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é).
- 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.
- Nincs tranzakciókezelés. Simán elképzelhető, hogy a műveleteink egy része végrehajtódik, más részük pedig nem.
- Azt azért tudni fogjuk, melyek hajtódtak végre.
1.3 Mi az LDIF?
- LDIF: LDAP Data Interchange Format
- Sima szöveges reprezentációja egy vagy több LDAP-címszó kiválasztott attribútumainak.
- Olyasmi, mint egy SQL dump.
- Példa:
dn: cn=wheel,ou=Group,dc=42,dc=hu cn: wheel gidNumber: 9999 objectClass: posixGroup objectClass: groupOfNames objectClass: top memberUid: balazs member: uid=balazs,ou=People,dc=42,dc=hu
- Ez egy wheel nevű csoport leírása.
- Az attribútumok neveiben nem különböztetjük meg a kis- és a nagybetűt (case insensitive).
- Vegyük észre, hogy az RDN-t nem elegendő a DN-ben feltüntetni (a cn szerepel a dn-ben is és az attribútumok között is).
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. Ezért nyilvánvaló, hogy az LDAP-ban is szükség van URL-re.
- 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: portszá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
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.