LDAP

A lap jelenlegi, 2015. május 6., 22:13-kori változata

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

[szerkesztés] 1 Mi az LDAP?

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

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

• A címtárban tárolt bejegyzések egy fát képeznek (directory tree), azaz egy gyökércsomóponttal rendelkező körmentes gráfot.
• A gráf csomópontjai a címszavak vagy bejegyzések (entries), amelyeknek sémától függően vannak kötelező és opcionális attribútumaik.
  • Minden csomópont egy-egy címszó; a közbülsők is és a levelek is.
  • A protokoll lehetővé teszi, hogy egyes részfákat, a DNS-hez kicsit hasonlóan, más szervereken tároljunk. Ennek a neve itt nem delegáció, hanem referral ("ajánlás"?).
  • A DNS-sel való hasonlóság azonban itt véget is ér, mert:
    • A referral a teljes részfát egyértelműen a másik szerver hatókörébe utalja (a felsőbb szintű szerver nem tárol a részfába tartozó címszavakat).
    • Az Interneten nincs egy nagy, közös LDAP-gyökér (a világ LDAP-szerverei erdőt alkotnak, nem egyetlen fát).
      • (Egy LDAP-szerver amúgy több fát, vagy ugyanannak a fának több részfáját is menedzselheti, vagyis mégis van még egy hasonlóság a DNS-sel.)
• A sémák határozzák meg, milyen típusú bejegyzéseket vehetünk fel egyáltalán, és melyiknek milyen attribútumai lehetnek (l. később).
• Minden csomópont rendelkezik egy kitüntetett attribútummal, amely azonosítja a csomópontot a vele egy szinten, közös szülőtől származó csomópontok között - ez az RDN (relative distinguished name).
• A csomópontból a gyökérbe vezető út RDN-jei kiadják a csomópont megkülönböztető nevét - ez a DN (distinguished name).
• Az attribútumok lehetnek többértékűek (ezt is a séma határozza meg).
  • A többértékű attribútum olyan, amiből több is lehet ugyanannak a címszónak (pl. egy embernek lehet több emailcíme, vagy csoportnak több tagja).
• NB: a fa csomópontjai nem objektumok abban az értelemben, ahogyan az objektumorientált programozásnál használják ezt a szót, mert nem társíthatunk hozzájuk műveleteket.

[szerkesztés] 1.2 Milyen műveleteket engedélyez az LDAP?

• Start TLS: titkosítás nélkül indított csatornán titkosított kommunikáció kezdeményezése.
• Bind: autentikáció - bizony nem a csatlakozás, az anonim keresések során nem kerül sor bind műveletre. Egy kapcsolat során a kliens több bind műveletet is végrehajthat, így több különböző "entitás" (pl. felhasználó) nevében is küldhet kéréseket.
• Search: keresés - lásd később.
• Compare: összehasonlítás - nem egy attribútum értékét kérdezzük le, hanem elküldünk egy értéket és megkérdezzük, hogy azzal (vagy annak a jelszó hash-ével) egyezik-e.
• Add: új címszó hozzáadása.
• Delete: címszó törlése.
• Modify entry: címszó attribútumlistájának módosítása.
• Modify DN: címszó átnevezése.
• Abandon: megkezdett művelet (leginkább keresés) megszakítása.
• Unbind: ez viszont már a kapcsolat bontását jelenti (nem a bind ellentettje).
• Egy LDAP-kapcsolat során egy kliens több kérést küldhet a szervernek, és a kérések között nem kötelessége megvárni a szerver válaszát (enélkül az abandon értelmét is veszítené).
• A szerver semmilyen sorrendiséget nem garantál egy válaszon belül az abban szereplő címszavakra, az attribútumaikra, többértékű attribútum esetén az értékekre.
• Nincs tranzakciókezelés. Simán elképzelhető, hogy a műveleteink egy része végrehajtódik, más részük pedig nem.
  • Bréking: 2010. márciusa óta van RFC LDAPos tranzakciókezelésről, 2014. szeptembere óta pedig az OpenLDAP is megvalósítja (némelyik kereskedelmi LDAP-szerver már régebben is, az RFC draftjai alapján).
    • Kliensoldali felhasználásával még nem találkoztam (2015. elején)

[szerkesztés] 1.3 Mi az LDIF?

• LDIF: LDAP Data Interchange Format
• Sima szöveges reprezentációja egy vagy több LDAP-címszó kiválasztott attribútumainak.
• Olyasmi, mint egy SQL dump.
• Példa:

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

• Ez egy wheel nevű csoport leírása.
• Az attribútumok neveiben nem különböztetjük meg a kis- és a nagybetűt (case insensitive).
• Vegyük észre, hogy az RDN-t nem elegendő a DN-ben feltüntetni (a cn szerepel a dn-ben is és az attribútumok között is).
• Az objectClassok magyarázatát l. alább.

[szerkesztés] 1.4 Mi a séma?

[szerkesztés] 1.4.1 Bevezetés

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

[szerkesztés] 1.4.2 Részletek

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

[szerkesztés] 1.5 Mi az LDAP URL?

• Ha egy protokoll nem támogatja az URL-t (unified resource locator) az erőforrások (jelen esetben címszavak) azonosítására, akkor sokkal nehezebb eladni a menedzsmentnek. Ezért nyilvánvaló, hogy az LDAP-ban is szükség van URL-re.
• Csomópontok egy halmazát lehet vele kiválasztani.

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

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

[szerkesztés] 1.6 Hogyan keressünk az LDAP segítségével?

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

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

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

[szerkesztés] 1.7 Skálázható?

• Megvalósítástól függ (nyilván alapvetően nem a protokollon múlik a skálázhatóság, hanem a szerveralkalmazáson és azon, hogyan használjuk).
• Az OpenLDAP támogatja a master - slave replikákat és a 2.4-es verziótól a multimaster üzemmódot is.
  • A korábbi verziókkal is összegányolható a multimaster működés, de a fejlesztők kifejezetten ellenjavallottnak tartják.
  • A 2.4-es verzió multimaster működésének leírása egyelőre (2008. január végén) hiányzik az amúgy mostanra elég jónak mondható dokumentációból; helyette az LDAP weekly newsban olvashatunk róla.
• Felmerülhet a kérdés, hogy érdemes-e minden gépre slave-et rakni - ez jó lehet, mert:
  • Tehermentesíti a központi szervert (a keresések és lekérdezések tekintetében).
  • Rövidebbek a válaszidők (mivel nem lép fel hálózati késleltetés).
  • Ha egyetlen központi szerverünk lenne, az egyedi meghibásodási pont (SPoF) lenne; ha megállna, az élet is megállna.

[szerkesztés] 1.8 Végülis mikor jó ez az egész?

Tömören:

• Ha az adatbázisműveletek döntő többsége keresés jellegű ÉS
• nincs szükség tranzakciókra ÉS
• nincs szükség idegen kulcsokra és komoly kényszerekre (constraint) VAGY
• marhára unatkozunk.

Például építhető az LDAP-ra "Single Sign On", vagyis olyan rendszer, amikor mindenkinek csak egy accountja van, egy jelszóval, és minden jelszóvédett erőforrást azzal ér el.

Ha sok gépünk van, amelyeket ugyanazok a felhasználók használhatnak, és azon kapjuk magunkat, hogy passwd- és group-fájlokat másolgatunk közöttük, akkor valószínűleg jól járunk az LDAP-pal, mert van hozzá NSS- és PAM-modul is.

Az LDAP arra is jó, hogy pl. egy cég "névjegyalbumát" tartsuk benne (emberek nevét, beosztását, telefonszámát, emailcímét stb.). A szabványos protokoll miatt sokféle klienssel használhatjuk ezt az adatbázist, a különféle webmailektől kezdve a Thunderbirdön át a parancssorig.

A sudo konfigurációját is tarthatjuk LDAP-ban; így a /etc/sudoers fájlt sem kell gépről gépre másolgatni.

[szerkesztés] 1.9 Hogyan állítsuk be az OpenLDAP szervert?

• Debian alatt a slapd csomag tartalmazza
• Konfiguráció: /etc/ldap/slapd.conf (az alábbi példa LDAP-alapú autentikációhoz jó).
  • Elvileg már magában az LDAP-fában is tarthatjuk a konfigurációt, de szerintem nem érdemes, hacsak nem akarjuk LDAP-kliens segítségével módosítani vagy szerverek között replikálni.

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

# Features to permit
#allow bind_v2

# Schema and objectClass definitions
include /etc/ldap/schema/core.schema
include /etc/ldap/schema/cosine.schema
include /etc/ldap/schema/rfc2307bis.schema
include /etc/ldap/schema/inetorgperson.schema
include /etc/ldap/schema/authldap.schema
include /etc/ldap/schema/samba.schema
include /etc/ldap/schema/sudo.schema

# Where the pid file is put. The init.d script
# will not stop the server if you change this.
pidfile         /var/run/slapd/slapd.pid

# List of arguments that were passed to the server
argsfile        /var/run/slapd/slapd.args

# Read slapd.conf(5) for possible values
loglevel        768

# Where the dynamically loaded modules are stored
modulepath      /usr/lib/ldap
# memberof: dinamikusan generál memberOf: attribútumokat minden csoporttagnak minden csoporthoz
moduleload      memberof
# unique: egyediséget lehet vele kikényszeríteni
moduleload      unique
# back_hdb: ez egy adatbázisdriver
moduleload      back_hdb
# syncprov: a replikációt megvalósító modul
moduleload      syncprov
# smbk5pwd: jelszóváltáskor többféle hasht is képez az új jelszóból, így több szolgáltatás is használhatja
moduleload      smbk5pwd

# The maximum number of entries that is returned for a search operation
sizelimit unlimited

serverid 1

# The tool-threads parameter sets the actual amount of cpu's that is used
# for indexing.
tool-threads 4 

TLSCertificateFile /etc/ldap/ssl/server.crt   
TLSCertificateKeyFile /etc/ldap/ssl/server.key
TLSCACertificateFile /etc/ssl/certs/ca.crt
TLSVerifyClient never

#######################################################################
# Specific Backend Directives for hdb:
# Backend specific directives apply to this backend until another
# 'backend' directive occurs
backend         hdb

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

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

# rootdn directive for specifying a superuser on the database. This is needed
# for syncrepl.
rootdn          "cn=admin,dc=42,dc=hu"

# Where the database file are physically stored for database #1
directory       "/var/lib/ldap/42.hu"

# Indexing options for database #1
# pres should be used if use searches of the form 'mail=*' will be used.
# approx MUST be used if use searches of the form 'sn~=person' (a 'sounds-alike' search) will be used.
# eq should be used if searches of the form 'sn=smith' will be used i.e no wildcards are included (uses the EQUALITY rule only).
# sub should be used if use searches of the form 'sn=sm*' i.e wildcards are included (uses the SUBSTR rule).
# This rule may be enhanced by a using subinitial (optimised for 'sn=s*'),
# subany (optimised for 'sn=*n*') or
# subfinal (optimised for 'sn=*th'). One or more sub parameters may be included.
index   cn,mail,uid,sn,displayName,givenName pres,eq,approx,sub,subinitial
index   ipHostNumber eq
index   ipServiceProtocol eq
index   objectClass eq
index   ou eq 
index   sudoUser eq
index   sambaPrimaryGroupSID,sambaDomainName,sambaSIDList,sambaGroupType eq
index   sambaSID eq,sub
index   uidNumber,gidNumber,memberUid,member,memberOf eq

# Save the time that the entry gets modified, for database #1
lastmod on

# The userPassword by default can be changed
# by the entry owning it if they are authenticated.
# Others should not be able to see it, except the  
# admin entry below
# These access lines apply to database #1 only
access to attrs=userPassword,shadowLastChange,sambaPwdLastSet,sambaLMPassword,sambaNTPassword
        by dn="cn=admin,dc=42,dc=hu" write
        by dn="cn=egyikszerver,ou=Replicator,dc=42,dc=hu" read
        by dn="cn=masikszerver,ou=Replicator,dc=42,dc=hu" read   
        by dn="cn=authreader,dc=42,dc=hu" read
        by anonymous auth
        by self write
        by * none

access to attrs=departmentNumber,displayName,facsimileTelephoneNumber,homePhone,l,mobile,postalCode,preferredLanguage,roomNumber,st,street,telephoneNumber,title
        by dn="cn=admin,dc=42,dc=hu" write
        by self write
        by * read

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

access to dn.base="" by * read

access to *
        by dn="cn=admin,dc=42,dc=hu" write
        by dn="cn=chinook,ou=Replicator,dc=42,dc=hu" read
        by dn="cn=stop,ou=Replicator,dc=42,dc=hu" read   
        by * read

syncrepl rid=2
        provider=ldap://masikszerver
        type=refreshAndPersist
        retry="5 5 300 +"
        searchbase="dc=42,dc=hu"
        schemachecking=off
# azért kell a "+" is, hogy ne csak a séma által leírt, hanem az ldap-szerver által dinamikusan generált "operational" attríbutumokat is replikálja -- ilyen pl. a memberOf
        attrs="*,+" 
        bindmethod=simple
        binddn="cn=egyikszerver,ou=Replicator,dc=42,dc=hu"
        credentials=Diddgos!
        starttls=critical

# a memberof overlayt valószínűleg a replikáló overlay előtt kell megadni, hogy a memberof attribútumok is replikálódjanak
overlay memberof
memberof-dangling       drop
memberof-refint         true

# ettől lesz kétirányú a replikáció
mirrormode on

# ettől lesz replikáció egyáltalán
overlay syncprov
syncprov-checkpoint 100 10

overlay unique
unique_uri ldap:///ou=People,dc=42,dc=hu?uidNumber,uid,mail?sub
unique_uri ldap:///ou=Group,dc=42,dc=hu?gidNumber?sub
unique_uri ldap:///dc=42,dc=hu?sambaSID?sub

overlay smbk5pwd
smbk5pwd-enable samba
smbk5pwd-must-change 0

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

SLAPD_SERVICES="ldaps:///"

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

BASE    dc=42,dc=hu
URI     ldapi:/// ldap://localhost ldaps://masikszerver
TLS_CACERT      /etc/ssl/certs/ca.crt

[szerkesztés] 1.10 Hogyan állítsuk be a központi autentikációt?

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

#host 127.0.0.1
uri ldapi:/// ldap://localhost ldaps://masikszerver

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

passwd:         files ldap
group:          files ldap
shadow:         files

• A libpam-ldap gyakorlatilag ugyanazt a konfigurációs fájlt használja, csak egy másik példányban (/etc/pam_ldap.conf); akár össze is hardlinkelhetjük a kettőt.
• Végezetül a /etc/pam.d/common-* fájlokat kell módosítani; ezt újabban a Debian-csomagok maguktól megteszik.
• Telepíthetünk nscd-t (Name Service Cache Daemon), így az NSS nem fordul minden kéréssel az LDAP-szerverhez.
  • Mindenképpen legyen nscd-nk, ha nem a helyi gépen futó LDAP-szervert használunk.
• Ha minden jól megy és nem felejtettem ki semmit, innentől működik a központi hitelesítés.
  • Feltéve, hogy vannak felhasználók az LDAP-fában, ugye.

[szerkesztés] 1.11 Hogyan változtathatják meg a felhasználók a saját jelszavukat?

• Az ldappasswd nem pont erre való (barátságtalan a paraméterezése), úgyhogy
• használhatjuk a sima passwd parancsot is, és az majd a PAM segítségével módosítja a jelszót az LDAP-ban.
• A /etc/pam.d/common-password file-ba írjunk valami ilyesmit (ezt megteszi helyettük a libpam-ldap csomag):

password  [success=2 default=ignore]  pam_unix.so obscure sha512
password  [success=1 user_unknown=ignore default=die]  pam_ldap.so use_authtok try_first_pass
password  requisite  pam_deny.so
password  required  pam_permit.so

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

[szerkesztés] 1.12 Hogyan tegyük a DNS-t LDAP-ba?

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

#!/bin/bash

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

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

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

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

cd /
rmdir "$temp"

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

Fájl:ldapadmin.png

[szerkesztés] 1.13 Mi támogatja még?

• Postfix: jól működik és egyszerűen telepíthető az LDAP modulja - az alias-tól az autoBcc-ig mindent LDAP-ba tehetünk
• AMaViS: támogatja az LDAP-ot, felhasználónként lehet a vírus-ellenőrzést be- és kikapcsolni; a fekete- és fehérlista 2007-ben nem működik (pedig a dokumentáció alapján kellene)
• Samba: ha komolyabb Windows domaint szeretnénk csinálni (pl. több domain controllerrel), nemigen ússzuk meg az LDAP-ot.
• Apache: tud LDAP-ból autentikálni
• sudo
• Számos javaszerencsétlenség, webmail, enterprise calendar stb. stb.

[szerkesztés] 2 Végezetül

• az LDAP jó dolog, ha az adatbázison végzendő műveletek atomiak, és a keresések vannak túlsúlyban, de...
• ...egy jótanács: soha ne mappeljünk relációs sémát LDAP-ra ;-)

[szerkesztés] 3 Ajánlott irodalom

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

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

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