LDAP
a (→Mi a séma?: alias, mint abstract osztály) |
(→Hogyan állítsuk be az OpenLDAP szervert?: memberOf replikációjára oda kell figyelni) |
||
(2 szerkesztő 20 közbeeső változata nincs mutatva) | |||
1. sor: | 1. sor: | ||
+ | Írta: Fülöp Balázs és [[User:KornAndras|Korn András]]. |
||
+ | |||
== Mi az LDAP? == |
== Mi az LDAP? == |
||
* '''LDAP''': '''L'''eightweight '''D'''irectory '''A'''ccess '''P'''rotocol |
* '''LDAP''': '''L'''eightweight '''D'''irectory '''A'''ccess '''P'''rotocol |
||
7. sor: | 9. sor: | ||
=== Miből áll egy LDAP-on elérhető címtár? === |
=== Miből áll egy LDAP-on elérhető címtár? === |
||
− | * a címtár egy fa ('''directory tree'''), azaz egy gyökér csomóponttal rendelkező körmentes gráf |
+ | * 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 ('''entries'''), melyeknek sémától függően vannak kötelező és opcionális attribútumaik |
+ | * 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 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''') |
+ | ** Minden csomópont egy-egy címszó; a közbülsők is és a levelek is. |
− | * 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''') |
+ | ** 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"?). |
− | * az attribútumok lehetnek '''többértékűek''' (ezt is a séma határozza meg) |
+ | ** 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? === |
=== 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 - ritkán használt, amióta támogatott az SSL feletti 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 anoním keresések enélkül működnek |
+ | * '''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 |
+ | * '''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 |
+ | * '''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 |
+ | * '''Add''': új címszó hozzáadása. |
− | * '''Delete''': címszó törlése |
+ | * '''Delete''': címszó törlése. |
− | * '''Modify entry''': címszó attribútumlistájának módosítása |
+ | * '''Modify entry''': címszó attribútumlistájának módosítása. |
− | * '''Modify DN''': címszó átnevezése - ez nekem OpenLDAP alatt csak levél típusú csomópontra működött, és annál is csak RDN-re |
+ | * '''Modify DN''': címszó átnevezése. |
− | * '''Abandon''': megkezdett művelet megszakítása |
+ | * '''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) |
+ | * '''Unbind''': ez viszont már a kapcsolat bontását jelenti (nem a bind ellentettje). |
− | * NB1: 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é) |
+ | * 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é). |
− | * NB2: 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 |
+ | * 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. |
− | * NB3: igen, tényleg '''hiányzik a tranzakció-kezelés''' |
+ | * ''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? === |
=== Mi az LDIF? === |
||
* LDIF: '''LDAP Data Interchange Format''' |
* LDIF: '''LDAP Data Interchange Format''' |
||
− | * sima szöveges leírása egy vagy több LDAP címszó kiválasztott attribútumainak |
+ | * Sima szöveges reprezentációja egy vagy több LDAP-címszó kiválasztott attribútumainak. |
− | * RDBMS adminok gondoljanak egy SQL dump-ra (mivel gyakorlatilag egy '''dump''' egy keresés eredményeiről) |
+ | * Olyasmi, mint egy SQL dump. |
+ | * Példa: |
||
<pre> |
<pre> |
||
dn: cn=wheel,ou=Group,dc=42,dc=hu |
dn: cn=wheel,ou=Group,dc=42,dc=hu |
||
37. sor: | 39. sor: | ||
gidNumber: 9999 |
gidNumber: 9999 |
||
objectClass: posixGroup |
objectClass: posixGroup |
||
+ | objectClass: groupOfNames |
||
objectClass: top |
objectClass: top |
||
memberUid: balazs |
memberUid: balazs |
||
+ | member: uid=balazs,ou=People,dc=42,dc=hu |
||
</pre> |
</pre> |
||
− | * ez egy wheel nevű csoport leírása |
+ | * Ez egy wheel nevű csoport leírása. |
− | * NB1: az attribútumok neveiben nem különböztetjük meg a kis- és a nagybetűt ('''case insensitive''') |
+ | * Az attribútumok neveiben nem különböztetjük meg a kis- és a nagybetűt ('''case insensitive'''). |
− | * NB2: az RDN-t nem elegendő a DN-ben feltüntetni |
+ | * 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? === |
=== Mi a séma? === |
||
− | * 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 |
+ | ==== Bevezetés ==== |
− | ** a mezők ('''attribútumok''') között lehet kötelező és opcionális |
+ | * A '''séma''' osztályok és attribútumok definíciója. |
− | * a séma adja meg: |
+ | ** Kicsit olyasmi, mint a relációs adatbázisok "sémája": mezők és típusaik vannak megadva. |
− | ** milyen '''objectClass'''ok léteznek |
+ | ** A mezők ('''attribútumok''') között lehet kötelező és opcionális. |
− | ** az egyes osztályokba ('''objectClass''') tartozó entitásoknak milyen attribútumai lehetnek, és ezek közül melyik kötelező |
+ | ** Szép formális szintaxis írja le, hogy az egyes attribútumok milyen típusú adatot tárolnak (pl. szám vagy szöveg), |
− | ** az attribútumok milyen típusúak |
+ | ** és azt, hogy melyik bejegyzésfajtának (osztálynak) milyen attribútumokkal kell rendelkeznie, ill. melyek megengedettek még. |
− | ** az egyes attribútumok értékeinek összehasonlításkor legyen-e különbség a kis- és nagybetűk között |
+ | * A bejegyzéstípus neve: objectClass. |
− | * vannak absztrakt ('''abstract'''), strukturális ('''structural''') és kiegészítő ('''auxiliary''') osztályok |
+ | ** A létező objectClassok típusát a séma határozza meg. |
− | ** absztrakt: az LDAP alapvető struktúrájához tartozik; pl. ''top'' (nincsenek a felhasználó számára érdekes tulajdonságai) |
+ | ** Háromféle objectClass létezik: strukturális ('''structural'''), kiegészítő ('''auxiliary''') és absztrakt ('''abstract'''). |
− | *** ilyen az ''alias'' is, ami a [[A DNS működése|DNS]] CNAME-jének a helyi megfelelője |
+ | ** 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). |
− | ** strukturális: alapvető tulajdonságcsoportokat tartalmaz, amelyek általában logikailag kizárják egymást |
+ | ** 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). |
− | *** pl. ''person'' vagy ''posixGroup'' - nem lenne értelme, hogy ugyanaz az entitás mindkét osztályba beletartozzon |
+ | *** Ilyen az ''alias'' is, ami a [[A DNS működése|DNS]] CNAME-jének a helyi megfelelője |
− | *** ezért egy entitás egyszerre pontosan egy strukturális objectClassba tartozhat |
+ | ** Strukturális objectClass: alapvető tulajdonságcsoportokat tartalmaz, amelyek általában logikailag kizárják egymást. |
− | ** kiegészítő objectClass: csak bizonyos felhasználás számára hasznos új attribútumokat tartalmaz |
+ | *** Pl. ''inetOrgPerson'' vagy ''groupOfNames'' - nem lenne értelme, hogy ugyanaz az entitás mindkét osztályba beletartozzon. |
− | *** 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) |
+ | ** Kiegészítő objectClass: csak bizonyos felhasználás számára hasznos új attribútumokat tartalmaz. |
− | *** egy entitás tetszőlegesen sok kiegészítő objectClassba tartozhat |
+ | *** 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 számokból és pontokból álló globálisan egyedi azonosító (ezért sem egyszerű saját objectClass-t csinálni) |
+ | ** 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. |
+ | *** 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. |
− | * egy címszónak legalább egy strukturális osztály kötelező attribútumaival rendelkeznie kell |
+ | *** 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. |
− | * 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''' tartalmaz információt |
+ | ==== Részletek ==== |
− | * egy attribútumnak lehetnek '''álnevei''' (pl. cn ugyanaz, mint a commonName) |
+ | |
− | * az attribútumok lehetnek binárisak (pl. jpegPhoto), ilyenkor az LDIF base64 kódolt változatukat tartalmazza |
+ | * Az osztályok között van '''öröklődés'''. |
− | * az objectClass-ok és attribútumok nevei globálisan egyediek (ne azzal kezdjük, hogy sajátot hozunk létre) |
+ | * 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. az inetOrgPerson osztály, amit előszeretettel alkalmaznak személyek leírásához: |
+ | ** 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. |
− | ** 2 kötelező attribútummal bír: cn és sn (surname); mindkettőt a person osztálytól örökölte |
+ | * Egy attribútumnak lehetnek '''álnevei''' (pl. a ''cn'' ugyanaz, mint a ''commonName''). |
− | ** 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 |
+ | * Az attribútumok lehetnek binárisak (pl. jpegPhoto), ilyenkor az LDIF (l. fent) base64 kódolt változatukat tartalmazza. |
− | * 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 |
+ | * 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? === |
=== 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 |
+ | * 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 |
+ | * Csomópontok egy halmazát lehet vele kiválasztani. |
<pre> |
<pre> |
||
proto://host:port/DN?attributes?scope?filter?extensions |
proto://host:port/DN?attributes?scope?filter?extensions |
||
</pre> |
</pre> |
||
− | * '''proto''': ldap, vagy ldaps (LDAP+SSL) |
+ | * '''proto''': ldap, vagy ldaps (LDAP+SSL). |
− | * '''host''': DNS név vagy IP cím |
+ | * '''host''': DNS-név vagy IP-cím. |
− | * '''port''': port szám, opcionális (alapértelmezés ldap esetén 389, ldaps esetén 636) |
+ | * '''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 |
+ | * '''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). |
** 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 (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. |
*** 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 |
+ | * '''attributes''': meglepő módon az attribútumok listája; opcionális. |
− | * '''scope''': base, ha pontosan egy címszót keresünk; one, ha a DN-ben megadott csomópont közvetlen gyermekei között keresünk; sub, ha egy részfában keresünk - NB: az, hogy melyik az alapértelmezés, implementáció-függő; opcionális |
+ | * '''scope''': A keresés mélysége. Lehetséges értékei: |
− | * '''filter''': ez egy keresési szűrő (lásd később), opcionális |
+ | ** Ha pontosan egy címszót (a megadottat) keresünk: ''base''. |
− | * '''extensions''': minden, ami az RFC-ből kimaradt (ja igen, opcionális) |
+ | ** 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? === |
=== 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) |
+ | * 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 |
+ | * Telepítsünk egy LDAP-klienst; Debian alatt az '''ldap-utils''' csomag tartalmazza az OpenLDAP kliensoldali segédprogramjait. |
− | * mivel a legtöbb LDAP kliens implementáció 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 manual-ban a paraméterezésnek |
+ | * 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> |
<pre> |
||
$ ldapsearch -LLL \ |
$ ldapsearch -LLL \ |
||
108. sor: | 112. sor: | ||
mail: ifj.fulop.balazs@42.hu |
mail: ifj.fulop.balazs@42.hu |
||
</pre> |
</pre> |
||
− | * '''-LLL''': a legszűkszavúbb, kommentmentes LDIF formátumot kérjük |
+ | * '''-LLL''': a legszűkszavúbb, kommentmentes LDIF-formátumot kérjük. |
− | * '''-H''': LDAP URI megadása (nem URL!) |
+ | * '''-H''': LDAP URI megadása (nem URL!). |
− | * '''-b''': a keresés kiindulópontja |
+ | * '''-b''': a keresés kiindulópontja. |
− | * '''-s''': a keresés hatóköre |
+ | * '''-s''': a keresés hatóköre (scope). |
− | * '''-x''': SASL nélkül kapcsolódunk |
+ | * '''-x''': [[SASL]] nélkül kapcsolódunk. |
* '''filter''': minden szűrő zárójelek között, logikai operátorok prefix jelöléssel |
* '''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 |
* '''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 |
+ | * 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ó? === |
=== 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) |
+ | * 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 (2008. elején még ki nem adott) verziótól a multimaster üzemmódot is |
+ | * 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 korábbi verziókkal is összegányolható a multimaster működés, de a fejlesztők kifejezetten ellenjavallottnak tartják. |
− | * felmerülhet a kérdés, hogy érdemes-e minden gépre slave-et rakni - ez jó lehet, mert: |
+ | ** 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. |
− | ** tehermentesíti a központi szervert |
+ | * Felmerülhet a kérdés, hogy érdemes-e minden gépre slave-et rakni - ez jó lehet, mert: |
− | ** gyorsabbak a válaszidők |
+ | ** Tehermentesíti a központi szervert (a keresések és lekérdezések tekintetében). |
− | * ki kell próbálni ;-) |
+ | ** 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? === |
=== Végülis mikor jó ez az egész? === |
||
− | * ha az adatbázisműveletek döntő többsége keresés jellegű '''ÉS''' |
+ | |
+ | 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 tranzakciókra '''ÉS''' |
||
− | * adatbázis szinten akarjuk szabályozni a felhasználók hozzáférését (lásd később) '''ÉS''' |
||
* nincs szükség idegen kulcsokra és komoly kényszerekre (constraint) '''VAGY''' |
* nincs szükség idegen kulcsokra és komoly kényszerekre (constraint) '''VAGY''' |
||
− | * ha marhára unatkozunk |
+ | * marhára unatkozunk. |
− | == Hogyan használjuk az OpenLDAP-ot központi konfigurációhoz? == |
+ | 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. |
− | * szükség van egy '''LDAP szerverre''' mindenféle '''*-ldap''' csomagokra, és sok-sok szkriptelésre |
+ | |
+ | 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? === |
=== Hogyan állítsuk be az OpenLDAP szervert? === |
||
* Debian alatt a '''slapd''' csomag tartalmazza |
* Debian alatt a '''slapd''' csomag tartalmazza |
||
− | * konfiguráció: '''/etc/ldap/slapd.conf''' |
+ | * 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> |
<pre> |
||
− | # This is the main slapd configuration file. See slapd.conf(5) for more |
||
− | # info on the configuration options. |
||
− | |||
####################################################################### |
####################################################################### |
||
# Global Directives: |
# Global Directives: |
||
+ | |||
+ | # Features to permit |
||
+ | #allow bind_v2 |
||
# Schema and objectClass definitions |
# Schema and objectClass definitions |
||
− | include /etc/ldap/schema/core.schema |
+ | include /etc/ldap/schema/core.schema |
− | include /etc/ldap/schema/cosine.schema |
+ | include /etc/ldap/schema/cosine.schema |
− | include /etc/ldap/schema/nis.schema |
+ | include /etc/ldap/schema/rfc2307bis.schema |
− | include /etc/ldap/schema/inetorgperson.schema |
+ | include /etc/ldap/schema/inetorgperson.schema |
− | include /etc/ldap/schema/authldap.schema |
+ | include /etc/ldap/schema/authldap.schema |
+ | include /etc/ldap/schema/samba.schema |
||
+ | include /etc/ldap/schema/sudo.schema |
||
− | # Schema check allows for forcing entries to |
+ | # Where the pid file is put. The init.d script |
− | # match schemas for their objectClasses's |
+ | # will not stop the server if you change this. |
− | schemacheck on |
+ | pidfile /var/run/slapd/slapd.pid |
− | # ... |
+ | # List of arguments that were passed to the server |
+ | argsfile /var/run/slapd/slapd.args |
||
− | TLSCACertificateFile /etc/ldap/certs/cert.pem |
+ | # Read slapd.conf(5) for possible values |
− | TLSCertificateFile /etc/ldap/certs/cert.pem |
+ | loglevel 768 |
− | TLSCertificateKeyFile /etc/ldap/certs/key.pem |
||
+ | # 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 |
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 Directives for database #1, of type bdb: |
+ | # 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 specific directives apply to this databasse until another |
||
# 'database' directive occurs |
# 'database' directive occurs |
||
− | database bdb |
+ | database hdb |
# The base of your directory in database #1 |
# The base of your directory in database #1 |
||
suffix "dc=42,dc=hu" |
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 |
# Indexing options for database #1 |
||
− | index objectClass eq |
+ | # pres should be used if use searches of the form 'mail=*' will be used. |
− | index cn eq |
+ | # approx MUST be used if use searches of the form 'sn~=person' (a 'sounds-alike' search) will be used. |
− | index uid eq |
+ | # 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). |
− | index mail eq |
+ | # sub should be used if use searches of the form 'sn=sm*' i.e wildcards are included (uses the SUBSTR rule). |
− | index dc eq |
+ | # 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" |
access to dn.sub="ou=DNS,dc=42,dc=hu" |
||
by dn="cn=admin,dc=42,dc=hu" write |
by dn="cn=admin,dc=42,dc=hu" write |
||
− | by dn="cn=dnsadmin,ou=system,dc=42,dc=hu" read |
+ | by dn="cn=dnsadmin,dc=42,dc=hu" read |
by * none |
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> |
</pre> |
||
* fent látható, hogyan kell megadni a tanúsítványt és a privát kulcsot az '''SSL'''-es eléréshez |
* 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 |
* '''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 az indexek legenerálásához. |
+ | * '''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 |
+ | * '''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: |
* 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> |
<pre> |
||
203. sor: | 262. sor: | ||
<pre> |
<pre> |
||
BASE dc=42,dc=hu |
BASE dc=42,dc=hu |
||
− | URI ldaps://localhost/ |
+ | URI ldapi:/// ldap://localhost ldaps://masikszerver |
− | TLS_REQCERT never |
+ | TLS_CACERT /etc/ssl/certs/ca.crt |
</pre> |
</pre> |
||
− | * a tanúsítvány-ellenőrzést csak akkor kapcsoljuk ki, ha előfordulhat, hogy az valamiért nem sikerül (pl. loopback interfészen szeretnénk elérni a szervert, és a tanúsítvány CN mezője nem localhost-ot tartalmaz ;-) - jó, belenyúlhatnánk a DNS-be is...) |
||
=== Hogyan állítsuk be a központi autentikációt? === |
=== Hogyan állítsuk be a központi autentikációt? === |
||
213. sor: | 271. sor: | ||
<pre> |
<pre> |
||
#host 127.0.0.1 |
#host 127.0.0.1 |
||
− | uri ldaps://127.0.0.1/ |
+ | uri ldapi:/// ldap://localhost ldaps://masikszerver |
</pre> |
</pre> |
||
* itt érdemes IP címet használni, ha lehet, hogy az NSS ne végezzen névfeloldást |
* itt érdemes IP címet használni, ha lehet, hogy az NSS ne végezzen névfeloldást |
||
222. sor: | 280. sor: | ||
shadow: files |
shadow: files |
||
</pre> |
</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''') - nem baj, ezt is átírjuk: |
+ | * 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> |
<pre> |
||
− | #host 127.0.0.1 |
+ | password [success=2 default=ignore] pam_unix.so obscure sha512 |
− | uri ldaps://127.0.0.1/ |
+ | 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> |
</pre> |
||
− | * végezetül a '''/etc/pam.d/common-*''' fájlokat kell módosítani, az alábbi séma szerint: |
+ | |
− | <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...). |
− | auth [success=1 default=ignore] pam_unix.so nullok_secure |
+ | ** Ezt a két fájlt is összehardlinkelhetjük amúgy. |
− | auth required pam_ldap.so use_first_pass |
+ | * 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. |
− | auth required pam_permit.so |
+ | * 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; |
− | </pre> |
+ | ** 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. |
− | * a fentit meg kell írni az account, password és session szekciókra is |
+ | ** Ez minket persze nem érint, hiszen úgyis SSL-t használunk, úgyhogy jó nekünk a plaintext autentikáció és a hash-elt jelszó. |
− | * NB1: ha azt szeretnénk, hogy a sima passwd parancs megváltoztassa a jelszavakat az LDAP adatbázisban, 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/ldap.secret''' fájlba (mód: 0600, de akkor is...) |
||
− | * NB2: opcionálisan telepíthetünk '''nscd'''-t (Name Service Cache Daemon), így az NSS nem fordul minden kéréssel az LDAP szerverhez |
||
− | * ha minden jól megy és nem felejtettem ki semmit, innentől működik a központi hitelesítés |
||
=== Hogyan tegyük a DNS-t LDAP-ba? === |
=== Hogyan tegyük a DNS-t LDAP-ba? === |
||
274. sor: | 332. sor: | ||
[[Kép:ldapadmin.png]] |
[[Kép:ldapadmin.png]] |
||
− | === Kikkel működik még? === |
+ | === 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 |
* 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 már nem működik (pedig a dokumentáció alapján kellene) |
+ | * 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: a samba.schema telepítése után a sambaSamAccount megvalósításával a személyekhez eltárolhatók a sambaLMPassword és a sambaNTPassword mezők (arra nem jöttem rá, hogy az Samba-nak miért van szüksége két hash-re) - de még ezután is nagyon macerás a beállítása |
+ | * Samba: ha komolyabb Windows domaint szeretnénk csinálni (pl. több domain controllerrel), nemigen ússzuk meg az LDAP-ot. |
− | * Apache: egy nagyon szerény tudású LDAP modullal a VirtualHost-ok kitehetők LDAP-ba - de a DocumentRoot-on kívül ne akarjunk állítgatni semmit... |
+ | * Apache: tud LDAP-ból autentikálni |
+ | * sudo |
||
+ | * Számos javaszerencsétlenség, webmail, enterprise calendar stb. stb. |
||
== Végezetül == |
== 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... |
* 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 relációs sémát LDAP-ra ;-) |
+ | * ...egy jótanács: '''soha''' ne mappeljünk relációs sémát LDAP-ra ;-) |
− | * egy másik: a rendszerusereket mindig hagyd meg a /etc/passwd-ben, mert: |
||
− | ** miért legyen mysql felhasználó olyan gépen, ahol nincs mysql szerver? |
||
− | ** ha egyik gépen letörlöd a mysql-t, és a csomagkezelő viszi a felhasználót is, az miért legyen hatással a többi gépre? |
||
== Ajánlott irodalom == |
== Ajánlott irodalom == |
||
− | * [ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf ftp://kalamazoolinux.org/pub/pdf/ldapv3.pdf] - ez egy prezentáció az LDAPról; olvasva is érthető |
+ | * [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.
[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)
- 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).
[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.
- pl. az inetOrgPerson osztály, amit előszeretettel alkalmaznak személyek leírásához
[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
[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.