Informatika | Felsőoktatás » Tóth László Attila - LDAP és Kerberos alapú rendszer megvalósítása

LDAP és Kerberos alapú rendszer megvalósítása Tóth László Attila (panther@elte.hu) 2009. december 3 Tartalomjegyzék Előszó 1 1. Bevezetés 3 2. DNS Server 2.1 A namedconf beállítása 2.2 A névről IP-re feloldó zóna fájl 2.3 Az IP-ről névre fordító (reverse) zóna fájl 2.4 A másodlagos névkiszolgáló(k) beállítása . . . . 5 5 6 7 7 3. További szerverek (dhcp, ntp) 3.1 Dinamikus IP címek (dhcp server) 3.2 Időkiszolgáló (ntp server) 9 9 9 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4. Tanúsítvány-kiszolgáló (CA) és titkosítás 4.1 A nyilvános kulcsú rendszerek és a tanúsítványok 4.2 Tanúsítványok készítése 4.21 opensslcnf 4.22 Parancsok, parancsfájlok 4.3 Biztonsági megfontolások . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 11 12 12 14 16 5. Az ldap és az OpenLDAP kiszolgáló 5.1 Mi is az ldap? 5.2 Telepítés 5.3 A szerver beállítófájlja: a slapdconf 5.4 Az ldapconf 5.5 A rendszer felkészítése az ldap használatához 5.51 nss-ldap 5.6 Az adatok feltöltése 5.61 ldap bejegyzések hozzáadása 5.62 Az alapvető bejegyzések 5.63 A többi bejegyzés 5.64 Az ldap bejegyzések módosítása 5.7 Titkosítás 5.8 Kerberos alapú hitelesítés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 17 17 18 20 20 21 21 22 22 23 25 26 26 . . . . . . . . . . . . . . . . . . . . . . . . . . ii 6. Levéltovábbítás és levélfogadás 6.1 Postfix 6.2 /etc/postfix/maincf 6.3 /etc/mail/aliases 6.4 LDAP-ban tárolt alias-ok 6.5 Virtuális tartományok Tartalomjegyzék . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7. Kerberos 7.1 A kerberos beállítása 7.11 /etc/krb5conf illetve DNS bejegyzések 7.12 A realm létrehozása 7.2 A kerberos bejegyzések létrehozása és listázása 7.21 A KDC beállítása 7.3 Szolgáltatások hozzáadása 7.4 Jegyek igénylése, kezelése 7.5 A pam beállítása 8. Cyrus (IMAP) . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 29 30 30 31 31 . . . . . . . . 35 35 35 37 38 39 40 40 41 43 9. Spam- és vírusszűrés 47 9.1 A ClamAV beállítása 47 9.2 A Postfix beállítása az Amavisd-New használatára 48 10.SSL, OpenLDAP, SASL beállítása 49 11.Levelezőkliensek beállítása 51 11.1 Mutt 51 11.2 Thunderbird 51 11.21 A kiszolgáló megadása 51 Források, javasolt oldalak 53 Egy slapd.conf állomány 55 Irodalomjegyzék 58 Előszó A számítógépek és az

Internet elterjedésével egyre több helyen épülnek ki sok felhasználós, számos szolgáltatást nyújtó rendszerek. A legtipikusabb szolgáltatások a bejelentkezést (parancssor kapást) és a levelezést teszik lehetővé. Kezdetben egy-egy nagy gép volt, amihez terminálokon keresztül csatlakoztak a felhasználók, később egyre gyakoribbá vált, hogy több számítógéphez is hozzáférhetnek, ámde még elegendő volt a bejelentkezéshez, azonosításhoz szükséges állományok átmásolása minden gépre. Ma már nem kerülhető el ezek az adatok központi tárolása, ahol néhány kifejezetten erre a célra fenntartott kiszolgáló számítógép látja el a tárolás feladatát. A felhasználó azonosítása során ezeket a kiszolgálókat kérdezi meg a rendszer, hogy ismerik-e azt, aki megpróbál bejelentkezni, illetve a helyes jelszót adta-e meg. A különböző operációs rendszerek különböző megoldást nyújthatnak erre, azonban az elterjedt megoldások

lényegében azonosak. A helyenként megvalósított hitelesítés Linux esetében lehetséges adatbázisból (pl. MySQL), a gyakori pedig ldap vagy ldap és Kerberos alapokon nyugszik Nagyvállalati környezetben is ez utóbbit használják, méghozzá tisztán Microsoft Windows alapú hálózat esetén Active Directory alapú tartományvezérlőkkel (pdc, bdc), vegyes környezetben pedig vagy Active Directory és Services for Unix segítségével egy Windows szerverrel, vagy pedig ldap vagy ldap és Kerberos használatával egy vagy több linuxos kiszolgálóval. Ez a jegyzet elsősorban Linuxokon használt megoldásról szól, bár más Unix-szerű rendszereken is hasonlóan beállítható. Az ldap és a Kerberos a két legfontosabb terület, azonban a biztonságos használatra és a spam- és vírusszűréssel ellátott levelezőszerverek beállításáról is szó esik A jegyzet viszonylag nagy felhasználói réteget céloz meg, hiszen részben azoknak készült – és

folyamatosan bővül –, akik ezzel szeretnének foglalkozni, azonban esetleg még nincsenek teljesen tisztában, hogy mi micsoda, és keresnek egy magyar nyelvű leírást, valamint azoknak is, akik jól ismerik ezeket a megoldásokat, csak valamelyik részfeladathoz szükségük van segítségre, támpontra. Budapest, 2007. március 1 Tóth László Attila panther@elte.hu 1. fejezet Bevezetés Bár ma a számítógépek és az Internet elterjedésével egyre több helyen épülnek ki sokfelhasználós, számos szolgáltatást nyújtó rendszerek, bonyolult kezdetben a felhasználók hitelesítésére elegendő volt egy egyszerű szövegfájl, amely tartalmazta a felhasználó adatait, valamint a jelszavát is. Mindenkinek joga volt olvasni ezt a fájlt, a jelszavak tárolása ezáltal nem volt biztonságos, de az akkori gépigénye miatt nem volt érdemes megpróbálni visszafejteni Ezért a jelszavakat később már külön állományban tárolták, amit a gépen egyetlen

felhasználó, a root tudott mind írni, mind olvasni. A biztonsági problémát sikerült elhárítani, azonban két további probléma változatlanul fennállt, az egyik az, hogy néhány ezer vagy különösen több tízezer felhasználó esetén kezelhetetlenné vált mind módosítás, mind keresés esetén. A másik akkor merült fel, ha egyazon felhasználónak több gépre is van bejelentkezési joga, ennek megfelelően ma sokszor egy-egy központi szerveren létrehozzák a felhasználó fiókját (ahol a fájljai, könyvtárai, tehát lényegében minden adata tárolódik), így számos egyéb gépen (például laborokban) azonos körülmények között folyhat a munka. A felhasználókat tároló fájlt minden gépre át kellene másolni, módosításokat követni, ami nagyon nehézkes, a probléma ugyanaz, mint mint alig több, mint egy évtizeddel korábban gépek azonosításával, amikor sok gép volt már, és az őket azonosító számokat, valamint a könnyebb

megjegyezhetőség végett bevezetett beszédes neveket összekapcsoló állományokat körülményes volt karbantartani. Ezért bevezették a névkiszolgálók rendszerét, s csak egy-egy gépen kell a módosításokat elvégezni. A hitelesítésnél ugyanez a megoldás, egy központi gépen tárolható a felhasználó összes adata, jelszava. Többféle megoldás is szóba kerülhet, például adatbázisban (MySQL, Oracle, stb.), vagy épp egy hierarchikus rendszerben (pl ldap-ban) történő tárolás Az ldap protokoll egy könnyen kezelhető, gyors megoldást nyújt, ezt valósítja meg az OpenLDAP szerver, valamint a Microsoft Active Directory (AD) vezérlői is. Az ldap adatbázisban is tárolható a jelszó, azonban nem túl biztonságos, ráadásul minden egyes szolgáltatás igénybevételekor újra be kell írni a jelszót. Mind a biztonság, mind a kényelem szempontjából előnyösebb a Kerberos használata, amit az mit mit-krb5 programja, valamint a Heimdal valósít meg

a nyílt forráskódú rendszerek esetén, és például Microsoft Windows AD tartományvezérlői is tartalmazzák. A jegyzetben a mit-krb5-ről lesz csak szó. Az ldap és a Kerberos segítségével bejelentkezés után többet nem kell beírni a jelszót, azonnal be lehet bejelentkezni bármely másik gépre is, valamint email-eket is el lehet olvasni, egészen pontosan bármely Kerberos-t támogató szolgáltatás azonnal, biztonságosan, és újbóli jelszó begépelés nélkül igénybe vehető. Ezek közül a levelezőszerverek (jelen esetben Postfix és Cyrus), és levelezőkliensek, valamint a bejelentkezés beállítását tekintjük 4 1. fejezet Bevezetés csak meg, mivel a többi szolgáltatás ezeknél jóval ritkábban fordul elő. Az itt bemutatott rendszer GNU/Linux alapokon nyugszik, a jegyzet elsősorban a Gentoo Linuxon történő beállításokat mutatja be, azonban a többi terjesztésen (disztribúción) is hasonlóan használható. A továbbiakban a

következő szolgáltatásokat vizsgáljuk: OpenLDAP, mit-krb5 (Kerberos), Tanúsítvány-kiszolgáló (Certificate Authority), PAM, Cyrus saslauthd, OpenSSH, Postfix, Amavisd-new, ClamAV, SpamAssassin, valamint ssl/tls titkosítás az előző programok esetén. A beállításokat lépésről lépésre nézzük át, először mindig azt, hogy önállóan, a többi nélkül hogyan lehet beállítani, majd pedig a rendszerbe történő integrálásukat. Egy nagyobb, sok számítógépből álló rendszerben a legtöbb szolgáltatás önálló gépen, vagy gépeken fut, ezért elengedhetetlen, hogy a hálózati kommunikáció titkosítva történjen. Néhány esetben enélkül nem is lehet igénybe venni a szolgáltatást (ssh, Kerberos), azonban több is megengedi a titkosítatlan használatot, amely túl nagy kockázattal járhat (ilyenek a levelezőszerverek, de maga az ldap kiszolgáló is). A titkosítást ssl (Secure Socket Layer) feletti kommunikáció teszi lehetővé, amely

biztonsága egyrészt a titkosítás erőssége (mennyire könnyű visszafejteni), másrészt a tanúsítványok használata adja, amelyekkel ellenőrizhető, hogy kivel történik a kommunikáció. Végezetül az itt bemutatott rendszerről essék pár szó: az egyes szolgáltatások többékevésbé ténylegesen önálló gépeken futnak, a gépek nevei utalnak a funkciójukra: dns, ldap, kerberos, mail, és egy desktop gép. Mindegyik a testpanthernet tartományban van, bár egyszerűségképpen a „test.” rész a legtöbb esetben nem fog szerepelni a jegyzetben A dns nevű gépen fut még egy ntp daemon is, amelyhez szinkronizálhatja az időt a többi gép. A tesztkörnyezet szerverei mindannyian Sun VirtualBox-on [?] futtatott, 128 MiB-os rendszermemóriával és 2 GiB-os merevlemezzel futnak, és Ubuntu 9.10 Server fut rajtuk Csak a minimálisan szükséges programok kerültek fel a gépekre, a kötelező OpenSSH szerveren felül DNS Server, vagy másik csomagcsoport

értelemszerűen, valamint olyan további csomagok, amelyek nem voltak így összefogva kategóriákba. A telepítés végén még több, mint 1 GiB-nyi hely marad, és a memória fele is szabad. Két hálózati kártya elég gépenként, az egyik NAT-tal eléri az Internetet, a másik pedig a vboxnet0 -ra köthető, amely által az egyes gépek belső hálón kommunikálhatnak egymással, valamint a VirtualBox-ot futtató gép is eléri őket. A jegyzet eredeti változatában csupán gentoo linuxról esett szó, amelynél nem voltak ennyire szétbontva a szolgáltatások. 2. fejezet DNS Server Egy összetett rendszer esetén nem egyértelmű, hogy az egyes szolgáltatások mely gépeken találhatóak, ezért ezeket központi helyen szokás tárolni, valamilyen dns kiszolgálón. Talán magától értetődik, hogy a gép neve utal a szolgáltatásra, és be van jegyezve egy központi névkiszolgálón. Ez a legtöbb protokollnál egészen természetes Az egyetlen kivétel a

Kerberos, amelyet a 7 fejezetben tárgyalunk, ugyanis vagy fél tucat különféle bejegyzés tartozik hozzá. A tesztkörnyezetben e feladatot egy Bind 9 kiszolgáló látja el. A Gentoo és Ubuntu linuxok esetén ezek nagyon hasonlóan festenek A névfeloldáshoz be kell állítani olyan gépeket, amelyekhez továbbíthatóak a nem lokális hálózatra vonatkozó kérések (pl. examplecom) Az elsődleges névkiszolgáló esetén a /etc/bind/pri könyvtárba kerülnek a teszt tartomány zóna fájljai. E könyvtárat Ubuntu alatt létre kell hozni, míg Gentoo alatt ez egy symlink a /var/bind/pri-re. A másodlagos kiszolgálón pedig ez a /etc/bind/sec könyvtárba kerülne, ennek beállítása a fejezet végén olvasható, de nem szükséges a működéshez. A tesztkörnyezetben a test.panthernet domain használatos a belső, gépek közti hálózaton, a testnetpanthernet pedig az, amelyen keresztül a virtuális gépeket futtató rendszer elérheti őket. 2.1 A named.conf

beállítása Itt nagyon keveset kell beállítani, viszont könnyű elrontani, hogy mi a zónafájlok lelőhelye. Gentoo esetén relatív könyvtárnév van, pri/ vagy sec/ kezdettel, Ubuntu alatt viszont abszolút, /etc/bind/pri/ kezdettel. Előbbi rendszeren valószínűleg inkább a /etc/bind/named.conf-ba érdemes írni, utóbbi esetben pedig a /etc/bind/namedconflocal nevű fájlba. 1 2 3 4 5 6 7 8 9 10 zone "testnet.panthernet" in { type master; file "/etc/bind/pri/testnet.panthernetzone"; allow-query { 10.000/8; localhost; 19216800/16; }; }; zone "test.panthernet" in { type master; file "/etc/bind/pri/test.panthernetzone"; allow-query { 10.000/8; localhost; 19216800/16; }; }; 6 2. fejezet DNS Server 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 zone "10.010in-addrarpa" in { type master; file "/etc/bind/pri/10.010zone"; allow-query { 10.000/8; localhost; 19216800/16; }; }; zone "11.010in-addrarpa" in {

type master; file "/etc/bind/pri/10.010zone"; allow-query { 10.000/8; localhost; 19216800/16; }; }; zone "9.010in-addrarpa" in { type forward; forward only; forwarders { 10.01120; }; }; Az első tíz sorban a két aldomain típusát (type), helyét (file) és elérési szabályozását (allow-query) adtuk meg. A sorrend egyáltalán nem lényeges A zónák csak a felsorolt hálózatokból érhetőek el. A dns szerver ezek elsődleges kiszolgálója (master ) A zónák típusa forward mapping, vagyis a gépek nevét azok ip címükre fordítja. A következő tíz sorban (11-20.) a fordított névfeloldáshoz szükséges zónák szerepelnek (reverse mapping zones). Ezeknek is elsődleges kiszolgálója az aktuális gép Amennyiben bizonyos zónákat el kell érni úgy, hogy csak továbbítjuk a lekérdezéseket (type forward), és nem akarjuk gyorsítótárban tárolni (forward only), akkor a 21-25. sorban látható módon tehetjük meg. A forwarders kulcsszó után

fel kell sorolni a névkiszolgálók ip címeit 2.2 1 2 A névről IP-re feloldó zóna fájl test.panthernetzone $TTL 86400 @ IN SOA dns.testnetpanthernet panthereltehu ( 2009120300 ; serial 1D ; refresh 180m ; retry 6W ; expiry 1D ) ; minimum @ NS dns ; IP addresses dns IN ldap IN kerberos IN mail IN A A A A 10.0101 10.0102 10.0103 10.0104 ; ALIASES dhcp IN CNAME dns 3 4 5 6 7 8 9 IN 10 11 12 13 14 15 16 17 18 2.3 Az IP-ről névre fordító (reverse) zóna fájl 19 20 21 ldaps ntp smtp IN IN IN CNAME CNAME CNAME ldap dns mail 22 23 24 ; Kerberos-related entries ; later 2.3 Az IP-ről névre fordító (reverse) zóna fájl 2.4 A másodlagos névkiszolgáló(k) beállítása 7 3. fejezet További szerverek (dhcp, ntp) 3.1 Dinamikus IP címek (dhcp server) 3.2 Időkiszolgáló (ntp server) 4. fejezet Tanúsítvány-kiszolgáló (CA) és titkosítás Manapság elengedhetetlen a hálózati forgalom titkosítása, bármilyen környezetről

legyen is szó. Ennek elmulasztása jelentős kockázattal járhat, mert illetéktelen személyek (harmadik félnek is nevezik) hozzájuthatnak olyan adatokhoz, amikre nem jogosultak Bár a legbiztonságosabb titkosítás az egyszer használatos kulcs (One Time Padding, OTP), sajnos nem valósítható meg gazdaságosan, ezért általában a nyilvános kulcsú titkosítást (és hitelesítést) szokták használni. A kapcsolat során fontos annak ismerete is, hogy kivel történik a kommunikáció (nem egy harmadik személy, hanem tényleg az, akinek gondoljuk). A tanúsítványok használata ezekre a problémákra nyújt jó megoldást. 4.1 A nyilvános kulcsú rendszerek és a tanúsítványok A nyilvános kulcs használata nagy számításigényű, ugyanis két nagy prímszámot szükséges találni, majd az ezekből képezett kulcsokkal kell a kódolást elvégezni. Ezért a titkosított kapcsolatok esetén az terjedt el, hogy egy ilyen rendszerrel (például RSA kódolással) a

kapcsolat elejét kódolják, amely alatt egy megfelelően hosszú kulcsot cserélnek, majd szimmetrikus kódolással folytatódik a kommunikáció. Ennek a módszernek előnye, hogy továbbra is biztonságos marad, ámde gyorsabban is működik. Aki nyilvános kulcsú hitelesítést vagy titkosítást szeretne használni, annak egy kulcspárra lesz szüksége, amely egy magán (privát) kulcsból és egy publikus (nyilvános) kulcsból áll, az utóbbit bárki ismerheti, az előbbit azonban csak a tulajdonos. A hitelesítés valójában aláírást jelent, egy elektronikus aláírással védett adat sértetlenségét hivatott bizonyítani Az aláírás a privát kulcs használatával történik, ellenőrzése pedig a publikus kulccsal A titkosítás viszont fordítva használja fel a kulcsokat, a publikus féllel titkosított szöveget (adatot) csak a kulcspár privát részének ismeretében lehet elolvasni. Ezért fontos a magán kulcs védelme, hiszen ellenkező esetben más is

hozzáférne az adatokhoz (információkhoz, el tudná olvasni a levelet). Az ilyen jellegű felhasználás azonban felvet egy problémát, és pedig azt, hogy a publikus rész felhasználója nem tudhatja teljes bizonyossággal, hogy a kulcspár valóban azé, akiének gondolja. Ezen probléma megoldására több lehetőségünk is van, mindegyiknek vannak előnyei és hátrányai is. Az egyik lehetőség, hogy a publikus kulcsot úgy továbbítjuk, hogy az semmilyen hálózaton nem megy keresztül, hanem például pendrive-ot használunk, vagyis a kulcs sértetlensége garantált marad. Sajnos a legtöbb esetben ez nem kivitelezhető, 12 4. fejezet Tanúsítvány-kiszolgáló (CA) és titkosítás ugyanis a fizikai távolság vagy más tényező meggátol minket ebben. Másik lehetőség, hogy publikus kulcsot csak már korábban is ismert publikus kulccsal aláírtan fogadunk el (vagyis a korábbi kulcs hitelesíti az újat). Természetesen legalább egy publikus kulcsban meg

kell bíznunk, hogy ez a lehetőség működőképes legyen. Az X509-es tanúsítványok pont ezt valósítják meg, és az Interneten egy-egy kiszolgáló ilyen tanúsítványt használ. A publikus kulcsot foglaljuk tanúsítványba további információkkal együtt. Ezen információk közül a leglényegesebb, hogy ki írta alá (ki igazolja a tanúsítványunk hitelességét) Emellett szerepel a tanúsítvány neve is, valamint a hozzá tartozó ország, állam, szervezet, szervezeti egység, egy e-mail cím, esetleg más információk is. Most már meg tudjuk állapítani, hogy a tanúsítványt ki írta alá, és ezáltal azt is, hogy az aláíró tanúsítvány kitől származik, illetve azt is, hogy ki írta alá, és így tovább. A tanúsítványok ennek megfelelően ún tanúsítványláncot alkotnak Az egyik végén van a mi tanúsítványunk, a másik végén pedig az a kitüntetett tanúsítvány, amelyben megbízunk. Előfordulhat, hogy több ilyen is van, több

tanúsítványban is megbízunk, s ezáltal az általuk aláírtakban, és az azok által aláírtban, és így tovább. Ez az utolsó tanúsítvány egy tanúsítvány-kiszolgálóé (Certificate Authority, pontosabb fordításban hitelesítő hatóság), a tanúsítvány elnevezése pedig gyökértanúsítvány (root certificate). Amikor a tanúsítványokat használjuk, akkor az adott kiszolgáló - vagy épp egy adott személy - publikus kulcsával dolgozunk. A Interneten számos olyan szerver van, amelyik egyáltalán nem használ aláírt tanúsítványokat, pontosabban csak önaláírtat használ. Ezzel a legnagyobb probléma, hogy általában rövid ideig, például egy évig érvényesek, és nem lehet ellenőrizni eredetüket. Ha pedig nem lehet ellenőrizni, könnyen megtehető, hogy egy harmadik személy beékelődik a titkosított kapcsolat két végpontja közé, a szervernek, ami a tanúsítványt és a privát kulcsot birtokolja ez nem tűnik fel, azonban a kliens

számára feltűnő, ha ellenőrzi a tanúsítványt. Sajnos az emberek erre általában lustaságból vagy tudatlanságból nem képesek, ezért könnyen vissza lehet élni vele. Hogyan dolgozik a beékelődött személy? Létrehoz az eredeti tanúsítványhoz hasonló saját tanúsítványt, és eléri, hogy ne az eredeti szerverhez csatlakozzanak, hanem őhozzá, majd pedig az eredeti kiszolgálóhoz csatlakozik, teljesen elrejti, hogy tevékenykedik. Tipikusan így lehet jelszavakhoz és más személyes adatokhoz hozzájutni, a támadás angol neve: man-in-the-middle attack. Saját tanúsítvány-kiszolgálót (hatóságot) is felhasználhatunk, tanúsítványok aláírására lehetőségünk van azonban már más, általánosan elfogadott hatóságok esetén is, természetesen ebben az esetben ők írják alá, különben nekünk kell. Az egyik legismertebb CA a VeriSign, azonban náluk is pénzbe kerül az aláírás megszerzése. Van azonban egy hasonló, ingyenes lehetőség

is, a https://www.cacertorg/indexphp oldalon 4.2 Tanúsítványok készítése Most, hogy már tudjuk, hogyan működnek a tanúsítványok, tekintsük meg a gyakorlati felhasználást is. Ehhez az OpenSSL csomag telepítésére van szükségünk Hacsak nem üzemeltetünk saját tanúsítvány-kiszolgálót, további beállítást nem igényel a rendszerünk. Ellenkező esetben a következő részben ismertetett beállításokra szükségünk van. 4.21 openssl.cnf Az OpenSSL beállításfájlja az openssl.cnf, mely általában a /etc/ssl (Gentoo-n) vagy a /etc/openssl könyvtárban található. Mi most nem ezekben a könyvtárakban tárol- 13 4.2 Tanúsítványok készítése juk, bár itt kellene, hanem a /root/panthernet.ca könyvtárban Ugyanaz a fájl több különböző CA-ra is vonatkozhat. A [ca] szakaszban csak azt adjuk meg, hogy melyik az alapértelmezett CA. Ezután minden egyes CA-t külön elnevezhetünk, és külön szakaszban definiálhatjuk a

beállításokat A példában csak egyetlen beállítás szerepel, a többi hasonlóan működik. Csak a dir beállítást szükséges megváltoztatni, ha többet használunk, viszont mindegyik szabadon konfigurálható. CA beállítások [ ca ] default ca = CA default [ CA default ] dir certs crl dir database #unique subject = = = = = new certs dir = $dir/newcerts certificate serial #crlnumber = $dir/ca/cacert.pem = $dir/ca.dbserial = $dir/crlnumber crl private key RANDFILE /root/panthernet.ca $dir/certs $dir/crl $dir/ca.dbindex no # # # # # # # # Where everything is kept Where the issued certs are kept Where the issued crl are kept database index file. Set to ’no’ to allow creation of several ctificates with same subject. default place for new certs. # The CA certificate # The current serial number # the current crl number # must be commented out # to leave a V1 CRL = $dir/crl.pem # The current CRL = $dir/ca/private/cakey.pem #The private key = $dir/ca.dbrand # private

random number file x509 extensions = usr cert # The extentions to add to the cert # Comment out the following two lines for the "traditional" # (and highly broken) format. name opt = ca default # Subject Name options cert opt = ca default # Certificate field options default days = default crl days= default md = preserve = policy 365 30 md5 no # # # # = policy match [ policy match ] countryName stateOrProvinceName organizationName = match = optional = match how long to certify for how long before next CRL which md to use. keep passed DN ordering 14 4. fejezet Tanúsítvány-kiszolgáló (CA) és titkosítás organizationalUnitName commonName emailAddress = optional = supplied = supplied Tehát a második lista a CA beállításait tartalmazza, a harmadik pedig azt, hogy a CA mikor tud aláírni egy tanúsítványt: minek kell egyeznie (match), mi az, ami nem kötelező optional, és mi az, ami kötelező, de bármi lehet (supplied), azaz más értéket is

felvehet, mint a CA tanúsítványában szereplő érték. Megadható az is, hogy alapértelmezetten mivel legyen kitöltve a tanúsítvány, valamint hogy milyen kérdések szerepeljenek (lehetne magyarul is!), csakúgy, mint az alapértelmezett kulcshossz is. Ezek a részletek: [ req ] default bits distinguished name = 1024 = req distinguished name alapértelmezett értékek és feliratok [ req distinguished name ] countryName = Country Name (2 letter code) countryName default = HU countryName min = 2 countryName max = 2 stateOrProvinceName stateOrProvinceName default = State or Province Name (full name) = . localityName localityMame default = Locality Name (eg, city) = Budapest 0.organizationName 0.organizationName default = Organization Name (eg, company) = PantherHome organizationalUnitName = Organizational Unit Name (eg, section) commonName commonName max = Common Name (eg, YOUR name) = 64 emailAddress emailAddress max = Email Address = 64 4.22 Parancsok,

parancsfájlok Általában több tanúsítványt is alá kell írni, vagy csak létrehozni, ha egy külső hatóság írja alá nekünk. Ezért érdemes egy parancsfájlt írni ezekre a műveletekre Az első ismertetett kód mégsem ilyen, hanem a CA tanúsítványának létrehozásának módja, hiszen enélkül nem tudunk aláírni semmilyen más tanúsítványt sem: openssl req -config /root/panthernet.ca/opensslcnf 4.2 Tanúsítványok készítése 15 -new -x509 -keyout /root/panthernet.ca/ca/private/cakeypem -out /root/panthernet.ca/ca/cacertpem -days 3650 A következő szkript hoz létre egy „kérést” (request) aláírásra (.csr: certificate sign request, tanúsítvány aláírási kérelem) és a hozzá tartozó privát kulcsot (.key fájl) Semelyik szkript sem igényel teljes nevet, kiterjesztéseket automatikusan hozzáilleszti. careq #!/bin/bash if [[ $# != 1 ]]; then exit 4; fi echo generating $1 openssl req -config /root/panthernet.ca/opensslcnf -nodes

-newkey rsa:2048 -keyout $1.key -out $1csr echo changing permissions on $1.key chmod 400 $1.key Fontos, hogy a létrehozott privát kulcs fájlját (.key állomány) csak a tulajdonos tudja olvasni, sőt, még neki sem kell írnia, ezért az utolsó sorban ennek megfelelően módosítottuk a jogokat. A szkript által generált kérelmet (csr fájl) elküldjük a tanúsítvány-kiszolgálónak, amely aláírja, például saját rendszeren a következő szkripttel. A létrehozott, aláírt tanúsítvány a .crt kiterjesztésű fájlba kerül casign #!/bin/bash if [[ $# != 1 ]]; then exit 4; fi echo signing $1 openssl ca -config /root/panthernet.ca/opensslcnf -policy policy match -out $1.crt -infiles $1csr} Nézzük meg, hogy hogyan is fog ez működni, azaz tekintsünk meg egy példát egy aláírásra: zeratul panthernet.certs # casign ldapspanthernet Using configuration from /root/panthernet.ca/opensslcnf Enter pass phrase for /root/panthernet.ca/ca/private/cakeypem: Check that the

request matches the signature Signature ok Certificate Details: Serial Number: 1 (0x1) Validity Not Before: Oct 15 10:36:30 2005 GMT Not After : Oct 15 10:36:30 2006 GMT Subject: countryName = HU organizationName = PantherHome commonName = ldaps.panthernet emailAddress = postmaster@panthernet} Az így kapott tanúsítványt (crt), valamint a privát kulcsot be kell másolni az adott szerver által igényelt helyre, és a szervert futtató felhasználó tulajdonába kell adni. 16 4.3 4. fejezet Tanúsítvány-kiszolgáló (CA) és titkosítás Biztonsági megfontolások Azt már láttuk, hogy mi a célja a tanúsítványok rendszerének, azonban ha használjuk is őket, akkor a következőkre kell ügyelnünk. A legfontosabb az, hogy a privát kulcsot soha ne olvashassa más (az a jó, ha a tulajdonos is csak olvashatja). Érdemes a kulcsot és a tanúsítványt elmenteni, hogy egy esetleges véletlen törléstől védve legyen, az ördög nem alszik, rosszul kiadott parancsok

következménye lehet ez, főleg, ha nem normál felhasználóként, hanem rootként dolgozunk. Az elmentett kulcspárra (és tanúsítványra) ugyanaz vonatkozik, mint a CA-ra. Ha saját hitelesítő hatóságunk (CA) van, akkor erre további szabályok vonatkoznak, amiket kötelező (lenne) betartani. A privát kulccsal vissza lehet élni, ezért azt mindenképpen védeni kell Minimális védelemnek tekinthető a kulcs jelszavas védelme és a géptől független tárolása. Ha alá kell írni egy tanúsítványt, akkor az aláírás idejére be kell csatolni a kulcsot tartalmazó fájlrendszert, ami ma nagy valószínűséggel pendrive vagy CD Az aláírás végeztével el kell távolítani az eszközt. Az még jobb, ha már maga a pendrive fájlrendszere is jelszóval védett, habár ez utóbbi esetleg már inkább csak extra védelmet nyújt. Ami lényeges, hogy az eltávolított eszközt biztonságos helyen, például páncélszekrényben kell őrizni, amelyhez nem férhet hozzá

akárki, és mindig lehet tudni, ki nyúlt bele. 5. fejezet Az ldap és az OpenLDAP kiszolgáló A jegyzetben ismertetett rendszer egyik központi része az OpenLDAP szerver. A kiszolgáló az ldap protokollt (Lightweight Directory Access Protocol) használja, amely egy „könyvtárszolgáltatás” (directory service) elérését teszi lehetővé, és alapvető jellemzője, hogy olvasásra, keresésre, böngészésre (átnézésre) optimalizált adatbázist használ az adatok tárolására. Az adatbázis lényegében bármilyen adatot tartalmazhat bármiről, az egyetlen megkötés, hogy faszerkezetű hierarchiába kell szervezni. Az OpenLDAP szerverhez általában tcp/ip kapcsolaton keresztül lehet csatlakozni, azonban a helyi gépen (amelyen az ldap kiszolgáló található), unix socketen keresztül is történhet a kapcsolódás. A következőkben az ldap szerver alapvető beállítását, majd pedig a rendszer kibővítését titkosítással, Kerberos alapú

hitelesítéssel, végül pedig a szerver adatbázisának replikálását olvashatjuk. 5.1 Mi is az ldap? A legelső kérdés, hogy mi az ldap? Az ldap egy hierarchikusan (faszerkezetbe) szervezett adatbázis elérésére szolgáló protokoll. A fában tárolt adatokat egy-egy egyedi név: Distinguished Name (DN) azonosítja, amely név több részből áll, a különböző részek alapján történik a bejegyzések (objektumok) fába szervezése. Minden bejegyzéshez tartozik egy vagy több tulajdonság, amit egy kulcs-érték pár határoz meg. A kulcs lehet például a „common name” (cn) - mindennapi név, a hozzá tartozó érték meg „Gipsz Jakab”, vagy épp a levélcím megadására szolgáló „mail” mező. Egy-egy tulajdonság (lényegében maga a kulcs) többször is szerepelhet egy objektumon belül. A fa csúcsainak elhagyható és kötelező tulajdonságait az objektumok (csúcsok) osztályai írják le (tulajdonságosztályok). A nevük: objectclass, és a

jelölés erejéig legalábbis maguk is (speciális) tulajdonságok. 5.2 Telepítés Az OpenLDAP szerver és a kliensoldali programok egyaránt az openldap csomagban találhatóak, melyet az emerge openldap paranccsal telepíthetünk Gentoo Linux esetén, azonban például Debian alatt már több csomagból áll, ezek: slapd és ldap-utils, és a telepítő egy minimális fastruktúrát létrehoz a slapd.conf állománnyal együtt, ezeket azonban Gentoo-n nekünk kell megtennünk. 18 5. fejezet Az ldap és az OpenLDAP kiszolgáló A beállítófájlok helye a /etc/openldap könyvtár Gentoo alatt és /etc/ldap Debian rendszer esetén. 5.3 A szerver beállítófájlja: a slapd.conf A /etc/openldap/slapd.conf fájl tartalmazza a szerver beállításait, nagy vonalakban ezek a következők: • Sémák (a használható attribútumokat adják meg) • Hozzáférés-vezérlési listák (acl) • Titkosítás, hitelesítés és egyéb információk • A (háttér)adatbázis

típusa, a keresést segítő index módja • Az ldap faszerkezet csúcsát jelölő név • A „szuperfelhasználó” (rootdn) egyedi neve és jelszava (mindent olvas, és ír, az acl nem érvényes rá) Figyeljünk arra, hogy ne olvashassa mindenki ezt a fájlt! Séma. Az általunk használt séma az alábbi: include include include include include /etc/openldap/schema/core.schema /etc/openldap/schema/cosine.schema /etc/openldap/schema/inetorgperson.schema /etc/openldap/schema/nis.schema /etc/openldap/schema/misc.schema A felsoroltak közül az első a rendszernek kell lényegében, a következő három az általánosan használt attribútumokat tartalmazza (többek között a felhasználók definiálásához). Az utolsó „misc”, azaz nem megszokott, most az ebben definiáltakkal lesz meghatározva az a cím, amelyre érkezett leveleket az adott felhasználó fogadhatja, illetve melyre továbbküldheti (ha nem küldi tovább, akkor is szükséges). Az ldap-ban tárolt

álnevek (aliases) meghatározásához is szükséges. Jogok (acl). A következő beállítás nagyon alapszintű, érdemes alaposabban utánaolvasni az OpenLDAP leírásában, vagy épp az interneten, mert esetleg sokkal bonyolultabb hozzáférés-szabályozásra lesz szükség. A jelszót csak saját maga tudja írni, valamint az admin. access by by by by to attrs=userPassword dn="cn=admin,dc=panthernet" write anonymous auth self write * none A következő két beállítás nagyjából azonos a jelenlegi esetben, csak az egyik szükséges! 5.3 A szerver beállítófájlja: a slapdconf 19 access to dn.children="ou=People,dc=panthernet" by dn="cn=admin,dc=panthernet" write by * read #access to * # by dn="cn=admin,dc=panthernet" write # by * read Látszik, hogy az admin nevű felhasználónak joga van írni bármilyen bejegyzést. De ki is ő? A rendszerben van egy kitüntetett felhasználó (rootdn, akinek a jogosultságát nem lehet

szabályozni, bármit módosíthat, a neve és a jelszava aslapd.conf fájlban adható meg Éppen ezért csak bizonyos esetekben szabad használni, ha máshogyan nem oldható meg a módosítás. Ebből következően szükség van egy kitüntetett felhasználóra is, amely az ldap adminisztrátor lesz, a Debian telepítésnek megfelelően cn=admin,dc=domain,dc=hu formában hozzuk létre. Az adatbázis és a root „user”. Az adatokat általában Berkeley adatbázis tartalmazza, mely nagyon gyors, ámde nem hordozható, vagyis maguk az adatbázisfájlok nem vihetőek át másik gépre. Ehhez exportálni kell az adatbázist, a másik gépen pedig importálni A faszerkezet gyökerét, aminek a neve minden csúcs nevének végződése, a suffix beállítás tartalmazza. A „root” felhasználót a „rootdn” és a „rootpw” pár azonosítja database bdb suffix "dc=panthernet" rootdn "cn=Manager,dc=panthernet" # Cleartext passwords, especially for the rootdn,

should # be avoid. See slappasswd(8) and slapdconf(5) for details # Use of strong authentication encouraged. rootpw {SSHA}blabla checkpoint 32 30 # <kbyte> <min> # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory /var/lib/openldap-data # Indices to maintain index objectClass eq # LogLevel 0 Mint látható, a jelszót is meg kell adni. Lehetne titkosítás nélküli (cleartext) jelszót is megadni, de ez nem célszerű, ugyanis ha esetleg valami hiba folytán a slapd.conf állományt más is olvashatja, akkor azonnal megvan. Ha egy bonyolult jelszót választunk, és titkosítva tároljuk, akkor akár évekig, sőt esetleg évezredekig tartana kitalálni a jelszót. Az SSHA egy megfelelő algoritmus, egyirányú, ezért nem lehet a jelszót visszaállítani, csak bruteforce-szal törhető (vagy szótári támadással, ha rossz a jelszó). Tehát a jó jelszó: kis-

20 5. fejezet Az ldap és az OpenLDAP kiszolgáló és nagybetűk, számok vegyesen, lehetőleg egyéb nyomtatható karakterekkel (pl. #, &, ! stb.) megtűzdelve, és legyen minél hosszabb Mivel a jelszó hash formájában tárolódik, ezért több különböző jelszót megadva azonos hash-t kapunk. SHA1 esetén 160 bites a hash hossza, ennél hosszabb jelszavak esetén garantáltan lesz több egyező is. A jelszó előállítására szolgál a slappaswd parancs, ennek kimenetét kell bemásolni. Használata: slappasswd -h SSHA Az adatbázisról (database beállításról) még egyszer: az adatbázis lehet többféle, a legegyszerűbb az ldbm, a legjobb választás azonban a bdb (Berkeley DB), melynek fájljai a directory beállításnak megfelelő könyvtárban lesznek. A könyvtárra a 700 jogot ajánlott megadni, hogy ne tudja a könyvtár tulajdonosán más is olvasni a fájlokat. Az index a kereséshez használt index. A LogLevel mondja meg, mennyire bőbeszédűen

(verbose) írja bele a syslog-ba, hogy mi történik. A „0” érték hatására szinte semmit sem ír, hibakeresésnél jön jól 5.4 Az ldap.conf A szerverhez történő hozzáférés beállításait a /etc/openldap/ldap.conf állomány tartalmazza Ez a fájl mondja meg, hogy az ldapsearch, és hasonló parancsok alapesetben milyen géphez, milyen protokollal és milyen végződésű helyhez (lásd a fentebbi suffix, itt base) csatlakozik. A fájl mindenki által olvasható BASE URI ldap.conf dc=panthernet ldaps://ldaps.panthernet TLS CACERT /etc/openldap/ssl/cacert.pem SASL REALM panthernet A base után a faszerkezet valamely csúcsának egyedi nevét kell megadni, amely alatti bejegyzéseken történik a keresés (tehát részfát határoz meg). Az URI a szerver elérését adja meg protokollal együtt A példában a titkosított protokoll (ldaps) szerepel, az „ldaps.panthernet” nevű gépen érhető el a szerver, a titkosítás miatt meg kell adni azt a helyet, ahol a

ca tanúsítványa található, ez a tls cacert beállítás. A sasl realm a 7. fejezetben részletesen tárgyalt Kerberos beállításaihoz tartozik, az alap OpenLDAP nem igényli, itt csupán a teljesség kedvéért szerepel. 5.5 A rendszer felkészítése az ldap használatához A fentiek elvégzése után még csak a szerver beállítása és a kapcsolódás módja adott. Ahhoz, hogy az ldap-ban tárolt felhasználók ténylegesen létezhessenek az adott gépen (pl. az id parancs lássa őket), fel kell telepíteni az „nss ldap” csomagot. Általában az ldap szerver különálló gépen található, de nincs mindig így, ezért néha azon is be kell állítani a csomagot (/etc/ldap.conf tartalmazza a beállításait) 5.6 Az adatok feltöltése 5.51 21 nss-ldap A névfeloldáshoz és az ldap-ban tárolt jelszavak kezeléséhez nélkülözhetetlen az nss-ldap csomag. A beállítófájlja a /etc/ldapconf, ennek néhány fontosabb beállítása: /etc/ldap.conf részlet

base dc=panthernet uri ldaps://ldaps.panthernet/ # The distinguished name to bind to the server with. #Optional: default is to bind anonymously. #binddn cn=proxyuser,dc=padl,dc=com # The credentials to bind with. # Optional: default is no credential. #bindpw secret Az első kettő lényeges minden esetben. Az egyik a szerver elérését mondja meg (uri): ldaps, azaz titkosított, utána pedig a gép neve szerepel. A másik, a base pedig a faszerkezet egy csúcsát, ami alatt keres a rendszer (ou=People, ou=Group). Alapesetben ez a teljes részfát jelenti, ám ez tovább módosítható lenne. A binddn és a bindpw segítségével elérhető, hogy névtelenül ne lehessen a szerverhez csatlakozni, onnan információkat gyűjteni, csak az itt megadott „felhasználó” és jelszó tudjon. Igazából a fa bármely csúcsa lehet, ha annak van joga olvasni szinte bármit, kivéve például a userPassword tulajdonságot. Ehhez a sor eleji „#” karaktert (megjegyzés jele) ki kell

törölni, és érvényes adatot írni a helyére. A fájl többi részét nem szükséges módosítani. nsswitch.conf Az ldap szerverhez történő csatlakozást a fentebb látható módon garantáltuk, de ez kevés Még meg kell mondani, hogy az információkat onnan (is) vegye Ezt a /etc/nsswitch.conf fájl módosításával tehető meg passwd: shadow: group: /etc/nsswitch.conf ldap-ot használó része files ldap files ldap files ldap Vagyis a jelszavakat, shadow jelszavakat és a csoportokat egyrészt a helyi fájlokból, másrészt ldap-ból olvassa ki (az elől álló nevek a /etc/ alatti fájlneveket jelzik. Ha nem akarjuk, hogy az ldap-ban tárolt jelszavakat használja a rendszer, akkor a passwd beállításnál nem szükséges a ldap megadása. 5.6 Az adatok feltöltése Egyelőre még egy teljesen üres adatbázisunk van, viszont már minden megvan ahhoz, hogy a teljes rendszer működjön. Akár le is kérdezhetjük az adatbázis tartalmát az ldapsearch -x parancs

kiadásával. Természetesen a kimenet üres lesz (pár megjegyzést nem számítva) A mostani példában felhasználók, csoportok és email álnevek (álnevek) szerepelnek. Az ezek szülőcsúcsáig bezárólag kézzel kell (érdemes) létrehozni a fát, utána már lehet szkriptekkel is beszúrni az adatokat. 22 5. fejezet Az ldap és az OpenLDAP kiszolgáló 5.61 ldap bejegyzések hozzáadása Az ldap a bejegyzéseket ldif formátumban jeleníti meg (például az ldapsearch és slapcat parancsok kimenete ilyen), és ezt a formátumot használva lehet adminisztrálni is. Ezért az összes bejegyzés (csúcs) ilyen formában van itt is. Ha elkészítettük a fájlt, amiben az ldif bejegyzés(ek) van(nak), akkor az ldapadd paranccsal hozzá lehet adni: ldapadd -xWD cn=Manager,dc=panthernet -f fájlnév.ldif Természetesen csak a legelső elemeket érdemes így létrehozni, utána pedig már másik felhasználót (a -D után egy másik bejegyzés, csúcs nevét) érdemes

megadni. 5.62 Az alapvető bejegyzések Az alapvető bejegyzések a gyökértől kezdődően lefelé a csoportokat definiáló csúcsokig tartanak, valamint az admin és Manager kitüntetett felhasználók (lehet, hogy a Manager felesleges is, ámde így biztosan működik). Tekintsük először a gyökeret, s annak tulajdonságait. A dc az egyedi név, az o a szervezet (organization) rövidítése dn: dc=panthernet objectClass: dcObject objectClass: organization dc: panthernet o: PantherNetwork A következő slapd.conf fájlban definiált „felhasználó” Az idézőjel oka, hogy valójában nem is felhasználó, ezért is más az objectClass. Kettő is van neki, a második (top) csak annyit jelent, hogy az objektumnak lehetnek gyerekei (bizonyos esetekben szükséges, bizonyos esetekben meg nem, ez erősen függ a többi megadott objectClass tulajdonságtól). Ezért a top egy felesleges objectClass, de nem helytelen. Lehet, hogy enélkül is menne a rendszer. dn:

cn=Manager,dc=panthernet objectClass: organizationalRole objectClass: top cn: Manager Most tekintsük az admin felhasználó bejegyzését, mely a Manager-től független adminisztrátori jogokkal rendelkezik. Nem kötelező, mégis jobb, ha szét vannak választva a jogosultságok, akár több részre is A simpleSecurityObject tartalmazza a userPassword tulajdonságot, vagyis lehet lehet hitelesíteni (jelszót ellenőrizni). A description mező pedig a leírás, melyet bármely objektum tartalmazhat, ámde használata opcionális. dn: cn=admin,dc=panthernet objectClass: organizationalRole objectClass: simpleSecurityObject cn: admin description: LDAP administrator userPassword: {SSHA}blabla 5.6 Az adatok feltöltése 23 A rendszeren létező összes (valódi) felhasználó egyetlen bejegyzés alá kerül, ez pedig a következő lesz, ahol szervezeti egységet jelent az organizationalUnit: dn: ou=People,dc=panthernet objectClass: organizationalUnit ou: People Az email aliasokat

tartalmazó ág csúcsa: dn: ou=MailAliases,dc=panthernet ou: MailAliases objectClass: top objectClass: organizationalUnit A csoportokat tartalmazó szervezeti egység: dn: ou=Group,dc=panthernet objectClass: organizationalUnit ou: Group 5.63 A többi bejegyzés Az előbb ismertetett bejegyzéseket létrehozva meg van minden, hogy felhasználókat létrehozzunk, sőt, bármilyen információt tárolhatunk az ldap szerveren, bár most nem célunk. Eddig csak a Manager (azaz a rootdn) tudott létrehozni csúcsokat, most már megtehetjük ezt az általunk létrehozott admin felhasználó segítségével. Az első kettő egy-egy felhasználói bejegyzés (nagyjából így definiáltam a felhasználómat a notebookomon). A példában nagyon sok tulajdonság kitöltetlen Először tekintsük át, milyen osztályokba tartozik a felhasználó, és melyek az egyes osztályok lényegesebb tulajdonságai. Az inetorgPerson többek között a következő opcionális tulajdonságokat határozza

meg (inetorgperson.schema): homePhone, homePostalAddress, initials, mail, mobile, roomNumber, uid. A person (core.schema) esetén az sn, cn attribútumokat kötelező definiálni (vezetéknév az sn) Opcionális többek között: userPassword, telephoneNumber Az organizationalPerson valamilyen szervezethez tartozó személyt jelent. Itt többek között telephoneNumber, ou (azaz a szervezeti egység), postalAddress tulajdonságok szerepelnek. A inetLocalMailRecipient a misc.schema-ban definiált, mailLocalAddress, mailHost, mailRoutingAddress az opcionális tulajdonságai. Ebből az első az, amire érkeznek a levelek, az utolsó meg amire mennek Ha helyi fiók (pl panther), akkor a levelezőszervernek (pl. Cyrus) továbbítódik, különben a megadott címre A posixAccount és shadowAccount tartalmazza a /etc/passwd és /etc/shadow fájlban is megtalálható információkat Ha a jelszavakat nem szeretnénk Kerberos-ban tárolni, ámde ldap-ban igen, akkor még egy osztályt meg kell

adnunk, ez pedig a shadowAccount. Most nincs szükségünk rá Mivel a nevem ékezeteket is tartalmaz, ezért UTF-8-ban megadtam, majd pedig Base64gyel kódoltam az egyes mezők értékét. Emiatt ezeknél a mezőknél nem egy, hanem két kettőspont szerepel. 24 5. fejezet Az ldap és az OpenLDAP kiszolgáló dn: uid=panther,ou=People,dc=panthernet objectClass: top objectClass: person objectClass: inetOrgPerson objectClass: organizationalPerson objectClass: inetLocalMailRecipient objectClass: posixAccount cn:: VMOzdGggTMOhc3psw7MgQXR0aWxh cn:: TMOhc3psw7MgQXR0aWxhIFTDs3Ro uid: panther mobile: 06 homePostalAddress: Erd mailRoutingAddress: panther mailLocalAddress: Toth.LaszloAttila mailLocalAddress: Laszlo.AttilaToth gecos: Toth Laszlo Attila sn:: VMOzdGg= homeDirectory: /home/panther loginShell: /bin/bash uidNumber: 1000 gidNumber: 100 givenName:: TMOhc3psw7MgQXR0aWxh illetve dn: uid=parad,ou=People,dc=panthernet objectClass: top objectClass: person objectClass: inetOrgPerson

objectClass: organizationalPerson objectClass: inetLocalMailRecipient objectClass: posixAccount objectClass: shadowAccount cn: Nagy Adrienn cn: Adrienn Nagy gecos: Nagy Adrienn sn: Nagy givenName: Adrienn uid: parad mailRoutingAddress: parad mailLocalAddress: Nagy.Adrienn mailLocalAddress: Adrienn.Nagy homeDirectory: /home/parad loginShell: /bin/bash uidNumber: 1001 gidNumber: 100 Csoportokat is létrehozhatunk, ahol felsorolhatjuk a tagokat is uid szerint: 5.6 Az adatok feltöltése 25 dn: cn=testgrp,ou=Group,dc=panthernet objectClass: top objectClass: posixGroup cn: testgrp gidNumber: 10000 memberUid: panther memberUid: parad Végezetül lássunk egy példát a levelezésben használt álnevekre. A bejegyzés akár több álnevet is tartalmazhat (mailLocalAddress tulajdonság), és akár több címre is továbbítódhat. Ez utóbbit a mailRoutingAddress tulajdonsággal adhatjuk meg, amelyből az előzővel ellentétben egyetlen egy lehet, és az összes címzettet szóközzel

elválasztva meg kell adni utána. dn: uid=mindenki,ou=MailAliases,dc=panthernet objectClass: account objectClass: top objectClass: inetLocalMailRecipient mailLocalAddress: mindenki mailLocalAddress: everyone mailLocalAddress: everybody uid: mindenki mailRoutingAddress: panther parad 5.64 Az ldap bejegyzések módosítása Sokszor menet közben kell felvenni újabb adatokat, vagy meglévőket módosítani, esetleg törölni néhányat. Ezt mind a következő paranccsal tehetjük meg: ldapmodify -xWD cn=Manager,dc=panthernet -f fájlnév.ldif Nézzük sorra, hogy mit hogyan lehet: Attribútum hozzáadása: dn: uid=panther,ou=People,dc=panthernet changeType: modify add: userPassword userPassword: {KERBEROS}panther@PANTHERNET Attribútum cseréje: dn: uid=panther,ou=People,dc=panthernet changeType: modify replace: userPassword userPassword: {KERBEROS}panther2@PANTHERNET Lehet törölni is egy attribútumot, például: dn: uid=panther,ou=People,dc=panthernet changeType: modify

delete: userPassword 26 5. fejezet Az ldap és az OpenLDAP kiszolgáló Ha egy adott attribútumot (amiből több különböző értékű is lehet) kellene, akkor: dn: uid=panther,ou=People,dc=panthernet changeType: modify delete: mail mail: panther@elte.hu Több is egyszerre: dn: uid=panther,ou=People,dc=panthernet changeType: modify add: userPassword userPassword: {KERBEROS}panther@PANTHERNET replace: homePostalAddress homePostalAddress: Erd, stb. A teljes bejegyzés törlése: dn: uid=panther,ou=People,dc=panthernet changeType: delete 5.7 Titkosítás Az eddigiek alapján nagyjából működőképes a rendszerünk, azonban vannak hiányosságai. Az egyik az, hogy a szerver és a kliens között titkosítatlan a kommunikáció, ezért egy harmadik személy is hozzáférhet az adatokhoz, ha valahogyan meg tudja szerezni a kliensszerver kapcsolat csomagjait. A szerver a tls (és ssl) titkosítást támogatja (Transport Layer Security és Secure Socket Layer kifejezések

rövidítései). A tls beállításhoz szükség van tanúsítványokra (ezek kezelését később tárgyaljuk). A beállítások a következők: TLSCACertificateFile /etc/openldap/ssl/cacert.pem TLSCertificateFile /etc/openldap/ssl/ldaps.panthernetcrt TLSCertificateKeyFile /etc/openldap/ssl/ldaps.panthernetkey #TLSCipherSuite HIGH,MEDIUM Az első sor jelzi a tanúsítvány-kiszolgáló (CA) tanúsítványát (certificate). A második az OpenLDAP-ét, a harmadik pedig az OpenLDAP titkos kulcsa (key). Ennek a fájlnak kötelezően 600 jogúnak kell lennie, nem szabad, hogy bárki is olvasni tudja. Az utolsó sor csak a közepes és erős titkosító algoritmusokat engedélyezi (ha nincs ott a kettős kereszt (#)). 5.8 Kerberos alapú hitelesítés A Kerberos előnye, hogy egyszer kell a felhasználót hitelesíteni, utána hozzáférhet más szolgáltatásokhoz, anélkül, hogy megadná újból és újból a jelszavát. Részletesen lásd a 7 fejezetben. Az ldap szerverhez történő

hozzáférés is szabályozható a következőkben (valamint egy további opció is szerepel a példában): 5.8 Kerberos alapú hitelesítés 27 sasl-realm panthernet sasl-regexp uid=([^,]+),.*cn=GSSAPI,.* uid=$1,ou=People,dc=panthernet sasl-host zeratul.panthernet A sasl-realm azt az ún. kerberos realm-ot határozza meg, amiben a kerberos bejegyzések vannak A sasl-host a kiszolgáló helyét mondja meg, sasl-regexp pedig azt, hogy hogyan lehet megtalálni azt a bejegyzést, aki csatlakozott a szerverhez. 6. fejezet Levéltovábbítás és levélfogadás A legtöbb esetben egy-egy szerveren megtalálható egy kisebb-nagyobb tudású levelező szerver, pontosabban levéltovábbító szerver (MTA, Mail Transfer Agent), amely a címzettől függően küldi tovább egy másik kiszolgálónak a leveleket. Néha nincsen erre szükség, ugyanis a kliens programnál beállítható, hogy egy adott MTA kapja meg az elküldött leveleket (és ezen a másik gépen menjen keresztül a

teljes levelezés). Egy ilyen helyzet lehet az, amikor a felhasználók által használt gép csupán bejelentkezésre és parancssori munkára szolgál (login server). Azonban a felhasználóknak meg is kell kapniuk a leveleket, ezért egy vagy több kiszolgálóra komolyabb levéltovábbító szervert tesznek, a legismertebbek a Postfix, az Exim és a Sendmail. Mi most csak az előbbivel foglalkozunk, elsősorban az LDAP és Kerberos felhasználásával – és a 9. fejezetben a spam- és vírusszűréssel – foglalkozunk 6.1 Postfix A nagyobb programok meglehetősen bonyolultakká, összetetté fejlődtek az idők folyamán, a Postfix mégis egyszerű tervezésű és könnyebben konfigurálható maradt. Nagyon sok minden beállítható, egyszerűsége nem is ebben, hanem modularitásában rejlik, számos kisebb programból áll ([1]). A Postfix a leveleket több várakozási sorban kezeli, egészen pontosan négyben, és nem csak egyetlen nagy várakozási sort használ. Ezek a

következők: • Levélgyűjtő sor (Maildrop queue) A helyileg fogadott levelek kerülnek ebbe a sorba, melyből formázás és esetleges javítás után a beérkező sorba jutnak. • Beérkező sor (Incoming queue) A helyileg fogadott leveleken felül a más kiszolgálókról a postfix smtpd folyamatán keresztül érkezeett levelek kerülnek ide, amíg nincs üresedés az aktív sorban. • Aktív sor (Active queue) Egy rövid sor, melybe csak akkor érkezik levél, ha van szabad hely. A Postfix ebből próbálja kézbesíteni a leveleket. • Halasztott sor (Deferred queue) Azokat a leveleket tartalmazza, melyeket nem sikerült kézbesíteni, így a rendszer 30 6. fejezet Levéltovábbítás és levélfogadás nem próbálja újból és újból továbbküldeni. Ha egy tartomány nem elérhető, akkor az összes oda szóló levél egy valamekkora várakozási ideig a halasztott sorba kerül. Ha a várakozási idő letelik, akkor az aktív sorba kerül. Ha még mindig nem

sikerült kézbesíteni, akkor egy új, hosszabb várakozási idővel visszakerül a halasztott sorba. 6.2 /etc/postfix/main.cf A postfix beállításait tartalmazza, például milyen címeket fogadjon el, aliasok hol vannak, levélküldés esetén milyen gépnevet adjon meg. myhostname = zeratul.panthernet mydomain = panthernet myorigin = $myhostname mydestination = $myhostname, localhost.$mydomain, localhost, $mydomain relayhost = smtp.axelerohu alias maps = hash:/etc/mail/aliases, ldap:/etc/postfix/ldapaliases-mailaliases.cf, ldap:/etc/postfix/ldapaliases-people.cf Alapesetben a mydomain a myhostname végével egyezik meg (nem kötelez megadni). Az SMTP protokollban ez utóbbi szerepel, vagyis amikor a levelet elküdli a postfix, akkor ilyen néven csatlakozik a másik szerverhez ($myhostname). A myorigin az, ami után megadott gépnév fog szerepelni az elkldött levél feladójaként és akár címzettként is. Például a root küld egy levelet saját magának: mail root.

Ekkor mind a feladó, mind a címzett root@$myorigin lesz. A mydestination vesszővel elválasztott lista, azon gépneveket tartalmazza, amelyekre fogad levelet, vagyis az itt felsorolt nevekhez tartzó felhasználók (pl user@$mydomain) leveleit nem egy másik smtp szervernek továbbítja, hanem az imap, pop, stb kiszolgálónak, ahonnan az adott felhasználó letöltheti leveleit. A relayhost az, ahova alapesetben (kivéve a /etc/postfix/transport fájlban megadott címzetteket, tartományokat) továbbítja a leveleket. Többféle formátumban meg lehet adni, IPv6-ot is támogat. Formáutma pl a fenti, aztán 19216801:25 is lehet (port számmal) A lehetőségek a konfigurációs fájlban megjegyzésben láthatók Amennyiben nincsen relayhost, akkor közvetlenül a címzett levelezőszerveréhez csatlakozik (amit a cím domain részéhez tartozó MX dns bejegyzésből vesz). Az alias maps mondja meg, hogy egy adott email címhez tartozó levelek hova továbbítódjanak. Itt most az

aliases fájlban találhatóak, valamint ldap-ban, a két fájl különböző beállításokat tartalmaz. 6.3 /etc/mail/aliases Debian rendszereken ennek a fájlnak a helye: /etc/aliases. Formátumra részlet: aliases részlet www: webmaster levlista: root user@domain1.com user2@example.com 6.4 LDAP-ban tárolt alias-ok 31 Jelen esetben a www címre küldött levelek a webmasternek továbbítódnak, ami még mindig csak virtulális cím, vagyis a neki címzett levelek a root felhasználónak továbbítódnak. Így a www címre küldött leveleket is a root kapja meg. Kisebb, statikus levelezési listák is megadhatóak így, ahol több címzett van (pl. a levlista); A Postfix ezt még nem kezeli, ezért adatbázist kell létrehozni belőle (erre utal a hash a fájlnév előtt), ez a /usr/bin/newaliases paranccsal tehető meg. A létrehozott fájl: /etc/mail/aliases.db 6.4 LDAP-ban tárolt alias-ok Az ldap-ban történő keresést az alábbi szerkezetű fájl teszi

lehetővé. /etc/postfix/ldapaliases.cf server host = ldap://ldaps.panthernet:389 search base = ou=MailAliases,dc=panthernet version = 3 scope = one bind = no query filter = (maillocaladdress=%s) result attribute = mailroutingaddress dereference = 3 timeout = 10 Az első sor azt az URI-t adja meg, ami a szervert azonosítja. A postfix a search base beállításban megadott csúcs alatti részfában keres. Mivel a scope értéke „one”, az előbb megadott csúcs gyerekeit nézi végig. A 3-as verzió a mostani A bind = no a névtelen kapcsolódást teszi lehetővé (mint a /etc/ldap.conf-ban a hasonló beállítás) 6.5 Virtuális tartományok Gyakran előfordul, hogy egy-egy szerveren egy vagy több tényleges tartomány (domain)van, amelyek levelei a tényleges felhasználóknak jönnek, azonban ezek mellett még további virtuális tartományok vannak. A virtuális tartományokra az a jellemző, hogy az oda érkező levelek továbbításra kerülnek. Postfix esetén külön fel

kell sorolni a virtuális tartományokat, továbbá azt is meg kell adni, hogy mi legyen a levelekkel A legegyszerűbb esetben – ezt nézzük meg most – a levelek továbbítását kell megadni. A maincf-ben megadjuk, hogy részben LDAP-ból, részben pedig hagyományos módon egy fájlból (hash prefix) történjen a cím-címzett megfeleltetés. main.cf részlet virtual alias domains = mytest.hu, mytest2hu virtual alias maps = hash:/etc/postfix/virtual, ldap:/etc/postfix/virtual-ldap-domains.conf Az LDAP változatnál annyi a változataás, hogy nem az ou=MailAliases alatt szerepelnek ezek, hanem önálló szervezeti egységben (ou=VirtualDomains) , és szintén szervezeti egységnek tekintjük az egyes tartományokat, vagyis részfában fog keresni a postfix. Ezért a scope = sub lesz a helyes beállítás a konfigurációs fájlban. 32 6. fejezet Levéltovábbítás és levélfogadás Ha egyszerű fájlt használunk, akkor mindig ki kell adni a postmap /etc/postfix/virtual

parancsot, hogy frissüljön az az adatbázisfájl is, amit a postfix olvas (/etc/postfix/virtual.db) Amennyiben azt szeretnénk, hogy minden egyéb levél, aminek az email címe nincs felsorolva egy adott címre vagy felhasználónak menjen, akkor a @domain1.hu stílusú (felhasználó nélkül megadott) email címre kell megmondani, mi történjen vele. virtual # lokális címre küldés (tényleges felhasználó) user1@mytest.hu panther user2@mytest.hu root # másik tartományba küldés user3@mytest.hu azon@examplecom # minden egyéb, az adott tartományba érkező levél küldése # angolul: ‘‘catch-all’’ @mytest.hu postmaster@examplenet virtual-ldap-domains.conf server host = ldap://ldaps.panthernet:389 search base = ou=VirtualDomains,dc=panthernet version = 3 scope = sub bind = no query filter = (maillocaladdress=%s) result attribute = mailroutingaddress dereference = 3 timeout = 10 Ilyen körülmények között felmerül a kérdés, hogy pontosan mi lesz a levelekkel? A

problémák, kérdések: (a) Egy címhez több különböző cél adott. Ha pl a user1@mytesthu ldap-beli célja (mailRoutingAddress bejegyzése) más, pl user4@examplenet, akkor mi történik? (b) Egy címhez több különböző helyen definiált cél adott. Pl a uer1@mytesthu célja az ldapban ugyanaz, mint a fájlban, akkor mi történik? (c) A fájlban adott catch-all cím mellett vannak további bejegyzések az ldap-ban is. (d) Ldap-ban definiált catch-all cím. A válaszok: (a) A virtual alias maps-ban megadott sorrend számít, ezért amelyik előrébb van, az dönt. (b) Az előzővel azonos. (c) A catch-all cím (alapértelmezett cím) mindig az utolsó, ezért a postfix előbb végignézi az összes lehetséges bejegyzést, hátha talál olyat, ami erre vonatkozik, ha nincs, csak utána foglalkozik az alapértelmezett címmel. (d) A catchall cím mindig az utolsó, akárhol is definiált. 6.5 Virtuális tartományok 33 Az LDAP bejegyzések Az email címek

csoportosíthatóak a következők szerint: ou=VirtualDomains szervezeti egység alatt van minden ilyen bejegyzés. Ez alatt szervezeti egységként az összes tartomány Ezek alatt pedig az email címek, amelyek nyilván egyediek, ezért az account objektumosztály megfelelő erre, akárcsak a MailAliases szervezeti egységben, és be kell állítani az uid attribútumot, amely lehet a cím @ előtti része. Most álljon itt néhány példa, ilyen sorrendben is kell létrehozni őket: VirtualDomains dn: ou=VirtualDomains,dc=panthernet ou: VirtualDomains objectClass: top objectClass: organizationalUnit description: Postfix Virtual Domains Root node mytest.hu dn: ou=mytest.hu,ou=VirtualDomains,dc=panthernet ou: mytest.hu objectClass: top objectClass: organizationalUnit mytest2.hu dn: ou=mytest2.hu,ou=VirtualDomains,dc=panthernet ou: mytest2.hu objectClass: top objectClass: organizationalUnit usr@mytest2.hu dn: uid=usr,ou=Mytest2.hu,ou=VirtualDomains,dc=panthernet objectClass: account

objectClass: top objectClass: inetLocalMailRecipient mailLocalAddress: usr@mytest2.hu uid: usr mailRoutingAddress: panther default dn: uid=default,ou=Mytest2.hu,ou=VirtualDomains,dc=panthernet objectClass: account objectClass: top objectClass: inetLocalMailRecipient mailLocalAddress: @mytest2.hu uid: default mailRoutingAddress: panther@example.net Azonban nem kötelező az ilyen elrendezés, használható akár maga az email cím is az uid attribútum értékeként. Itt az is változtatás, hogy közvetlenül a VirtualDomains alatt van, amely azonban átláthatatlanná tehet egy bonyolultabb adatbázist (fastruktúrát). 34 6. fejezet Levéltovábbítás és levélfogadás user1@mytest.hu dn: uid=user1@mytest.hu,ou=VirtualDomains,dc=panthernet objectClass: account objectClass: top objectClass: inetLocalMailRecipient mailLocalAddress: user1@mytest.hu mailRoutingAddress: user@example.net uid: user1@mytest.hu 7. fejezet Kerberos Egy részletes leírás itt olvasható:

http://cfhay.infeltehu/kerberos/leirashtml A Kerberos a felhasználók (és szolgáltatások) biztonságos hitelesítésére szolgál. Amikor valaki bejelentkezik a gépre a jelszójával, akkor kap egy őt azonosító ticket-et, jegyet. Ezzel igényelhet továbbiakat, például amikor továbbssh-zik egy másikra, vagy éppen elolvassa a levleleit. A DNS-hez hasonlóan itt is tartományok vannak, csak ezeket realm-oknak hívják. Például az examplecom-hoz tartozó realm EXAMPLECOM (vagyis a domain név nagybetűs alakja, megszokásból, ugyanis nem kötelező így eljárni). Nálam ez PANTHERNET Bejelentkezés után kapott „ jegy” a krbtgt/PANTHERNET@PANTHERNET lesz. Itt a név a krbtgt (pontosabban krbtgt/PANTHERNET) és a realm a „@” után álló rész, ami szintén PANTHERNET. Az adott felhasználó, pl panther bejegyzése a panther@PANTHERNET alakú, a néven kívül további tulajdonságok is tartoznak: mikor jár le a jelszó, milyen lehet (bármilyen, vagy pl. kell

kisbetű is, szám is, stb) Ez a kettő szorosan összekapcsolódik Az utóbbi a felhasználót azonosítja, az előbbi a kerberizált szolgáltatások elérésére szolgál, ezért is a neve ticket granting ticket, vagyis további jegyeket biztosító jegy. Egy realm nem csak felhasználókat tartalmaz, hanem szolgáltatásokat is, ezek formája: szolgáltatásnév/gépnév@REALM. Ilyen például a imaps/zeratulpanthernet@PANTHERNET Ezt a jegyet akkor kapjuk meg, ha már egyszer bejelentkeztünk az imap szerverre. SSH szerver használata esetén pédául a host/fenix.panthernet@PANTHERNET jegyet kapjuk meg. Ebben a dokumentumban a mit-krb5 változatról lesz szó, viszont létezik másik implementáció is, a heimdal. A jegyet nevezhetjük kulcsnak is, és akkor kulcskiosztó szerverünk van (KDC). 7.1 A kerberos beállítása A legfontosabb beállásokat a /etc/krb5.conf tartalmazza 7.11 /etc/krb5.conf illetve DNS bejegyzések A fájlt mindenki olvashatja. Nálam ezek a

beállítások vannak: krb5.conf [libdefaults] ticket lifetime = 86400 default realm = PANTHERNET 36 7. fejezet Kerberos forwardable = true [realms] PANTHERNET = { kdc = 10.01101:88 admin server = 10.01101:749 } [domain realm] .panthernet = PANTHERNET panthernet = PANTHERNET localhost = PANTHERNET [logging] kdc = FILE:/var/log/krb5kdc.log admin server = FILE:/var/log/kadmin.log default = FILE:/var/log/krb5lib.log A logolás (logging) nem túl érdekes. A libdefaults tartalmazza az alapértelmezett beállításokat Az első sor a jegy élettartamát adja meg, mely most egy nap A következő az alapértelmezett realm, amely azért szükséges, hogy ne kelljen mindig kiírni, melyik realmról van szó. Az utolsó pedig azt jelzi, hogy a kapott jegyek továbbíthatók más szerverekre (például ssh-n keresztül). Amennyiben a kerberos szerver másik gépen van (nálam ugyanaz), akkor szükség van még egy beállításra a fenti hármon felül. Ez mondja meg, hogy hány

másodperccel térhet el a kerberos szerver és az aktuális gép rendszerórája. A név a clockskew, alapértelmezett értéke 300 (5 perc). Többit lásd man 5 krb5conf A következő szakasz azt mondja meg, hogy hol keresse a kerberos szervereket egy adott realmhoz. Jelen esetben a kdc is és az kadmin szerver is a gépemen van, a 88-as illetve 749-es porton. Próbáltam localhost-ot megadni, de az nem működött rendesen Ugyanitt megadható több további realm is. Ha így nem szerepel, akkor még van egy lehetőség, hogy az adott realm nevének megfelelő dns bejegyzéseket keres. Tegyük fel, hogy két kerberos szerverünk van, kdc1 és kdc2. Ekkor a DNS bejegyzések a következők lesznek: kerberos DNS bejegyzések kerberos. udp IN SRV 1 0 88 kdc1 kerberos. tcp IN SRV 1 0 88 kdc1 kerberos. udp IN SRV 10 0 88 kdc2 kerberos. tcp IN SRV 10 0 88 kdc2 kerberos-adm. tcp IN SRV 1 0 749 kdc1 kpasswd. udp IN SRV 1 0 464 kdc1 kerberos IN TXT "EXAMPLE.COM" Itt a

gépnevek végén nincsen pont, ezért a tartományon belül szerepelnek, pl. a gépem esetén így egészülne ki: 7.1 A kerberos beállítása 37 kerberos.udppanthernet IN SRV 1 0 88 kdc1panthernet A kdc1 az elsődleges kerberos kiszolgáló, ezért az SRV bejegyzés után álló számot kisebbre kell állítani (1 versus 10). A 88 a kdc standard (krb5-ös) portja (tcp + udp), 749 pedig a kadmin szerveré. A jelszóváltoztatást is és a realm felügyeletét is a kdc1-en keresztül lehet megtenni. A krb5.conf fájl következő szakasza a [domain realm], amely azt adja meg, melyik géphez melyik realm tartozik. Itt lehet tartomány is, ilyenkor ponttal kezdődik, és lehet konkrét gép is. Erre példa a panthernet és a localhost Mindkettőhoz a PANTHERNET realm tartozik. Ha így nem található meg egy géphez tartozó realm, akkor a rendszer levágja a domain nevet, pl. fooexamplecom esetén ez az examplecom, és megnézi, hogy a domain névhez milyen TXT bejegyzés

tartozik. A fenti példában az EXAMPLECOM Továbbá megnézi a fent megadott kerberos.* bejegyzéseket is, amely révén megtalálja a géphez tartozó kerberos kiszolgálót. 7.12 A realm létrehozása A(z elsődleges) KDC-n a kadmin.local programmal lehet adminisztrálni a realmot Ha ezt még nem hoztuk létre, akkor ilyen hibaüzenetet kapunk: # kadmin.local\ Authenticating as principal root/admin@PANTHERNET with password. kadmin.local: No such file or directory while initializing kadminlocal interface Hozzuk létre (PANTHERNET helyére értelemszerűen mást írva): realm létrehozása # kdb5 util create -s -r PANTHERNET Loading random data Initializing database ’/etc/krb5kdc/principal’ for realm ’PANTHERNET’, master key name ’K/M@PANTHERNET’ You will be prompted for the database Master Password. It is important that you NOT FORGET this password. Enter KDC database master key: Re-enter KDC database master key to verify: A realm adatbázisa (fájlja) a

következő: /etc/krb5kdc/principal. A fájlt jelszó védi, amit érdemes felírni és jól elzárt helyen tárolni. Enélkül könnyen visszaélhet valaki a jogosultságokkal. Ha nem ismert a jelszó, akkor nem lesz mindenre jogunk (nekem helyi gépen nem sikerült helyzetet produkálni, talán csak szerencsém volt). A legfontosabb bejegyzés a K/M@PANTHERNET, ezt TILOS kiexportálni, mert ennek ismeretében bármilyen változtatást megtehet a szerveren az, aki csak akar. Ha meg kell adni a mesterjelszót a kadmin.local-nak, akkor azt a parancs után megadott -m opcióval tehetjük meg A program indulás után bekéri a jelszót 38 7.2 7. fejezet Kerberos A kerberos bejegyzések létrehozása és listázása A kadmin.local kliens programot elindítva elkedhetjük a felhasználókat és a szolgáltatásokat megadni Első lépésben házirendeket (policy) érdemes létrehozni, amelynek most különösebb szerepe nincsen, viszont bármikor szükséges lehet a szabályok

szigorítása, és így általánosan kezelhetjük a felhasználókat. A kliensben van segítség is, mely a help parancs hatására jön elő, illetve egy nem teljesen megadott parancs is kiírja paraméterezését. A parancsoknak van hosszabb és rövidebb formájuk is. házirendek # kadmin.local Authenticating as principal root/admin@PANTHERNET with password. kadmin.local: addpol add policy: parser lost count! usage; add policy [options] policy options are: [-maxlife time] [-minlife time] [-minlength length] [-minclasses number] [-history number] kadmin.local: addpol users kadmin.local: addpol admin kadmin.local: addpol hosts A fenti 3 házirenddel szétválaszthatjuk a jogosultságok szerint az ún. pricipal -okat (a létrehozott bejegyzéseket). Az enyémet (normál ill. admin változatban) így lehet hozzáadni (a parancs 2 alakját használva a 3-ból): Felhasználók hozzáadása kadmin.local: ank -policy users panther Enter password for principal

"panther@PANTHERNET": Re-enter password for principal "panther@PANTHERNET": Principal "panther@PANTHERNET" created. kadmin.local: addprinc -policy admin panther/admin Enter password for principal "panther/admin@PANTHERNET": Re-enter password for principal "panther/admin@PANTHERNET": Principal "panther/admin@PANTHERNET" created. Ha ki szeretnénk listázni az összeset, akkor a következőképp járjunk el (és ilyesmilyen kimenetet kapunk): kadmin.local: listprincs K/M@PANTHERNET . panther/admin@PANTHERNET Normál felhasználóként indítva más promptot kapunk és másképp kell indítani: Normál felhasználóként indítva panther ~ > /usr/sbin/kadmin Couldn’t open log file /var/log/kadmin.log: Permission denied 7.2 A kerberos bejegyzések létrehozása és listázása 39 Couldn’t open log file /var/log/kadmin.log: Permission denied Authenticating as principal panther/admin@PANTHERNET with password. Password

for panther/admin@PANTHERNET: kadmin: Az első két sor elfogadható, hiszen csak a rootnak szabad írnia a log fájlokat. Utána kiírja, hogy a felhasználói fiók admin változatával próbál csatlakozni, ehhez bekéri a jelszót. Ekkor sajnos még nincs jogunk listázni sem a principal-okat. A kdc-t tartalmazó géphez tartozó principal hozzáadása: kadmin.local: addprinc -randkey -policy hosts host/zeratulpanthernet Principal "host/zeratul.panthernet@PANTHERNET" created kadmin.local: ktadd -k /etc/krb5keytab host/zeratulpanthernet Entry for principal host/zeratul.panthernet with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytab Entry for principal host/zeratul.panthernet with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytab Most nem kell jelszó, ezért egy véletlen kulcsot generál a program a -randkey opció hatására. Mivel a kiszolgáló nem adhat meg jelszót, ezért

jelszava például a /etc/krb5keytab fájlban tárolódik, vagy másban, a lényeg, hogy csak a kiszolgáló felhasználója tudja olvasni. Itt most ebbe a fájlba került. 7.21 A KDC beállítása A KDC beállítófájlja, amin nem nagyon kell változtatni (/etc/kdc.conf): kdc.conf [kdcdefaults] kdc ports = 88,750 [realms] PANTHERNET = { database name = /etc/krb5kdc/principal admin keytab = /etc/krb5kdc/kadm5.keytab acl file = /etc/krb5kdc/kadm5.acl dict file = /etc/krb5kdc/kadm5.dict key stash file = /etc/krb5kdc/.k5PANTHERNET kadmind port = 749 max life = 10h 0m 0s max renewable life = 7d 0h 0m 0s master key type = des3-hmac-sha1 supported enctypes = des3-hmac-sha1:normal des-cbc-crc:normal } Egy KDC több realmot is kiszolgálhat. Amennyiben automatikusan szeretnénk elindítani, a mester jelszó megadása nélkül, akkor a key stash file opcióban megadott fájlra 40 7. fejezet Kerberos szükségünk van, ellenkező esetben töröljük le. Az automatikus indítás a

biztonság rovására megy, mert a fájl megszerzésével vissza lehet élni. A /etc/krb5kdc/kadm5.acl fájl tartalmazza a jogosultságokat, jelen esetben: kadm5.acl */admin@PANTHERNET * vagyis az összes adminnak mindenhez van joga. A /etc/krb5kdc/kadm5.keytab az admin keytab (kulcsokat tartalmazó fájl), ide két principal-t kell betenni: principal keytab-hoz adása kadmin.local: ktadd -k /etc/krb5kdc/kadm5keytab kadmin/admin kadmin/changepw Entry for principal kadmin/admin with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab Entry for principal kadmin/admin with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab Entry for principal kadmin/changepw with kvno 4, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5kdc/kadm5.keytab Entry for principal kadmin/changepw with kvno 4, encryption type DES cbc mode with CRC-32 added to keytab

WRFILE:/etc/krb5kdc/kadm5.keytab 7.3 Szolgáltatások hozzáadása Tegyük fel, hogy a cyrus szervert szeretnénk beüzemelni. Neki külön keytab fájl kell, ezt a következőképpen tehetjük meg (kadmin vagy kadmin.local is jó): szolgáltatás principal hozzáadása admin.local: addprinc -randkey -policy hosts imap/zeratulpanthernet Principal "imap/zeratul.panthernet@PANTHERNET" created kadmin.local: ktadd -k /etc/krb5keytabcyrus imap/zeratulpanthernet Entry for principal imap/zeratul.panthernet with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytabcyrus Entry for principal imap/zeratul.panthernet with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytabcyrus Bármely további szolgáltatást hasonlóképpen, szolgáltatásnév/szervernév formában megadhatunk. Itt a /etc/krb5keytabcyrus fájl a cyrus tulajdonában lévő, csak általa olvasható (és esetleg írható) fájl. 7.4

Jegyek igénylése, kezelése Általában bejelentkezéskor kapunk egy jegyet, ahogy fentebb elhangzott, a tgt-t, azonban néha szükség lehet arra, hogy menet közben ezt eldobjuk, vagy éppen másik realmból szeretnénk jegyet kapni. Például bejelentkeztem az INF.ELTEHU tartományba, és a host ticketeknek megfelelően a 3 gépre: 41 7.5 A pam beállítása klist klist Ticket cache: FILE:/tmp/krb5cc 1000 Default principal: panther@INF.ELTEHU Valid starting Expires 07/30/06 23:59:19 07/31/06 09:59:30 renew until 07/31/06 23:59:19 07/30/06 23:59:54 07/31/06 09:59:30 renew until 07/31/06 23:59:19 07/30/06 23:59:54 07/31/06 09:59:30 renew until 07/31/06 23:59:19 07/30/06 23:59:54 07/31/06 09:59:30 renew until 07/31/06 23:59:19 Service principal krbtgt/INF.ELTEHU@INFELTEHU host/valerie.infeltehu@INF host/panda.infeltehu@INF host/pandora.infeltehu@INF Itt a jegy a /tmp/krb5cc 1000 fájlban van, amelyben az alapértelmezett (principal) a panther@INF.ELTEHU Ennek eldobása:

kdestroy Ha nincsen „default principal”, akkor a /etc/krb5.conf alapértelmezett realm-ját veszi alapul, ellenkező esetben a principalt újítja meg: kinit kinit Password for panther@INF.ELTEHU: A kinit egyik legfontosabb opciója a -f és a -F, az előbbivel lehet továbbítható (forwardable) jegyet igényelni, utóbbi pedig letiltja ezt. Ha továbbítható a jegy, akkor jelszókérés nélkül be lehet jelentkezni másik gépre is, ugyanis a jegy azonosít minket. 7.5 A pam beállítása Ahhoz, hogy bejelentkezéskor a kerberosban tárolt jelszavunkat használjuk, be kell állítani a PAM-ban a kerberos használatát. A PAM a „Pluggable Authentication Modules for Linux” rövidítése, olyan hitelesítő modulokból áll, amelyek szabadon cserélhetőek. A változtatások azonnal érvénybe lépnek, a PAM-ot használó alkalmazás újraindítása nélkül is. A beállításokat a /etc/pamd könyvtár tartalmazza. A Gentoo Linuxon az általánosan használt rész egy

külön fájlban, a /etc/pam.d/system-auth-ban van: system-auth auth required pam env.so auth sufficient pam unix.so likeauth nullok auth sufficient pam krb5.so use first pass forwardable auth required pam deny.so 42 7. fejezet Kerberos account required pam unix.so password required password password password sufficient sufficient required pam cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3 pam unix.so nullok md5 shadow use authtok\ pam krb5.so use first pass\ pam deny.so session session session session session required sufficient sufficient required required pam limits.so pam unix.so pam krb5.so pam deny.so pam unix.so Ez egy tipikusan hibás fájl, ami viszont jól szerepel benne: a pam krb5-öt ugyanúgy kell kezelni, mint a pam unix-ot. Az előbbi az első jelszót használja, ha nem sikerülne a pam unix jelszóellenőrzése, valamint továbbítható jegyet kér. Hogyan lehet használni a fenti fájlt? Például így: auth auth account session required

include include include pam nologin.so system-auth system-auth system-auth 8. fejezet Cyrus (IMAP) A Cyrus IMAP szerverhez fel kell tenni a következő csomagokat (a SASL-ra legfőképpen későbbb lesz szükség). dev-libs/cyrus-sasl net-mail/cyrus-imap-admin net-mail/cyrus-imapd Korábban már láttuk, hogyan lehet az imap/zeratul.panthernet@PANTHERNET principalt hozzáadni a rendszerhez, a továbbiakban szükség lesz rá Tegyük fel, hogy kinit-tel már azonosítottuk magunkat. Ekkor kipróbálhatjuk a már elindított imap szervert: $ imtest -m GSSAPI -u panther zeratul.panthernet S: * OK zeratul Cyrus IMAP4 v2.212-Gentoo server ready C: C01 CAPABILITY S: * CAPABILITY IMAP4 IMAP4rev1 ACL QUOTA LITERAL+ MAILBOX-REFERRALS NAMESPACE UIDPLUS ID NO ATOMIC RENAME UNSELECT CHILDREN MULTIAPPEND BINARY SORT THREAD=ORDEREDSUBJECT THREAD=REFERENCES ANNOTATEMORE IDLE STARTTLS LOGINDISABLED AUTH=GSSAPI SASL-IR LISTEXT LIST-SUBSCRIBED X-NETSCAPE S: C01 OK Completed Hogyha nem menne,

akkor a /etc/cyrus.conf fájlt kell módosítani: 44 8. fejezet Cyrus (IMAP) SERVICES { # Add or remove based on preferences. imap cmd="imapd" listen="imap2" prefork=0 pop3 cmd="pop3d" listen="pop-3" prefork=0 # Don’t forget to generate the needed keys for SSL or TLS # (see doc/html/install-configure.html) imaps cmd="imapd -s" listen="imaps" prefork=0 #pop3s cmd="pop3d -s" listen="pop3s" prefork=0 sieve cmd="timsieved" listen="sieve" prefork=0 # at least one LMTP is required for delivery #lmtp cmd="lmtpd" listen="lmtp" prefork=0 lmtpunix cmd="lmtpd" listen="/var/imap/socket/lmtp" prefork=0 # this is only necessary if using notifications #notify cmd="notifyd" listen="/var/imap/socket/notify" proto="udp" prefork=1 } Ennek megfelelően a postfix beállítása: mailbox transport = lmtp:unix:/var/imap/socket/lmtp

Itt az imap, pop3, imaps portok engedélyezettek, utóbbihoz szükség van egy CA által aláírt tanúsítványra is #/etc/imapd.conf részlet tls ca file: /etc/ssl/panthernet.cacrt tls cert file: /etc/ssl/cyrus/server.crt tls key file: /etc/ssl/cyrus/server.key A fenti beállítások mellett előjött az a hiba, hogy a saslauthd nem futott, valamint a postfixnak nem volt joga a cyrus unix foglalatához: 45 Oct 30 09:51:12 zeratul imaps[9961]: starttls: SSLv3 with cipher AES256-SHA (256/256 bits reused) no authentication Oct 30 09:51:19 zeratul imaps[9961]: cannot connect to saslauthd server: No such file or directory Oct 30 09:51:19 zeratul imaps[9961]: badlogin: zeratul.panthernet [1001101] plaintext panther SASL(-1): generic failure: checkpass failed Oct 30 09:52:51 zeratul postfix/pickup[9204]: AE99D79BB78E: uid=1000 from=<panther> Oct 30 09:52:51 zeratul postfix/cleanup[10026]: AE99D79BB78E: message-id=<20051030085251.AE99D79BB78E@zeratulpanthernet> Oct 30

09:52:51 zeratul postfix/qmgr[9205]: AE99D79BB78E: from=<panther@zeratul.panthernet>, size=488, nrcpt=1 (queue active) Oct 30 09:52:51 zeratul postfix/lmtp[10029]: AE99D79BB78E: to=<panther@zeratul.panthernet>, orig to=<panther>, relay=none, delay=0, status=deferred (connect to /var/imap/socket/lmtp[/var/imap/socket/lmtp]: Permission denied) A Cyrus imap fájlját a következő módon tettem elérhetővé a postfix számára: zeratul socket # setfacl -m u:postfix:x . zeratul socket # setfacl -m u:postfix:x . zeratul socket # setfacl -m u:postfix:rw lmtp zeratul socket # l összesen 12 drwxr-x–-+ 2 cyrus mail 88 okt 30 09:58 ./ drwxr-x–-+ 12 cyrus mail 4096 okt 30 09:51 ./ -rw–––1 cyrus mail 0 okt 29 23:18 imap-1.lock -rw–––1 cyrus mail 0 okt 30 09:25 imaps-1.lock -rw-r–r– 1 root root 0 okt 29 23:09 .keep srwxrwxrwx+ 1 cyrus mail 0 okt 30 09:51 lmtp= 9. fejezet Spam- és vírusszűrés Az Amavisd-new egy általános célú levélszűrő, spam-

és vírusszűrő programokat hív meg és az általuk adott válasz alapján eldönti, hogy az adott levél spam-e, vagy épp vírusos-e. Egy minimális konfiguráció (amit be kell állítani) a következő: amavisd.conf részlet $mydomain = ’panthernet’; $myhostname = ’zeratul.panthernet’; $daemon user = ’amavis’; # (no default; customary: vscan or amavis) $daemon group = ’clamav’; # (no default; customary: vscan or amavis) $virus admin = "panther@$mydomain"; $mail notify admin = "antivirus@$mydomain"; $mail notify spamadmin = "antivirus@$mydomain"; #### http://www.clamavnet/ #$ # [’ClamAV-clamd’, # &ask daemon, ["CONTSCAN {} ", "/var/run/clamav/clamd.sock"], # qr/OK$/, qr/ extbackslash bFOUND$/. Az amavisnak a clamav-vel azonos csoportban kell lennie, hogy olvashassa a clamav socket fájlját, a /var/run/clamav/clamd.sock-t A mail notify* a levelek feladója, ha értesítést küld a rendszer, hogy spamet

vagy mást talált. Illetve be kell állítani, hogy a könyvtár (/var/amavis) megfelelő tulajdonú legyen: # chown -R amavis:amavis /var/amavis 9.1 A ClamAV beállítása A ClamAV alapértelmezett konfigja csak példa, ezért egy hashmark (#) karaktert kell az „Example” sor elé tenni: clamd.conf részlet # Example LogFile /var/log/clamav/clamd.log LocalSocket /var/run/clamav/clamd.sock 48 9. fejezet Spam- és vírusszűrés A LocalSocket ugyanaz legyen, mint ami az /etc/amavisd.conf-ban szerepel Ha ez megvan, már működőképes a rendszer. 9.2 A Postfix beállítása az Amavisd-New használatára A /etc/postfix/master.cf fájlban kell módosítani, az első három sor talán nem kell master.cf részlet ### # AMAVIS etc 127.001:10025 inet n n smtpd -o content filter= -o local recipient maps= -o smtpd client restrictions= -o smtpd helo restrictions= -o smtpd sender restrictions= -o smtpd restrictions=permit mynetworks,reject unauth destination -o

mynetworks=127.000/8 -o strict rfc821 envelopes=yes -o smtpd error sleep time=0 -o smtpd soft error limit=1001 -o smtpd hard error limit=1000 smtp-amavis unix n 2 smtp -o smtp data done timeout=1200 -o disable dns lookups=yes A /etc/postfix/master.cf fájlban is kell egy új sor: content filter = smtp-amavis:[127.001]:10024 Mi is történik ekkor? A Postfix kap egy levelet a 25-ös porton. Ezt továbbadja a localhost 10024-es portjára az amavisd-new-nak. Az amavisd-new meghívja a spam- és vírusszűrőket, majd visszaküldi a levelet a postfixnak a localhost 10025-ös portján Bizonyos feltételek mellett bármikor blokkolódhat a levél. Ha az amavis karanténba zárja, akkor értesítést küld, alapesetben a localhost 10025-ös portjára. 10. fejezet SSL, OpenLDAP, SASL beállítása Az OpenLDAP is támogatja a Kerberost, ehhez neki is meg kell adni egy keytab fájlt. A szolgáltatásnév ldap/gepnev. Például: kadmin.local: ktadd -k /etc/krb5keytabldap

ldap/zeratul.panthernet Entry for principal ldap/zeratul.panthernet with kvno 3, encryption type Triple DES cbc mode with HMAC/sha1 added to keytab WRFILE:/etc/krb5.keytabldap Entry for principal ldap/zeratul.panthernet with kvno 3, encryption type DES cbc mode with CRC-32 added to keytab WRFILE:/etc/krb5.keytabldap A /etc/openldap/slapd.conf fájlt be kell állítani a SASL (GSSAPI) használatára: sasl-realm panthernet sasl-regexp uid=([,̂]+),.*cn=GSSAPI uid=$1,ou=People,dc=panthernet sasl-host zeratul.panthernet Az init scriptben meg kell adni, hol van a keytab fájl, még a slapd indulása előtt: export KRB5 KTNAME=/etc/krb5.keytabldap Kerberos ticket nélkül: panther@zeratul $ ldapsearch -Y GSSAPI uid=panther SASL/GSSAPI authentication started ldap sasl interactive bind s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Miscellaneous failure (No credentials cache found) panther@zeratul $ ldapsearch uid=panther ldap sasl interactive bind s: No such

object (32) Azzal együtt már működik: $ ldapsearch -Y GSSAPI uid=panther 11. fejezet Levelezőkliensek beállítása 11.1 Mutt A mutt rendszerszintű beállítófájljában, a /etc/mutt/Muttrc-ben a következőket állítjuk be: set set set set certificate file="/etc/openldap/ssl/cacert.pem" move=no set hostname=panthernet ssl starttls=yes folder=$MAIL Az első a CA tanúsítványát jelöli, a 3. azért kell, hogy ne a gépnévdomain alakú email cím legyen, ha elküld a rendszer egy levelet, a 4. az SSL/TLS titkosítást állítja be, végül az utolsó az IMAP könyvtár helye (INBOX), ami egy környezeti változó: export MAIL={$USER@zeratul.panthernet}INBOX 11.2 Thunderbird A Thunderbird címjegyzékében megadható LDAP kiszolgáló is, ilyenkor kereshetőek a szerveren található bejegyzések. 11.21 A kiszolgáló megadása A kiszolgáló tulajdonságai ablakban megadható a kapcsolat tulajdonságai, a következők szerint: Általános fül. Itt a

kapcsolat minimális tulajdonságai állíthatóak be Név: Panthernet Gépnév: ldaps.panthernet Alap DN: ou=People,dc=Panthernet Port száma: 389 52 11. fejezet Levelezőkliensek beállítása Ennyi elég, a gépnév (Host) a kiszolgáló neve vagy IP címe, az alap DN (Base DN) az a csúcs, amely alatt keres a Thunderbird. A port száma pedig ahol a kiszolgáló megtalálható Előfordulhat, hogy névtelen kapcsolódás tiltott, ekkor meg kell adni a Bejelentkezési DN beállítást is, pl. uid=panther,ou=People,dc=panthernet Az első csatlakozáskor kéri a jelszót is. Végül megadható az is, hogy SSL titkosítást használjon-e Ebben az setben a jelszavak, adatok nem mindenki által olvashatóan, hanem kódoltan mennek a hálózaton, ezért érdemes használni. Haladó fül. Néhány további beállítás adható meg, egyrészt a Hatókör (Scope), amely lehet Egy szint (One level?), illetve Részfa (Subtree), másrészt a keresés szűkítésére szolgáló szűrő.

Alapesetben ez objectClass=*), azonban szűkíthető, hogy csak olyan bejegyzéseket listázzon, amelyek ténylegesen egy kapcsolatot (vagy bejelentkezési azonosítót) jelölnek: (objectClass=inetOrgPerson). Források, javasolt oldalak OpenLDAP http://tldp.fsfhu/HOWTO/LDAP-HOWTO-hu/indexhtml LDAP-hogyan http://sapiens.wustledu/~sysmain/info/openldap/openldap populatehtml LDAPban tárolt felhasználók, jelszavak, stb Samba http://www.unaves/cti/ldap-smb/ldap-smb-2 2-howtohtml http://sourceforge.net/project/showfilesphp?group id=166108 IDX-smbpldap-tools http://www.idealxcom/content/view/184/169/lang,fr/ IDEALX, Samba oldal OpenSSL, tanúsítványok Postfix http://postfix.org http://www.postfixorg/VIRTUAL READMEhtml Kerberos http://aput.net/~jheiss/krbldap/howtohtml Replacing NIS with Kerberos and LDAP HOWTO http://www.cmfnrlnavymil/CCS/people/kenh/kerberos-faqhtml#general Kerberos FAQ Egy slapd.conf állomány # # See slapd.conf(5) for details on configuration options #

This file should NOT be world readable. # include /etc/openldap/schema/core.schema include /etc/openldap/schema/cosine.schema include /etc/openldap/schema/inetorgperson.schema include /etc/openldap/schema/nis.schema include /etc/openldap/schema/misc.schema include /etc/openldap/schema/samba.schema # Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap://root.openldaporg pidfile argsfile # # # # # # # /var/run/openldap/slapd.pid /var/run/openldap/slapd.args Load dynamic backend modules: modulepath /usr/lib/openldap/openldap moduleload back bdb.la moduleload back ldap.la moduleload back ldbm.la moduleload back passwd.la moduleload back shell.la # Sample security restrictions # Require integrity protection (prevent hijacking) # Require 112-bit (3DES or better) encryption for updates # Require 63-bit encryption for simple bind #security ssf=1 update ssf=112 simple

bind=64 # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: 56 # # # # # # # # # # # # # # # . fejezet Egy slapdconf állomány Allow self write access Allow authenticated users read access Allow anonymous users to authenticate Directives needed to implement policy: access to dn.base="" by * read access to dn.base="cn=Subschema" by * read access to * by self write by users read by anonymous auth if no access controls are present, the default policy allows anyone and everyone to read anything but restricts updates to rootdn. (eg, "access to * by read") access to attrs=userPassword by dn="cn=admin,dc=panthernet" write by anonymous auth by self write by * none # The admin dn has full write access access to dn.children="ou=People,dc=panthernet" by dn="cn=admin,dc=panthernet" write by * read # rootdn can always read and write EVERYTHING!

sasl-realm panthernet sasl-regexp uid=([^,]+),.*cn=GSSAPI,.* uid=$1,ou=People,dc=panthernet sasl-host zeratul.panthernet ############ TLS ####### TLSCACertificateFile /etc/openldap/ssl/cacert.pem TLSCertificateFile /etc/openldap/ssl/ldaps.panthernetcrt TLSCertificateKeyFile /etc/openldap/ssl/ldaps.panthernetkey TLSCipherSuite HIGH,MEDIUM ####################################################################### # BDB database definitions ####################################################################### database suffix bdb "dc=panthernet" 57 rootdn "cn=Manager,dc=panthernet" # Cleartext passwords, especially for the rootdn, should # be avoid. See slappasswd(8) and slapdconf(5) for details # Use of strong authentication encouraged. rootpw {SSHA}stb. checkpoint 32 30 # <kbyte> <min> # The database directory MUST exist prior to running slapd AND # should only be accessible by the slapd and slap tools. # Mode 700 recommended. directory

/var/lib/openldap-data # Indices to maintain index objectClass eq LogLevel 0 Irodalomjegyzék [1] Bauer, Michael D.: Szerverek védelme Linuxszal 2003, Kossuth Kiadó ISBN 963 09 4488 X