LDAP

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

Tartalomjegyzék 1 Mi az LDAP? 1.1 Miből áll egy LDAP-on elérhető címtár? 1.2 Milyen műveleteket engedélyez az LDAP? 1.3 Mi az LDIF? 1.4 Mi a séma? 1.4.1 Bevezetés 1.4.2 Részletek 1.5 Mi az LDAP URL? 1.6 Hogyan keressünk az LDAP segítségével? 1.7 Skálázható? 1.8 Végülis mikor jó ez az egész? 1.9 Hogyan állítsuk be az OpenLDAP szervert? 1.10 Hogyan állítsuk be a központi autentikációt? 1.11 Hogyan változtathatják meg a felhasználók a saját jelszavukat? 1.12 Hogyan tegyük a DNS-t LDAP-ba? 1.13 Mi támogatja még? 2 Végezetül 3 Ajánlott irodalom

1 Mi az LDAP?

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

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

• A címtárban tárolt bejegyzések egy fát képeznek (directory tree), azaz egy gyökércsomóponttal rendelkező körmentes gráfot.
• A gráf csomópontjai a címszavak vagy bejegyzések (entries), amelyeknek sémától függően vannak kötelező és opcionális attribútumaik.
  • Minden csomópont egy-egy címszó; a közbülsők is és a levelek is.
  • A 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.

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)

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.

1.4 Mi a séma?

1.4.1 Bevezetés

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

1.4.2 Részletek

• Az osztályok között van öröklődés.
• Egy attribútum leírása a típusra, formátumra és az illeszthetőség vizsgálatára nézve tartalmaz információt.
  • Pl. megadható, van-e rendezés az attribútum lehetséges értékei között; az uidNumber és a gidNumber pl. ugyan numerikus, de sajnos nem rendezett attribútum, így nem tudjuk egyszerűen megtalálni mondjuk az 1000-nél kisebb UID-val rendelkező felhasználókat.
• Egy attribútumnak lehetnek álnevei (pl. a cn ugyanaz, mint a commonName).
• Az attribútumok lehetnek binárisak (pl. jpegPhoto), ilyenkor az LDIF (l. fent) base64 kódolt változatukat tartalmazza.
• Az objectClass-ok és attribútumok nevei globálisan egyediek (ne azzal kezdjük, hogy sajátot hozunk létre).
  • pl. az inetOrgPerson osztály, amit előszeretettel alkalmaznak személyek leírásához
    • 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.

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

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: [email protected]

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

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.

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.

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

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.

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

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

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.

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

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.