LDAP
A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
a (→Ajánlott irodalom: fölös ENTER) |
(→Mit tartalmaz a séma?: még az OIDról) |
||
44. sor: | 44. sor: | ||
* NB2: az RDN-t nem elegendő a DN-ben feltüntetni |
* NB2: az RDN-t nem elegendő a DN-ben feltüntetni |
||
− | === Mit tartalmaz a séma? === |
+ | === Mi a séma? === |
* a '''séma''' osztályok és attribútumok definíciója |
* 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 |
** kicsit olyasmi, mint a relációs adatbázisok "sémája": mezők és típusaik vannak megadva |
||
61. sor: | 61. sor: | ||
*** 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) |
*** 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) |
||
*** egy entitás tetszőlegesen sok kiegészítő objectClassba tartozhat |
*** egy entitás tetszőlegesen sok kiegészítő objectClassba tartozhat |
||
− | ** minden objectClassnak van egy ún. OID-je, ami egy számokból és pontokból álló globálisan egyedi azonosító (ezért sem egyszerű saját objectClass-t csinálni) |
+ | ** minden objectClassnak és attribútumnak van egy ún. OID-ja, ami egy 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. |
||
* egy címszónak legalább egy strukturális osztály kötelező attribútumaival rendelkeznie kell |
* egy címszónak legalább egy strukturális osztály kötelező attribútumaival rendelkeznie kell |
||
* az osztályok között van '''öröklődés''' |
* az osztályok között van '''öröklődés''' |
A lap 2008. január 26., 00:16-kori változata
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ár egy fa (directory tree), azaz egy gyökér csomóponttal rendelkező körmentes gráf
- a gráf csomópontjai a címszavak (entries), melyeknek sémától függően vannak kötelező és opcionális attribútumaik
- 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)
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 - ritkán használt, amióta támogatott az SSL feletti LDAP
- Bind: autentikáció - bizony nem a csatlakozás, az anoním keresések enélkül működnek
- 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
- RDBMS adminok gondoljanak egy SQL dump-ra (mivel gyakorlatilag egy dump egy keresés eredményeiről)
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?
- 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
- a séma adja meg:
- milyen objectClassok léteznek
- az egyes osztályokba (objectClass) tartozó entitásoknak milyen attribútumai lehetnek, és ezek közül melyik kötelező
- az attribútumok milyen típusúak
- az egyes attribútumok értékeinek összehasonlításkor legyen-e különbség a kis- és nagybetűk között
- vannak absztrakt (abstract), strukturális (structural) és kiegészítő (auxiliary) osztályok
- absztrakt: az LDAP alapvető struktúrájához tartozik; pl. top (nincsenek a felhasználó számára érdekes tulajdonságai)
- strukturális: alapvető tulajdonságcsoportokat tartalmaz, amelyek általában logikailag kizárják egymást
- pl. person vagy posixGroup - nem lenne értelme, hogy ugyanaz az entitás mindkét osztályba beletartozzon
- ezért egy entitás egyszerre pontosan egy strukturális objectClassba tartozhat
- 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)
- egy entitás tetszőlegesen sok kiegészítő objectClassba tartozhat
- minden objectClassnak és attribútumnak van egy ún. OID-ja, ami egy 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.
- egy címszónak legalább egy strukturális osztály kötelező attribútumaival rendelkeznie kell
- 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 tartalmaz információt
- egy attribútumnak lehetnek álnevei (pl. cn ugyanaz, mint a commonName)
- az attribútumok lehetnek binárisak (pl. jpegPhoto), ilyenkor az LDIF 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
- 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.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 (2008. elején még ki nem adott) 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
- 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
- gyorsabbak a válaszidők
- 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 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
- NB1: ha azt szeretnénk, hogy a sima passwd parancs megváltoztassa a jelszavakat az LDAP adatbázisban, 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/ldap.secret fájlba (mód: 0600, de akkor 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 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.4 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 prezentáció az LDAPról; olvasva is érthető