Szakdolgozat. Makádi Zsolt. Műszaki informatikai szak, műszaki informatikai szakirány, nappali tagozat

Átírás

1 Szakdolgozat Makádi Zsolt Műszaki informatikai szak, műszaki informatikai szakirány, nappali tagozat Kecskeméti Főiskola Gépipari és Automatizálási Műszaki Főiskolai Kar KECSKEMÉT 2005

2 Samba alapú tartományvezérlők

3 Tartalomjegyzék 1. Bevezetés A szakdolgozat célja, témaválasztás A Samba bemutatása A Samba, mint tartományvezérlő A tartományba fűzés előnyei Alkalmazási lehetőségek Samba PDC + Windows kliensekből álló egyszerű tartomány Szerveroldali beállítások Kliensoldali beállítások Gyakorlati megvalósítás Samba PDC + Samba BDC + OpenLDAP + Windows kliens + Linux kliensből álló tesztrendszer A rendszer ismertetése Saját hitelesítésszolgáltató felállítása az OpenLDAP címtárhoz Az OpenLDAP szerver beállítása NSS és PAM beállítások A Samba PDC beállításai Az SMBLDAP Tools beállításai A Samba BDC beállításai UNIX kliensek Összegzés, továbbfejlesztési lehetőségek...26

4 1. Bevezetés 1.1. A szakdolgozat célja, témaválasztás A szakdolgozat célja a Samba 3.x tartományvezérlési képességeinek bemutatása konkrét példákon keresztül. A dolgozat két konkrét Samba 3 megvalósítást tárgyal. Az első egy egyszerű tartományvezérlőként működő szerver, a második pedig egy OpenLDAP címtárat használó, tartalék tartományvezérlővel és UNIX klienssel is rendelkező tesztrendszer. A témával a nyári gyakorlatom során ismerkedtem meg, az egyik feladatom egy irodai hálózat kivitelezése kapcsán a Linux tartományvezérlő szerver telepítése és konfigurálása volt. A dokumentációk tanulmányozása közben ismertem fel, hogy a Samba számos további lehetőséget nyújt, amelyekkel jóval nagyobb rendszereket is meg lehet valósítani. A dolgozatnak nem célja a Samba általános beállításainak és a Windows hálózatok alapfogalmainak ismertetése, mivel azokról számos leírás található a hivatkozott irodalmakban. A hangsúly mindkét megvalósítás kapcsán a gyakorlati lépésekre és az esetleges buktatókra kerül, a dolgozat kereteit ugyanis meghaladná az összes alkalmazott alrendszer részletes ismertetése. A célom azt bemutatni, hogy a felhasznált különálló, egyenként is jelentős képességű nyílt forráskódú szoftver együttes alkalmazásával komoly, akár nagyvállalati szintű rendszereket lehet kialakítani A Samba bemutatása A Samba egy olyan UNIX alkalmazáscsomag, amely az SMB (Server Message Block) protokollt beszéli. 1 Első verzióját 1992-ben adta ki Andrew Tridgell. Azzal a problémával szembesült ugyanis, hogy bizonyos alkalmazások csak ezen a protokollon keresztül hajlandóak kommunikálni, ezáltal nem tudják elérni a UNIX szerverek NFS-en keresztül megosztott állományait. Így tehát visszafejtette az SMB protokollt és 1 1

5 megvalósította UNIX alatt. A Samba alkalmazásának legfőbb előnye, hogy nyílt forráskódú, a GNU GPL szerint terjeszthető, ez nyilvánvalóan bármely cég számára jelentős megtakarítást eredményez. Kis cégek esetén ahol összesen néhány számítógépet kell a szervernek kiszolgálnia egy Windows szerver operációs rendszer ára közel eléri a hardver árát. Nagyvállalati környezetben pedig a processzorszám, a kliensek száma, vagy egyéb, a rendszer teljesítményével összefüggő többletköltség elmaradása a fő érv. A GPL licenc másik előnye, hogy megengedi a szoftver módosítását, ezt a zárt forráskódú megoldások nem biztosítják. Itt szeretném felhívni a figyelmet arra a gyakran felmerülő érvelésre, miszerint a nyílt forráskódú szoftverek készítői a zárt forráskódú termékeket előállító cégekkel szemben nem vállalnak felelősséget a programért. Ez első megközelítésben valóban helyes megállapítás, azonban meg kell vizsgálni, hogy a szoftverkészítő cégek felelősségvállalása valójában mire is terjed ki. A végfelhasználói licencszerződésekből ugyanis kiderül hogy minden cég szinte kivétel nélkül csupán bizonyos értékhatárig vállal felelősséget termékéért, legtöbbször a szoftver árának megfelelő összegig. S ami a legfontosabb: e felelősségvállalás nem terjed ki a hiba következményeként felmerülő egyéb károkra, például az adatvesztésre. Ezt figyelembe véve pedig látható, hogy ez a hátrány valójában nem összemérhető a fentebb vázolt előnyökkel, amit a nyílt forráskód biztosít. A sokéves tapasztalat azt mutatja, hogy a nagy GPL projektekben készülő szoftverek folyamatosan fejlődnek, javulnak, mint a Samba is immár 13 éve. Ha valami oknál fogva egyszer mégis abbahagynák a fejlesztését ami meglehetősen valószínűtlen akkor pedig a meglévő forráskód birtokában a cégek a felmerülő problémák megoldására alkalmazhatnak programozókat, akik a szükséges módosításokat el tudják végezni. Ezzel szemben szinte nincs olyan zárt forráskódú termék melynek készítői 13 év után még javításokat, fejlesztéseket adnának ki a szoftverhez, mivel az az érdekük, hogy az újabb változatok licencelésére ösztönözzék ügyfeleiket. Az természetesen igaz, hogy az akkori Samba változatokat sem fejlesztik már régen, azonban ez esetben az újabb verziók használatért sem kell fizetni. 2

6 2. A Samba, mint tartományvezérlő 2.1. A tartományba fűzés előnyei Egy Windows hálózat számítógépeinek tartományba fűzése számos előnnyel jár az egyszerű fájlmegosztáshoz képest. A legfontosabb, hogy a felhasználói fiókok a tartományvezérlőn tárolódnak, ezért központilag kezelhetőek ( ábra). Nagyszámú kliensgép esetén a hagyományos munkacsoport jellegű felépítéssel gyakorlatilag szinte lehetetlen kézben tartani a hálózatot, de kisebb rendszerek esetén is jelentősen rövidül az adminisztráláshoz szükséges idő. A mozgó profilok alkalmazásával minden felhasználó bármely kliensgépet ugyanúgy tudja használni mintha a sajátja előtt ülne, a bejelentkezési parancsfájlok használatával pedig az alkalmazások számára lehet egységes környezetet biztosítani minden gépről. Természetesen ez csak akkor teljesül maradéktalanul ha minden adat a kiszolgálókon van tárolva, ehhez minden alkalmazást úgy kell beállítani, hogy a helyi lemez helyett a hálózaton tárolja adatfájljait. Mindezeken felül adatbiztonsági szempontból is előnyös a központi adattárolás, mivel a kiszolgálók rendszerint redundáns háttértárrendszerrel és periodikus adatmentései lehetőséggel is fel vannak szerelve Ábra: A tartományi rendszer felépítése 2.2. Alkalmazási lehetőségek A 2.2 verziótól kezdve a Samba teljes értékű elsődleges NT4 típusú tartományvezérlőként (PDC - Primary Domain Controller) használható Windows 2000 és XP kliensek számára, sőt kliensként vagy tagszerverként részt vehet egy Active Directory 3

7 tartományban. Az Active Directory ugyanis natív módban engedélyez NT4 típusú tartományi tagokat, csak NT4 típusú tartalék tartományvezérlők (BDC - Backup Domain Controller) tiltottak. A 3-as Samba változat támogatja a Kerberos 5 hitelesítési és az LDAP címtárprotokollt, ezért részt vehet olyan Active Directory tartományban is ahol a biztonsági házirend tiltja az NT4 típusú hitelesítési protokoll használatát. Ugyanakkor nem képes sem elsődleges sem tartalék Active Directory tartományvezérlőként működni. Ennek az az oka, hogy habár az Active Directory hitelesítési megoldása az MIT Kerberos 5-re épül mégis eltér az eredeti protokolltól. Jelenleg egy UNIX szerver bármely Kerberos implementációt futtassa is csak helyi Windows felhasználók számára tud Kerberos hitelesítést nyújtani, tartományi felhasználók számára nem. A készülő 4-es Samba sorozat azonban már képes lesz erre is, jelenlegi tesztverzióját a Windows kliensek már felismerik Active Directory tartományvezérlőként. A Samba 3 BDC szerepben működhet egy Samba 3 PDC mellett, Windows PDC mellett azonban nem, ugyanis a natív NT4 SAM (Security Accounts Manager) replikációs protokoll még nincs teljesen implementálva. Ahhoz, hogy BDC-ként üzemeltessük a Sambát jelenleg LDAP szabványú címtárra van szükség mivel a többi adatbázis háttér nem támogatja a szükséges kétirányú replikációt. Mivel a tartományi tagok folyamatosan változtatják a MTA (Machine Trust Account) jelszót, abban az esetben ha a BDC nem tudja ezt a PDC-n is megváltoztatni (kétirányú replikáció hiányában), akkor az egyirányú replikáció során a PDC-től érkező adatbázis felülírja a BDC sajátját (mely időközben megváltozott) ezáltal a tartományi bizalmi rendszer összeomlik. Az LDAP háttér lehet egy közös mester szerver, vagy egy szolga szerver. A szolga LDAP szerverek és a BDC-k használatának lehetősége jól skálázható, nagyméretű rendszerek esetén is hatékony alternatívává teszik tehát a Sambát. 4

8 3. Samba PDC + Windows kliensekből álló egyszerű tartomány 3.1. Szerveroldali beállítások A nyári gyakorlatom során készített Samba PDC szerver konfigurációs állománya az 1. sz. mellékletben látható. Ez a kiszolgáló csak két démont futtat, az smbd maga a fájlkiszolgáló szerver, az nmbd pedig a névfeloldásért és a tallózásért felelős. A Samba egyetlen fájlon keresztül konfigurálható, ez rendszerint a /etc/samba/smb.conf állomány. A [global] részben adhatók meg a szerver beállításai, a további szögletes zárójelek közötti nevek az egyes megosztásokat jelölik. A tartományvezérlői szerepkör szempontjából fontos beállítások az alábbiak: - security = user Ez az alapbeállítás Samba 3 esetén. A klienseknek felhasználónév és jelszó megadásával be kell jelentkezniük a kiszolgálóra a megosztások eléréséhez. - passdb backend = tdbsam A Samba adatbázis-hátterének típusa. A tdbsam TDB alapú bináris adatbázis mely nagy számú felhasználó esetén jóval gyorsabb, mint a hagyományos szöveges smbpassword. Előnye, hogy a Samba automatikusan tudja generálni és kezelni, nincs szükség további beállításokra. - local master = yes Arra utasítja az nmbd-t, hogy vegyen részt a helyi főtallózó szerepkörért folyó választásban. - os level = 33 Meghatározza, hogy mekkora eséllyel nyeri el a helyi főtallózó szerepet az nmbd. Ha a 20-as alapértéken hagyjuk a Windows tartományvezérlők nyernek, 65-ös érték biztosítja, hogy minden Windows rendszer fölött a Samba nyerjen, a 33 egy ajánlott érték, mely a konkrét esetben is megfelelő. - domain master = yes Az opció hatására az nmbd a munkacsoport tartományi főtallózójaként hirdeti magát (ezt kizárólag a PDC-n szabad beállítani) - preferred master = yes Hatásra az nmbd szavazást kezdeményez. A domain master = yes opcióval együtt használva garantáltan ez a szerver lesz a tartomány főtallózója. - domain logons = yes A tartományi bejelentkezések kiszolgálására utasítja a szervert. - logon path = \\%L\Profiles\%U A kliensek számára adja meg, hogy a mozgó profilt 5

9 hol tárolják, %L a szerver NetBIOS nevét, %U a felhasználónevet jelenti. - logon drive = S: A kliensek számára adja meg, hogy melyik meghajtóként csatlakoztassa a felhasználó saját könyvtárát. - logon home = \\%L\%U A felhasználó saját könyvtárának elérési útvonala. - logon script = scripts\logon.cmd A Logon szkript NETLOGON megosztáson belüli elérési útja. A %U paraméterrel ez egyes felhasználóknak külön szkriptet adhatunk meg. - wins support = yes Utasítja az nmbd-t, hogy WINS szerverként is működjön. Nagyon fontos, hogy ha több kiszolgáló van,akkor egyszerre csak egy lássa el ezt a feladatot. - dns proxy = no Amikor az nmbd WINS szerverként működik akkor az ismeretlen NetBIOS neveket alapbeállításként DNS-el próbálja feloldani, mivel jelen esetben nincs DNS szerver ezért ez a funkció tiltva van. A mellékletben ezután következő szkriptek a tartományi fiókok (felhasználók, gépek, csoportok) UNIX fiókokhoz rendelését végzik, majd a megosztások következnek. Látható, hogy a tartományvezérlői szerephez feltétlenül szükséges NETLOGON szolgáltatás is egy egyszerű megosztás csupán, azonban amennyiben használni szeretnénk ezen könyvtár scripts alkönyvtárában kell elhelyezni logon.cmd néven a bejelentkezési parancsfájlt, és a Default User alkönyvtárban az alapértelmezett profilt. Miután a fájl elkészült a testparm parancs segítségével ellenőrizhetjük, hogy a Samba számára szintaktikailag helyes-e, s ha igen indíthatjuk az smbd és az nmbd szervert. Ezután a Samba adatbázis-hátteréhez hozzá kell adni a root fiókot az smbpasswd -a root paranccsal. Fontos megjegyezni, hogy az itt megadott jelszó alapesetben nem változtatja meg a UNIX fiók jelszavát, de van rá lehetőség a unix password sync opcióval (lásd 4.5). Ezt követően a Windows tartományi és helyi csoportjait kell UNIX csoportokhoz rendelni a net groupmap modify parancs segítségével, ahogyan a 2. sz. mellékletben látható; a forrás az [1] sz. irodalom es példája (26.o). Mivel ehhez a kiszolgálóhoz nem kapcsolódik címtárszolgáltatás így a tartományi felhasználói fiókokat és csoportokat tényleges UNIX fiók létrehozása nélkül nem lehet megfeleltetni UNIX fiókoknak. Ezért a konfigurációs fájlban lévő szkriptek a hagyományos UNIX felhasználó és csoportkezelő parancsokat használják. Ezzel a Samba beállítása elkészült, a szerver készen áll a kliensek beléptetésére. 6

10 3.2. Kliensoldali beállítások A Windows rendszerek egy tartomány tagjaivá az ún. tartományba léptetés után válhatnak, melyet csak a tartományi rendszergazda vagy egy általa erre feljogosított felhasználó tehet meg (ez a lehetőség csak a es Samba verziótól áll rendelkezésre). A hálózati csatoló beállításakor fontos, hogy a Microsoft Networks ügyfél opció engedélyezve legyen, valamint a TCP/IP Protokoll -> Tulajdonságok -> Speciális -> WINS fülön a PDC szerver IP címét megadjuk, mint WINS szervert. Windows 2000 vagy XP operációs rendszer esetén a Vezérlőpult -> Rendszer -> Számítógépnév -> Módosítás menü választásával adható meg a tartomány neve amelybe az adott gépet be szeretnénk léptetni ( ábra) Ábra: Windows XP kliens beléptetése a tartományba A jelszó megadása után az 'Üdvözöljük a tartományban Tartománynév' üzenetet kell kapnunk. Újraindítás után a helyi gép mellett immár a tartományt is választhatjuk bejelentkezési helyként, ahová azonban csak egy tartományi felhasználó léphet be, helyi nem. A tartományi felhasználói fiókokat kétféleképpen hozhatjuk létre illetve módosíthatjuk. Magán a kiszolgálón a hagyományos UNIX felhasználókezelő parancsok használata a legkézenfekvőbb, a Samba jelszó állításához pedig az smbpasswd. A Microsoft holnapjáról ingyenesen elérhető Windows NT Server Tools for Windows NT Workstation 4.0 programcsomag [2] User Manager programja ( ábra) segítségével 7

11 pedig bármely kliensgépről is kezelhetjük a fiókokat, de csak rendszergazdaként Ábra: A User Manager program Amikor a felhasználó először belép a tartományba az alapértelmezett felhasználói profil egy másolatát kapja, amelyet a NETLOGON megosztás Default User könyvtárából tölt le a kliensgép, vagy ha ez nem létezik, akkor a C:\Documents and Settings\Default User könyvtárból. Kijelentkezéskor a profilt a logon path által meghatározott könyvtárba menti a rendszer, s a legközelebbi bejelentkezéskor már onnan tölti le. Mivel a felhasználó minden adata és beállítása alapértelmezésként ebben a könyvárban van tárolva gyakorlatilag ezzel a mechanizmussal valósul meg a mozgó profil. Fontos megemlíteni, hogy amíg a felhasználó be van jelentkezve a kliensgépre addig a rendszer a mozgó profil helyi másolatával dolgozik, s csak kijelentkezéskor menti vissza a változásokat a szerverre. Ez ugyanakkor azt is jelenti, hogy amennyiben a felhasználó jelentős mennyiségű adatot tárol a profilban lévő könyvtárakban a be és kijelentkezés a teljes könyvtár oda-vissza másolása miatt nagyon sokáig eltarthat. Valójában ez az egész hálózat működését feleslegesen lassítja ha egy munkafolyamat alatt csupán néhány dokumentumot használ a kliens. Az ilyen könyvtárakat ezért célszerű átirányítani közvetlenül a szerverre. Amennyiben kizárólag a Dokumentumok mappa nagyméretű, akkor az egyszerűen a mappa tulajdonságai között állítható a célkönyvtár átirányítható a felhasználó saját szerveren lévő könyvtárába, amely jelen példánál az S: hálózati meghajtón keresztül érhető 8

12 el. Amennyiben a profil egyéb könyvtárainak átirányítása is szükséges akkor a következő a teendő: Meg kell változtatni az alapértelmezett profilt A helyi csoportházirendben ki kell venni az adott mappát a mozgó profilból Ábra: Az Asztal mappa átirányítása Ha még nem rendelkezünk alapértelmezett profillal akkor a C:\Documents and Settings útvonalon elérhető Default User könyvtár NETLOGON megosztásra másolásával készíthetjük azt el. A regedit programot indítsuk el, és a HKEY LOCAL MACHINE ágat kijelölve a Fájl menüből a Struktúra betöltése paranccsal töltsük be az alapértelmezett profil NTUSER.DAT fájlját, kulcsnévnek a Default szót adjuk meg. A HKEY_LOCAL_MACHINE\Default\Software\Microsoft\Windows\CurrentVersion\Explo rer\user Shell Folders ágban adható meg a profil könyvárainak elérési útvonala. A ábrán látható az Asztal mappa átirányítása, ehhez a Desktop kulcsot kell módosítani, melynél a UNC szintaxis változói is használhatóak, új értéke így %LOGONSERVER%\%USER NAME%\Asztal. Azért célszerűbb az előbbi formátum az S:\Asztal helyett, mert így a meghajtó kicsatolása, vagy betűjelének változása esetén is elérhető marad a könyvtár. Ha végeztünk a kulcsok módosításával ki kell jelölni a Default ágat, majd a Fájl menüből a Struktúra eltávolítása paranccsal menthetjük az alapértelmezett profilt. Ezután minden kliensgépen módosítani kell a helyi csoportházrendet. A 9

13 gpedit.msc parancs kiadásával egy szerkesztőkonzolt kapunk ( ábra), ahol a Felhasználó konfigurációja -> Felügyeleti sablonok -> Rendszer -> Felhasználói profilok -> Központi profil könyvtárainak kizárása útvonalon érjük el a szükséges menüpontot. Az opció engedélyezése után pontosvesszővel elválasztva adhatjuk meg a profilból kizárni kívánt könyvtárakat. Fontos, hogy ugyanazt a könyvtárnevet használjuk, mint a profil szerkesztésekor, azaz például az Asztal esetén a Desktop nevet kell használnunk Ábra: A helyi csoportházirend szerkesztése Ezzel az átirányítás beállítása elkészült, azonban még egy fontos teendő hátra van. Windows XP operációs rendszer esetén alapbeállításként engedélyezve vannak a Kapcsolat nélküli fájlok, így az átirányított könyvtárak tartalmáról - a beállított gyorsítótár méretéig a helyi gépen is tart másolatot a rendszer. Ez abban az esetben nagyon hasznos ha a szerverrel nincs állandó kapcsolat, de egyébként csak feleslegesen terheli a hálózatot. A szinkronizálás során ugyanis a gyorsítótárban lévő fájlokat összehasonlítja a rendszer a szerveren lévőkkel, s ez sok fájl esetén hosszú ideig tart. A funkciót bármely Intézőablakból kikapcsolhatjuk az Eszközök -> Mappa beállításai -> Kapcsolat nélküli fájlok fülön, természetesen csak rendszergazdaként. A kiszolgálókon tárolt adatok elérésének legegyszerűbb módja a hálózati meghajtók használata, mivel gyorsabban kezelhetőek, mintha a megosztásokat kellene böngészni és azon felhasználók számára is szemléletes, akik nem rendelkeznek hálózati tapasztalatokkal. 10

14 A hálózati meghajtók csatlakoztatására nagyon jól használhatóak a bejelentkezési parancsfájlok (Logon script), mivel minden bejelentkezéskor lefutnak és akkor is csatlakoztatják a meghajtót ha azt a felhasználó az előző munkamenetben lecsatolta, ezáltal az alkalmazások által használt hálózati meghajtók mindig elérhetőek. A Logon szkript egyszerű szövegfájl, a.bat fájlokhoz hasonlóan DOS kódolású, ezért szerkesztésére a Windows Jegyzettömböt használjuk, vagy a unix2dos paranccsal konvertáljuk át arra. A meghajtók csatlakoztatására szolgáló bejelentkezési parancsfájl a 3. sz. mellékletben látható Gyakorlati megvalósítás A nyári gyakorlatom során készített kiszolgáló egy irodában működik elsődleges tartományvezérlőként. A Pentium II és III processzoros kliens gépek Windows XP operációs rendszert futtatnak, 100 Megabites zárt Fast Ethernet hálózaton kapcsolódnak a szerverhez. A kiszolgáló hardvere szerénynek mondható: 2,4 GHz-es processzor, 512 MiB Dual Channel DDR memória, 2 db 120GB SATA HDD RAID-1 tömbben; de mint látni fogjuk teljesítménye így is bőségesen elegendő. Az alaplap kiválasztásánál elsődleges szempont volt, hogy rendelkezésre álljon stabil meghajtóprogram Linux operációs rendszerhez, ezért az Intel ICH5R déli híddal és Marvell 88E8001 gigabites Ethernet csatolóval rendelkező ASUS P4P800 típusú alaplap került a gépbe. Operációs rendszernek a Slackware Linux 10.0 verzióját választottam. Az elérhető legfrissebb kernel és Samba verziót (2.6.7 illetve 3.07) forráskódból telepítettem. A Samba esetén csupán a jobb teljesítmény elérése volt a cél, mivel az eredeti csomag i486 architektúrára volt optimalizálva de a kernel esetén speciális funkciókra is szükség volt. Az alaplap ICH5R déli hídja ugyanis rendelkezik RAID támogatással, de az valójában csak szoftveres RAID megvalósítás és a gyakorlat idején nem volt hozzá stabil Linuxos meghajtóprogram. A dolgozat írásának idejére sem készült még el a végleges kiadás [3]. Meg kell említeni, hogy a 2.4-es kernelcsaládhoz létezik egy másik driver is [4], de az a projekt is hasonló stádiumban volt akkor, és van még mindig. Ugyan léteznek olyan valódi hardveres SATA RAID kártyák, amelyet a kernel már akkor is támogatott 11

15 (pl. 3ware LP) [5], de az áruk meglehetősen magas. Mivel mindenképpen stabil és olcsó megoldásra volt szükség, ezért a Linux kernel által nyújtott szoftveres RAID volt az egyedüli lehetőség. A gyökérpartíció RAID tömbre telepítését kétféleképpen lehet elvégezni [6]. Az egyik lehetőség, hogy a rendszert egy külön merevlemezre telepítjük, ott létrehozzuk a tömböt, amire átmásoljuk a rendszert. A másik, hogy a tömböt alkotó egyik lemezre telepítjük a rendszert és ún. degraded tömböt hozunk létre, melynek azt a tagját melyen a rendszer van a failed-disk opcióval ideiglenesen kikapcsoljuk. Ez utóbbi módszer RAID-0 esetén természetesen nem használható. A 4-es számú mellékletben látható a LILO, az 5-ös számúban a RAID konfigurációs állománya. A LILO esetén a raid-extra-boot=mbr opcióval érhető el, hogy mindkét lemez MBR területébe bekerüljön a rendszertöltő, vagyis akkor is el tudjon indulni a rendszer, ha az egyik lemez kiesik [7]. Egyik idézett leírás sem említi azonban, hogy a lilo -r /mnt/newroot parancs kiadása előtt a forrásrendszer /dev könyvtárát a célpartícióba is be kell csatolni a mount --bind /dev / mnt/newroot/dev paranccsal, különben a LILO nem éri el a lemezeket. Mivel az adatbiztonság e szerver esetén kulcsfontosságú, ezért az adatpartíció tartalma és a log fájlok minden héten automatikusan DVD lemezre kerülnek a Cron periodikus ütemező segítségével. Mivel minden program adatállománya a szerveren tárolódik ezért a mentés megkezdése előtt néhány perccel minden felhasználó kap egy "WinPopup" üzenetet, hogy jelentkezzen ki a rendszerből. Így elkerülhető, hogy egy esetleges visszaállítás után a lezáratlanul hagyott adatállományok valamelyik felhasználói programban hibát vagy adatvesztést okozzanak. Az üzenetküldő és a mentést végző szkript a 6-os és a 7-es számú mellékletben látható. Már a beüzemelés napján beigazolódott, hogy a szerver teljesítménye elegendő az 5 kliensgép számára, sőt később probléma nélkül kiszolgálhat többet is ez egyébként elvárás is volt. A korszerű alaplapnak és merevlemeznek 7200 ford./perc, 8 MiB cache, SATA csatoló köszönhetően a pufferelt lineáris olvasási sebesség elérte az 57 MB/sec-ot. Mivel a RAID-1 olvasáskor a lemezeket párhuzamosan használja, ezért a sok apró fájlt mint az asztal elemei és a menü nagyon gyorsan tudja olvasni a rendszer. Emiatt a viszonylag idős kliensgépeken a rendszer hamarabb töltődik be a tartományba lépve, mint 12

16 helyileg. A technika fejlődésére ugyancsak jó példa az alaplapra integrált Marvell hálózati csatoló, mivel a processzor-terhelése gyakorlatilag elenyésző egy átlagos kártyához képest. A Serial ATA szabványú háttértár szintén jóval kevesebb processzort használ, mint az ugyanolyan felépítésű párhuzamos csatolójú eszköz. Ennek köszönhetően a kiszolgáló CPU terhelése még intenzív használat során sem ment 20% fölé, de legtöbbször 10% alatt maradt. Így később a jelenlegi hagyományos 100 megabites switch-et egy gigabites csatlakozással rendelkezőre cserélve sokkal gyorsabb kliensgépeket is ki tud majd szolgálni a szerver. 4. Samba PDC + Samba BDC + OpenLDAP + Windows kliens + Linux kliensből álló tesztrendszer 4.1. A rendszer ismertetése Ábra: A tesztrendszer felépítése A ábrán látható rendszer egy rugalmasan skálázható, központi címtárral kezelt többplatformos hálózat alapjainak ismertetésére készült. A címtár használata lehetővé teszi, hogy a felhasználók bármely Windows és UNIX kliensre bejelentkezzenek anélkül hogy az adott gépen helyi fiókkal rendelkeznének. A címtárral a Samba szerver és a UNIX kliensek is TLS protokollal titkosított kapcsolaton kommunikálnak, de a fájlforgalom nem kódolt, 13

17 ezért nyílt hálózaton történő alkalmazása esetén csak protokollszinten titkosított (pl. IPsec) kapcsolaton keresztül alkalmazható biztonsággal. A valóságban természetesen egy alhálózatra értelmetlen két tartományvezérlőt kötni, de a beállítások így is gyakorolhatóak. A tartományvezérlők operációs rendszere Debian GNU/Linux, Samba a és OpenLDAP verziókkal. A tesztrendszer alapötletét az [1] számú irodalom 5. fejezetében ismertetett tartomány adta, melyhez képest az alábbi lényeges pontokban tér el: Az LDAP kommunikáció titkosított Nem fut Winbind démon nss_ldap lekérdezések anonymous-ként A Windows és a UNIX jelszó szinkronizált A felhasználó és csoportazonosítók (UID, GID) feloldása bővebb ismertetést igényel, mivel meglehetősen összetett rendszert képez ( ábra). A feladat, amelyet minden Samba szerver esetén meg kell oldani a POSIX azonosítók és a Windows SID-ek kölcsönös megfeleltetése ( ábra). Ugyanis a kiszolgálón tárolt fájlok és könyvtárak jogosultságait magán a szerver fájlrendszerén tárolja a Samba, s nem külön adatbázisban, így szükséges egy POSIX azonosító amihez a Samba kötni tudja azokat Ábra: UID/GID feloldás, forrás: [8] 14

18 Egyszerű kiszolgálóknál a probléma nem merül fel, mivel minden Samba felhasználó és csoport meg kell feleljen egy helyi UNIX felhasználónak vagy csoportnak tehát helyi UID-vel vagy GID-vel rendelkeznek. Több tartományvezérlővel rendelkező rendszerek esetében azonban közös címtárban kell tárolni a fiókokat, s ezek megfeleltetésére két lehetőség kínálkozik. Használható a PADL Software Pty Ltd [10] által készített nss_ldap modul, vagy a Samba részeként elérhető Winbind Ábra: A POSIX és Samba azonosítók kölcsönös megfeleltetése, forrás: [9] Általános Windows hálózattervezési javaslat, hogy lehetőleg a hálózatot egy tartományba szervezzük, ez a legtöbb esetben valóban elegendő is. Több tartományból álló hálózat esetén csak a Winbind szerver használatával lehet megoldani, hogy minden SID garantáltan külön POSIX azonosítóknak feleljen meg. Az alábbi esetekben ugyancsak szükséges a Winbind használata: Tartományon kívüli Windows kliensek is vannak A UNIX klienseken nincs nss_ldap támogatás Windows szerver által vezérelt tartományba kell Samba klienst vagy tagszervert csatlakoztatni Egyéb esetekben azonban nincs rá szükség. A Winbind másik fontos funkciója, hogy egyértelmű SID<->UID/GID megfeleltetést biztosít, azaz garantáltan olyan azonosítót rendel a SID-hez amely még nem használt és ezt természetesen fenn is tartja. Ezt azonban a előbb felsorolt esetek kivételével az IDEALX SMBLDAP Tools csomag [11] smbldap-useradd szkriptje is biztosítja, lássuk hogyan. A sz. ábrán látható, 15

19 hogy amennyiben nem adjuk meg a UID-t akkor a get_next_id függvénnyel (8. sz. melléklet) a szkript a következő szabad azonosítót rendeli a felhasználóhoz, ha pedig megadjuk, de az már létezik, akkor hibaüzenettel leáll. Az SMBLDAP Tools programcsomag mindenképpen szükséges a Samba számára a címtár kezeléséhez, s láttuk, hogy egyértelmű UID-t rendel a felhasználókhoz. Az smbldap-groupadd szintén biztosítja ezt a csoportok esetében. Az előbbi szkriptek az előállított UID-t vagy GID-t eltárolják a címtárban, s az nss_ldap modul ez alapján mindig fel tudja oldani a neveket, ezáltal úgymond megspóroljuk a Winbind szerver használatát. A névfeloldás és a hitelesítés működéséhez az NSS és a PAM alrendszereket mind a kiszolgálókon mind a klienseken be kell állítani a címtár használatára, ez a 4.4 fejezetben kerül ismertetésre Ábra: Az smbldap-useradd szkript részlete 4.2. Saját hitelesítésszolgáltató felállítása az OpenLDAP címtárhoz A TLS titkosítás használatához egy olyan tanúsítványra van szükség, melyet az adott szerverhez állítottak ki. Amennyiben nem rendelkezünk hozzáféréssel egy ismert hitelesítésszolgáltatóhoz, úgy létre kell hoznunk egyet, vagy ún. saját aláírású tanúsítványt kell használnunk. A második módszer azonban nem ajánlott mivel a tanúsítvány melyet el kell juttatni a kliensekhez egyben tartalmazza a titkos kulcsot is. A hitelesítésszolgáltató felállításara az OpenSSL által nyújtott CA.pl szkript (/usr/lib/ssl/misc/ca.pl) használható. Fontos megemlíteni, hogy OpenLDAP csak titkosítatlan privát kulccsal működik, ezt a második lépés során kell majd figyelembe venni [12]. Hozzunk létre egy üres könyvtárat majd lépjünk bele. Hívjuk meg a szkriptet -newca opcióval. Üssünk Enter-t, adjunk meg egy jelszót a hitelesítésszolgáltatónak, majd 16

20 töltsük ki a szervezetre vonatkozó információkat, vagy írjunk egyszerűen egy pontot helyettük. Nagyon fontos, hogy a Common Name (eg, YOUR name) [] : kérdésre az OpenLDAP kiszolgáló teljes domain nevét adjuk meg, ez jelen esetben server1.peldadomain.com. Most következik a második lépes, amikor elkészítjük a tanúsítványkérelmet, itt azonban nem használható a szkript mivel titkosítatlan privát kulcsot kell kérnünk, ezt az alábbi paranccsal tehetjük meg: openssl req -newkey rsa:1024 -nodes -keyout newreq.pem -out newreq.pem Az eljárás ezután ugyanaz, mint az előző lépésben, de a végén meg kell adnunk egy jelszót, amellyel az új saját kulcs lesz titkosítva. Végül ismét hívjuk meg a CA.pl szkriptet, de ezúttal a -sign opcióval, hogy a hitelesítésszolgáltatónk aláírja az új kulcsot, ehhez az első lépésben bekért jelszót kell megadnunk. Az alábbi 3 fájlra lesz majd szükségünk: A newcert.pem a szerver tanúsítványa, a newreq.pem a tanúsítvány titkos kulcsa, a democa könyvtárban található cacert.pem pedig a hitelesítésszolgáltató tanúsítványa Az OpenLDAP szerver beállítása A szerver konfigurációs állománya a 9. sz. mellékletben látható. Ez a fájl az [1] számú irodalom es példájából (167.o) származik, mivel korábban nem volt tapasztalatom az OpenLDAP-al így a szerző javaslatára nem tértem el tőle. Az OpenLDAP által alapértelmezetten betöltött sémákon felül szükséges a Samba forráskód examples/ldap könyvtárba található Samba séma (samba.schema); mely Debian rendszer esetén a samba-docs csomag részeként is elérhető. Az alapértelmezett OpenLDAP szerver (slapd.conf) konfigurációs fájl alábbi pontjait kell változtatni: -access to * A hozzáférési jogosultságok szabályai. -security tls=1 A szerver csak TLS protokollal titkosított kapcsolatot fogadjon el, hagyományos módon ne lehessen csatlakozni. Az alkalmazott módszer az ún. START_TLS, amelynél a TCP kapcsolat a hagyományos 389-es LDAP portot használva épül fel, ezen keresztül kér a szerver TLS titkosítást, s a titkosított forgalom is ezen a porton halad. 17