Directory Server IBM Tivoli Directory Server for i5/os (LDAP)

Transkript

1 System i Directory Serer IBM Tioli Directory Serer for i5/os (LDAP) Verze 6, ydání 1

2

3 System i Directory Serer IBM Tioli Directory Serer for i5/os (LDAP) Verze 6, ydání 1

4 Poznámka Před použitím těchto informací a produktu, ke kterému se ztahují, si nezapomeňte přečíst informace uedené části Poznámky, na stránce 309. Toto ydání se ztahuje na erzi 6, ydání 1, modifikaci 0 operačního systému IBM i5/os (číslo produktu 5761-SS1) a na eškerá následná ydání a modifikace, dokud nebude noých ydáních uedeno jinak. Tato erze nefunguje na šech modelech počítačů RISC (reduced instruction set computer) ani na modelech CISC. Copyright International Business Machines Corporation 1998, Všechna práa yhrazena.

5 Obsah IBM Tioli Directory Serer for i5/os (LDAP) Co je noého e erzi V6R Soubor PDF pro produkt IBM Tioli Directory Serer for i5/os (LDAP) Koncepce produktu Directory Serer Adresáře Distribuoané adresáře Rozlišoací jména (DN) Přípona (kontext pojmenoání) Schéma Doporučené postupy pro strukturu adresáře Publikoání Replikace Sféry a užiatelské šablony Parametry prohledáání Praidla pro podporu národního jazyka (NLS)...49 Jazykoé příznaky Odkazy adresáři LDAP Transakce Zabezpečení produktu Directory Serer Procedura Backend projektoaná operačním systémem 84 Produkt Directory Serer a podpora žurnáloání operačního systému i5/os Jedinečné atributy Operační atributy Sereroé paměti cache Oladače a přídané operace Pokyny týkající se uložení a obnoy Začínáme s produktem Directory Serer Pokyny pro migraci Plánoání produktu Directory Serer Konfigurace produktu Directory Serer Naplnění adresáře Administrace prostřednictím weboého rozhraní Scénáře produktu Directory Serer Scénář: Nastaení produktu Directory Serer Scénář: Kopíroání užiatelů z oěřoacího seznamu HTTP sereru do produktu Directory Serer Spráa produktu Directory Serer Obecné úlohy administrace Úlohy týkající se administrační skupiny Úlohy týkající se skupin s limity hledání Úlohy týkající se skupin s proxy autorizací Úlohy týkající se jedinečných atributů Úlohy týkající se ýkonu Úlohy týkající se replikace Úlohy týkající se topologie replikací Úlohy týkající se lastností bezpečnosti Úlohy týkající se schématu Úlohy týkající se záznamů adresáře Úlohy týkající se užiatelů a skupin Úlohy týkající se sfér a užiatelských šablon Úlohy týkající se seznamů přístupoých prá (ACL) 206 Odkaz Obslužné programy příkazoého řádku produktu Directory Serer LDAP data interchange format (LDIF) Schéma konfigurace sereru adresářů Identifikátory objektů (OID) Ekialence produktu IBM Tioli Directory Serer 297 Předolená konfigurace produktu Directory Serer 297 Odstraňoání problémů produktu Directory Serer Sledoání chyb a přístupů produktu Directory Serer pomocí protokolu úloh Použití příkazu TRCTCPAPP k yhledání problémů 299 Použití olby LDAP_OPT_DEBUG při sledoání chyb Identifikátory zprá GLEnnnn Běžné chyby klienta LDAP Chyby souisející se zásadou pro spráu hesel Odstraňoání problémů s rozhraním API QGLDCPYVL Souisející informace Dodatek. Poznámky Ochranné známky Ustanoení a podmínky Copyright IBM Corp. 1998, 2008 iii

6 i System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

7 IBM Tioli Directory Serer for i5/os (LDAP) Produkt IBM Tioli Directory Serer for i5/os (dále označoaný jako Directory Serer) je komponentou operačního systému i5/os, která poskytuje funkce sereru LDAP (Lightweight Directory Access Protocol). LDAP yužíá protokol TCP/IP (Transmission Control Protocol/Internet Protocol) a je stále častěji použíán jako adresářoá služba pro internetoé i neinternetoé aplikace. V následujících tématech najdete informace, které ám pomohou s pochopením produktu Directory Serer a jeho použitím. Co je noého e erzi V6R1 Zde jsou uedeny noé nebo ýznamně změněné informace tématech týkajících se produktu IBM Tioli Directory Serer for i5/os (LDAP). Odstranění replikačních konfliktů V síti s íce hlaními serery poskytuje produkt IBM Tioli Directory Serer schopnost automaticky detekoat a yřešit konfliktní změny tak, aby adresáře na šech sererech zůstaly konzistentní. Když jsou detekoány replikační konflikty, je konfliktní změna nahlášena do protokolu sereru a také je zaznamenána do souboru protokolu lost and found, takže administrátor může obnoit jakákoli ztracená data. Přehled replikací Modifikace nastaení protokolu lost and found Zobrazení souboru protokolu lost and found Příkaz ldapmodify Volba -e errorfile přidaná do příkazu ldapmodify je určena pro zadání souboru, do kterého se zapisují zamítnuté položky. Volba -n je přidána za tím účelem, aby se před změny, které se mají proést, zapsal ykřičník, a změny byly ytištěny do standarního ýstupu. ldapmodify a ldapadd LDAP data interchange format (LDIF) Replikace s podporou podprocesů Můžete replikoat s použitím íce podprocesů, což zlepšuje celkoou propustnost replikace. Replikace s podporou podprocesů Ujednání o replikacích Šifroání hesla Produkt IBM Tioli Directory Serer poskytuje konfigurační olbu pro zašifroání hesla předtím, než je heslo uloženo adresáři. Tuto šifroací olbu lze yužít k tomu, aby se zabránilo přístupu k datům hesel prostém textu ze strany jak běžných užiatelů adresáře tak administračních užiatelů adresáře. Šifroání hesla Nastaení lastností zásady spráy hesel Copyright IBM Corp. 1998,

8 Atribut IBMAttributeTypes IBM Tioli Directory Serer 6.0 umožňuje použít prních 128 znaků atributu pro ytoření jména tabulky. Atribut IBMAttributeTypes Zakázané změny schématu Prostřednictím modifikace schématu můžete zětšit elikost sloupce. To ám umožní prostřednictím modifikace schématu zětšit maximální délku atributů, a to buď pomocí weboé admininistrace nebo obslužného programu ldapmodify. Zakázané změny schématu Distribuoaný adresář Produkt IBM Tioli Directory Serer byl upraen tak, aby fungoal jako distribuoaný adresář. V kombinaci se sererem proxy umožňuje funkce distribuoaného adresáře, aby se klastr adresářů jeil jako jeden adresář. Funkce distribuoaného adresáře spolu s funkcí proxy sereru umožní, aby implementace adresáře obsahoaly miliony záznamů. Distribuoané adresáře ldapmodrdn Produkt IBM Tioli Directory Serer podporuje u příkazu modifydn atribut newsuperior (noý nadřazený záznam) na listoém uzlu. ldapmodrdn Použití příkazu TRCTCPAPP k yhledání problémů Příkaz TRCTCPAPP můžete použít ke sledoání aktiní instance sereru. Použití příkazu TRCTCPAPP k yhledání problémů Přístup pro čtení k projektoaným užiatelům Můžete zakázat šechny prohledáací operace směroané na proceduru Backend projektoanou užiatelem. Operace LDAP Přístup pro čtení k projektoaným užiatelům Více instancí sereru V systému i5/os můžete mít íce sererů adresářů. Každý serer je známý jako instance. Pokud jste serer adresářů použíali předchozím ydání systému i5/os, bude migroat na instanci jménem QUSRDIR. Pro účely obsluhy ašich aplikací můžete ytořit íce instancí sereru adresářů. Spráa instancí Konfigurace produktu Directory Serer Pokyny k migraci Produkt IBM Tioli Directory Serer přejde na yšší erzi, když se popré serer adresářů spustí. Migrace na erzi V6R1 z erze V5R4 nebo V5R3 2 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

9 Zásady pro spráu hesel Administrační účty lze zamknout kůli nadměrnému počtu selhání při oěření. Tato funkce se týká pouze zdálených klientských připojení. Účet se při spuštění sereru obnoí. Noý atribut je definoán proto, aby umožnil administrační uzamčení účtu. Nastaení administračního hesla a zásad uzamčení účtu Nastaení lastností zásady spráy hesel K dispozici je noá přídaná operace, požadaek na sta účtu, která poskytne sta konkrétního účtu: oteřený (aktioaný), uzamčený nebo skončená platnost. ldapexop Jiné Ekialence produktu IBM Tioli Directory Serer: Verze V6R1 produktu Directory Serer je ekialentem produktu IBM Tioli Directory Serer Version 6.0. Informační centrum pro systémy Tioli Jak zjistíte, co je noé nebo co se změnilo Abyste snadněji iděli, kde byly proedeny technické změny, použíají tyto informace: Značku pro označení, kde noé nebo změněné informace začínají. Značku pro označení, kde noé nebo změněné informace končí. V PDF souborech můžete idět na leém okraji noých nebo změněných informací reizní značky (). Chcete-li najít další informace o tom, co je noého nebo co se změnilo tomto ydání, yhledejte si část Sdělení pro užiatele. Soubor PDF pro produkt IBM Tioli Directory Serer for i5/os (LDAP) Informace o produktu IBM Tioli Directory Serer for i5/os (LDAP) můžete prohlížet nebo tisknout e formátu souboru PDF. Chcete-li prohlížet nebo stáhnout PDF erzi tohoto dokumentu, yberte téma IBM Tioli Directory Serer for i5/os (LDAP (cca 2700 KB). Další informace Chcete-li prohlížet nebo ytisknout soubory PDF souisejících publikací a čerených knih (Redbooks), prostudujte si část Souisející informace na stránce 306. Jak ukládat soubory e formátu PDF Chcete-li uložit soubor PDF na praconí stanici za účelem prohlížení nebo tisku: 1. Klepněte praým tlačítkem myši na odkaz PDF prohlížeči. 2. Klepněte na olbu pro lokální uložení souboru PDF. 3. Vyhledejte adresář, do něhož chcete soubor PDF uložit. 4. Klepněte na Uložit. IBM Tioli Directory Serer for i5/os (LDAP) 3

10 Jak stáhnout produkt Adobe Reader K tomu, abyste mohli tyto soubory PDF prohlížet nebo tisknout, potřebujete mít systému nainstaloanou aplikaci Adobe Reader. Kopii je možno bezplatně stáhnout z weboých stránek Adobe ( Koncepce produktu Directory Serer Informace o koncepcích produktu Directory serer. Produkt Directory Serer implementuje specifikace LDAP V3 asociace Internet Engineering Task Force (IETF). Obsahuje také ylepšení oblasti funkčnosti a ýkonu doplněná společností IBM. Tato erze použíá pro zálohoání produkt IBM DB2 Uniersal Database for iseries, což zabezpečuje pro činnost LDAP integritu transakce, ysoký ýkon operací a možnosti zálohoání a obnoy online. Spolupracuje s klienty připojenými prostřednictím protokolu LDAP V3 IETF. Adresáře Produkt Directory Serer umožňuje přístup do takoého typu databáze, která ukládá informace hierarchické struktuře podobným způsobem, jakým je uspořádán integroaný systém souborů operačního systému i5/os. Jestliže je známo jméno některého objektu, je možné načíst jeho charakteristiky. Pokud jméno konkrétního jednotliého objektu známo není, je možné adresář prohledáat a nalézt seznam objektů, které yhoují určitému požadaku. Adresáře se mohou obykle prohledáat podle specifických kritérií, nikoli pouze podle předdefinoaných množin kategorií. Adresář je specializoaná databáze mající charakteristiky, které ji odlišují od relačních databází pro šeobecné účely. Charakteristika adresáře je takoá, že je k němu proáděn přístup (čte se nebo prohledáá) mnohem častěji, než je aktualizoán (zapisuje se do něj). Protože musejí být adresáře schopny podporoat elké objemy požadaku na čtení, jsou typicky optimalizoány pro přístup ke čtení. Jelikož adresáře nejsou určeny k tomu, aby umožňoaly tolik funkcí jako databáze pro šeobecné účely, je možné je optimalizoat tak, aby úsporně poskytoaly rychlý přístup íce aplikacím k datům adresáře e elkých distribuoaných prostředích. Adresář je možné centralizoat nebo distribuoat. Jestliže je adresář centralizoaný, potom na jednom místě existuje serer adresářů (nebo klastr sererů), který poskytuje přístup do příslušného adresáře. Pokud je adresář distribuoaný, existuje několik sererů, obykle geograficky rozptýlených, které zajišťují přístup do tohoto adresáře. V případě, že je adresář distribuoaný, informace uložené adresáři mohou být rozdělené na logické části nebo replikoané. Když jsou informace rozdělené na logické části, každý serer adresářů uchoáá jedinečnou a nepřekrýající se podmnožinu informací. To znamená, že každý záznam adresáře je uchoáán jednom a pouze jednom sereru. Metoda pro rozdělení adresáře yužíá odkazy LDAP. Odkazy LDAP umožňují užiatelům odkazoat požadaky LDAP (Lightweight Directory Access Protocol) buď na tytéž, nebo na odlišné prostory jmen uložené na jiném (nebo tomtéž) sereru. Když jsou informace replikoané, je tentýž záznam adresáře uložen na íce než jednom sereru. V distribuoaném adresáři mohou být některé informace rozdělené na logické části a některé informace mohou být replikoané. Model sereru adresářů LDAP je založen na záznamech (které se roněž označují jako objekty). Každý záznam sestáá z jednoho nebo íce atributů, jako je např. jméno nebo adresa, a z typu. Typy jsou obykle mnemotechnické řetězce, například cn pro common name (obecné jméno) nebo mail pro adresu elektronické pošty. Příklad adresáře, který uádí Obrázek 1 na stránce 6, znázorňuje záznam pro Tima Jonese, který obsahuje atributy mail a telephonenumber. Některé další možné atributy jsou fax, title (titul), sn (pro surname - příjmení) a jpegphoto. Každý adresář má určité schéma, což je sada praidel, která určují strukturu a obsah adresáře. Toto schéma můžete zobrazit pomocí weboého administračního nástroje. 4 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

11 Každý záznam adresáře obsahuje zláštní atribut zaný třída objektu (objectclass). Tento atribut řídí, které atributy daném záznamu jsou poinné nebo poolené. Jinými sloy, hodnota atributu třídy objektu určuje praidla schématu, která musí daný záznam zachoáat. Kromě atributů definoaných příslušným schématem obsahují záznamy také sadu atributů, které jsou uchoáány na sereru. Tyto atributy, označoané jako operační atributy, obsahují např. údaje o čase ytoření záznamu a informace o řízení přístupu. Záznamy adresáři LDAP jsou tradičně uspořádány do hierarchické struktury, která odráží politické, geografické nebo organizační hranice (iz Obrázek 1 na stránce 6). Záznamy, které předstaují země nebo regiony, se zobrazují na nejyšší úroni této hierarchické struktury. Záznamy, které předstaují státní a národní organizace, zaujímají hierarchii druhou úroeň. Záznamy na dalších úroních mohou předstaoat osoby, organizační jednotky, tiskárny, dokumenty nebo jiné položky. LDAP na záznamy odkazuje pomocí rozlišoacích jmen, neboli DN (Distinguished Names). Rozlišoací jména jsou tořena jménem samotného záznamu a jmény nadřazených objektů adresáři směrem zdola nahoru. Například plné DN pro záznam leém dolním rohu Obrázek 1 na stránce 6 je cn=tim Jones, o=ibm, c=us. Každý záznam obsahuje minimálně jeden atribut, který pojmenoáá lastní záznam. Tomuto atributu pojmenoání se říká relatiní rozlišoací jméno, neboli RDN (Relatie Distinguished Name) záznamu. Záznam nad tímto RDN se označuje jako nadřazené rozlišoací jméno. Ve ýše uedeném příkladu je lastní záznam pojmenoán cn=tim Jones, je to tedy RDN. Nadřazené DN pro cn=tim Jones je o=ibm, c=us. K tomu, aby mohl serer LDAP spraoat část adresáře LDAP, je nutné konfiguraci sereru specifikoat nadřazená rozlišoací jména nejyšší úroně. Tato rozlišoací jména se nazýají přípony. Serer má přístup ke šem objektům, které se hierarchii adresáře nacházejí pod zadanou příponou. Obsahuje-li serer LDAP například adresář, který znázorňuje Obrázek 1 na stránce 6, měl by mít konfiguraci zadánu příponu o=ibm, c=us, aby mohl uspokojit dotazy klienta týkající se Tima Jonese. IBM Tioli Directory Serer for i5/os (LDAP) 5

12 Obrázek 1. Struktura adresáře LDAP Při torbě struktury adresáře nejste ázáni tradiční hierarchií. Oblibu získáá například struktura doménoých komponent. V této struktuře se záznamy skládají z částí jmen domén TCP/IP. Například struktura dc=ibm,dc=com může být ýhodnější než o=ibm,c=us. Řekněme, že chcete ytořit adresář pomocí struktury doménoých komponent, která bude obsahoat data zaměstnance, jako např. jména, čísla telefonu a oé adresy. Použíáte příponu nebo kontext pojmenoání na základě domény TCP/IP. Tento adresář je možné znázornit asi takto: / +- ibm.com +- zaměstnanci +- Tim Jones tjones@ibm.com +- John Smith jsmith@ibm.com Když se tato data zadáají do sereru adresářů, mohou e skutečnosti ypadat nějak takto: # pripona ibm.com dn: dc=ibm,dc=com objectclass: top objectclass: domain dc: ibm # adresar zamestnancu dn: cn=employees,dc=ibm,dc=com objectclass: top 6 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

13 objectclass: container cn: employees # zamestnanec Tim Jones dn: cn=tim Jones,cn=employees,dc=ibm,dc=com objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson objectclass: publisher objectclass: eperson cn: Tim Jones cn: "Jones, Tim" sn: Jones gienname: Tim telephonenumber: mail: tjones@ibm.com # zamestnanec John Smith dn: cn=john Smith,cn=employees,dc=ibm,dc=com objectclass: top objectclass: person objectclass: organizationalperson objectclass: inetorgperson objectclass: publisher objectclass: eperson cn: John Smith cn: "Smith, John" sn: Smith gienname: John telephonenumber: mail: jsmith@ibm.com Asi si šimnete, že každý záznam obsahuje hodnoty atributů nazané třída objektu (objectclass). Hodnoty třídy objektu definují, které atributy jsou záznamu poolené, jako například telephonenumber nebo gienname. Poolené třídy objektů (object classes) jsou definoány e schématu. Schéma je sestaa praidel, která definují typ záznamů poolených příslušné databázi. Klienti a serery adresáře K adresářům se obykle získáá přístup pomocí komunikačního modelu klient-serer. Klientské i sereroé procesy mohou nebo nemusí běžet na stejném počítači. Serer je schopen obsloužit mnoho klientů. Aplikace, která chce zapisoat nebo číst informace adresáři, nezískáá přístup k adresáři přímo. Namísto toho olá funkci nebo rozhraní API, které zprostředkuje odeslání zpráy jinému procesu. Tento druhý proces získáá přístup k informacím adresáři jménem žádající aplikace. Výsledky zápisu nebo čtení jsou potom ráceny do žádající aplikace. Rozhraní API definuje programoací rozhraní, které konkrétní programoací jazyk použíá k získání přístupu k dané službě. Formát a obsah zprá yměňoaných mezi klientem a sererem se musí řídit dohodnutým protokolem. LDAP definuje protokol zprá použíaný klienty a serery adresáře. K dispozici je roněž rozhraní API pro LDAP přiřazené jazyku C nebo například způsoby přístupu k adresáři z aplikací Jaa yužíajících rozhraní pojmenoání a adresářů JNDI (Naming and Directory Interface) systému Jaa. Zabezpečení adresáře Adresář by měl podporoat základní schopnosti potřebné k implementaci zásad zabezpečení dat. Adresář nemusí přímo zajišťoat lastní schopnosti zabezpečení, ale může být začleněn do služby důěryhodné sítě, která poskytuje základní služby zabezpečení. Předeším je zapotřebí metoda pro oěření užiatelů. Oěření oěřuje, zda jsou užiatelé těmi, za které se ydáají. Základním schématem oěření je ID užiatele a heslo. Jakmile jsou užiatelé autentizoáni, je nutné určit, zda mají opránění nebo poolení k proádění požadoané činnosti na specifickém objektu. IBM Tioli Directory Serer for i5/os (LDAP) 7

14 Autorizace je často založena na seznamech přístupoých prá (ACL). ACL je seznam opránění, která mohou být připojena k objektům a atributům příslušném adresáři. Seznamy ACL uádějí, který typ přístupu má každý z užiatelů nebo skupin užiatelů poolen nebo odepřen. K tomu, aby bylo možné seznamy ACL ytořit co nejkratší a snadněji spraoatelné, jsou často užiatelé se stejnými přístupoými práy soustřeďoáni do skupin. Souisející pojmy Schéma na stránce 15 Schéma je sestaa praidel, která řídí, jakým způsobem je možné ukládat data adresáři. Schéma definuje typ poolených záznamů, strukturu jejich atributů a syntaxi atributů. Operační atributy na stránce 90 Existuje několik atributů, které mají pro serer adresářů speciální ýznam; označují se jako operační atributy. Jsou to atributy, které se uchoáají na sereru a buď odrážejí takoé informace o záznamech, které sprauje příslušný serer, nebo které oliňují činnost sereru. Rozlišoací jména (DN) na stránce 10 Každý záznam adresáři má rozlišoací jméno (DN - distinguished name). DN je jméno, které jednoznačně určuje záznam adresáři. Prní z komponent DN se označuje jako RDN (relatiní rozlišoací jméno - Relatie Distinguished Name). Rozhraní API LDAP (Lightweight Directory Access Protocol) Další informace o rozhraních API produktu Directory Serer najdete tématu Rozhraní API LDAP (Lightweight Directory Access Protocol). Zabezpečení produktu Directory Serer na stránce 51 Zde najdete informace o různých funkcích, které lze použít k zajištění zabezpečení produktu Directory Serer. Souisející informace Weboé stránky The Jaa Naming and Directory Interface (JNDI) Tutorial Distribuoané adresáře Distribuoaný adresář je adresářoé prostředí, e kterém jsou data rozdělena mezi íce serery adresářů. K tomu, aby se distribuoaný adresář jeil klientské aplikaci jako jeden adresář, je poskytoán jeden nebo íce sererů proxy, které mají znalosti o šech sererech a datech, která obsahují. Serery proxy distribuují příchozí požadaky na příslušné serery a shromažďují ýsledky, které pak racejí klientoi e sjednocené odpoědi. Jednotlié části distribuoaného adresáře obsluhuje sada tz. backend sererů. Tyto backend serery jsou zásadě standardní LDAP serery s dodatečnou podporou pro serer proxy, aby mohly ydáat požadaky jménem užiatelů, kteří jsou definoáni na odlišném sereru nebo patří do skupin definoaných na odlišných sererech. Produkt IBM Tioli Directory Serer 6.0 a noější (distribuoané platformy) poskytuje tento distribuoaný adresář s proxy serery, backend serery a nástroji pro nastaení takoého adresáře. Takoýto adresář je schopen se rozšířit až na několik milionů záznamů. Podpora produktu IBM Directory Serer for i5/os pro distribuoané adresáře Produkt IBM Directory Serer for i5/os je schopen fungoat jako backend serer rámci distribuoaného adresáře IBM Tioli Directory Serer. Serer adresářů operačního systému i5/os nemůže fungoat jako serer proxy, ani neobsahuje nástroje nezbytné pro nastaení distribuoaného adresáře. Serer proxy pak může být proozoán na další platformě, zatímco skutečná data se nacházejí jednom nebo íce sererů adresářů i5/os nebo kombinaci sererů adresářů i5/os a sererů platformy Tioli. Aby mohla být existující data adresáře oddělena od sereru adresářů i5/os, který má být použit topologii distribuoaného adresáře, je nutno data z adresáře i5/os exportoat do souboru LDIF, s yužitím souboru LDIF je nutno spustit a proést nástroj pro nastaení distribuoaného adresáře poskytoaný společností Tioli na platformách Tioli, a pak je potřeba data opětoně načíst do sererů adresářů i5/os a Tioli, které jsou zahrnuty jako backend serery pro tento distribuoaný adresář. Tento postup se nijak neliší pro serery i5/os a serery platformy Tioli, 8 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

15 přičemž užiatelé nástroj pro nastaení distribuoaného adresáře již mají, protože lastní serer proxy na platformě Tioli. Oladače a přídané operace na podporu distribuoaných adresářů Protože užiatelé a skupiny, do kterých patří, mohou být distribuoáni mezi íce serery, má produkt IBM Tioli Directory Serer nadefinoánu sadu oladačů a přídaných operací, které podporují členstí e skupině a řízení přístupu distribuoaném adresáři. K dispozici je roněž mechanismus pro zpětné poskytoání záznamu monitoroání půodnímu klientoi. Poznámka: Záznam adresáře je uložen na jednom sereru a jeho replikách. V distribuoaném adresáři šak určitý užiatel může patřit do jedné nebo íce skupin na jednom sereru a dále může patřit do dalších skupin definoaných na jiném sereru. Obdobně užiatel samotný nemusí být definoaný na backend sereru zpracoáajícím konkrétní požadaek. Oladač Audit Oladač Audit je mechanismus, pomocí kterého serer proxy posílá jedinečný identifikátor klientského požadaku inicioaného sererem proxy na backend serer. Kromě jedinečného identifikátoru je spolu s oladačem Audit zasláno IP půodního klienta. Tento jedinečný identifikátor se použíá pro oěření shody záznamů auditu na sereru proxy se záznamy auditu na backend sererech. Když požadaek prochází přes íce sererů, připojuje se informace o IP jednotliých sererů, což poskytuje trasu přes jednotlié serery zpátky k půodnímu klientoi. Přídaná operace Hodnocení členstí e skupině Tato přídaná operace umožňuje autorizoanému klientoi (sereru proxy) zasílat informace o užiateli backend sereru a požadoat seznam skupin (statických, nořených nebo dynamických), e kterých je tento užiatel členem na backend sereru. Oladač Členstí e skupině Tento oladač umožňuje autorizoanému klientoi (sereru proxy) zasílat seznam skupin, který bude použíán pro řízení přístupu. Řízení přístupu je yhodnocoáno na základě tohoto seznamu skupin namísto seznamu skupin, které by serer určil za normálních okolností, tj. na základě informací o skupinách uložených lokálně na sereru. Při typickém použití tento seznam obsahuje skupiny, které serer proxy shromáždí z jednotliých backend sererů na základě použití přídané operace Hodnocení členstí e skupině. Podpora monitoroání distribuoaných adresářích Bezpečnostní monitoroání operačního systému i5/os bylo zdokonaleno tak, aby podporoalo distribuoané adresáře. Oladač Audit: Sledoání požadaku zpět k půodnímu kleintoi je užitečné. I5/OS monitoruje oladač auditu tak, že přidáá do existujícího záznamu bezpečnostního monitoroacího žurnálu DI pole směroání. I když obsah není erifikoatelný, přichází z klienta, který je autorizoán k použití proxy autorizace a tudíž by měl být důěryhodným klientem. Oladač členstí e skupině: Přítomnost oladače skupin je monitoroána e dou částech: do záznamu bezpečnostního monitoroacího žurnálu DI bylo přidáno jednoznakoé pole uplatnění členstí e skupině. Serer lze také nakonfiguroat tak, aby olitelně monitoroal seznam skupin poskytnutý klientem. Pokud je tato olba nakonfiguroána, serer monitoruje také pole křížoá reference XD záznamu žurnálu DI a ytáří jeden nebo íce záznamů bezpečnostního monitoroacího žurnálu XD s odpoídajícím polem křížoá reference XD a seznamem skupin (až 5 skupin na jeden záznam žurnálu). Další podrobnosti o monitoroání bezpečnosti operačního systému i5/os najdete tématech týkajících se bezpečnosti níže uedených odkazech. Můžete také použít weboé stránkythe Internet Engineering Task Force a yhledat si rfc4648, kde získáte další informace o konfiguroání monitoroání pro serery adresářů. IBM Tioli Directory Serer for i5/os (LDAP) 9

16 Další informace o distribuoaných adresářích a nastaoání distribuoaných adresářů najdete tématu Distribuoané adresáře aplikaci Tioli Software Information Center. Souisející pojmy Monitoroání na stránce 52 Monitoroání ám umožňuje sledoat podrobnosti o transakcích určitého produktu Directory Serer. Souisející informace Monitoroání zabezpečení Další informace o monitoroání najdete tématu Monitoroání zabezpečení. Identifikátory objektů (OID) pro přídané operace a oladače Rozlišoací jména (DN) Každý záznam adresáři má rozlišoací jméno (DN - distinguished name). DN je jméno, které jednoznačně určuje záznam adresáři. Prní z komponent DN se označuje jako RDN (relatiní rozlišoací jméno - Relatie Distinguished Name). DN je tořeno z párů atribut=hodnota, oddělených čárkami, například: cn=ben Gray,ou=editing,o=New York Times,c=US cn=lucille White,ou=editing,o=New York Times,c=US cn=tom Brown,ou=reporting,o=New York Times,c=US K ytoření DN je možné použít jakýkoli z atributů definoaných e schématu adresáře. Důležité je šak pořadí párů hodnot atributů komponent. DN obsahuje jednu komponentu pro každou úroeň hierarchie adresáře od kořene až po úroeň, kde je záznam umístěn. Jména DN použíaná pro LDAP začínají nejspecifičtějším atributem (obykle některým typem jména) a pokračují postupně širšími atributy a často končí atributem země. Prní z komponent DN se označuje jako RDN (relatiní rozlišoací jméno - Relatie Distinguished Name). To jasně odlišuje příslušný záznam od jakýchkoli jiných záznamů, které mají stejné nadřazené atributy. Ve ýše uedených příkladech odlišuje jméno RDN cn=ben Gray prní záznam od druhého záznamu (se jménem RDN cn=lucille White ). Jména DN těchto dou příkladech jsou jinak ronocenná. V příslušném záznamu musí být roněž přítomen pár atribut=hodnota tořící RDN pro daný záznam (to neplatí pro ostatní komponenty DN). Vytořte podle tohoto příkladu záznam pro nějakou osobu: dn: cn=tim Jones,o=ibm,c=us objectclass: top objectclass: person cn: Tim Jones sn: Jones telephonenumber: Praidla pro uolnění znaků z DN Některé znaky mají DN speciální ýznam. Například znak = (ronítko) odděluje jméno a hodnotu atributu a znak, (čárka) odděluje páry atribut=hodnota. Speciálními znaky jsou, (čárka), = (ronítko), + (plus), < (menší než), > (ětší než), # (křížek), ; (středník), \ (zpětné lomítko) a (uozoka, ASCII 34). Speciální znak může být hodnotě atributu uolněn, tím se odstraní jeho speciální ýznam. Uolnění těchto speciálních znaků nebo jiných znaků hodnotě atributu řetězci DN se proádí těmito způsoby: 1. V případě, že znak, který má být uolněn, je jeden ze speciálních znaků, zapište před něj zpětné lomítko ( \ ASCII 92). Tento příklad znázorňuje způsob uolnění čárky názu organizace: CN=L. Eagle,O=Sue\, Grabbit and Runn,C=GB To je preferoaný způsob. 2. Jiným způsobem je nahrazení uolňoaného znaku zpětným lomítkem a děma hexadecimálními číslicemi, které toří jediný bajt kódu znaku. Kód znaku musí být e znakoé sadě UTF System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

17 CN=L. Eagle,O=Sue\2C Grabbit and Runn,C=GB 3. Celou hodnotu atributu uzařete uozokami (ASCII 34), které nejsou součástí hodnoty. Mezi párem uozoek jsou šechny znaky chápány tak, jak jsou, s ýjimkou \ (zpětného lomítka). Zpětné lomítko \ je možné použít pro uolnění zpětného lomítka (ASCII 92) nebo uozoek (ASCII 34), kteréhokoli z ýše uedených speciálních znaků nebo párů hexadecimálních číslic jako metodě 2. Příkladem může být uolnění uozoek e ýrazu cn=xyz"qrs"abc, ze kterého se stane cn=xyz\"qrs\"abc, nebo uolnění \ : "jednoduché zpětné lomítko musíte uolnit takto \\" Jiný příklad: "\Zoo" je neplatné, protože Z nelze tomto kontextu uolnit. Nepraá DN Nepraá (pseudo) DN se použíají při definoání a yhodnocoání řízení přístupu. Adresář LDAP podporuje několik nepraých DN (například group:cn=this a access-id:cn=anybody ), které se použíají pro odkazoání na elké počty DN, která sdílejí společnou charakteristiku, buď souislosti s proáděnou činnost, nebo s objektem, na kterém se tato činnost proádí. Serer adresářů podporuje tři nepraá DN: access-id: CN=THIS Když je uedeno jako součást ACL, odkazuje toto DN na binddn (připojoací DN), které odpoídá DN, na němž je příslušná činnost proáděna. Jestliže je například nějaká činnost proáděna na objektu cn=persona, ou=ibm, c=us a binddn je cn=persona, ou=ibm, c=us, jsou poskytnutá práa kombinací prá udělených jménu CN=THIS a jménu cn=persona, ou=ibm, c=us. group: CN=ANYBODY Když je uedeno jako součást ACL, odkazuje toto DN na šechny užiatele, četně těch, jejichž identita nebyla oěřena. Užiatele nelze yjmout z této skupiny a tuto skupinu nelze yjmout z databáze. group: CN=AUTHENTICATED Toto DN odkazuje na jakékoli DN, které bylo adresářem autentizoáno. Na metodu oěření se nebere zřetel. Poznámka: CN=AUTHENTICATED odkazuje na DN, které bylo autentizoáno kdekoli na sereru, bez ohledu na to, kde je umístěn objekt předstaoaný jménem DN. Toto jméno by se šak mělo použíat opatrně. Například pod jednou příponou cn=secret by mohl být uzel nazaný cn=confidential Material, který má aclentry group:cn=authenticated:normal:rsc. Pod jinou příponou, cn=common by mohl být uzel cn=public Material. Pokud jsou tyto da stromy umístěny na stejném sereru, připojení k cn=public Material by se poažoalo za autentizoanou a dostalo by poolení pro normální třídu objektu cn= Confidential Material. Některé příklady nepraých DN: Příklad 1 Předpokládejme toto ACL pro objekt: cn=persona, c=us AclEntry: access-id: CN=THIS:critical:rwsc AclEntry: group: CN=ANYBODY: normal:rsc AclEntry: group: CN=AUTHENTICATED: sensitie:rcs Připojení užiatele jako Obdržel by cn=persona, c=us normal:rsc:sensitie:rcs:critical:rwsc cn=personb, c=us normal:rsc:sensitie:rsc Anonymous normal:rsc V tomto případě obdrží persona práa udělená objektu s ID CN=THIS i práa udělená oběma skupinám s nepraými DN, jak CN=ANYBODY, tak CN=AUTHENTICATED. Příklad 2 Předpokládejme toto ACL pro objekt: cn=persona, c=us AclEntry: access-id:cn=persona, c=us: object:ad IBM Tioli Directory Serer for i5/os (LDAP) 11

18 AclEntry: access-id: CN=THIS:critical:rwsc AclEntry: group: CN=ANYBODY: normal:rsc AclEntry: group: CN=AUTHENTICATED: sensitie:rcs Pro činnost proáděnou na cn=persona, c=us: Připojení užiatele jako Obdržel by cn=persona, c=us object:ad:critical:rwsc cn=personb, c=us normal:rsc:sensitie:rsc Anonymous normal:rsc V tomto případě obdrží persona práa udělená objektu s ID CN=THIS i práa udělená DN samotnému cn=persona, c=us. Pošimněte si, že práa skupiny nejsou udělena, protože pro připojoací DN ( cn=persona, c=us ) existuje specifičtější aclentry ( access-id:cn=persona, c=us ). Zpracoání rozšířeného DN Smíšené RDN jména DN se může skládat z několika komponent spojených operátory +. Serer rozšiřuje podporu pro yhledáání záznamů, které mají takoé DN. Smíšené RDN je možné specifikoat jakémkoli pořadí jako ýchozí bod pro operaci yhledáání. ldapsearch -b "cn=mike+ou=austin,o=ibm,c=us" "(objectclass=*)" Serer podporuje rozšířenou operaci normalizace DN. Rozšířené operace normalizace DN normalizují jména DN pomocí schématu sereru. Tato rozšířená operace může být užitečná u aplikací, které použíají jména DN. Syntaxe rozlišoacího jména Formální syntaxe pro rozlišoací jméno (DN) je založena na RFC Syntaxe podle BNF (Backus Naur Form) je definoána takto: <name> ::= <name-component> ( <spaced-separator> ) <name-component> <spaced-separator> <name> <spaced-separator> ::= <optional-space> <separator> <optional-space> <separator> ::= "," ";" <optional-space> ::= ( <CR> ) *( " " ) <name-component> ::= <attribute> <attribute> <optional-space> "+" <optional-space> <name-component> <attribute> ::= <string> <key> <optional-space> "=" <optional-space> <string> <key> ::= 1*( <keychar> ) "OID." <oid> "oid." <oid> <keychar> ::= letters, numbers, and space <oid> ::= <digitstring> <digitstring> "." <oid> <digitstring> ::= 1*<digit> <digit> ::= digits 0-9 <string> ::= *( <stringchar> <pair> ) " *( <stringchar> <special> <pair> ) " "#" <hex> 12 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

19 <special> ::= "," "=" <CR> "+" "<" ">" "#" ";" <pair> ::= "\" ( <special> "\" " ) <stringchar> ::= any character except <special> or "\" or " <hex> ::= 2*<hexchar> <hexchar> ::= 0-9, a-f, A-F Pro odděloání jednotliých RDN rozlišoacím jménu je možné použíat znak středníku (;), ačkoli typickým zápisem je znak čárky (,). Na obou stranách čárky nebo středníku mohou být použity neiditelné znaky (mezery). Tyto neiditelné znaky se ignorují a středník je nahrazen čárkou. Kromě toho je možné použít znaky mezery ( ASCII 32), buď před, nebo za + nebo =. Tyto znaky mezer se při analýze ignorují. Následující příklad znázorňuje rozlišoací jméno zapsané pomocí zápisu, který je ýhodný pro běžné tary jmen. Prní jméno obsahuje tři komponenty. Prní z komponent je složené RDN. Složené RDN obsahuje íce než jeden pár atribut:hodnota a lze je použít pro jednoznačné určení specifického záznamu případech, e kterých by mohla být jednoduchá hodnota CN nejednoznačná: OU=Sales+CN=J. Smith,O=Widget Inc.,C=US Souisející pojmy Adresáře na stránce 4 Produkt Directory Serer umožňuje přístup do takoého typu databáze, která ukládá informace hierarchické struktuře podobným způsobem, jakým je uspořádán integroaný systém souborů operačního systému i5/os. Zabezpečení produktu Directory Serer na stránce 51 Zde najdete informace o různých funkcích, které lze použít k zajištění zabezpečení produktu Directory Serer. Oladače a přídané operace na stránce 92 Oladače a přídané operace umožňují rozšiřoat protokol LDAP, aniž by bylo nutno měnit protokol samotný. Přípona (kontext pojmenoání) Přípona (roněž označoaná jako kontext pojmenoání) je DN, které označuje nejyšší záznam hierarchii místně uloženého adresáře. Následkem použití schématu relatiního pojmenoání LDAP je toto DN roněž příponou každého dalšího záznamu hierarchii tohoto adresáře. Serer adresářů může mít mnoho přípon, z nichž každá identifikuje hierarchii místně uloženého adresáře, například o=ibm,c=us. Do adresáře musí být přidán určitý záznam, který odpoídá příponě. Záznam, který ytoříte, musí yužíat třídu objektu, která obsahuje použitý atribut pojmenoání. Pro ytáření záznamu odpoídajícího této příponě můžete použít weboý nástroj administrace nebo obslužný program Qshell ldapadd. Jednou z koncepcí LDAP je existence globálního prostoru pro jména LDAP. V globálním prostoru pro jména LDAP byste mohli najít DN jako například: cn=john Smith,ou=Rochester,o=IBM cn=jane Doe,o=My Company,c=US cn=systémoý administrátor,dc=myco,dc=com Přípona o=ibm sděluje sereru, že pouze prní DN je prostoru pro jména uchoáaném příslušným sererem. Pokusy odkazoat na objekty, které nespadají do jedné z přípon, mají za následek chybu no such object (žádný takoý objekt) nebo odkaz na jiný serer adresářů. IBM Tioli Directory Serer for i5/os (LDAP) 13

20 Serer může mít několik přípon. Serer adresářů má několik předdefinoaných přípon, které uchoáají data specifická pro naši implementaci: cn=schema obsahuje přístupné znázornění LDAP schématu cn=changelog uchoáá protokol změn sereru, pokud je poolený cn=localhost obsahuje nereplikoané informace, které určují některé aspekty činnosti sereru, například konfigurační objekty replikace cn=ibmpolicies obsahuje informace o činnosti sereru, které jsou replikoány cn=pwdpolicy obsahuje zásadu spráy hesel pro celý serer přípona os400-sys=system-name.mydomain.com zajišťuje LDAP s možností přístupu k objektům i5/os, současnosti omezený na užiatelské profily a skupiny Serer adresářů se dodáá předkonfiguroaný pomocí předolené přípony dc=system-name, dc=domain-name, což usnadňuje zahájení práce se sererem. Použití této přípony šak není podmínkou. Můžete přidáat sé lastní přípony a předkonfiguroanou příponu ymazat. Pro přípony existují dě obykle použíané konence pojmenoání. Jedna je založena na doméně TCP/IP přidělené aší organizaci. Ta druhá je založena na jménu a umístění organizace. Předpokládejme například doménu TCP/IP se jménem mycompany.com, pro kterou si můžete zolit příponu jako dc=mycompany,dc=com, kde atribut dc odkazuje na komponentu domény. V tomto případě by mohl záznam nejyšší úroně, který adresáři ytoříte, ypadat (s yužitím LDIF, textoého formátu souboru pro znázorňoání záznamů LDAP) nějak takto: dn: dc=mycompany,dc=com objectclass: domain dc: mycompany Příslušná třída objektu domain má roněž některé olitelné atributy, které budete praděpodobně moci yužít. Další použitelné atributy můžete zobrazit za pomoci weboého administračního nástroje, který umožňuje roněž prohlížet schéma nebo editoat záznam, který jste ytořili. Jestliže je jméno aší společnosti My Company a je-li tato společnost umístěna e Spojených státech, mohli byste si zolit podobnou příponu, jako je tato: o=my Company o=my Company,c=US ou=widget Diision,o=My Company,c=US Kde ou je jméno pro třídu objektu organizationalunit, o je jméno organizace pro třídu objektu organizace a c je standardní doupísmenná zkratka země použíaná pro pojmenoání třídy objektu země. V tomto případě by záznam nejyšší úroně, který ytoříte, mohl ypadat takto: dn: o=my Company,c=US objectclass: organization o: My Company Aplikace, které použíáte, mohou yžadoat, aby byly definoány určité přípony nebo aby byly použity konkrétní konence pojmenoání. Jestliže se například áš adresář použíá pro spráu digitálních podpisů, může být zapotřebí, abyste uspořádali část sého adresáře takoým způsobem, aby jména záznamů odpoídala jménům DN subjektů certifikátů, jejichž jsou držiteli. Záznamy, které se mají přidat do adresáře, musí mít příponu, která odpoídá hodnotě DN, jako například ou=marketing,o=ibm,c=us. Jestliže dotaz obsahuje příponu, která neodpoídá žádné příponě konfiguroané pro místní databázi, je tento dotaz odkázán na serer LDAP určený předoleným odkazem. Pokud není zadán žádný předolený odkaz LDAP, je rácen ýsledek Object does not exist (objekt neexistuje). Souisející pojmy 14 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

21 Úlohy týkající se záznamů adresáře na stránce 188 Pomocí těchto informací proádíte spráu záznamů adresáře. Úlohy týkající se schématu na stránce 178 Pomocí těchto informací proádíte spráu schématu. Souisející úlohy Přidáání a odstraňoání přípon sereru adresářů na stránce 121 Pomocí těchto informací přidáte nebo odstraníte příponu sereru adresářů. Souisející odkazy ldapmodify a ldapadd na stránce 210 Obslužný program příkazoého řádku pro modifikaci a přidáání záznamů LDAP. Schéma Schéma je sestaa praidel, která řídí, jakým způsobem je možné ukládat data adresáři. Schéma definuje typ poolených záznamů, strukturu jejich atributů a syntaxi atributů. Data jsou ukládána adresáři pomocí záznamů adresáře. Záznam se skládá ze třídy objektu, která je poinná, a jejích atributů. Atributy mohou být buď poinné, nebo olitelné. Třída objektu určuje druh informací, které záznam popisuje, a definuje sadu atributů, které obsahuje. Každý atribut má jednu nebo íce přiřazených hodnot. Další informace souisejících se schématem najdete těchto částech: Souisející pojmy Adresáře na stránce 4 Produkt Directory Serer umožňuje přístup do takoého typu databáze, která ukládá informace hierarchické struktuře podobným způsobem, jakým je uspořádán integroaný systém souborů operačního systému i5/os. Úlohy týkající se záznamů adresáře na stránce 188 Pomocí těchto informací proádíte spráu záznamů adresáře. Úlohy týkající se schématu na stránce 178 Pomocí těchto informací proádíte spráu schématu. Schéma sereru adresářů Schéma pro serer adresářů je předdefinoané, pokud šak máte další požadaky, můžete schéma změnit. Serer adresářů obsahuje podporu dynamických schémat. Schéma je zeřejněno jako součást informací adresáře a je k dispozici záznamu podschématu (DN= cn=schema ). Na schéma se můžete dotázat pomocí rozhraní API ldap_search() a modifikoat je pomocí ldap_modify(). Schéma obsahuje íce informací o konfiguraci než schéma začleněné RFC (Request for Comments) LDAP Verze 3 nebo e standardních specifikacích. Pro daný atribut můžete například stanoit, které indexy je nutno zachoáat. Tyto dodatečné informace o konfiguraci se podle potřeby uchoáají záznamu podchématu. Další třída objektu je definoána pro záznam podschématu IBMsubschema mající atributy typu MAY, které uchoáají přídané informace schématu. Serer adresářů definuje pro celý serer jediné schéma, které je přístupné prostřednictím speciálního záznamu adresáře, cn=schema. Tento záznam obsahuje šechna schémata definoaná pro příslušný serer. Chcete-li načíst informace o schématu, můžete proést ldap_search s yužitím tohoto postupu: DN: "cn=schema", search scope: base, filter: objectclass=subschema nebo objectclass=* Schéma poskytuje hodnoty pro tyto typy atributů: objectclasses attributetypes IBMAttributeTypes IBM Tioli Directory Serer for i5/os (LDAP) 15

22 matching rules (poronáací praidla) ldap syntaxes Syntaxe těchto definicí schématu je založena na RFC Verze 3 LDAP. Vzoroý záznam schématu by mohl obsahoat: objectclasses=( NAME extensibleobject SUP top AUXILIARY ) objectclasses=( NAME subschema AUXILIARY MAY ( ditstructurerules $ nameforms $ ditcontentrules $ objectclasses $ attributetypes $ matchingrules $ matchingruleuse ) ) objectclasses=( NAME alias SUP top STRUCTURAL MUST aliasedobjectname ) attributetypes=( NAME subschemasubentry EQUALITY distinguishednamematch SYNTAX NO-USER-MODIFICATION SINGLE-VALUE USAGE directoryoperation ) attributetypes=( NAME attributetypes EQUALITY objectidentifierfirstcomponentmatch SYNTAX USAGE directoryoperation ) attributetypes=( NAME objectclasses EQUALITY objectidentifierfirstcomponentmatch SYNTAX USAGE directoryoperation SYNTAX USAGE directoryoperation ) ldapsyntaxes=( DESC binární ) ldapsyntaxes=( DESC booleoský ) ldapsyntaxes=( DESC DN ) ldapsyntaxes=( DESC adresářoý řetězec ) ldapsyntaxes=( DESC zobecněný čas ) ldapsyntaxes=( DESC řetězec IA5 ) ldapsyntaxes=( DESC celé číslo ) ldapsyntaxes=( DESC telefonní číslo ) ldapsyntaxes=( DESC čas UTC ) matchingrules=( NAME caseignorematch SYNTAX ) matchingrules=( NAME objectidentifiermatch SYNTAX ) matchingrules=( NAME objectidentifierfirstcomponentmatch SYNTAX ) matchingrules=( NAME caseignoresubstringsmatch SYNTAX ) 16 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

23 Informace schématu je možné modifikoat prostřednictím rozhraní API ldap_modify. Pomocí DN cn=schema můžete doplňoat, mazat nebo nahrazoat typ atributu nebo třídu objektu. Je možné zadat i úplný popis. Záznamy schématu můžete přidáat nebo nahrazoat pomocí definice erze 3 LDAP či s yužitím definice rozšíření atributu IBM nebo pomocí obou definic. Souisející pojmy Úlohy týkající se schématu na stránce 178 Pomocí těchto informací proádíte spráu schématu. Rozhraní API LDAP (Lightweight Directory Access Protocol) Další informace o rozhraních API produktu Directory Serer najdete tématu Rozhraní API LDAP (Lightweight Directory Access Protocol). Třídy objektů Třída objektu specifikuje sestau lastností použíaných k popisu objektu. Atributy na stránce 19 Každý záznam adresáře obsahuje množinu atributů, která je k němu přiřazená prostřednictím jeho třídy objektu. Souisející odkazy Atribut IBMAttributeTypes na stránce 21 Atribut IBMAttributeTypes je možné použíat k definoání informací o schématu neobsažených e standardu LDAP erze 3 pro atributy. Poronáací praidla na stránce 22 Poronáací praidlo poskytuje odítka pro poronáání řetězců během operace yhledáání. Syntaxe atributu na stránce 24 Syntaxe atributu definuje přípustné hodnoty daného atributu. Dynamické schéma na stránce 28 Schéma je možno dynamicky měnit. Podpora obecného schématu Adresář IBM podporuje standardní schéma adresáře. Adresář IBM podporuje standardní schéma adresáře, jak je definoáno těchto specifikacích: RFC LDAP erze 3 od Internet Engineering Task Force (IETF), jako je RFC 2252 a Common Information Model (CIM) od Desktop Management Task Force (DMTF). Lightweight Internet Person Schema (LIPS) od Network Application Consortium. Tato erze LDAP zahrnuje předolené konfiguraci schématu definoané schéma erze 3 LDAP. Obsahuje roněž definice schématu DEN. IBM poskytuje také sadu přídaných obecných definicí schémat, která sdílejí jiné produkty IBM při yužití adresáře LDAP. Tato schémata zahrnují: Objekty pro aplikace bílé stránky, jako jsou eperson, skupina, země, organizace, organizační jednotka a role, umístění, stát a tak dále. Objekty pro další subsystémy, jako jsou účty, služby a přístupoé body, autorizace, oěření, zabezpečení ochrany dat a tak dále. Souisející informace Internet Engineering Task Force (IETF) Desktop Management Task Force (DMTF) Network Application Consortium Třídy objektů Třída objektu specifikuje sestau lastností použíaných k popisu objektu. IBM Tioli Directory Serer for i5/os (LDAP) 17

24 Kdybyste například ytořili třídu objektu tempemployee, mohla by obsahoat atributy ztahující se k dočasnému zaměstnanci jako například idnumber, dateofhire nebo assignmentlength. Je přirozeně možné přidáat takoé užiatelské třídy objektu, které yhoují potřebám aší organizace. Schéma sereru adresářů IBM poskytuje některé základní typy třídy objektů, četně typů: skupiny umístění organizace osoby Poznámka: Třídy objektů, které jsou specifické pro serer adresářů, mají předponu ibm-. Třídy objektů jsou definoány charakteristikami typu, dědičnosti a atributů. Typ třídy objektu Třída objektu může spadat pod jeden ze tří typů: Strukturní: Každý záznam musí příslušet do jedné a pouze jedné strukturní třídy objektu, která definuje základní obsah záznamu. Tato třída objektu předstauje objekt, který na sětě reálně existuje. Protože šechny záznamy musí příslušet do strukturní třídy objektu, jedná se o nejběžnější typ třídy objektu. Abstraktní: Tento typ se použíá jako nadtřída neboli šablona pro jiné (strukturní) třídy objektů. Definuje sestau atributů, které jsou společné pro množinu strukturních tříd objektů. Tyto třídy objektů, pokud jsou definoány jako podtřídy abstraktní třídy, dědí (přebírají) definoané atributy. Atributy není nutno definoat pro každou z podřízených tříd objektů. Pomocná: Tento typ uádí dodatečné atributy, které mohou být přiřazeny záznamu příslušejícímu do konkrétní strukturní třídy objektu. Ačkoli může záznam příslušet pouze do jediné strukturní třídy objektu, může příslušet do několika pomocných tříd objektů. Dědičnost třídy objektu Tato erze sereru adresářů podporuje dědičnost objektu pro definice třídy objektu a atributu. Noá třída objektu se může definoat pomocí nadřazených tříd (ícenásobná dědičnost) a dodatečných nebo změněných atributů. Každý záznam je přiřazen jediné strukturní třídě objektu. Všechny třídy objektů dědí od abstraktní třídy objektu top. Mohou roněž dědit i od jiných tříd objektů. Členění třídy objektu určuje seznam požadoaných a poolených atributů pro konkrétní záznam. Dědičnost třídy objektu záisí na pořadí definicí tříd objektů. Třída objektu může dědit pouze od tříd objektů, které ji předcházejí. Například struktura třídy objektu pro záznam osoby by mohla být definoána souboru LDIF jako: objectclass: top objectclass: person objectclass: organizationalperson V této struktuře dědí organizationalperson od třídy objektů person a top, zatímco třída objektu person dědí pouze od třídy objektu top. Proto, když nějakému záznamu přiřadíte třídu objektu organizationalperson, automaticky dědí poinné i poolené atributy od nadřazené třídy objektu ( tomto případě je to třída objektu person). Před zpracoáním a ykonáním operací aktualizace schématu se kontroluje jeho shodnost poronáním s hierarchií tříd schématu. 18 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

25 Atributy Každá třída objektu obsahuje mnoho poinných atributů a olitelných atributů. Poinné atributy jsou takoé atributy, které musí být obsaženy záznamech použíajících tuto třídu objektu. Volitelné atributy jsou takoé atributy, které smí být obsaženy záznamech použíajících tuto třídu objektu. Atributy Každý záznam adresáře obsahuje množinu atributů, která je k němu přiřazená prostřednictím jeho třídy objektu. Zatímco třída objektu popisuje typ informací, které záznam obsahuje, skutečná data jsou obsažena atributech. Atribut je předstaoán jedním nebo íce páry jméno-hodnota, které uchoáají specifické prky dat, jako např. jméno, adresu nebo telefonní číslo. Serer adresářů předstauje data jako např. páry jméno-hodnota, popisný atribut jako commonname (cn) a specifické informace jako např. John Doe. Například záznam pro osobu jménem John Doe by mohl obsahoat několik párů jméno-hodnota příslušného atributu. dn: uid=jdoe, ou=people, ou=mycompany, c=us objectclass: top objectclass: person objectclass: organizationalperson cn: John Doe sn: Doe gienname: Jack gienname: John I když standardní atributy jsou e schématu již definoány, definice atributů je možné ytářet, editoat, kopíroat nebo mazat tak, aby yhooaly potřebám aší organizace. Další informace najdete těchto částech: Obecné prky podschématu: Prky se použíají pro definoání gramatiky hodnot atributů podschématu. Níže uedené prky se použíají pro definoání gramatiky hodnot atributů podschématu: alpha = a - z, A - Z number = 0-9 anh = alpha / number / - / ; anhstring = 1 * anh keystring = alpha [ anhstring ] numericstring = 1 * number oid = descr / numericoid descr = keystring numericoid = numericstring *(. numericstring ) woid = whsp oid whsp ; sada několika oid jakékoli formy (numerická OID nebo jména) oids = woid / ( ( oidlist ) ) oidlist = woid *( $ woid ) ; deskriptory objektů použíané jako jména prků schématu qdescrs = qdescr / ( whsp ( qdescrlist ) whsp ) qdescrlist = [ qdescr *( qdescr ) ] whsp descr whsp Atribut objectclass: Atribut objectclasses zobrazuje seznam tříd objektů podporoaných sererem. IBM Tioli Directory Serer for i5/os (LDAP) 19

26 Každá hodnota tohoto atributu předstauje samostatnou definici třídy objektu. Definice tříd objektů je možno přidáat, mazat nebo modifikoat pomocí příslušných modifikací atributu objectclasses záznamu cn=schema. Hodnoty atributu objectclasses se řídí touto gramatikou definoanou RFC 2252: ObjectClassDescription = "(" whsp numericoid whsp ; Identifikátor atributu objectclass [ "NAME" qdescrs ] [ "DESC" qdstring ] [ "OBSOLETE" whsp ] [ "SUP" oids ] ; nadřazené objectclasses [ ( "ABSTRACT" / "STRUCTURAL" / "AUXILIARY" ) whsp ] ; předolená hodnota je strukturní [ "MUST" oids ] ; AttributeTypes [ "MAY" oids ] ; AttributeTypes whsp ")" Například definice třídu objektu (objectclass) osoby je: ( NAME person DESC Definuje záznamy, které obecném použití předstaují osoby. STRUCTURAL SUP top MUST ( cn $ sn ) MAY ( userpassword $ telephonenumber $ seealso $ description ) ) OID pro tuto třídu je Jméno je person Jedná se o strukturní třídu objektu Dědí od třídy objektu top Poinné jsou tyto atributy: cn, sn Volitelné jsou tyto atributy: userpassword, telephonenumber, seealso, description Souisející pojmy Úlohy týkající se schématu na stránce 178 Pomocí těchto informací proádíte spráu schématu. Atribut attributetypes: Atribut attributetypes zobrazuje seznam atributů podporoaných sererem. Každá hodnota tohoto atributu předstauje samostatnou definici atributu. Definice atributů je možno přidáat, mazat nebo modifikoat pomocí příslušných modifikací atributu attributetypes záznamu cn=schema. Hodnoty atributu attributetypes se řídí následující gramatikou, jak je definoána RFC 2252: AttributeTypeDescription = "(" whsp numericoid whsp ; identifikátor AttributeType [ "NAME" qdescrs ] ; jméno použíané AttributeType [ "DESC" qdstring ] ; popis [ "OBSOLETE" whsp ] [ "SUP" woid ] ; odozeno od tohoto jiného AttributeType [ "EQUALITY" woid ; jméno Matching Rule [ "ORDERING" woid ; jméno Matching Rule [ "SUBSTR" woid ] ; jméno Matching Rule [ "SYNTAX" whsp noidlen whsp ] [ "SINGLE-VALUE" whsp ] ; předolená hodnota - s íce hodnotami [ "COLLECTIVE" whsp ] ; předolená hodnota - není společné [ "NO-USER-MODIFICATION" whsp ]; předolená hodnota - modifikoatelné užiatelem [ "USAGE" whsp AttributeUsage ]; předolená hodnota - userapplications whsp ")" AttributeUsage = "userapplications" / "directoryoperation" / "distributedoperation" / ; DSA-sdíleno "dsaoperation" ; specifické pro DSA, hodnota záisí na sereru Poronáací praidla a syntaxe hodnot musejí odpoídat jedné z hodnot definoaných podle následujících částí: 20 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

27 Poronáací praidla na stránce 22 Syntaxe atributu na stránce 24 Ve schématu je možné definoat nebo modifikoat pouze atributy userapplications. Atributy directoryoperation, distributedoperation a dsaoperation jsou definoány sererem a mají přesný ýznam pro činnosti sereru. Například atribut description (popis) má tuto definici: ( NAME description DESC Atribut společný pro schémata CIM a LDAP pro specifikaci podrobného popisu záznamu objektu adresáře. EQUALITY caseignorematch SUBSTR caseignoresubstringsmatch SYNTAX USAGE userapplications ) Jeho OID je Jeho jméno je description Jeho syntaxe je (adresářoý řetězec) Souisející pojmy Úlohy týkající se schématu na stránce 178 Pomocí těchto informací proádíte spráu schématu. Atribut IBMAttributeTypes: Atribut IBMAttributeTypes je možné použíat k definoání informací o schématu neobsažených e standardu LDAP erze 3 pro atributy. Hodnoty IBMAttributeTypes musí splňoat tato gramatická praidla: IBMAttributeTypesDescription = "(" whsp numericoid whsp [ "DBNAME" qdescrs ] ; maximálně 2 jména (tabulka, sloupec) [ "ACCESS-CLASS" whsp IBMAccessClass whsp ] [ "LENGTH" wlen whsp ] ; maximální délka atributu [ "EQUALITY" [ IBMwlen ] whsp ] ; torba indexu pro poronáací praidlo [ "ORDERING" [ IBMwlen ] whsp ] ; torba indexu pro poronáací praidlo [ "APPROX" [ IBMwlen ] whsp ] ; torba indexu pro poronáací praidlo [ "SUBSTR" [ IBMwlen ] whsp ] ; torba indexu pro poronáací praidlo [ "REVERSE" [ IBMwlen ] whsp ] ; přerácený index pro podřetězec whsp ")" IBMAccessClass = "NORMAL" / ; toto je předolená hodnota "SENSITIVE" / "CRITICAL" / "RESTRICTED" / "SYSTEM" / "OBJECT" IBMwlen = whsp len Numericoid Použíá se k uedení hodnoty atributu attributetypes soulad s hodnotou IBMAttributeTypes. DBNAME Je možné použít maximálně dě jména, samozřejmě pokud jsou tato dě jména stanoena. Prní je jméno tabulky použíané pro tento atribut. Druhé je jméno sloupce použíaného pro plně normalizoanou hodnotu atributu tabulce. Pokud zadáte pouze jedno jméno, použije se jako jméno tabulky i jméno sloupce. Pokud nezadáte žádné jméno DBNAME, pak bude použito jméno na základě prních 128 znaků jména atributu (které musí být jedinečné). Jména tabulky databáze se zkracují na 128 znaků. Jména sloupců se zkracují na 30 znaků. ACCESS-CLASS Klasifikace přístupu pro tento typ atributu. Je-li ACCESS-CLASS ynechán, je použita předolená hodnota normal. IBM Tioli Directory Serer for i5/os (LDAP) 21

28 LENGTH Maximální délka tohoto atributu. Délka je yjádřena jako počet bajtů. Serer adresářů má opatření pro stanoení délky atributu. V hodnotě attributetypes může být řetězec: ( attr-oid... SYNTAX syntax-oid{len}... ) použit k yznačení, že attributetype s oid attr-oid má maximální délku. EQUALITY, ORDERING, APPROX, SUBSTR, REVERSE Jestliže je použit kterýkoli z těchto atributů, pro odpoídající poronáací praidlo se ytoří index. Volitelná délka uádí šířku indexoaného sloupce. Použije se jediný index, který yužíá několika praidel poronáání. Není-li některé z nich určeno užiatelem, serer adresářů přiřazuje délku 500. V odůodněných případech může serer roněž použít kratší délku, než požaduje užiatel. Například, překročí-li délka indexu maximální délku atributu, délka indexu se ignoruje. Poronáací praidla: Poronáací praidlo poskytuje odítka pro poronáání řetězců během operace yhledáání. Poronáací praidla jsou rozdělena do tří kategorií: ronost řazení podřetězec Serer adresářů podporuje poronání ronosti pro šechny syntaxe s ýjimkou binární. Pro atributy definoané pomocí binární syntaxe serer podporuje pouze prohledáání existence, například (jpegphoto=*). Pro syntaxe řetězce IA5 String a syntaxe adresářoého řetězce lze definici atributu dále definoat z hlediska rozlišoání elkých a malých písmen (case exact nebo case ignore). Například atribut cn použíá poronáací praidlo caseignorematch, takže hodnoty John Doe a john doe jsou ekialentní. U poronáacích praidel, která nerozlišují elká a malá písmena (case ignore), se poronání proádí po přeedení hodnot na elká písmena. Algoritmus přeádění na elká písmena není přizpůsoben podle lokálního jazyka, takže nemusí u šech lokálních jazyků fungoat spráně. Serer adresářů podporuje poronáání podřetězců pro atributy syntaxe adresářoého řetězce, řetězce IA5 String a rozlišoacího jména. Prohledáací filtry pro poronáání podřetězců použíají znak *, aby poronali žádný nebo íce znaků řetězci. Například prohledáací filtr (cn=*smith) prohledá šechny hodnoty cn zakončené řetězcem smith. Poronáání řazení je podporoáno pro syntaxe celočíselné proměnné (Integer), adresářoého řetězce, řetězce IA5 a rozlišoacího jména. Pro syntaxe řetězců je řazení založeno na jednoduchém řazení bajtů hodnot řetězce UTF-8. Je-li atribut definoán s poronáacím praidlem bez rozlišoání malých a elkých písmen (case ignore), je řazení proedeno za použití hodnot řetězce přeedených na elká písmena. Jak již bylo zmíněno ýše, algoritmus přeádění na elká písmena nemusí u šech lokálních jazyků fungoat spráně. V sereru adresářů IBM je choání poronáání řetězců a řazení odozeno z poronáacího praidla: šechny syntaxe, které podporují poronáání podřetězců, mají implicitní praidlo poronáání podřetězců a šechny syntaxe, které podporují řazení, mají implicitní praidlo řazení. Pro atributy definoané za použití poronáacího praidla bez rozlišoání elkých a malých písmen (case ignore) jsou implicitní poronáací praidla podřetězců a řazení také bez rozlišoání elkých a malých písmen. Poronáací praidla ronosti Poronáací praidlo OID Syntaxe caseexactia5match Syntaxe adresářoého řetězce caseexactmatch IA5 Syntaxe řetězce caseignoreia5match Syntaxe řetězce IA5 caseignorematch Syntaxe adresářoého řetězce 22 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

29 Poronáací praidla ronosti Poronáací praidlo OID Syntaxe distinguishednamematch DN - rozlišoací jméno generalizedtimematch Syntaxe zobecněného času ibm-entryuuidmatch Syntaxe adresářoého řetězce integerfirstcomponentmatch Syntaxe celočíselné proměnné - celé číslo integermatch Syntaxe celočíselné proměnné - celé číslo objectidentifierfirstcomponentmatch Řetězec pro zahrnutí OID. OID je řetězec obsahující číslice (0-9) a desetinné tečky (.). objectidentifiermatch Řetězec pro zahrnutí OID. OID je řetězec obsahující číslice (0-9) a desetinné tečky (.) octetstringmatch Syntaxe adresářoého řetězce telephonenumbermatch Syntaxe telefonního čísla utctimematch Syntaxe času UTC Poronáací praidla řazení Poronáací praidlo OID Syntaxe caseexactorderingmatch Syntaxe adresářoého řetězce caseignoreorderingmatch Syntaxe adresářoého řetězce distinguishednameorderingmatch DN - rozlišoací jméno generalizedtimeorderingmatch Syntaxe zobecněného času Poronáací praidla podřetězce Poronáací praidlo OID Syntaxe caseexactsubstringsmatch Syntaxe adresářoého řetězce caseignoresubstringsmatch Syntaxe adresářoého řetězce telephonenumbersubstringsmatch Syntaxe telefonního čísla Poznámka: UTC-Time je formát časoého řetězce definoaný podle standardů ASN.1. Viz normy ISO 8601 a X680. Tato syntaxe se použíá pro ukládání časoých hodnot e formátu UTC-Time. Souisející odkazy Zobecněný čas a UTC čas na stránce 34 Produkt Directory Serer podporuje syntaxe zobecněného času a UTC času. Praidla indexoání: Praidla indexoání připojená k atributům umožňují rychlejší načítání informací. Pokud je zadán pouze atribut, žádné indexy se neuchoáají. Serer adresářů umožňuje tato praidla indexoání: ronost řazení přibližně IBM Tioli Directory Serer for i5/os (LDAP) 23

30 podřetězec opačné pořadí Specifikace praidel indexoání pro atributy: Určení praidla indexoání pro určitý atribut řídí torbu a údržbu speciálních indexů pro hodnoty atributů. To ýrazně zlepšuje dobu odezy na hledání s filtry, které takoé atributy obsahují. S činnostmi uplatněnými e filtru yhledáání souisí těchto pět možných typů praidel indexoání. ronost Platí pro tyto činnosti při yhledáání: equalitymatch = Například: "cn = John Doe" řazení Platí pro tuto činnost při yhledáání: greaterorequal >= lessorequal <= Například: "sn >= Doe" přibližně Platí pro tuto činnost při yhledáání: approxmatch ~= Například: "sn ~= doe" podřetězec Platí pro operaci yhledáání s použitím syntaxe podřetězce: substring * Například: "sn = McC*" "cn = J*Doe" opačné pořadí Platí pro tuto činnost při yhledáání: * substring Například: "sn = *baugh" Jako minimum se doporučuje, abyste určili indexoání ronosti jakýchkoli atributů, které se mají použít e filtrech yhledáání. Syntaxe atributu: Syntaxe atributu definuje přípustné hodnoty daného atributu. Serer použíá definici syntaxe pro příslušný atribut k oěřoání dat a určení způsobu, kterým se mají poronáat hodnoty. Například Booleoský atribut může mít pouze hodnoty TRUE a FALSE. 24 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

31 Atributy je možné definoat buď tak, že mají jedinou hodnotu, nebo několik hodnot. Hodnoty atributech s íce hodnotami nejsou uspořádány podle pořadí, takže by žádná aplikace neměla záiset na tom, zda bude skupina hodnot pro daný atribut racena konkrétním pořadí. V případě, že požadujete setříděnou množinu hodnot, máte možnost ložit seznam hodnot do jediné hodnoty atributu: preferences: 1st-pref 2nd-pref 3rd-pref Další možností je zahrnout informace o řazení přímo do dané hodnoty: preferences: 2 yyy preferences: 1 xxx preferences: 3 zzz Atributy s íce hodnotami jsou užitečné případě, kdy je nějaký záznam označoán několika jmény. Například cn (common name) má několik hodnot. Záznam by bylo možné definoat takto: dn: cn=john Smith,o=My Company,c=US objectclass: inetorgperson sn: Smith cn: John Smith cn: Jack Smith cn: Johnny Smith To umožňuje yhledáání Johna Smithe i Jacka Smithe, přičemž se rátí tytéž informace. Binární atributy obsahují liboolný bajtoý řetězec, například fotografii JPEG, a nelze je yužíat k yhledáání záznamů. Booleoské atributy obsahují řetězec TRUE nebo FALSE. Atributy DN obsahují rozlišoací jména LDAP. Hodnoty nemusí být jména DN existujících záznamů, ale musí mít platnou syntaxi DN. Atributy s adresářoým řetězcem obsahují textoý řetězec sestaený ze znaků UTF-8. Atribut může u hodnot použíaných e filtrech yhledáání rozlišoat malá a elká písmena nebo může elikost písmen ignoroat (na základě poronáacího praidla definoaného pro daný atribut), hodnota je šak ždy rácena tak, jak byla půodně zadána. Atributy zobecněného času obsahují řetězec znázorňující datum a čas se zabezpečením přechodu přes rok 2000 s yužitím času GMT s olitelným posunem časoého pásma GMT. Atributy s řetězcem IA5 obsahují textoý řetězec yužíající znakoou sadu IA5 (7bitoou ASCII sadu použíanou USA). Atribut může u hodnot použíaných e filtrech yhledáání rozlišoat malá a elká písmena nebo může elikost písmen ignoroat (na základě poronáacího praidla definoaného pro daný atribut), hodnota je šak ždy rácena tak, jak byla půodně zadána. Řetězec IA5 roněž umožňuje yužití zástupných znaků pro yhledáání podřetězců. Celočíselné atributy obsahují znázornění hodnoty textoým řetězcem. Jako příklad může sloužit 0 nebo Hodnoty celočíselných atributů syntaxe musí být rozmezí od do Atributy telefonního čísla obsahují textoé znázornění telefonního čísla. Serer adresářů neyžaduje u těchto hodnot žádnou konkrétní syntaxi. Následující hodnoty jsou šechny platné: (555) , i Atributy času UTC použíají starší formát řetězce pro znázornění data a času bez zabezpečení přechodu přes rok Ve schématu adresáře je syntaxe atributu specifikoána pomocí identifikátoru objektu (OID) přiřazeného ke každé syntaxi. V následující tabulce jsou uedeny syntaxe podporoané sererem adresářů a jejich OID. Syntaxe Syntaxe popisu typu atributu OID IBM Tioli Directory Serer for i5/os (LDAP) 25

32 Syntaxe Binární - oktetoý řetězec Booleoský - TRUE/FALSE Syntaxe adresářoého řetězce Syntaxe popisu praidla obsahu DIT Syntaxe popisu praidla DITStructure DN - rozlišoací jméno Syntaxe zobecněného času Syntaxe řetězce IA Popis typu atributu IBM Syntaxe celočíselné proměnné - celé číslo Syntaxe popisu syntaxe LDAP Popis praidla poronáání Popis použití praidla poronáání Popis formy jména Syntaxe popisu třídy objektu Řetězec pro zahrnutí OID. OID je řetězec obsahující číslice (0-9) a desetinné tečky (.). OID Syntaxe telefonního čísla Syntaxe času UTC. UTC-Time je formát časoého řetězce definoaný podle standardů ASN.1. Viz normy ISO 8601 a X680. Tato syntaxe se použíá pro ukládání časoých hodnot e formátu UTC-Time Souisející pojmy Identifikátor objektu (OID) Identifikátor objektu (OID) je řetězec sestaený z dekadických čísel, který jednoznačně určuje příslušný objekt. Těmito objekty jsou typicky třída objektu nebo atribut. Souisející odkazy Zobecněný čas a UTC čas na stránce 34 Produkt Directory Serer podporuje syntaxe zobecněného času a UTC času. Identifikátor objektu (OID) Identifikátor objektu (OID) je řetězec sestaený z dekadických čísel, který jednoznačně určuje příslušný objekt. Těmito objekty jsou typicky třída objektu nebo atribut. Pokud nemáte OID, můžete zadat třídu objektu nebo jméno atributu s připojeným -oid. Například jestliže ytáříte atribut tempid, můžete zadat OID jako tempid-oid. Zásadně důležité je to, aby soukromé OID ydáaly opráněné orgány. Existují dě základní strategie pro získáání legitimních OID: Zaregistroat dané objekty u příslušného úřadu. Tato strategie může být například hodná, jestliže potřebujete malý počet OID. Od úřadu získat arc (arc je samostatný podstrom stromu OID) a přidělit sé lastní OID podle potřeby. Tato strategie může být hodnější, když je zapotřebí mnoho OID nebo když nejsou přiřazení OID stabilní. Americký národní úřad pro normalizaci (ANSI) je registrační úřad pro jména organizací e Spojených Státech rámci globálního registračního procesu zaedeného organizacemi ISO (International Standards Organization) a ITU 26 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

33 (International Telecommunication Union). Další informace o registraci jména organizace můžete nalézt na weboých stránkách ANSI ( Arc OID úřadu ANSI pro organizace je ANSI přiřadí číslo (NEWNUM) a ytoří noý podstrom arc OID: NEWNUM. Ve ětšině zemí nebo regionů ede registr OID národní ústa pro normalizaci. Tak jako u podstromu arc úřadu ANSI se obyčejně jedná o podstromy arc přiřazené pod OID Je možné, že nalezení úřadu pro přiděloání OID některých zemích nebo regionech bude nutné ěnoat určité úsilí. Národní úřad pro normalizaci e aší zemi nebo regionu může být členem ISO. Jména a kontaktní informace členů ISO je možné yhledat na weboých stránkách ISO ( Úřad IANA (Internet Assigned Numbers Authority) přiděluje soukromým podnikům čísla OID podstromu arc IANA přidělí číslo (NEWNUM) tak, aby noý arc OID byl NEWNUM. Tato čísla je možné získat na weboých stránkách IANA ( Jakmile byl aší organizaci přidělen OID, můžete definoat sé lastní OID připojením hodných čísel na konec přiděleného OID. Předpokládejme například, že aší organizaci byl přidělen fiktiní OID Žádné jiné organizaci nebyl přidělen OID, který začíná Řadu pro LDAP můžete ytořit připojením.1, což ytoří Dále je možno dělit tuto řadu do řad pro třídy objektů ( ), typy atributů ( ) a tak dále, a přiřadit OID atributu foo. Souisející informace Weboé stránky ANSI Weboé stránky ISO Weboé stránky IANA Záznamy podschématu Na každý serer připadá jeden záznam podschématu. Všechny záznamy adresáři mají implicitní typ atributu subschemasubentry. Hodnotou typu atributu subschemasubentry je DN záznamu podschématu, který odpoídá danému záznamu. Všechny záznamy pod stejným sererem sdílejí tentýž záznam podschématu a jejich typ atributu subschemasubentry má tutéž hodnotu. Záznam podschématu má peně naprogramoáno DN cn=schema. Záznam podschématu náleží do třídy objektu top, subschema a IBMsubschema. Třída objektu IBMsubschema nemá žádné atributy MUST a má jeden typ atributu MAY ( IBMattributeTypes ). Třída objektu IBMsubschema Třída objektu IBMsubschema je specifická třída objektu, která uchoáá šechny atributy a třídy objektu pro daný serer adresářů. Třída objektu IBMsubschema se použíá pouze záznamu podschématu, a to takto: ( NAME ibmsubschema DESC třída objektu specifická pro IBM, která uchoáá šechny atributy třídy objektů pro daný serer adresářů. SUP subschema STRUCTURAL MAY ( IBMAttributeTypes ) ) Dotazy na schéma Pro dotazoání na záznam podschématu lze použít rozhraní API ldap_search(). Rozhraní API ldap_search() je možné yužíat pro dotazoání na záznam podschématu, jak je znázorněno tomto příkladu: DN : "cn=schema" rozsah yhledáání : base filtr : objectclass=subschema nebo objectclass=* IBM Tioli Directory Serer for i5/os (LDAP) 27

34 Tento příklad načítá celé schéma. Chcete-li načíst šechny hodnoty ybraných typů atributů, použijte při hledání parametr attrs příkazu ldap_search. Není možné načíst pouze určitou hodnotu určitého typu atributu. Souisející pojmy Rozhraní API LDAP (Lightweight Directory Access Protocol) Další informace o rozhraních API produktu Directory Serer najdete tématu Rozhraní API LDAP (Lightweight Directory Access Protocol). Dynamické schéma Schéma je možno dynamicky měnit. K proádění dynamických změn schématu se použíá rozhraní API pro ldap_modify se jménem DN cn=schema. Současně je pooleno přidáat, mazat nebo nahrazoat pouze jeden subjekt schématu (například typ atributu nebo třídu objektu), nikoli íce subjektů zároeň. Chcete-li ymazat záznam schématu, určete atribut schématu, který definuje příslušný záznam schématu (objectclasses nebo attributetypes), a pro jeho hodnotu zadejte OID záorkách. Například, chcete-li ymazat atribut s OID <attr-oid>: dn: cn=schema changetype: modify delete: attributetypes attributetypes: ( <attr-oid> ) Roněž je možné zadat úplný popis. V každém případě poronáacím praidlem použitým při hledání subjektu schématu, který se má ymazat, je objectidentifierfirstcomponentmatch. Při přidáání nebo nahrazoání subjektu schématu MUSÍTE zadat definici LDAP Version 3 a SMÍTE zadat definici IBM. Ve šech případech musíte zadat pouze definici nebo definice subjektu schématu, které chcete postihnout. Pokud chcete například ymazat typ atributu cn (jeho OID je ), použijte ldap_modify()s: LDAPMod attr; LDAPMod *attrs[] = { &attr, NULL }; char *als [] = { "( )", NULL }; attr.mod_op = LDAP_MOD_DELETE; attr.mod_type = "attributetypes"; attr.mod_alues = als; ldap_modify_s(ldap_session_handle, "cn=schema", attrs); Chcete-li přidat noý typ atributu řádek (bar) s OID , který dědí od jména atributu a má délku 20 znaků: char *als1[] = { "( NAME bar SUP name )" NULL }; char *als2[] = { "( LENGTH 20 )", NULL }; LDAPMod attr1; LDAPMod attr2; LDAPMod *attrs[] = { &attr1, &attr2, NULL }; attr1.mod_op = LDAP_MOD_ADD; attr1.mod_type = "attributetypes"; attr1.mod_alues = als1; attr2.mod_op = LDAP_MOD_ADD; attr2.mod_type = "IBMattributeTypes"; attr2.mod_alues = als2; ldap_modify_s(ldap_session_handle, "cn=schema", attrs); Výše uedený ýraz e erzi pro LDIF by byl: dn: cn=schema changetype: modify add: attributetypes 28 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

35 attributetypes: ( NAME bar SUP name ) - add:ibmattributetypes ibmattributetypes: ( LENGTH 20) Řízení přístupu Změny dynamického schématu může proádět pouze dodaatel replikací nebo administrátor DN. Replikace Při proádění změny dynamického schématu se toto schéma replikuje. Zakázané změny schématu Přípustné jsou pouze některé změny schématu. Omezení změn zahrnují následující případy: Jakákoli změna schématu musí ponechat toto schéma konzistentním stau. Typ atributu, který je nadřazeným typem jiného typu atributu, se nesmí ymazat. Nesmí se ymazat ani typ atributu, který je typem atributu MAY nebo MUST některé třídy objektu. Nesmí se ymazat třída objektu, která je nadřazenou třídou jiné třídy. Není možné přidáat typy atributů nebo třídy objektů, které odkazují na neexistující subjekty (například syntaxe nebo třídy objektů). Typy atributů nebo třídy objektů není možné modifikoat takoým způsobem, aby nakonec odkazoaly na neexistující subjekty (například syntaxe nebo třídy objektů). Noé atributy nesmí použíat existující databázoé tabulky jejich definici IBMattributestype. Atributy, které jsou použity jakémkoli existujícím záznamu adresáře, se nesmí ymazat. Délka a syntaxe atributů se nesmí měnit. Databázoá tabulka nebo sloupec přidružený k atributu se nesmí měnit. Atributy použíané definicích existující třídy objektu se nesmí ymazat. Třídy objektu, které jsou použity jakémkoli existujícím záznamu adresáře, se nesmí ymazat. Prostřednictím modifikace schématu můžete zětšit elikost sloupce. To ám umožní prostřednictím modifikace schématu zětšit maximální délku atributů, a to buď pomocí weboé admininistrace nebo obslužného programu ldapmodify. Nejsou pooleny změny schématu, které oliňují činnost sereru. Níže uedené definice schématu jsou yžadoány sererem adresářů. Proto se nesmějí měnit. Třídy objektů: accessgroup accessrole alias os400-usrprf referral replicaobject top Atributy: aclentry aclpropagate aclsource IBM Tioli Directory Serer for i5/os (LDAP) 29

36 aliasedobjectname, aliasedentryname businesscategory cn, commonname createtimestamp creatorsname description dn, distinguishedname entryowner hassubordinates ibm-entrychecksum ibm-entrychecksumop ibm-entryuuid member modifiersname modifytimestamp name o, organizationname, organization objectclass os400-acgcde os400-astll os400-atnpgm os400-audll os400-aut os400-ccsid os400-chridctl os400-cntryid os400-curlib os400-dlry os400-docpwd os400-dspsgninf os400-eimassoc os400-gid os400-groupmember os400-grpaut os400-grpauttyp os400-grpprf os400-homedir os400-iaspstorageinformation os400-inlmnu os400-inlpgm os400-inalidsignoncount os400-jobd os400-kbdbuf os400-langid os400-lclpwdmgt 30 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

37 os400-lmtcpb os400-lmtdessn os400-locale os400-maxstg os400-msgq os400-objaud os400-outq os400-owner os400-password os400-passwordexpirationdate os400-passwordlastchanged os400-preioussignon os400-profile os400-prtde os400-ptylmt os400-pwdexp os400-pwdexpit os400-setjobatr os400-se os400-spcaut os400-spcen os400-srtseq os400-status os400-storageused os400-storageusedoniasp os400-supgrpprf os400-sys os400-text os400-uid os400-usrcls os400-usropt ou, organizationalunit, organizationalunitname owner ownerpropagate ownersource ref replicabinddn replicabindmethod replicacredentials, replicabindcredentials replicahost replicaport replicaupdatetimeinteral replicausessl seealso Syntaxe: Všechny IBM Tioli Directory Serer for i5/os (LDAP) 31

38 Poronáací praidla: Všechna Kontrola schématu Když je serer inicializoán, přečtou se soubory schématu a zkontroluje se jejich konzistence a spránost. V případě, že této kontrole neyhoí, serer neproede inicializaci a yšle chyboou zpráu. Během jakékoli změny dynamického schématu se u ýsledného schématu roněž kontroluje konzistence a spránost. Pokud této kontrole neyhoí, je rácena chyba a změna se nezdaří. Některé kontroly jsou součástí gramatiky (například typ atributu může mít nanejýš jeden nadřazený typ, ale třída objektu může mít jakýkoli počet nadřazených tříd). U typů atributů se kontrolují tyto položky: Da různé typy atributů nemohou mít stejné jméno nebo OID. Hierarchie dědičnosti typů atributů neobsahují cykly. Pro příslušný typ atributu je nutné definoat roněž nadřazený typ, i když jeho definice může být zobrazena později nebo samostatném souboru. Pokud je typ atributu podtyp jiného typu atributu, mají oba stejnou hodnotu USAGE. Syntaxe šech typů atributů může být buď přímo definoaná, nebo zděděná. Jako NO-USER-MODIFICATION mohou být označeny pouze operační atributy. U tříd objektů se kontrolují následující položky: Dě různé třídy objektů nemohou mít stejné jméno nebo OID. Hierarchie dědičnosti tříd objektů nemají cykly. Pro příslušnou třídu objektu je nutné definoat roněž nadřazené třídy, i když se její definice může objeit později nebo samostatném souboru. Pro příslušnou třídu objektu je nutné definoat roněž typy atributu MUST a MAY, i když se její definice může objeit později nebo samostatném souboru. Každá strukturní třída objektu je přímou nebo nepřímou podtřídou nejyšší třídy. Jestliže má abstraktní třída objektu nadřazené třídy, musí být tyto nadřazené třídy roněž abstraktní. Kontrola záznamu poronáním se schématem Když je prostřednictím operace LDAP přidán nebo modifikoán nějaký záznam, kontroluje se tento záznam poronáním se schématem. Standardně se proádějí šechny kontroly uedené této kapitole. Je šak možné ýběroě některé z těchto kontrol schématu zakázat změnou úroně kontroly schématu. To se proádí pomocí produktu System i Naigator změnou hodnoty pole Kontrola schématu na straně Databáze/Přípony lastností sereru adresářů. U záznamu, který má yhoět schématu, se kontrolují tyto podmínky: Pokud se týče tříd objektů: Musí mít alespoň jednu hodnotu typu atributu objectclass (třída objektu). Může mít jakýkoli počet pomocných tříd objektů četně nuly. V tomto případě se nejedná o kontrolu, ale o objasnění. Není žádná možnost tuto funkci zakázat. Může mít jakýkoli počet abstraktních tříd objektů, ale pouze jako ýsledek dědičnosti třídy. To znamená, že pro každou abstraktní třídu objektu, kterou tento záznam obsahuje, má roněž strukturní nebo pomocnou třídu objektu, která dědí přímo nebo nepřímo od této abstraktní třídy objektu. Musí mít alespoň jednu strukturní třídu objektu. Musí mít přesně jednu aktuální nebo základní strukturní třídu objektu. To znamená, že ze šech strukturních tříd objektu přiřazených k záznamu musejí být šechny nadřazenými třídami přesně jedné z nich. Nejíce odozená třída objektu se nazýá aktuální nebo základní strukturní třída objektu záznamu nebo jednoduše strukturní třída objektu záznamu. Nemůže měnit sou aktuální strukturní třídu objektu (na ldap_modify). 32 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

39 Pro každou třídu objektu patřící k záznamu se ypočítá množina šech jejích přímých i nepřímých nadřazených tříd; pokud žádná z těchto nadřazených tříd není k záznamu přiřazena, automaticky se přidá. Pokud je úroeň kontroly schématu nastaena na Verze 3 (striktní), musejí být přiřazeny šechny strukturní nadřazené třídy. Chcete-li například ytořit záznam s třídou objektu inetorgperson, je nutné určit tyto třídy objektu: person, organizationalperson a inetorgperson. Platnost typů atributů pro daný záznam je určena takto: Množina typů atributů MUST pro příslušný záznam se spočítá jako sjednocení množin typů atributů MUST šech jeho tříd objektů, četně implicitních zděděných tříd objektů. Pokud není množina typů atributů MUST pro příslušný záznam podmnožinou množiny typů atributů obsažených záznamu, je tento záznam zamítnut. Množina typů atributů MAY pro příslušný záznam se spočítá jako sjednocení množin typů atributů MAY šech jeho tříd objektů, četně implicitních zděděných tříd objektů. Pokud není množina typů atributů obsažených příslušném záznamu podmnožinou sjednocení množin typů atributů MUST a MAY pro daný záznam, je tento záznam zamítnut. Jestliže je některý z typů atributů definoaných pro příslušný záznam označen jako NO-USER- MODIFICATION, je tento záznam zamítnut. Platnost hodnot typů atributů pro daný záznam je stanoena takto: Pro každý typ atributu obsažený záznamu platí, že pokud má daný typ atributu jedinou hodnotu a záznam má íce než jednu hodnotu, je tento záznam zamítnut. Pro každou hodnotu typu atributu každého typu atributu obsaženého záznamu platí, že pokud jeho syntaxe neyhoí rutině kontroly syntaxe pro syntaxi tohoto atributu, je tento záznam zamítnut. Pro každou hodnotu typu atributu každého typu atributu obsaženého záznamu platí, že pokud je jeho délka ětší než maximální délka přiřazená k tomuto typu atributu, je tento záznam zamítnut. Platnost DN se kontroluje takto: Proádí se kontrola, zda syntaxe dodržuje BNF pro rozlišoací jména. Pokud ji nedodržuje, je tento záznam zamítnut. Oěřuje se, zda je RDN sestaeno pouze z takoých typů atributů, které jsou platné pro tento záznam. Oěřuje se, zda se daném záznamu yskytují hodnoty typů atributů použitých RDN. Souisející pojmy Schéma konfigurace sereru adresářů na stránce 248 Tyto informace popisují strom DIT (Directory Information Tree) a atributy, které se použíají při konfiguraci souboru ibmslapd.conf. Kompatibilita s iplanet Kontrolní program použíaný sererem adresářů umožňuje zadáání hodnot atributů pro typy atributů schématu (objectclasses a attributetypes) s yužitím gramatiky iplanet. Například je možné zadáat hodnoty descr a numeric-oid uzařené jednoduchými uozokami (jako kdyby to byly qdescr). Informace schématu jsou šak ždy zpřístupňoány prostřednictím ldap_search. Jakmile se (pomocí ldap_modify) proede jediná dynamická změna hodnoty některého atributu souboru, je celý tento soubor nahrazen takoým souborem, e kterém se šechny hodnoty atributů řídí specifikacemi sereru adresářů. Kontrolní program použíaný pro soubory a pro požadaky ldap_modify je stejný, proto je ldap_modify, který pro hodnoty atributů použíá gramatiku iplanet, roněž zpracoán spráně. Když je proeden dotaz na záznam podschématu sereru iplanet, může mít ýsledný záznam pro daný OID íce než jednu hodnotu. Jestliže má například určitý typ atributu dě jména (jako např. cn a commonname ), je popis tohoto typu atributu zadáán dakrát, jednou pro každé jméno. Serer adresářů může analyzoat schéma, e kterém se popis jediného typu atributu nebo třídy objektu objeí několikrát se stejným popisem (s ýjimkou NAME a DESCR). Pokud šak serer adresářů zeřejní dané schéma, uede jediný popis takoého typu atributu s yjmenoanými šemi těmito jmény (krátké jméno je uedeno prní). Zde je ueden příklad, jakým způsobem iplanet popisuje atribut obecného jména: IBM Tioli Directory Serer for i5/os (LDAP) 33

40 ( NAME cn DESC Standardní atribut SYNTAX ) ( NAME commonname DESC Standardní atribut, alias pro cn SYNTAX ) Toto je způsob, kterým je serer adresářů popisuje: ( NAME ( cn commonname ) SUP name ) Serer adresářů podporuje podtypy. Jestliže nechcete, aby cn bylo podtypem jména (které se odchyluje od standardu), můžete deklaroat toto: ( NAME ( cn commonname ) DESC Standardní atribut SYNTAX ) Prní jméno ( cn ) je poažoáno za preferoané neboli krátké jméno a šechna ostatní jména následující po cn za alternatiní jména. Od tohoto bodu dále mohou být řetězce , cn a commonname (ale také jejich ekialenty nerozlišující elká a malá písmena) rámci schématu nebo pro záznamy přidáané do adresáře použíány zaměnitelně. Zobecněný čas a UTC čas Produkt Directory Serer podporuje syntaxe zobecněného času a UTC času. Pro yznačení informací týkajících se data a času se použíají různé notace. Například čtrtý den února roce 1999 může být zapsán takto: 2/4/99 4/2/99 99/2/ FEB-1999 i s použitím mnoha dalších notací. Serer adresářů standardizuje znázornění časoého označení tím, že yžaduje od sererů LDAP podporu dou syntaxí: Syntaxe zobecněného času, která má formu: RRRRMMDDHHMMSS[.,zlomek][(+-HHMM)Z] V tomto zápise jsou čtyři číslice pro rok, dě číslice pro měsíc, den, hodinu, minutu a sekundu a olitelný zlomek sekundy. Když nejsou doplněny žádné další přídaky, předpokládá se, že se jedná o datum a čas zapsaný pro místní časoé pásmo. Chcete-li yznačit, že je čas měřen koordinoaném unierzálním čase (Coordinated Uniersal Time), připojte k času nebo rozdílu místního času elké písmeno Z. Například: " " je 6 minut, 27,3 sekund po 9. hodině odpoledne, 6. listopadu 1999, yjádřeno místním čase. " Z" je koordinoaný unierzální čas. " " je místní čas jako prním příkladu s pětihodinoým rozdílem s ohledem na koordinoaný unierzální čas. Pokud zadááte olitelný zlomek sekundy, je yžadoána tečka nebo čárka. U rozdílu místního času musí hodnotu minuty-hodiny předcházet znak + nebo -. Syntaxe unierzálního času, která má formu: RRMMDDHHMM[SS][(+ -)HHMM)Z] V tomto zápise jsou dě číslice pro každé pole, tedy pro pole roku, měsíce, dne, hodiny, minuty a olitelně sekundy. Tak jako zobecněném čase (GeneralizedTime) lze zadat olitelný časoý rozdíl. Například, jestliže je místní čas dopoledne 2. ledna 1999 a koordinoaný unierzální čas je 12 hodin (poledne) 2. ledna 1999, hodnota času UTCTime je buď: 34 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

41 " Z" nebo " " Pokud je místní čas dopoledne 2. ledna 2001 a koordinoaný unierzální čas je 12 hodin (poledne) 2. ledna 2001, hodnota času UTCTime je buď: " Z" nebo " " UTCTime umožňuje pouze zadáání dou číslic pro hodnotu roku, proto se jeho použití nedoporučuje. Podporoaná poronáací praidla jsou generalizedtimematch pro ronost a generalizedtimeorderingmatch pro neronost. Vyhledáání podřetězce není pooleno. Platné jsou například tyto filtry: generalized-timestamp-attribute= utc-timestamp-attribute>= generalized-timestamp-attribute=* Platné nejsou tyto filtry: generalized-timestamp-attribute=1999* utc-timestamp-attribute>=*1010 Doporučené postupy pro strukturu adresáře Serer adresářů se často použíá jako úložiště pro užiatele a skupiny. V této části je popsáno několik doporučených postupů pro nastaení takoé struktury adresáře, která je optimální pro spráu užiatelů a skupin. Tuto strukturu a souisející model zabezpečení lze aplikoat i na další použití adresáře. Užiatelé jsou obykle uloženi jednom nebo několika místech. Můžete mít jediný zásobník, cn=users, který je nadřazeným záznamem pro šechny užiatele, nebo samostatné zásobníky pro různé sady užiatelů, které jsou spraoány samostatně. Tak lze mít například zaměstnance, prodejce a užiatele registrující se přes Internet uloženy odděleně objektech nazaných cn=employees, cn=endors a cn=internet users. Někdy existuje tendence ukládat lidi podle organizace, do které patří; to šak může dělat problémy, když se daná osoba přesune do jiné organizace, protože záznam adresáře pak je také potřeba přesunout a roněž je potřeba aktualizoat skupiny a další datoé zdroje (jak interní tak externí zhledem k adresáři), aby reflektoaly noé DN. Vztah užiatelů k organizační struktuře lze yjádřit rámci záznamu užiatele použitím atributů adresáře, jako je o (organization name), ou (organizational unit name) nebo departmentnumber, které jsou součástí standardního schématu pro organizationalperson a inetorgperson. Obdobně se často do samostatných zásobníků umisťují skupiny, například do zásobníku jménem cn=groups. Pokud se užiatelé a skupiny organizují tímto způsobem, pak existuje jen několik míst, kde je potřeba nastait přístupoé seznamy (ACL). Podle způsobu použití sereru adresářů a podle způsobu spráy užiatelů a skupin lze použít jeden z uedených modelů přístupoé kontroly: Pokud se adresář použíá pro aplikace jako seznam adres, můžete ytořit zláštní skupinu cn=anybody, které udělíte opránění ke čtení a hledání normálních atributů zásobníku cn=users a jeho nadřazených objektech. Přístup k zásobníku cn=groups často potřebují pouze jména DN použíaná specifickými aplikacemi a administrátoři skupin. Můžete tedy ytořit skupinu obsahující DN administrátorů skupin a udělat z této skupiny lastníka zásobníku cn=groups a jeho podřazených objektů. A můžete ytořit další skupinu obsahující DN použíaná aplikacemi pro čtení skupinoých informací a udělit této skupině poolení ke čtení a hledání pro cn=groups. Pokud jsou užiatelské objekty aktualizoány přímo užiateli, budete chtít udělit speciálnímu přístupoému id cn=this appropriate opránění ke čtení, zapisoání a hledání. Pokud jsou užiatelé aktualizoáni prostřednictím aplikací, tyto aplikace jsou často spuštěny pod sou lastní identitou, a opránění aktualizoat užiatelské objekty potřebují pouze tyto aplikace. Opět platí, že je hodné dát tyto DN do jedné skupiny, např. cn=user administrators, a udělit této skupině nezbytná poolení pro cn=users. IBM Tioli Directory Serer for i5/os (LDAP) 35

42 Použijete-li tento typ struktury a kontroly přístupu, mohl by áš počáteční adresář ypadat takto: Obrázek 2. Příklad struktury adresáře c=mycompany, dc=com je lastněný administrátorem adresáře nebo jiným užiatelem či skupinou s opráněním spraoat nejyšší úroeň adresáře. Další záznamy ACL udělují přístup ke čtení pro normální atributy pro jeden z cn=anybody nebo cn=authenticated, nebo případně nějakou jinou skupinu, pokud je zapotřebí restriktinější ACL. cn=users má záznamy ACL mimo záznamy popsané níže, aby se umožnil příslušný přístup k užiatelům. Seznamy ACL mohou obsahoat: přístup ke čtení a hledání pro normální atributy pro cn=anybody nebo cn=authenticated přístup ke čtení a hledání pro normální a citlié atributy pro spráce další záznamy ACL podle potřeby, například poolující přístup k zapisoání pro jednotlice k jejich lastním záznamům Poznámky: Pro zlepšení čitelnosti byly namísto plného DN použity RDN záznamů. Například skupina user admins by měla jako člen plné jméno DN uid=app,cn=users,dc=mycompany,dc=com, ne pouze kratší uid=app. Některé užiatele a skupiny by bylo možno kombinoat. Například pokud by administrátor aplikace měl opránění spraoat užiatele, mohla by aplikace být spuštěna pod DN administrátora aplikace. To by šak mohlo přinést jistá omezení, např. schopnost změnit heslo administrátora pro aplikaci, aniž by se také nenakonfiguroalo noé heslo aplikaci. Vzhledem k tomu, že ýše uedené postupy jsou optimální pro adresáře použíané pouze jednou aplikací, mohlo by být účelnější nechat šechny aktualizace dělat s autentizací administrátora adresáře. Proti tomuto postupu hooří důody zmiňoané předchozím textu. Publikoání Produkt Directory Serer poskytuje možnost prostřednictím systému publikoat adresáři LDAP určité druhy informací. To znamená, že systém ytoří a aktualizuje záznamy LDAP předstaující různé typy dat. 36 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

43 Operační systém i5/os má estaěnou podporu publikoání následujících informací na serer LDAP: Užiatelé Když konfigurujete operační systém pro publikoání informací typu užiatelé na sereru adresářů, automaticky se proede export záznamů z distribučního adresáře systému na serer adresářů. K tomu slouží rozhraní API QGLDSSDD. Toto nastaení také synchronizuje adresář LDAP se změnami proáděnými systémoém distribučním adresáři. Publikoání užiatelů je užitečné případě, že chcete poskytnout sereru LDAP přístup k yhledáání informací ze systémoého distribučního adresáře (například poskytnout přístup k seznamu adres sereru LDAP poštoním klientům typu POP3, jako je např. Netscape Communicator nebo Microsoft Outlook Express). Publikoání užiatelů je možné použít také k podpoře oěření LDAP tehdy, když někteří užiatelé jsou publikoáni ze systémoého distribučního adresáře a jiní užiatelé jsou přidááni do adresáře jinými prostředky. Publikoaný užiatel má atribut uid, který uádí jméno užiatelského profilu, a nemá žádný atribut userpassword. Když se obdrží požadaek na spojení pro takoýto druh záznamu, serer olá zabezpečení operačního systému, aby se oěřilo, že daný uid a heslo jsou platné pro tento profil. Chcete-li použíat oěření LDAP a zároeň umožnit stáajícím užiatelům proádět oěření s yužitím jejich hesel operačního systému, zatímco osoby neyužíající operační systém i5/os by byly přidáány do adresáře manuálně, měli byste o této funkci uažoat. Další možností jak publikoat užiatele je přezít záznamy z existujícího oěřoacího seznamu HTTP a ytořit odpoídající záznamy sereru adresářů. K tomu slouží rozhraní API QGLDPUBVL. Toto API ytoří záznamy adresáře s hesly, které jsou ázány na půodní záznam oěřoacího seznamu. API lze spustit jednorázoě, nebo lze naplánoat jeho praidelné spuštění, aby se zkontroloalo, zda existují noé záznamy a tyto se přidaly do sereru adresářů. Poznámka: Toto API podporuje pouze záznamy oěřoacích seznamů ytořené pro použití s HTTP sererem (na bázi Apache). Existující záznamy sereru adresářů nebudou aktualizoány. Užiatelé, kteří jsou z oěřoacího seznamu ymazáni, se nezaznamenají. Jakmile jsou užiatelé přidáni do adresáře, mohou se autentizoat do aplikací, které oěřoání použíají, a také do aplikací, které podporují oěření LDAP. Systémoé informace Když konfigurujete operační systém pro publikoání informací systémoého typu na serer adresářů, budou publikoány tyto typy informací: Základní informace o tomto počítači a erzi operačního systému. Volitelně si můžete ybrat k publikoání jednu nebo íce tiskáren, tom případě bude systém automaticky udržoat adresář LDAP synchronizoaný, pokud se týká změn, které jsou u těchto tiskáren systému proedeny. Informace o tiskárnách, které lze publikoat, zahrnují: Umístění Rychlost e stránkách za minutu Podpora oboustranného tisku a bareného tisku Typ a model Popis Tyto informace pocházejí z popisu zařízení systému, který je publikoán. V síťoém prostředí slouží tyto informace užiatelům při ýběru tiskárny. Tyto informace se publikují popré od okamžiku, kdy je ybrána tiskárna k publikoání, a aktualizují se tehdy, když je ukončen nebo spuštěn tiskoý program nebo když se změní popis tiskoého zařízení. Sdílení tiskárny Když konfigurujete operační systém pro publikoání sdílení tiskárny, informace o sdílení ybrané tiskárny iseries NetSerer jsou publikoány na nakonfiguroaný serer Actie Directory. Publikoání sdílení tisku IBM Tioli Directory Serer for i5/os (LDAP) 37

44 Actie Directory umožňuje užiatelům přidat tiskárny systému System i na jejich praconí plochu Windows 2000 pomocí průodce Přidání tiskárny systému Windows K tomu je zapotřebí, abyste průodci pro přidání tiskárny zadali, že chcete tiskárnu yhledat e Windows 2000 Actie Directory. Sdílení tisku je nutné publikoat na takoém sereru adresářů, který podporuje schéma Microsoft Actie Directory. TCP/IP Quality of Serice Serer TCP/IP Quality of Serice (QOS) je možné konfiguroat pro použití sdílené zásady QOS definoané adresáři LDAP s yužitím definoaného schématu IBM. Publikační agent TCP/IP QOS je yužíán sererem QOS ke čtení informací zásady; definuje serer, autentizační informace a umístění, kde jsou adresáři informace o zásadě uloženy. Pomocí tohoto ýojoého prostředí můžete roněž ytořit aplikaci pro publikoání nebo yhledáání jiných druhů informací adresáři LDAP, k tomu je nutno definoat další publikační agenty a yužít rozhraní API pro publikoání adresáři. Souisející pojmy Rozhraní API LDAP (Lightweight Directory Access Protocol) Další informace o rozhraních API produktu Directory Serer najdete tématu Rozhraní API LDAP (Lightweight Directory Access Protocol). Souisející úlohy Publikoání informací na serer adresářů na stránce 126 Pomocí těchto informací můžete publikoat informace do produktu Directory Serer (sereru adresářů). Replikace Replikace je postup použíaný serery adresářů ke zýšení ýkonu a spolehliosti. Proces replikace udržuje data uložená e íce adresářích synchronizoaná. Chcete-li se o replikacích dozědět íce, prostudujte si tyto části: Souisející pojmy Úlohy týkající se replikace na stránce 142 Pomocí těchto informací proádíte spráu replikací. Proedení migrace sítě replikačních sererů na stránce 96 Následující informace použijte, pokud máte síť replikačních sererů. Přehled replikací Prostřednictím replikace se změny proedené na jednom adresáři propagují (šíří) do jednoho nebo íce dodatečných adresářů. Změna jednoho adresáře se e skutečnosti projeí několika různých adresářích. Replikace poskytuje dě hlaní ýhody: Zdojoání informací - repliky zálohují obsah sých dodaatelských sererů. Rychlejší yhledáání - požadaky na hledání mohou být namísto uložení na jediném sereru rozloženy mezi několik různých sererů, které uchoáají stejný obsah. To zlepšuje dobu odezy pro splnění požadaku. Specifické záznamy adresáři jsou doplněním třídy objektu ibm-replicationcontext označeny jako kořeny replikoaných podstromů. Každý podstrom je replikoán samostatně. Podstrom pokračuje dolů podél informačního stromu adresáře DIT (directory information tree), až dosáhne listoých záznamů nebo jiných replikoaných podstromů. Pod kořen replikoaného podstromu se přidáají záznamy, které budou obsahoat informace o topologii replikace. Tyto záznamy toří jednu nebo íce replikačních skupin, pod nimiž se ytářejí podzáznamy repliky. Ke každému replikačnímu podzáznamu jsou přiřazena ujednání o replikaci označující serery, které jsou každým sererem zabezpečoány (replikoány), ale také definice poěření a informace o časoém plánu. Adresář IBM podporuje rozšířený model replikace master-subordinate (hlaní-podřízený). Topologie replikace se rozšiřují tak, aby zahrnoaly: Replikaci podstromů DIT (Directory Information Tree - informačního stromu adresáře) na určité serery. 38 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)

45 Vícerstenou topologii, která se označuje jako kaskádoá replikace. Přiřazení role sereru (hlaní nebo replika) podstromem. Vícenásobné hlaní serery, což se označuje jako replikace peer to peer. Replikace přes brány rámci sítí. Výhodou replikace podle podstromů je to, že replika nemusí replikoat celý adresář. Je možné replikoat pouze část neboli podstrom adresáře. Rozšířený model mění koncepci hlaního sereru a repliky. Tyto ýrazy už nadále neplatí pro serery, ale spíše pro role, které má serer plnit souislosti s konkrétním replikoaným podstromem. Serer může pracoat pro některé podstromy jako hlaní serer a pro jiné jako replika. Výraz hlaní serer se použíá pro serer, který přijímá aktualizace klientů pro replikoaný podstrom. Výraz replika se použíá pro serer, který přijímá pouze aktualizace z jiných sererů určených za dodaatelský serer replikoaného podstromu. Typy sererů definoané podle funkcí při replikaci jsou: hlaní/peer, kaskádoý, brána a replika. Tabulka 1. Role sererů Adresář Hlaní/peer Hlaní/peer serer obsahuje informace o adresáři hlaního sereru, z něhož jsou šířeny aktualizace do replik. Všechny změny se proádějí a yskytují na hlaním sereru a tento hlaní serer je odpoědný za šíření těchto změn do replik. Popis V systému může být několik sererů pracujících jako hlaní serery pro informace o adresáři, přičemž každý hlaní serer je odpoědný za aktualizaci ostatních hlaních sererů a replikoaných sererů. To se označuje za peeroou replikaci. Peeroá replikace může zýšit ýkon a spolehliost. Zýšení ýkonu se dosahuje použitím místního sereru, který obsluhuje aktualizace široce distribuoané síti. Zýšení spolehliosti se dosahuje použitím záložního hlaního sereru připraeného okamžitě přezít roli hlaního sereru, pokud by primární hlaní serer selhal. Poznámky: 1. Hlaní serery replikují šechny klientské aktualizace, ale nereplikují aktualizace obdržené od ostatních hlaních sererů. 2. Aktualizace stejného záznamu proedené několika serery by mohly způsobit nekonzistence datech adresáře, protože zde neexistuje řešení konfliktů. Kaskádoý (předáací) Kaskádoý serer je replikoaný serer, který replikuje šechny změny, které jsou na něj zaslány. Tím se liší od hlaního/peer sereru, neboť hlaní/peer serer replikuje pouze změny, které jsou proáděny klienty připojenými k tomuto sereru. Kaskádoý serer může odlehčit replikační zatížení hlaních sererů síti, která obsahuje mnoho elmi rozptýlených replik. Brána Replikace přes brány yužíá serery bran k efektinímu shromažďoání a distribuci informací týkajících se replikace síti, kde replikace probíhá. Hlaním přínosem replikace přes brány je snížení proozu síti. Replika (pouze pro čtení) Replika je přídaný serer, který obsahuje kopii informací adresáře. Repliky jsou kopie hlaního sereru (nebo podstromu, jehož je replikou). Replika zajišťuje zálohoání replikoaného podstromu. Pokud replikace selže, opakuje se i tehdy, když bude hlaní serer restartoán. Pro kontrolu nezdařených replikací je možné použít okno Manage Queues e weboém nástroji administrace sereru. Všechny aktualizace je možno požadoat na replikoaném sereru, ale jednotlié aktualizace se e skutečnosti předáají na hlaní serer rácením odkazu klientoi. Jestliže je aktualizace úspěšná, hlaní serer rozešle aktualizaci na jednotlié repliky. Do doby, než hlaní serer dokončí replikaci aktualizace, se změna neodrazí na replikoaném sereru, kde byla půodně požadoána. Změny se replikují pořadí, e kterém jsou proáděny na hlaním sereru. Pokud už repliku nepoužíáte, musíte dodaatelskému sereru odebrat souhlas s replikací. Ponechání definice způsobuje, že serer řadí šechny aktualizace do fronty a užíá nepotřebný prostor adresáře. Kromě toho se dodaatel stále pokouší naazoat spojení s chybějícím odběratelským sererem a znou mu zasílat příslušná data. IBM Tioli Directory Serer for i5/os (LDAP) 39

46 Replikace přes brány Replikace přes brány yužíá serery bran k efektinímu shromažďoání a distribuci informací týkajících se replikace síti, kde replikace probíhá. Hlaním přínosem replikace přes brány je snížení proozu síti.serery bran musí být hlaní serery (schopné zápisu). Následující obrázek znázorňuje, jak replikace přes brány funguje: Obrázek 3. Replikoaná síť se serery bran Replikoaná síť na předcházejícím obrázku obsahuje tři replikační uzly, z nichž každý obsahuje serer brány. Serer brány shromažďuje replikační aktualizace z hlaních/peer sererů replikačního uzlu, e kterém se nachází, a posílá aktualizace šem ostatním sererům bran rámci replikoané sítě. Shromažďuje také replikační aktualizace od ostatních sererů bran replikoané síti a posílá tyto aktualizace na hlaní/peer serery a replikoané serery replikačním uzlu, kde se nachází. Serery bran použíají ID sererů a ID odběratelských sererů, aby určily, které aktualizace mají poslat ostatním sererům bran a které aktualizace mají poslat lokálním sererům rámci replikačního uzlu. Chcete-li nastait replikaci přes brány, musíte ytořit alespoň da serery bran. Vytořením sereru brány ytáříte replikační uzel. Pak musíte ytořit ujednání o replikaci mezi bránou a eškerými hlaními/peer serery a replikoanými serery, které chcete zahrnout do replikačního uzlu dané brány. 40 System i: Directory Serer IBM Tioli Directory Serer for i5/os (LDAP)