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
Samba alapú tartományvezérlők
Tartalomjegyzék 1. Bevezetés............................................................................................................................1 1.1. A szakdolgozat célja, témaválasztás...........................................................................1 1.2. A Samba bemutatása...................................................................................................1 2. A Samba, mint tartományvezérlő.......................................................................................3 2.1. A tartományba fűzés előnyei......................................................................................3 2.2. Alkalmazási lehetőségek............................................................................................3 3. Samba PDC + Windows kliensekből álló egyszerű tartomány..........................................5 3.1. Szerveroldali beállítások.............................................................................................5 3.2. Kliensoldali beállítások..............................................................................................7 3.3. Gyakorlati megvalósítás...........................................................................................11 4. Samba PDC + Samba BDC + OpenLDAP + Windows kliens + Linux kliensből álló tesztrendszer.........................................................................................................................13 4.1. A rendszer ismertetése..............................................................................................13 4.2. Saját hitelesítésszolgáltató felállítása az OpenLDAP címtárhoz..............................16 4.3. Az OpenLDAP szerver beállítása.............................................................................17 4.4. NSS és PAM beállítások...........................................................................................19 4.5. A Samba PDC beállításai.........................................................................................20 4.6. Az SMBLDAP Tools beállításai..............................................................................22 4.7. A Samba BDC beállításai.........................................................................................24 4.8. UNIX kliensek..........................................................................................................24 5. Összegzés, továbbfejlesztési lehetőségek.........................................................................26
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.
1.2. 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 http://hu.samba.org/samba/docs/using_samba/ch01.html
1
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
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 (2.1.1. á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.
2.1.1. Á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
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 – implementációt futtassa is –
bármely Kerberos
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
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
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 – egy egyszerű megosztás csupán, azonban –
NETLOGON szolgáltatás is
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 2.3.1-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
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 3.0.11-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 (3.2.1. ábra).
3.2.1. Á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 (3.2.2. ábra) segítségével
7
pedig bármely kliensgépről is kezelhetjük a fiókokat, de csak rendszergazdaként.
3.2.2. Á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
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.
3.2.3. Á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 3.2.3. á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
gpedit.msc parancs kiadásával egy szerkesztőkonzolt kapunk (3.2.4. á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.
3.2.4. Á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
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ó.
3.3. 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
(pl. 3ware 8006-2LP) [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
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
4.1.1. Ábra: A tesztrendszer felépítése
A 4.1.1. á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
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 3.0.14a és OpenLDAP 2.2.23 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 (4.1.2. á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 (4.1.3. á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.
4.1.2. Ábra: UID/GID feloldás, forrás: [8]
14
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.
4.1.3. Á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 4.1.4. sz. ábrán látható, 15
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.
4.1.4. Á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 – hitelesítésszolgáltató
felállításara
egyben tartalmazza a titkos kulcsot is. A 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
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.
4.3. 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 5.4.2-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
-TLSCertificateFile /etc/ldap/szervercert.pem Az OpenLDAP szerver tanúsítványa. -TLSCertificateKeyFile /etc/ldap/szerverkulcs.pem A tanúsítványhoz tartozó titkos kulcs. -TLSCACertificateFile /etc/ldap/cacert.pem -checkpoint 1024 5
A hitelesítésszolgáltató tanúsítványa.
Az alapértelmezett BDB adatbázis-háttér opciója, meghatározza,
hogy mennyi adat változása után valamint mennyi idő elteltével írja ki a változásokat az adatbázis-háttér a lemezre. Konkrétan: 1024 KiB és 5 perc. -cachesize 10000
Meghatározza, hogy hány darab bejegyzést tároljon a az adatbázis a
memóriában. -suffix "dc=peldadomain,dc=com"
Melyik
DN-re
(Distinguished
Name
-
az
adatbázis kulcsa) érkező kéréseket továbbítsa ehhez az adatbázishoz. -rootdn "cn=Admin,dc=peldadomain,dc=com"
Az a DN amellyel adminisztrátorként
lehet csatlakozni. -rootpw {SSHA}*** Az adminisztrátor jelszava, vagy annak hash értéke. Hash generálásához a slappasswd parancs használható. -directory "/var/lib/ldap"
Az adatbázis fájlokat tartalmazó könyvtár.
-index sambaSID eq Azon attribútumok amelyeket indexeljen az adatbázis. Az adatbázis könyvtárának (/var/lib/ldap) jogosultságát állítsuk 700-ra, tulajdonosa és csoportja egyaránt ldap legyen. Ha korábbról volt benne tartalom, amelyre tovább nincs szükségünk, akkor töröljük azt le, ha ez nem tehető meg, akkor hozzunk létre új adatbázist. Másoljuk be a 10. sz. mellékletben látható BDB adatbázis konfigurációs fájlt az adatbázis könyvtárába DB_CONFIG néven; a fájl az [1] sz. irodalom 5.4.1-es példájából (129.o) származik. A címtárat kezelő parancsoknak a /etc/ldap/ldap.conf
fájlban adjuk meg a
hitelesítésszolgáltató tanúsítványának elérési útját a TLS_CACERT /etc/ldap/cacert.pem opció megadásával. Ezt minden UNIX gépen, tehát a klienseken is meg kell adni, mivel kizárólag titkosított kommunikációt engedélyeztünk. A kliensoldali LDAP eszközök Debian rendszeren az ldap-utils csomag részei, ezeket természetesen a szervereken is telepíteni kell.
18
4.4. NSS és PAM beállítások A PADL Software Pty Ltd által készített nyílt forráskódú nss_ldap és pam_ldap modulok a legtöbb UNIX rendszeren használhatóak. Az nss_ldap modul segítségével az RFC 2307-nek [13] megfelelő névfeloldás érhető el LDAP címtárból, a pam_ldap pedig a hitelesítésre és a jelszóváltoztatásra nyújt megoldást. Miután telepítettük a modulokat a strings /lib/modulnév | grep conf paranccsal állapíthatjuk meg, hogy milyen útvonalon kell elhelyezni a konfigurációs fájlokat. Debian rendszeren a szokásos /etc/ldap/ldap.conf útvonallal ellentétben a /etc/libnss-ldap.conf illetve a /etc/pam_ldap.conf az elérési út. A két modul teljesen azonos konfigurációt igényel, ezért is van az, hogy a szokásos közös fájlt használják a legtöbb rendszeren. Jelen esetben pedig az egyik nyugodtan lehet a másikra mutató link. A konfigurációs fájl a 11. sz. mellékletben látható, az [1] sz. irodalom 5.4.5-ös példájához (169.o) képest az alábbi pontokon kell eltérni: -host server1.peldadomain.com A TLS titkosítás miatt szükséges, hogy IP cím helyett a teljes domain névvel hivatkozzunk a szerverre, ugyanis a tanúsítvány ahhoz van kiállítva. -rootbinddn cn=Admin,dc=peldadomain,dc=com
A root felhasználó által indított
lekérdezések DN-je. A root azonosításhoz szükséges jelszót szöveges formátumban a /etc/ldap.secret fájlban kell tárolni, szigorúan 600-as jogosultsággal. A binddn és a bindpw megadása nem szükséges. Azért kell így megoldani a lekérdezést, hogy a címtárban tárolt felhasználók számára is legyen a UNIX rendszereken névfeloldás. Ha a hivatkozott irodalom szerint járnánk el, ahol minden lekérdezés adminisztrátori szinten történik (binddn, bindpw megadásával), akkor a címtár biztonsága érdekében 600-as jogosultságú kellene legyen a konfigurációs fájl, különben bárki elolvashatná az adminisztrátori jelszót. Így azonban a felhasználóknak nem lenne joga a nevek lekérdezéséhez (ahhoz 644-es jogosultság kell); belátható, hogy ez számtalan problémához vezetne. (Már bejelentkezés után szembetűnő, mivel I have no name!@host szerepel felhasználónév@host helyett.) A megoldást az opciók tanulmányozása jelentette, ugyanis a binddn és a bindpw megadása nélkül, alapértelmezetten anonymous lekérdezéseket hajt végre a modul, a root felhasználó számára pedig az /etc/ldap.secret fájlban tárolható a 19
jelszó a rootbinddn megadásával. Ezáltal pedig már nyugodtan adhatunk 644-es jogosultságot a konfigurációs fájlnak, s így működik a névfeloldás. -ssl start_tls A használt titkosítási mód. -tls_cacertfile /etc/ldap/cacert.pem A hitelesítésszolgáltató tanúsítványa. A pam_ldap modul beállítása az azonos konfiguráció miatt az említett szimbolikus link létrehozásával tehető meg, magát a PAM rendszert azonban be kell állítani. A PAM konfigurációs állományai a 12. sz. mellékletben láthatóak. Az auth és password modulok esetében a try_first_pass opcióval adható át az előzőleg bekért jelszó, ezzel elkerülhető, hogy kétszer kelljen azt begépelni. Fontos, hogy az [1] sz. irodalom 131. oldalán lévő beállítással ellentétben a password modulnál ne a use_first_pass opciót használjuk, hanem a try_first_pass-t, különben a helyileg tárolt UNIX jelszavakat nem tudjuk megváltoztatni. Ez első ránézésre nem tűnik komoly problémának, mivel a felhasználói fiókokat a címtárban
tároljuk,
azonban
biztonsági
kockázatot
vet
fel.
Ugyanis
a
helyi
jelszóadatbázisban is kell legyen root jelszó ahhoz, hogy ha valami probléma folytán a címtár nem elérhető akkor is be tudjunk jelentkezni rootként. A fenti módosítás nélkül kizárólag a jelszófájl szerkesztésével változtathatóak meg a helyi jelszavak, ami nem elfogadható megoldás. Az NSS konfigurációs állománya (/etc/nsswitch.conf ) a 13. sz. mellékletben látható. A névfeloldás sorrendje: helyi fájlok majd az LDAP címtár. Az NSS és a PAM rendszereket természetesen szintén minden UNIX gépen be kell állítani.
4.5. A Samba PDC beállításai Ahhoz, hogy több tartományvezérlőt használhassunk a megosztásokat szinkronizálni kell. Ennek legegyszerűbb módja az NFS-el központilag megosztott könyvtárak használata, mely azonban adatbiztonsági és elérhetőségi szempontból problémákat vet fel. Ugyanis ha a központi NFS szerver nem elérhető, akkor nincs tartalék tároló amelyhez a fájlszerverek fordulhatnak,
amennyiben
adatvesztés
lép
fel
csak
a
biztonsági
másolatokra
hagyatkozhatunk, nagyszámú kliens esetén pedig a háttértár bizonyulhat lassúnak. Ezért éles környezetben ez a módszert kizárólag jól megtervezett diszk alrendszerrel és
20
rendszeres adatmentésekkel alkalmazható s még így is csak akkor ha a hálózati kapcsolat sebessége biztosan elegendő a kliensek számára. Nagyméretű hálózatok esetén mindenképpen javasolt több független tárolórendszer alkalmazása, melyeket természetesen szinkronizálni kell, például az rsync használatával. A tesztrendszer esetében maga a PDC szerver egyben NFS szerver is, melynek működéséhez a /etc/exports fájlban a /home és a /adat könyvtár tartalma elérhetővé van téve a BDC számára. Ehhez a /home esetében a /home server2.peldadomain.com (rw,root_squash,sync)
szintaxist
kell
használni.
server2.peldadomain.com:/home /home nfs rw 0 0
A
BDC-n
pedig
a
sor kerül ennek megfelelően
a /etc/fstab fájlba. Az elsődleges tartományvezérlő szerver konfigurációs állománya a 14. sz. mellékletben látható. A 3.1 fejezetbeli PDC-hez képest az alábbiak eltérőek: -passdb backend = ldapsam:ldap://server1.peldadomain.com
Az LDAP adatbázis-
háttér kiszolgálójának megadása, a titkosítás miatt fontos, hogy a teljes domain névvel hivatkozzunk a szerverre. -add user script = /opt/IDEALX/sbin/smbldap-useradd -m "%u"
A
fiókokat
kezelő SMBLDAP Tools szkriptek, beállításuk ismertetése a 4.6 fejezetben. -ldap admin dn = cn=Admin,dc=peldadomain,dc=com
A címtár adminisztrátorának
megkülönböztetett neve. -ldap group suffix = ou=Groups
A csoportok utótagja a címtárban.
-ldap machine suffix = ou=People
A gépnevek utótagja a címtárban.
-ldap user suffix = ou=People A felhasználónevek utótagja a címtárban. -ldap suffix = dc=peldadomain,dc=com Az előbbiek utótagja a címtárban. -ldap ssl = start tls Az LDAP kommunikációhoz START_TLS-t használjon. -unix password sync = yes A Windows jelszót szinkronizálja össze a UNIX jelszóval. Egy egyszerű másolással a probléma nem oldható meg mert a Windows és a UNIX eltérő algoritmus használ a jelszó tárolására (MD4, illetve MD5). A passwd program paraméterben megadott szkriptet hívja meg, amellyel a passwd chat paraméterben megadott formátum szerint kommunikál. -passwd program = /etc/samba/jelszovalt %u A UNIX jelszó változtatásának szkriptje 21
(15. sz. melléklet), az ötlet a [14] sz. irodalomban megjelölt, Samba listára írt levélből származik, de a TLS kapcsolat miatt a -ZZ paraméter is szükséges. -passwd chat = *New*password* %n\n *new*password* %n\n *Success*
A
jelszóváltáskor használt kommunikációs forma. A %n magát a jelszót helyettesíti, a /n az új sor karakter, a * pedig a köztes karaktersorozatot helyettesíti. A Samba számára az LDAP adminisztrátori jelszót az smbpasswd -w *** paranccsal kell megadni. Ezután indítsuk el a Sambát, majd a net getlocalsid paranccsal kérjük le a helyi SID-et. Ne ijedjünk meg hogy hibaüzenetet kapunk, mivel az LDAP szerver még nem fut, ezért az LDAP lekérdezés természetesen nem sikerül. Néhány másodperc múlva ismételjük meg a parancsot, s ekkor már meg kell kapnunk a SID-et. Ezután állítsuk le a Sambát, majd a konfigurálást az SMBLDAP Tools csomag beállításával folytassuk.
4.6. Az SMBLDAP Tools beállításai Az SMBLDAP Tools a Samba forráskód examples/LDAP könyvtárból, vagy Debian rendszeren a samba-doc csomagból érhető el, de érdemes letölteni a legfrissebb verziót a [11] sz. irodalomban megjelölt oldalról. Hozzuk létre a /opt/IDEALX/sbin és a /etc/smbldap-tools könyvtárakat a tulajdonos és a csoport root legyen, a jogosultság 755. Másoljuk az smbldap.conf és az smbldap_bind.conf könyvtárba,
640
illetve
600-as
jogosultsággal.
fájlokat a /etc/sambldap-tools A
többi
szkriptet
másoljuk
a /opt/IDEALX/sbin könyvtárba, az smbldap_tools.pm jogosultsága 640 a többié 755 legyen. Az smbldap_tools.pm fájlban keressük meg a 16-os számú mellékletben található megjegyzést és módosítsuk az alatta található három változót aszerint, hogy mik a konfigurációs fájlok elérési útjai. A csomag beállításához használhatjuk a configure.pm szkriptet, de a 17-es és a 18-as számú melléklet alapján közvetlenül is módosíthatjuk a konfigurációs állományokat. Az alapértelmezett smbldap.conf fájlhoz képest az alábbiak eltérőek: -SID=... A helyi SID, melyet az említett net getlocalsid paranccsal kérhetünk le. -slaveLDAP="server1.peldadomain.com" 22
A tartalék LDAP szerver címe, amennyiben
ilyen nincs – mint jelen esetben is – akkor adjuk meg a fő LDAP szerver címét. Ezt követi a port majd a fő LDAP szerver megadása. -ldapTLS="1" TLS protokoll használata. -verify="require" A TLS kapcsolat létrejöttéhez érvényes tanúsítványt kell nyújtson az LDAP szerver. Az ezután következő TLS és LDAP paramétereket az előző fejezetek alapján kell kitölteni. -sambaUnixIdPooldn="cn=NextFreeUnixId,${suffix}" A következő szabad UID és GID tárhelye. Az smbldap.populate szkript használata után később meg kell majd változtatni az értéket a mellékletben ismertetett módon. -hash_encrypt="MD5" A UNIX jelszó tárolására használt algoritmus. -defaultUserGid="513" A tartományi felhasználók alapértelmezett csoportazonosítója. -defaultComputerGid="515" A
tartományi
számítógépek
alapértelmezett
csoportazonosítója. -defaultMaxPasswordAge="0" A jelszavak érvényességi ideje napban megadva. 0 értékkel korlátlan ideig érvényesek a jelszavak. Az ezt követő Samba paramétereket a PDC szerver beállításai alapján kell kitölteni. Az smbldap_bind.conf (18. sz. melléklet) a címtár adminisztrátorának DN-jét és jelszavát tartalmazza, a jogosultsága emiatt szigorúan 600. Ha készen vagyunk, akkor címtárat fel kell tölteni a Windows tartomány csoportjaival az smbldap-populate -a root -k 0 -m 0 parancs segítségével. Fontos, hogy ezután a 17. sz. mellékletben látható megjegyzés szerint módosítani kell az smbldap.conf fájlt! A címtárszerver (slapd) újraindítása után az smbldap-usermod -u 0 -d /root -s /bin/bash root paranccsal biztosítani kell, hogy a címtárban tárolt root felhasználó UID-je is 0 legyen, majd indíthatjuk a Samba szervert. A felhasználókat az smbldap-useradd
-m
hozhatjuk
smbldap-passwd
létre,
majd
jelszavukat
az
-a
felhasználónév paranccsal felhasználónév
segítségével adhatjuk meg. Fontos tudni, hogy az ezzel a parancskombinációval megadott jelszót a Windows operációs rendszer lejártnak tekinti, azaz a felhasználónak az első Windows gépről történő bejelentkezése során meg kell azt változtatni. Természetesen mivel a jelszavak szinkronizáltak ezért a megadott új jelszó lesz érvényes UNIX 23
rendszereken is. Ha a fiókokat a User Manager programmal hozzuk létre akkor ott beállítható, hogy a felhasználónak ne kelljen a jelszavát megváltoztatnia az első bejelentkezéskor. A csoportok létrehozására az smbldap-groupadd parancs, vagy a User Manager program használható.
4.7. A Samba BDC beállításai A tartalék tartományvezérlő szerver konfigurációs állománya a 19. sz. mellékletben látható. A 4.5 fejezetbeli PDC-hez képest az alábbiak eltérőek: -domain master = No
Ezzel tudatjuk a szerverrel, hogy nem PDC, hanem BDC.
-wins server = 192.168.1.10
A PDC szerver (amely WINS szerverként funkcionál) IP
címe. Fontos, hogy egy tartományban csak egy WINS szerver lehet. A Samba számára az LDAP adminisztrátori jelszót az smbpasswd -w *** paranccsal kell megadni. Miután az NFS segítségével a 4.5 fejezetben leírt módon csatoltuk a könyvtárakat indíthatjuk a szervert.
4.8. UNIX kliensek A 3.2 fejezetben ismertetett Windows kliensoldali beállításokhoz képest jelen rendszer Windows beállításaiban nincs változás, a UNIX kliensoldal azonban új elem. Ezen kliensek kényelmes használatának lehetőségét a címtár és a szinkronizált jelszavak teremtik meg, mivel így az egész rendszer központilag adminisztrálható, s a felhasználóknak mindenhol ugyanaz a jelszavuk. A címtár használatához minden UNIX kliensen be kell állítani az NSS és a PAM rendszereket, ez a 4.4 fejezetben ismertetésre került. A kiszolgálókon tárolt adatok elérésére alapvetően parancssori eszközök állnak rendelkezésre, melyekhez szerencsére számos grafikus felület készült [15]. Terminálról az smbtree parancs segítségével listázhatjuk ki a kiszolgálók megosztásait, hasonlóan a Windowsos Hálózati helyek-hez. Az smbclient FTP-szerű elérést biztosít a megosztásokhoz, melyeket az smbmount segítségével csatolhatunk is. Ezt a felhasználók 24
csak akkor tehetik meg ha az smbmnt setuid root, és akkor is csak a saját könyváraikat adhatják meg csatolási pontként. A grafikus eszközök közül az XFCE 4 ablakkezelő xffm fájlkezelő programját említem meg, mivel használata rendkívül egyszerű, gyakorlatilag semmilyen beállítást nem igényel. A fájlkezelő részét képező, de önállóan is futtatható xfsamba4 (4.8.1. ábra) automatikusan feltérképezi a kiszolgálókat, a szerver kiválasztása után bekéri a felhasználónevet és a jelszót, s ezután ugyanúgy használhatjuk a megosztásokat, mint a helyi könyvtárakat. Könnyű kezelhetősége révén a UNIX rendszereket kevésbé ismerő felhasználók számára is megfelelő választás lehet.
4.8.1. Ábra: Az xffm fájlkezelő xfsamba4 modulja
25
5. Összegzés, továbbfejlesztési lehetőségek A 3. fejezetben bemutatott rendszerhez képest az elkészített tesztkörnyezet az alábbi lényeges többletfunkciókkal rendelkezik: •
OpenLDAP címtárban központilag tárolt fiókok
•
UNIX és Windows kliensek integrálása (szinkronizált jelszavak)
•
Tartalék tartományvezérlő Ezen funkciók és a TLS protokollal titkosított LDAP kommunikáció miatt az
elkészített rendszer egy központilag adminisztrálható, biztonságos, többplatformos nagyméretű hálózat alapjául szolgálhat. Véleményem szerint sikerült bemutatnom, hogy a felhasznált nyílt forráskódú rendszerek együttes alkalmazásával komoly rendszereket lehet megvalósítani. A gyakorlati megvalósítás során a 4.5 fejezetben ismertetett módszerek szerint javasolt a háttértárrendszer kialakítása. Nagyméretű hálózatok esetén ezen felül a tartalék tartományvezérlők és az LDAP szerverek számának bővítése is szükséges lehet. Ezen szempontok figyelembevételével rugalmasan skálázható, magas rendelkezésre állású környezetek kialakítása lehetséges. A rendszer összetettsége miatt számos lehetőség kínálkozik a továbbfejlesztésre: •
Több tartomány létrehozása - azonosítók kezelése a Winbind szerver alkalmazásával
•
A hálózati forgalom titkosítása IPsec-el az adatfájlok biztonsága érdekében
•
Active Directory szerver megvalósítása a készülő Samba 4 segítségével
26
Irodalomjegyzék [1] Samba-3 by Example: http://hu.samba.org/samba/docs/Samba-Guide.pdf (Mivel az [1] sz. irodalom on-line változata rendszeresen frissül, ezért a CD-mellékleten szerepel az aktuális változat, amelyre a szövegben megadott oldalszámok érvényesek) [2] Srvtools: http://support.microsoft.com/default.aspx?scid=kb;en-us;173673 [3] dmraid: http://people.redhat.com/~heinzm/sw/dmraid/ [4] Intel Software RAID Driver: http://iswraid.sourceforge.net/ [5] 3ware® 8000 Series: http://www.3ware.com/products/serial_ata8000.asp [6] The Software-RAID HOWTO: http://www.tldp.org/HOWTO/Software-RAID-HOWTO.html [7] Building a Software RAID System in Slackware: http://slacksite.com/slackware/raid.html [8] http://hu.samba.org/samba/docs/man/Samba-Guide/images/chap9-SambaDC.png [9] http://hu.samba.org/samba/docs/man/Samba-Guide/images/UNIX-Samba-andLDAP.png [10] PADL Software Pty Ltd: http://www.padl.com/ [11] IDEALX Contributions to the Samba projekt: http://www.idealx.org/prj/samba/index.en.html [12] OpenLDAP SSL/TLS How-To: http://www.openldap.org/pub/ksoper/OpenLDAP_TLS_howto.html [13] RFC 2307: http://www.faqs.org/rfcs/rfc2307.html [14] [Samba] Unix-password-sync in LDAP? : http://lists.samba.org/archive/samba/2005-April/103120.html [15] Samba GUI page: http://hu.samba.org/samba/GUI/ 16: The Official Samba-3 HOWTO and Reference Guide: http://hu.samba.org/samba/docs/man/Samba-HOWTO-Collection/ 17: Using Samba, 2nd Edition: http://hu.samba.org/samba/docs/using_samba/toc.html 18: Babócsy László - Urbanovits György - Lepenye Tamás: Windows 2003 hálózatok NeTeN Bt. Budapest 2003 27
Mellékletek jegyzéke 1. sz. melléklet :
Az önálló PDC-ként működő Samba szerver konfigurációs állománya
2. sz. melléklet :
A Windows tartományi és helyi csoportjait UNIX csoportokhoz
rendelő szkript 3. sz. melléklet :
A meghajtók csatlakoztatására szolgáló bejelentkezési parancsfájl
4. sz. melléklet :
A LILO konfigurációs állománya (/etc/lilo.conf)
5. sz. melléklet :
A RAID konfigurációs állománya (/etc/raidtab)
6. sz. melléklet :
Az adatmentés előtt WinPopup üzenetet küldő szkript
7. sz. melléklet :
Az adatmentést végző szkript
8. sz. melléklet :
Az SMBLDAP Tools get_next_id függvénye
(/opt/IDEALX/sbin/smbldap_tools.pm) 9. sz. melléklet :
Az OpenLDAP konfigurációs állománya (/etc/ldap/slapd.conf)
10. sz. melléklet :
A BDB adatbázis konfigurációs állománya
11. sz. melléklet :
Az nss_ldap és a pam_ldap modulok konfigurációs állománya
12. sz. melléklet :
A PAM konfigurációs állományai
13. sz. melléklet :
Az NSS konfigurációs állománya
14. sz. melléklet :
A tesztrendszerbeli Samba PDC konfigurációs állománya
15. sz. melléklet :
A UNIX jelszót változtató szkript
16. sz. melléklet :
Az smbldap_tools.pm szükséges módosításai
17. sz. melléklet :
Az SMBLDAP Tools konfigurációs állománya (smbldap.conf)
18. sz. melléklet :
Az SMBLDAP Tools smbldap_bind.conf állománya
19. sz. melléklet :
A tesztrendszerbeli Samba BDC konfigurációs állománya
CD-melléklet: - Az 1-19. sz. mellékletek állományai, a melléklet számával egyező nevű könyvtárban - Az [1] sz. irodalomban megjelölt PDF fájl - A [2] sz. irodalomban megjelölt Srvtools.exe program
28
