1 Hálózati Operációs Rendszerek X.500, Címtárak, NIS, NIS+ Előadó: Bilicki Vilmos

2 Tartalom 1. NIS, NIS+ 2. Címtár fogalma, szerepe 3. X.500

3 Források NIS,NIS+ ( n/nisplus/mastertoc.htm) ( n/nisplus/mastertoc.htm) X

4 NIS (Network Information Services) problémát okozott a közös felhasználói adatbázis karbantartása (kié a jó verzió, globális UID, GID) 1985 SUN -> Yellow Pages -> NIS RPC hívások UDP felett a rendszerhívásokat átirányítja a szerverre DBM fájlokat használ az információ tárolására (indexelt fájlok) kulcs alapján könnyen kereshető az információ probléma a DBM fájlok binárisak -> nehezen érthető megoldás ASCII fájlokból időnként átkonvertáljuk DBM-be az adatokat

5 NIS elemei NIS domain név Gépek csoportja Minden hoszt-on be kell állítani Master, Map (ypserv, yupdated, ypasswdd) egy lehet belőle Slave működhetnek szerverként azonban az információt a master-től kapják Terhelés elosztás Client (ybind) egy IP álhálózatban kell lennie a szerverrel a kliensek üzenetszórással keresik a szervert RPC segítségével kommunikál a szerverrel

6 A NIS előnyei, hátrányai Egyszerűen karbantartható, egyszerű szöveges fájlokat kell módosítgatnunk Sok felhasználó és számítógép könnyen menedzselhető Időnként nagy a sávszélesség igénye Csak egy kulcs alapján kereshető Nem biztonságos (véletlen domain név)! 1024 bájtos maximális rekordhossz

7 NIS+ Azonosítás, jogosultság kezelés RPC hitelesítés Névmodell (~10000 gépes hálózatra is alkalmas): fa struktúra (hierarchikus névtér) minden levél egy NIS+ objektum, ”.” elválasztó könyvtár bejegyzés csoport hivatkozás tábla privát org_dir – adminisztrációs táblák groups_dir – hozzáférés vezérlés táblák

8 NIS+ Több kulcs alapján lehet keresni DES azonosítás A rekordoknak nincs felső méretkorláta (a NIS esetén 1024 bájt) A kliens választhat az információforrások közül (NIS, NIS+, DNS, /etc/…) Növekményes frissítések

9 NIS+ előnyei hátrányai A NIS lényegesebb hátrányait kiküszöbölték Nem eléggé kiforrott Nincs adat titkosítás Nem LDAP kompatibilis Bonyolultabb mint a NIS

10 A Címtárak múltja Jó lenne egy a telefonkönyvhöz hasonló adatbázis mely nemzetközi lenne A telefonkönyvben lévő adatok egy része már a nyomtatáskor elavul A 80-as években népszerű volt a fax szolgáltatás (napjainkban is az) Hogyan keressük ki a partner cég telefonszámát? Megoldás: telefon -> szám -> fax Ma ? -> google -> spam

11 Próbálkozások A British Telecom fax adatbázist hozott létre 1992-ben megszüntette Ok: Hatalmas adminisztrációs munkát igényelt az adatbázis naprakész állapotban tartása

12 Projektek 2 nagy projekt: CCITT (ITU-T) White pages (telefonszám, vagy cím keresés) ISO, ECMA (European Computer Manufacturers Association) – az ISO OSI modell számára egy név szolgáltatás kifejlesztése (name service) 1986-ban egyesültek 1990 január - CCITT X.500 Blue Book Recommendations (The official CCITT version of the '88 Standard)

13 Címtárak jövője Cégeken átívelő elosztott adatbázisok Federated Identity & Liberty Allinance Minden fontos nem túl gyakran változó információ ezekben lesz elhelyezve Címtár nélkül nem lesz versenyképes egy cég sem Egyre több címtárképes alkalmazás Webes szolgáltatások és címtárak integrációja

14 Címtárak A vállalatokban az információ több formában van tárolva Több WAN kapcsolattal összekötött telephely Nagy adatmozgás Egy információt több helyen több formában is tárolnak Inkonzisztens állapot léphet fel (Nagy J. Lajos – Nagy János Lajos) A különböző formátumokhoz különböző elérési protokollok tartoznak

15 Címtár

16 A címtár szolgáltatásai Egy adatbázis Több adatbázis Központi adminisztráció Elosztott adminisztráció Azonosítás Jogosultság kezelése …

17 X.500 Globális Címtár Szolgáltatás ISO/ITU-T szabványok 1993-ból Nem mond semmit sem a belső működésről A kommunikációra és az információ ábrázolásra koncentrál Komplex, Nehézsúlyú

18 Nézetek Directory Information Modells: Directory User Information Modell (Directory Information Modell,88) Elérés Adattípusok Directory Operational and Administrative Information Model (Adminisztrátor nézet) Adminisztratív információk DSA Information Model (Az elosztott tárolást írja le) Directory Administrative Authority Model (A címtár adminisztrálását írja le)

19 Szerkezet Directory Information Base (DIB) A teljes tárolt információ Nem csak egy – egy hozzárendelés Bejegyzések (entry), hierarchikus szerkezetet képeznek, az adatbázis alap építőkövei (Directory Information Tree DIT) Object Class (objektum osztály) Minden bejegyzés legalább egy objektum osztály tagja Tulajdonságok (attribute) Tulajdonság típus Tulajdonság érték/ek A felhasználó definiálhat saját típus-érték párokat De egy részük szabványosítva van

20 Címtár Felhasználói Információs modellje

21 DIT A DIB faként ábrázolható (DIT) Minden elemnek lehet őse és gyermeke Levél bejegyzések, csomópontok -> csak ősei vannak A gyökér bejegyzésnek, elemnek csak gyermekei vannak Alatta tipikusan országokat képzeltek el …

22 DIT - DIB

23 Az egyedek elnevezése A DIT-en belül az egyedeket a nevükkel különböztetjük meg. Megkülönböztető név (Distinguised Name DN) Relatív megkülönböztető név (Relative Distinguished Name RDN) egyedi egy adott ágon Név érték párok Olyan tulajdonság mint a többi, csak meg van jelölve (Distinguised) Csak a gyökér Distinguised tulajdonsága lehet null

24 RDN, DN

25 Helyettesítő név (Alias) Egy objektumnak több mint egy neve lehet Egy objektumnak csak egy megkülönböztető neve lehet (ezzel együtt egy DIT bejegyzése) A helyettesítő névnek egyértelműnek igen, de nem kell egyedinek lennie. Az alias csak levél elem lehet A helyettesítő név mutathat helyettesítő névre (pl.: egy munkás vándorol a szervezeti egységek között) Helyettesító név feloldás - Alias Dereferencing Helyettesítő név helyettesítő névre is mutathat Keresés RDN alapján a helyettesítő nevet behelyettesítve újra a gyökértől

26 Példa

27 Kollektív tulajdonságok Speciális tulajdonságok Közösek több objektumra (DIT) is (pl.: telefonszám) Nem a bejegyzésben tárolódnak Speciális bejegyzés (subentry), csak az Adminisztrátor számára látható Tartalmazza azon alfa leírását melyre érvényes

28 Működési és Adminisztráció Információs modell A címtár működéséhez szükséges információkat is az adatbázisban tároljuk Címtár működési tulajdonságok (Directory Operational Attributes) Ezek normál felhasználó számára láthatatlanok Léteznek rejtett bejegyzések is (subentry) ezek is csak az adminisztrátor számára olvashatóak

29 Tulajdonság hierarchiák Egyes tulajdonságok hasonlóak Származtatás Supertype Subtype Pl.: telefon = ország + behívó + mellék

30 Directory Administrative Authority Model A címtár egyes részei más-más hatóság által lehetnek adminisztrálva Egyes helyeken az adminisztráció teljesen elkülönül, más helyeken átfedheti egymást Megoldás: Autonóm adminisztratív körzetek (Autonome Administrative Areas) Autonóm Adminisztrációs Pont (Autonome Administrative Point) Teljes önállóság Belső adminisztratív körzetek (Inner Administrative Areas) Belső Adminisztrációs Pont (Inner Administrative Point) Részleges önállóság Metszhetik egymást

31 AAA

32 IAA

33 Az adminisztrációs övezetek felosztása Három adminisztratív szerepkör: Alséma adminisztráció (Subshema Administration) Hozzáférés Adminisztráció (Access Control Administration) Kollektív Tulajdonságok Adminisztrálása (Collective Attribute Administration) Az AAA mindhárom szerepkörből nézhető, ezek egymástól függetlenül is kioszthatóak Független a DSA-tól !!! administrative role tulajdonság

34 Al Bejegyzések (Subentries) Adminisztratív pontok tartalmazhatják Olyan kollektív bejegyzések melyek egy alfára vonatkoznak AAP, IAP, közös tulajdonságok, … Al-fa specifikáló tulajdonság (Subtree Specification Attribute) Alap (base) Vágás (chop) Specifikáció Szűrő (specification filter)

35 Példa

36 Elosztott Információs Modell (DSA Information Modell) Milyen információt kell egy DSA kliensnek hordoznia ahhoz, hogy együtt tudjon működni más DSA klienssel A következőkre van szüksége: Az általa mesterként tárolt felhasználói attribútumok teljes leírására (master – slave koncepció) Hogyan integrálódnak az általa tárolt bejegyzések a golbális DIT-be Amennyiben tárol más bejegyzéseket, ezek szárazási helyét és frissítési módja (fogyasztó) Amennyiben az ő bejegyzéseit másolják akkor a változások értesítési módját (forrás)

37 DSA működési tulajdonságok A DIT-ben eddig megismert tulajdonságok nem mondanak semmit sem a DSA-ról DSA osztott tulajdonság Független az aktuális tároló DSA-tól Függ a replikáció módjától (pl.: DSA master) DSA specifikus tulajdonság Függ az aktuális tárolótól Függ a replikáció módjától (forrás ?)

38 DSA specifikus bejegyzés DSA information tree

39 Címtár séma OID Alséma (subschema) AAA hatókör ASN.1 (Abstract Syntax Notation) (integer, …) Szűkítések Összehasonlítás Present Equality Substrings Ordering ( ) Approximate

40 Példa integerSyntax ATTRIBUTE- SYNTAX INTEGER MATCHES FOR EQUALITY ORDERING ::= {attributeSyntax 9}

41 Az elosztott címtár működése Címtár Felhasználói Ügynök - Directory User Agent (DUA) Címtár Rendszer Ügynök - Directory System Agent (DSA) DSA Absztrakt szolgáltatás - DSA Abstract service DSA specifikus bejegyzés - DSA Specific Entry (DSE) Mivel versenyt szerettek volna nem specifikálták a DSA-t

42 DUA Szabványos kapcsolat a címtárral Címtár Hozzáférési Protokoll (Directory Access Protocol) – DAP -> LDAP Minden művelet és annak eredménye specifikálva van – Directory Absctract Service -> DAP Egy DUA – egy felhasználó

43 DSA Címtár Rendszer Protokoll – Directory System Protocoll – DSP Működési mód Láncolás Hivatkozások (referrals) Access Point – AP DAP + állapot Home DSA

44 A DIT elosztása Minden alfa egy DSA-hoz tartozik Egy DSA tetszőleges számú alfát tartalmazhat Kotensztus előtag - Context prefix Tudás referencia – Knowledge reference Alsó Tudás referencia – Subordinate Knowledge reference Első szintű DSA – first level DSA Elnevezési Kontesztus – Naming Context Felsőrendű hivatkozás – Superior reference

45 Directory Access Protocol Kötés – bind Lekérdező műveletek Olvasás Összehasonlítás Listázás Keresés Megszakítás Módosító műveletek AddEntry RemoveEntry ModifyDN ModifyEntry

46 Replikáció Multimaster Master/Slave Tükör másolat - shadow copy Másodlagos tükrözés Tükör szolgáltató Tükör fogyasztó Firssítés 1s -> x nap Tükör megegyezések Shadow Agreements Tartományközi Tartományon belüli

47 X.500 nem (volt!) megoldás A szerver szoftver komplex és túltervezett Nehéz együttműködni egyszerű címtárakkal Kevés X.500 megvalósítás Nagy, komplex, erőforrás-igényes egy PC-hez Erősen kötődik az OSI modellhez Megoldás: LDAP

48 LDAP – könnyűsúlyú X.500 Működő kód (jobb mint a rideg szabványok) Több éve fejlesztik (RFC 1487 (1993): LDAPv1; RFC 1777 (1995): LDAPv2; RFC 2251 (1997): LDAPv3) Csak könyvtár-hozzáférési protokoll nem teljes címtár Csak azt specifikálja hogyan társalogjon a kliens és a szerver Nem specifikálja a címtár működését

49 LDAP általános hozzáférési protokoll

50 LDAP tulajdonságok X.500 mintát használja cn = Common Name mail = o = Organization ou = Organization Unit c = Country objectclass = type of entry Példa: objectclass = employee, dn = Dmitry Dimov, o = BEA Systems, ou = E-Commerce, c = US URL-szerű szintakszis ldap://ldap.bea.com /c = US, ou = E-Commerce