Autor práce: Karel Benák

ˇ ´ VYSOKE ´ UCEN ˇ Í TECHNICKE ´ V PRAZE CESK E

Fakulta stavebn´ı Katedra systémového inˇzen´ yrstv´ı

Diplomov´ a pr´ ace Pouˇzit´ı adresáˇrov´ ych sluˇzeb v informaˇcn´ıch systémech

Autor práce: Vedouc´ı práce: ˇ Skoln´ ı rok:

Karel Ben´ ak doc. RNDr. Jiˇ r´ı Demel, CSc. 2003/2004

kvˇeten 2004

Prohl´ aˇ sen´ı Prohlaˇsuji, ˇze jsem tuto práci vypracoval samostatnˇe, pouze za odborného veden´ı vedouc´ıho diplomové práce doc. RNDr. Jiˇr´ıho Demela, CSc. Dále prohlaˇsuj´ı, ˇze veˇskeré podklady, ze kter´ ych jsem ˇcerpal, jsou uvedeny v seznamu literatury. V Praze dne 7. ˇcervna 2004

Karel Benák

Podˇ ekov´ an´ı Touto cestou bych rád podˇekoval vedouc´ımu diplomové práce, panu doc. RNDr. Jiˇr´ımu Demelovi, CSc., za konzultace a rady, jak psát diplomovou práci pomoc´ı sázec´ıho systému LATEX. Dále bych chtˇel podˇekovat sv´ ym koleg˚ um z Klubu Sinkuleho koleje za moˇznost vyzkouˇsen´ı a realizace nˇekter´ ych m´ ych nápad˚ u a návrh˚ u v ostrém provozu. Velké podˇekován´ı ˇ patˇr´ı Ing. Martinu Cerven´ emu nejen za zap˚ ujˇcen´ı cenné pokladnice informac´ı, [UDLDAPDS], ale pˇredevˇs´ım za jeho pˇripom´ınky a rady k realizaci nového informaˇcn´ıho systému. Karel Benák

ABSTRAKT V diplomové práci se zab´ yvám moˇznost´ı vyuˇzit´ı adresáˇrov´ ych sluˇzeb v informaˇcn´ıch systémech a jejich moˇzného nasazen´ı jako d˚ uleˇzité souˇc´ asti informaˇcn´ıho systému. Práce seznamuje s protokolem LDAP, jeho pouˇzit´ım a návrhem základn´ıch datov´ ych typ˚ u, adresáˇrov´ ych struktur a základn´ıch metod zabezpeˇcen´ı proti zneuˇzit´ı. Na reálném pˇr´ıkladu je pˇredvedena realizace adresáˇrové sluˇzby jako d˚ uleˇzité sluˇzby poˇc´ıtaˇcové s´ıtˇe, která dynamicky poskytuje data sluˇzbám, napˇr. DNS, DHCP a dalˇs´ım. Kl´ıˇcová slova: Adresáˇrové sluˇzby, LDAP, objektové tˇr´ıdy, atributy

ABSTRACT My diploma thesis is engaged in possibilities of usage of directory services in information systems and of their possible use as important part of information system. Thesis acquaints with LDAP protocol, with its use and elementary data types design, directory structures and basic security methods against misuse. Real example demonstrates practical realization of directory service as important service of computer network, which dynamically provides data to other services (e.g. DNS, DHCP, etc.) Key words: Directory Services, LDAP, ObjectClass, Attributes

Karel Ben´ ak

OBSAH

Obsah ´ 1 Uvod

4

2 Adres´ aˇ rov´ e sluˇ zby 2.1 Adresáˇre a adresáˇrové sluˇzby . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Pouˇzit´ı adresáˇrov´ ych sluˇzeb . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 Data a jejich správa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

5 5 7 9

3 LDAP 3.1 Protokol LDAP . . . 3.2 Informaˇcn´ı model . . 3.3 Jmenn´ y model . . . 3.4 Funkˇcn´ı model . . . 3.5 Bezpeˇcnostn´ı model 3.6 LDIF . . . . . . . . . 3.7 Topologie . . . . . .

. . . . . . .

13 13 15 22 30 35 39 42

4 Software pro adres´ aˇ rov´ e sluˇ zby 4.1 Adresáˇrové servery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Prohl´ıˇzeˇce a editory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 V´ yvojové prostˇredky . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

44 44 45 47

5 Anal´ yza a ˇ reˇ sen´ı ˇ c´ asti IS Klubu Sinkuleho koleje 5.1 SQL databáze . . . . . . . . . . . . . . . . . . . . . 5.2 Topologie . . . . . . . . . . . . . . . . . . . . . . . 5.3 Jmenné prostory . . . . . . . . . . . . . . . . . . . 5.4 Adresáˇrová sluˇzba . . . . . . . . . . . . . . . . . . 5.5 Schémata . . . . . . . . . . . . . . . . . . . . . . . 5.6 Spolupráce se software . . . . . . . . . . . . . . . . 5.7 Závˇer . . . . . . . . . . . . . . . . . . . . . . . . .

49 49 49 53 55 55 68 71

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

. . . . . . .

6 Z´ avˇ er

72

Pouˇ zit´ e zdroje Literatura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

73 73 75

-1-

Karel Ben´ ak

SEZNAM TABULEK

Seznam tabulek 3.1 3.2 3.3 3.4

Pˇr´ıklad hierarchie OID . Syntaxe vybran´ ych typ˚ u Vybraná pravidla shody Vyhledávac´ı filtry LDAP

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

16 18 18 32

5.1

Hierarchie OID pro KSk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

55

-2-

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

. . . .

´ ˚ SEZNAM OBRAZK U

Karel Ben´ ak

Seznam obr´ azk˚ u 2.1 2.2 2.3 2.4 2.5 2.6 2.7 2.8

Souˇcásti adresáˇrov´ ych sluˇzeb . . . . . . . . . . . Autentizace v SAPu pomoci adresáˇrov´ ych sluˇzeb Centralizace ovˇeˇren´ı dat . . . . . . . . . . . . . . Duplicita databáz´ı . . . . . . . . . . . . . . . . . Centralizace databáz´ı . . . . . . . . . . . . . . . . Centralizace adresáˇrov´ ych dat na jednom serveru Distribuce adresáˇrov´ ych dat mezi v´ıce server˚ u . . Replikované adresáˇrové sluˇzby . . . . . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

. . . . . . . .

7 8 9 10 10 11 12 12

3.1 3.2 3.3 3.4 3.5 3.6 3.7 3.8 3.9 3.10 3.11 3.12 3.13 3.14 3.15 3.16 3.17 3.18 3.19 3.20 3.21 3.22 3.23 3.24 3.25 3.26 3.27

Jeden nalezen´ y záznam . . . . . . . . . . . V´ıce nalezen´ ych záznam˚ u . . . . . . . . . . Typická komunikace protokolu LDAP . . . ˇ ast typického adresáˇre . . . . . . . . . . . C´ Organizace dat . . . . . . . . . . . . . . . . Adresáˇrov´ y záznam . . . . . . . . . . . . . . Popis typu atributu . . . . . . . . . . . . . Vyuˇzit´ı atributu . . . . . . . . . . . . . . . Vztahy mezi supertypem a subtypy . . . . . Pˇr´ıklad nového atributu skanskaCard . . . . Odvozen´ y atribut skanskaCardCar . . . . . Dˇediˇcnost objektov´ ych tˇr´ıd . . . . . . . . . Definice objektové tˇr´ıdy . . . . . . . . . . . Objektová tˇr´ıda typu STRUCTURAL . . . Objektová tˇr´ıda typu AUXILIARY . . . . . ˇ ast typického adresáˇrového stromu . . . . C´ ˇ ast typického souborového systému UNIX C´ ˇ ast typického LDAP adresáˇre . . . . . . . C´ Záznamy se shodn´ ym RDN . . . . . . . . . Podporované jmenné prostory . . . . . . . . Nepodporované jmenné prostory . . . . . . Jmenné prostory podle normy X500 . . . . Pˇr´ıklady sufix˚ u v LDAP . . . . . . . . . . . Jmenné prostory podle kontinent˚ u . . . . . Jmenné prostory podle oddˇelen´ı . . . . . . . Jmenné prostory podle souˇc´ ast´ı . . . . . . . Aliasy v adresáˇrovém stromu . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

14 14 15 16 17 17 19 19 20 20 20 21 21 22 22 23 23 24 26 27 27 27 28 28 28 29 29

-3-

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . . . . . . . . . . . . .

´ ˚ SEZNAM OBRAZK U

Karel Ben´ ak

3.28 3.29 3.30 3.31 3.32 3.33 3.34 3.35 3.36 3.37 3.38 3.39 3.40 3.41 3.42 3.43

Aliasy mezi adresáˇrov´ ymi servery . . . . . . . . Vyhledán´ı v konkrétn´ı vˇetvi . . . . . . . . . . . Prohledáván´ı adresáˇrového stromu . . . . . . . Vyhledáván´ı v konkrétn´ı vˇetvi do prvn´ı u ´rovnˇe Kombinace vyhledávac´ıch filtr˚ u . . . . . . . . . V´ ypis konkrétn´ıch atribut˚ u . . . . . . . . . . . Operace compare . . . . . . . . . . . . . . . . . Jednoduchá autentizace . . . . . . . . . . . . . PKI autentizace . . . . . . . . . . . . . . . . . . Systém PKI . . . . . . . . . . . . . . . . . . . . SASL mechanismus . . . . . . . . . . . . . . . . Bezpeˇcné spojen´ı pˇres ned˚ uvˇeryhodné prostˇred´ı Typick´ y LDIF soubor . . . . . . . . . . . . . . Záznam ve formátu DSMLv2 . . . . . . . . . . . Topologie Skansky podle poboˇcek . . . . . . . . Topologie Skansky podle m´ısta pracoviˇstˇe . . .

. . . . . . . . . . . . . . . .

29 30 31 31 32 33 33 36 37 37 38 39 40 41 42 43

4.1

GQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

46

5.1 5.2 5.3

ER diagram databáze . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Topologie s´ıtˇe KSk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . KSk - návrh DIT . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

50 52 54

-4-

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

. . . . . . . . . . . . . . . .

´ KAPITOLA 1. UVOD

Karel Ben´ ak

Kapitola 1

´ Uvod Snahou této práce je pˇribl´ıˇzit moˇznosti adresáˇrov´ ych sluˇzeb, pˇredevˇs´ım standardizovaného protokolu LDAP, a jejich pouˇzit´ı v informaˇcn´ıch systémech, vytipovat vhodné oblasti pouˇzit´ı adresáˇrov´ ych sluˇzeb v informaˇcn´ıch systémech a realizovat ukázkové ˇreˇsen´ı vybran´ ych sluˇzeb. Adresáˇre a adresáˇrové sluˇzby prov´ azej´ı náˇs ˇzivot, aniˇz bychom si uvˇedomili jejich existenci a mˇeli tuˇsen´ı o jejich v´ yznamu. Jejich pouˇzit´ı je natolik jednoduché a relativnˇe pˇrirozené, ˇze jejich skuteˇcn´ y v´ yznam pro náˇs ˇzivot nen´ı dostateˇcnˇe ocenˇen. Adresáˇrem je klasick´ y telefonn´ı seznam, v adresáˇri je organizovan´ y seznam kontakt˚ u, vizitek a celá ˇrada dalˇs´ıch uˇziteˇcn´ ych a praktick´ ych informac´ı. Bohuˇzel, jejich pouˇzit´ı je bˇehem na dlouhou trat’ a návrh´ aˇri informaˇcn´ıch systém˚ u mus´ı provést velmi d˚ ukladnou anal´ yzu, která je pro zákazn´ıka nákladn´ a. Dále je nutné brát v u ´vahu cenu licenc´ı software, které se mohou velmi v´ yraznˇe liˇsit pro r˚ uzn´ y poˇcet záznam˚ u, uˇzivatel˚ u, nebo pro r˚ uzné technické prostˇredky. Pokud se jeˇstˇe pˇripoˇc´ıt´ a zákaznick´ a podpora, moˇzné problémy s migrac´ı stávaj´ıc´ıch dat, pˇr´ıpadné v´ ypadky pˇri zav´ adˇen´ı systému, náklady na správu dat, nároky kladené na správce informaˇcn´ıho systému a pˇreˇskolen´ı uˇzivatel˚ u na nov´ y systém, vyˇsplhá se cena nového informaˇcn´ıho systému na pomˇernˇe vysokou ˇc´ astku. Proˇc se tedy zab´ yvat adresáˇrov´ ymi sluˇzbami, prostˇredky umoˇzn ˇuj´ıc´ımi jejich provoz a spolupráci s dalˇs´ımi aplikacemi? D˚ uvod je pomˇernˇe jednoduch´ y. Pokud si zákazn´ık sv´ ych informac´ı skuteˇcnˇe cen´ı, dokáˇze v adresáˇrov´ ych sluˇzb´ ach zorganizovat a poskytovat obrovské mnoˇzstv´ı dat podle konkrétn´ıch poˇzadavk˚ u i s ohledem na dalˇs´ı v´ yvoj nárok˚ u a poˇzadavk˚ u. Adresáˇrové sluˇzby jsou velmi siln´ ym nástrojem pro aplikace, které vyˇzaduj´ı rychl´ y, stabiln´ı a bezpeˇcn´ y pˇr´ıstupu k dat˚ um. Pro ukázky v textu práce jsou pouˇzity návrhy ˇc´ ast´ı informaˇcn´ıho systému spoleˇcnosti Skanska CZ. Na této spoleˇcnosti lze názornˇe vysvˇetlit a popsat návrh jmenn´ ych prostor˚ ua topologie pro rozsáhlejˇs´ı podnik. Bohuˇzel, popis nebude zcela odpov´ıdat skuteˇcnosti pˇredevˇs´ım proto, ˇze se jedná o velmi rozsáhlou spoleˇcnost a jej´ı anal´ yza by zabrala pˇr´ıliˇs mnoho ˇcasu. Pˇresto je Skanska CZ ideáln´ım pˇr´ıkladem vˇetˇs´ıho podniku, kter´ y by mohl pouˇz´ıvat adresáˇrové sluˇzby. Závˇereˇcná kapitola je vˇenována anal´ yze ˇreˇsen´ı ˇc´ asti informaˇcn´ıho systému Klubu Sinkuleho koleje, realizovaného v tomto roce.

-5-

Karel Ben´ ak

2.1 Adres´ aˇre a adres´ aˇrov´ e sluˇ zby

Kapitola 2

Adres´ aˇ rov´ e sluˇ zby 2.1

Adres´ aˇ re a adres´ aˇ rov´ e sluˇ zby

Adresáˇr slouˇz´ı k organizován´ı a sdruˇzov´ an´ı dat do skupin, aby se v nich mohl uˇzivatel snáze orientovat. V podstatˇe jsou to jakési kontejnery pro uklád´ an´ı dat, specializované databáze, ve kter´ ych lze uchovat a pˇredevˇs´ım vyhledávat velké mnoˇzstv´ı informac´ı r˚ uzného charakteru. Na rozd´ıl od relaˇcn´ıch databáz´ı jsou urˇceny pˇredevˇs´ım pro vyhledáv´ an´ı, nikoliv pro klasické transakce, ˇcasté ukládán´ı a zmˇeny dat anebo pro velmi komplikované dotazy. V normáln´ım ˇzivotˇe se lze vˇetˇsinou setkat s off-line adres´ aˇri, které jsou nejˇcastˇeji k dispozici v tiˇstˇené verzi (telefonn´ı seznam apod.). Pˇri práci s poˇc´ıtaˇci se pouˇz´ıvaj´ı on-line adresáˇre, které maj´ı oproti zm´ınˇen´ ym off-line adresáˇr´ım následuj´ıc´ı v´ yhody: On-line adres´ aˇ re jsou dynamick´ e – v pˇr´ıpadˇe potˇreby lze velmi snadno pˇrid´ avat nové záznamy, mazat zastaralé záznamy a aktualizovat stávaj´ıc´ı záznamy. U off-line adresáˇr˚ u je jakákoliv aktualizace obt´ıˇzn´ a a vˇetˇsinou se prov´ ad´ı nov´ ym v´ ytiskem. Pˇr´ıkladem v´ yhody dynamick´ ych adresáˇr˚ u m˚ uˇze b´ yt situace, kdy zamˇestnanec z centr´ aly v Praze jede na sluˇzebn´ı cestu do poboˇcky v Brnˇe. Bˇehem jeho cesty mu lze pˇridˇelit pˇr´ısluˇsn´ a pˇr´ıstupová práva pro objekt v Brnˇenské poboˇcce, aniˇz by muselo doj´ıt k nové registraci zamˇestnance. V pˇr´ıpadˇe off-line adresáˇre, kter´ ym m˚ uˇze b´ yt napˇr. telefonn´ı seznam, katalog zboˇz´ı ad., je nutné provést jejich nov´ y v´ ytisk. On-line adres´ aˇ re jsou flexibiln´ı – v adresáˇri lze ukládat data r˚ uzn´ ych typ˚ u, napˇr. ASCII text, text v kódován´ı UTF-8, digitáln´ı certifikáty, obrázky, audio, odkazy, r˚ uzné URL ad. V záznamech lze pak jednoduˇse a velmi rychle vyhledávat podle pˇr´ısluˇsn´ ych pravidel. Mimo to lze data pomˇernˇe pruˇznˇe rozˇsiˇrovat a doplˇ novat o nové vlastnosti, nutné pro nové sluˇzby spolupracuj´ıc´ı s on-line adresáˇrem. On-line adres´ aˇ re lze velmi dobˇ re zabezpeˇ cit – pˇrenosov´ y protokol je standardizovan´ y a má i svou zabezpeˇcenou verzi. Uˇzivatel˚ um lze pomoc´ı ACL (access control list) pˇresnˇe vymezit, ke kter´ ym záznam˚ um smˇej´ı a ke kter´ ym nesmˇej´ı pˇristupovat. On-line adres´ aˇ re lze snadno personalizovat – d´ıky adresáˇrov´ ym sluˇzb´ am lze velmi snadno uchovat informace o nastaven´ı aplikace nebo prostˇred´ı pro konkrétn´ıho uˇzivatele systému. Rovnˇeˇz lze v adresáˇri snadno uchovat informace o zálib´ ach a uˇzivatelem nejˇcastˇeji hledan´ ych informac´ıch a dokumentech a c´ılenˇe mu pak pˇredkl´ adat konkrétn´ı reklamu a nab´ıdky. Tento princip je ale postupnˇe nahrazov´ an principem kolaborace. -6-

Karel Ben´ ak

2.1 Adres´ aˇre a adres´ aˇrov´ e sluˇ zby

Adresáˇre lze také rozdˇelit podle zp˚ usobu, jak´ ym spolupracuj´ı s ostatn´ımi aplikacemi a systémy: Aplikaˇ cn´ı adres´ aˇ re – adresáˇre, které si udrˇzuj´ı aplikace pro uklád´ an´ı sv´ ych vlastn´ıch záznam˚ u. Pˇr´ıkladem m˚ uˇze b´ yt napˇr. IBM/Lotus Notes, Microsoft Exchange a napˇr. aliasy obsaˇzené v /etc/aliases. Ty slouˇz´ı pro poˇstovn´ı aliasy MTA server˚ u. Adres´ aˇ re s´ıt’ov´ ych operaˇ cn´ıch syst´ em˚ u (NOS) – adresáˇre, které vyuˇz´ıvaj´ı r˚ uzné operaˇcn´ı systémy, jak´ ymi jsou napˇr. Windows, Linux, Solaris, AIX apod. Tyto adresáˇre b´ yvaj´ı postaveny na nˇekterém z uznávan´ ych standard˚ u a mohou kombinovat nˇekolik protokol˚ u, jako je tomu napˇr. u Microsoft Active Directory. Ten v sobˇe obsahuje protokoly LDAP, Kerberos a CIFS. Dalˇs´ım pˇrikladem je napˇr. Novell eDirectory (dˇr´ıve znám´ y jako Netware Directory Services), kter´ y implementuje protokol X.500, nebo Network Information Service (NIS ) od Sun Microsystems uˇz´ıvan´ y pro distribuci uˇzivatelsk´ ych u ´ˇct˚ u mezi UNIXov´ ymi poˇc´ıtaˇci. ´ celov´ Uˇ e adres´ aˇ re – velmi specializovan´ y typ adresáˇr˚ u urˇcen´ ych pro jedin´ y konkrétn´ı u ´ˇcel. Nelze je pˇr´ıliˇs rozˇsiˇrovat o dalˇs´ı typy informac´ı, pouze pˇri zmˇenˇe standardu. Typick´ ym pˇr´ıkladem u ´ˇcelového adresáˇre je Domain Name System (DNS ). Univerz´ aln´ı standardizovan´ e adres´ aˇ re – standardizované adresáˇrové sluˇzby zaloˇzené na protokolu X.500 postaveného nad s´ıt’ov´ ym modelem OSI a protokol LDAP, kter´ y je zjednoduˇsenou variantou protokolu X.500 a je podstatnou ˇc´ ast´ı této práce. Velmi ˇcasto se spojuj´ı term´ıny adres´ aˇr a adres´ aˇrov´ a sluˇzba a jsou povaˇzov´ any za synonymum. Adresáˇrové sluˇzby jsou souhrnem software, hardware, proces˚ u, politik a administrativn´ıch procedur. Skládaj´ı se z následuj´ıc´ıch komponent: • Informace uloˇzené v adresáˇri • Serverov´ y software, kter´ y tyto informace poskytuje • Klientsk´ y software, kter´ y je schopen uˇzivateli tyto informace zprostˇredkovat • Hardware, na kterém klienti a servery pracuj´ı • Podporuj´ıc´ı software jako jsou operaˇcn´ı systémy a ovladaˇce zaˇr´ızen´ı • S´ıt’ová infrastruktura, která je schopna spojit klienty se servery • Bezpeˇcnostn´ı politika, která specifikuje oprávnˇen´ı pˇristup˚ u k záznam˚ um, aktualizaci dat, apod. • Procedury, které adresáˇrové sluˇzby pouˇz´ıvaj´ı pro udrˇzbu a monitorov´ an´ı • Software pouˇz´ıvan´ y pro u ´drˇzbu a monitorov´ an´ı adresáˇrov´ ych sluˇzeb Obrázek 2.1 zobrazuje typické souˇc´ asti adresáˇrov´ ych sluˇzeb, ovˇsem nezobrazuje kompletn´ı seznam, pouze nejzákladnˇejˇs´ı souˇcásti.

-7-

Karel Ben´ ak

2.2 Pouˇ zit´ı adres´ aˇrov´ ych sluˇ zeb

Obr. 2.1: Souˇc´ asti adresáˇrov´ ych sluˇzeb

2.2

Pouˇ zit´ı adres´ aˇ rov´ ych sluˇ zeb

Adresáˇrové sluˇzby maj´ı velmi ˇsiroké pole vyuˇzit´ı. Aˇckoliv nedosahuj´ı takov´ ych moˇznost´ı jako relaˇcn´ı databáze, pˇresto se jich ve velké m´ıˇre uˇz´ıv´ a pro uklád´ an´ı informac´ı o uˇzivatel´ıch poˇc´ıtaˇcov´ ych s´ıt´ı r˚ uzn´ ych organizac´ı a spoleˇcnost´ı. Adresáˇrové servery slouˇz´ı pˇredevˇs´ım jako zdroje pro ovˇeˇren´ı pˇr´ıstupov´ ych práv k dan´ ym prostˇredk˚ um, napˇr. poˇc´ıtaˇcovému u ´ˇctu a poˇstovn´ımu u ´ˇctu elektronické poˇsty. Dále m˚ uˇze slouˇzit jako adresáˇr a telefonn´ı seznam spoleˇcnosti, ve kterém m˚ uˇze b´ yt uvedeno velké mnoˇzstv´ı informac´ı poˇc´ınaje jménem a pˇr´ıjmen´ım, pˇres telefonn´ı linku, mobiln´ı telefon, u ´ˇcet pro instant messengera aˇz po fotografii. V adresáˇrov´ ych sluˇzbách jsou organizov´ any i veˇrejné kl´ıˇce a digitáln´ı certifikáty uˇzivatel˚ u podle norem PKI. Model certifikát˚ u pouˇz´ıvan´ ych pro ovˇeˇren´ı uˇzivatelské identity je pˇrevzat´ y z protokolu X.500, konkrétnˇe X.509v3 ([X.509] a [Dostalek], kapitola 9.). Moˇznosti adresáˇrov´ ych sluˇzeb jsou opravdu veliké a záleˇz´ı pouze na návrh´ aˇr´ıch informaˇcn´ıho systému, jak dokáˇzou vyuˇz´ıt moˇznosti této technologie. Pˇri správném návrhu je tˇreba vz´ıt vu ´vahu nejen aktuáln´ı, ale i budouc´ı potˇreby spoleˇcnosti. Ve vˇetˇsinˇe pˇr´ıpad˚ u se s adresáˇrov´ ym serverem zaˇc´ıná jako s levn´ ym a efektivn´ım zdrojem pro autentizaci uˇzivatel˚ u v poˇc´ıtaˇcové s´ıti spoleˇcnosti. Po nˇejaké dobˇe pˇrijde návrh na propojen´ı tohoto seznamu uˇzivatel˚ u s vlastn´ım seznamem zamˇestnanc˚ u a moˇznost´ı jejich správy. Pracovn´ıci zase ocen´ı moˇznost propojen´ı svého poˇstovn´ıho klienta s adresáˇrov´ ym serverem, ve kterém budou m´ıt uloˇzeny kontakty nejen na své spolupracovn´ıky, ale zároveˇ n i na své zákazn´ıky a dodavatele. V tomto okamˇziku se jiˇz jedná o provázán´ı s CRM a SRM systémy. Nˇekteré velké podnikové aplikace jsou schopny pouˇz´ıvat adresáˇrové sluˇzby pro ovˇeˇren´ı uˇzivatele k pˇr´ıstupu ke konkrétn´ım záznam˚ um, napˇr. SAP (obr. 2.2, strana 8.). Produkt mySAP, postaven´ y nad J2EE, je schopen pomoc´ı jednoduchého pˇremapov´ an´ı sv´ ych obvykl´ ych ABAP atribut˚ u z´ıskávat z adresáˇrové sluˇzby daleko v´ıce informac´ı, neˇz je pouhá autentizace uˇzivatele1 . Velk´ y konkurent SAPu, produkt spoleˇcnosti PeopleSoft2 , je schopen d´ıky svému zamˇeˇren´ı pˇredevˇs´ım na CRM a HR systémy pˇr´ımé spolupráce s adresáˇrov´ ymi sluˇzbami a vyuˇz´ıvá jich jako moˇzného zdroje dat. 1 2

http://www.sap.com http://www.peoplesoft.com

-8-

Karel Ben´ ak

2.2 Pouˇ zit´ı adres´ aˇrov´ ych sluˇ zeb

Obr. 2.2: Autentizace v SAPu pomoci adresáˇrov´ ych sluˇzeb

Dalˇs´ım pˇr´ıkladem vyuˇzit´ı adresáˇrov´ ych sluˇzeb je jejich spojen´ı s poˇstovn´ım serverem, kter´ y dokáˇze pˇrepisovat poˇstovn´ı hlaviˇcky s názvem u ´ˇctu uˇzivatele na jeho poˇstovn´ı alias a zpˇet. Poˇstovn´ı server pˇrijme napˇr. e-mail pro pˇr´ıjemce [email protected] a pˇri dotazu na systémové u ´ˇcty zjist´ı, ˇze ˇzádn´ y takov´ yu ´ˇcet na daném serveru neexistuje. Pod´ıv´ a se tedy do seznamu poˇstovn´ıch alias˚ u uloˇzeného v adresáˇrové sluˇzbˇe a zjist´ı, ˇze e-mail má uloˇzit do poˇstovn´ı schránky jnovak. Toto propojen´ı poˇstovn´ıho serveru s adresáˇrov´ ym serverem má ’ napˇr. MS Active Directory s MS Exchange Serverem, kter´ y zajiˇst uje právˇe zmiˇ nované poˇstovn´ı sluˇzby. MS Exchange Server sice obsahuje vlastn´ı verzi adresáˇre, ale propojen´ı s jiˇz zmiˇ novan´ ym Active Directory z nˇej ˇcin´ı ˇcasto pouˇz´ıvané ˇreˇsen´ı pro stˇrednˇe velké a velké podniky. Podobnˇe je na tom [JES], kter´ y pracuje i na jin´ ych platformách, neˇz-li jsou Microsoft Windows, a snaˇz´ı se v´ıce dodrˇzovat standardy definované v pˇr´ısluˇsn´ ych RFC. Obrázek 2.3, strana 9., zobrazuje moˇznost praktického vyuˇzit´ı adresáˇrového serveru jako moˇzného autentizaˇcn´ıho zdroje pro IMAP /POP3 a HTTP server, ovˇsem jak bude popsáno na stranˇe 70, nemus´ı se jeho moˇznosti omezovat pouze na u ´lohu autentizace. M˚ uˇze slouˇzit i jako databáze, ze které ˇcerpá potˇrebné informace DNS a DHCP server. Adres´ aˇrové sluˇzby se snaˇz´ı nahradit nˇekteré zastaralé standardy pro sd´ılen´ı dat pomoc´ı jmenn´ ych sluˇzeb. Pˇr´ıkladem je noˇcn´ı m˚ ura vˇsech administrátor˚ u a odborn´ık˚ u, standardy NIS a NIS+, vytvoˇrené spoleˇcnost´ı Sun Microsystems. Ve své dobˇe se jednalo o pokrokové ˇreˇsen´ı, bohuˇzel se pˇr´ıliˇs nedbalo na jejich bezpeˇcnost. Pokud by z pˇredchoz´ıho ˇci následuj´ıc´ıho textu mohlo vyplynout, ˇze adresáˇrové sluˇzby jsou vˇsemocné, je tˇreba si uvˇedomit charakter a povahu dat, která se v nich ukládaj´ı a se kter´ ymi uˇzivatel pracuje. Adresáˇrové sluˇzby nejsou v ˇz´ adném pˇr´ıpadˇe podobné klasick´ ym relaˇcn´ım databáz´ım, jak se je vˇetˇsina lid´ı snaˇz´ı pochopit. Lze si je pˇredstavit jako velmi jednoduchou kartotéku, ve které se ukládaj´ı jednotlivé l´ıstky do jednotliv´ ych kontejner˚ u. Pˇri splnˇen´ı urˇcit´ ych podm´ınek lze vˇsak v takovéto stromovˇe uspoˇr´ adané kartotéce velmi rychle vyhledávat.

-9-

Karel Ben´ ak

2.3 Data a jejich spr´ ava

Obr. 2.3: Centralizace ovˇeˇren´ı dat

Adresáˇrové sluˇzby nejsou urˇceny k zachycen´ı transakˇcn´ıch dat a neovl´ adaj´ı práci s referenˇcn´ı integritou. K tomu se velmi dobˇre hod´ı klasické relaˇcn´ı databáze, dnes jiˇz v drtivé vˇetˇsinˇe vyuˇz´ıvaj´ıc´ı jazyka SQL (Structured Query Language). Napˇr. pravidelné platby je moˇzné v adresáˇrov´ ych sluˇzbách jist´ ym zp˚ usobem zachytit, je to ale velmi nepraktické ˇreˇsen´ı. S tˇemito daty pak nelze rozumnˇe manipulovat. Jazyk SQL m´ a v tomto ohledu velmi ˇsiroké moˇznosti (matematické operace, pohledy apod.). Adresáˇrov´ ym sluˇzb´ am nelze klást tak sofistikované dotazy, jaké je moˇzné pokládat pomoc´ı SQL, a jiˇz v˚ ubec nepˇripadaj´ı v u ´vahu jakékoliv rozsáhlé transakce spojené napˇr. s vklád´ an´ım v´ıce záznam˚ u do databáze u kter´ ych je nutné provádˇet kontrolu správn´ ych hodnot dat. Adresáˇrové sluˇzby nejsou urˇceny k pˇrenosu soubor˚ u. K nˇemu je primárnˇe urˇcen protokol FTP (File Transfer Protocol). Je snahou, aby zaznamenaná data mˇela co nejmenˇs´ı velikost, zat´ımco pomoc´ı FTP lze pˇrenáˇset data (pˇredevˇs´ım soubory) v rozsahu od nˇekolika byt˚ u aˇz do nˇekolika gigabyt˚ u. Adresáˇrové sluˇzby nejsou urˇceny k prezentaci dat. K tomuto je urˇcen protokol HTTP (Hyper Text Transfer Protocol) a sluˇzba WWW (World Wide Web). Podobnˇe jako v pˇr´ıpadˇe FTP protokolu zde docház´ı k velkému pˇrenosu dat a pˇredevˇs´ım jejich vizualizaci v uˇzivatelovˇe prohl´ıˇzeˇci. Adresáˇrová sluˇzba vˇsak m˚ uˇze slouˇzit jako dobr´ y základ pro seznam odkaz˚ u na konkrétn´ı www stránky. Je tˇreba d˚ uslednˇe analyzovat potˇreby organizace a vyuˇz´ıvat vˇsechny sluˇzby ke konkrétn´ımu u ´ˇcelu, ke kterému byly navrˇzeny. Adresáˇrové sluˇzby jsou velmi v´ yhodné pro jiˇz zm´ınˇenou autentizaci, lze je ovˇsem vyuˇz´ıt i pro uloˇzen´ı jin´ ych dat.

2.3

Data a jejich spr´ ava

Klasické aplikace pouˇz´ıvaj´ı pro uklád´ an´ı sv´ ych dat r˚ uzné druhy databáz´ı. At’ uˇz se jedná o jejich intern´ı datové formáty soubor˚ u, r˚ uzné embedded databáze zaloˇzené na principu kliˇc– hodnota, nebo dokonce velké RDMBS datab´ aze typu klient–server, vˇzdy je tu problém s duplicitou záznam˚ u. Nˇekteré typy dat jsou duplicitnˇe vedené v kaˇzdé z databáz´ı a jejich v´ ymˇena mezi jednotliv´ ymi aplikacemi je moˇzn´ a pouze na základˇe exportn´ıch a importn´ıch filtr˚ u, které jsou schopny pˇrevést jeden typ dat na druh´ y. Administrátor je tak nucen dohl´ıˇzet na nˇekolik - 10 -

Karel Ben´ ak


databáz´ı a mus´ı zajistit jejich konzistenci, správnou u ´drˇzbu, zálohov´ an´ı a pˇr´ıpadnou obnovu (obr. 2.4, strana 10.).

Obr. 2.4: Duplicita databáz´ı Data uloˇzená v adresáˇrovém serveru lze organizovat a spravovat z jediného m´ısta a aplikace, které jsou schopny pouˇz´ıvat adresáˇrové sluˇzby jako sv˚ uj zdroj dat, je pak mohou velmi snadno sd´ılet (obr. 2.5, strana 10.). Rovnˇeˇz je ale moˇzné delegovat administrátorsk´ a práva na

Obr. 2.5: Centralizace databáz´ı v´ıce pracovn´ık˚ u, takˇze jednotlivé ˇcásti adresáˇre mohou spravovat r˚ uzn´ı lidé. Bohuˇzel, adresáˇrové sluˇzby nelze pouˇz´ıt pro uklád´ an´ı vˇsech typ˚ u dat. Zat´ımco v relaˇcn´ıch databáz´ıch lze uloˇzit témˇeˇr vˇsechny druhy, v adresáˇrov´ ych sluˇzb´ ach se jedná o data, která nejsou transakˇcn´ıho charakteru a pro jejichˇz uloˇzen´ı se adresáˇr hod´ı. Adresáˇrové sluˇzby totiˇz ve vˇetˇsinˇe pˇr´ıpad˚ u umoˇzn ˇuj´ı pouze jednoduché transakce a na rozd´ıl od relaˇcn´ıch databáz´ı neobsahuj´ı kontrolu referenˇcn´ı integrity3 . Tu mus´ı zajistit samotná aplikace informaˇcn´ıho systému. 3

Nˇekteré komerˇcn´ı adres´ aˇrové servery, napˇr. [JES] ji v omezené m´ıˇre umoˇzn ˇuj´ı.

- 11 -

Karel Ben´ ak


Data jsou vˇetˇsinou uloˇzena v jednoduch´ ych databáz´ıch typu Berkeley DB. Ty jsou zaloˇzeny na principu kl´ıˇc/hodnota (key/value), ovˇsem tento typ databáz´ı má v nˇekter´ ych implementac´ıch velmi rozsáhlé moˇznosti, mezi kter´ ymi je i moˇznost transakc´ı (ty se ovˇsem net´ ykaj´ı samotné adresáˇrové sluˇzby). Mezi dalˇs´ımi moˇznostmi uklád´ an´ı dat jsou klasické textové nebo binárn´ı soubory a v nˇekter´ ych pˇr´ıpadech i relaˇcn´ı databáze. Napˇr. pˇri pouˇzit´ı Oracle Internet Directory je nutné zakoupit i licenci k jejich relaˇcn´ı databázi, kterou pak adresáˇr vyuˇz´ıv´ a jako u ´loˇziˇstˇe dat. V jin´ ych pˇr´ıpadech je moˇzné pouˇz´ıt pro pˇr´ıstup k relaˇcn´ı databázi rozhran´ı ODBC (Open Database Connectivity) nebo JDBC (Java Database Connectivity). Kaˇzd´ y záznam uloˇzen´ y v databázovém serveru se sklád´ a z atribut˚ u a kaˇzd´ y z atribut˚ u má pˇriˇrazenou nˇejakou hodnotu, jak je vidˇet z obr. 3.5, strana 17. Bl´ıˇze o nich pojednáv´ a kapitola 3.2.2 na stranˇe 16. Data adresáˇrov´ ych sluˇzeb jsou uloˇzena na pevném disku serveru, pˇr´ıpadnˇe na nˇekterém specializovaném hardwarovém a softwarovém ˇreˇsen´ı typu RAID, LVM, SAN apod. Tato ˇreˇsen´ı jsou popsána napˇr. v [BfHA]. V pˇr´ıpadˇe malého rozsahu b´ yvá adresáˇrov´ y strom uloˇzen na jednom serveru (obr. 2.6, strana 11.), kter´ y je navrˇzen na odpov´ıdaj´ıc´ı v´ ykon a vhodnˇe nakonfigurov´ an.

Obr. 2.6: Centralizace adresáˇrov´ ych dat na jednom serveru Nˇekdy je vˇsak vhodnˇejˇs´ı rozdˇelit adresáˇrov´ y strom na nˇekolik jednotliv´ ych vˇetv´ı, které pouze odkazuj´ı na data uloˇzená na jin´ ych serverech. V pˇr´ıpadˇe rozsáhl´ ych strom˚ u a obrovského mnoˇzstv´ı záznam˚ u, které by zab´ıraly velk´ y diskov´ y prostor, je v´ yhodné pouˇz´ıt rozdˇelen´ı adresáˇrového stromu na ˇcásti mezi nˇekolik server˚ u a pak se pomoc´ı referenc´ı odkazovat na jednotlivé vˇetve (obr. 2.7, strana 12.). O tomto problému pojednáv´ a kapitola 3.7. Topologie na stranˇe 42. Tuto moˇznost lze pouˇz´ıt pˇri dobrém návrhu adresáˇrového stromu, kdy je tˇreba vz´ıt v u ´vahu, jak je to pro konkrétn´ı pˇr´ıpad v´ yhodné z hlediska dostupnosti dat a ceny spojen´ı. Pro zv´ yˇsen´ı bezpeˇcnosti ukládan´ ych dat je pouˇzit princip replikac´ı. Replikace je proces, kter´ y slouˇz´ı pro správu a u ´drˇzbu mnoha kopii dat mezi nˇekolika lokalitami. Tyto replikace mohou slouˇzit pro dotazován´ı klient˚ u a t´ım odlehˇcit hlavn´ımu serveru (obr. 2.8, strana 12.). V nˇekter´ ych pˇr´ıpadech je dokonce vhodné nastavit politiku replikac´ı tak, ˇze uˇzivatelé nemohou z centráln´ıho adresáˇrového serveru ˇc´ıst, ale mohou do nich zapisovat. Naopak z replik je moˇzné pouze ˇc´ıst. Repliky je vhodné um´ıstit na poboˇcky, které by byly nuceny se neustále dotazovat centráln´ıho serveru a zatˇeˇzovaly by tak linky pˇripojen´ı k internetu. - 12 -

Karel Ben´ ak


Obr. 2.7: Distribuce adresáˇrov´ ych dat mezi v´ıce server˚ u

Obr. 2.8: Replikované adresáˇrové sluˇzby

- 13 -

Karel Ben´ ak

3.1 Protokol LDAP

Kapitola 3

LDAP Lightweight Directory Access Protocol, ve zkratce LDAP [RFC 2251], je zjednoduˇsenou verz´ı adresáˇrového protokolu X.500 a p˚ uvodnˇe slouˇzil pro komunikaci s t´ımto protokolem. Postupem ˇcasu se vyvinul v plnohodnotn´ y adresáˇrov´ y protokol, kter´ y je schopen svému pˇredch˚ udci zdatnˇe konkurovat a je v podnikové sféˇre mnohem v´ıce pouˇzitelnˇejˇs´ı, neˇz jeho pˇredch˚ udce. V souˇcasné dobˇe vyuˇz´ıvaj´ı protokol X.500 pouze velké telekomunikaˇcn´ı spoleˇcnosti. Podniková sféra a ostatn´ı organizace pˇrech´ azej´ı na LDAP nebo na Microsoft Active Directory. Co je to LDAP? V´ yznam zkratky LDAP lze shrnout do nˇekolika následuj´ıc´ıch term´ın˚ u: • Lightweight Directory Access Protocol – standardizovan´ y protokol pro pˇr´ıstup k adresáˇrov´ ym sluˇzbám • Soubor ˇctyˇr model˚ u – informaˇcn´ı, jmenn´ y, funkˇcn´ı a bezpeˇcnostn´ı model • LDAP Data Interchange Format (LDIF ) – standardizovan´ y textov´ y formát pro v´ ymˇenu adresáˇrov´ ych dat • LDAP serverov´ y software – soubor software pro provoz LDAP serveru • LDAP klientsk´ y software – soubor program˚ u schopn´ ych práce s LDAP serverem • LDAP API – aplikaˇcn´ı programové rozhran´ı pro v´ yvoj software

3.1

Protokol LDAP

LDAP je protokol orientovan´ y na zprávy (message-oriented protocol). Klient vytvoˇr´ı zprávu obsahuj´ıc´ı nˇejakou ˇzádost a odeˇsle ji serveru. Ten ji zpracuje a odeˇsle v´ ysledek zpˇet jako sérii jedné nebo v´ıce LDAP zpráv. Pokud napˇr. klient hledá v adresáˇri konkrétn´ı záznam, zaˇsle LDAP serveru ˇz´ adost o vyhledán´ı (LDAP search request). Ta obsahuje pokud moˇzno co nejpˇresnˇejˇs´ı um´ıstˇen´ı záznamu v adresáˇrovém stromˇe, vyhledávac´ı filtry, poˇzadované atributy, ovˇeˇrovac´ı u ´daje ad. V pˇr´ıpadˇe, ˇze server nalezne v´ıce záznam˚ u, zaˇsle je klientu zpˇet v sérii urˇcitého poˇrad´ı (obr. 3.2, strana 14.).

- 14 -

Karel Ben´ ak

3.1 Protokol LDAP

Obr. 3.1: Jeden nalezen´ y záznam

Obr. 3.2: V´ıce nalezen´ ych záznam˚ u

3.1.1

Operace protokolu LDAP

Protokol LDAP má devˇet základn´ıch operac´ı. Ty lze dále rozdˇelit do tˇrech kategori´ı, podrobnˇeji popsan´ ych v kapitole 3.4 Funkˇcn´ı model, strana 30.: Dotazovac´ı operace: search, compare. Tyto dvˇe operace umoˇzn ˇuj´ı klást adresáˇrovému serveru dotazy. Aktualizaˇ cn´ı operace: add, delete, modify, modify DN (rename). Tyto operace umoˇzn ˇuj´ı u ´pravy záznam˚ u v adresáˇrovém serveru Autentizaˇ cn´ı a ˇ r´ıd´ıc´ı operace: bind, unbind, abandon. Pˇr´ıklad typické komunikace klienta se serverem pˇri hledán´ı záznamu pomoc´ı protokolu LDAP je na obr. 3.3, strana 15. 1. Klient otevˇre TCP spojen´ı s LDAP serverem a zaˇsle pˇr´ıkaz bind. Ten slouˇz´ı pro autentizaci klienta 2. Server ovˇeˇr´ı klientovu identitu a autentizuje jej pro dalˇs´ı operace. V opaˇcném pˇr´ıpadˇe ukonˇc´ı s klientem spojen´ı 3. Klient vytvoˇr´ı a odeˇsle ˇzádost o nalezen´ı záznamu 4. Server odeˇsle klientu záznam nebo v sérii za sebou vˇsechny záznamy, které nalezl 5. Server odeˇsle návratov´ y kód 6. Klient odeˇsle serveru ˇzádost o operaci unbind, která serveru oznám´ı, ˇze klient chce ukonˇcit spojen´ı 7. Server uzavˇre spojen´ı

- 15 -

Karel Ben´ ak

3.2 Informaˇ cn´ı model

Obr. 3.3: Typick´ a komunikace protokolu LDAP

3.1.2

Protokol LDAP v provozu

Z´ akladn´ı pravidla pro k´ odov´ an´ı (Basic Encoding Rules – BER [Dostalek] kapitola 6.) jsou souborem norem pro zakódován´ı r˚ uzn´ ych typ˚ u dat. Tˇemito typy jsou napˇr. celá ˇc´ısla, textové ˇretˇezce a dalˇs´ı. BER ukládá data ve zhuˇstˇeném a na systému nezávislém tvaru, coˇz je d˚ uleˇzité u rozd´ıln´ ych procesorov´ ych architektur v nehomogenn´ım s´ıt’ovém prostˇred´ı, jak´ ym je napˇr. Internet. BER také definuje zp˚ usoby, jak´ ymi lze kombinovat datové typy do r˚ uzn´ ych datov´ ych struktur jako jsou tˇr´ıdy a sekvence. Protokol LDAP pouˇz´ıvá zjednoduˇsenou verzi protokolu BER, tzv. Lightweight BER, zkratka LBER. BER byl zrevidován a byly z nˇej vypuˇstˇeny nˇekteré prvky, které dˇelaly vlastn´ı protokol BER velmi sloˇzit´ ym na pochopen´ı a implementaci. Pˇri vlastn´ım provozu po s´ıti pouˇz´ıv´ a protokol LDAP k´ odov´ an´ı dat pomoc´ı LBER, takˇze data neproud´ı v ˇcistˇe textové podobˇe jako napˇr´ıklad pˇri komunikaci protokolem HTTP a nelze je snadno ˇc´ıst napˇr. pomoc´ı telnetu. Pro zpracov´ an´ı pˇrenesen´ ych dat je nutné opˇet vyuˇz´ıt knihovnu LBER. Vˇetˇsina analyzátor˚ u s´ıt’ového provozu vˇsak nemá s protokolem LDAP a kódován´ım LBER problémy a nen´ı problém napˇr. pomoc´ı obl´ıbeného programu Ethereal1 pˇreˇc´ıst komunikaci mezi serverem a klientem. Pro jej´ı ochranu se proto vyuˇz´ıv´ a zabezpeˇcen´ı popsaného v kapitole 3.5 Bezpeˇcnostn´ı model na stranˇe 35. V pˇr´ıpadˇe nˇekterého serverového software je moˇzné vyuˇz´ıt modern´ıho formátu DSMLv2 (viz. kapitola 3.6 LDIF, strana 39.) zaloˇzeného na jazyce XML.

3.2

Informaˇ cn´ı model

Informaˇcn´ı model definuje datové typy a jednotky informac´ı, které lze v adresáˇri ukládat. V adresáˇri m˚ uˇze b´ yt uloˇzeno nˇekolik tis´ıc aˇz milion˚ u podrobn´ ych záznam˚ u o lidech, poˇc´ıtaˇc´ıch, tiskárnách, pˇr´ıstroj´ıch, m´ıstnostech apod. Záznamy jsou uloˇzeny v pˇrehledné stromové struktuˇre, která vyjadˇruje, jak´ ym stylem jsou záznamy v adresáˇri organizov´ any. Jejich organizac´ı se zab´ yvá jmenn´ y model (viz. kapitola 3.3 Jmenn´ y model, strana 22).

3.2.1

Identifik´ atory objekt˚ u

Identifikátory objekt˚ u nejsou souˇcást´ı LDAP modelu, je ale d˚ uleˇzité se o nich zm´ınit. Slouˇz´ı k pˇresné identifikaci prvku, kter´ y je jednoznaˇcnˇe urˇcen sv´ ym globáln´ım OID (Object Identifier ). Maj´ı hierarchickou strukturu a jsou unikátn´ı na celém svˇetˇe, nelze je tedy zvolit podle libosti. Tuto unikátnost zaruˇcuje centr´ aln´ı autorita, která pˇridˇeluje ˇc´ısla (sufixy) pro sestaven´ı 1

Ethereal – http://www.ethereal.com

- 16 -

Karel Ben´ ak


ˇ ast typického adresáˇre Obr. 3.4: C´

OID. O jejich pˇridˇelován´ı soukrom´ ym organizac´ım se stará mezinárodn´ı organizace IANA2 . Jedné organizaci je moˇzné pˇridˇelit pouze jedno OID, které si mus´ı organizace s ohledem na sv˚ uj rozvoj vhodn´ ym zp˚ usobem rozdˇelit. OID maj´ı tvar 1.3.6.1.4.1.XXX, kde XXX je zm´ınˇen´ y pˇridˇelen´ y suffix reprezentovan´ y cel´ ym ˇc´ıslem. Seznam sufix˚ u jednotliv´ ych organizac´ı je k disˇ ısla za sufixem jsou spravov´ pozici na adrese organizace IANA3 . C´ ana spoleˇcnosti, která si je m˚ uˇze rozdˇelit s ohledem na své intern´ı ˇc´ıseln´ıky. Pokud by napˇr. Skanska CZ z´ıskala sufix 332211, jej´ı OID by mˇ elo tvar 1.3.6.1.4.1.332211 a jeho dalˇs´ı rozdˇelen´ı na jednotlivé ˇc´ asti by mohlo vypadat napˇr. podle tab. 3.1, strana 16. OID 1.3.6.1.4.1.332211 1.3.6.1.4.1.332211.1 1.3.6.1.4.1.332211.2 1.3.6.1.4.1.332211.2.1 1.3.6.1.4.1.332211.2.1.1 1.3.6.1.4.1.332211.2.2 1.3.6.1.4.1.332211.2.2.1

V´ yznam OID Skanska CZ SNMP elementy LDAP elementy Typy atribut˚ u Vlastn´ı atribut Objektové tˇr´ıdy Vlastn´ı objektov´ a tˇr´ıda

Tab. 3.1: Pˇr´ıklad hierarchie OID V´ıce informac´ı o OID se lze dozvˇedˇet napˇr. z [UDLDAPDS], nebo z [Dostalek], kapitola 6.3.

3.2.2

Z´ aznamy

Z´ aznam (entry) je základn´ı jednotkou informac´ı v adresáˇrov´ ych sluˇzb´ ach. Jedná se o soubor informac´ı o objektech, resp. o objektových tˇr´ıd´ ach (objectclass). Kaˇzd´ y záznam se snaˇz´ı 2 3

http://www.iana.org http://www.iana.org/assignments/enterprise-numbers

- 17 -

Karel Ben´ ak


nˇejak´ ym zp˚ usobem popsat reáln´ y objekt, napˇr. ˇclovˇeka, poˇc´ıtaˇc apod. a je sloˇzen z jedné nebo v´ıce objektov´ ych tˇr´ıd. Objektová tˇr´ıda je mnoˇzinou typ˚ u atribut˚ u (Attribute Types) nebo zjednoduˇsenˇe atribut˚ u (Attributes). Ty slouˇz´ı k popisu vlastnost´ı této tˇr´ıdy. Atributy maj´ı jednu nebo v´ıce hodnot (value). Tyto návaznosti zachycuje obr. 3.5, strana 17.

Obr. 3.5: Organizace dat Pˇr´ıkladem záznamu m˚ uˇze b´ yt obr. 3.6, strana 17., kde jsou popsány informace, které jsou o dané osobˇe uchovány. Typ atributu (Attribute type) cn: sn: telephoneNumber: mail:

Hodnoty atributu (Attribute values) Karel Benák Benák Karel Benák +420 723 881 194 [email protected] [email protected]

Obr. 3.6: Adresáˇrov´ y záznam Atributy maj´ı urˇcitou syntaxi (syntax ) a sadu pravidel shody (matching rules). Syntaxe (tab. 3.2, strana 18..) specifikuje, v jaké formˇe mohou b´ yt informace v atributu reprezentov´ any, napˇr´ıklad v datovém typu JPEG Image lze uloˇzit pouze JPEG obrázek (foto uˇzivatele). Pˇri návrhu nov´ ych atribut˚ u, objektov´ ych tˇr´ıd, pravidel shody nebo datov´ ych typ˚ u je vhodné, aby jejich pojmenován´ı mˇelo jedineˇcn´ y prefix. LDAP vyˇzaduje jedineˇcné názvy pro vˇsechny atributy a objektové tˇr´ıdy. Prefix se nejˇcastˇeji vol´ı tak, aby obsahoval zkratku organizace kv˚ uli moˇznému konfliktu názv˚ u s pˇr´ıpadn´ ymi rozˇsiˇruj´ıc´ımi schematy. Napˇr. myPhoto je ’ nevhodn´ y název, nebot stejnˇe znˇej´ıcich názv˚ u m˚ uˇze b´ yt v´ıc. Vhodnˇejˇs´ı je napˇr. pojmenov´ an´ı pˇr´ısluˇsného atributu názvem skanskaPhoto,

3.2.3

Syntaxe

Syntaxe atribut˚ u je definována v [RFC 2252]. Ve své podstatˇe definuje datov´ y typ, kter´ y bude atribut pouˇz´ıvat. Vybrané typy syntaxe jsou v tab. 3.2, strana 18. Pokud je nutné omezit délku atributu na pˇredem stanoven´ y poˇcet m´ıst, uvede se za OID syntaxe sekvence {poˇcet m´ıst}. - 18 -

Karel Ben´ ak


N´ azev binary boolean distinguishedName directoryString IA5String Integer Name and Optional UID Numeric String OID

OID 1.3.6.1.4.1.1466.115.121.1.5 1.3.6.1.4.1.1466.115.121.1.7 1.3.6.1.4.1.1466.115.121.1.12 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.1466.115.121.1.26 1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.34 1.3.6.1.4.1.1466.115.121.1.36 1.3.6.1.4.1.1466.115.121.1.38

Popis BER/DER data boolean hodnota DN UTF-8 ˇretˇezec ASCII ˇretˇezec celé ˇc´ıslo DN plus UID ˇc´ıseln´ y ˇretˇezec object identifier

Tab. 3.2: Syntaxe vybran´ ych typ˚ u

3.2.4

Pravidla shody

Pravidla shody jsou rozdˇelena na pravidla pro: porovn´ av´ an´ı rovnosti hodnot – podle tˇechto pravidel jsou napˇr´ıklad hodnoty atribut˚ u sn=Nov´ ak a sn=nov´ ak pˇri pouˇ zit´ı pravidla caseIgnoreMatch rovny, zat´ımco pˇri pouˇzit´ı jin´ ych pravidel (caseExactMatch) tomu tak nen´ı. setˇ r´ıdˇ en´ı hodnot – podle tˇechto pravidel se napˇr´ıklad pˇri pouˇzit´ı zm´ınˇeného pravidla caseIgnoreMatch hodnoty setˇr´ıd´ı podle lexikografick´ eho poˇrad´ı. Pˇri pouˇzit´ı pravidla integerMatch budou hodnoty setˇr´ıdˇ eny podle ˇc´ıselné hodnoty. N´ azev objectIdentifierMatch distinguishedNameMatch caseIgnoreMatch caseIgnoreOrderingMatch caseIgnoreSubstringsMatch caseExactMatch caseExactOrderingMatch caseExactSubstringsMatch booleanMatch

OID 2.5.13.0 2.5.13.1 2.5.13.2 2.5.13.3 2.5.13.4 2.5.13.5 2.5.13.6 2.5.13.7 2.5.13.13

Typ shoda shoda shoda uspoˇr´ ad´ an´ı podˇretˇezec shoda uspoˇr´ ad´ an´ı podˇretˇezec shoda

Popis OID DN velikost a mezery nerozliˇsuje velikost a mezery nerozliˇsuje velikost a mezery nerozliˇsuje velikost rozliˇsuje, mezery ne velikost rozliˇsuje, mezery ne velikost rozliˇsuje, mezery ne boolean

Tab. 3.3: Vybraná pravidla shody Jak je z tab. 3.3, strana 18. a pˇredevˇs´ım z OID jednotliv´ ych pravidel vidˇet, jsou tato pravidla shody vˇetˇsinou pˇrevzata z protokolu X.500. Podle [RFC 2252], ˇc´ ast 4.5 si kaˇzd´ y návrháˇr m˚ uˇze definovat vlastn´ı pravidla.

3.2.5

Atributy

Atributy slouˇz´ı k popisu nˇekteré z vlastnost´ı objektu. V protokolu LDAPv3 podle [RFC 2252] maj´ı tvar zobrazen´ y na obr. 3.7, strana 19. Jeho pouˇzit´ı je definov´ ano pomoc´ı direktivy USAGE, která pouˇz´ıvá v´ yˇctov´ y typ AttributeUsage (obr. 3.8, strana 19.). - 19 -

Karel Ben´ ak


AttributeTypeDescription = "(" whsp numericoid whsp ; Identifik´ ator Typu atributu [ "NAME" qdescrs ] ; N´ azev pouˇ z´ ıvan´ y typem atributu [ "DESC" qdstring ] ; Popis [ "OBSOLETE" whsp ] [ "SUP" woid ] ; Odvozen´ ı od jin´ eho typu ; atributu [ "EQUALITY" woid ; N´ azev pravidla shody pro shodu [ "ORDERING" woid ; N´ azev pravidla shody pro porovn´ an´ ı [ "SUBSTR" woid ] ; N´ azev pravidla shody pro podˇ retˇ ezec [ "SYNTAX" whsp noidlen whsp ] ; OID syntaxe [ "SINGLE-VALUE" whsp ] ; Standardnˇ e v´ ıcehodnotov´ e [ "COLLECTIVE" whsp ] ; Standardnˇ e not collective [ "NO-USER-MODIFICATION" whsp ]; Standardnˇ e modifikovateln´ e uˇ zivatelem [ "USAGE" whsp AttributeUsage ]; Standardnˇ e userApplications whsp ")" Obr. 3.7: Popis typu atributu

AttributeUsage = "userApplications" / "directoryOperation" / "distributedOperation" / ; DSA-shared "dSAOperation" ; DSA-specific, hodnota z´ avis´ ı na serveru Obr. 3.8: Vyuˇzit´ı atributu

- 20 -

Karel Ben´ ak


Atributy lze podle direktivy USAGE rozdˇelit do dvou kategori´ı: uˇ zivatelsk´ e – atributy pouˇz´ıvané pro uklád´ an´ı uˇzivatelsk´ ych informac´ı. V takovém atributu m˚ uˇze b´ yt uloˇzeno napˇr´ıklad jméno uˇzivatele (givenName) apod. Mohou b´ yt mˇenˇeny uˇzivatelem, kter´ y k tomu má pˇr´ısluˇsn´ a oprávnˇen´ı. operaˇ cn´ı – atributy, které vyuˇz´ıvá adresáˇrov´ y server pro uchov´ an´ı systémov´ ych informac´ı, napˇr. data posledn´ı zmˇeny modifyTimeStamp. Takov´ y atribut má kaˇzd´ y záznam a pokud dojde k jeho zmˇenˇe, server automaticky zmˇen´ı i hodnotu tohoto atributu. Atributy mohou m´ıt jednu (single-valued ) nebo v´ıce (multivalued ) hodnot, resp. mohou b´ yt v objektové tˇr´ıdˇe pouze jednou (direktiva SINGLE-VALUE) nebo v´ıcekr´ at. Pˇri vytváˇren´ı atribut˚ u je moˇzné vyuˇz´ıt principu tzv. supertypu a subtypu. Supertyp je základn´ı typ, ze kterého se vycház´ı pˇri odvozov´ an´ı nov´ ych typ˚ u. Schema závislost´ı zobrazuje obr. 3.9, strana 20..

Obr. 3.9: Vztahy mezi supertypem a subtypy

attributeType ( 1.3.6.1.4.1.332211.2.1.12 NAME ’skanskaCard’ DESC ’ID pristupove karty pro pristup do budov Skanska CZ’ EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27{8} SINGLE-VALUE ) Obr. 3.10: Pˇr´ıklad nového atributu skanskaCard

attributeType ( 1.3.6.1.4.1.332211.2.1.13 NAME ’skanskaCardCar’ DESC ’ID pristupove karty do garazi Skanska CZ’ SUP skanskaCard SINGLE-VALUE ) Obr. 3.11: Odvozen´ y atribut skanskaCardCar

3.2.6

Objektov´ e tˇ r´ıdy

Objektová tˇr´ıda slouˇz´ı pro popis konkrétn´ıho objektu, napˇr. ˇclovˇeka, zamˇestnance, uˇzivatele pˇripojen´ı, m´ıstnosti apod. Skládaj´ı se z nˇekolika atribut˚ u a jsou vˇetˇsinou odvozeny od nˇekteré - 21 -

Karel Ben´ ak


z nadˇrazen´ ych tˇr´ıd. Hlavn´ı tˇr´ıdou, je abstraktn´ı tˇr´ıda top, od které jsou vˇsechny ostatn´ı tˇr´ıdy odvozeny. Princip dˇediˇcnosti a jeho v´ yznam je na obr. 3.12, strana 21. Pˇri vytváˇren´ı nové tˇr´ıdy z´ıskává po svém pˇredkovi jeho atributy a pˇrid´ av´ a k nˇemu vlastn´ı.

Obr. 3.12: Dˇediˇcnost objektov´ ych tˇr´ıd Tvar objektové tˇr´ıdy podle LDAPv3 definované v [RFC 2252] je na obr. 3.12, strana 21.. ObjectClassDescription = "(" whsp numericoid whsp ; Identifikace objektov´ e tˇ r´ ıdy [ "NAME" qdescrs ] [ "DESC" qdstring ] [ "OBSOLETE" whsp ] [ "SUP" oids ] ; Nadˇ razen´ a tˇ r´ ıda [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] ; Standardnˇ e structural [ "MUST" oids ] ; Atributy [ "MAY" oids ] ; Atributy whsp ")" Obr. 3.13: Definice objektové tˇr´ıdy Objektová tˇr´ıda mus´ı m´ıt své jedineˇcné OID, jedineˇcn´ y název, popis, pˇredka, druh a seznam atribut˚ u, které mohou b´ yt povinné nebo nepovinné. Povinné atributy (MUST) mus´ı b´ yt vyplnˇeny vˇzdy, jinak adresáˇrov´ y server odm´ıtne záznam uloˇzit nebo modifikovat. Atributy uvedené v direktivˇe MAY nemusej´ı b´ yt vyplnˇeny. V záznamu mus´ı b´ yt minimálnˇe jedna tˇr´ıda typu STRUCTURAL, nelze jej sloˇzit pouze ze tˇr´ıd typu AUXILIARY. ABSTRACT – Abstraktn´ı tˇr´ıda, od které se budou odvozovat nové tˇr´ıdy, nebo tˇr´ıdy slouˇz´ıc´ı pro správu informaˇcn´ıho modelu. Nejˇcastˇeji pouˇz´ıvanou abstraktn´ı tˇr´ıdou je tˇr´ıda top, od které jsou odvozeny dalˇs´ı tˇr´ıdy a tˇr´ıda alias, která slouˇz´ı pro správu alias˚ u (kapitola 3.3.3 Aliasy na stranˇe 29). AUXILIARY – Tˇr´ıda, která je doplˇ nkovou tˇr´ıdou k ostatn´ım tˇr´ıd´ am. Velmi ˇcasto má jako svého pˇredka tˇr´ıdu top. Lze ji pˇriˇradit ke kaˇzdému typu záznamu, v záznamu je vˇsak tˇreba pouˇz´ıt minimálnˇe jednu tˇr´ıdu typu STRUCTURAL. Tyto tˇr´ıdy lze v záznamu kombinovat bez ohledu na jejich urˇcen´ı.

- 22 -

Karel Ben´ ak

3.3 Jmenn´ y model

STRUCTURAL – Podobnˇe jako tˇr´ıda AUXILIARY je odvozena od nˇekteré tˇr´ıdy uvedené v direktivˇe SUP. Je mnohem v´ıce restriktivn´ı a umoˇ zn ˇuje kombinaci pouze se tˇr´ıdami nadˇrazen´ ymi, které pˇresnˇe vystihuj´ı typ ukládaného záznamu. Typick´ ym pˇr´ıkladem tˇr´ıdy typu STRUCTURAL je tˇr´ıda inetOrgPerson (definovan´ a v [RFC 2798]), odvozen´ a od tˇr´ıdy organizationalPerson. K této tˇr´ıdˇe nen´ı moˇzné pˇriˇradit dalˇs´ı tˇr´ıdu typu STRUCTURAL, napˇr. tˇr´ıdu account. Ta je sice potomkem tˇr´ıdy top, ovˇsem nen´ı potomkem tˇr´ıdy person, tud´ıˇz ji nen´ı moˇzné slouˇcit s tˇr´ıdami, které maj´ı tˇr´ıdu person jako svého pˇredka a jsou typu STRUCTURAL. objectclass ( 1.3.6.1.1.1.2.4 NAME ’ipProtocol’ SUP top STRUCTURAL DESC ’Abstraction of an IP protocol’ MUST ( cn $ ipProtocolNumber $ description ) MAY description ) Obr. 3.14: Objektov´ a tˇr´ıda typu STRUCTURAL

objectclass ( 1.3.6.1.1.1.2.0 NAME ’posixAccount’ SUP top AUXILIARY DESC ’Abstraction of an account with POSIX attributes’ MUST ( cn $ uid $ uidNumber $ gidNumber $ homeDirectory ) MAY ( userPassword $ loginShell $ gecos $ description ) ) Obr. 3.15: Objektov´ a tˇr´ıda typu AUXILIARY Pˇr´ıklady záznam˚ u jsou uvedeny v kapitole 3.6 LDIF na stranˇe 39.

3.2.7

Sch´ emata

Seznam atribut˚ u a objektov´ ych tˇr´ıd, se kter´ ymi adresáˇrov´ y server pracuje, je uloˇzen v tzv. schematech. Standardizovaná schemata jsou vˇetˇsinou souˇc´ ast´ı adresáˇrov´ ych server˚ u, stejnˇe jako schemata dodaná v´ yrobcem. Aˇckoliv je doporuˇceno v maximáln´ı m´ıˇre vyuˇz´ıvat schemat dodávan´ ych spolu s adresáˇrov´ ym serverem, m˚ uˇze vzniknout potˇreba napsat schema vlastn´ı. Pokud tv˚ urci informaˇcn´ıho systému sáhnou k této variantˇe, mus´ı poˇc´ıtat s t´ım, ˇze nˇekteré informace budou pro klienty podporuj´ıc´ı standardizovan´ a schemata nedostupná, pˇr´ıpadnˇe se budou muset sloˇzitˇe pˇremapovat na standardizované atributy. Podrobnˇejˇs´ı informace o objektov´ ych tˇr´ıd´ ach, atributech, pravidlech syntaxe a pravidel shody jsou v [UDLDAPDS, RFC 2252].

3.3

Jmenn´ y model

Jmenný model LDAP (LDAP Naming Model) definuje, jak´ ym zp˚ usobem lze organizovat a odkazovat se na data uloˇzená v adresáˇri. Umoˇzn ˇuje tak flexibiln´ı pˇr´ıstup a jednoduˇsˇs´ı správu pomoc´ı logické stromové struktury. Typick´ y tvar adresáˇrového stromu, tzv. DIT (Directory Information Tree), je na obr. 3.16, strana 23. Jedná se o stromov´ y graf, kter´ y má své uzly a listy. Listy jsou vlastn´ı záznamy o nˇejakém reálném objektu, uzly pak definuj´ı vˇetve stromu. Uzly jsou nutnou souˇcást´ı adresáˇrového stromu, do kter´ ych se ukládaj´ı jednotlivé listy (záznamy).

- 23 -

Karel Ben´ ak

3.3 Jmenn´ y model

ˇ ast typického adresáˇrového stromu Obr. 3.16: C´

Adresáˇrov´ y strom je podobn´ y hierarchickému souborovému systému pouˇz´ıvaného operaˇcn´ımi systémy typu UNIX, ve kterém se systém soubor˚ u sklád´ a z adresáˇr˚ u a soubor˚ u. Kaˇzd´ y adresáˇr má nˇekolik soubor˚ u anebo podadresáˇr˚ u, jak je vidˇet z obrázku 3.17.

ˇ ast typického souborového systému UNIX Obr. 3.17: C´ Mezi UNIXov´ ym souborov´ ym systémem a adresáˇrov´ ym stromem LDAP jsou vˇsak tˇri podstatné rozd´ıly. Prvn´ı spoˇc´ıvá v tom, ˇze LDAP server ve skuteˇcnosti nemá ˇz´ adn´ y reáln´ y koˇren, zat´ımco koˇren souborového systému je rodiˇcem dalˇs´ıch adresáˇr˚ u a soubor˚ u. LDAP server má sice koˇrenov´ y záznam, ten ale pouˇz´ıv´ a pro uloˇzen´ı specifick´ ych konfiguraˇcn´ıch informac´ı o sv´ ych moˇznostech, tzv. rootDSE. Jsou v nˇem uloˇzeny napˇr. informace o pouˇz´ıvané verzi protokolu, FQDN 4 serveru, podpoˇre protokol˚ u TLS a SASL apod., nikoliv vˇsak vlastn´ı uˇzivatelská data. Pro nˇe m˚ uˇze m´ıt nˇekolik ”virtuáln´ıch” koˇren˚ u, zat´ımco souborov´ y systém má pouze jedin´ y koˇren. Druh´ ym podstatn´ ym rozd´ılem je zp˚ usob uklád´ an´ı informac´ı. Typick´ y LDAP adresáˇr se záznamy a kontejnery ukazuje obr. 3.18, strana 24.. V tomto pˇr´ıpadˇe kontejnery dc=skanska, dc=cz ou=Kub´ ansk´ e~n´ amˇ est´ ı, dc=skanska, dc=cz 4

FQDN – fully qualified domain name, pln´ y doménov´ y n´ azev

- 24 -

Karel Ben´ ak

3.3 Jmenn´ y model

ˇ ast typického LDAP adresáˇre Obr. 3.18: C´

- 25 -

Karel Ben´ ak

3.3 Jmenn´ y model

ou=Tˇ rinec, dc=skanska, dc=cz ou=Lide, ou=Kub´ ansk´ e n´ amˇ est´ ı, dc=skanska, dc=cz ou=Lide, ou=Tˇ rinec, dc=skanska, dc=cz vystupuj´ı zároveˇ n jako uzly (kontejnery) i listy (záznamy), ve kter´ ych jsou uloˇzeny dalˇs´ı kontejnery a záznamy. Naproti tomu v souborovém systému vystupuje adresáˇr pouze jako uzel a soubor pouze jako list. Kaˇzd´ y uzel m˚ uˇze obsahovat dalˇs´ı uzly i listy, nem˚ uˇze se vˇsak stát zároveˇ n listem i uzlem dohromady. Tˇret´ım podstatn´ ym rozd´ılem je zp˚ usob, jak´ ym se vyjadˇruje cesta k záznamu nebo souboru. Zat´ımco v pˇr´ıpadˇe souborového systému je cesta ke kompil´ atoru cc vyj´ adˇrena od koˇrene systému / pˇres adresáˇre usr a bin aˇz k cc jako /usr/bin/cc z leva do prava, v LDAP adresáˇri je cesta od koˇrene k záznamu vyjadˇrov´ ana z prava do leva (uid=fa145020, ou=Lidé, ou=Kub´ ansk´ e n´ amˇ est´ ı, dc=skanska, dc=cz). Zat´ımco vlastn´ı z´ aznam o pracovn´ıkovi s uid=fa145020 je uveden na prvn´ım m´ıstˇe, koˇrenov´ y kontejner je uveden aˇz na m´ıstˇe posledn´ım.

3.3.1

V´ yznam jmenn´ eho modelu

Správnˇe navrˇzené jmenné prostory jsou velmi d˚ uleˇzité a pˇrin´ aˇsej´ı velké v´ yhody pˇri správˇe a u ´drˇzbˇe záznam˚ u. Reference dat – jmenn´ y model umoˇzn ˇuje pohodlné odkazov´ an´ı se z jednoho záznamu na druh´ y napˇr´ıklad pomoc´ı referenc´ı, alias˚ u, nebo pomoc´ı atribut˚ u, které maj´ı jako sv˚ uj datov´ y typ DN zázamu, na kter´ y je odkazov´ ano. Organizace dat – data jsou uloˇzena v jednotliv´ ych kontejnerech podle nˇejakého specifického znaku. Ten je v daném kontejneru jedineˇcn´ y a t´ım je stanovena jedineˇcnost záznamu. Rozdˇ elen´ı dat – data lze efektivnˇe rozdˇelit mezi v´ıce poboˇcek a nen´ı nutné je drˇzet vˇsechny na jediném serveru v centrále. O topologii pojednáv´ a kapitola 3.7 Topologie na stranˇe 42. Replikace dat – pˇri správnˇe navrˇzen´ ych jmenn´ ych prostorech je efektivnˇejˇs´ı zálohovat pouze ˇcást pˇr´ısluˇsného stromu, nikoliv vˇsechny jeho ˇc´ asti Pˇ r´ıstupov´ a pr´ ava – pˇri správnˇe navrˇzen´ ych jmenn´ ych prostorech lze pˇriˇradit pˇr´ıstupov´ a práva v konkrétn´ı vˇetvi konkrétn´ımu ˇclovˇeku, aniˇz by mˇel dotyˇcn´ y práva k dat˚ um, která nezbytnˇe nepotˇrebuje. Pˇr´ıkladem m˚ uˇze b´ yt situace, kdy správce Tˇrinecké poboˇcky Skansky spravuje pouze svou vˇetev ou=Trinec, dc=skanska, dc=cz, zat´ımco ke zbyl´ ym vˇetv´ım má pˇr´ıstup pouze pro ˇcten´ı, nikoliv pro modifikaci záznam˚ u. Podpora aplikac´ı – aplikace mohou vyuˇz´ıvat pouze ˇc´ ast stromové struktury a nemusej´ı zbyteˇcnˇe prohledávat vˇsechny záznamy. Pˇr´ıkladem je seznam pracovn´ık˚ u konkrétn´ı poboˇcky ou=Pracovnici, ou=Trinec, dc=skanska, dc=cz, kdy klient se ptá pouze v této vˇetvi, aniˇz by musel prohledávat i dalˇs´ı vˇetve. Jmenn´ y model poskytuje unikátn´ı a jedineˇcné názvy pro kaˇzd´ y záznam v adresáˇri umoˇzn ˇuj´ıc´ı snadné a pˇresné odkazován´ı se. Tuto jedineˇcnou identifikaci záznamu v adresáˇrovém stromu umoˇzn ˇuje tzv. rozliˇ sovac´ı n´ azev, zkratka DN, (distinguished name), kter´ y je u ´plnou cestou k danému záznamu. Pˇr´ıkladem typického DN je jiˇz zmiˇ novan´ y záznam o uˇzivateli s uid=fa145020. V cestˇe jsou smˇerem z prava do leva uvedeny jednotlivé kontejnery oddˇelené ˇc´ arkou (mezera - 26 -

Karel Ben´ ak

3.3 Jmenn´ y model

je volitelná). Na konci cesty je uveden vlastn´ı záznam. Název záznamu se sklád´ a z názvu atributu, znaku = a hodnoty atributu. Následuj´ıc´ı záznamy jsou si rovny: uid=fa145020, ou=Lid´ e, ou=Kub´ ansk´ e n´ amˇ est´ ı, dc=skanska, dc=cz uid=fa145020,ou=Lid´ e,ou=Kub´ ansk´ e n´ amˇ est´ ı,dc=skanska,dc=cz S pojmen rozliˇsovac´ı n´ azev u ´zce souvis´ı pojem relativn´ı rozliˇ sovac´ı n´ azev (relative distinguished name – RDN). RDN je název vlastn´ıho záznamu kter´ y mus´ı b´ yt v daném kontejneru jedineˇcn´ y. Z DN cn=Jana Nováková, ou=Lide, ou=Tˇrinec, dc=skanska, dc=cz je RDN cn=Jana Nováková. V této vˇetvi se jiˇz ˇz´ adn´ y dalˇs´ı záznam s t´ımto RDN nesm´ı vyskytovat, ovˇsem v dalˇs´ıch vˇetv´ıch ano.

Obr. 3.19: Záznamy se shodn´ ym RDN V nˇekter´ ych pˇr´ıpadech je tˇreba pouˇz´ıt stejnou hodnotu atributu v RDN pro dva nebo v´ıce záznam˚ u, napˇr´ıklad pokud je tˇreba v jedné vˇetvi drˇzet záznamy o dvou Janách Nov´ akov´ ych. V takovém pˇr´ıpadˇe se pouˇz´ıvá tzv. v´ıcehodnotové RDN (multivalued RDN ). V RDN je pouˇz´ıto v´ıce hodnot atribut˚ u oddˇelen´ ych znakem +. Tvar RDN pak vypadá napˇr. následovnˇe: cn=Jana Nov´ akov´ a + [email protected]

Ve v´ıcehodnotovém RDN nezáleˇz´ı na poˇrad´ı, proto si jsou následuj´ıc´ı DN rovny: cn=Jana Nov´ akov´ a + [email protected], ou=Lid´ e, ou=Kub´ ansk´ e n´ amˇ est´ ı, dc=skanska, dc=cz [email protected] + cn=Jana Nov´ akov´ a, ou=Lid´ e, ou=Kub´ ansk´ e n´ amˇ est´ ı, dc=skanska, dc=cz Bohuˇzel, málo aplikac´ı um´ı pracovat s v´ıcehodnotov´ ymi RDN, proto se doporuˇcuje volit název RDN tak, aby byla zajiˇstˇena jeho unikátnost v rámci daného kontejneru pomoc´ı jediného názvu v RDN. V pˇr´ıpadˇe nutnosti pouˇzit´ı speciáln´ıch znak˚ u v DN, jak´ ym je pˇredevˇs´ım znak ˇc´ arky slouˇz´ıc´ı standardnˇe pro oddˇelen´ı jednotliv´ ych záznam˚ u, je nutné pouˇz´ıt tzv. u ńikových nebo-li escape sekvenc´ı, které jsou uvozeny obrácen´ ym lom´ıtkem \, tzv. backslash. Pˇr´ıkladem by mohl b´ yt záznam o=Skanska CZ, a.s. V tom pˇr´ıpadˇe by DN záznamu vypadalo: o=Skanska CZ\, a.s., c=CZ

- 27 -

Karel Ben´ ak

3.3 Jmenn´ y model

Obr. 3.20: Podporované jmenné prostory

3.3.2

Struktura jmenn´ ych prostor˚ u

LDAP podporuje stromové struktury podle obrázku obr. 3.20, strana 27., naopak nˇekteré tvary (obr. 3.21, strana 27.) nejsou podporované a odporuj´ı stromové struktuˇre.

Obr. 3.21: Nepodporované jmenné prostory Koˇren jmenn´ ych prostor˚ u se naz´ yv´ a sufix (suffix ), nˇekdy téˇz prefix. Model jmenn´ ych prostor˚ u LDAP je zdˇedˇen z modelu jmenn´ ych prostor˚ u standardu X.500. Ten zaˇc´ın´ a vrcholov´ ym prvkem C (Country), ve kterém je uvedena ISO zkratka zemˇe. Pak m˚ uˇze následovat prvek S pro uveden´ı názvu státu (standard X.500 vych´ az´ı z norem USA) a po nˇem následuje záznam organizace O. Pˇr´ıklad adresáˇrového stromu podle normy X.500 je na obr. 3.22, strana 27. a DN záznamu o Janˇe Novákové by vypadalo: cn=Jana Nováková, ou=Lide, o= Skanska CZ, c=cz

Obr. 3.22: Jmenné prostory podle normy X500

- 28 -

Karel Ben´ ak

3.3 Jmenn´ y model

Na rozd´ıl od X.500 nen´ı model LDAP tak restriktivn´ı jako jeho pˇredch˚ udce a umoˇzn ˇuje flexibilnˇejˇs´ı návrh sufixu, kter´ y v´ıce odpov´ıd´ a potˇreb´ am organizace pro kterou je navrhov´ an. Je moˇzné drˇzet se podle normy X.500, ovˇsem doporuˇcuje se sp´ıˇs pouˇz´ıt v sufixu doménové jméno podle [RFC 2247]. Sufix spoleˇcnosti Skanska CZ pak vypadá dc=skanska, dc=cz, v´ıce pˇr´ıklad˚ u návrh˚ u sufix˚ u je na obr. 3.23, strana 28. V DN záznam˚ u je moˇzné pouˇz´ıt i diakritické

Obr. 3.23: Pˇr´ıklady sufix˚ u v LDAP znaky, ovˇsem pak je nutné uvést DN v kódov´ an´ı UTF-8 podle [RFC 2253]. Dalˇs´ı dˇelen´ı adresáˇrového stromu na jednotlivé vˇetve záleˇz´ı na podrobnˇejˇs´ı anal´ yze, kdy je tˇreba vz´ıt v u ´vahu potˇreby spoleˇcnosti, jej´ı s´ıt’ovou topologii, potˇrebu replikac´ı a celou ˇradu dalˇs´ıch podm´ınek. V tomto pˇr´ıpadˇe se lze setkat s pojmem kontext (context), coˇz je ve své podstatˇe cesta od sufixu aˇz k RDN záznamu. DN se ve své podstatˇe sklád´ a z RDN, kontextu a sufixu. Pˇr´ıkladem je napˇr. DN záznamu uid=ja131515, ou=Lide, ou=Trinec, dc=skanska, dc=cz, kdy RDN z´ aznamu je uid=ja131515, ou=Lide, kontext je ou=Lide, ou=Trinec a koneˇcnˇe hodnota sufixu dc=skanska, dc=cz. Pˇr´ıklady jmenn´ ych prostor˚ u jsou na obr. 3.24, strana 28., obr. 3.25, strana 28. a obr. 3.26, strana 29.

Obr. 3.24: Jmenné prostory podle kontinent˚ u

Obr. 3.25: Jmenné prostory podle oddˇelen´ı

- 29 -

Karel Ben´ ak

3.3 Jmenn´ y model

Obr. 3.26: Jmenné prostory podle souˇc´ ast´ı

3.3.3

Aliasy

Záznamy Alias jsou záznamy v adresáˇrovém stromu, které funguj´ı jako odkazy na uloˇzen´ y záznam. Jsou velmi podobné klasick´ ym symbolick´ ym link˚ um ze souborového systému typu UNIX nebo zástupc˚ um ve Windows. Pomoc´ı aliasu lze dosáhnout um´ıstˇen´ı jednoho záznamu do v´ıce vˇetv´ı, napˇr. pokud jeden pracovn´ık pracuje pro dvˇe oddˇelen´ı. Pˇri pouˇzit´ı SQL by bylo nutné pouˇz´ıt napˇr. speciáln´ı tabulku, která by postihovala relaci m:n mezi tabulkou pracovn´ık˚ u a tabulkou oddˇelen´ı. V adresáˇrové struktuˇre je naproti tomu nutné bud’ duplikovat záznam, coˇz je nevyhovuj´ıc´ı kv˚ uli redundanci dat, nebo se zde nab´ız´ı moˇznost pouˇzit´ı alias˚ u, kdy hlavn´ı záznam je uloˇzen v jedné vˇetvi stromu a z druhé vˇetve je na nˇej vytvoˇren´ y odkaz.

Obr. 3.27: Aliasy v adresáˇrovém stromu Aliasy poruˇsuj´ı pˇr´ısnˇe hierarchickou strukturu adresáˇrového stromu, ovˇsem bez jejich pouˇzit´ı nelze postihnout zm´ınˇené vazby m:n. Pro vytvoˇren´ı aliasu je tˇreba vytvoˇrit záznam z objektové tˇr´ıdy alias a jako atribut pouˇz´ıt aliasObjectName, ve kterém se uvede DN záznamu, na kter´ y se alias odkazuje.

Obr. 3.28: Aliasy mezi adresáˇrov´ ymi servery

- 30 -

Karel Ben´ ak

3.4 Funkˇ cn´ı model

Aliasy lze pouˇz´ıt i pro odkazy na záznamy uloˇzené na jin´ ych serverech. Bohuˇzel, jejich pouˇzit´ı je v tomto ohledu velmi pomalé a neefektivn´ı, proto se doporuˇcuje pouˇz´ıt m´ısto nich mechanismu referenc´ı, které jsou popsány v [UDLDAPDS].

3.4

Funkˇ cn´ı model

Funkˇcn´ı model LDAP obsahuje tˇri kategorie operac´ı, které byly ve struˇcnosti zm´ınˇeny v kapitole 3.1.1.

3.4.1

Dotazovac´ı operace LDAP

Dotazovac´ı operace search slouˇz´ı pro vyhledáv´ an´ı záznam˚ u v adresáˇri a operace compare pro testován´ı, zda záznamy obsahuj´ı atributy s urˇcit´ ymi hodnotami. Operace search slouˇz´ı pro prohledáván´ı adresáˇrového stromu a jako sv˚ uj v´ ysledek vrac´ı jednotlivé záznamy. Pˇri jejich prohledáván´ı je moˇzné z´ıskat u ´plné záznamy nebo pouze hodnoty nˇekter´ ych atribut˚ u. V´ ysledek prohledáván´ı rovnˇeˇz záleˇz´ı na pˇr´ıstupov´ ych právech, kdy napˇr´ıklad uˇzivatelské heslo uloˇzené v atributu userPassword je pˇr´ıstupné5 pouze jeho vlastn´ıkovi nebo správci celého DIT. Operace search má 8 vstupn´ıch parametr˚ u: V´ ychoz´ı bod hled´ an´ı (base object) – V doslovném pˇrekladu z´ akladn´ı objekt (v tomto kontextu jsou pojmy objekt a záznam ekvivalentn´ı). Urˇcuje uzel stromu pomoc´ı jeho DN, od kterého se má zaˇc´ıt s prohledáv´ an´ım záznam˚ u. Tento parametr je v´ yhodné pouˇz´ıt zejména pro optimalizaci vyhledáv´ an´ı záznam˚ u, pˇredpokladem je ovˇsem znalost m´ısta, kde je tˇreba hledat. Pˇr´ıkladem m˚ uˇze b´ yt obr. 3.29, ve kterém se m´ısto prohledáván´ı celého adresáˇrového stromu prohledáv´ a pouze vˇetev od uzlu ou=Clenove, dc=sin, dc=cvut, dc=cz. ldapsearch -b "ou=Clenove,dc=sin,dc=cvut,dc=cz" Obr. 3.29: Vyhledán´ı v konkrétn´ı vˇetvi Oblast prohled´ av´ an´ı (search scope) – Tento parametr urˇcuje, do jaké hloubky se má pˇri prohledáván´ı adresáˇre j´ıt. K dispozici jsou tˇri parametry: base, onelevel a sub. Na obr. 3.30 jsou vidˇet oblasti prohledáv´ an´ı pˇri pouˇzit´ı pˇr´ısluˇsn´ ych parametr˚ u. base – pˇri pouˇzit´ı tohoto parametru vrac´ı operace search pouze záznam v´ ychoz´ıho bodu hledán´ı onelevel – pˇri pouˇzit´ı tohoto parametru vrac´ı operace search vˇsechny záznamy prvn´ı u ´rovnˇe od v´ ychoz´ıho bodu hledán´ı sub – pˇri pouˇzit´ı tohoto parametru vrac´ı operace search vˇsechny záznamy od v´ ychoz´ıho bodu hledán´ı (vˇcetnˇe) 5ˇ

Citelné je pouze v pˇr´ıpadˇe, ˇze je uloˇzeno ve form´ atu ˇcistého textu

- 31 -

Karel Ben´ ak


search base = "ou=People, dc=sin, dc=cvut, dc=cz"

search scope=base

search scope=onelevel

search scope=sub

Obr. 3.30: Prohledáv´ an´ı adresáˇrového stromu ldapsearch -b "ou=Clenove,dc=sin,dc=cvut,dc=cz" -s onelevel Obr. 3.31: Vyhledáv´ an´ı v konkrétn´ı vˇetvi do prvn´ı u ´rovnˇe Dereference z´ astupc˚ u (alias dereferencing options) – Tento tˇret´ı parametr urˇcuje, jak´ ym zp˚ usobem se bude pˇri prohledáv´ an´ı nakládat s aliasy na jiné objekty. neverDerefAliases derefInSearching derefFindingBaseObject derefAlways Limit poˇ ctu navr´ acen´ ych z´ aznam˚ u (size limit) – Udáv´ a maximáln´ı poˇcet záznam˚ u, které je klient ochoten akceptovat. Standardnˇe b´ yv´ a nastaveno cca 100 záznam˚ u. Pˇri pˇrekroˇcen´ı limitu je vrácen návratov´ y kód LDAP SIZELIMIT EXCEEDED, která informuje o jeho pˇrekroˇcen´ı a kter´ y mus´ı pˇr´ısluˇsn´ a aplikace nˇejak´ ym zp˚ usobem zpracovat. Limit nastaven´ y na hodnotu 0 informuje, ˇze nen´ı ˇza´dn´ y limit nastaven a server m˚ uˇze zaslat veˇskeré informace, které nalezl. Toto lze ovˇsem nastavit i na stranˇe serveru a neomezen´ y poˇcet nalezen´ ych záznam˚ u lze povolit jen privilegovan´ ym uˇzivatel˚ um. ˇ Casov´ y limit (time limit) – Nastavuje hodnoty pro ˇcasov´ y limit v sekundách, po kter´ y je klient ochoten pˇrij´ımat od LDAP serveru záznamy. Pˇri pˇrekroˇcen´ı tohoto limitu je navrácen návratov´ y kód LDAP TIMELIMIT EXCEEDED. Pouze atributy (attributes-only ) – attrsOnly je logick´ y parametr (boolean), kter´ y udáv´ a, máj´ı-li se vracet ve v´ ysledku záznamu hodnoty atribut˚ u. Pˇri nastaven´ı atributu na hodnotu true se vrac´ı pouze seznam atribut˚ u, které jsou v záznamu pouˇzity, pˇri nastaven´ı na hodnotu false se vrát´ı atributy i jejich hodnoty. Vyhled´ avac´ı filtry (search filter ) – Slouˇz´ı pro vyjádˇren´ı hledan´ ych v´ yraz˚ u v adresáˇrovém stromu. Filtry jsou specifikovány v [RFC 2254] a jejich pˇrehled udáv´ a tab. 3.4, strana 32. - 32 -

Karel Ben´ ak

Typ filtru Shoda (Equality) Podˇretˇezec (Substring)


Form´ at (atribut= hodnota)

Pˇ r´ıklad

(atribut= [prvn´ ı] *nˇ ejak´ y* [koncov´ y])

(sn=*ov´ a*) (sn=Nov´ a*)

Pˇribliˇznˇe (Approximate)

(atribut~= hodnota)

cn~=tatar

Vˇetˇs´ı nebo shodné Menˇs´ı nebo shodné Pˇr´ıtomnost (Presence) AND

(atribut>=

(floor>=9)

OR NOT

(sn=Nov´ ak)

(sn=*´ aˇ cek) (sn=N*v*k)

hodnota) (atribut<=

(floor<9)

hodnota) (atribut=*)

(sn=*)

(&(filtr1) (filtr2)...) (|(filtr1) (filtr2)...) (!(filtr))

(&(sn=Nov´ ak) (givenName=Jiˇ r´ ı)) (|(givenName=Jiˇ r´ ı) (givenName=Josef))

(!(mail=*))

Odpov´ıd´ a Pˇr´ıjmen´ı pˇresnˇe odpov´ıd´ a Novák Pˇr´ıjmen´ı obsahuje ”ová” Pˇr´ıjmen´ı zaˇc´ın´ a na ”Nová” Pˇr´ıjmen´ı konˇc´ı na ”áˇcek” Pˇr´ıjmen´ı zaˇc´ın´ a na ”N”, obsahuje ”v” a konˇc´ı na ”k” N´ azev poˇc´ıtaˇce odpov´ıd´ a n´ azvu tatar, ale m˚ uˇze odpov´ıdat i názvu tartar Lidé, kteˇr´ı bydl´ı na devátém nebo vyˇsˇs´ım patˇre Lidé, kteˇr´ı bydl´ı pod dev´ at´ ym patrem Vˇsechna pˇr´ıjmen´ı

Vˇsechny záznamy mimo atributu mail

Tab. 3.4: Vyhledávac´ı filtry LDAP

- 33 -

Karel Ben´ ak


Jednotlivé filtry (tab. 3.4, strana 32.) lze mezi sebou vhodnˇe kombinovat, jak je vidˇet napˇr. na obr. 3.32, strana 32., a t´ım pokládat fundovanˇejˇs´ı dotazy. $ ldapsearch (&(|(givenName=Josef)(givenName=Jiˇ r´ ı))(sn=Nov´ ak)) Obr. 3.32: Kombinace vyhledávac´ıch filtr˚ u V´ ysledkem tohoto dotazu jsou záznamy vˇsech Josef˚ u nebo Jiˇr´ı Nov´ ak˚ u, které operace search v adres´ aˇri nalezla. Bohuˇzel nen´ı moˇzné klást komplikované dotazy, které by prohledávaly a spojovaly jednotlivé záznamy dohromady, pˇr´ıpadnˇe prov´ adˇely nad tˇemito daty nˇekteré operace (SUM, AVG apod.), jako je tomu v pˇr´ıpadˇe jazyka SQL. Jako atribut˚ u pro vyhledáván´ı lze pouˇz´ıt nejen atributy obsaˇzené v záznamu, ale i speciáln´ı atributy (rootDSE), pomoc´ı kter´ ych pˇred´ av´ a LDAP server informace napˇr. o podporovan´ ych autentizaˇcn´ıch mechanismech apod. Seznam atribut˚ u pro navr´ acen´ı – V tomto posledn´ım parametru lze vyjmenovat atributy, které jsou poˇzadovány. Napˇr. pˇri vytváˇren´ı statick´ ych arp z´ aznam˚ u jsou d˚ uleˇzité pouze u ´daje o IP adrese (atribut ipHostNumber) a HW adrese s´ıt’ové karty (atribut macAddress). ldapsearch -b "ou=Pocitace,dc=sin,dc=cvut,dc=cz" \ > ipHostNumber macAddress Obr. 3.33: V´ ypis konkrétn´ıch atribut˚ u

Operace compare slouˇz´ı pro testován´ı hodnoty atributu s hodnotami uloˇzen´ ymi v záznamu. Jako vstupn´ı parametry je pouˇzito DN záznamu na kterém se hodnoty atribut˚ u testuj´ı a seznam atribut˚ u 6 a jejich hodnot . Funkce pak vrac´ı v pˇr´ıpadˇe u ´spˇechu hodnotu TRUE, v pˇr´ıpadˇe ne´ uspˇechu hodnotu FALSE. Pˇr´ıkladem pouˇzit´ı m˚ uˇze b´ yt napˇr. porovn´ an´ı otisku digitáln´ıho certifikátu s hodnotou uvedenou v adresáˇrovém serveru, nebo jednoduch´ y pˇr´ıklad na obr. 3.34, strana 33. ldapcompare "employeeNumber=88592,ou=Clenove,dc=sin,dc=cvut,dc=cz" \ > givenName:Karel TRUE Obr. 3.34: Operace compare Pˇr´ıkaz compare je v protokolu LDAP pouˇz´ıv´ an vˇetˇsinou z d˚ uvodu vazby na protokol X.500, ale pˇresto má své opodstatnˇen´ı a nelze jej plnˇe nahradit operac´ı search. Pˇr´ıkaz search vrát´ı vˇsechny nalezené atributy a v pˇr´ıpadˇe hledán´ı jednoho jediného atributu je tˇreba pˇrenést nˇekolik byt˚ u dat, ve kter´ ych bude obsaˇzeno DN hledaného záznamu, seznam atribut˚ u a jejich 6

Vyj´ adˇrené ve form´ atu prostého textu nebo zaˇsifrované pomoc´ı base64

- 34 -

Karel Ben´ ak


hodnot. Pˇr´ıkaz compare pˇrenese jako sv˚ uj v´ ysledek pouze logickou hodnotu true nebo false návratového kódu v´ ysledku operace.

3.4.2

Aktualizaˇ cn´ı operace LDAP

LDAP má ˇctyˇri aktualizaˇcn´ı operace: add (pˇrid´ an´ı), delete (smazán´ı), rename (zmˇena DN) a modify (zmˇena u ´daj˚ u). Tyto operace se doporuˇcuje prov´ adˇet pomoc´ı LDIF soubor˚ u (kapitola 3.6, strana 39) pˇr´ıpadnˇe vhodného editoru. Prov´ adˇen´ı zmˇen pomoci program˚ u ldapadd, ldapdelete, ldapmodify a ldapmodrdn s pˇr´ım´ ym zápisem atribut˚ u, jejich hodnot a poˇzadovan´ ych zmˇen se nedoporuˇcuje. LDIF soubor je moˇzné si po sobˇe nˇekolikr´ at zkontrolovat, neˇz se provede nˇejaká zmˇena, pˇr´ıpadnˇe lze vystopovat, jaká zmˇena mˇela b´ yt provedena. Pˇri pˇr´ımém pouˇzit´ı je vysoká pravdˇepodobnost, ˇze se nepodaˇr´ı tuto zmˇenu dohledat. Operace add pˇridá záznam do adresáˇrového stromu. Má dva parametry: DN záznamu a mnoˇzinu atribut˚ u a jejich hodnot. Operace pˇridán´ı se povede pouze za pˇredpokladu splnˇen´ı následuj´ıc´ıch pˇredpoklad˚ u: • Rodiˇc záznamu mus´ı jiˇz v adresáˇrovém stromu existovat • V této ˇcásti adresáˇre nesm´ı jiˇz stejn´ y záznam existovat • Záznam mus´ı odpov´ıdat a splˇ novat poˇzadavky schémat, ze kter´ ych se sklád´ a • Pˇr´ıstupová práva mus´ı tuto operaci umoˇznit V pˇr´ıpadˇe splnˇen´ı vˇsech tˇechto poˇzadavk˚ u bude nov´ y záznam do DIT pˇrid´ an. Operace delete smaˇze záznam z adresáˇre. Má jedin´ y parametr, DN záznamu kter´ y se má smazat. Operace smazán´ı se povede pouze v pˇr´ıpadˇe, ˇze jsou splnˇeny následuj´ıc´ı pˇredpoklady: • Záznam pro smazán´ı mus´ı existovat • Záznam nesm´ı m´ıt ˇzádného potomka, ty musej´ı b´ yt smazány pˇred smazán´ım vlastn´ıho záznamu • Pˇr´ıstupová práva mus´ı tuto operaci umoˇznit V pˇr´ıpadˇe splnˇen´ı vˇsech tˇechto poˇzadavk˚ u bude záznam z DIT smazán. Operace rename slouˇz´ı k pˇrejmenován´ı RDN a pˇresunu záznamu mezi vˇetvemi adresáˇrového stromu. Operace pˇrejmenován´ı se povede pouze v pˇr´ıpadˇe, ˇze jsou splnˇeny následuj´ıc´ı pˇredpoklady: • Záznam pro smazán´ı mus´ı existovat • Nové DN záznamu nesm´ı b´ yt shodné s jiˇz existuj´ıc´ım DN jiného záznamu • Pˇr´ıstupová práva mus´ı tuto operaci umoˇznit - 35 -

Karel Ben´ ak

3.5 Bezpeˇ cnostn´ı model

Operace modify slouˇz´ı ke zmˇenˇe hodnot atribut˚ u v záznamech. Operace modifikace se povede pouze v pˇr´ıpadˇe, ˇze jsou splnˇeny následuj´ıc´ı pˇredpoklady: • Záznam pro modifikaci mus´ı existovat • Vˇsechny modifikace atribut˚ u mus´ı skonˇcit u ´spˇechem • Modifikace mus´ı splˇ novat poˇzadavky, které na nˇe schemata kladou (povinné atributy, správné datové typy apod.) • Pˇr´ıstupová práva mus´ı tuto operaci umoˇznit

3.4.3

Autentizaˇ cn´ı a ˇ r´ıd´ıc´ı operace

LDAP má dvˇe autentizaˇcn´ı operace (bind a unbind) a jednu ˇr´ıd´ıc´ı operaci (abandon). Operace bind Slouˇz´ı pro ovˇeˇren´ı identity uˇzivatele (autentizace), kter´ y k adresáˇrové sluˇzbˇe pˇristupuje. Po proveden´ı autentizace se provede autorizace a uˇzivateli je dovoleno pracovat s daty v závislosti na jeho pˇr´ıstupov´ ych právech. V´ıce o autentizaci v kapitole 3.5.1 Autentizace, strana 36. Operace unbind oznamuje serveru, ˇze klient s n´ım hodlá ukonˇcit komunikaci. Operace abandon adresáˇrovému serveru oznám´ı, ˇze klient chce ukonˇcit komunikaci. Vyuˇzije se napˇr. v situaci, kdy server vyhledává velké mnoˇzstv´ı záznam˚ u v rozsáhlém stromu a uˇzivatel chce toto vyhledáván´ı náhle pˇreruˇsit. Jako vstupn´ı parametr pouˇz´ıv´ a ˇc´ıseln´ y identifik´ ator operace, kterou má LDAP server pˇreruˇsit.

3.5

Bezpeˇ cnostn´ı model

Bezpeˇcnostn´ı model zajiˇst’uje zabezpeˇcen´ı pˇr´ıstupu k záznam˚ um uloˇzen´ ych v adresáˇrovém serveru podle urˇcit´ ych, pˇredem stanoven´ ych pravidel pˇred neˇz´ adouc´ımi osobami. Sklád´ a se ze tˇr´ı ˇcást´ı: Autentizace Pˇ r´ıstupov´ a pr´ ava TLS/SSL

- 36 -

Karel Ben´ ak

3.5.1


Autentizace

Autentizace slouˇz´ı k ovˇeˇren´ı identity uˇzivatele. Server tak má moˇznost pomoc´ı nˇekterého z autentizaˇcn´ıch mechanism˚ u ovˇeˇrit, zda osoba, která se vydáv´ a za konkrétn´ıho uˇzivatele, splˇ nuje pˇredepsané autentizaˇcn´ı podm´ınky. Ve vˇetˇsinˇe pˇr´ıpad˚ u se tak dˇeje na základˇe znalosti pˇrihlaˇsovac´ıho jména a hesla uˇzivatele, digitáln´ıho certifikátu nebo u velmi sloˇzit´ ych systém˚ u napˇr. podle biometrick´ ych znak˚ u (duhovka oka, otisk prstu apod). Autentizace m˚ uˇze b´ yt bud’ jednocestná, nebo dvojcestná. Pˇri jednocestné autentizaci klient zas´ılá heslo adresáˇrovému serveru pˇri tzv. bind operaci, nebo kdyˇz adresáˇrov´ y server zas´ılá sv˚ uj certifikát klientu bˇehem navazov´ ani chr´ anˇeného spojen´ı a t´ım se ovˇeˇruje pˇr´ımo u adresáˇrového serveru pomoc´ı svého X.509 certifikátu. Pˇr´ıkladem dvojcestné autentizace je situace, kdy si adresáˇrov´ y klient a server vymˇen ˇuj´ı bˇehem vyjednáv´ an´ı TSL spojen´ı své certifikáty a teprve poté dojde k ovˇeˇren´ı uˇzivatele. Anonymn´ı autentizace pˇri operaci bind se serveru nezas´ılaj´ı ˇz´ adné identifikaˇcn´ı u ´daje o uˇzivateli a jeho pˇr´ıstupov´ ych právech. Pˇri pouˇz´ıv´ an´ı anonymn´ı autetizace se doporuˇcuje nastavit pˇr´ıstupová práva pouze k vybran´ ym informac´ım. Jednoduch´ a autentizace – po nechr´ anˇeném spojen´ı protokolem LDAP se pˇri operaci bind zaˇsle identifikace uˇzivatele pomoc´ı jeho DN a hesla. Heslo by mˇelo b´ yt na stranˇe serveru uloˇzeno v zaˇsifrované nebo hashované formˇe pomoc´ı algoritm˚ u crypto7 , MD5 nebo SHA1. ldapsearch -h ldap -b "dc=sin,dc=cvut,dc=cz" \ > -D "uid=uzivatel,ou=lide,dc=sin,dc=cvut,dc=cz" -w mojeheslo Obr. 3.35: Jednoduch´ a autentizace

Jednoduch´ a autentizace pˇ res bezpeˇ cn´ y kan´ al – pouˇzit stejn´ y princip jako u jednoduché autentizace uˇzivatele pomoc´ı jména a hesla, ale v tomto pˇr´ıpadˇe je pˇri spojen´ı a zas´ıl´ an´ı dat pouˇzit bezpeˇcn´ y kanál TLS/SSL. Jedná se o dvojcestnou autentizaci, zm´ınˇenou vu ´vodu. Pˇred vlastn´ı autentizac´ı uˇzivatele si klient a server vymˇen´ı informace o sv´ ych X.509 certifikátech a naváˇzou spojen´ı pˇres bezpeˇcn´ y TLS/SSL kan´ al. Po jeho nav´ az´ an´ı pak docház´ı k operaci bind, ve které je zasláno DN uˇzivatele, kter´ y se autentizuje, a jeho heslo. Proxy autentizace – pˇri tomto druhu autentizace obsaˇzeném v LDAPv3 je vyuˇzito toho, ˇze jist´ y uˇzivatel má moˇznost nahl´ıˇzet na hesla ostatn´ıch uˇzivatel˚ u, a tak m˚ uˇze ovˇeˇrit, zda uˇzivatel, kter´ y se pˇrihlaˇsuje, zná skuteˇcnˇe své uˇzivatelské jméno a heslo a má pˇr´ısluˇsn´ a práva. K serveru se tedy ”binduje” proxy uˇzivatel, kter´ y provede ovˇeˇren´ı uˇzivatele napˇr. pomoc´ı operace compare. PKI autentizace je zaloˇzena na principu digitáln´ıch PKI certifik´ at˚ u [X.509] (viz. [Dostalek]). Tento druh autentizace ovládaj´ı jen nˇekteré LDAP servery a klienti. Certifikát mus´ı odpov´ıdat struktuˇre adresáˇrového stromu a je uloˇzen v atributu userCertificate. Klient si pˇri spojen´ı vybere konkrétn´ı certifikát ve své kl´ıˇcence, kter´ ym se chce v˚ uˇci serveru ovˇeˇrit a pˇri jeho pouˇzit´ı je nucen pouˇz´ıt heslo. Server zkontroluje, souhlas´ı-li uˇzivatelsk´ y 7

Nedoporuˇcuje se pouˇz´ıvat

- 37 -

Karel Ben´ ak


certifikát s certifikátem uloˇzen´ ym v serveru. Pokud ano, uˇzivatel je ovˇeˇren. Tento zp˚ usob je nároˇcn´ y jak pro uˇzivatele, tak pro administrátora, protoˇze mus´ı své digitáln´ı certifikáty stále hl´ıdat a v pˇr´ıpadˇe potˇreby aktualizovat. LDAP server m˚ uˇze b´ yt propojen

Obr. 3.36: PKI autentizace

Obr. 3.37: Systém PKI s OCSP (On-Line Certificate Status Protocol) serverem, zajiˇst’uj´ıc´ım on-line aktualizace informac´ı o digitáln´ıch certifikátech. SASL mechanismus (Simple Authentication and Security Layer ) [RFC 2222] umoˇzn ˇuje pouˇzit´ı sv´ ych modul˚ u (PLAIN, LOGIN, GSSAPI, NTLM, OTP, CRAM-MD5, DIGEST-MD5, SRP, pˇr´ıpadnˇe dalˇs´ı moduly) pro autentizaci uˇzivatele. Autentizaˇcn´ı mechanismy PLAIN a LOGIN neobsahuj´ı ˇzádné bezpeˇcnostn´ı mechanismy, proto je pˇri pˇrihl´ aˇsen´ı k LDAP serveru vhodné doplnit pˇrenos jména a hesla vrstvou TLS. Pokud je nutné pouˇz´ıt nezabezpeˇcenou variantu pˇrenosu dn uˇzivatele a jeho hesla, doporuˇcuje se pouˇzit´ı mechanismu DIGEST-MD5. Praktick´ ym pˇr´ıkladem pouˇzit´ı SASL a LDAP je napˇr. ovˇeˇren´ı existence uˇzivatele SMTP serveru pro pˇrepos´ılán´ı e-mailu uˇzivatel˚ u zdrˇzuj´ıch se mimo vnitˇrn´ı s´ıt’ pomoc´ı mechanismu SMTP-AUTH. - 38 -

Karel Ben´ ak


Obr. 3.38: SASL mechanismus

3.5.2

Pˇ r´ıstupov´ a pr´ ava

Pˇr´ıstupov´ a práva v adresáˇrov´ ych sluˇzb´ ach mohou b´ yt na rozd´ıl od relaˇcn´ıch databáz´ı nastavena aˇz do u ´rovnˇe záznam˚ u. Bohuˇzel zat´ım neexistuje oficiáln´ı standard kter´ y by pˇresnˇe definoval model tˇechto práv, resp. existuj´ı pouze ve stadiu RFC draft˚ u8 , proto se jejich implementace bude produkt od produktu liˇsit. Ve vˇetˇsinˇe produkt˚ u jsou k dispozici tzv. Access Control Lists, zkratka ACL, které specifikuj´ı, jak´ ym zp˚ usobem je moˇzné k záznam˚ um a pˇredevˇs´ım atribut˚ um pˇristupovat. Netscape Directory server a jeho nástupce [JES] pouˇz´ıvaj´ı jako doplnˇek k ACL tzv. Access Control Information, zkratka ACI, které jejich moˇznosti dále rozˇsiˇruj´ı na omezen´ı typu: odkud dan´ y dotaz vzeˇsel, jak´ ym protokolem vzeˇsel apod. ACI zaˇc´ın´ a v experiment´ aln´ı podobˇe pouˇz´ıvat i obl´ıben´ y projekt [OpenLDAP] a nejsp´ıˇs se v dohledné dobˇe stane souˇc´ ast´ı nˇekterého ze standard˚ u RFC.

3.5.3

SSL/TLS

V bezpeˇcnostn´ım modelu se pro ochranu komunikace proti neˇz´ adouc´ımu odposlechu vyuˇz´ıv´ a moˇznosti vrstev TLS (Transport Security Layer ) nebo SSL (Socket Security Layer – starˇs´ı protokol). Standardn´ı protokol LDAP vyuˇz´ıv´ a port 389, zat´ımco protokol LDAPS chr´ anˇen´ y vrstvou SSL vyuˇz´ıvá port 636. Bezpeˇcnostn´ı model vyuˇz´ıvaj´ıc´ı protokol TLS podle [RFC 2830] má vˇsak jeˇstˇe lepˇs´ı moˇznosti pˇredevˇs´ım v tom, ˇze vyuˇz´ıv´ a standardn´ı LDAP port 389 a server s klientem se pˇri navazován´ı spojen´ı teprve dohodnou, budou-li spojen´ı chr´ anit, ˇci nikoliv. Pokud se dohodnou na chránˇeném spojen´ı, pouˇzij´ı k tomu vol´ an´ı funkce StartTLS. Zat´ımco pˇri nechránˇeném pˇrenosu dat protokolem LDAP m˚ uˇze pˇr´ıpadn´ y u ´toˇcn´ık odposlechnout komunikaci mezi serverem a klientem a z´ıskat tak velmi citlivé u ´daje napˇr. o pˇrihlaˇsovac´ım DN a jeho hesle pro operaci bind, pˇri komunikaci pˇres protokol chr´ anˇen´ y vrstvou TLS nebo SSL je pˇrenos dat zabezpeˇcen´ y proti odposlechu, resp. proti rozkódován´ı této komunikace. K tomu by musel m´ıt u ´toˇcn´ık privátn´ı kl´ıˇc klienta nebo serveru. Pˇri této komunikaci je nutné, aby se server, pˇr´ıpadnˇe i klient, prokazovaly platn´ ym [X.509] certifikátem podepsan´ ym nˇekterou z certifikaˇcn´ıch autorit. 8

draft-ietf-ldapext-acl-model, draft-legg-ldap-acm-admin, draft-legg-ldap-acm-bac

- 39 -

Karel Ben´ ak

3.6 LDIF

Chránˇené spojen´ı je vhodné pˇredevˇs´ım pˇri pˇrenosu dat mezi klientem a serverem, mezi kter´ ymi je ned˚ uvˇeryhodné prostˇred´ı, napˇr. Internet. Pˇr´ıklad pouˇzit´ı zobrazuje obr. 3.39, strana 39.

Obr. 3.39: Bezpeˇcné spojen´ı pˇres ned˚ uvˇeryhodné prostˇred´ı

Klienti, kteˇr´ı se k serveru pˇripojuj´ı pˇres TLS vrstvu, maj´ı následuj´ıc´ı v´ yhody: • Komunikace je chránˇena proti odposlechu • Komunikace je chránˇena proti u ´toku typu ”muˇz uprostˇred” • Klient se m˚ uˇze v˚ uˇci serveru autentizovat pouˇzit´ım PKI • M˚ uˇze si ovˇeˇrit platnost certifikátu, kter´ y server poskytuje Bezpeˇcné a autentizované spojen´ı mezi klientem a serverem m˚ uˇze vypadat následovnˇe: • Otevˇren´ı TCP/IP spojen´ı se serverem • Operace StartTLS • Operace bind za pouˇzit´ı extern´ıho mechanismu SASL, pˇr´ıpadnˇe jiného SASL mechanismu (DIGEST-MD5)

3.6

LDIF

LDAP Data Interchange Format je standardn´ı textov´ y formát pro popisov´ an´ı adresáˇrov´ ych záznam˚ u, definovan´ y v [RFC 2849]. LDIF umoˇzn ˇuje snadn´ y import a export mezi r˚ uzn´ ymi adresáˇrov´ ymi servery, které pouˇz´ıvaj´ı rozd´ılné intern´ı databázové formáty. Textové formáty jsou mezi systémov´ ymi administrátory velmi obl´ıbené pˇredevˇs´ım pro svou pˇrehlednost a snadnou editovatelnost. Za normáln´ıch okolnost´ı je LDIF soubor psán v kódové stránce ASCII, pokud je ale tˇreba pouˇz´ıt diakritiku, pouˇz´ıvá se pro ni standardn´ı kódov´ a stránka UTF-8. Data, která nelze vyjádˇrit jako ASCII nebo UTF-8 jsou kódov´ ana pomoc´ı base64. T´ımto zp˚ usobem lze v LDIF formátu uloˇzit napˇr. fotografii, digitáln´ı certifikát apod. V posledn´ı dobˇe docház´ı k nástupu r˚ uzn´ ych textov´ ych formát˚ u zaloˇzen´ ych na technologii XML. Adresáˇrové sluˇzby se tomuto trendu nevyh´ ybaj´ı, proto byl vytvoˇren formát DSML - 40 -

Karel Ben´ ak

3.6 LDIF

dn: employeeNumber=95882,ou=Clenove,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: person objectclass: organizationalPerson objectclass: inetOrgPerson objectclass: kskPerson cn: Karel Ben´ ak sn: Ben´ ak givenName: Karel employeeNumber: 95882 employeeType: admin Obr. 3.40: Typick´ y LDIF soubor (Directory Services Markup Language), v aktuáln´ı verzi DSMLv2. Tento protokol je schopen pˇrenosu pomoc´ı protokolu HTTP a následného zpracov´ an´ı pomoc´ı protokol˚ u HTTP/SOAP. Tato vlastnost m˚ uˇze napomoci napˇr. pˇri zabezpeˇcen´ı dat pˇri pˇrenosu v poˇc´ıtaˇcové s´ıti. Aˇckoliv i protokol LDAP má svou zabezpeˇcenou variantu (protokol LDAPS nebo vrstvu TLS ), je moˇzné pouˇz´ıt pro chránˇen´ y pˇrenos protokolu https. Z obrázku obr. 3.41, strana 41. je patrné, ˇze v modern´ıch aplikac´ıch (postaven´ ych pˇrev´ aˇznˇe na www technologi´ıch a standardech) programovan´ ych jazyky Java nebo C# m´ a DSMLv2 ˇsiroké uplatnˇen´ı. Formáty zaloˇzené na XML jsou pro souˇcasné aplikace snáze zpracovatelné a ˇcitelnˇejˇs´ı, narozd´ıl od klasick´ ych textov´ ych nebo binárn´ıch formát˚ u, jak´ ym je jiˇz zmiˇ novan´ y LDIF. Pˇri programován´ı aplikac´ı zaloˇzen´ ych na XML se ve velké m´ıˇre vyuˇz´ıv´ a jiˇz hotov´ ych ˇreˇsen´ı a aplikace sama pak nemus´ı umˇet pracovat s LDAP protokolem a pˇresto m˚ uˇze klást dotazy a z´ıskávat odpovˇedi pomoc´ı protokolu HTTP/SOAP.

- 41 -

Karel Ben´ ak

3.6 LDIF

top person organizationalPerson inetOrgPerson kskPerson Karel Ben´ ak Ben´ ak Karel 95882 admin Obr. 3.41: Záznam ve formátu DSMLv2

- 42 -

Karel Ben´ ak

3.7

3.7 Topologie

Topologie

Topologie se zab´ yvá pˇredevˇs´ım rozdˇelen´ım adresáˇrového stromu mezi v´ıce server˚ u. Nejˇcasteji se navrhuje podle geografického rozm´ıstˇen´ı poboˇcek, server˚ u a klient˚ u. Ve své podstatˇe kop´ıruje fyzickou topologii s´ıtˇe a mˇela by velmi u ´zce souviset s návrhem jmenn´ ych prostor˚ u a replikac´ı. Jedn´ım z nejˇcastˇejˇs´ıch d˚ uvod˚ u rozdˇelen´ı DITu na nˇekolik ˇc´ ast´ı je pˇredevˇs´ım potˇreba spravovat a ukládat konkrétn´ı ˇcást stromu na konkrétn´ı poboˇcce, zat´ımco ostatn´ı poboˇcky lokáln´ıho administrátora a lokáln´ı uˇzivatele nezaj´ımaj´ı. Pokud by napˇr. Skanska CZ byla zaˇ edsku, nezaj´ımalo by správce pojena do adresáˇrového stromu své mateˇrské spoleˇcnosti ve Sv´ ˇceské poboˇcky nastaven´ı norské vˇetve. Zárovˇen ˇ by ˇsetˇril m´ısto na disku (disc´ıch) pro lokáln´ı záznamy, které poboˇcka potˇrebuje ke svému bˇehu, zat´ımco norské záznamy by v ˇceské poboˇcce zbyteˇcnˇe zab´ıraly volné m´ısto. Správn´ y návrh mus´ı respektovat pˇredevˇs´ım potˇrebu dostupnosti dat pro kaˇzdého klienta. Topologie s´ıtˇe a adresáˇrov´ ych sluˇzeb ji mus´ı zajistit bez jak´ ychkoliv problém˚ u ve stanoveném ˇcase. Je samozˇrejmˇe v´ yhodné pouˇz´ıt replikac´ı, ty ovˇsem neˇreˇs´ı problémy spjaté se správou a pˇrenosem dat pˇredevˇs´ım po pomal´ ych linkách typu WAN. Pokud se napˇr. klient v praˇzské poboˇcce mus´ı autentizovat na stockholmské centr´ ale, m˚ uˇze v´ ysledek trvat nepˇrimˇeˇrenˇe dlouho a ostatn´ı sluˇzby (napˇr. Kerberos) mohou klienta oznaˇcit jako ned˚ uvˇeryhodného a znemoˇznit mu práci. Rovnˇeˇz jakékoliv ˇcekán´ı na odezvu server˚ u a aplikac´ı je nepˇr´ıjemné a pro bˇeˇzného uˇzivatele neakceptovatelné. Nav´ıc t´ım stoupá provoz po linkách poskytovatele, kter´ y si m˚ uˇze u ´ˇctovat cenu za poˇcet pˇrenesen´ ych dat nebo za dobu pˇripojen´ı. Pokud by napˇr´ıklad Skanska pouˇz´ıvala adresáˇrové sluˇzby ve vˇsech sv´ ych poboˇck´ ach a mˇela je zorganizovány v navazuj´ıc´ıch stromech, mohl by pˇri respektov´ an´ı geografického rozm´ıstˇen´ı poboˇcek vypadat DIT jako napˇr. na obrázku 3.42. Obrázek samozˇrejmˇe nepostihuje vˇsechny mezinárodn´ı poboˇcky Skansky, pouze se zab´ yv´ a jej´ımi evropsk´ ymi poboˇckami. Pro ilustraci je ale v´ıce neˇz dostaˇcuj´ıc´ı.

Obr. 3.42: Topologie Skansky podle poboˇcek ˇ edsku, kde je V poˇzadavku by mohlo b´ yt ˇreˇceno, ˇze koˇren DITu zaˇc´ın´ a v centr´ ale ve Sv´ rovnˇeˇz um´ıstˇena pˇr´ısluˇsná vˇetev. Dále se v centr´ ale spravuje celá evropská vˇetev a pˇr´ısluˇsné vˇetve rozdˇeluj´ıc´ı Evropu na regiony West, North a Middle. Vˇetev America a k n´ı pˇr´ısluˇsej´ıc´ı vˇetve North America a Latin America se spravuj´ı v poboˇcce ve Spojen´ ych státech, Vˇetev Asia se spravuje v poboˇcce v Hong Kongu. Adresáˇrov´ y strom by mˇel tedy sv˚ uj koˇren v dc=skanska,dc=com, kter´ y je um´ıstˇen´ y ˇ v centrále ve Svédsku. To znaméná, ˇze prefix dc=skanska,dc=com a vˇetev ou=Sweden,ou=North Europe,ou=Europe,dc=skanska,dc=com jsou um´ıstˇeny na centr´ aln´ım serveru. Na nˇem jsou rovnˇeˇz um´ıstˇeny vˇetve : - 43 -

Karel Ben´ ak

3.7 Topologie

ou=America,dc=skanska,dc=com ou=Asia,dc=skanska,dc=com ou=Europe,dc=skanska,dc=com ou=West Europe,ou=Europe,dc=skanska,dc=com ou=UK,ou=West Europe,ou=Europe,dc=skanska,dc=com ou=North Europe,ou=Europe,dc=skanska,dc=com ou=OY,ou=West Europe,ou=Europe,dc=skanska,dc=com ou=Denmark,ou=West Europe,ou=Europe,dc=skanska,dc=com ou=Norway,ou=West Europe,ou=Europe,dc=skanska,dc=com ou=Middle Europe,ou=Europe,dc=skanska,dc=com ou=Czech,ou=West Europe,ou=Europe,dc=skanska,dc=com ou=Poland,ou=West Europe,ou=Europe,dc=skanska,dc=com Z tˇechto vˇetv´ı pak vedou odkazy pomoc´ı referenc´ı na pˇr´ısluˇsné poboˇckové servery v jednotliv´ ych zem´ıch. Jelikoˇz nemá spoleˇcnost Skanska podobné ˇreˇsen´ı, mohla by Skanska CZ pouˇz´ıvat rozdˇelen´ı svého DIT na adresáˇrové servery podle obrázku 3.43. Skanska CZ vˇsak m´ısto tohoto ˇreˇsen´ı

Obr. 3.43: Topologie Skansky podle m´ısta pracoviˇstˇe pouˇz´ıvá replikac´ı, které jsou pro zajiˇstˇen´ı provozu dostaˇcuj´ıc´ı.

- 44 -

Karel Ben´ ak

4.1 Adres´ aˇrov´ e servery

Kapitola 4

Software pro adres´ aˇ rov´ e sluˇ zby Ve svˇetˇe otevˇreného software je jen málo v´ yznamn´ ych projekt˚ u, které jsou schopny s adresáˇrov´ ymi sluˇzbami pracovat. Naopak velké softwarové firmy se snaˇz´ı tuto technologii ve sv´ ych produktech prosazovat, pˇr´ıkladem m˚ uˇze b´ yt Microsoft Active Directory a jeho v´ yteˇcn´ a provázanost se systémem, nebo Java Enterprise System, kter´ y v sobˇe integruje.

4.1

Adres´ aˇ rov´ e servery

Adresáˇrov´ ych server˚ u je k dispozici celá ˇrada. V rámci OpenSource software jsou k dispozici servery OpenLDAP (4.1.1) a TinyLDAP (4.1.2). Pro podnikovou sféru, kde záleˇz´ı na 100 % pˇr´ıstupnosti k dat˚ um nutné podpoˇre ze strany dodavatele, lze zvolit nˇekter´ y z komerˇcn´ıch produkt˚ u. U adresáˇrov´ ych server˚ u by se nemˇel nakupovat pouze vlastn´ı adresáˇrov´ y server, ale celé ˇreˇsen´ı, které by mˇelo obsahovat i dalˇs´ı komponenty, napˇr. PKI, návaznost na operaˇcn´ı systém a jeho sluˇzby, identity server ad. Podle m´ ych zkuˇsenost´ı tyto poˇzadavky splˇ nuj´ı produkty Java Enterprise System Directory server (strana 45.) od Sun Microsystems, Active Directory (strana 45.) od Microsoft Corporation obsaˇzen´ y napˇr. v MS Windows Server 2003, Tivoli od IBM a Novell E-Directory od Novell.

4.1.1

OpenLDAP

OpenLDAP je vyv´ıjen´ y pro r˚ uzné operaˇcn´ı systémy, jak´ ymi jsou napˇr. Linux, FreeBSD, Solaris apod. Nen´ı nijak hardwarovˇe nároˇcn´ y. Ve standardn´ı instalaci podporuje SSL/TLS, Kerberos a mechanismy SASL, obsaˇzené v LDAPv3. Podporu TLS je moˇzné dodat pomoc´ı knihoven OpenSSL [OpenSSL] nebo GNU TLS [GNU TLS], podporu protokolu Kerberos je moˇzné z´ıskat z knihoven projektu [MIT Kerberos] nebo [Heimdal] a protokol SASL z projektu [Cyrus SASL]. Pokud nejsou na adresáˇrov´ y server kladeny velké nároky na rychlost a dodavatel systému nebo aplikace je schopen sestavit a poskytovat pro OpenLDAP podporu, je [OpenLDAP] vhodn´ ym ˇreˇsen´ım. Sami v´ yvojáˇri OpenLDAPu pˇripouˇstˇej´ı, ˇze jejich adresáˇrov´ y server nen´ı tak rychl´ y, jako ostatn´ı, pˇredevˇs´ım komerˇcn´ı implementace. Paradoxnˇe b´ yv´ a OpenLDAP pomˇernˇe ˇ ˇcasto nasazován. Pˇr´ıkladem m˚ uˇze b´ yt Fakulta stavebn´ı CVUT v Praze a jej´ı systém ELDAP.

- 45 -

Karel Ben´ ak

4.1.2

4.2 Prohl´ıˇ zeˇ ce a editory

TinyLDAP

TinyLDAP je mal´ y ale velmi rychl´ y adresáˇrov´ y server, kter´ y data uklád´ a do klasick´ ych textov´ ych soubor˚ u. Z protokolu LDAP ovl´ ad´ a pouze nejzákladnˇejˇs´ı ˇc´ asti a napˇr. replikace nemá v˚ ubec vyˇreˇseny.

4.1.3

Sun Java Enterprise Directory Server

P˚ uvodˇe se jedná o Netscape Directory Server, posléze pˇrevzat´ y spoleˇcnost´ı iPlanet a nyn´ı je souˇcást´ı projektu Java Enterprise System, produkovaného spoleˇcnost´ı Sun Microsystems. Implementuje pokroˇcilé moˇznosti LDAPv3 a je nasazen napˇr´ıklad pro autentizaci uˇzivatel˚ u pro pˇr´ıstup k bankovn´ımu systému www.mojebanka.cz. Tento adresáˇrov´ y systém lze za urˇcit´ ych podm´ınek vyzkouˇset zcela zdarma.

4.1.4

Microsoft Active Directory

Active Directory (AD) je typick´ ym pˇr´ıkladem NOS. Nen´ı to typick´ y LDAP server, aˇckoliv je schopen pomoc´ı tohoto protokolu komunikovat. V AD je integrov´ an LDAP, Kerberos, SMB/CIF server a dalˇs´ı ˇcásti. AD lze v s´ıti Microsoft Windows integrovat s DHCP serverem, DNS serverem, tiskov´ ym serverem a dalˇs´ımi sluˇzbami. V´ ybornou vlastnost´ı tohoto produktu je u ´zká vazba na PKI, takˇze se uˇzivatel m˚ uˇze velmi snadno prokazovat sv´ ymi digitáln´ımi certifikáty. Provázanost jednotliv´ ych komponent Windows Serveru 2003 s AD je podle mého názoru velk´ ym trumfem proti ostatn´ım serverov´ ym systém˚ um, nehledˇe na produkty vytváˇrené v rámci Open Source software.

4.2

Prohl´ıˇ zeˇ ce a editory

GQ GQ je podle mého názoru jedn´ım z nejlepˇs´ıch klient˚ u pro prohl´ıˇzen´ı a editaci záznam˚ u v LDAP adreáˇri, kter´ y je pod operaˇcn´ımi systémy typu UNIX k dispozici. Jako grafické prostˇred´ı pouˇz´ıvá knihovnu Gtk a jeho lokalizace do ˇceˇstiny je pomˇernˇe zdaˇril´ a. Poskytuje velmi ˇsiroké moˇznosti editace a vkládán´ı dat, stejnˇe tak i jejich prohledáv´ an´ı a prohl´ıˇzen´ı. K zaj´ımav´ ym vlastnostem patˇr´ı i moˇznost prohl´ıˇzen´ı schémat, atribut˚ u a datov´ ych typ˚ u. Klient umoˇzn ˇuje velmi dobˇre vkládat i binárn´ı záznamy (obrázky, zvuk) a digitáln´ı certifikáty uˇzivatel˚ u a server˚ u.

- 46 -

Karel Ben´ ak

4.2 Prohl´ıˇ zeˇ ce a editory

Obr. 4.1: GQ - 47 -

Karel Ben´ ak

4.3

4.3 V´ yvojov´ e prostˇredky

V´ yvojov´ e prostˇ redky

Pro v´ yvoj aplikac´ı spolupracuj´ıch s adresáˇrov´ ymi sluˇzbami existuj´ı r˚ uzné v´ yvojové prostˇredky (Software Developer kit - SDK) pro celou ˇradu programovac´ıch jazyk˚ u. Lze se setkat napˇr´ıklad s API, které poskytuj´ı v´ yvojáˇri projektu Mozilla, OpenLDAP, Java apod.

4.3.1

C/C++

Pˇri instalaci OpenLDAP je moˇzné zárovˇen instalovat i statické a dynamické knihovny (libldap.a, libldap r.a, liblber.a, libldap.so, libldap r.so, liblber.so) a hlaviˇckové soubory potˇrebné pro v´ yvoj aplikac´ı v programovac´ım jazyce C. OpenLDAP obsahuje i knihovnu a hlaviˇckové soubory pro práci s programovac´ım jazykem C++. Potˇrebné zdrojové soubory se nach´ azej´ı v adresáˇri contrib/ldapc++ a je nutné je ’ pˇreloˇzit zvláˇst . Pˇri standardn´ım pˇrekladu se nepˇrekl´ adaj´ı a nejsou ani souˇc´ ast´ı pˇreloˇzen´ ych v´ yvojov´ ych baliˇck˚ u. Pro vlastn´ı pˇreklad je tˇreba standardn´ı knihovny pro jazyk C a pro generován´ı dokumentace k API je nutné pouˇzit program doxygen [Doxygen]. Bez vygenerované dokumentace je obt´ıˇzné programovat a pˇr´ısluˇsné API je v n´ı velmi dobˇre popsáno.

4.3.2

Java

Programovac´ı jazyk Java poskytuje knihovnu tˇr´ıd JNDI (Java Naming and Directory Interface) urˇcenou pro práci se jmenn´ ymi a adresáˇrov´ ymi sluˇzbami. Pˇri v´ yvoji aplikac´ı je tˇreba m´ıt nainstalovanou SDK verzi Javy, pro bˇeh aplikac´ı postaˇc´ı JRE verze Javy. K dispozici je rovnˇeˇz pˇrehledn´ y a ˇciteln´ y návod [6], jak JNDI knihovnou programovat. Mezi dalˇs´ımi je od firmy Novell k dispozici knihovna JLDAP (Java LDAP) [JLDAP] a od firmy OctetString knihovna JDBC-LDAP (JDBC-LDAP Bridge Driver) [JDBC LDAP].

4.3.3

Perl

Pro skriptovac´ı jazyk Perl je moˇzné vyuˇz´ıt modul perl-ldap [Perl-LDAP], kter´ y lze stáhnout z kteréhokoliv CPAN archivu. Spolu s modulem je pˇriloˇzena i pˇrehledn´ a dokumentace, která je pˇri instalaci instalována jako tzv. POD. perl-ldap vyˇzaduje pˇred vlastn´ı instalac´ı pomˇernˇe mnoho doplˇ nkov´ ych bal´ıˇck˚ u. Je proto dobré se pˇresvˇedˇcit, zda Perl obsahuje správné knihovny (napˇr. pro práci se SSL, SASL, ASN1, Base64 apod.). Vˇsechny administraˇcn´ı skripty pro IS Sinkuleho koleje spolupracuj´ıc´ı s LDAP serverem jsou psány právˇe za pouˇzit´ı perl-ldap.

4.3.4

Python

Pro skriptovac´ı jazyk Python je moˇzné pouˇz´ıt Python-LDAP [Python-LDAP]. Jedná se o objektovˇe orientované API poskytuj´ıc´ı pˇr´ıstup aplikac´ım napsan´ ym v jazyce Python k adresáˇrov´ ym sluˇzbám, které poskytuje moˇznosti vyuˇzit´ı protokolu LDAPv3.

4.3.5

PHP

Skriptovac´ı jazyk PHP standardnˇe neobsahuje podporu LDAP, je ale moˇzné ji do tohoto jazyka pˇridat. Pro platformu windows je tˇreba povolit a doplnit v souboru php.ini cestu k pˇr´ısluˇsné sd´ılené knihovnˇe (ldap.dll). Pro operaˇcn´ı systémy typu UNIX je nutné pˇri kompilaci pouˇz´ıt sd´ılené knihovny libldap.so, libldap r.so, liblber.so nebo knihovny statické - 48 -

Karel Ben´ ak

4.3 V´ yvojov´ e prostˇredky

(libldap.a, libldap r.a, liblber.a). Pokud se instaluje PHP a zvláˇst’ rozˇs´ıˇren´ı o LDAP pomoc´ı pˇredkompilovan´ ych bal´ıˇck˚ u (napˇr. RPM), je nutné m´ıt nainstalov´ anu odpov´ıdaj´ıc´ı verzi LDAP knihovny, se kterou bylo PHP p˚ uvodnˇe kompilov´ ano.

4.3.6

ADSI

ADSI je proprietárn´ı objektovˇe orientované SDK od firmy Microsoft pro programovac´ı jazyky Visual Basic, C a C++. Primárnˇe je urˇcen´ y pro spolupráci s Microsoft Active Directory, ale je schopen pracovat i s jin´ ymi adresáˇrov´ ymi servery.

- 49 -

Karel Ben´ ak

5.2 Topologie

Kapitola 5

Anal´ yza a ˇ reˇ sen´ı ˇ c´ asti IS Klubu Sinkuleho koleje ˇ Klub Sinkuleho koleje je poˇc´ıtaˇcov´ y klub student˚ u CVUT spadaj´ıc´ı pod Studentskou Unii. ˇ Clenem klubu se m˚ uˇze stát kaˇzd´ y ubytovan´ y na koleji V. Sinkule v Zikovˇe ulici 13, Praze 6. Poˇc´ıtaˇcov´ y klub má pˇribliˇznˇe 250 ˇclen˚ u a jeho nápln´ı je poskytov´ an´ı kvalitn´ıch sluˇzeb a modern´ıch technologi´ı pro pˇrenos dat ˇclen˚ u. V souˇcasné dobˇe je prov´ adˇen pˇrechod na nov´ y informaˇcn´ı systém, jehoˇz souˇcást´ı budou i adresáˇrové sluˇzby. Mezi hlavn´ı poˇzadavky na nov´ y informaˇcn´ı systém patˇr´ı: • Evidence ˇclen˚ u a jejich poˇc´ıtaˇc˚ u • Evidence plateb ˇclen˚ u • Evidence majetku klubu a jeho záp˚ ujˇcek • Spolupráce se standardn´ımi internetov´ ymi sluˇzbami a protokoly Základn´ım zdrojem dat je relaˇcn´ı databáze PostgreSQL, ve které jsou uloˇzeny informace o uˇzivatel´ıch, jejich poˇc´ıtaˇc´ıch, platbách pˇr´ıspˇevk˚ u a jin´ ych poplatk˚ u, evidence majetku klubu a jeho záp˚ ujˇcek ˇclen˚ um klubu. Anal´ yza vlastn´ı relaˇcn´ı databáze nebude souˇc´ ast´ı této práce, bude v n´ı pouze ˇcást t´ ykaj´ıc´ı se adresáˇrov´ ych sluˇzeb a jejich návaznost na nˇekteré dalˇs´ı ˇc´ asti informaˇcn´ıho systému. Adresáˇrová sluˇzba bude pouˇzita pˇredevˇs´ım pro autentizaci uˇzivatel˚ u v˚ uˇci nˇekter´ ym sluˇzbám, napˇr. smtp, pop3, ssh apod.

5.1

SQL datab´ aze

Návrh relaˇcn´ı databáze na obr. 5.1, strana 50. nen´ı jeˇstˇe zcela dokonˇcen a je ve fázi pˇripom´ınkov´ an´ı. ˇ Jeho tv˚ urci jsou studenty CVUT Fakulty Elektrotechnické, Petr Macejko a Jiˇr´ı Zamazal. Ti jej navrhli v rámci semestráln´ı práce z pˇredmˇetu Jazyk SQL.

5.2

Topologie

Pokud by KSk byl souˇcást´ı SU ve které by se pouˇz´ıvalo adresáˇrov´ ych sluˇzeb, mˇel by kaˇzd´ y klub na svém centráln´ım serveru uloˇzenu vlastn´ı vˇetev adresáˇrového stromu a odkazy na dalˇs´ı vˇetve by se provádˇely pomoc´ı referenc´ı. Tyto jednotlivé vˇetve by mohly vypadat následovnˇe: - 50 -

Karel Ben´ ak

5.2 Topologie

Obr. 5.1: ER diagram databáze

- 51 -

Karel Ben´ ak

5.2 Topologie

dc=su,dc=cvut,dc=cz ou=buk,dc=su,dc=cvut,dc=cz ou=dik,dc=su,dc=cvut,dc=cz ou=dk,dc=su,dc=cvut,dc=cz ou=krestani,dc=su,dc=cvut,dc=cz ou=mk,dc=su,dc=cvut,dc=cz ou=pod,dc=su,dc=cvut,dc=cz ou=blok A,ou=sh,dc=su,dc=cvut,dc=cz ou=blok B,ou=sh,dc=su,dc=cvut,dc=cz ou=blok C,ou=sh,dc=su,dc=cvut,dc=cz ou=blok D,ou=sh,dc=su,dc=cvut,dc=cz ou=blok E,ou=sh,dc=su,dc=cvut,dc=cz ou=blok F,ou=sh,dc=su,dc=cvut,dc=cz ou=sh,dc=su,dc=cvut,dc=cz ou=blok 1,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 2,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 3,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 4,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 5,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 6,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 7,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 8,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 9,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 10,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 11,ou=sh,dc=su,dc=cvut,dc=cz ou=blok 12,ou=sh,dc=su,dc=cvut,dc=cz ou=sin,dc=su,dc=cvut,dc=cz

Návrh vycház´ı z hierarchického uspoˇr´ ad´ an´ı Studentské unie a snaˇz´ı se dodrˇzovat [RFC 2247]. Pˇri pouˇzit´ı této struktury jmenn´ ych prostor˚ u vˇsak nen´ı respektov´ an tvar pouˇziteln´ y pro digitáln´ı certifikáty [X.509]. Vzhledem ke vztah˚ um uvnitˇr Unie nen´ı snaha o vyuˇzit´ı adresáˇrov´ ych sluˇzeb, proto si kaˇzd´ y klub ˇreˇs´ı informaˇcn´ı systém podle sv´ ych návrh˚ u, moˇznost´ı a schopnost´ı. V souˇcasné situaci je vhodné navrhnout koˇren DIT ve tvaru dc=sin,dc=cvut,dc=cz vych´ azej´ıc´ı z doménové adresy klubu sin.cvut.cz a z jiˇz zmiˇ novaného [RFC 2247]. Vzhledem k jednoduché topologii zobrazené na obr. 5.2, strana 52. nemá cenu dˇelit DIT mezi v´ıce server˚ u. Pˇri návrhu topologie s´ıtˇe bylo vych´ azeno z poˇzadavk˚ u maximáln´ı snahy o zabezpeˇcen´ı s´ıtˇe a jednotliv´ ych server˚ u. Vˇsechny protokoly, kter´ ymi spolu servery komunikuj´ı, jsou zabezpeˇcen´ ymi variantami standardn´ıch protokol˚ u. Jedná se pˇredevˇs´ım o prokotoly ssh, https, ldaps, pop3s, imap4s a smtps, rovnˇ eˇz pˇr´ıstup k relaˇcn´ımu databázovému serveru PostgreSQL je ˇsifrován. Pro tyto zabezpeˇcené protokoly je nutné vygenerovat digitáln´ı certifikáty [X.509]

- 52 -

Karel Ben´ ak

5.2 Topologie

Obr. 5.2: Topologie s´ıtˇe KSk

podepsané nˇekterou z certifikaˇcn´ıch autorit, jinak budou klienti odm´ıtat spojen´ı s tˇemito zabezpeˇcen´ ymi servery a zabezpeˇcen´ı tak nebude efektivn´ı. Certifikáty budou nejsp´ıˇs podepsány lokáln´ı certifikaˇcn´ı autoritou a digitáln´ı certifikát této autority si do své kl´ıˇcenky importuj´ı vˇsichni klienti, kteˇr´ı s tˇemito servery budou spolupracovat.

5.2.1

Rozdˇ elen´ı server˚ u

ˇ gateway – centráln´ı smˇerovaˇc kter´ y zajiˇst’uje smˇerov´ an´ı s´ıtˇe 147.32.110.0/23 do s´ıtˇe CVUT 147.32.252.12/30. Pln´ı funkci centr´ aln´ıho firewallu zabraˇ nuj´ıc´ıho nˇekter´ ym u ´tok˚ um a zas´ılá ohláˇsen´ı smˇerovaˇce protokolu IPv6. Dalˇs´ım zaj´ımav´ ym programem bˇeˇz´ıc´ım na tomto poˇc´ıtaˇci je poˇc´ıtán´ı trafficu jednotliv´ ych poˇc´ıtaˇc˚ u a jeho pˇr´ıpadné omezen´ı. Pro zabezpeˇcen´ı správn´ ych vazeb mezi HW adresou a IP adresou je pouˇzita statick´ a ARP cache, která je generována z adresáˇrové sluˇzby pomoc´ı skriptu napsaného v jazyce Perl a pravidelnˇe aktualizována kaˇzd´ ych 15 minut. services – centráln´ı informaˇcn´ı a databázov´ y server na kterém jsou provozov´ any vˇsechny d˚ uleˇzité aplikace. Mezi hlavn´ı aplikace patˇr´ı pˇredevˇs´ım databáze ˇclen˚ u klubu uloˇzen´ a v relaˇcn´ı databázi PostgreSQL. Z této databáze jsou exportov´ any hodnoty nˇekter´ ych u ´daj˚ u o uˇzivatel´ıch a jejich poˇc´ıtaˇc´ıch a jsou importov´ any do ldap serveru. Ten slouˇz´ı jako zdroj informac´ı pro primárn´ı DNS server a DHCP server bˇeˇz´ıc´ım na tomto poˇc´ıtaˇci. Rovnˇeˇz jsou zde provozovány http servery Apache a Apache Tomcat jako aplikaˇcn´ı server pro vlastn´ı intranetovou aplikaci, která je napsána pomoc´ı JSP a Java servrlet˚ u. Ty vyuˇz´ıvaj´ı technologie JDBC a JNDI pro komunikaci mezi relaˇcn´ı databáz´ı a adresáˇrov´ ym serverem. Technologie Java byla zvolena pro snadnou portaci i na jiné platformy, neˇz-li je Intel/Linux. Pro tento server mus´ı b´ yt vygenerov´ ano nˇekolik digitáln´ıch certifikát˚ u [X.509] podepsan´ ych lokáln´ı certifikaˇcn´ı autoritou. Jsou to certifikáty pro domény services.sin.cvut.cz, intranet.sin.cvut.cz, ldap.sin.cvut.cz, db.sin.cvut.cz a ns.sin.cvut.cz. apps – aplikaˇcn´ı server pro provozov´ an´ı uˇzivatelsk´ ych aplikac´ı. Pˇr´ıstup je povolen pouze po dohodˇe s administrátory pomoc´ı protokolu ssh, kter´ y uˇzivatele autentizuje pomoc´ı

- 53 -

Karel Ben´ ak

5.3 Jmenn´ e prostory

adresáˇrové sluˇzby. Standardnˇe je pˇr´ıstup na tento server uˇzivatel˚ um zakáz´ an a povolen pouze na vyˇzádán´ı. Dále má na tomto serveru kaˇzd´ y uˇzivatel sv˚ uj poˇstovn´ı u ´ˇcet dostupn´ y pˇres protokoly pop3 nebo imap4. Jako serverov´ y software pro tyto protokoly je pouˇzit software Cyrus IMAP, kter´ y jako autentizaˇcn´ı zdroj pouˇz´ıv´ a centr´ aln´ı LDAP server dostupn´ y pˇres protokol ldaps. Odes´ıl´ an´ı poˇsty zajiˇst’uje server Postfix pomoc´ı protokolu smtp. Poˇstu je moˇzné pomoc´ı tohoto serveru odes´ılat i mimo s´ıt’ 147.32.110.0/23 a to d´ıky protokolu SMTP AUTH. Ten vyuˇz´ıv´ a protokol SASL a SASL opˇet z´ısk´ av´ a autentizaˇcn´ı informace pomoc´ı protokolu ldaps z centr´ aln´ıho serveru. Pro tento server mus´ı b´ yt vygenerováno nˇekolik digitáln´ıch certifikát˚ u [X.509] podepsan´ ych lokáln´ı certifikaˇcn´ı autoritou. Jsou to certifikáty pro domény apps.sin.cvut.cz, www.sin.cvut.cz, imap.sin.cvut.cz, pop3.sin.cvut.cz, mail.sin.cvut.cz a smtp.sin.cvut.cz. Na tomto serveru jsou pro potˇreby uˇzivatel˚ u klubu k dispozici SQL servery PostgreSQL, MySQL a FireBird a pˇredevˇs´ım http a https server Apache, kter´ y zajiˇst’uje veˇrejnou prezentaci stránek klubu a domovsk´ ych stránek uˇzivatel˚ u. backup – zálohovac´ı server na kterém jsou um´ıstˇeny pravidelné zálohy zb´ yvaj´ıc´ıch server˚ ua pˇr´ıpadnˇe obsahu disk˚ u ˇclen˚ u klubu, kteˇr´ı potˇrebuj´ı krátkodobˇe zálohovat své poˇc´ıtaˇce. Na tomto serveru je záloha aplikace pro správu uˇzivatel˚ u a rovnˇeˇz replikovan´ y LDAP server. Ostatn´ı servery jsou pro dalˇs´ı funkˇcnost s´ıtˇe nepodstatné a poskytuj´ı pouze doplˇ nkové sluˇzby, napˇr. TV server nebo news server. U news serveru by mohlo pˇrich´ azet v u ´vahu vyuˇzit´ı adresáˇrové sluˇzby pro autentizaci uˇzivatel˚ u k pˇr´ıstupu na privátn´ı diskusn´ı skupiny, ale zat´ım nebyl tento poˇzadavek vznesen. Pˇri návrhu a realizaci nelze pouˇz´ıt mechanismus Single Sign One pro moˇznost jediné autentizace pro vˇsechny sluˇzby spoleˇcnˇe. D˚ uvodem je velk´ a heterogenita s´ıtˇe a neexistence ˇz´ adného vyuˇzitelného standardu. Nab´ız´ı se sice moˇznost vyuˇzit´ı systému Kerberos, jeho konfigurace vˇsak nen´ı jednoduchou záleˇzitost´ı a v pˇr´ıpadˇe systém˚ u Microsoft Windows doˇslo k modifikaci tohoto standardu. V podnikovém informaˇcn´ım systému je situace odliˇsn´ a. Vˇetˇsinou je v nich homogenn´ı prostˇred´ı operaˇcn´ıch systém˚ u a administrátorsk´ a práva k poˇc´ıtaˇc˚ um maj´ı pouze jejich správci. V s´ıti KSk je kaˇzd´ y majitel poˇc´ıtaˇce jeho vlastn´ım administrátorem, proto se k tˇemto poˇc´ıtaˇc˚ um nem˚ uˇze navrhovan´ y systém chovat jako k d˚ uvˇeryhodn´ ym a autentizace pomoc´ı Kerbera by mohla pˇrinést bezpeˇcnostn´ı rizika. Nav´ıc by bylo nutné pˇrinutit uˇzivatele, aby pouˇz´ıvali na sv´ ych poˇc´ıtaˇc´ıch jména a hesla sjednocená s novˇe vytváˇren´ ym systémem.

5.3

Jmenn´ e prostory

Adresáˇrov´ y strom má zvolen´ y prefix dc=sin,dc=cvut,dc=cz a jeho tvar je navrˇzen podle schématu na obr. 5.3, strana 54.. V DN jednotliv´ ych ˇcást´ı DIT by bylo moˇzno pouˇz´ıt názvy dle [RFC 2253] v kódován´ı UTF-8, ovˇsem vzhledem k pˇr´ıpadnn´ ym komplikac´ım s r˚ uzn´ ymi národn´ımi prostˇred´ımi jednotliv´ ych aplikac´ı byly názvy záznam˚ u zvoleny v kódov´ an´ı ASCII.

5.3.1

Pˇ rehled jednotliv´ ych vˇ etv´ı

V následuj´ıc´ım pˇrehledu jednotliv´ ych vˇetv´ı navrˇzeného DIT jsou vysvˇetleny jejich v´ yznamy. Nˇekteré vˇetve se mohou dále rozˇsiˇrovat. - 54 -

Karel Ben´ ak

5.3 Jmenn´ e prostory

dc=sin,dc=cvut,dc=cz | +--------------+-------+-------+--------------+ | | | | ou=clenove ou=pocitace ou=majetek ou=konfigurace Obr. 5.3: KSk - návrh DIT ou=clenove V této vˇetvi jsou uchovány informace o ˇclenech klubu jako jsou jejich jméno, pˇr´ıjmen´ı, adresa, ID pod kter´ ym plat´ı své pˇr´ıspˇevky, digitáln´ı certifikát, foto a celá ˇrada dalˇs´ıch atribut˚ u. Proti záznam˚ um v této vˇetvi se mohou uˇzivatelé autentizovat pˇri pouˇz´ıv´ an´ı jiˇz zm´ınˇen´ ych sluˇzeb protokol˚ u imap4, pop3 ad. Kaˇzd´ y uˇzivatel si bude moci tuto vˇetev pˇripojit do svého e-mailového klienta pro vyhledán´ı e-mailov´ ych adres ostatn´ıch ˇclen˚ u klubu. Pˇri autentizaci by se pouˇzil kontext ou=clenove, dc=sin, dc=cvut, dc=cz. ou=pocitace V této vˇetvi jsou uchovány informace o poˇc´ıtaˇc´ıch ˇclen˚ u klubu. Z tˇechto záznam˚ u dynamicky ˇcerpaj´ı data pro sv˚ uj bˇeh servery DNS a DHCP. Je vˇsak velmi snadné záznamy v této vˇetvi pˇrizp˚ usobit pro statické generován´ı potˇrebn´ ych soubor˚ u. Toto ˇreˇsen´ı bylo zvoleno pˇredevˇs´ım d´ıky snadné distribuci potˇrebn´ ych dat pˇri pˇr´ıpadném pˇresunu tˇechto server˚ u na jiné stroje. Vˇetev se dále dˇel´ı na: zoneName=sin.cvut.cz – kontejner, ve kterém jsou uloˇzeny informace o poˇc´ıtaˇc´ıch ˇclen˚ u klubu. Kaˇzd´ y z tˇechto poˇc´ıtaˇc˚ u má v této vˇetvi sv˚ uj záznam obsahuj´ıc´ı jeho název, pˇr´ısluˇsnou IPv4 adresu, IPv6 adresu vygenerovanou z prefixu z´ıskaného od SU, HW adresu pro DHCP server a odkaz na majitele poˇc´ıtaˇce. zoneName=110.32.147.in-addr.arpa – kontejner, ve kterém jsou uloˇzeny záznamy reverzn´ı domény pro s´ıt’ 147.32.110.0 zoneName=111.32.147.in-addr.arpa – kontejner, ve kterém jsou uloˇzeny záznamy reverzn´ı domény pro s´ıt’ 147.32.111.0 Reverzn´ı doména pro IPv6 zat´ım nebyla navrˇzena. ou=majetek V této vˇetvi jsou uloˇzeny záznamy o majetku klubu. Základn´ı informace jsou uloˇzeny v relaˇcn´ı databázi, ve které lze d´ıky vhodnˇe navrˇzen´ ym objektov´ ym tˇr´ıd´ am a atribut˚ um zachytit velmi podrobnou konfiguraci konkrétn´ıho zaˇr´ızen´ı vˇcetnˇe fotografie. ou=konfigurace V této vˇetvi jsou uloˇzeny obecnˇe známé informace, které jsou bˇeˇznˇe uloˇzeny v souborech /etc/services, /etc/protocols apod. Pro jejich pˇrevod z klasick´ e textové podoby uloˇzené ve

- 55 -

Karel Ben´ ak

5.5 Sch´ emata

zm´ınˇen´ ych souborech lze pouˇz´ıt software migration tools od spoleˇcnosti PADL Software Pty Ltd1 . Dále tu je uloˇzena konfigurace DHCP serveru.

5.4

Adres´ aˇ rov´ a sluˇ zba

Vzhledem k poˇzadavk˚ um na pouˇz´ıván´ı otevˇreného software byl vybrán server [OpenLDAP]. Pˇri jeho instalaci je nutné pouˇz´ıt nˇekteré doplˇ nkové knihovny, jak´ ym jsou pˇredevˇs´ım [OpenSSL] pro podporu protokolu TLS a [Cyrus SASL] pro podporu protokolu SASL. [OpenLDAP] pouˇz´ıvá pro sv˚ uj bˇeh program slapd, kter´ y by mˇel b´ yt standardnˇe um´ıstˇen v adresáˇri /usr/sbin pˇr´ıpadnˇe v /usr/libexec. Pouˇz´ıv´ a konfiguraˇcn´ı soubor slapd.conf um´ıstˇen´ y v adresáˇri /etc/openldap. Jeho konfigurace je podrobnˇe popsána v manu´ alov´ ych stránk´ ach a na stránkách projektu [OpenLDAP]. Mezi nejd˚ uleˇzitˇejˇs´ı parametry v konfiguraˇcn´ım souboru patˇr´ı následuj´ıc´ı direktivy: include – Cesty k soubor˚ um se schématy database – Databázov´ y backend, standardnˇe nastavena hodnota bdb pro Berkley DB, jinak je moˇzno pouˇz´ıt backendy ldbm, sql ad. suffix – Prefix DIT "dc=sin, dc=cvut, dc=cz" rootdn – DN správce DIT "cn=manager, ou=Users, ou=konfigurace, dc=sin, dc=cvut, dc=cz"

rootpw – Heslo správce DIT. Pokud nen´ı uvedeno, pˇredpoklád´ a se, ˇze je uloˇzeno v databázi SASLu. Hesla ve tvaru SHA1 a MD5 lze generovat pomoc´ı utility slappasswd.

5.5

Sch´ emata

Pˇri návrhu schémat objektov´ ych tˇr´ıd a atribut˚ u se vych´ azelo ze snahy o maximáln´ı vyuˇzit´ı standard˚ u. V prvn´ı ˇradˇe bylo nutné z´ıskat jedineˇcné OID pro potˇreby návrhu nov´ ych atribut˚ u a objektov´ ych tˇr´ıd. Vzhledem k vazbˇe na SU bylo poskytnuto OID z rozsahu SU a sice 1.3.6.1.4.1.16748.3. S t´ımto rozsahem OID bylo moˇ zno naloˇzit dle libosti, proto byl rozsah dále rozdˇelen na ˇcásti podle tab. 5.1, strana 55. Vzhledem k moˇznosti v´ yskytu nˇekter´ ych spoleˇcn´ ych názv˚ u v jin´ ych aplikac´ıch by mohlo doj´ıt k duplicitˇe názv˚ u atribut˚ u a objektov´ ych tˇr´ıd, proto bylo zvoleno pojmenov´ an´ı atribut˚ u a objektov´ ych tˇr´ıd tak, aby jejich název obsahoval ksk....

5.5.1

ˇ Clenov´ e

Pro uloˇzen´ı informac´ı o jednotliv´ ych ˇclenech klubu jsou z relaˇcn´ı databáze importov´ any základn´ı u ´daje, kter´ ymi jsou: uid – identifikaˇcn´ı ˇc´ıslo ˇclena v rámci klubu jm´ eno – jméno ˇclena klubu 1

www.padl.com

- 56 -

Karel Ben´ ak

5.5 Sch´ emata

OID 1.3.6.1.4.1.16748.3 1.3.6.1.4.1.16748.3.1 1.3.6.1.4.1.16748.3.2 1.3.6.1.4.1.16748.3.2.1 1.3.6.1.4.1.16748.3.2.1.1 1.3.6.1.4.1.16748.3.2.2 1.3.6.1.4.1.16748.3.2.2.1

V´ yznam OID KSk SNMP elementy LDAP elementy Atributy Vlastn´ı atribut Objektové tˇr´ıdy Vlastn´ı objektov´ a tˇr´ıda

Tab. 5.1: Hierarchie OID pro KSk

pˇ r´ıjmen´ı – pˇr´ıjmen´ı ˇclena klubu rodn´ eˇ c´ıslo (ˇ c´ıslo pasu) – rodné ˇc´ıslo nebo ˇc´ıslo pasu pro evidenci SU ˇ skola – fakulta ,kterou ˇclen klubu navˇstˇevuje nebo je zamˇestnancem pokoj – ˇc´ıslo pokoje, na kterém ˇclen klubu bydl´ı konto – uˇzivatelsk´ yu ´ˇcet e-mail – oficiáln´ı e-mailová adresa, na kterou jsou zas´ıl´ ana d˚ uleˇzit´ a upozornˇen´ı datum – datum vstupu do klubu K tˇemto základn´ım informac´ım jsou pˇriˇrazeny dalˇs´ı, které jsou uloˇzeny pouze v adresáˇrovém serveru a nejsou nezbytnˇe nutné pro evidenci ˇclen˚ u, Bez nich mu vˇsak napˇr´ıklad nebude správnˇe doruˇcována ani odes´ılána elektronick´ a poˇsta. Uvedené atributy SQL databáze jsou pˇremapovány na LDAP atributy v pˇr´ısluˇsn´ ych objektov´ ych tˇr´ıd´ ach. Základn´ı pouˇzité objektové tˇr´ıdy a jejich atributy (povinné jsou vyznaˇceny silnˇe): top – základn´ı objektová tˇr´ıda person – dˇed´ı po objektové tˇr´ıdˇe top cn – Bˇeˇzn´ y název, v tomto pˇr´ıpadˇe jméno a pˇr´ıjmen´ı uˇzivatele sn – Pˇr´ıjmen´ı uˇzivatele userPassword – Heslo uˇzivatele. Tato poloˇzka je nutn´ a pokud bude cht´ıt uˇzivatel pˇrij´ımat a odes´ılat elektronickou poˇstu z lokáln´ıho serveru. Heslo bude uloˇzeno ve formátu MD5 telephoneNumber – Telefonn´ı ˇc´ıslo uˇzivatele seeAlso – DN na souvisej´ıc´ı objekty, napˇr. poˇc´ıtaˇce, které uˇzivatel vlastn´ı description – Popis organizationalPerson – dˇed´ı po objektové tˇr´ıdˇe person title – Titul, napˇr. Ing., Bc. apod. ou – Organizaˇcn´ı jednotka. V tomto pˇr´ıpadˇe studijn´ı obor kter´ y uˇzivatel studuje nebo vyuˇcuje - 57 -

Karel Ben´ ak

5.5 Sch´ emata

inetOrgPerson – dˇed´ı po objektové tˇr´ıdˇe organizationalPerson, definov´ ana v [RFC 2798] employeeNumber – UID pod kter´ ym je uˇzivatel v systému zaveden. employeeType – V´ yˇctov´ y typ uˇzivatele (admin, vip, normal) jpegPhoto – Fotografie uˇzivatele ve formátu JPEG givenName – Jméno uˇzivatele displayName – Jméno, které se bude zobrazovat v aplikac´ıch které umˇej´ı s adresáˇrov´ ymi sluˇzbami spolupracovat initials – Iniciály uˇzivatele preferredLanguage – Jazyk, kter´ y uˇzivatel preferuje pˇri komunikaci ˇ ıslo pokoje uˇzivatele roomNumber – C´ o – Organizace, kde uˇzivatel pracuje. V tomto pˇr´ıpadˇe je tento atribut pouˇzit´ y pro uloˇzen´ı názvu fakulty, kterou studuje. departmentNumber homePostalCode – Poˇstovn´ı adresa uˇzivatele homePhone – Telefon na uˇzivatelovu pevnou linku mobile – Mobiln´ı telefon userCertificate – Digitáln´ı certifikát uˇzivatele userPKCS12 – Digitáln´ı certifikát podle normy #PKCS12 userSMIMECertificate – Digitáln´ı certifikát pro podepisov´ an´ı el. poˇsty mail – Oficiáln´ı uˇzivatel˚ uv certifikát posixAccount – objektová tˇr´ıda pro UNIXové uˇzivatelské u ´ˇcty. Pomoc´ı této tˇr´ıdy bude uˇzivatel pˇristupovat ke své elektronické poˇstˇe apod. uid – Uˇzivatel˚ uv u ´ˇcet pro v´ ybˇer poˇsty ˇ uidNumber – C´ıslo uˇzivatelova u ´ˇctu, standardnˇe to b´ yv´ a ˇc´ıslo vyˇsˇs´ı neˇz-li 1000 ˇ ıslo skupiny, do které uˇzivatel patˇr´ı. Standardnˇe to b´ gidNumber – C´ yv´ a ˇc´ıslo 100, coˇz odpov´ıdá skupinˇe users homeDirectory – Domovsk´ y adresáˇr uˇzivatele gecos – Identifikaˇcn´ı u ´daje pro utility typu finger loginShell – Cesta k uˇzivatelovu shellu, standardnˇe nastavena´ a na /bin/false shadowAccount – objektová tˇr´ıda pro st´ınov´ a hesla. Nastavuj´ı se zde atributy pro expiraci hesel, jejich minimáln´ı a maximáln´ı délku apod. inetLocalMailRecipient – objektov´ a tˇr´ıda pro práci s e-maily podle draftu RFC draft-lachman-laser-ldap-mail-routing

Pro záznam dalˇs´ıch informac´ı o uˇzivatel´ıch je nutné navrhnout novou objektovou tˇr´ıdu a pˇr´ısluˇsné atributy. kskUser - 58 -

Karel Ben´ ak

5.5 Sch´ emata

objectclass ( 1.3.6.1.4.1.16748.3.2.2.1 NAME ’kskUser’ SUP top AUXILIARY DESC ’Schema ˇ clen˚ u KSk’ MAY ( kskNativeNumber $ kskPassportNumber $ kskDate $ kskMD5CertFingerPrint $ kskSHA1CertFingerPrint $ kskICQ $ kskJabber $ kskYahoo $ kskAIM $ kskMSN $ kskIRC ) ) kskNativeNumber – Rodné ˇc´ıslo uˇzivatele attributetype (1.3.6.1.4.1.16748.3.2.1.1 NAME ’kskNativeNumber’ DESC ’Rodn´ e ˇ c´ ıslo uˇ zivatele’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ˇ ıslo pasu uˇzivatele kskPassportNumber – C´ attributetype (1.3.6.1.4.1.16748.3.2.1.2 NAME ’kskPassportNumber’ DESC ’ˇ C´ ıslo pasu zahraniˇ cn´ ıho uˇ zivatele’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskDate – datum vstupu uˇzivatele do klubu attributetype (1.3.6.1.4.1.16748.3.2.1.3 NAME ’kskDate’ DESC ’Datum’ EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) kskMD5CertFingerPrint – MD5 fingerprint uˇzivatelova certifikátu attributetype (1.3.6.1.4.1.16748.3.2.1.4 NAME ’kskMD5CertFingerPrint’ DESC ’MD5 fingerprint uˇ zivatelova certifik´ atu’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskSHA1CertFingerPrint – SHA1 fingerprint uˇzivatelova certifikátu attributetype (1.3.6.1.4.1.16748.3.2.1.5 NAME ’kskSHA1CertFingerPrint’ DESC ’SHA1 fingerprint uˇ zivatelova certifik´ atu’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskICQ – ICQ kontakt na uˇzivatele attributetype (1.3.6.1.4.1.16748.3.2.1.6 NAME ’kskICQ’ DESC ’ICQ kontakt na uˇ zivatele EQUALITY caseIgnoreIA5Match’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskJabber – Jabber kontakt na uˇzivatele

- 59 -

Karel Ben´ ak

5.5 Sch´ emata

attributetype (1.3.6.1.4.1.16748.3.2.1.7 NAME ’kskJabber’ DESC ’Jabber kontakt na uˇ zivatele’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskYahoo – Yahoo kontakt na uˇzivatele attributetype (1.3.6.1.4.1.16748.3.2.1.8 NAME ’kskYahoo’ DESC ’Yahoo kontakt na uˇ zivatele’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskAIM – AIM kontakt na uˇzivatele attributetype (1.3.6.1.4.1.16748.3.2.1.9 NAME ’kskAIM’ DESC ’AIM kontakt na uˇ zivatele’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskMSN – MSN messenger kontakt na uˇzivatele attributetype (1.3.6.1.4.1.16748.3.2.1.10 NAME ’kskMSN’ DESC ’MSN messenger kontakt na uˇ zivatele’ EQUALITY caseIgnoreIA5Match SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) kskIRC – IRC kontakt na uˇzivatele attributetype (1.3.6.1.4.1.16748.3.2.1.11 NAME ’kskIRC’ DESC ’IRC kontakt na uˇ ziva EQUALITY caseIgnoreIA5Match’ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) Záznamy o uˇzivatel´ıch jsou uloˇzeny v kontejneru ou=clenove,dc=sin,dc=cvut,dc=cz pod RDN employeeNumber=UID uˇzivatele a záznam by pak mohl vypadat napˇr. takto: dn: employeeNumber=95799,ou=clenove,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetOrgPerson objectClass: inetLocalMailRecipient objectClass: kskUser sn: Ben´ ak cn: Karel Ben´ ak employeeNumber: 95799 employeeType: admin givenName: Karel uid: beny uidNumber: 1032 gidNumber: 100 homeDirectory: /home/beny - 60 -

Karel Ben´ ak

5.5 Sch´ emata

loginShell: /bin/bash mail: [email protected] mail: [email protected] kskNativeNumber: 770319/XXXX kskICQ: 36646638

5.5.2

Poˇ c´ıtaˇ ce

Pro uloˇzen´ı informac´ı o jednotliv´ ych poˇc´ıtaˇc´ıch ˇclen˚ u klubu a serverech jsou z relaˇcn´ı databáze exportov´ any základn´ı u ´daje, kter´ ymi jsou: id clena – identifikaˇcn´ı ˇc´ıslo majitele poˇc´ıtaˇce jm´ eno – název poˇc´ıtaˇce mac – HW adresa poˇc´ıtaˇce ip – IPv4 adresa poˇc´ıtaˇce zasuvka – Zásuvka, do které je poˇc´ıtaˇc pˇripojen datum – Datum pˇripojen´ı poˇc´ıtaˇce stav – Stav poˇc´ıtaˇce. Ten m˚ uˇze b´ yt bud’ aktivn´ı, vyˇrazen´ y nebo doˇcasnˇe odpojen´ y Informace o poˇc´ıtaˇc´ıch jsou ponˇekud komplikovanˇejˇs´ı a program pro jejich generov´ an´ı mus´ı ˇreˇsit problematick´ y zápis do reverzn´ıch záznam˚ u. Pro uloˇzen´ı normáln´ıch záznam˚ u o poˇc´ıtaˇc´ıch slouˇz´ı vˇetev zoneName=sin.cvut.cz, ou=pocitace, dc=sin, dc=cvut,dc=cz. V tomto záznamu jsou pouˇzita následuj´ıc´ı schémata a atributy: top – základn´ı objektová tˇr´ıda dnsZone – objektová tˇr´ıda pro spolupráci s DNS serverem zoneName – jméno zónového souboru relativeDomainName – název poˇc´ıtaˇce v dané zónˇe DNSTTL – atribut pro hodnotu ˇcasového u ´daje time to live DNSClass ARecord – IPv4 adresa MDRecord MXRecord – MX záznam e-mailového serveru NSRecord – NS záznam o nameserveru SOARecord CNAMERecord – Záznam o aliasu PTRRecord – PTR záznam pouˇz´ıvan´ y v reverzn´ıch zón´ ach HINFORecord MINFORecord - 61 -

Karel Ben´ ak

5.5 Sch´ emata

TXTRecord SIGRecord KEYRecord AAAARecord – IPv6 adresa ve formátu AAAA záznamu LOCRecord NXTRecord SRVRecord NAPTRRecord KXRecord CERTRecord A6Record – IPv6 adresa ve formátu A6 záznamu DNAMERecord – Reverzn´ı IPv6 záznam dhcpSubnet – Objektová tˇr´ıda DHCP pro nastaven´ı pods´ıtˇe dhcpNetMask – Délka masky pods´ıtˇe dhcpOptions – Objektová tˇr´ıda DHCP pro nastaven´ı parametr˚ u dhcpOption – Parametry, které se zas´ılaj´ı klientsk´ ym stanic´ım. Atribut m˚ uˇze b´ yt v´ıcehodnotov´ y. dhcpComputer – Objektová tˇr´ıda DHCP pro uloˇzen´ı informac´ı o poˇc´ıtaˇci. Tuto objektovou tˇr´ıdu je nutné upravit z typu STRUCTURAL na typ AUXILIARY, aby ji bylo moˇzno pouˇz´ıt spoleˇcnˇe se tˇr´ıdou dnsZone dhcpHWAddress – HW adresa s´ıt’ové karty poˇc´ıtaˇce dhcpStatements – Uloˇzen´ı pˇreddefinované IPv4 adresy kterou bude DHCP server poskytovat stanici poskytovat dhcpServer – Objektová tˇr´ıda pro nastaven´ı konfigurace serveru. Tuto objektovou tˇr´ıdu je nutné upravit z typu STRUCTURAL na typ AUXILIARY, aby ji bylo moˇzno pouˇz´ıt spoleˇcnˇe se tˇr´ıdou dnsZone dhcpServiceDN – DN záznamu, kde je uloˇzena konfigurace serveru. kskComputer objectclass ( 1.3.6.1.4.1.16748.3.2.2.2 NAME ’kskComputer’ SUP top AUXILIARY DESC ’Schema pro poˇ c´ ıtaˇ ce ˇ clen˚ u KSk’ MAY ( owner $ roomNumber $ kskDataConnector ) ) owner – DN vlastn´ıka poˇc´ıtaˇce ˇ ıslo pokoje, kde je poˇc´ıtaˇc um´ıstˇen roomNumber – C´ - 62 -

Karel Ben´ ak

5.5 Sch´ emata

ˇ ıslo zásuvky kskDataConnector – C´ attributetype (1.3.6.1.4.1.16748.3.2.1.12 NAME ’kskDataConnector’ DESC ’ˇ C´ ıslo z´ asuvky’ EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) kskServer objectclass ( 1.3.6.1.4.1.16748.3.2.2.3 NAME ’kskServer’ SUP top AUXILIARY DESC ’Schema pro poˇ c´ ıtaˇ ce ˇ clen˚ u KSk’ MAY ( manager $ roomNumber ) ) manager – DN správce daného serveru roomNumber – M´ıstnost, kde je zaˇr´ızen´ı um´ıstˇeno dn: ou=pocitace,dc=sin,dc=cvut,dc=cz ou: pocitace objectClass: top objectClass: organizationalUnit objectClass: dhcpService cn: DHCP Config dhcpStatements: ddns-update-style none dhcpPrimaryDN: relativeDomainName=services,zoneName=sin.cvut.cz, ou=pocitace,dc=sin,dc=cvut,dc=cz dn: zoneName=sin.cvut.cz,ou=pocitace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: dnsZone objectClass: dhcpSubnet objectClass: dhcpOptions zoneName: sin.cvut.cz relativeDomainName: @ dNSTTL: 86400 aRecord: 147.32.110.2 aAAARecord: 2001:718:2:880:210:5aff:fed7:8380 mXRecord: 10 mail.sin.cvut.cz. nSRecord: ns.sin.cvut.cz. nSRecord: apps.sin.cvut.cz. sOARecord: services.sin.cvut.cz. admin.sin.cvut.cz. 200406011330 10800 3600 604800 86400 cn: 147.32.110.0 dhcpNetMask: 23 dhcpOption: subnet-mask 255.255.254.0 dhcpOption: broadcast-address 147.32.111.255 dhcpOption: routers 147.32.110.1 - 63 -

Karel Ben´ ak

5.5 Sch´ emata

dhcpOption: domain-name-servers 147.32.110.2 dhcpOption: domain-name-servers 147.32.110.3 dhcpOption: domain-name "sin.cvut.cz" Záznam vˇetve zoneName=110.32.147.in-addr.arpa, ou=pocitace, dc=sin, dc=cvut,dc=cz slouˇz´ıc´ı pro reverzn´ı doménu s´ıtˇe 147.32.110 má následuj´ıc´ı tvar: dn: zoneName=110.32.147.in-addr.arpa,ou=pocitace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: dNSZone zoneName: 110.32.147.in-addr.arpa relativeDomainName: @ dNSTTL: 86400 nSRecord: services.sin.cvut.cz. nSRecord: apps.sin.cvut.cz. sOARecord: services.sin.cvut.cz. beny.sin.cvut.cz. 2003080301 10800 3600 604800 86400 Reverzn´ı doména 147.32.111 má shodn´ y záznam, jen hodnota atributu zoneName je nastavena na hodnotu 111.32.147.in-addr.arpa Vlastn´ı záznam o poˇc´ıtaˇci ˇclena klubu má následuj´ıc´ı tvar: dn: relativeDomainName=jsb,zoneName=sin.cvut.cz,ou=Hosts,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: dNSZone objectClass: dhcpHost objectClass: kskComputer zoneName: sin.cvut.cz relativeDomainName: jsb aRecord: 147.32.110.45 aAAARecord: 2001:718:2:880:230:4fff:fe13:86ac aAAARecord: 2001:718:2:880:0000:5efe:9320:6e2d owner: employeeNumber=58014,ou=clenove,dc=sin,dc=cvut,dc=cz cn: jsb dhcpHWAddress: ethernet 00:30:4F:13:86:AC dhcpStatements: fixed-address 147.32.110.45 Následuj´ıc´ı záznam ukazuje konfiguraci serveru services.sin.cvut.cz, u ostatn´ıch server˚ u je situace podobná. Servery jsou totiˇz konfigurov´ any pro statickou konfiguraci IP adresy a nepotˇrebuj´ı tedy ˇzádn´ y záznam pro DHCP server. dn: relativeDomainName=services,zoneName=sin.cvut.cz,ou=Hosts,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: dNSZone objectClass: dhcpServer objectClass: kskServer zoneName: sin.cvut.cz relativeDomainName: services ARecord: 147.32.110.2 - 64 -

Karel Ben´ ak

5.5 Sch´ emata

AAAARecord: 2001:718:2:880:210:5aff:fed7:8380 AAAARecord: 2001:718:2:880:0000:5efe:9320:6e02 CNAMERecord: ns CNAMERecord: intranet CNAMERecord: ldap CNAMERecord: db owner: dc=sin,dc=cvut,dc=cz managerer: employeeNumber=95799,ou=clenove,dc=sin,dc=cvut,dc=cz cn: services dhcpServiceDN: ou=pocitace,dc=sin,dc=cvut,dc=cz Tyto relativnˇe komplikované záznamy budou vyuˇz´ıvat DNS server a DHCP server. Pokud se v adresáˇri zmˇen´ı nˇejaká hodnota, servery okamˇzitˇe zareaguj´ı bez nutnosti generov´ an´ı nov´ ych konfiguraˇcn´ıch soubor˚ u a jejich znovunaˇc´ıt´ an´ı spojeného s pˇr´ıpadn´ ym restartem sluˇzby.

5.5.3

Majetek

Tato vˇetev slouˇz´ı pro rychlé prohl´ıˇzen´ı evidence zaˇr´ızen´ı, jak´ ymi jsou napˇr. r˚ uzné switche, huby, scannery apod. top device cn – Obecn´ y název, v tomto pˇr´ıpadˇe zastupuje název zaˇr´ızen´ı, napˇr. switch serialNumber – Sériové ˇc´ıslo zaˇr´ızen´ı seeAlso – Pokud je toto zaˇr´ızen´ı souˇc´ ast´ı jiného, pak je zde uvedeno jeho DN description – Detailn´ı popis zaˇr´ızen´ı kskDevice – Objektová tˇr´ıda pro podrobnˇejˇs´ı popis zaˇr´ızen´ı a jeho aktuáln´ıch záp˚ ujˇcek. objectclass ( 1.3.6.1.4.1.16748.3.2.2.4 NAME ’kskDevice’ SUP device AUXILIARY DESC ’Majetek KSk’ MAY ( manager $ jpegPhoto $ roomNumber $ kskBorrower $ kskDateLoan $ kskDateReturn ) ) manager – DN správce zaˇr´ızen´ı jpegPhoto – Foto zaˇr´ızen´ı ˇ ıslo m´ıstnosti, kde je zaˇr´ızen´ı um´ıstˇeno roomNumber – C´ kskBorrower – DN ˇclovˇeka, kterému bylo zaˇr´ızen´ı p˚ ujˇceno attributetype (1.3.6.1.4.1.16748.3.2.1.13 NAME ’kskBorrower’ DESC ’Osoba, kter´ e je zaˇ r´ ızen´ ı zap˚ ujˇ ceno’ EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE )

- 65 -

Karel Ben´ ak

5.5 Sch´ emata

kskDateLoan – Datum kdy bylo zaˇr´ızen´ı p˚ ujˇceno attributetype (1.3.6.1.4.1.16748.3.2.1.14 NAME ’kskBorrower’ DESC ’Datum zap˚ ujˇ cen´ ı zaˇ r´ ızen´ ı’ EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) kskDateReturn – Datum kdy bylo zaˇr´ızen´ı vráceno attributetype (1.3.6.1.4.1.16748.3.2.1.15 NAME ’kskDateReturn’ DESC ’Datum pˇ redpokl´ adan´ eho vr´ acen´ ı zaˇ r´ ızen´ ı’ EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) Objektové tˇr´ıdy je moˇzné dále rozvést pro konkrétn´ı potˇreby a je také moˇzné napˇr. vytvoˇrit tˇr´ıdu, zab´ yvaj´ıc´ı se speciálnˇe rozboˇcovaˇci, pˇrep´ınaˇci apod. Pˇr´ıklad záznamu o skeneru: dn: serialNumber=123X321,ou=majetek,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: device objectClass: kskDevice cn: Scanner HP serialNumber: 123X321 manager: employeeNumber=95799,ou=clenove,dc=sin,dc=cvut,dc=cz roomNumber: x13

5.5.4

Konfigurace

V této vˇetvi jsou uloˇzeny obecnˇe sd´ılené informace jako jsou napˇr. názvy uˇzivatelsk´ ych skupin, vazby ˇc´ısel port˚ u a jejich názv˚ u z /etc/services apod. V pˇr´ıkladech jsou uvedeny jen nˇekteré záznamy, jejich kompletn´ı seznam by byl pˇr´ıliˇs dlouh´ y. Jednotlivé ˇc´ asti této vˇetve mohou vyuˇz´ıt i uˇzivatelé, kteˇr´ı chtˇej´ı m´ıt konfiguraci shodnou s konfigurac´ı hlavn´ıch server˚ u pomoc´ı nov´ ané spoleˇcnosti PADL Software Pty Ltd. Pro migraci utilit nss ldap a pam ldap od jiˇz zmiˇ textov´ ych soubor˚ u do adresáˇrového stromu je moˇzné pouˇz´ıt Migration Tools. dn: ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: konfigurace ou=Group – definice systémov´ ych skupin, které by mˇely b´ yt na vˇsech serverech spoleˇcné dn: ou=Group,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: Group cn=users – základn´ı skupina pro vˇsechny uˇzivatele

- 66 -

Karel Ben´ ak

5.5 Sch´ emata

dn: cn=users,ou=Group,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: posixGroup cn: users gidNumber: 100 cn=postfix – skupina uˇzivatele postfix dn: cn=postfix,ou=Group,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: posixGroup cn: postfix gidNumber: 20 ou=Networks – seznam s´ıt´ı patˇr´ıc´ıch do SU. Odpov´ıd´ a souboru /etc/networks dn: ou=Networks,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: Networks cn=sin.cvut.cz dn: cn=sin.cvut.cz,ou=Networks,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: ipNetwork cn: sin.cvut.cz ipNetworkNumber: 147.32.110.0 ipNetmaskNumber: 255.255.254.0 ou=Protocols – seznam protokol˚ u. Odpov´ıd´ a souboru /etc/protocols. Aktuáln´ı seznam je moˇzné z´ıskat z http://www.iana.org dn: ou=Protocols,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: Protocols cn=icmp dn: cn=icmp,ou=Protocols,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: ipProtocol cn: icmp ipProtocolNumber: 1 description: Protocol icmp ou=Rpc – seznam port˚ u pro RPC. Odpov´ıd´ a souboru /etc/rpc. Aktuáln´ı seznam je moˇzné z´ıskat z http://www.iana.org

- 67 -

Karel Ben´ ak

5.5 Sch´ emata

dn: ou=Rpc,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: Rpc cn=ypserv dn: cn=ypserv,ou=Rpc,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: oncRpc cn: ypserv oncRpcNumber: 100004 description: RPC ypprog ou=Services – seznam sluˇzeb a odpov´ıdaj´ıc´ıch ˇc´ısel port˚ u. Odpov´ıd´ a souboru /etc/services. Jejich ofici´ aln´ı seznam je moˇzné z´ıskat z http://www.iana.org dn: ou=Services,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: Users cn=ssh dn: cn=ssh,ou=Services,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: ipService cn: ssh ipServicePort: 22 ipServiceProtocol: tcp ipServiceProtocol: udp ou=Users – definice systémov´ ych u ´ˇct˚ u, které by mˇely b´ yt na vˇsech serverech spoleˇcné. dn: ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: organizationalUnit ou: Users cn=postfix – uˇzivatel postfix dn: cn=postfix,ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectclass: account objectClass: posixAccount cn: postfix uid: postfix uidNumber: 100 gidNumber: 20 homeDirectory: /var/spool/postfix - 68 -

Karel Ben´ ak

5.6 Spolupr´ ace se software

V kontejneru ou=Users, ou=konfigurace, dc=sin, dc=cvut, dc=cz budou uloˇzeny i záznamy o uˇzivateli manager, kter´ y je hlavn´ım správcem adresáˇrového serveru a uˇzivateli proxyuser, kter´ y bude podle bezpeˇcnostn´ıho modelu slouˇzit jako prostˇredn´ık pˇri autentizaci uˇzivatel˚ u. dn: cn=manager,ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: person cn: manager password: {MD5}XYZ== dn: cn=proxyuser,ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz objectClass: top objectClass: person cn: manager password: {MD5}ZYY== Pro uˇzivatele proxyuser je tˇreba nastavit pˇr´ısluˇsn´ a práva ke ˇcten´ı uˇzivatelsk´ ych hesel: access to dn=".*,dc=sin,dc=cvut,dc=cz" attr=userPassword by dn="cn=manager,ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz" write by dn="cn=proxyuser,ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz" read by self write by * auth

5.6 5.6.1

Spolupr´ ace se software Operaˇ cn´ı syst´ emy

V prvn´ı ˇradˇe je tˇreba nastavit servery tak, aby spolupracovali s adresáˇrov´ ymi sluˇzbami. Vzhledem k tomu, ˇze pouˇzité operaˇcn´ı systémy na centr´ aln´ıch serverech jsou typu UNIX, konkrétnˇe Linux, je ˇreˇsen´ı pomˇernˇe snadné. Linux vyuˇz´ıv´ a sluˇzeb systémové knihovny glibc, která poskytuje systému mnoho standardizovan´ ych funkc´ı jazyka C, které vyuˇz´ıvaj´ı r˚ uzné aplikace. Ta má nˇekolik knihoven, které mohou pouˇz´ıvat r˚ uzné zdroje informac´ı. Napˇr. libnss files.so umoˇzn ˇuje z´ıskáván´ı informac´ı a konfigurac´ı z textov´ ych soubor˚ u, libnss dns.so umoˇzn ˇuje pouˇzit´ı systému DNS pro pˇrevod jmen poˇc´ıtaˇc˚ u na IP adresy a libnss nis.so umoˇzn ˇuje z´ıskávat potˇrebné informace z NIS serveru. Jiˇz nˇekolikrát zmiˇ novaná knihovna nss ldap od PADL Software Pty Ltd. umoˇzn ˇuje z´ısk´ av´ an´ı informac´ı z LDAP serveru. Knihovna nss ldap implementuje [RFC 2307], a proto umoˇzn ˇuje pouˇzit´ı adresáˇrov´ ych sluˇzeb i na jin´ ych systémech neˇz-li je Linux, napˇr. Solaris, AIX, HP-UX ad. a spolupracuje napˇr. s [OpenLDAP], [JES], NDS, [AD] ad. Ke správnému provozu knihovny je nutné nainstalovat nˇekterou ze systémov´ ych knihoven nutn´ ych pro práci s LDAP sluˇzbami, napˇr. knihovny libldap.so, libldap r.so a liblber.so z projektu [OpenLDAP]. Pro pouˇzit´ı adresáˇrov´ ych sluˇzeb v operaˇcn´ım systému je v prvn´ım kroku nutné nastavit klienta knihovny nss ldap. Standardnˇe se jeho konfiguraˇcn´ı soubor jmenuje /etc/ldap.conf a obsahuje celou ˇradu parametr˚ u. host – IP adresy nebo názvy LDAP server˚ u oddˇelen´ ych mezerou, ze kter´ ych se budou z´ısk´ avány potˇrebné informace, napˇr. ldap.sin.cvut.cz - 69 -

Karel Ben´ ak


base – DN koˇrenového záznamu, napˇr. dc=sin, dc=cvut, dc=cz ldap version – Verze LDAP protokolu, standardnˇe nastavena na hodnotu 3 bind bindpwd ssl start tls – Direktiva pro pouˇzit´ı vrstvy TLS pˇri komunikaci s LDAP serverem ssl on tls cacertdir – Cesta k certifikát˚ um certifikaˇcn´ıch autorit, napˇr. /etc/ssl/certs V tomto souboru je rovnˇeˇz moˇzné pomˇernˇe snadno vyuˇz´ıt pˇremapov´ an´ı názv˚ u atribut˚ u pouˇz´ıvan´ ych v adresáˇrovém serveru na názvy atribut˚ u pouˇz´ıvan´ ych jmenn´ ymi sluˇzbami podle [RFC 2307] V dalˇs´ım kroku je nutné aktualizovat soubor /etc/nsswitch.conf pro pouˇzit´ı adresáˇrov´ ych sluˇzeb a u jednotliv´ ych konfiguraˇcn´ıch direktiv nastavit správné hodnoty: # Z´ ısk´ an´ ı informac´ ı o~syst´ emov´ ych ´ uˇ ctech, napˇ red ze soubor˚ u /etc/passwd, # /etc/group a /etc/shadowm. Pokud v nich nebude z´ aznam nalezen, # pokus´ ı se syst´ em hledat v ldap serveru passwd: files ldap group: files ldap shadow: files ldap # !!!Varov´ an´ ı!!! Velmi citliv´ e na spr´ avn´ y pˇ reklad jmen, # bez nˇ ej by nemuselo doj´ ıt ke kontaktu s LDAP serverem. # libldap vyuˇ z´ ıv´ a vol´ an´ ı funkce gethostbyname(). hosts: files dns ldap # LDAP je autoritativn´ ı sluˇ zbou ve services: ldap [NOTFOUND=return] networks: ldap [NOTFOUND=return] protocols: ldap [NOTFOUND=return] rpc: ldap [NOTFOUND=return]

kter´ e files files files files

se m´ a dan´ y z´ aznam vyhledat # /etc/services # /etc/networks # /etc/protocols # /etc/rpc

uzn´ ych Doplˇ nkovou knihovnou je knihovna pam ldap. PAM moduly slouˇz´ı pro nastaven´ı r˚ variant pˇr´ıstupov´ ych práv k r˚ uzn´ ym sluˇzb´ am. V definici PAM modul˚ u pro jednotlivé typy pˇr´ıstup˚ u standardnˇe uloˇzen´ ych v /etc/pam.d je nutné uvést pouˇz´ıván´ı modulu pam ldap.so. V pˇriloˇzen´ ych konfiguraˇcn´ıch souborech jsou praktické ukázky, jak pˇr´ısluˇsnou sluˇzbu nakonfigurovat pro spolupráci s LDAP. # /etc/pam.d/login auth required auth required auth sufficient auth required account sufficient

/lib/security/pam_securetty.so /lib/security/pam_nologin.so /lib/security/pam_ldap.so /lib/security/pam_unix_auth.so try_first_pass /lib/security/pam_ldap.so - 70 -

Karel Ben´ ak

account password password password session


required required required required required

/lib/security/pam_unix_acct.so /lib/security/pam_cracklib.so /lib/security/pam_ldap.so /lib/security/pam_pwdb.so use_first_pass /lib/security/pam_unix_session.so

V´ıce informac´ı o konfiguraci PAM lze nalézt napˇr. v ˇcl´ anku PAM – správa autentizaˇcn´ıch mechanism˚ u2 .

5.6.2

DNS

Pro DNS bude pouˇzit software BIND od spoleˇcnosti ISC3 ve verzi 9.2.X, která má podporu protokolu IPv6 a umoˇzn ˇuje vyuˇz´ıvat i jin´ ych zdroj˚ u dat pomoc´ı rozhran´ı sdb, neˇz-li jsou klasické textové soubory. Na serveru services.sin.cvut.cz bude um´ıstˇen primárn´ı DNS server, kter´ y bude pouˇz´ıvat data z´ıskávána z LDAP serveru. Konkrétnˇe se jedná o vˇetve: zoneName=sin.cvut.cz,ou=pocitace,dc=sin,dc=cvut,dc=cz – zóna sin.cvut.cz zoneName=110.32.147.in-addr.arpa,ou=pocitace,dc=sin,dc=cvut,dc=cz – reverzn´ı zóna pro 147.32.110.0 zoneName=111.32.147.in-addr.arpa,ou=pocitace,dc=sin,dc=cvut,dc=cz – reverzn´ı zóna pro 147.32.111.0 Server DNS je nutné pˇreloˇzit s podporou protokolu LDAP. Postup u ´prav je k nalezen´ı na adrese http://klobouk.fsv.cvut.cz/~beny/ldap/ldap/ldap-8.html Do konfiguraˇcn´ıho souboru bindu je nutné pro zónu sin.cvut.cz uvést: zone "sin.cvut.cz" { type master; database "ldap ldap://127.0.0.1/zoneName=sin.cvut.cz, ou=pocitace,dc=sin,dc=cvut,dc=cz 86400"; }; A pro reverzn´ı domény 110.32.147.in-addr.arpa a 111.32.147.in-addr.arpa: zone "110.32.147.in-addr.arpa" { type master; database "ldap ldap://127.0.0.1/zoneName=110.32.147.in-addr.arpa,\ ou=pocitace,dc=sin,dc=cvut,dc=cz 86400"; }; zone "111.32.147.in-addr.arpa" { type master; database "ldap ldap://127.0.0.1/zoneName=111.32.147.in-addr.arpa,\ ou=pocitace,dc=sin,dc=cvut,dc=cz 86400"; }; Pˇri jakékoliv zmˇenˇe nˇekterého ze záznam˚ u v LDAP se tyto zmˇeny projev´ı okamˇzitˇe, coˇz je v´ yhoda kterou pouˇzit´ı LDAP serveru pˇrin´ aˇs´ı. 2 3

http://www.root.cz/clanek/478 www.isc.org

- 71 -

Karel Ben´ ak

5.6.3

5.7 Z´ avˇ er

DHCP

DHCP server zajiˇst’uje pˇridˇelován´ı statick´ ych IP adres na základˇe znalosti HW adresy poˇc´ıtaˇce. Je nakonfigurován tak, aby u ´daje z´ısk´ aval dynamicky z LDAP serveru. Tuto funkˇcnost je nutné zajistit podle návodu na adrese http://klobouk.fsv.cvut.cz/~beny/ ldap/ldap/ldap-9.html. Dále je nutné naimportovat soubor se schematy do adresáˇre /etc/openldap/schema a zajistit, aby daemon slapd pouˇ z´ıval i toto nové schema pouˇzit´ım direktivy include v konfiguraˇcn´ım souboru /etc/openldap.slapd.conf. V nˇem je rovnˇeˇz nutné serveru oznámit, ˇze má indexovat atributy s názvy dhcpHWAddress a dhcpClassData index index

dhcpHWAddress dhcpClassData

Pˇred vlastn´ım spuˇstˇen´ım slapd daemona je nutné upravit definici schémat objektov´ ych tˇr´ıd dhcpHost, dhcpServer, dhcpSubnet a dhcpOptions a zmˇenit na typ AUXILIARY, jinak doch´ az´ı ke konfliktu se tˇr´ıdou dnsZone. Po této u ´pravˇe je nutné pomoc´ı slapdindex pˇreindexovat data v databázovém backendu a následnˇe lze spustit daemona slapd. Konfigurace DHCP daemona je pomˇernˇe jednoduch´ a, v konfiguraˇcn´ım souboru /etc/dhcpd.conf lze uv´ est následuj´ıc´ı hodnoty: ldap-server "ldap.sin.cvut.cz"; # LDAP server ldap-port 389; # Port ldap-username "cn=proxyuser,ou=Users,ou=konfigurace,dc=sin,dc=cvut,dc=cz"; ldap-password "XYZ"; ldap-base-dn "dc=sin,dc=cvut,dc=cz"; ldap-method dynamic; Po svém spuˇst’en´ı je dhcpd server schopen vyˇrizovat poˇzadavky na pˇridˇelen´ı IP adresy dynamicky pomoc´ı LDAP serveru.

5.7

Z´ avˇ er

V této kapitole je uvedena jen ˇcást informaˇcn´ıho systému. K dynamickému z´ısk´ av´ an´ı dat pro DHCP a DNS servery bylo vzhledem k relativnˇe malému poˇctu záznam˚ u pˇristoupeno pˇredevˇs´ım z d˚ uvodu jiˇz hotového a vyzkouˇseného ˇreˇsen´ı. Pokud by se mˇela data pro jednotlivé servery generovat staticky do jejich konfiguraˇcn´ıch soubor˚ u, bylo by nutné napsat nˇekolik obsluˇzn´ ych skript˚ u nejsp´ıˇs za pouˇzit´ı jazyka Perl a vhodn´ ym zp˚ usobem vyˇreˇsit aktualizaci tˇechto soubor˚ u, napˇr. pomoc´ı systémového programu cron. Vlastn´ı záznamy by se t´ım vˇsak zjednoduˇsily. Dalˇs´ı souˇcást´ı je sluˇzba smtp, která slouˇz´ı k odes´ıl´ an´ı a pˇrij´ım´ an´ı doˇslé poˇsty. LDAP server se tu vyuˇz´ıvá pro pˇreklad z poˇstovn´ıch alias˚ u na systémové u ´ˇcty a opaˇcne. Dalˇs´ım vyuˇzit´ım LDAPu v smtp je autentizace pomoc´ı protokolu SMTP AUTH, d´ıky kterému budou moci uˇzivatelé odes´ılat svou poˇstu i mimo kolejn´ı s´ıt’.

- 72 -

´ ER ˇ KAPITOLA 6. ZAV

Karel Ben´ ak

Kapitola 6

Z´ avˇ er Pˇri psan´ı této práce jsem mohl z´ uroˇcit své zkuˇsenosti se správou a návrhem adresáˇrového serveru. Zároveˇ n jsem rád, ˇze se mé návrhy ˇreˇsen´ı správy ˇclen˚ u Klubu Sinkuleho koleje a jejich poˇc´ıtaˇc˚ u podaˇrilo realizovat a t´ım pˇrispˇet sv´ ym koleg˚ um a nástupc˚ um na pozici administrátor˚ u kolejn´ı s´ıtˇe ke zjednoduˇsen´ı a zpˇrehlednˇen´ı správy uˇzivatel˚ u a aplikac´ı. Bohuˇzel, téma adresáˇrov´ ych sluˇzeb je natolik rozsáhlé a komplexn´ı, ˇze je velmi obt´ıˇzné popsat vˇsechny d˚ uleˇzité informace v rozsahu diplomové práce a bylo by nutné poˇc´ıtat sp´ıˇse s objemem rozsáhlejˇs´ı publikace. Vyuˇzit´ı adresáˇrov´ ys sluˇzeb znamená velk´ y pˇr´ınos pro správu informaˇcn´ıho systému, kter´ y by vyuˇz´ıvalo v´ıce neˇz-li 50 uˇzivatel˚ u. Mezi administrátory a návrh´ aˇri systém˚ u je bohuˇzel malá povˇedomost o jeho moˇznostech a v´ yhodách. Podle podle mého názoru s t´ım souvis´ı ˇc´ asteˇcn´ a ˇci u ´plná neznalost standardn´ıch protokol˚ u a zamˇeˇren´ı pouze na firemn´ı produkty, pro jejichˇz funkˇcnost nen´ı tˇreba hlubˇs´ıch znalost´ı.

- 73 -

Karel Ben´ ak

LITERATURA

Literatura [UDLDAPDS] Timothy A. Howes, Ph.D., Mark C. Smith, Gordon S. Good: Understanding and Deploying LDAP Directory Services, Second Edition Vydavatelstv´ı Addison Wesley, 2003 ISBN 0672-32316-8 [LDAPSA] Gerald Carter: LDAP System Administration Vydavatelstv´ı O’Reilly, 2003 ISBN 1-56592-491-6 [LDAPDE] Brian Arkills: LDAP Directories Explained: An Introduction and Analysis Vydavatelstv´ı Addison Wesley, 2003 ISBN 0-201-78792-X [PERL] Larry Wall, Tom Christiansen, Randal L. Schwartz: Programov´ an´ı v jazyce Perl Vydavatelstv´ı ComputerPress ISBN 80-85896-95-8 [BfHA] Evan Marcus, Hal Stern: Blueprints for High Availibility Vydavatelstv´ı John Wiley & Sons, Inc. ISBN 0471-35601-8 [Sitera 1] Jiˇr´ı Sitera: Adres´ aˇ rov´ e sluˇ zby - u ´ vod do problematiky http://www.cesnet.cz/doc/techzpravy/2000-4/ [Sitera 2] Jiˇr´ı Sitera: Vyuˇ zit´ı adres´ aˇ rov´ ych sluˇ zeb (LDAP) v projektu MetaCentrum http://www.cesnet.cz/doc/techzpravy/2001/02/ [Sitera 3] Jiˇr´ı Sitera: LDAP a Kerberos http://www.cesnet.cz/doc/techzpravy/2002/ldapkrb/ldapkrb.pdf [Dostalek] Libor Dost´ alek a kolektiv: Velk´ y pr˚ uvodce protokoly TCP/IP Bezpeˇ cnost 2. aktualizované vydán´ı - 74 -

Karel Ben´ ak

LITERATURA

Vydavatelstv´ı Computer Press, Praha 2003 ISBN 80-7226-84-X

X.500 [X.501] X.501: The Models [X.509] X.509: Authentication Framework [X.511] X.511: Abstract Service Definition

RFC [RFC 1274] RFC 1274 – The COSINE and Internet X.500 Schema [RFC 2222] RFC 2222 – Simple Authentication and Security Layer (SASL) [RFC 2247] RFC 2247 – Using Domains in LDAP/X.500 Distinguished Names [RFC 2251] RFC 2251 – Lightweight Directory Access Protocol (v3) [RFC 2252] RFC 2252 – Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions [RFC 2253] RFC 2253 – Lightweight Directory Access Protocol (v3): UTF–8 String Representation of Distinguished Names [RFC 2254] RFC 2254 – The String Representation of LDAP Search Filters [RFC 2255] RFC 2255 – The LDAP URL Format [RFC 2256] RFC 2256 – A Summary of the X.500(96) User Schema for use with LDAPv3 [RFC 2307] RFC 2307 – An Approach for Using LDAP as a Network Information Service [RFC 2444] RFC 2444 – The One-Time-Password SASL Mechanism [RFC 2798] RFC 2798 – Definition of the inetOrgPerson LDAP Object Class [RFC 2829] RFC 2829 – Authentication Methods for LDAP [RFC 2830] RFC 2830 – Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security [RFC 2849] RFC 2849 – LDIF [RFC 3377] RFC 3377 – Lightweight Directory Access Protocol (v3): Technical Specification

Dokumentace na WWW [1] OpenLDAP http://www.openldap.org/doc [2] SunOne Directory Server 5.2 Deployment Guide http://docs-pdf.sun.com/816-6700-10/816-6700-10.pdf - 75 -

Karel Ben´ ak

LITERATURA

[3] Sun ONE Directory Server 5.2 Getting Started Guide http://docs-pdf.sun.com/816-6696-10/816-6696-10.pdf [4] Sun ONE Directory Server 5.2 Installation and Tuning Guide http://docs-pdf.sun.com/816-6697-10/816-6697-10.pdf [5] Sun ONE Directory Server 5.2 Administration Guide http://docs-pdf.sun.com/816-6698-10/816-6698-10.pdf [6] The JNDI Tutorial Building Directory-Enabled Java Applications http://java.sun.com/products/jndi/tutorial/index.html

Software Serverov´ y software [OpenLDAP] OpenLDAP – OpenSource implementace LDAP serveru, klientu a API. http://www.openldap.org [TinyLDAP] TinyLDAP [JES] Sun Java Enterprise Directory Server – http://www.sun.com [AD] Microsoft Active Directory – S´ıt’ov´ y adresáˇrov´ y server pro operaˇcn´ı systémy MS Windows http://www.microsoft.com [7] IBM Tivoli – Adresáˇrová sluˇzba od IBM Editory a prohl´ıˇ zeˇ ce [GQ] GQ – klient pro prohl´ıˇzen´ı a editaci LDAP záznam˚ u (strana 45.) http://biot.com/gq Klienti V´ yvojov´ e prostˇ redky [Doxygen] Doxygen – software pro generov´ an´ı dokumentace [OpenSSL] OpenSSL – Open source SSL/TLS knihovna http://www.openssl.org [GNU TLS] GNU TLS – Alternativa k OpenSSL http://www.gnu.org/software/gnutls [Cyrus SASL] Cyrus SASL http://asg.web.cmu.edu/sasl/ [GNU SASL] GNU SASL http://www.gnu.org/software/gsasl [MIT Kerberos] MIT Kerberos http://web.mit.edu/kerberos - 76 -

Karel Ben´ ak

LITERATURA

[Heimdal] Heimdal Kerberos http://www.pdc.kth.se/heimdal/ [GNU Shishi] GNU Shishi http://www.gnu.org/software/shishi [GNU GSS] GNU Generic Security Service Library http://www.gnu.org/software/gss [LibNTLM] LibNTLM http://josefsson.org/libntlm [JLDAP] JLDAP http://www.openldap.org/jldap [JDBC LDAP] JDBC-LDAP http://www.openldap.org/jdbcldap [Perl-LDAP] Perl-LDAP http://ldap.perl.org [Python-LDAP] Python-LDAP http://python-ldap.sourceforge.net

- 77 -

Autor práce: Karel Benák

Recommend Documents