LDAP

A Unix/Linux szerverek üzemeltetése wikiből
(Változatok közti eltérés)
(Új oldal, tartalma: „Az LDAP”)
 
(→‎Hogyan állítsuk be az OpenLDAP szervert?: memberOf replikációjára oda kell figyelni)
 
(3 szerkesztő 44 közbeeső változata nincs mutatva)
1. sor: 1. sor:
−
Az LDAP
 +
Írta: Fülöp Balázs és [[User:KornAndras|Korn András]].
  +
  +
== Mi az LDAP? ==
  +
* '''LDAP''': '''L'''eightweight '''D'''irectory '''A'''ccess '''P'''rotocol
  +
* '''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
  +
  +
=== 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.
  +
  +
=== 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: [https://tools.ietf.org/html/rfc5805 2010. márciusa óta van RFC LDAPos tranzakciókezelésről], [http://www.openldap.org/lists/openldap-devel/201409/msg00004.html 2014. szeptembere óta pedig az OpenLDAP is megvalósítja] ([http://www.novell.com/documentation//edir88/edir88/data/b4r36pg.html 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)
  +
  +
=== 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:
  +
<pre>
  +
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
  +
</pre>
  +
* 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.
  +
  +
=== Mi a séma? ===
  +
  +
==== 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 [[A DNS működése|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.
  +
  +
==== 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.
  +
  +
=== 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.
  +
<pre>
  +
proto://host:port/DN?attributes?scope?filter?extensions
  +
</pre>
  +
* '''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 <tt>cn=Gipsz Jakab+relatedDomain=fenchurch.42.hu,ou=People,dc=42,dc=hu</tt>. 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).
  +
  +
=== 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
  +
<pre>
  +
$ 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
  +
</pre>
  +
* '''-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.
  +
  +
=== 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ó [http://www.openldap.org/doc/admin24/ dokumentációból]; helyette az [http://blog.suretecsystems.com/archives/40-OpenLDAP-Weekly-News-Issue-5.html#extended 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.
  +
  +
=== 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 <tt>passwd</tt>- és <tt>group</tt>-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 <tt>sudo</tt> konfigurációját is tarthatjuk LDAP-ban; így a <tt>/etc/sudoers</tt> fájlt sem kell gépről gépre másolgatni.
  +
  +
=== 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.
  +
<pre>
  +
#######################################################################
  +
# 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
  +
  +
</pre>
  +
* 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:
  +
<pre>
  +
SLAPD_SERVICES="ldaps:///"
  +
</pre>
  +
* é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:
  +
<pre>
  +
BASE dc=42,dc=hu
  +
URI ldapi:/// ldap://localhost ldaps://masikszerver
  +
TLS_CACERT /etc/ssl/certs/ca.crt
  +
</pre>
  +
  +
=== 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:
  +
<pre>
  +
#host 127.0.0.1
  +
uri ldapi:/// ldap://localhost ldaps://masikszerver
  +
</pre>
  +
* 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:
  +
<pre>
  +
passwd: files ldap
  +
group: files ldap
  +
shadow: files
  +
</pre>
  +
* 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.
  +
  +
=== Hogyan változtathatják meg a felhasználók a saját jelszavukat? ===
  +
  +
* Az <tt>ldappasswd</tt> nem pont erre való (barátságtalan a paraméterezése), úgyhogy
  +
* használhatjuk a sima <tt>passwd</tt> parancsot is, és az majd a PAM segítségével módosítja a jelszót az LDAP-ban.
  +
* A <tt>/etc/pam.d/common-password</tt> file-ba írjunk valami ilyesmit (ezt megteszi helyettük a libpam-ldap csomag):
  +
  +
<pre>
  +
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
  +
</pre>
  +
  +
* A <tt>/etc/pam_ldap.conf</tt> 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 <tt>pam_ldap.conf</tt>-ba írjuk be azt, hogy <tt>pam_password exop</tt> - 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ó.
  +
  +
=== 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:
  +
<pre>
  +
#!/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"
  +
</pre>
  +
* 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
  +
  +
[[Kép:ldapadmin.png]]
  +
  +
=== 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.
  +
  +
== 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 ;-)
  +
  +
== Ajánlott irodalom ==
  +
  +
* [ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf 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 :)
  +
  +
* [http://moduli.net/sysadmin/sarge-ldap-auth-howto.html 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 <tt>chsh</tt>-t és a <tt>chfn</tt>-t.
  +
  +
* [http://www.zytrax.com/books/ldap/ 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.

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

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

Tartalomjegyzék

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

[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 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.
A lap eredeti címe: „http://unixlinux.tmit.bme.hu/index.php?title=LDAP&oldid=5916”