Mac Os X Server: Open Directory

Kezdjünk akkor bele akkor most egy olyan témába, ami régóta dédelgetett álmom volt. Ez pedig Mac Os X alapokon szervert üzemeltetni. Sok kétség merül fel a Mac Os X enterprise kategóriájával kapcsolatban. Én már egy ideje nyüstölöm, hogy egy hosszabb írás sorozatba kezdhessek, és azt kell hogy mondjam nem tud semmi olyan spéci dolgot, amit egy Unix – Linux üzemeltető ne tudna megcsinálni. Mégis lesz valami bája, egyszerűsége és szépsége ennek a platofmnak, ami az Apple termékeit amúgy is jellemzi. Az első írás legyen a Mac Os X lelke, az Open Directory.

Miből áll egy Open Directory?

Az Apple nagyon sok technológiát és innovatív gondolatot vett át a SUN-tól. Ilyen a Directory Server filozófia is. Ez nem egy teljesen új dolog, csak a meglévő komponensek egyesítése és rendszerbe foglalása. Be kell látni a Linux/UNIX világnak, hogy nagyon jó technológiák állnak rendelkezésre, de mivel nincs valamiféle szabványos eljárás, ezek kapcsolataiból, struktúrájából annyi féle van, ahány üzemeltető létezik. Az Open Directory (vagy SUN esetében Directory) szerver meglévő alkalmazások/programok csoportba foglalása, és valamilyen standard létrehozása. Ez az amit a Microsoft már régen meglépett az Active Directory-val (rövidítve AD), és azóta is nagy siker követi ezt a technológiát. Nézzük is milyen elemekből épül fel az Open Directory (rövidítve OD).

– LDAP
– Kerberose
– Password Server

LDAP

Ez egy rövidítés. Lightweight Directory Access Protocol azaz „pehelykönnyű könyvtár hozzáférés protokoll”. Egyszerűen mondva egy olyan fa struktúrán alapuló adatbázis ahol tipikusan gyorsan kell keresnünk, és sok kis információt akarunk benne elraktározni. Íme egy kis ábra arról a filozófiáról amit az LDAP vall:

Jól látszik a fa struktúra. Fent van a gyökér elem (ahonnan a fa kinő ez a kezdő pont). Minden zöld elemnek kell hogy legyen Distinguished Name-je (rövidítve DN), azaz egyedi megkülönböztető neve, amivel hivatkozhatunk rá.

Ezek a DN-ek tartalmazhatnak minden féle rövidítési tagot. A fenti példában is jól látszik ahogy „dc=”, „cn=” értékekkel nevesítsük a levél elemeket. Ahhoz hogy egy levélelemet meg akarunk hivatkozni, akkor a teljes DN-jét meg kell adnunk. A fenti példában például: „uid=anne, cn=users, dc=example, dc=com” DN-el hivatkozzuk meg Anne Johnson bejegyzését. Lehetőségünk van relative distinguished name (rövidítve RDN) megadására is, amikor nem a gyökérelemhez viszonyítva adjuk meg a helyzét a másik elemnek.

Az LDAP tehát egy gyorsan kereshető címtár. Ahol strukturáltan tudunk információkat tárolni. Itt tárolódnak majd a számítógépeink minden kapcsolódó információval együtt, a felhasználóink csoportjaink. Az LDAP jól ismert a Linux/UNIX világban, és természetesen az Open Directory LDAP-al is lehetőség van bármely olyan a külső alkalmazást használni ami a normál LDAP standard kapcsolódást támogatja

Kerberos

A kerberosnak kettős feladata van. Első sorban egy központi megbízható hitelesítési csomópontot jelent mindenki számára, másrészről viszont jegykiszolgáló feladatot is lát el. A hitelesítéshez ugye minden féle kulcsokat cserélgetnek, és információkat titkosítónak a résztvevő tagok. Ez bonyolult hálózat esetén hihetetlen szövevényes utakat jelenthetnek, és mindig kérdéses lesz az, hogy az akivel kommunikálni akarunk, az mennyire megbízható. Így jött létre a kerberos technológia, ami egy központi megbízható hitelesítést tesz elérhetővé. Ez a Key Distribution Center (röviden KDC).

Másod sorban lehetőség van jegyrendszer szolgáltatásra is. Ekkor van egy KDC és egy szolgáltatás ami kerberose támogatással bír és természetesen van egy felhasználó, aki a szolgáltatást kívánja igénybe venni:

Először a felhasználó a KDC-hez fordul, és hitelesíti magát. Ez ez első két nyíl. Majd amikor ez megvan akkor külön kér engedélyt ahhoz a bizonyos servicehez, ami valahol távol fut. Amennyiben van hozzáférése a KDC kiállít egy jegyet neki. Ez a hármas és négyes nyíl. Az ötös hatos lépésben a kliensünk ezzel a jeggyel felkeresi a használni kívánt service-t, aki ezt a jegyet érvényesíti magánál, és engedélyezi a felhasználónknak a használatot.

Tehát a kerberos a biztonságos és centralizált hitelesítésért felelős az OD-ben.

Password Server

Ahogy a nevéből is következik ez a komponens a jelszavak tárolásáért felel. A jelszavak a rendszerünk legfontosabb elemei. Ezeket megfelelően kell tárolnunk, és biztosítanunk azt, hogy a felhasználók ne juthassanak senki más jelszavához. Lehetőség lenne a jelszavakat az LDAP struktúrában tárolni, de külön szeparált komponensként így nagyobb biztonságot lehet garantálni.

A password server egy 128 bites azonosítót rendel hozzá minden egyes jelszóhoz, a jelszót pedig típusa szerint vagy visszafejthető (plain text) vagy titkosított (encrypted) formában tárolja a saját adatbázisában. Természetesen a password server a jelszavakhoz minden féle információt le tud tárolni. Úgy mint honnan használták és mikor utoljára sikeresen vagy sikertelenül.

Íme a táblázat arról, hogy a Password Server milyen típusú authentikációkat, hogy kommunikál a hálózaton, illetve hogyan tárol el.

Tehát a Password Server komponens felel a biztonságos jelszó tárolásért és jelszó kiadásért.

Open Directory típusok

Tehát már tudjuk, hogy az OD nem más mint egy csoport komponensből álló egység, ami a jelszókezelést, hitelesítést és címtár szolgáltatást rejt magában. Az Mac Os X Server viszont csak mint Open Directory kezeli ezt a szolgáltatás halmazt.

Alapvetően minden előzetes beállítás nélkül a serverünk Standalone állapotban lesz. A jövőben is lehetőség van visszaállni erre a helyzetre. Ez gyakorlatilag az Open Directory hiányát fogja jelenteni, ilyenkor simán a UNIX-os file alapú minimális szolgáltatás áll rendelkezésünkre.

Open Directory master-ről akkor beszélünk, ha a kinevezett gép látja el a fent tárgyalt három funkciót. Az adatok olvashatóak és változtathatóak is ezen OD-n keresztül.

Open Directory Replica ahogy az a nevéből is következik egy másolat. Értelem szerűen ahhoz, hogy replikát használjunk kell, hogy már legyen egy Open Directory Master-ünk. Ilyenkor egy másolat jön létre egy másik szeparált rendszeren az egész OD-ről. Természetesen a master és a replica között folyamatosan fent áll a kapcsolat. Ha ez mégse történne meg (kiesés vagy hálózati hiba), akkor amint újra helyreáll a kapcsolat a replica leszinkronizálja magát.

Fontos hogy egy replikára csatlakozva lekérhetőek az információk, authentikálni is lehet róla, de módosítani, felvinni, törölni adatokat nem lehet, csak és kizárólag a Masterre. Ez az alkalmazás telephelyek esetén jó megoldás tud lenni, egy „read only Active Directory”-hoz hasonlóan tud funkcionálni. Amennyiben a master-en helyreállíthatatlan kár történne, mindegyik repilákát „elő lehet léptetni” OD masterré.

Open Directory Master inicializálása

!!!FONTOS!!! Az Open Directory service megköveteli, hogy az Open Directory-ban definált Search Base (az LDAP gyökér eleme, ami a server host nevéből származik) a DNS servere által elérhető legyen és a gépünk által használt IP-re mutasson. Ha ez nem lenne meg, elég komoly problémákba fogunk futni.

Amennyiben Standalone állapotban van a gépünk, akkor kattintsunk a CHANGE gombra, ahol a következő ablakokban kell a megfelelő adatokat kitölteni.

Először is meg kell adnunk egy Directory Administrator-t. Annak username-ét, UID-ját, és jelszavát. Alapból felajánlja az első hármat, érdemes is elfogadni. Jelszót pedig elég bonyolultra és erősre érdemes választani, ugyanis ez a felhasználó lesz a korlátlan ura az egész OD-nek.

A következő ablakon már csak a Kerberos REALM-et kell definiálni és az LDAP Search Base-jét. Ezeket is automatikusan felajánlja a varázsló a gépünk host nevéből származtatva. Különleges igények nélkül érdemes is elfogadni.

Ezek után már csak egy összegző képernyőt kapunk, és el is készült az Open Directory Master szervizünk.

Open Directory Replica iniciálása

Amennyiben létre akarunk hozni egy replikát, fontos hogy legyen egy működő már inicializált OD master-ünk. Az OD master és a leendő replika között fontos, hogy a következő portok nyitva legyenek:

Open Directory Master gépen:

311

389

636

Open Directory Replica gépen:

311

389

636

Amennyiben ezek a dolgok nem lesznek előkészítve a OD replika varázsló ablaka meg fog akadni és hibásan fog létrejönni a OD replica, ami természetesen teljes mértékben használhatatlan lesz.

Ahogy fent látszik az OD masternél az SSH portot is ki kellett nyitunk. Természetesen arról is gondoskodnunk kell, hogy az SSH fusson is az OD master gépünkön. Ehhez válasszuk ki a Server Admin Tool-ban a serverünket. Menjünk a Settings fülre, majd ott General tab alatt pipáljuk be az SSH-t. Ezzel el fog indulni maga az SSH, de még azt is ellenőriznünk kell, hogy root-ként is be lehessen lépni. Ez egy elég nagy biztonsági rést jelent, de arra a rövid időre amíg a replika elkészül szükséges. Ezt a Server Admin Tool-ban a master servert kiválasztva, a Settings fülön az Access menüben tudjuk megtenni.

Amennyiben ezen elő követelményekről gondoskodtunk indítsuk a replikának kijelölt gépen a varázslót és válasszuk a replika létrehozását.

Meg kell adnunk a OD master IP-jét vagy host nevét, és a master jelszót. Ez a master jelszó megegyezik a telepítésnél először megadott helyi felhasználó jelszavával. (gyakorlatilag a root jelszava). Továbbá a OD masteren létrehozott Directory Administrator user neve és jelszava szükségeltetik. Ezek után ha minden rendben van, akkor indul is a replikáció.

Ha ez a csík huzamosabb ideig nem akar mozdulni (5 percnél tovább), akkor biztosra vehetjük, hogy valamilyen port nincs kinyitva megfelelő képen.

Amennyiben viszont mindent megfelelően tettünk, akkor a következő képernyőt kell kapnunk:

Ha minden rendben van, akkor a Server Administrator Tool-ban az Open Directory menüpontban valami hasonlót kell látnunk:

Természetesen a replica „read-only” tulajdonsága miatt itt több fül is inaktív lesz, mivel ez csak egy replika.

Open Directory replica változtatása

Ahogy említettem nem áll meg az élet az OD replica esetén sem. Amennyiben egy replica fut az adott Mac Os X Server-en úgy lehetőség van visszaállni (lebutítani) egy sima Standalone változatra, vagy a meglévő adatokat felhasználva előléptetni OD master-ré. Ezen felül pedig lehetőségünk van még OD nélkül csak egy meglévő master-hez csatlakoztatni a gépünket.

Ilyenkor meg kell adnunk a master jelszót, illetve a Directory Administrator username-ét és jelszavát. A replika ilyenkor ugyan úgy mint a létrehozásakor SSH-n felkeresi a master-t, és szépen kiregisztrálja magát a központból.

Open Directory Struktúra

Akkor most essen pár szó a struktúráról. Sajnos fájó, de csak egy OD master lehet a struktúránkban. Egy OD masternek maximum 32 darab replikája lehet. Ezt azzal lehet fűszerezni, hogy a replikákból úgynevezett replica realay-ket hozhatunk létre amiből szintén 32 lehet, de ezek alá újabb 32 replikát tolhatunk be, így a dokumentáció szerinti maximális szám 1056 tud lenni. Nem hinném, hogy ennyire bárkinek is szüksége lehetne.

Ami igaz az igaz, ez számomra is egy fájó pont egy egyszerű Microsoft Active Directory-hoz hasonlítva. Ez az egy master tagból álló rendszer eléggé megköti a lehetőségeket, és korlátozza az adminisztrálási, vagy feladat/jogkör leosztási lehetőségeket. Remélem a jövőben ezen majd változtat az Apple, és felzárkózik tudásban a konkurencia mögé.

Természetesen nem kell megijedni, Windows-al szemben itt lehetőségünk van, több OD struktúrához is egyszerre kapcsolódni egy klienssel. Így végül is ha nem is adminisztrátori megoldással, de könnyedén tagjai tudunk lenni több domain-nak is.

Open Directory CLI – Command Line Interface

Akkor had jöjjön pár tipp, ahhoz hogy tudjuk debugolni, vagy egy egyszerű terminál segítségével vezérelni az Open Directory-nkat. Sajnos sok esetben szükséges, mert kis figyelmetlenséggel könnyű olyan állapotba kergetni az OD-t, hogy onnan a szép grafikus admin tooljaival az életbe ne lehessen kihozni.

Először is a legfontosabb, amit ha hamarabb tudok, nem kell kétszer is újra telepíteni az egész Mac Os X Server-t, hogy bármilyen összehugyozott állapotában, hogyan lehet törölni egy OD mastert, vagy replikát.

# slapconfig -destroyldapserver

Nézzünk még pár hasznosat:

# slapconfig -getstyle
Megmondja, milyen OD beállítás van használva.

# slapconfig -getmasterconfig
Kirajzolja az adott struktúrát, a kapcsolódó replikákat és azok állapotait. (Master-on kiadandó)

# slapconfig -getreplicaconfig
A replikán kiadva kiírja a master elérhetőségét és az utolsó szinkronizáció idejét.

# slapconfig -getldapconfig
LDAP alap beállításainak listázása.

# slapconfig -getmacosxodpolicy
OD Policyk lekérése.

# slapconfig -createldapmasterandadmin „new admin” „new fullname” „new uid” [

[]]
OD master készítése command line-ból.

# slapconfig -createreplica „master address” „admin user”
Replika készítése command line-ból.

# slapconfig -setstandalone
Standalone státuszra „butítás” command line-ból.

# slapconfig -backupdb archive-path
Biztonsági másolat készítése a teljes OD beállításról és állományokról.

# slapconfig -restoredb archive-path
Egy meglévő biztonsági másolat visszaállítása. Vigyázzunk ezzel a meglévő adatokat el is veszíthetjük.

Összegzés

Az Open Directory jó kezdetnek, és próbál felnőni társához az Active Directoryhoz. Mivel ezek kezdeti próbálkozások, ezért sok alapvetőnek tűnhet dolog itt még nem létezik, cserébe Linux/UNIX folozófiával bíró adminisztrátoroknak nagy megkönnyebbülést jelenthet ez az összeszedett és kapcsolódó struktúra.

Bír néhány gyermekbetegséggel az OD, sokszor tud olyan állapotba jönni, hogy semmi és senki nem tud rá mit mondani. Nálam főleg a repilkák esetében volt ez igaz. Maga szimpla OD masterként tökéletesen működött.

Ami még az előnye a könnyű beállítási „varázsló”, bár ha probléma van akkor idegesítő, hogy az a pár klikkelésre alkalmas ablak semmiben sem tud nekünk segíteni.

Az Open Directory Snow Leopard Server-es dokumentációja elérhető itt.