1.1. Mi az LDAP?

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.

1.2. Az LDAP működése

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.

1.3. LDAP hátterek, objektumok és tulajdonságok

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.

1.4. A dokumentum újabb változatai

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

1.5. Javaslatok és vélemények

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!

1.6. Köszönetnyilvánítás

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 !

1.7. Szerzői jog és licenc

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.

1.8. Magyar fordítás

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.

2.1. Előfeltételek

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.

2.2. A csomag letöltése

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.

2.3. A szerver csomag kitömörítése

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 -

2.4. A program beállítása

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.

2.5. A szerver fordí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ó .

3.1. Konfigurációs file formátuma

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ó.

3.2. Általános beállítási lehetőségek

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>):

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

3.3. Általános háttér opciók

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:

Példa:

backend bdb

Ez a bejegyzés jelzi egy új BDB háttér definíciójának kezdetét.

3.4. Általános háttér opciók

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

3.5. BDB adatbázis direktívák

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ó.

3.6. LDBM adatbázis lehetőségek

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

3.7. Hozzáférés szabályozási példák:

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.

3.8. Konfigurációs fájl példa

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

4.1. Parancssori opciók

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ö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.

4.2. Az LDAP kiszolgáló indítása

Á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.

4.3. Az LDAP kiszolgáló leállítása

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.

5.1. Adatbázis online létrehozása

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: 

5.2. Adatbázis offline létrehozása

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..

5.3. Bővebben az LDIF formátumról

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.

5.4. Az ldapsearch, ldapdelete és az ldapmodify progrmok

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).

6.1. LDAP Migrációs Eszközök

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:

http://dataconv.org/apps_ldap.html

6.2. Azonosítás LDAP használatával

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

6.3. SASL konfiguráció : Digest-MD5 azonosítás

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

6.4. Grafikus LDAP eszközök

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.

6.5. Naplók

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.

7.1. URL-ek

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/

7.2. Könyvek

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

7.3. RFC-k

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