malere@yahoo.com
v1.09, 2004.03.05
Verziótörténet | ||
---|---|---|
Verzió: 1.09 | 2004.03.05 | |
OpenLDAP 2.2 és általános javítások. | ||
Verzió: 1.08 | 2003.04.02 | |
SASL, DIGEST-MD5 hitelesítéssel. | ||
Verzió: 1.07 | 2002.09.16 | |
Szedési javítások. | ||
Verzió: 1.06 | 2002.07.17 | |
Áttérés a Docbook XML standard formátumra, a szöveg teljes felülvizsgálata. OpenLDAP 2.1 bemutatása. | ||
Verzió: 1.05 | 2001.06.22 | Átdolgozta: lepm |
Megoldás a "hosszú sorok" problémára (a doksi PDF formában szétcsúszott). | ||
Verzió: 1.04 | 2001.02.28 | Átdolgozta: lepm |
Tipográfiai javítások, és a "Roaming Access", "Azonosítás LDAP segítségével" fejezetek frissítése. | ||
Verzió: 1.03 | 2000.09.28 | Átdolgozta: lepm |
Az OpenLDAP 2.0 bemutatása, ami már az LDAP v3-at tartalmazza, idevágó szabvány: RFC2251 | ||
Verzió: 1.02 | 2000.09.13 | Átdolgozta: lepm |
Szöveg javítások, új fejezet a "Verziótörténet". | ||
Verzió: 1.01 | 2000.02.15 | Átdolgozta: lepm |
Új fejezetek az "LDAP migrációs eszközök", "Azonosítás LDAP használatával", "Grafikus LDAP eszközök", "RFC-k" | ||
Verzió: 1.00 | 1999.06.20 | Átdolgozta: lepm |
A legelső változat. |
Ez a dokumentáció a Linux operációs rendszeren LDAP (Lightweight Directory Access Protocol) szerver telepítéséről, konfigurálásáról és üzemeltetéséről szól. Részletesen leírja, hogyan lehet létrehozni LDAP adatbázist, miként frissíthetők és törölhetők az információk az adatbázisban. Ez a dokumentáció leginkább a University of Mitchigan LDAP információs oldalai és az OpenLDAP adminisztrátorok kézikönyve alapján készült.
Ez a dokumentum az LDAP szerver telepítésének és használatának leírása Linux operációs rendszeren. Tartalmazza, hogyan telepíthető, konfigurálható, és üzemeltethető az LDAP szerver, és ezek után hogyan tárolhatók, kereshetők és frissíthetők adatok az adatbázisban, LDAP kliensek és segédprogramok használatával. Az LDAP címtár szolgáltatást nyújtó démont slapd-nek hivják, és sok különböző Unix platformon fut.
Egy másik démon gondoskodik az LDAP szerverek közötti replikációról. Ezt slurpd-nek hívják, és egyelőre nem foglalkozunk vele. Ez a dokumentáció a slapd démonról szól, amely lokális hálózatokon nyújt címtárszolgáltatást, replikáció - vagyis slurpd - nélkül. További információt a többszörözésről a OpenLDAP Administrator's Guide (OpenLDAP adminisztrátorok kézikönyve) dokumentumban találsz.
Az LDAP szervernek ez az egyszerű beállítása megfelelő kezdés lesz, amelyet később könnyen továbbfejleszthetsz, ha akarsz. Ez a dokumentáció bemutatja az LDAP protokoll használatához szükséges kezdeti lépéseket. Lehetséges, hogy miután végigérünk a dokumentumon elég erőt érzel majd magadban a további fejlesztői munkához, a szerver lehetőségeinek minél teljesebb kihasználásához - sőt, saját kliens programozásához - a fellelhető C, C++ és Java fejlesztő eszközökkel.
Az LDAP betűszó az angol "Lightweight Directory Access Protocol" (könnyű címtár elérési protokoll) kifejezésből származik. Ahogy a név is sugalmazza az LDAP kliens-szerver protokoll, címtár szolgáltatás eléréséhez, melyet eleinte főleg X.500 hozzáféréshez alkalmaztak. Az LDAP TCP/IP vagy más kapcsolat orientált átviteli szolgáltatást használhat. Az LDAP az RFC2251-ben - "The Lightweight Directory Access Protocol (v3)" - van definiálva. (Még egy URL: RFC2251 - a fordító)
A címtár olyan, mint egy adatbázis, de arra törekszik, hogy magába foglaljon egy részletesebb, tulajdonság alapú információkezelést. Általában az információt a címtárban gyakrabban olvassák, mint írják. Ennek következtében a címtárak általában nem alkalmaznak bonyolult tranzakció kezelést vagy roll-back rendszereket, amiket általában az adatbáziskezelők használnak a nagy méretű, összetett frissítésekhez. A címtár aktualizálása tipikusan egyszerű, mindent vagy semmit jellegű változás. A címtárakat összetett kérdések gyors megválaszolására hangolták. Képes arra, hogy széles körben sokszorosítsa az információkat azért, hogy növelje az elérhetőséget és a rendelkezésre állást, miközben a válaszidőt csökkenti. A többszörözött címtár információk egyes példányai között átmeneti rendezetlenség megengedett, de a többszörözések (replica) végül szinkronba kerülnek.
Sok különböző lehetőség van címtár szolgáltatás nyújtására. Különböző eljárásokkal más és más információk tárolhatók a címtárban, különböző követelmények szerint lehet hivatkozni az információkra, lekérdezni és frissíteni az adatokat, megvédeni azokat a meg nem engedett hozzáféréstől, stb. Néhány címtár szoláltatás lokális, és korlátozott környezetben nyújt szolgáltatásokat (például a finger szolgáltatás önálló gépen). Más szolgáltatások globálisak, széles körben elérhetőek.
Az LDAP címtárszolgáltatás kliens-szerver modellen alapul. Egy vagy több LDAP szerveren tárolt adatból épül fel az LDAP fa vagy LDAP háttér adatbázis. Az LDAP kliens egy LDAP szerverhez csatlakozik, és teszi fel a kérdéseit. A szerver megválaszolja a kérdést, vagy egy mutatót ad vissza, hol talál több információt a kliens (tipikusan egy másik LDAP szerver). Mindegy, hogy a kliens melyik LDAP szerverhez csatlakozik, ugyanazt a címtárat látja, ugyanaz a név az egyik címtár szerveren ugyanazt az adatot jeleníti meg, mint a másikon. Ez fontos tulajdonsága az olyan globális címtárszolgáltatásoknak, mint az LDAP.
Az LDAP szerver démon neve Slapd, ez több különböző, szabadon választható háttér adatbázis használatát támogatja.
Ezek között van az elsődlegesen támogatott BDB, egy nagy teljesítményű tranzakciós háttér adatbázis; az LDBM, a egyszerű DBM-re épülő háttér-adatbázis (database backend); a SHELL, az adatbázis interfész tetszőleges UNIX parancs vagy shell szkript eléréséhez, és a PASSWD, a passwd(5) jelszó adatbázis eléréséhez.
BDB segédeszközök: Sleepycat Berkeley DB 4. LDBM segédeszközök: Berkeley DB vagy a GDBM.
A BDB tranzakciós hátér adatbázist többfelhasználós olvasási/írási adatbázis elérésre fejlesztették ki, mindenféle olvasási/írási művelet kombinációjával. A BDB olyan programokkal használható együtt, melyekhez szükségesek a következők:
Tranzakciók, beleértve a többszörös változtatást az adatbázison, a visszaállítás lehetőségével együtt.
A rendszerösszeomlásokból és hardverhibákból fakadó hibák helyreállításának képessége, minden lezajlott tranzakció elvesztése nélkül.
Ez a leírás a BDB háttér adatbázis használatát feltételezi.
A címtár információk importálása és exportálása két LDAP alapú címtárszolgáltató szerver között, és a címtárakban alkalmazott változások leírása az LDIF formátumként ismert (LDAP Data Interchange Format; LDAP adatcserélési formátum) fájlokkal lehetséges. Az LDIF fájl a bejegyzéseket objektum orientált hierarchikus formában tárolja. Az LDAP csomag tartalmazza az LDIF fájlok BDB formátumba konvertálásához szükséges eszközöket.
Egy LDIF fájl általában így néz ki:
dn: o=TUDelft, c=NL o: TUDelft objectclass: organization dn: cn=Luiz Malere, o=TUDelft, c=NL cn: Luiz Malere sn: Malere mail: malere@yahoo.com objectclass: person |
Mint látható, minden bejegyzésnek saját azonosítója van, a distinguished name (DN; megkülönböztető név). A DN a bejegyzés nevéből áll, megtoldva a név elérési útjával vissza a címtár hierarchia csúcsáig (mint egy fánál).
Az LDAP-nál az objektumosztályok határozzák meg a bejegyzések azonosításához használható jellemzők csoportját. Az LDAP standard az alábbi alapvető objektum osztályokat nyújtja:
Group (csoport), független objektumok rendezetlen listája vagy objektumok csoportja.
Location (elhelyezkedés), az országok nevei és leírásuk.
Organization (szervezet).
People (személy).
Egy bejegyzés több objektumosztályhoz is tartozhat. Például a person bejegyzést definiálja a person objektumosztály, de szintén definiálják az inetOrgPerson, groupOfNames és organization objektumosztályok. Az LDAPserver objektumosztály struktúráját (sémáját) meghatározza az egyes bejegyzések számára szükséges és engedélyezett attribútumok egyéni listája.
A címtár az adatokat jellemző-érték (attribute-value) párosként jeleníti meg. Az információ meghatározott darabjai a leíró attribútumhoz tartoznak.
Például, a commonName (köznév), vagy cn attribútum az egyének nevét tárolja. A Jonas Salk nevű embert a címtárban a következő bejegyzés azonosítja:
cn: Jonas Salk |
Minden, a címtárban bejegyzett egyént a person objektumosztályban tárolt jellemzők csoportja ír le. Más jellemzőket is lehet ugyanabban a bejegyzésben használni:
givenname: Jonas surname: Salk mail: jonass@airius.com |
A bejegyzéshez szükséges jellemzőket tartalmaznia kell a használt objektumosztálynak. Minden bejegyzésnek tartalmaznia kell az objectClass-t, ami a bejegyzéshez tartozó objektumosztályok listáját tartalmazza.
Az engedélyezett jellemzőknek szerepelnie kell a használt objektumosztályban. Például, a person objektumosztályban a cn és sn jellemzők szükségesek. A leírásban a telephoneNumber, seeAlso és userpassword jellemzők engedélyezettek, de nem szükségesek.
Minden attribútumnak meghatározott szintaxis-definíciója van. A szintaxis-definíció információt nyújt a jellemzőről, mint például:
bin binary (bináris)
ces case exact string (betűnagyságnak meg kell egyeznie az összehasonlítás során).
cis case ignore string (betűnagyságnak nem kell egyeznie az összehasonlítás során).
tel telephone number string (olyan, mint a cis, de a "-" kihagyásával).
dn distinguished name (megkülönböztető név).
Figyelem! Az objektumosztályok és a jellemzők általában egy - az OpenLDAP telepítési könyvtárában a schema alkönyvtárban található séma-fájl szerint állnak össze.
Ennek a leírásnak az olvasók visszajelzési alapján korrigált és frissített változata megtalálható angol nyelven a
http://www.tldp.org/HOWTO/LDAP-HOWTO.html
honlapon
Ha bármilyen kétség merül fel benned valamilyen, az angol dokumentumban található információval kapcsolatban, angolul írj levelet erre a malere@yahoo.com e-mail címre
Egyéb, a témába vágó hozzáfűzni valód, javaslatod, ötleted is várom!
Ez a HOGYAN a TUDelft University - Hollandia - segítségével jött létre. Szeretnék köszönetet mondani mindazoknak, akik ennek a dokumentumnak a megírására bíztattak: Rene van Leuken és Wim Tiwon. Hálás köszönet érte! Ők is Linux-rajongók, akárcsak én.
Szintén köszönetet szeretnék mondani Thomas Bendler-nek, a német nyelvű LDAP-HOGYAN elkészítéséért és sok hasznos ötletéért. Valamint Joshua Go-nak, az LDP projekt önkéntesének.
Karl Lattimer megérdemelne egy különdíjat a SASL részben nyújtott segítségéért.
And thanks my Lord !
Copyright (c) 1999 Luiz Ernesto Pinheiro Malère. (Az LDAP Linux HOGYANt 1999-ben Luiz Ernesto Pinheiro Malère készítette.) A dokumentum szabadon terjeszthető, másolható és módosítható a Free Software Foundation által kiadott GNU FDL v1.1, vagy annak későbbi változatában leírt feltételek szerint. A GNU FDL külön fejezetben található, ennek a dokumentumnak a végén.
Ha kérdésed van látogass el a http://www.gnu.org/licenses/fdl.txt oldalra, és lépj kapcsolatba a LINUX-HOGYAN koordinátorával az guylhem@metalab.unc.edu e-mail címen.
A magyar fordítást Halász Gábor készítette (2000). A fordítást Völgyi Péter frissítette (2004.01.26). A frissítést lektorálta Kormos György (2004.03.16). Az utolsó frissítést Daczi László jelenleg is végzi. Eme dokumentum legfrissebb változata megtalálható a Magyar Linux Dokumentációs Projekt honlapján.
Öt lépés szükséges a szerver telepítéséhez:
Telepítsd a szerverhez szükséges programokat (ha még nincsenek telepítve a gépedre).
Töltsd le a szerver programot.
Csomagold ki.
Állítsd be a Makefile fájlt.
Fordítsd le a szervert.
(Azért egyszerűbb, ha a kedvenc disztribúciódban található OpenLDAP csomagot használod, ahelyett, hogy a forrással bajlódnál - a fordító)
Az LDAPv3 működéséhez az OpenLDAP kliensnek és szervernek szüksége van további csomagok telepítésére is. E dokumentum írásához dobozos Mandrake 9.0-t használtam, 2.4.20-as rendszermaggal, forrásból telepítettem a Berkeley BDB-t és a SASL programkönyvtárakat.
OpenSSL TLS programkönyvtárak
Az OpenSSL TLS programkönyvtárai általában az alaprendszer részét képezik, vagy opcionális programrészként jelennek meg. Az OpenSSL hivatalosan a http://www.openssl.org webhelyen található.
Azonosítás Kerberos-szal
Az OpenLDAP kliensek és szerverek támogatják a Kerberos alapú azonosítást. Az OpenLDAP kiemelten támogatja a Heimdal vagy MIT Kerberos V alapú SASL/GSSAPI azonosítási metódust. Ennek a használatához a megfelelő csomagokat (Heimdal vagy MIT Kerberos V) telepíteni kell. A Heimdal Kerberos a http://www.pdc.kth.se/heimdal, a MIT Kerberos a http://web.mit.edu/kerberos/www webhelyen található meg.
A Kerberos szintű, emelt biztonsági fokú azonosítás használata erősen javasolt.
A Cyrus féle SASL programkönyvtárak
A Cyrus féle SASL (Simple Authentication and Security Layer; egyszerű azonosítás és biztonsági szint) programkönyvtárak általában az alaprendszer részét képezik, vagy kiegészítő csomagokként találhatóak meg. A Cyrus SASL a http://asg.web.cmu.edu/sasl/sasl-library.html webhelyen található meg. A Cyrus SASL csak akkor tudja használni az OpenSSL és a Kerberos/GSSAPI programkönyvtárakat, ha azokat előbb telepíted nála. A dokumentum írása során a Cyrus SASL 2.1.17 verzióját használtam.
Adatbázis szoftverek
A Slapd's elsődleges adatbázis háttere a BDB, működéséhez szükséges a Sleepycat Software Berkeley DB (v4). Amennyiben a beállításkor nem áll rendelkezésre, akkor a slapd-t nem lehet elsődleges hátttér adatbázissal használni.
Ha nincs sem az alap Linux rendszereden, sem kiegészítő csomagként Berkeley DB (v4), a legegyszerűbben a Sleepycat webhelyen lehet hozzájutni. A dokumentum frissítése idején a legújabb stabil, és ajánlott verzió a 4.2.52-es. Az OpenLDAP slapd LDBM háttér többféle adatbázis kezelő, menedzselő felület használatát támogatja, így például a Berkeley DB (v3) és a GDBM használatát is. A GDBM letölthető az FSF webhelyéről, amely a ftp://ftp.gnu.org/pub/gnu/gdbm/ honlapon található.
Szálak
A többszálúság nagy valószínűséggel alapértelmezetten támogatott a Linux rendszereden. Az OpenLDAP-t úgy tervezték, hogy ennek előnyeit kihasználhassa. Az OpenLDAP támogatja a POSIX pthread, a Mach CThread és még számos más szálkezelési technológiát. A konfigurációs szkript jelez, ha nem talál alkalmas szálkezelési rendszert. Amennyiben ilyesmi fordulna elő keresd fel az OpenLDAP GYIK-et, amely a http://www.openldap.org/faq/ honlapon található.
TCP szűrők
A Slapd támogatja a TCP szűrők (IP szintű hozzáférés szűrők) használatát, amennyiben az előbb lett telepítve mint a slapd. A TCP szűrő vagy más IP alapú hozzáférés szűrő (mint egy IP alapú tűzfal) használata javasolt nem publikus szerverek adatainak védelmére.
Két szabadon terjeszthető LDAP szerver ismert, a Univesity of Michigan LDAP szerver és az OpenLDAP szerver. Létezik még a Netscape Directory Server, ami bizonyos körülmények között szabadon használható (oktatási intézmények például szabadon hozzájuthatnak). Az OpenLDAP szerver a University of Michigan Server legfrissebb változatán alapul, további dokumentumok és levelezőlisták találhatók a témába vágóan. Ez a dokumentum az OpenLDAP szerver használatát feltételezi.
(Az UM LDAP szerver kissé másképp kezeli a tranzakciókat, mint a Netscape Directory Server, ezért nem működik együtt a Netscape Navigatorral. Az OpenLDAP szerver a Netscape szerveréhez hasonlóan működik, ezért mindenképpen ezt használd, különben "megmagyarázhatatlan" hibákkal fogsz találkozni. Ha nem használsz Netscape Navigatort, akkor szabadon választhatsz. - a ford.)
Az aktuális OpenLDAP verziót a http://www.openldap.org webhelyen találod meg.
A University of Michigan Server legfrissebb változata az ftp://terminator.rs.itd.umich.edu/ldap webhelyen található.
Ennek a dokumentumnak a megírásához az OpenLDAP 2.2.5-os változatát használtam, rendszerem a Mandrake 9.0, 2.4.20-as rendszermaggal.
Az OpenLDAP webszerverén megtalálod az OpenLDAP szerver legutolsó stabil és fejlesztői változatát. A dokumentum frissítésekor az utolsó stabil változat az openldap-stable-20031217.tgz (v: 2.1.25), a fejlesztői változat az OpenLDAP-2.2.5.tgz.
Ha az betömörített csomag rendelkezésre áll a számítógépen, tömörítsük ki.
Először másoljuk a csomagot a megfelelő helyre, például a /usr/local könyvtárba. Ezután a következő parancsot használva kitömöríthetjük a csomagot:
tar xvzf openldap-2.2.5.tgz |
Ugyanilyen jól használható a következő is:
gunzip openldap-2.2.5.tgz | tar xvf - |
Az OPenLDAP szerverrel együtt terjesztett beállító szkript segít a telepítő könyvtár, a fordító (compiler) és szerkesztő (linker) kapcsolóinak beállítására. Segítséget kaphatunk a következő parancsot kiadva abban a könyvtárban, ahová a csomagot kitömörítettük:
./configure --help |
Ez ki fogja írni az összes lehetőséget a konfiguráló szkript beállításához, mielőtt a programot lefordítanánk. Néhány hasznos lehetőség a --prefix=pref, --exec-prefix=eprefix és a --bindir=dir, a telepítési könyvtár beállításához. Ha a configure szkriptet paraméterek nélkül futtatod, automatikusan megállapítja a szükséges beállításokat és előkészíti a telepítést az alapértelmezett helyre. Tehát gépeld be:
./configure |
Figyeld a kimenetét, hogy lásd, minden a megfelelően történik-e.
Tipp: Néha szükséges a konfigurációs szkript speciális beállítása is, mint például --with-tls (a slapd biztonságos csatornán keresztüli használatához. LDAPS://). Ebben az esetben az SSL/TLS könyvtárak nem biztos, hogy a standard könyvtárakban vannak. Beállíthatod az elérési utakat a környezeti paraméterek változtatásával. Ehhez használd az env parancsot. Tételezzük fel, hogy az openssl csomagot az /usr/local/openssl könyvtárba telepítetted. A következő paranccsal a slapd SSL/TLS támogatással fordítható:
env CPPFLAGS=-I/usr/local/openssl/include \ LDFLAGS=-L/usr/local/openssl/lib \ configure --with-tls ... |
A következő környezeti változókat lehet beállítani az env paranccsal, még a beállítási szkript futtatása előtt:
CC: Alternatív C fordító.
CFLAGS: További fordító kapcsolók beállítása
CPPFLAGS: C előfeldolgozó kapcsolók beállítása.
LDFLAGS: Linker kapcsolók beállítása.
LIBS: További könyvtárak beállítása.
A program konfigurálása után elkezdődhet a fordítás. Először a függőségeket hozzuk létre a következő paranccsal:
make depend |
Majd a szerver fordításához a következő parancsot kell használni:
make |
Ha minden jól ment, a szerver a beállításoknak megfelelően elkészült. Ha nem, térj vissza az előző lépéshez, és tekintsd át a beállításokat. Az INSTALL és a README fájlokat érdemes elolvasni! Ellenőrizd a rendszerspecifikus beállításokra vonatkozó javaslatokat, mely a doc/install/configure fájlban található meg.
Ahhoz, hogy biztosak legyünk a dolgunkban, futtassunk egy tesztet is (csak néhány percről van szó):
make test |
Ha minden OK, a beállításoknak megfelelő tesztek lefutnak. Néhány tesztet átugorhat a program, mint például a többszörözésre vonatkozót.
Most telepítsd a bináris fájlokat és a kézikönyveket (manual). Ennek elvégzéséhez root felhasználóként add ki a következő parancsot:
su root -c 'make install' |
Ez minden, most már megvannak a szerver és sok segédprogram bináris fájljai. A következő 3 fejezetben az OpenLDAP szerver működésének beállításáról lesz szó .
Ha a programot telepítetted és lefordítottad, jöhet a beállítás. A slapd futásidejű beállítása a konfigurációs könyvtárban található slapd.conf fájlon keresztül végezhető el, amelyet a konfigurációs szkript állít be, alapértelmezés szerint ez a /usr/local/etc/openldap. (Ha csomagból telepíted, akkor valószínűleg a /etc/openldap könyvtárban találod - a fordító)
Ez a fejezet a slapd.conf. általános beállítási elveit részletezi. A teljes felsorolást megtalálhatod a slapd.conf(5) kézikönyv oldalon (manual page). A konfigurációs fájl több részre osztható, úgymint: global (általános), backend specific (háttér specifikus) és database specific (adatbázis specifikus). A következőkben találhatod a direktívák magyarázatait, az alapértékeikkel együtt (ha van), példákkal illusztrálva.
A slapd.conf fájl három konfigurálási információt tartalmaz:global (általános), backend specific (háttér-specifikus), and database specific (adatbázis-specifikus). Először az általános rész kerül beállításra, ezt követi a háttér, majd az adott adatbázisra vonatkozó rész zárja a konfig fájlt.
Az általános opciók később felülbírálhatók a háttér és/vagy az adatbázis részben, a háttér részben beállított opciók felülbírálhatók az adatbázis részben (azoknak az opcióknak, amik egynél többször szerepelnek az slapd.conf-ban, utolsó megjelenésük lesz érvényes - a fordító).
Az üres sorok és a "#" jellel kezdődő sorok figyelmen kívül maradnak. Ha white space-el kezdődik a sor, akkor a következő sor folytatásaként érvényesül (még akkor is, ha az előző sor megjegyzés). Az slapd.conf általános formája a következő:
# global configuration directives <global config directives> # backend definition backend <typeA> <backend-specific directives> # first database definition & config directives database <typeA> <database-specific directives> # second database definition & config directives database <typeB> <database-specific directives> # second "typeA" database definition & config directives database <typeA> <database-specific directives> # subsequent backend & database definitions & config directives ... |
A konfigurációs fájl paraméterezhető. A paramétereket white space-ek választják el. Ha a paraméter white space-t tartalmaz, akkor paramétereket idézőjelbe kell tenni, "mint ezt itt". Ha az argumentum idézőjelet ' " ' vagy backslash-t '\' tartalmaz, akkor azt backslash karakternek kell megelőznie.(pl "\\d").
A disztribúció tartalmaz példa konfigurációt, amit a konfigurációs könyvtárban találsz (pl.: /usr/local/etc/openldap). A /usr/local/etc/openldap/schema könyvtárban található sok, általánosan használt jellemző, és objektumosztály definíció.
Az ebben a fejezetben leírt beállítási lehetőségek valamennyi háttérre és adatbázisra érvényesek, amíg specifikusan felül nem írja a háttér vagy az adatbázis definíció. Az argumentumok aktuális értékét a <kapcsok> közé kell beírni.
access to <what> [ by <who> <accesslevel> <control> ]+ |
Ezen opció biztosítja az <accesslevel> által meghatározott módon (hogyan?) a <what>> által meghatározott bejegyzésekhez (mit?) és tulajdonságokhoz a <who> által meghatározott kérelmezők (ki?) hozzáférését. Részletek az 3.7 részben.
Fontos: amennyiben nincs hozzáférési direktíva meghatározva, úgy az alapértelmezett hozzáférési szabály az access to * by * read, engedélyezi mind az azonosított, mind az anonymus felhasználóknak az olvasási jogot.
attributetype <RFC2252 Attribute Type Description> |
Ez a direktíva egy paraméter típust határoz meg. További információt találsz a Schema Specification (minta) leírásban.
idletimeout <integer> |
Meghatározza egy meddő kapcsolat bezárásának idejét. (Ennyi másodperc múlva kezdeményezi a kapcsolat megszakítását). A 0 érték (alaphelyzet) kikapcsolja ezt a funkciót.
include <filename> |
Ez az opció meghatározza azokat a konfigurációs állományokat, amelyeket a slapd végigolvas, mielőtt a következő sorral folytatná a fájl feldolgozását. A beemelt fájlnak követnie kell a slapd konfigurációs formátumát. Ezt a lehetőséget az adatbázis-háttér objektumosztályainak és attribútumainak definícióit tartalmazó fájlok beemelésére használható.
Megjegyzés: óvatosan kezelendő ez az opció. Semmi nem korlátozza az egymásba ágyazott include-ok számát, és nincs hurokellenőrzés sem.
loglevel <integer> |
Ez az opció specifikálja, hogy milyen hibakövető üzenetek és működési statisztikák kerüljenek az syslog-ba (jelenleg a syslogd-n(8) keresztül LOCAL4 jellemzővel kerülnek naplózásra az események). Ehhez az OpenLDAP-t --enable-debug kapcsolóval (alaphelyzet) kell fordítani a slapd-t, (kivéve a két stat szintet, amelyek mindig működnek). A loglevel értékei összeadódnak. Annak megjelenítéséhez,hogy melyik érték milyen üzeneteket eredményez, a slapd-t -? paraméterrel kell meghívni. Az értékek megtalálhatóak az alábbi táblázatban is (<integer>):
Táblázat 3-1. Hibakereső szintek
Szint | Leírás |
---|---|
-1 | enable all debugging (minden hibakövetés engedélyezve) |
0 | no debugging (nincs hibakövetés) |
1 | trace function calls (funkcionális hívások követése) |
2 | debug packet handling (csomagkezelés hibakövetése) |
4 | heavy trace debugging (kiterjedt hibakeresés) |
8 | connection management (kapcsolatkezelés) |
16 | print out packets sent and received (küldött és fogadott csomagok listázása) |
32 | search filter processing (kereső szűrő feldolgozása) |
64 | configuration file processing (konfigurációs fájl feldolgozása) |
128 | access control list processing (hozzáférési jogosultság lista feldolgozása) |
256 | stats log connections/operations/results (statisztika: napló kapcsolat/művelet/eredmény) |
512 | stats log entries sent (statisztika: elküldött naplóbejegyzések) |
1024 | print communication with shell backends (shell háttér kommunikáció megjelenítése) |
2048 | print entry parsing debugging (bejegyzés-fordítás hibakövetése) |
Például:
loglevel 255 vagy loglevel -1
Ez nagyon sok üzenetet eredményez a syslog-ban.
Alapértelmezés:
loglevel 256
objectclass <RFC2252 Object Class Description> |
Ez az opció definiálja a séma szabályokat az adott objektum-osztályokhoz. További információt találsz a Schema Specification (minta) leírásban.
referral <URI> |
Ez specifikálja, hova küldje a slapd a kérést, ha nem talál információt a kérés megválaszolásához a helyi adatbázisban.
Példa:
referral ldap://root.openldap.org
Ez átirányítja a nem lokális kéréseket a központi OpenLDAP szervernek (University of Michigan LDAP szerver - a fordító). Az ügyes LDAP kliensek újra felteszik a kérdést ennél a szervernél, de a legtöbb kliens csak arra képes, hogy egyszerű LDAP URL-eket kezeljen, melyek csak host részből és esetleg distinguished name-ből állnak.
sizelimit <integer> |
Ez az lehetőség maximalizálja a keresésre adott válasz sorainak számát.
Alapértelmezett:
sizelimit 500
timelimit <integer> |
Ez a kapcsoló specifikálja egy kérdés megválaszolására szánható maximális időt, másodpercekben (valós időben). Ha a kérést ez idő alatt nem sikerül megválaszolni, az eredmény időtúllépéssel (exceeded timelimit) tér vissza.
Alapértelmezés:
timelimit 3600
Ezek az opciók csak azokra a hátterekre érvényesek, amelyekben szerepenek. Valamennyi háttértípusnál alkalmazhatók. A háttér opciók minden azonos típusú adatbázisnál megjelennek, és az adatbázis direktívákkal felülírhatók.
backend <type> |
Ez az opció a háttér definíció kezdetét jelöli. A <típus> valamelyik bdb vagy a következők egyike kell legyen:
Táblázat 3-2. Adatbázis hátterek
Típus | Leírás |
---|---|
bdb | Berkeley DB tranzakciós adatbázis |
dnssrv | DNS SRV háttér |
ldbm | Lightweight DBM hátér |
ldap | Lightweight Directory Access Protocol (Proxy) háttér |
meta | Meta Directory háttér |
monitor | Monitor háttér |
passwd | Read-only hozzáférést biztosít a passwd(5)fájlhoz |
perl | Perl programozható háttér |
shell | Shell (külső program) háttér |
sql | SQL programozható háttér |
tcp | TCP programozható háttér |
Példa:
backend bdb
Ez a bejegyzés jelzi egy új BDB háttér definíciójának kezdetét.
Ezek az opciók csak azokra az adatbázis-hátterekre érvényesek, amelyekben szerepelnek. Valamennyi háttértípusnál alkalmazhatók.
database <típus> |
Ez az opció jelzi az új adatbázis definíció kezdetét. A <típus> az előzőekben felsoroltak valamelyike legyen.
Példa:
database bdb
Ez egy új BDB típusú adatbázis definíció kezdetét jelzi.
readonly { on | off } |
Ez az opció az adatbázist csak olvasható (read-only) módba kapcsolja. Az adatbázis módosításának kísérlete az "unwilling to perform" hibaüzenetet adja.
Alapértelmezés:
readonly off
replica uri=ldap[s]://<hostname>[:<port>] | host=<hostname>[:<port>] [bindmethod={simple|kerberos|sasl}] ["binddn=<DN>"] [saslmech=<mech>] [authcid=<identity>] [authzid=<identity>] [credentials=<password>] [srvtab=<filename>] |
Ez az opció határoz meg egy replikációs helyet az adatbázishoz. Az uri= paraméter egy sémát határoz meg, egy gazdagép és opcionálisan egy port, ahol a szolga slapd kérelme kezelhető. Vagy domain név vagy IP cím használható a <hostname> megadására. Ha <port> nincs megadva, úgy az általános LDAP portot (389 vagy 636) használja.
Az uri engedélyezi, hogy az LDAP szerver másolat LDAP URI-ként legyen meghatározva, például ldap://slave.example.com:389 vagy ldaps://slave.example.com:636
A binddn= paraméter adja meg a frissítéshez szükséges csatlakozás DN-ét. Ennek olyan DN-nek kell lennie, amelynek olvasási/írási joga van a szolga slapd adatbázisához. Ennek összhangban kell lennie a szolga slapd konfiguráció fájlában lévő updatedn opcióval. Általában az a DN nem lehet azonos a mester adatbázis rootdn-jével. Mivel a DN-ek szóközöket is tartalmazhatnak, az egész "binddn=<DN>" sztringet idézőjelek közé kell tenni.
A bindmethod egyaránt lehet simple, kerberos vagy sasl, annak függvényében, hogy egyszerű jelszó alapú, Kerberos alapú vagy SASL azonosítás szükséges a szolga szerverhez történő kapcsolódáshoz.
Amennyiben lehetséges, NE használjuk az egyszerű, jelszó alapú azonosítást (csak olyan esetekben, amikor a megfelelő biztonsági intézkedések megtörténtek (TLS, IPSEC, stb))! A jelszó alapú azonosításhoz binddn és credentials paraméter kell. A credentials paraméter, amely csak akkor szükséges, ha egyszerű azonosítást használsz, a szolga szervernek a binddn azonosításához szükséges jelszót tartalmazza.
A Kerberos azonosítást háttérbe szorítja a SASL azonosítási módszer, különösen a KERBEROS_V4 és GSSAPI mechanizmusok esetében. A Kerberos azonosításhoz binddn és érvényes srvtab fájl szükséges (Az srvtab paraméter, amely csak kerberos használatához szükséges, specifikálja, hogy melyik fájl tartalmazza a kulcsokat. Az alapértelmezett érték az /etc/srvtab - a fordító.)
Az SASL azonosítás a javasolható módszer. Az SASL azonosítás a saslmech paraméter használatán alapuló mechanizmus specifikációját igényli. Attól függően, hogy milyen mechanizmust választunk, az azonosítási személy és/vagy a credential meghatározható az authcid és a credential használatával. Az authcid paraméter meghatározhatja az azonosítási személyt.
További információt találsz a Replication with Slurpd (Másolat készítése a Slurpd-vel) leírásban.
replogfile <fájlnév> |
Ez az opció állítja be az replikációs log fájlt, ahol a slapd naplózza a változásokat. A replikációs log-ot tipikusan a slapd írja és a slurpd olvassa. Rendszerint ezt a lehetőséget csak a slurpd használja az adatbázis replikációjára. Mindamellett arra is használható, hogy tranzakciós naplót készíts, ha a slurpd nem fut. Ebben az esetben ne felejtsd el rendszeresen darabolni a fájlt, különben kezelhetetlen méretűre nő.
További információt találsz a Replication with Slurpd (Másolat készítése a Slurpd-vel) leírásban.
rootdn <dn> |
Ez az opció specifikálja azt a DN-t, akire nem vonatkozik a hozzáférés szabályozás és az adminisztrációs korlátozások az adatbázis-műveletek során. A DN-nek nem kell bejegyzésre mutatnia a könyvtárban. Viszont mutathat egy SASL identitásra.
Bejegyzés példa:
rootdn "cn=Manager, dc=example, dc=com"
SASL alapú példa:
rootdn "cn=Manager, dc=example, dc=com"
rootpw <jelszó> |
Ez az opció állítja be a fent leírt rootdn jelszavát (amikor a rootdn be van állítva egy DN adatbázisban). (Ez a lehetőség adatbázisok létrehozásakor vagy replikációs szolgáltatások nyújtásakor hasznos. Mindenképpen kerülendő a kódolatlan jelszavak használata. A legkevesebb az /etc/password fájlban található crypt kódolású jelszó használata. A slapd számos más típusú kódolást támogat - a fordító.)
Példa:
rootpw secret
Jelszó-zagyvalék szolgáltatása is megengedett az RFC 2307 szerint. A slappasswd használható a jelszó-zagyvalék létrehozására.
Példa:
rootpw {SSHA}ZKKuqbEKJfKSXhUbHG3fG8MDn9j1v4QN
A zagyvalék (hash) a slappasswd -s secret parancs kiadásakor jön létre.
suffix <dn toldalék> |
A suffix opció specifikálja a kérések DN toldalékát, ami átkerül a háttér-adatbázishoz. Több suffix sor is megadható, de legalább egy szükséges minden adatbázis definícióhoz.
Példa:
suffix "dc=example, dc=com"
A kérések DN-je "dc=example, dc=com" toldalékkal kerülnek az adatbázisba.
Figyelem: Amikor a hátteret - amelyiknek majd a kérést továbbadjuk - kiválasztottuk, a slapd tekintetbe veszi a suffix sor(oka)t minden adatbázis definíciónál abban a sorrendben, ahogy a fájlban előfordulnak. Így, ha az egyik adatbázis toldaléka egy másiknak előtagja, akkor ennek meg kell jelennie a konfigurációs file-ban is.
syncrepl |
Ez az opció használható egy másolt adatbázisnak az eredetivel történő szinkronban tartására. Ezáltal a másolt adatbázis tartalma naprakész lesz az eredeti adatbázis tartalmához képest.
Jelen dokumentum nem részletezi ezt az opciót, mivel egy egyszerű LDAP szerver beállítását tűztük célul. Erről az opciórol további információ a LDAP Sync Replication honlapon található.
updatedn <dn> |
Ez az opció csak a szolga slapd-n értelmezhető, és meghatározza a replika megváltoztatására jogosult DN-t. Ez lehet az a DN, amellyel a slurpd csatlakozik a replikálás során vagy a DN-t azonosítja az SASL indentitással.
Bejegyzés alapú példa:
updatedn "cn=Update Daemon, dc=example, dc=com"
SASL alapú példa:
updatedn "uid=slurpd,cn=example.com,cn=digest-md5,cn=auth"
További információk a Replication with Slurpd (Replikáció a slurpd használatával - angol nyelvű) honlapon találhatók.
updateref <URL> |
Ez az opció csak a szolga slapd-n értelmezhető. A replikán végzett frissítési kérések jóváhagyásának URL-jét (ami majd a kliensekhez kerül) határozza meg. Annyiszor kell meghatározni, ahány URL van.
Példa:
updateref ldap://master.example.net
Az ebben a kategóriában található előírások csak a BDB adatbázisokra vonatkoznak. Ezért az opciókat minden esetben a "database bdb" sor követi és megelőz minden további "háttér" vagy "adatbázis" sort. A BDB beállító opciók teljes referenciája a slapd-bdb kézikönyv oldalakon található (man page) (man slapd-bdb).
directory <könyvtár> |
Ez a direktíva meghatározza azt a könyvtárat, ahol a BDB adatbázis és a hozzá tartozó fájlok elhelyezkednek.
Alapértelmezés:
directory /usr/local/var/openldap-data
sessionlog <sid> <limit> |
This directive specifies a session log store in the syncrepl replication provider server which contains information on the entries that have been scoped out of the replication content identified by <sid>. The first syncrepl search request having the same <sid> value in the cookie establishes the session log store in the provider server. The number of the entries in the session log store is limited by <limit>. Excessive entries are removed from the store in the FIFO order. Both <sid> and <limit> are non-negative integers. <sid> has no more than three decimal digits.
The LDAP Content Synchronization operation that falls into a pre-existing session can use the session log store in order to reduce the amount of synchronization traffic. If the replica is not so outdated that it can be made up-to-date by the information in the session store, the provider slapd will send the consumer slapd the identities of the scoped-out entries together with the in-scope entries added to or modified within the replication content. If the replica status is outdated too much and beyond the coverage of the history store, then the provider slapd will send the identities of the unchanged in-scope entries along with the changed in-scope entries. The consumer slapd will then remove those entries in the replica which are not identified as present in the provider content.
A syncrepl-ről további információ a LDAP Sync Replication honlapon található.
Ebben a kategóriában csak az LDBM típusú háttér-adatbázisokra vonatkozó opciók találhatók. Ezért az opciókat minden esetben a "database ldbm" sor követi és megelőz minden további "database" vagy "backend" sort. A LDBM beállító opciók teljes referenciája a slapd-lbdm kézikönyv oldalakon található (man page; man slapd-ldbm).
cachesize <integer> |
Ez az opció határozza meg az átmeneti memóriában tárolt bejegyzések számát, amelyet az LDBM háttér-adatbáziskérések tartanak fent.
Alapértelmezés:
cachesize 1000
dbcachesize <integer> |
Ez az opció határozza meg minden egyes nyitott index fájlhoz rendelt átmeneti memória méretét byte-ban. Ha nem támogatja az alapját képező adatbázis eljárás, ez az opció kommentezés (#) nélkül is figyelmen kívül marad. A felhasznált memória méretének növelése drámaian növeli a teljesítményt, különösen az indexek módosításakor vagy létrehozásakor.
Alapértelmezés:
dbcachesize 100000
dbnolocking |
Bekapcsolva ezt az opciót az adatbázist nem lehet zárolni (lock). Növelheti a feldolgozási sebességet, persze a biztonság rovására.
dbnosync |
Ez a lehetőség azt eredményezi, hogy a lemezen levő adatbázis tartalmak nem lesznek automatikusan és azonnal szinkronizálva a memóriatartalommal, amikor valami változás történik. Engedélyezve szintén növelheti a sebességet a biztonság rovására.
directory <könyvtár> |
Ez a direktíva meghatározza azt a könyvtárat, ahol a LBDM adatbázis és a hozzá tartozó fájlok elhelyezkednek.
Alapértelmezés:
directory /usr/local/var/openldap-data
index {<attrlist> | default} [pres,eq,approx,sub,none] |
Ez a direktíva meghatározza az adott attribútum karbantartásáért felelős indexeket. Ha csak az <attrlist> van megadva, az alapértelmezett indexek lesznek csak karbantartva.
Példa:
index default pres,eq index uid index cn,sn pres,eq,sub index objectClass eq |
!!!FIXME!!! Az első sor beállítja az alapértelmezett index készleteket (present (jelenlét) és equality (egyenlőség) lesz a karbantartási szempont). A második sor objectClass és uid attribútumok alapján kezeli tovább az alapértelmezett index készleteket. A harmadik sor cn és sn attribútum típusok szerint vizsgálja az equality (egyenlőség), substring és approximate (becslés) index készleteket. !!!FIXME!!!
Alapértelmezés szerint az indexeket nem tartja karban. Ajánlott azonban legalább az objectClass szerinti equality (egyenlőség) index karbantartása.
index objectClass eq
mode <integer> |
Ez a direktíva határozza meg az újonnan létrehozott adatbázis index állományainak fájlvédelmi módját.
Alapértelmezés:
mode 0600
A hozzáférési eszköztár, melyet az access direktíva szabályoz, elég erőteljes. Most bemutatunk néhány példát a használatára vonatkozóan. Először néhány egyszerű példa:
access to * by * read |
Ez a hozzáférési direktíva mindenkinek olvasási jogot biztosít.
A következő példa bemutatja a regexp használatát a DN alapján történő kereséshez két access direktívában, ahol a sorrend is fontos.
access to dn=".*, o=U of M, c=US" by * search access to dn=".*, c=US" by * read |
Ebben az esetben a hozzáférési jogosultságok így alakulnak: Keresési (search) jogosultsággal rendelkeznek az 'o=U of M, c=US' dn-ű felhasználók, míg a többi, c=US jelzetű felhasználó olvasási (read) - eggyel magasabb szintű - jogosultságot kap. Ha fordítva lenne a két access sor, a U of M-re vonatkozó korlátozások nem lépnének életbe, mivel a c=US körbe beletartoznak, és a szűkítés nem lépne életbe. (a hozzáférési listákat felűlről lefelé dolgozza fel a program.)
Another way to implement the same access controls is:
access to dn.children="dc=example,dc=com" by * search access to dn.children="dc=com" by * read |
Read access is granted to entries under the dc=com subtree, except for those entries under the dc=example,dc=com subtree, to which search access is granted. No access is granted to dc=com as neither access directive matches this DN. If the order of these access directives was reversed, the trailing directive would never be reached, since all entries under dc=example,dc=com are also under dc=com entries.
Note: Also note that if no access to directive or no "by <who>" clause matches, access is denied. That is, every access to directive ends with an implicit by * none clause and every access list ends with an implicit access to * by * none directive.
A következő példa ismét jól mutatja a sorrend fontosságát. Mind a hozzáférési direktívák (access), mind pedig a "by <kicsoda>" cikkely esetében. Bemutatja továbbá az attribútum kapcsoló használatát, bizonyos attribútumok és többféle <who> kapcsoló hozzáférési jogainak beállításához.
access to dn.subtree="dc=example,dc=com" attr=homePhone by self write by dn.children=dc=example,dc=com" search by peername=IP:10\..+ read access to dn.subtree="dc=example,dc=com" by self write by dn.children="dc=example,dc=com" search by anonymous auth |
This example applies to entries in the "dc=example,dc=com" subtree. To all attributes except homePhone, an entry can write to itself, entries under example.com entries can search by them, anybody else has no access (implicit by * none) excepting for authentication/authorization (which is always done anonymously). The homePhone attribute is writable by the entry, searchable by entries under example.com, readable by clients connecting from network 10, and otherwise not readable (implicit by * none). All other access is denied by the implicit access to * by * none.
Sometimes it is useful to permit a particular DN to add or remove itself from an attribute. For example, if you would like to create a group and allow people to add and remove only their own DN from the member attribute, you could accomplish it with an access directive like this:
access to attr=member,entry by dnattr=member selfwrite |
A dnattr <kicsoda> kapcsoló megmondja,hogy a hozzáférések a 'member' (tag) -jellemzőben felsorolt elemekre vonatkoznak. A 'selfwrite' hozzáférési kapcsoló pedig ezen tagoknak csak saját DN-jükben történő hozzáadásra és törlésre ad jogosultságot. A bejegyzés jellemző hozzáadása kötelező, mivel a bejegyzéshez való hozzáférés során szükségszerűen a bejegyzés jellemzőihez is hozzá kell férnünk.
A hozzáférés szabályozásról rengeteg példa található az OpenLDAP Adminisztrátorok Kézikönyvében. Kattints a linkre: Hozzáférés szabályozás további információkért.
A következőkben magyarázó szövegrészekkel megszakítva bemutatok egy konfigurációs állományt. Két adatbázist definiál, az X.500-as fa különböző részeinek kezelésére. Mindkettő BDB adatbázis. A sorok számozása csak a tájékozódást és a magyarázatot hivatott segíteni, a működő fájlban nincsenek sorszámok. Nézzük először az általános beállításokat! ( global configuration section)
1. # example config file - global configuration section példa konfig fájl - általános beállítások rész 2. include /usr/local/etc/schema/core.schema 3. referral ldap://root.openldap.org 4. access to * by * read |
Az első sor megjegyzés. Az alap-séma leírásokat tartalmazó külső fájl befoglalása a második sorban történik meg. A harmadik sorban található utalás (referral) utasítás azt jelenti, hogy az összes olyan keresési kérelem, amelyet a helyi adatbázis nem tud kiszolgálni, át lesz irányítva a hagyományos LDAP kapun (389) keresztül a root.openldap.org szerverre.
A negyedik sor az általános elérést biztosítja. Minden bejegyzésre érvényes (minden más, használható adatbázis hozzáférés korlátozás után).
A beállítófájl következő szakaszában a "dc=example,dc=com" ágban történő kérések kiszolgálására szolgáló BDB háttér leírása jön. Az adatbázis két szolga slapd-re lesz megkettőzve. Az első egy tényleges, míg a második egy "vészhelyzeti" tükrözés. Az indexelések több attribútum szerint is karbantartásra kerülnek. A userPassword tulajdonság védett a jogosulatlan hozzáférésektől.
5. # BDB definition for the example.com 6. database bdb 7. suffix "dc=example,dc=com" 8. directory /usr/local/var/openldap-data 9. rootdn "cn=Manager,dc=example,dc=com" 10. rootpw secret 11. # replication directives 12. replogfile /usr/local/var/openldap/slapd.replog 13. replica uri=ldap://slave1.example.com:389 14. binddn="cn=Replicator,dc=example,dc=com" 15. bindmethod=simple credentials=secret 16. replica uri=ldaps://slave2.example.com:636 17. binddn="cn=Replicator,dc=example,dc=com" 18. bindmethod=simple credentials=secret 19. # indexed attribute definitions 20. index uid pres,eq 21. index cn,sn,uid pres,eq,sub 22. index objectClass eq 23. # database access control definitions 24. access to attr=userPassword 25. by self write 26. by anonymous auth 27. by dn.base="cn=Admin,dc=example,dc=com" write 28. by * none 29. access to * 30. by self write 31. by dn.base="cn=Admin,dc=example,dc=com" write 32. by * read |
Az 5. sor megjegyzés. Az adatbázis definíció kezdetét a 'database' kulcsszó jelzi (6.sor). A 7. sor határozza meg a helyi adatbázishoz továbbítandó keresések DN-utótagját. A 8. sor jelzi az adatbázis fájlok helyét.
A 9. és 10. sor az adatbázis felügyelőt azonosítja és a hozzárendelt jelszót. This entry is not subject to access control or size or time limit restrictions. Please remeber to encrypt the rootpw using slappasswd.
Example: rootpw {SSHA}Jq4xhhkGa7weT/0xKmaecT4HEXsdqiYA
11-18. sorok a többszörözési feladatot írják le. Bővebben: Replication angol nyelvű oldalon.
A 20. és 22. sorok a különböző attribútumokért felelős indexeket jelzik
A 24-től a 32. sorok hozzáférési jogosultságokat szabályoznak az adabázison. Minthogy ez az első adatbázis, a szabályozók életbe lépnek minden más bejegyzésre is, amelyek nincsenek még adatbázisban (mint pl. a root DSE). Minden alkalmazható bejegyzésre érvényes, hogy a userPassword attribútum írható a bejegyzés és az 'admin' bejegyzés által. Ezt azonosítási célokra lehet használni, máskülönben nem olvasható. Minden más attribútum írható a bejegyzés és az 'admin' bejegyzés által (mások által nem), és olvashatja minden bejegyzés (akár autentikált, akár nem).
A példa konfigurációs fájl következő része egy másik BDB adatbázist is definiál. Ez az adatbázis a dc=example, dc=net alág kereséseit kezeli, de ugyanaz a lényeg, mint az első adatbázis esetében. Figyeljük meg, hogy a 39. sor nélkül olvasási jogot mindenki, az általános beállítások 4. sorának megfelelően kap.
33. # BDB definition for example.net 34. database bdb 35. suffix "dc=example,dc=net" 36. directory /usr/local/var/openldap-data-net 37. rootdn "cn=Manager,dc=example,dc=com" 38. index objectClass eq 39. access to * by users read |
Az LDAP démona, a slapd önállóan futó szerverként használható. Ez lehetővé teszi a háttér számára a cache-elés előnyeinek kihasználását, jobban tudja kezelni az adatbázisok közötti ütközések problémáit és gazdaságosabban bánik a rendszer erőforrásaival. Futtatása az inetd(8)-ből nem lehetséges. (Korábban opció volt)
A slapd számos parancssori opciót támogat (részletesen a manuálban). Ebben a részben néhány, általánosan használt opció leírását taláhatod meg.
-f <fájlnév> |
Ez az opció alternatív konfigurációs fájlt határoz meg a slapd számára Alapértelmezett: /usr/local/etc/openldap/slapd.conf.
-h <URL-ek> |
Ezzel az opcióval alternatív port/host párokat állíthatsz be, amiken az LDAP figyel. Alapértelmezett: ldap:// ami arra utal, hogy az LDAP minden hálózati eszközön figyel a TCP-n keresztül az alapértelmezett LDAP porton (389). Megadható speciális host-port páros is, vagy más protokoll séma (mint pl. az ldaps:// or ldapi://) is. Például: -h "ldaps:// ldap://127.0.0.1:667" két figyelő csatornát hoz létre, egyiket az LDAP SSL-en keresztül minden eszközre vonatkozóan és a szabványos LDAP/SSL porton (637), míg a másikat a localhoston (127.0.0.1) a loopback eszközön, TCP-n, a 667-es kapun keresztül. A hostokat IPv4 szerint, numerikusan, vagy névvel is megadhatjuk. A port értékének numerikusan kell szerepelnie.
-n <szolgáltaltás-név> |
Itt adható meg a naplózásra és más célokra szolgáló szolgáltatás neve. Alapértelmezett: slapd.
-l <syslog-local-user> |
Ez a paraméter határozza meg a helyi felhasználót a syslog(8) lehetőség használatához. Lehetséges értékek: LOCAL0, LOCAL1, LOCAL2, ..., és LOCAL7. Az alapértelmezés: LOCAL4. Ez az opció nem használható minden rendszer alatt. További információkat lásd a 6.5 fejezetben.
-u user -g group |
Itt adható meg a felhasználó és a csoport, akinek a nevében fut a slapd. Mind a <user≶, mind a <group≶ megadható névvel vagy uid-del.
-r directory |
Ez a paraméter határozza meg a futás idejű könyvtárat. . Ez lesz a slapd chroot(2) könyvtára az indítás után, még mielőtt felolvasná a konfigurációs fájlokat vagy inicializálná a háttereket.
-d <szint> | ? |
Ez az opció beállítja az slapd hibakereső értékét a <szint>-re. Amikor a szint a '?' karakter, a különböző hibakereső szinteket írja ki és kilép a slapd attól függetlenül, hogy milyen egyéb opció lett még beállítva. A jelenlegi hibakereső szintek a következők:
Táblázat 4-1. Hibakövetés szintje
Level | Leírás |
---|---|
-1 | minden hibakövetés engedélyezése |
0 | nincs hibakövetés |
1 | funkció hívások nyomkövetése |
2 | csomagkezelés követése |
4 | alapos nyomkövetés |
8 | kapcsolatkezelés |
16 | fogadott és küldött csomagok kiírása |
32 | mintakeresés feldolgozása |
64 | konfigurációs fájl feldolgozása |
128 | hozzásférésszabályozási lista feldolgozása |
256 | kapcsolatok/műveletek/eredmények naplózása |
512 | küldött bejegyzések naplózása |
1024 | a háttérkommunikáció kiírása |
2048 | bejegyzések elemzésének kiírása |
Több szint is megadható egyszerre ha felsoroljuk egymás után a kívánt szinteket, mindet külön -d kapcsolóval. Mivel a hibakövetési szintek additívak egyszerű összeadással elvégezhető a számolás: Például, ha a funkcióhívások nyomkövetésése és a konfigurációs fájl feldolgozása egyaránt szükséges, akkor ennek a két hibakövető szintnek az összeadásával (ebben az esetben 1+64=65 vagyis a kapcsoló: -d 65) egyszerre adható meg a két hibakövetési szint, vagy a slapd is elvégezheti ezt helyettünk (ekkor a kapcsolók: -d 1 -d 64). További inforációk az <ldap.h> fájlban.
Figyelem!A slapd fordításakor az -LDAP_DEBUG-ot definiálni kell minden hibakövető funkció használatához, kivéve a két naplózási lehetőséget.
Általában a slapd a követlezőképpen fut:
/usr/local/etc/libexec/slapd [<option>]* |
ahol a /usr/local/etc/libexec értékét a konfigurációs szkript és az <opciók> határozzák meg, az <option> a fentebb leírtak bármelyike lehet. Ha a hibakereső értéke nem definiált, a slapd automatikusan elágazik és leválasztja magát a vezérlő terminálról és a háttérben fut tovább.
A slapd démon biztonságos leállításához ehhez hasonló parancs szükséges:
kill -INT `cat $(ETCDIR)/slapd.pid` |
Drasztikusabb leállítási módok alkalmazásakor az adatbázisok sérülhetnek, és a nem mentett adatok elveszhetnek. Itt jegyezzük meg, hogy a slapd pid a slapd.pid fájlba kerül, amit a slapd.conf fájlban állítottunk be. Pl. /usr/local/var/slapd.pid.
A slapd az argumentumait szintén a slapd.conf által meghatározott elérési úton lévő slapd.args fájlba írja. Pl. /usr/local/var/slapd.args.
Ez a fejezet leírja az adatbázisok létrehozását a semmiből. Két út van az adatbázisok létrehozására. Létrehozhatók adatbázisok az LDAP online használatával. Ennél az eljárásnál egyszerűen a slapd indítása után a tetszés szerinti LDAP klienssel elvégezhető a bejegyzések hozzáadása. Ez az eljárás viszonylag kis méretű adatbázisoknál használható jól (néhány száz vagy ezer bejegyzés, a követelmények függvényében). Azoknál az adatbázisoknál alkalmazható, amelyek támogatják a frissítést (update).
A második eljárás az adatbázisok létrehozására a slapd speciális eszközeinek segítségével lehetséges, offline módban. Ez a legjobb eljárás, ha sok ezer bejegyzést kell létrehozni, ami nagyon hosszú időt venne igénybe az LDAP eljárással, vagy ha biztos akarsz lenni abban, hogy az adatbázis biztosan ne legyen elérhető a létrehozás ideje alatt. FIGYELEM! Nem minden adatbázis típus támogatja a slapd ezen speciális eszközeit!
Az OpenLDAP programcsomag tartalmazza az ldapadd programot, a bejegyzések online hozzáadásához, vagyis amíkor az LDAP szerver fut. Amennyiben az online módszert választod az adatbázis létrehozására, ezt az eszközt kell használnod a bejegyzések hozzáadásához (más, OpenLDAP csomagon kívüli eszközöket is használhatsz, mint amilyen az Ldap Browser). Az első bejegyzések hozzáadása után még további bejegyzések felvétele is lehetséges. Mindenképpen szükséges a következő konfigurációs opciók beállítása a slapd indítása előtt:
suffix <dn> |
Az 3.4 fejezetben leírtak szerint ez az opció mondja meg, milyen bejegyzések kerülnek ebbe az adatbázisba. Be kell állítani a létrehozandó részfa gyökerének DN értékét:
suffix "o=TUDelft, c=NL" |
Specifikáni kell a könyvtárat, ahol az index file-ok létrejönnek:
directory /usr/local/tudelft |
Lehetővé kell tenni, hogy csatlakozhass a slapdhez mint címtár-felhasználó bejegyzések hozzáadásának jogával. Beállítható úgy a címtár, hogy támogassa a super-user-t, vagy root felhasználót erre a célra.
Ez a következő két opció segítségével lehetséges az adatbázis létrehozása során:
rootdn <dn> rootpw <passwd> /* Mindenképpen kódolt jelszót használj!!! */ |
Ez a két opció határozza meg az adatbázis adminisztrátoraként használható bejegyzés DN-jét és jelszavát (akinek minden tevékenység engedélyezett). Az itt meghatározott DN és a jelszó mindig működik, attól függetlenül, hogy a bejegyzés vagy a jelszó valóban létezik-e. Ez megoldja a tyúk és a tojás problémáját, vagyis hogyan azonosítható az adminisztrátor, és hozhatók létre rekordok mielőtt bármilyen bejegyzés létezne.
A slapd megérti ha SHA-1 kódolású jelszavakat használsz a rootpw direktívában. Én egy Java osztályt használtam SHA-1 szintű jelszavak létrehozására, de használható a slappasswd parancs is jelszavak generálására.
slappasswd -h {SHA} |
rootpw "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=" |
Például:
rootdn "cn=Manager,dc=example,dc=com" rootpw "{SHA}5en6G6MezRroT3XKqkdPOmY/BfQ=" |
The default output for slappasswd is to generate Secure Hash passwords {SSHA}, in this case you don't need to pass the -h parameter, just call slappasswd directly.
Amennyiben SASL-t használsz a rootpw sort ki kell szedni. Vess egy pillantást a 3.4 és a 6.2 (Autentikáció) fejezetre.
Végül, az adatbázis definícióinak tartalmaznia kell az szükséges indexek definícióit:
index {<attrlist> | default} [pres,eq,sub,none] |
Például, a cn, sn, uid és objectclass attribútumok indexét a következő index konfigurációs sor hozza létre:
index cn,sn,uid pres,eq,sub index objectClass pres,eq |
Note: Megjegyzés: figyelj arra, hogy nem minden indextípus használható minden jellemző esetében. Nézd meg a 3.6 fejezetben (példák).
Ha egyszer beállítottad a szükséges dolgokat, indítsd el a slapd-t, kapcsolódj az LDAP klienssel, és kezdd el a bejegyzések hozzáadását. Például, a TUDelft bejegyzést követő a Postmaster bejegyzés létrehozásához az ldapadd részére létre kell hozni a /tmp/newentry fájlt a következő tartalommal:
o=TUDelft, c=NL objectClass=organization description=Technical University of Delft Netherlands cn=Postmaster, o=TUDelft, c=NL objectClass=organizationalRole cn=Postmaster description= TUDelft postmaster - postmaster@tudelft.nl |
és utána a következő parancs létrehozza a szükséges bejegyzést:
ldapadd -f /tmp/newentry -x -D "cn=Manager, o=TUDelft, c=NL" -w secret |
A fenti parancs feltételezi, hogy a roodn bejegyzés a "cn=Manager, o=TUDelft, c=NL" és a rootpw a "secret" (vagy kódolt jelszó a slapd.conf-ban). Ha nem akarod begépelni a jelszót a parancsorba, használd a -W opciót az ldapadd parancs használatakor a -w"jelszó" helyett. Felszólítást kapsz jelszó beírására:
ldapadd -f /tmp/newentry -x -D "cn=Manager, o=TUDelft, c=NL" -W Enter LDAP Password: |
A második eljárás az adatbázisok offline létrehozása, az alább leírt slapd eszközök segítségével. Ez a legjobb eljárás ha sok ezer bejegyzés létrehozása szükséges, ami nagyon hosszú időt venne igénybe a fent leírt LDAP eszközök használatával. Ezek az eszközök elolvassák a slapd konfigurációs fájlt és a hozzáadandó bejegyzések szövegét tartalmazó LDIF file-t. Ez hozza létre közvetenül az LDAP index fájlokat . For database types which support the tools, they produce the database files directly (otherwise you must use the on-line method above). A következő néhány konfigurációs lehetőséget mindenképpen ismerni kell és be kell állítani a konfigurációs fájl adatbázis-definíciójának elején:
suffix <dn> |
Az előző bekezdésnek megfelelően, ez az opció határozza meg, milyen bejegyzéseket fog tartalmazni az adatbázis. Ennek a létrehozandó részfa gyökerének DN-jét kell tartalmaznia. Például:
suffix "o=TUDelft, c=NL" |
Mindenképpen meg kell határozni az index fájlok könyvtárát:
directory /usr/local/tudelft |
Végül meg kell mondanunk, milyen indexekre van szükség. Ez egy vagy több index opcióval végezhető el:
index {<attrlist> | default } [pres,eq,approx,sub,none] |
Például:
index cn,sn,uid pres,eq,sub index objectClass eq |
A fenti parancs létrehozza a presence, equality és approximate indexeket a cn,sn és uid attribútumoknál, és equality indexet az objectClass opciónál. További információk a konfigurációs fájl beállítása fejezetben találhatók erről az opciókról.
Miután a konfiguráció kész van, létre kell hoznunk az elsődleges adatbázist a hozzá tartozó indexfájlokkal együtt. Ezt a slapadd(8) programmal tehetjük meg:
slapadd -l <inputfile> -f <slapdconfigfile> [-d <debuglevel>] [-n <integer>|-b <suffix>] |
Az argumentmok jelentései:
-l <inputfile> |
meghatározza az LDIF bemeneti fájlt, ami a hozzáadandó bejegyzéseket tartalmazza szöveges formában (A következő fejezet erről szól).
-f <slapdconfigfile> |
Specifikálja a slapd konfigurációs fájlját, ami meghatározza hol, milyen indexeket kell létrehozni, stb.
-d <debuglevel> |
Bekapcsolja a hibakeresést a debuglevel által meghatározott módon. A hibakeresés szintjei megegyeznek a slapd értékeivel. (lásd a 4.1 további részletekért.)
-n <databasenumber> |
Ez az opcionális argumentum határozza meg, hogy az adatbázisok közül melyiket használja a program. A konfigurációs fájlban szereplő első adatbázis az "1", a második a "2", stb. Alapértelmezésként az első adatbázist használja. A -b argumentummal együtt nem használható.
-b <suffix> |
Ez az opcionális argumentum határozza meg, hogy az adatbázisok közül melyiket használja a program. Az utótagot (suffix) összehasonlítja az adatbázisban szereplő adatbázis direktíva számával, és így dönti el melyik adatbázist használja. Az -n argumentummal együtt nem használható.
Néha szükségessé válik az indexek újragenerálása (pl. a slapd.conf(5) módosítása után). Ezt a slapindex(8) programmal végezhetjük el. A program meghívása a következőképpen történik:
slapindex -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>] |
Ahol az -f, -d, -n és a -b kapcsolók ugyanazok, mint a slapadd(1) program esetében. A slapindex újraépíti az indexállományokat az éppen aktuális adatbázis tartalmak alapján.
A slapcat programmal az adatbázis tartalmát egy szöveges LDIF fájlba tudjuk önteni (dump). Akkor lehet hasznos, ha olvasható adatbázis-másolatot szeretnénk készíteni, vagy, ha az adatbázist off-line módon szeretnénk szerkeszteni. A program indítása:
slapcat -l <filename> -f <slapdconfigfile> [-d <debuglevel>] [-n <databasenumber>|-b <suffix>] |
Ahol az -f opció -n vagy -b kapcsolóival lehet kiválasztani a slapd.conf(5)-ban leírt adatbázisok közül azt, amilyre szükségünk van. Az LDIF eredmény a standard kimenetre kerül, hacsak nem határoztunk meg egy fájlt a -l opcióban..
Az LDAP Data Interchange Fromat (LDIF) az LDAP bejegyzések megjelenítésére szolgál szöveges formában. Egy bejegyés alapvető formája:
#comment megjegyzés dn: <distinguished name> <attrdesc>: <attrvalue> <attrdesc>: <attrvalue> ... |
A '#' kezdetű sorok megjegyzések. Az attribútum leírások (attrdesc) lehetnek egyszerűek, mint pl. a cn, az objectClass vagy az 1.2.3 (egy attribútum-típussal azonosított OID) vagy opciókat is magukba foglalhatnak, pl. cn;lang_en_US vagy userCertificate;binary.
A sorok folytathatóak a következő sorban egy szóköz vagy tab karatkerrel. Például:
dn: cn=Barbara J Jensen, dc=example, dc= com cn: Barbara J Jensen |
megfelel ennek:
dn: cn=Barbara J Jensen, dc=example, dc=com cn: Barbara J Jensen |
Többszörös attribútumok több elválasztott sorban is specifikálhatóak. Például:
cn: Barbara J Jensen cn: Babs Jensen |
Ha az <attrvalue> (attribútum érték) nem nyomtatható karaktereket tartalmaz, vagy szóközzel, kettősponttal (':'), kisebb jellel('<') kezdődik, akkor az <attrdesc> (attribútum leírás)-t kettőspont követi, és az érték base64 kódolású lesz. Például a "begins with space" érték a következőképpen lesz kódolva:
cn:: IGJlZ2lucyB3aXRoIGEgc3BhY2U= |
Meghatározható egy URL-is amely az attribútum értéket tárolja. Pl. a következő sor a jpegPhoto értékét az /útvonal/a/jpeg.képhez fájlból veszi.
cn:< file://path/to/file.jpeg |
A többszörös bejegyzéseket ugyanabban az LDIF file-ban üres sorokkal kell elválasztani. Egy három bejegyzést tartalmazó LDIF file:
# Barbara's Entry #Barbara bejegyzése dn: cn=Barbara J Jensen, dc=example, dc=com cn: Barbara J Jensen cn: Babs Jensen objectClass: person sn: Jensen # Bjorn's Entry #Björn bejegyzése dn: cn=Bjorn J Jensen, dc=example, dc=com cn: Bjorn J Jensen cn: Bjorn Jensen objectClass: person sn: Jensen # Base64 encoded JPEG photo # Base64 kódolású fénykép jpegPhoto:: /9j/4AAQSkZJRgABAAAAAQABAAD/2wBDABALD A4MChAODQ4SERATGCgaGBYWGDEjJR0oOjM9PDkzODdASFxOQ ERXRTc4UG1RV19iZ2hnPk1xeXBkeFxlZ2P/2wBDARESEhgVG # Jennifer's Entry #Jennifer bejegyzése dn: cn=Jennifer J Jensen, dc=example, dc=com cn: Jennifer J Jensen cn: Jennifer Jensen objectClass: person sn: Jensen # JPEG photo from file # JPEG kép fájlból jpegPhoto:< file://path/to/file.jpeg |
Figyeljük meg, hogy a Bjorn bejegyzésben taláható jpegPhoto érték base64 kódolású, míg a Jennifer bejegyzésben szereplő jpegPhoto az URL-ben szereplő helyen tárolódik.
FIGYELEM: A követő szóközök benne maradnak az LDIF file-ban. A többszörös szóközök is megmaradnak. Ha nem szükségesek az adatokban, akkor el kell távolítani őket.
ldapsearch - Az ldapsearch a parancsértelmező által elérhető felületet biztosít az ldap_search(3) függvény használatához. Ez a program jól használható bejegyzések kereséséhez az LDAP adatbázisban.
Az ldapsearch szintaktikája a következő (Az opciók jelentése az ldapsearch man lapján található):
ldapsearch [-n] [-u] [-v] [-k] [-K] [-t] [-A] [-B] [-L] [-R] [-d debuglevel] [-F sep] [-f file] [-x] [-D binddn] [-W] [-w bindpasswd] [-h ldaphost] [-p ldapport] [-b searchbase] [-s base|one|sub] [-a never|always|search|find] [-l timelimit] [-z sizelimit] filter [attrs...] |
Az ldapsearch kapcsolatot létesít az LDAP szerverrel, és a szűrő (filter) használatával keresést hajt végre az adatbázisban. A szűrőnek meg kell felenie az RFC 1558-ban definiált LDAP szürők ábrázolásához. Ha az ldapsearch egy vagy több bejegyzést talál, az attrs által specifikált attribútumokat adja vissza, és az értékeket a standard kimenetre írja ki. Ha attrs nincs felsorolva, az összes attribútumot visszaadja.
ldapsearch -x -b 'o=TUDelft,c=NL' 'objectclass=*' ldapsearch -b 'o=TUDelft,c=NL' 'cn=Rene van Leuken' ldasearch -u -b 'o=TUDelft,c=NL' 'cn=Luiz Malere' sn mail |
A -b opció a searchbase-t (a keresés kindulási pontja), az -u opció a felhasználóbarát kimenő információt míg az -x opció az egyszerű azonosítást képviseli.
ldapdelete - Az ldapdelete a parancsértelmező által elérhető felületet biztosít az ldap_delete(3) függvény használatához. Ez a program használható bejegyzések törléséshez az LDAP adatbázisban.
Az ldapdelete szintaktikája a következő (Az opciók jelentése az ldapdelete man lapján található):
ldapdelete [-n] [-v] [-k] [-K] [-c] [-d debuglevel] [-f file] [-D binddn] [-W] [-w passwd] [-h ldaphost] [-p ldapport] [dn]... |
Az ldapdelete kapcsolatot létesít az LDAP szerverrel, és töröl egy vagy több bejegyzést. Ha egy vagy több DN argumentum szerepel, akkor azok a Megkülönbüztető Nevü (dn) bejegyzések törlődnek. Minden DN-nek meg kell felelnie az RFC1779-ben definiált karatersorral. Ha nincs dn argumentum megadva, a dn-ek listáját a standard bemenetről olvassa be (vagy az -f kapcsolóval megadott fájlból).
Néhány példa következik az ldapdelete használatára:
ldapdelete 'cn=Luiz Malere,o=TUDelft,c=NL' ldapdelete -v 'cn=Rene van Leuken,o=TUDelft,c=NL' -D 'cn=Luiz Malere,o=TUDelft,c=NL' -W |
A -v opció a bőbeszédű kimenetet, a -D a Binddn-t (az azonosító dn-t) és a -W a jelszó prompt-ot jelenti.
ldapmodify - Az ldapmodify a parancsértelmező által elérhető felületet biztosít az ldap_modify(3) és az ldap_add(3) függvények használatához. Ez a program bejegyzések módosításához használható az LDAP adatbázisban.
Az ldapmodify szintaktikája a következő (Az opciók jelentése az ldapmodify man lapján található):
ldapmodify [-a] [-b] [-c] [-r] [-n] [-v] [-k] [-d debuglevel] [-D binddn] [-W] [-w passwd] [-h ldaphost] [-p ldapport] [-f file] ldapadd [-b] [-c] [-r] [-n] [-v] [-k] [-K] [-d debuglevel] [-D binddn] [-w passwd] [-h ldaphost] [-p ldapport] [-f file] |
Az ldapadd megvalósítása egy hard link az ldapmodify programra. Az ldapadd hívásakor az ldappmodify -a (új bejegyzés hozzáadása) kapcsolója automatikusan bekapcsoldódik. Az ldapmodify kapcsolatot létesít az LDAP szerverrel, és egy vagy több bejegyzést módosít. A bejegyzések információit a standard inputról olvassa be, vagy pedig az -f opcióval beállított fájlból.
Néhány példa az ldapmodify használatára:
Tételezzük fel, hogy a /tmp/entrymods fájl létezik, és a következőket tartalmazza:
dn: cn=Modify Me, o=University of Michigan, c=US #módosítandó rész changetype: modify replace: mail mail: modme@terminator.rs.itd.umich.edu - add: title title: Grand Poobah - add: jpegPhoto jpegPhoto: /tmp/modme.jpeg - delete: description - |
A parancs:
ldapmodify -b -r -f /tmp/entrymods |
kicseréli a "Módositandó" bejegyzés (cn="Modify Me") mail attribútumát a "modme@terminator.rs.itd.umich.edu"-ra, hozzáadja a "Grand Poobah" title (cím) attribútumot, és a /tmp/modme.jpeg fájl tartalmát, mint jpegPhoto, és törli a description attribútumot.
A fentiekkel megegyező módosítások a régebbi ldapmodify bemeneti formájában:
cn=Modify Me, o=University of Michigan, c=US mail=modme@terminator.rs.itd.umich.edu +title=Grand Poobah +jpegPhoto=/tmp/modme.jpeg -description |
és a hozzá tartozó parancs:
ldapmodify -b -r -f /tmp/entrymods |
Tételezzük fel, hogy a /tmp/entrymods fájl létezik, és a következőket tartalmazza:
dn: cn=Barbara Jensen, o=University of Michigan, c=US objectClass: person cn: Barbara Jensen cn: Babs Jensen sn: Jensen title: the world's most famous manager mail: bjensen@terminator.rs.itd.umich.edu uid: bjensen |
A parancs:
ldapadd -f /tmp/entrymods |
hozzáadja a bejegyzést a következő megkülönböztető névvel: cn=Barbara Jensen, o=University of Michigan, c=US, ha eddig nem létezett volna. Ha létezik ilyen dn-ű bejegyzés, a program hibával leáll és nem írja felül a bejegyzést.
Tételezzük fel, hogy a /tmp/newentry fájl létezik, és a következőket tartalmazza:
dn: cn=Barbara Jensen, o=University of Michigan, c=US changetype: delete |
A parancs:
ldapmodify -f /tmp/entrymods |
eltávolítja a Barbara Jensen bejegyzést.
Az -f opció jelenti a fájlt (a módosításhoz szükséges információkat tartalmazza a standard input helyett), a -b kapcsoló jelzi a bináris adatokat (minden '/' karakterrel kezdődő értéket binárisként kezel), az -r kapcsoló állítja be a hozzáadást (a létező értékeket alapértelmezésként felülírja).
Ebben a fejezetben további információk találhatók olyan hasznos témákról, mint az azonosítás, naplózás, és az LDAP kliens. A fejezet végén további hasznos linkeket (magyar nyelvűeket is!), könyveket, és ajánlott irodalmat, RFC-ket találunk.
Az LDAP Migrációs Eszközök a PADL Software Ltd. által közzétett perl script-ek gyűjteménye, használatuk előtt ajánlott a licensz feltételek elolvasása, habár szabad szoftver. Konfigurációs fájlok LDIF formátumra történő átalakításához használhatóak. Ha felmerül az LDAP szerver használata a felhasználók azonosításhoz, ezek nagyon hasznos programok lehetnek. A Migration Tools használható a NIS vagy a password archívumok LDIF formába konvertálásához, ezeket a fájlokat kompatibilissé téve az LDAP szerverrel. Ezeknek a Perl scripteknek alkalmazásával átköltöztethetők a user-ek, group-ok, alias-ok, host-ok, netgroup-ok, network-ok, protocol-ok, PRC-k és service-k a meglevő szolgáltatóktól (NIS, fájlok, és NetInfo) LDIF fomátumúvá.
Az LDAP Migration Tools letölthető, és további információk találhatók a következő címen: http://www.padl.com/OSS/MigrationTools.html
A csomagban találhat README fájl, és a script-ek neve egyértelmű. A script-ek alkalmazása előtt el kell olvasni a README fájlt!
További hasznos URL a migrációs eszközökről:
Ahhoz, hogy az LDDAP szolgáltatást igénybe vehessük, először azonosítani kell magunkat (a klienset) a szolgáltaóval. Ez annyiból áll, hogy megmondjuk a szervernek, ki akar az adatokhoz férni, ebből a szerver eldönti, hogy mihez férhetünk hozzá és már mehetünk is. Ha a kliens sikeresen azonosítja magát az LDAP szervernél, akkor ezután kéréseket küld a szervernek, a szerver pedig ellenőrzi, hogy a kérés kiszolgálása jogos-e vagy sem. Ez a folyamat a hozzáférés-szabályozás.
Az LDAP-ban az azonosítást a "bind" művelet végzi. Az Ldapv3 háromféle azonosítási módot támogat: anonymous, egyszerű és SASL azonosítást. Azok az ügyfelek, melyek a "bind" megkerülésével küldenek kéréseket a szerver felé, anonymous-ként lesznek kezelve. Az egyszerű azonosítás abból áll, hogy az ügyfél elküldi az LDAP szerver felé a felhasználó DN-jét és a felhasználó egyszerű jelszavát. Ennek a folyamatnak biztonsági problémái adódnak, mivel a jelszó könnyen elolvasható a hálózatról. Ennek elkerülésére használható az egyszerű azonosítási folyamat egy titkosított csatornán keresztül (mint amilyen az SSL), ezt az LDAP is támogatja.
Végezetül itt van az SASL, vagyis a Simple Authentication and Security Layer (RFC 2222). Ez a fajta azonosítás egy kérdés-válasz típusú protokoll az ügyfél és a szerver között, melyen keresztül létrejön egy biztonságos csatorna, ahol a további tranzakciók lebonyolódnak. Az SASL használatával mindenféle olyan azonosítási mód lehetséges, amelyet a szerver és a kliens megenged. A Cyrus-SASL csomag a következő URL-ről érhető el: http://asg.web.cmu.edu/sasl/sasl-library.html.
A felhasználók további azonosítása a címtár fában lévő további információk eléréséhez, az LDAP szerver más szolgáltatásokból származó felhasználókat (sendmail, login, ftp, stb. ) is képes azonosítani. Ezek a specifikus felhasználói információk eljutnak a szerverhez, majd a PAM (Pluggable Authentication Modules) mechanizmus használatával azonosítja a felhasználókat. Ez az azonosító modul az LDAP számára elérhető tarball formájában a következő címen:http://www.padl.com/OSS/pam_ldap.html
Nekem LDAP-SASL azonosítási rendszerem van, amely a DIGEST-MD5 mechanizmust használja. Ahhoz, hogy működjön szigorúan ezekhez a lépésekhez ragaszkodva jutottam el:
Töltsük le a SleepyCat aktuális verzióját (4.2.52 -a doksi frissítésekor), majd fordítsuk le. Letöltés után csak a doc/install.html (abban a könyvtárban, ahova kitömörítetted a csomagot) fájlban talált instrukciókra támaszkodtam.
Kicsomagolás után a várható parancsok:
root@rdnt03:/usr/local/BerkeleyDB.4.2/build_unix#../dist/configure root@rdnt03:/usr/local/BerkeleyDB.4.2/build_unix#make root@rdnt03:/usr/local/BerkeleyDB.4.2/build_unix#make install |
Töltsük le a Cyrus SASL aktuális változatát (2.1.17), tömörítsük ki és kövessük a doc/install.html-ben található utasításokat! Itt figyelnünk kell egy kicsit: ugyanis a konfiguráció során néhány env (környezeti változó) paramétert is meg kell adnunk
root@rdnt03:/usr/local/cyrus-sasl-2.1.17#env CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include" LDFLAGS="-L/usr/local/BerkeleyDB.4.2/lib" ./configure |
A CPPFLAGS és LDFLAGS környezeti változóknak a Berkeley DBD telepítési könyvtárában található include és lib könyvtáraira kell mutatniuk.
Ezután már futtathatók a következők:
root@rdnt03:/usr/local/cyrus-sasl-2.1.17#make root@rdnt03:/usr/local/cyrus-sasl-2.1.17#make install root@rdnt03:/usr/local/cyrus-sasl-2.1.17#ln -s /usr/local/lib/sasl2 /usr/lib/sasl2 |
Végül, telepítettem az OpenLDAP programot (2.2.5) ugyanazokat az utasításokat használva, mint az SASL-nél csak futtatva a konfigurációs szkriptet:
root@rdnt03:/usr/local/openldap-2.2.5#env CPPFLAGS="-I/usr/local/BerkeleyDB.4.2/include" LDFLAGS="-L/usr/local/BerkeleyDB.4.2/lib" ./configure |
Ezután futtattam a továbbiakat:
root@rdnt03:/usr/local/openldap-2.2.5#make depend root@rdnt03:/usr/local/openldap-2.2.5#make root@rdnt03:/usr/local/openldap-2.2.5#make install |
Majd létrehoztam a sasl felhasználói adatbázist:
root@rdnt03:~# saslpasswd2 -c admin |
Jelszót kell majd beírni. FIGYELEM! A felhasználónév ne egy DN (megkülönböztető név) legyen. A jelszó ugyanaz legyen mint az admin jelszó a címtár fánál.
Most be kell állítani az sasl-regexp direktívát a slapd.conf fájlban, mielőtt elindítanánk a slapd démont és tesztelni kezdenénk az azonosítást. Az én slapd.conf fájlom a /usr/local/etc/openldap könyvtárban csücsül:
sasl-regexp uid=(.*),cn=rdnt03,cn=DIGEST-MD5,cn=auth uid=$1,ou=People,o=Ever |
Ez a paraméter ebben a formában van:
uid=<username>,cn=<realm>,cn=<mech>,cn=auth
A felhasználónév az sasl-ből vétetik, és az ldap keresési sztringbe illesztődik, a $1 helyére. A territóriumod valószínüleg a FQDN-ből (domain) jön, de néha nem, mint nálam sem. Ahhoz, hogy megtudjuk mi a felségterületeted a következőket kell tenni:
root@rdnt03:~# sasldblistusers2 admin@rdnt03: userPassword admin@rdnt03: cmusaslsecretOTP |
Esetemben az rdnt03 jelzi a domén-t. Ha ez a Te FQDN-d nem lehet problémád. A következő LDIF fájlt használom:
dn: o=Ever o: Ever description: Organization Root objectClass: top objectClass: organization dn: ou=Staff, o=Ever ou: Staff description: These are privileged users that can interact with Organization products objectClass: top objectClass: organizationalUnit dn: ou=People, o=Ever ou: People objectClass: top objectClass: organizationalUnit dn: uid=admin, ou=Staff, o=Ever uid: admin cn: LDAP Adminstrator sn: admin userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ= objectClass: Top objectClass: Person objectClass: Organizationalperson objectClass: Inetorgperson dn: uid=admin,ou=People,o=Ever objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson userPassword: {SHA}5en6G6MezRroT3XKqkdPOmY/BfQ= displayName: admin mail: admin@eversystems.com.br uid: admin cn: Administrator sn: admin |
Adjunk bejegyzéseket az LDAP címtárunkhoz a következő paranccsal:
slapadd -c -l Ever.ldif -f slapd.conf -v -d 256 |
Most elindíthatjuk a slapd démont, és futtassunk le egy keresést az ldapsearch parancs használatával:
root@rdnt03:~# ldapsearch -U admin@rdnt03 -b 'o=Ever' '(objectclass=*)' SASL/DIGEST-MD5 authentication started Please enter your password: SASL username: admin@rdnt03 SASL SSF: 128 SASL installing layers ... Entries ... |
Ennyi! Amennyiben jobban szeretnéd használni az SASL-t Kerberos V vagy GSSAPI mechanizmusokkal, íme egy hasznos link: http://www.openldap.org/doc/admin22/sasl.html Ez az oldal feltételezi, hogy már túl vagy az SASL telepítésén és beállításán. A levelezőlista segíthet, ha elakadnál: http://asg.web.cmu.edu/sasl/index.html#mailinglists
A kldap egy grafikus ldap kliens a KDE környezetet számára. A Kldap kényelmes felülettel rendelkezik, és képes valamennyi, a címtárban tárolt információs fa megjelentítésére. Néhány kép az alkalmazásról valamint a letöltési hely: http://www.mountpoint.ch/oliver/kldap/
A KDirAdm könyvtár kezelő eszközt KDE 2 vagy újabb környezethez írták. Célja, hogy összegyűjtse a legáltalánosabban használt könyvtár kezelő eszközöket: http://www.carillonis.com/kdiradm/
A Directory Administrator(Könyvtár Titkár) a legelterjedtebben használt Gnome alapú UNIX rendszerű felhasználó és csoportkezelő alkalmazás LDAP címtár kiszolgálókhoz. A Directory administrator lehetővé teszi felhasználók és csoportok létrehozását és törlését, valamint a felhasználókhoz tartozó névjegyalbum információk, kiszolgálónkénti hozzáférés-szabályozások, és Sendmail útvonalválasztások kezelését. http://diradmin.open-it.org/index.php
A GQegy másik, a Gnome környezet számára készült grafikus LDAP kliens, egyszerű felülettel. Működik KDE alatt is, mint ahogy a Kldap is fut Gnome környezetben. További információk és a program letölthetősége: http://biot.com/gq/
LDAP Browser/Editor: Ez egy fantasztikus eszköz, mindenféle adminisztrációs és böngészési lehetőséggel felszerelve. Itt megnézhető/letölthető: Ldap Browser.
A slapd a syslog(8) képességeit használja naplózásra. Alapértelmezés szerinti syslog(8) jellemző a user LOCAL4, de az értéke LOCAL0, LOCAL1, egészen LOCAL7-ig engedélyezett.
A naplók létrehozásához szerkeszteni kell a syslog.conf file-t, rendszerint a /etc könyvtárban.
Ehhez hasonló sort kell létrehozni:
local4.* /usr/adm/ldaplog |
Ez az alapértelmezett LOCAL4 usert állítja be a syslog jellemzőnek. A syslog szintaxisában kevésbé járatosak számára a syslog, a syslog.conf és a syslogd man oldalai segítenek. Ha meg kell változtatni az alapértelmezett user-t vagy szintet, akkor a következő opciókkal kell elindítani a slapd-t:
-s syslog-level |
Ez az opció mondja meg, hogy a slapd milyen hibakereső állapotait naplózza a syslog(8). A szint leírja az üzenetek mennyiségét. A következő kulcsszavak használhatók csökkenő sorrendben: emerg, alert, crit, err, warning, notice, info, debug. Példa: slapd -f myslapd.conf -s debug
-l syslog-local-user |
Kiválasztja a syslog(8) jellemző user-ét. Az értékek a LOCAL0, LOCAL1, egészen LOCAL7-ig terjedhetnek. LOCAL4 az alapértelmezett. Viszont ez a lehetőség csak azokon a rendszereken engedélyezett, amelyek támogatják a helyi usereket a syslog(8) jellemzőként.
Néhány pillantás a létrehozott naplókra (a példában: /usr/adm/ldaplog) segíthet felderíteni és megoldani sok problémát.
Ebben a fejezetben további LDAP dokumentációk felsorolása találhatók: hasznos linkek, könyvek és RFC-k.
Néhány, az LADP-ről hasznos információkat tartalmazó tartalmazó weboldal címe következik. Ezek alapján állítottam össze ezt a HOGYANt, szóval, amennyiben további információkra lenne szükséged, talán segítenek ezek az oldalak
University of Michigan LDAP oldal: http://www.umich.edu/~dirsvcs/ldap/
University of Michigan LDAP dokumentációs oldal: http://www.umich.edu/~dirsvcs/ldap/doc/
OpenLDAP Adminisztrátorok Kézikönyve (testvéroldal): http://www.openldap.org/doc/admin
Linux Directory Service: http://www.rage.net/ldap/
Red Hat és LDAP: http://www.redhat.com/docs/manuals/linux/RHL-9-Manual/ref-guide/ch-ldap.html
Mandrake Linux - OpenLDAP használata azonosításhoz: http://www.mandrakesecure.net/en/docs/ldap-auth.php
Az OpenLDAP használata más nyílt forráskódú projektekkel: ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf
Magyar nyelvű oldalak:
LDAP-ról pár szóban http://padre.web.elte.hu/ldap.html
Gentoo Linux - OpenLDAP hitelesítési útmutató http://www.gentoo.org/doc/hu/ldap-howto.xml
NOVELL - Fejlesztői oldalak http://www.novell.hu/developer/opensource.shtml
Az LDAP szerver installálása - U of SZEGED http://www.cab.u-szeged.hu/~bilickiv/h_op/inflab_2001_1_f/3/LDAP.htm
HOGYAN érjük el az LDAP adatbázist Evolution alól? http://kszk.sch.bme.hu/net/lists/evolution_ldap/
A legnépszerübb és a leghasznosabb LDAP témájú könyvek:
Mark Wilcox: Implementing LDAP
Howes and Smith: LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol
Howes, Smith, and Good: Understanding and Deploying LDAP Directory Servers
Az LDAP fejlesztőket támogató RFC-k:
RFC 1558: A String Representation of LDAP Search Filters
RFC 1777: Lightweight Directory Access Protocol
RFC 1778: The String Representation of Standard Attribute Syntaxes
RFC 1779: A String Representation of Distinguished Names
RFC 1781: Using the OSI Directory to Achieve User Friendly Naming
RFC 1798: Connectionless LDAP
RFC 1823: The LDAP Application Programming Interface
RFC 1959: An LDAP URL Format
RFC 1960: A String Representation of LDAP Search Filters
RFC 2251: Lightweight Directory Access Protocol (v3)
RFC 2307: LDAP as a Network Information Service