IBM Directory Server (LDAP)

Systémy IBM - iseries IBM Directory Serer (LDAP) Verze 5, ydání 4

Systémy IBM - iseries IBM Directory Serer (LDAP) Verze 5, ydání 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 275 a publikaci IBM eserer Safety Information,. Osmé ydání (únor 2006) Toto ydání se ztahuje na erzi 5, ydání 4, modifikaci 0 operačního systému IBM i5/os (číslo produktu 5722 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, 2006. Všechna práa yhrazena.

Obsah Kapitola 1. IBM Directory Serer for iseries (LDAP)............ 1 Kapitola 2. Co je noého e erzi V5R4. 3 Kapitola 3. Tisk PDF......... 5 Kapitola 4. Koncepce sereru adresářů. 7 Adresáře................7 Rozlišoací jména (DN)...........11 Přípona (kontext pojmenoání).........14 Schéma................15 Schéma sereru adresářů IBM........16 Podpora obecného schématu.........17 Třídy objektů.............18 Atributy...............19 Identifikátor objektu (OID).........26 Záznamy podschématu..........27 Třída objektu IBMsubschema........27 Dotazy na schéma............27 Dynamické schéma...........27 Zakázané změny schématu.........28 Kontrola schématu............31 Kompatibilita s iplanet..........33 Zobecněný čas a UTC čas.........33 Publikoání...............34 Replikace...............36 Přehled replikací............36 Terminologie replikace..........39 Ujednání o replikacích..........40 Způsob uložení informací replikace na sereru...41 Hlediska zabezpečení ochrany dat pro informace replikace..............41 Replikace prostředí s ysokou dostupností....41 Sféry a užiatelské šablony..........41 Parametry prohledáání...........42 Praidla pro podporu národního jazyka (NLS)....44 Jazykoé příznaky.............44 Odkazy adresáři LDAP..........45 Transakce...............46 Serer adresářů - Zabezpečení ochrany dat.....46 Monitoroání.............46 SSL (Secure Sockets Layer) a TLS (Transport Layer Security) u sereru adresářů.........47 Autentizace Kerberos na sereru adresářů.....47 Skupiny a role.............48 Administrační přístup...........54 Proxy autorizace............55 Seznamy přístupoých prá.........55 Vlastnictí objektů adresáře LDAP.......67 Zásada pro spráu hesel..........67 Autentizace..............70 Odmítnutí služeb............73 Procedura Backend projektoaná operačním systémem..74 Stromoá struktura adresáře projektoaná užiatelem 74 Operace LDAP.............75 Připojoací DN administrátora a repliky.....79 Schéma projektoané užiatelem.......79 Serer adresářů a podpora žurnáloání i5/os....80 Jedinečné atributy.............80 Operační atributy.............80 Sereroé paměti cache...........81 Paměť cache atributů...........81 Paměť cache filtrů............82 Paměť cache záznamů...........82 Paměť cache seznamů ACL.........82 Oladače a přídané operace.........83 Kapitola 5. Začínáme s produktem Serer adresářů........... 85 Pokyny pro migraci............85 Proedení migrace z V5R3 nebo V5R2 na erzi V5R4 85 Proedení migrace dat z erzí V4R4, V4R5 nebo V5R1 na erzi V5R4...........86 Proedení migrace sítě replikačních sererů....87 Změna jména služby Kerberos........89 Plánoání sereru adresářů..........89 Konfigurace sereru adresářů.........90 Předolená konfigurace produktu Serer adresářů..91 Naplnění adresáře.............92 Publikoání informací na serer adresářů.....92 Import a export souboru LDIF........93 Kopíroání užiatelů z oěřoacího seznamu HTTP sereru do sereru adresářů.........94 Doporučené postupy pro strukturu adresáře.....96 Weboá administrace............97 Prní nastaení weboé administrace......98 Weboý nástroj administrace........99 Kapitola 6. Scénář: Nastaení sereru adresářů............. 101 Podrobnosti scénáře: Nastaení sereru adresářů... 102 Podrobnosti scénáře: Vytoření adresářoé databáze.. 103 Podrobnosti scénáře: Publikace dat iseries do adresářoé databáze............... 105 Podrobnosti scénáře: Zadáání informací do adresářoé databáze............... 106 Podrobnosti scénáře: Testoání adresářoé databáze.. 107 Kapitola 7. Jak proádět spráu sereru adresářů.......... 109 Jak spustit/zastait serer adresářů....... 110 Jak kontroloat sta sereru adresářů....... 111 Jak kontroloat úlohy na sereru adresářů..... 111 Jak spraoat připojení sereru........ 111 Jak spraoat lastnosti připojení........ 112 Jak aktioat oznámení o události....... 114 Jak specifikoat nastaení transakcí....... 115 Jak změnit port nebo IP adresu......... 115 Copyright IBM Corp. 1998, 2006 iii

Jak specifikoat serer pro adresářoé odkazy.... 116 Jak přidáat a odstraňoat přípony sereru adresářů.. 116 Jak uložit a obnoit informace o produktu Serer adresářů............... 117 Jak poskytnout administrátorský přístup projektoaným užiatelům.............. 117 Jak pracoat s administrační skupinou...... 118 Jak poolit administrační skupinu....... 118 Jak přidáat, upraoat a odstraňoat členy administrační skupiny.......... 119 Jak spraoat skupiny s limity hledání...... 119 Jak ytořit skupinu s limity hledání...... 120 Jak měnit skupinu s limity hledání...... 120 Jak kopíroat skupinu s limity hledání..... 121 Jak odstranit skupinu s limity hledání..... 121 Jak spraoat skupiny s proxy autorizací..... 121 Jak ytořit skupinu s proxy autorizací..... 121 Jak měnit skupinu s proxy autorizací...... 122 Jak kopíroat skupinu s proxy autorizací.... 122 Jak odstranit skupinu s proxy autorizací..... 122 Jak spraoat jedinečné atributy........ 122 Jak ytořit seznam jedinečných atributů.... 122 Jak odstranit záznam ze seznamu jedinečných atributů 123 Jak sledoat přístup a změny u adresáře LDAP... 123 Jak aktioat monitoroání objektů pro serer adresářů 124 Jak přizpůsobit nastaení yhledáání...... 124 Jak přizpůsobit nastaení ýkonu........ 125 Jak nastait databázoá připojení a nastaení paměti cache............... 126 Jak konfiguroat paměť cache atributu..... 126 Jak konfiguroat nastaení transakcí...... 128 Jak proádět spráu replikací......... 129 Jak ytořit topologii hlaní serer-replika.... 129 Jak ytořit topologii hlaní serer-předáací serer-replika............. 134 Přehled torby úplné replikační topologie.... 136 Jak ytořit úplnou topologii s peeroou replikací 136 Jak nastait topologii brány......... 139 Jak proádět spráu topologií........ 140 Jak měnit lastnosti replikace........ 143 Jak ytářet časoé plány replikací...... 144 Jak proádět spráu front......... 146 Jak nastait replikaci přes zabezpečené spojení... 146 Jak spraoat lastnosti zabezpečení....... 147 Jak spraoat hesla........... 147 Jak aktioat SSL a TSL (Transport Layer Security) na sereru adresářů........... 151 Jak aktioat autentizaci Kerberos na sereru adresářů 153 Jak aktioat autentizaci DIGEST-MD5 na sereru adresářů.............. 154 Jak proádět spráu schématu......... 154 Jak prohlížet třídy objektů......... 155 Jak přidat třídu objektu.......... 155 Jak editoat třídu objektu......... 156 Jak kopíroat třídu objektu......... 157 Jak ymazat třídu objektu......... 158 Jak prohlížet atributy.......... 159 Jak přidat atribut............ 160 Jak editoat atribut........... 161 Jak kopíroat atribut........... 162 Jak ymazat atribut........... 163 Jak kopíroat schéma na jiné serery...... 164 Jak proádět spráu záznamů adresáře...... 165 Jak procházet strom........... 165 Jak přidat záznam........... 165 Jak přidat záznam obsahující atribut s jazykoým příznakem.............. 166 Jak ymazat záznam........... 167 Jak editoat záznam........... 167 Jak kopíroat záznam.......... 167 Jak editoat seznamy přístupoých prá..... 168 Jak přidat pomocnou třídu objektu...... 168 Jak ymazat pomocnou třídu........ 168 Jak změnit skupinoé členstí........ 169 Jak prohledáat záznamy adresáře....... 169 Jak změnit binární atributy......... 171 Jak proádět spráu užiatelů a skupin...... 172 Jak proádět spráu užiatelů........ 172 Jak proádět spráu skupin......... 173 Jak proádět spráu sfér a užiatelských šablon.... 174 Jak ytořit sféru............ 175 Jak ytořit administrátora sféry....... 175 Jak ytořit šablonu........... 176 Jak přidat šablonu do sféry......... 177 Jak ytářet skupiny........... 178 Jak přidat užiatele do sféry........ 178 Jak proádět spráu sfér.......... 178 Jak proádět spráu šablon......... 179 Jak proádět spráu seznamů přístupoých prá (ACL) 181 Efektiní seznamy ACL.......... 182 Efektiní lastníci........... 182 Nefiltroané seznamy ACL......... 182 Filtroané seznamy ACL......... 184 Vlastníci.............. 185 Kapitola 8. Odkazy......... 187 Obslužné programy pro příkazoý řádek...... 187 ldapmodify a ldapadd.......... 187 ldapdelete.............. 191 ldapexop.............. 194 ldapmodrdn............. 199 ldapsearch.............. 202 ldapchangepwd............ 211 ldapdiff.............. 213 Jak použíat SSL s obslužnými programy příkazoého řádku LDAP......... 216 LDAP data interchange format (LDIF)...... 216 Příklad: LDIF............. 217 Podpora LDIF erze 1.......... 217 Příklad: LDIF erze 1.......... 218 Schéma konfigurace sereru adresářů....... 219 Informační strom adresáře (DIT - Directory information tree)............ 219 Atributy.............. 228 Identifikátory objektů (OID)......... 259 Kapitola 9. Odstraňoání problémů s produktem Serer adresářů.... 265 Sledoání chyb a přístupů produktu Serer adresářů pomocí protokolu úloh........... 266 Použití příkazu TRCTCPAPP k yhledání problémů.. 266 i IBM Directory Serer (LDAP)

Použití olby LDAP_OPT_DEBUG při sledoání chyb 267 Identifikátory zprá GLEnnnn......... 267 Běžné chyby klienta LDAP.......... 270 ldap_search: Timelimit exceeded....... 270 [Selháající operace LDAP]: Operations error... 271 ldap_bind: No such object......... 271 ldap_bind: Inappropriate authentication..... 271 [Selháající operace LDAP]: Insufficient access.. 271 [Selháající operace LDAP]: Cannot contact LDAP serer............... 271 [Selháající operace LDAP]: Failed to connect to SSL serer............... 271 Chyby souisející se zásadou pro spráu hesel.... 272 Odstraňoání problémů s rozhraním API QGLDCPYVL 272 Kapitola 10. Souisející informace.. 273 Dodatek. Poznámky......... 275 Ochranné známky............ 276 Ustanoení a podmínky.......... 277 Obsah

i IBM Directory Serer (LDAP)

Kapitola 1. IBM Directory Serer for iseries (LDAP) Serer adresářů IBM Directory Serer for iseries (dále označoaný jako Serer adresářů) poskytuje funkce sereru LDAP (Lightweight Directory Access Protocol) na sereru iseries. 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 na sereru iseries: Kapitola 2, Co je noého e erzi V5R4, na stránce 3 Informace o změnách a ylepšeních proedených na sereru adresářů od posledního ydání. Kapitola 3, Tisk PDF, na stránce 5 PDF erze tohoto informačního hesla. Kapitola 4, Koncepce sereru adresářů, na stránce 7 Informace o koncepcích sereru adresářů. Kapitola 5, Začínáme s produktem Serer adresářů, na stránce 85 Informace týkající se konfiguroání sereru adresářů. Kapitola 6, Scénář: Nastaení sereru adresářů, na stránce 101 Příklad nastaení adresáře LDAP na sereru adresářů. Kapitola 7, Jak proádět spráu sereru adresářů, na stránce 109 Informace o práci se sererem adresářů. Kapitola 8, Odkazy, na stránce 187 Referenční materiál souisející se sererem adresářů, jako např. obslužné programy pro příkazoý řádek a informace o LDIF. Kapitola 9, Odstraňoání problémů s produktem Serer adresářů, na stránce 265 Informace pomáhající při řešení problémů. Obsahuje nárhy pro činnost shromažďoání serisních údajů a řešení specifických problémů. Kapitola 10, Souisející informace, na stránce 273 Další informace souisející se sererem adresářů. Copyright IBM Corp. 1998, 2006 1

2 IBM Directory Serer (LDAP)

Kapitola 2. Co je noého e erzi V5R4 Produkt Directory Serer for iseries má e erzi V5R4 tato ylepšení a noé funkce: Replikace Replikace přes brány: Replikaci lze rámci replikoaných sítí proádět za použití sererů bran. Serery bran mohou efektiněji shromažďoat a distribuoat informace, a zároeň se tak redukuje objem síťoého proozu. Další informace najdete části Replikace přes brány tématu Přehled replikací na stránce 36. cn=ibmpolicies: Noý objekt zásobníku pro záznamy, které se mají sdílet mezi replikačními serery. Na rozdíl od cn=localhost, zásobníku pro záznamy, které se nereplikují, obsahuje cn=ibmpolicies informace konfiguračního typu, které je někdy potřeba replikoat. Další informace najdete tématu Přípona (kontext pojmenoání) na stránce 14. Zabezpečení Autentizace DIGEST-MD5: DIGEST-MD5 je autentizační mechanismus yužíající protokol SASL (simple authentication security layer). Když klient použije olbu Digest-MD5, heslo se nepřenáší jako čistý text a protokol zabrání útokům na bázi přehráání. Další informace najdete tématu Autentizace na stránce 70. Transport layer security (TLS): Byla přidána rozšířená operace StartTLS, která klientu umožňuje, aby přeedl nezabezpečené připojení na připojení zabezpečené pomocí TLS. Kromě toho serer podporuje 256bitoou šifroací sadu AES TLS. Další informace najdete tématu SSL (Secure Sockets Layer) a TLS (Transport Layer Security) u sereru adresářů na stránce 47 Vyhledáání Prohledáání podstromu na nuloé bázi: Všechny přípony definoané konfiguračním souboru lze prohledáat pomocí pouze jednoho yhledáacího požadaku. Tím se eliminuje potřeba ícenásobného hledání (ždy pro jednotlié přípony jako ýchozí bod hledání) při prohledáání celého adresáře. Další informace najdete tématu Jak prohledáat záznamy adresáře na stránce 169. Skupiny s limity hledání: Tato funkce umožňuje, aby administrátor přiřadil specifickým skupinám odlišné limity yhledáání naíc k obecným limitům uplatněným ůči šem užiatelům. Administrátoři tak mají yšší flexibilitu při určoání, kdo bude mít jaká yhledáací omezení na konkrétním sereru. Další informace najdete tématu Parametry prohledáání na stránce 42. Vylepšení zpracoání dereference aliasů: Výkon yhledáání, které použíá olby dereference, se ýrazně zlepší, když adresář neobsahuje žádné aliasy. Kromě toho nyní existují konfigurační olby, které přepíšou olby dereference specifikoané e yhledáacím požadaku klienta. Další informace najdete tématu Parametry prohledáání na stránce 42. Paměť cache atributů: Funkce paměti cache atributů předstauje zdokonalení ýkonu, neboť řešení yhledáacího filtru probíhá paměti namísto toho, že by počáteční řešení bylo proedeno databázi a uložilo se do paměti cache filtru. Paměť cache atributu se na rozdíl od paměti cache filtru neymaže pokaždé, když se proede operace LDAP pro přidání, modifikaci nebo ymazání. Když je serer takto nakonfiguroán, proádí automaticky nakonfiguroaných interalech úpray pamětí cache atributu a ukládá do paměti cache ty atributy, které by byly nejužitečnější, rámci maximálního objemu paměti konfiguroaného pro paměti cache atributů. Další informace najdete tématu Paměť cache atributů na stránce 81. Atributy Jedinečné atributy: Funkce jedinečných atributů zajišťuje, aby specifikoané atributy měly rámci adresáře ždy jedinečnou hodnotu. Například administrátor může chtít specifikoat, že atribut, který obsahuje číslo sociálního zabezpečení, musí být jedinečný, protože není možné, aby da lidé měli stejné číslo. Další informace najdete tématu Jedinečné atributy na stránce 80. Zachoání operačních atributů: Operační atributy creatorsname, createtimestamp, modifiersname a modifytimestamp se nyní replikují na odběratelské serery a jsou importoány a exportoány do souborů LDIF. Další informace najdete tématu Operační atributy na stránce 80. Copyright IBM Corp. 1998, 2006 3

Jazykoé příznaky: Jazykoé příznaky jsou mechanismy, které umožňují adresáři asocioat kódy přirozeného jazyka s hodnotami uloženými adresáři a které umožňují klientům dotazoat se adresáři na hodnoty, které odpoídají požadakům určitého přirozeného jazyka. Další informace najdete tématu Jazykoé příznaky na stránce 44. Skupiny Skupina administračních užiatelů: Více užiatelských DN nyní může mít téměř stejný rozsah administračního přístupu jako administrátor LDAP sereru. Tato funkce umožňuje, aby administrační úlohy proádělo několik užiatelů, aniž by museli sdílet jeden ID užiatele a heslo. Další informace najdete tématu Administrační přístup na stránce 54. Proxy autorizace: Proxy autorizace poskytuje způsob, jak se může LDAP klient připojit jako jeden užiatel ale přistupoat k cíloému adresáři jako jiný užiatel. To poskytuje klientským aplikacím íce flexibility, protože mohou proádět operace jménem íce užiatelů, aniž by se musely za každého užiatele opětoně připojoat. Další informace najdete tématu Proxy autorizace na stránce 55. Další Zdokonalení monitoru: Pomocí weboého administračního nástroje lze nyní zobrazit informace o sereru a připojení. U podpory monitoru byla proedena tato ylepšení: Obslužnost a odmítnutí služeb - Do ýstupu monitoru byly přidány noé informace, které zahrnují počty proedených operací podle typu (BIND, MODIFY, COMPARE, SEARCH atd.), délku praconí fronty, počet dostupných praconích láken, počet zprá přidaných do protokolu sereru, protokol monitoroání, chyby rozhraní příkazoého řádku (CLI), počet připojení SSL i TSL, informace o nečinných připojeních a statistiku nouzoého lákna. - Je dodán noý ýchozí bod hledání cn=workers,cn=monitor, který rací informace o praconích láknech. Paměť cache atributu - Informace o paměti cache a atributech paměti cache (konfiguroaná elikost, celkoá elikost, poměrná četnost odkazů) se zaznamenáá. - Pro nárat informací o paměti cache atributu pro protokol změn se použíá noý ýchozí bod hledání cn=changelog,cn=monitor. Podpora pro autentizoání klientských aplikací jako aktuální užiatel: Klient LDAP a obslužné programy příkazoého řádku jsou rozšířeny tak, aby podporoaly autentizaci na lokální serer adresářů jako aktuální užiatel. Toto je obzlášť užitečné pro ykonáání administračních úloh při přihlášení jako užiatel i5/os, který má k adresáři administrační opránění. Kontrola přístupu k systémoým a omezeným atributům: Nyní můžete kontroloat přístup k systémoým a omezeným atributům souisejícím s kontrolou přístupu a dalším atributům záznamů LDAP spraoaným sererem. Kopíroání užiatelů z oěřoacího seznamu do adresáře LDAP: Serer adresářů lze naplnit objekty adresáře na základě užiatelů definoaných oěřoacím seznamu stylu HTTP. Kromě toho může serer adresářů autentizoat užiatele na základě poěření zkopíroaných z oěřoacích seznamů HTTP. Tento proces umožňují noá rozhraní API. Další informace najdete tématu Kopíroání užiatelů z oěřoacího seznamu HTTP sereru do sereru adresářů na stránce 94. Odmítnutí služeb a zrušení azby u připojeného DN: Noá ylepšení umožňují, aby serer identifikoal mnoho forem útoků způsobujících odmítnutí služeb (DoS, denial of serice), zotail se po nich a překonal je. Tato ylepšení poskytují administrátorům možnost ětší kontroly a automatických úpra sereru. Další informace najdete tématu Odmítnutí služeb na stránce 73. Více administračních funkcí proáděných přes web: Více úloh lze proádět pomocí weboého administračního nástroje. Většina noých funkcí se nachází rámci noé kategorie Serer administration. 4 IBM Directory Serer (LDAP)

Kapitola 3. Tisk PDF Chcete-li prohlížet nebo stáhnout PDF erzi tohoto dokumentu, yberte si téma Serer adresářů (LDAP) (přibližně 2700 KB). Ostatní informace Chcete-li prohlížet nebo ytisknout soubory PDF souisejících publikací a čerených knih (Redbooks), prostudujte si část Kapitola 10, Souisející informace, na stránce 273. Ukládání souborů 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 soubor PDF prohlížeči (klepněte praým tlačítkem myši na ýše uedený odkaz). 2. Klepněte na olbu, která lokálně ukládá soubor PDF. 3. Vyhledejte adresář, do něhož chcete soubor PDF uložit. 4. Klepněte na Uložit (Sae). Stažení aplikace Adobe Reader K tomu, abyste mohli prohlížet nebo ytisknout tyto soubory PDF e ašem systému, potřebujete aplikaci Adobe Reader. Kopii je možné bezplatně stáhnout z weboých stránek společnosti Adobe (www.adobe.com/products/acrobat/readstep.html). Copyright IBM Corp. 1998, 2006 5

6 IBM Directory Serer (LDAP)

Kapitola 4. Koncepce sereru adresářů Serer adresářů implementuje specifikace LDAP V3 asociace Internet Engineering Task Force (IETF). Obsahuje roněž ylepšení oblasti funkčnosti a ýkonu doplněná společností IBM. Tato erze yužíá pro zálohoání IBM DB2 Uniersal Database for iseries, což zabezpečuje pro činnost LDAP integritu transakce, ysoký ýkon operací a možnost zálohoání a obnoy on-line. Spolupracuje s klienty připojenými prostřednictím protokolu LDAP V3 IETF. Informace o koncepcích a aspektech souisejících se sererem adresářů najdete těchto částech: Adresáře Rozlišoací jména (DN) na stránce 11 Přípona (kontext pojmenoání) na stránce 14 Schéma na stránce 15 Publikoání na stránce 34 Replikace na stránce 36 Sféry a užiatelské šablony na stránce 41 Parametry prohledáání na stránce 42 Praidla pro podporu národního jazyka (NLS) na stránce 44 Jazykoé příznaky na stránce 44 Odkazy adresáři LDAP na stránce 45 Transakce na stránce 46 Serer adresářů - Zabezpečení ochrany dat na stránce 46 Procedura Backend projektoaná operačním systémem na stránce 74 Serer adresářů a podpora žurnáloání i5/os na stránce 80 Jedinečné atributy na stránce 80 Operační atributy na stránce 80 Sereroé paměti cache na stránce 81 Oladače a přídané operace na stránce 83 Adresáře Serer adresářů 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 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. Copyright IBM Corp. 1998, 2006 7

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 9, 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. Další informace o schématu najdete tématu Schéma na stránce 15. 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. Další informace o operačních atributech najdete tématu Operační atributy na stránce 80. 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 9). 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 9 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. Další informace o DN najdete tématu Rozlišoací jména (DN) na stránce 11. 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 9, 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. 8 IBM Directory Serer (LDAP)

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 e-mailoé 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 555-555-1234 tjones@ibm.com +- John Smith 555-555-1235 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 Kapitola 4. Koncepce sereru adresářů 9

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: 555-555-1234 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: 555-555-1235 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ářů 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 autentizaci užiatelů. Autentizace oěřuje, zda jsou užiatelé těmi, za které se ydáají. Základním schématem autentizace 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. 10 IBM Directory Serer (LDAP)

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. 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. 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: 555-555-1234 Praidla pro uolnění 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-8. 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 \\" Kapitola 4. Koncepce sereru adresářů 11

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í. Další informace o řízení přístupu najdete tématu Serer adresářů - Zabezpečení ochrany dat na stránce 46. 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 autentizace 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 AclEntry: access-id: CN=THIS:critical:rwsc AclEntry: group: CN=ANYBODY: normal:rsc AclEntry: group: CN=AUTHENTICATED: sensitie:rcs 12 IBM Directory Serer (LDAP)

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. Další informace o rozšířených operacích najdete tématu Oladače a přídané operace na stránce 83. Syntaxe rozlišoacího jména Formální syntaxe pro rozlišoací jméno (DN) je založena na RFC 2253. Syntaxe podle BNF (Backus Naur Form) je definoána takto: <jméno> ::= <jméno-komponenty> ( <odděloač-mezera> ) <jméno-komponenty> <odděloač-mezera> <jméno> <odděloač-mezera> ::= <olitelná-mezera> <odděloač> <olitelná-mezera> <odděloač> ::= "," ";" <olitelná-mezera> ::= ( <CR> ) *( " " ) <jméno-komponenty> ::= <atribut> <atribut> <olitelná-mezera> "+" <olitelná-mezera> <jméno-komponenty> <atribut> ::= <řetězec> <kláesa> <olitelná-mezera> "=" <olitelná-mezera> <řetězec> <kláesa> ::= 1*( <keychar> ) "OID." <oid> "oid." <oid> <keychar> ::= písmena, číslice a mezera <oid> ::= <digitstring> <digitstring> "." <oid> <digitstring> ::= 1*<číslice> <číslice> ::= číslice 0-9 <řetězec> ::= *( <stringchar> <pár> ) " *( <stringchar> <speciální> <pár> ) " "#" <hex> <speciální> ::= "," "=" <CR> "+" "<" ">" "#" ";" <pár> ::= "\" ( <speciální> "\" " ) Kapitola 4. Koncepce sereru adresářů 13

<stringchar> ::= jakýkoli znak s ýjimkou <speciálního> nebo "\" nebo " <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 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. Další informace najdete tématu Jak proádět spráu záznamů adresáře na stránce 165 nebo tématu ldapmodify a ldapadd na stránce 187. 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ářů. 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 14 IBM Directory Serer (LDAP)

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. Další informace najdete tématu Jak proádět spráu schématu na stránce 154. 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). Další informace o způsobech přidáání nebo odstraňoání přípon najdete tématu Jak přidáat a odstraňoat přípony sereru adresářů na stránce 116. 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. Více informací o způsobech spráy záznamů najdete tématu Jak proádět spráu záznamů adresáře na stránce 165. Kapitola 4. Koncepce sereru adresářů 15

Další informace souisejících se schématem najdete těchto částech: Schéma sereru adresářů IBM Podpora obecného schématu na stránce 17 Třídy objektů na stránce 18 Atributy na stránce 19 Identifikátor objektu (OID) na stránce 26 Záznamy podschématu na stránce 27 Třída objektu IBMsubschema na stránce 27 Dotazy na schéma na stránce 27 Dynamické schéma na stránce 27 Zakázané změny schématu na stránce 28 Kontrola schématu na stránce 31 Kompatibilita s iplanet na stránce 33 Zobecněný čas a UTC čas na stránce 33 Schéma sereru adresářů IBM Schéma pro serer adresářů je předdefinoané, pokud šak máte další požadaky, můžete schéma změnit. Další informace o způsobu změny schématu najdete tématu Jak proádět spráu schématu na stránce 154. 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(). Další informace o těchto rozhraních API najdete tématu Rozhraní API sereru adresářů. 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 (další informace o třídách objektů - objectclasses najdete tématu Třídy objektů na stránce 18). attributetypes (další informace o typech atributů - attributetypes najdete tématu Atributy na stránce 19). IBMAttributeTypes (další informace o typech IBMAttributeTypes najdete tématu Atribut IBMAttributeTypes na stránce 21). Poronáací praidla (další informace o poronáacích praidlech najdete tématu Poronáací praidla na stránce 22). Syntaxe ldap (další informace o syntaxích ldap najdete tématu Syntaxe atributu na stránce 24). Syntaxe těchto definicí schématu je založena na RFC Verze 3 LDAP. Vzoroý záznam schématu by mohl obsahoat: objectclasses=( 1.3.6.1.4.1.1466.101.120.111 NAME extensibleobject SUP top AUXILIARY ) 16 IBM Directory Serer (LDAP)

objectclasses=( 2.5.20.1 NAME subschema AUXILIARY MAY ( ditstructurerules $ nameforms $ ditcontentrules $ objectclasses $ attributetypes $ matchingrules $ matchingruleuse ) ) objectclasses=( 2.5.6.1 NAME alias SUP top STRUCTURAL MUST aliasedobjectname ) attributetypes=( 2.5.18.10 NAME subschemasubentry EQUALITY distinguishednamematch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION SINGLE-VALUE USAGE directoryoperation ) attributetypes=( 2.5.21.5 NAME attributetypes EQUALITY objectidentifierfirstcomponentmatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryoperation ) attributetypes=( 2.5.21.6 NAME objectclasses EQUALITY objectidentifierfirstcomponentmatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryoperation SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE directoryoperation ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.5 DESC binární ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.7 DESC booleoský ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.12 DESC DN ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.15 DESC adresářoý řetězec ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.24 DESC zobecněný čas ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.26 DESC řetězec IA5 ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.27 DESC celé číslo ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.50 DESC telefonní číslo ) ldapsyntaxes=( 1.3.6.1.4.1.1466.115.121.1.53 DESC čas UTC ) matchingrules=( 2.5.13.2 NAME caseignorematch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) matchingrules=( 2.5.13.0 NAME objectidentifiermatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) matchingrules=( 2.5.13.30 NAME objectidentifierfirstcomponentmatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) matchingrules=( 2.5.13.4 NAME caseignoresubstringsmatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) Informace schématu je možné modifikoat prostřednictím rozhraní API ldap_modify. Chcete-li získat další informace, prostudujte si téma Rozhraní API sereru adresářů. Pomocí DN cn=schema můžete doplňoat, mazat nebo nahrazoat typ atributu nebo třídu objektu. Další informace najdete tématech Dynamické schéma na stránce 27 a Jak proádět spráu schématu na stránce 154. 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í. Podpora obecného schématu Adresář IBM podporuje standardní schéma adresáře, jak je definoáno těchto specifikacích: RFC erze 3 LDAP Internet Engineering Task Force (IETF), jako například RFC 2252 a 2256. Kapitola 4. Koncepce sereru adresářů 17

Directory Enabled Network (DEN) 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 také poskytuje 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ší podsystémy, jako jsou účty, služby a přístupoé body, autorizace, autentizace, zabezpečení ochrany dat a tak dále. Třídy objektů Třída objektu specifikuje sestau lastností použíaných k popisu objektu. 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ů. 18 IBM Directory Serer (LDAP)

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 Vté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. 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 Atribut objectclass na stránce 20 Atribut attributetypes na stránce 20 Atribut IBMAttributeTypes na stránce 21 Poronáací praidla na stránce 22 Praidla indexoání na stránce 23 Syntaxe atributu na stránce 24 Obecné prky 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 Kapitola 4. Koncepce sereru adresářů 19

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. 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: ( 2.5.6.6 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 2.5.6.6 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 Další informace o způsobech změny tříd objektů podporoaných sererem najdete tématu Jak proádět spráu schématu na stránce 154. 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 20 IBM Directory Serer (LDAP)

[ "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í: 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: ( 2.5.4.13 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 1.3.6.1.4.1.1466.115.121.1.15 USAGE userapplications ) Jeho OID je 2.5.4.13 Jeho jméno je description Jeho syntaxe je 1.3.6.1.4.1.1466.115.121.1.15 (adresářoý řetězec) Další informace o způsobu změny typů atributů najdete tématu Jak proádět spráu schématu na stránce 154. 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 Kapitola 4. Koncepce sereru adresářů 21

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 17 znaků jména atributu (které musí být jedinečné). Jména tabulky a sloupce databáze jsou omezena na 17 znaků. ACCESS-CLASS Klasifikace přístupu pro tento typ atributu. Je-li ACCESS-CLASS ynechán, je použita předolená hodnota normal. 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í. Tato 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 22 IBM Directory Serer (LDAP)

rozlišoání elkých a malých písmen. Poronáací praidla ronosti Poronáací praidlo OID Syntaxe caseexactia5match 1.3.6.1.4.1.1466.109.114.1 Syntaxe adresářoého řetězce caseexactmatch 2.5.13.5 IA5 Syntaxe řetězce caseignoreia5match 1.3.6.1.4.1.1466.109.114.2 Syntaxe řetězce IA5 caseignorematch 2.5.13.2 Syntaxe adresářoého řetězce distinguishednamematch 2.5.13.1 DN - rozlišoací jméno generalizedtimematch 2.5.13.27 Syntaxe zobecněného času ibm-entryuuidmatch 1.3.18.0.2.22.2 Syntaxe adresářoého řetězce integerfirstcomponentmatch 2.5.13.29 Syntaxe celočíselné proměnné - celé číslo integermatch 2.5.13.14 Syntaxe celočíselné proměnné - celé číslo objectidentifierfirstcomponentmatch 2.5.13.30 Řetězec pro zahrnutí OID. OID je řetězec obsahující číslice (0-9) a desetinné tečky (.). objectidentifiermatch 2.5.13.0 Řetězec pro zahrnutí OID. OID je řetězec obsahující číslice (0-9) a desetinné tečky (.) octetstringmatch 2.5.13.17 Syntaxe adresářoého řetězce telephonenumbermatch 2.5.13.20 Syntaxe telefonního čísla utctimematch 2.5.13.25 Syntaxe času UTC Poronáací praidla řazení Poronáací praidlo OID Syntaxe caseexactorderingmatch 2.5.13.6 Syntaxe adresářoého řetězce caseignoreorderingmatch 2.5.13.3 Syntaxe adresářoého řetězce distinguishednameorderingmatch 1.3.18.0.2.4.405 DN - rozlišoací jméno generalizedtimeorderingmatch 2.5.13.28 Syntaxe zobecněného času Poronáací praidla podřetězce Poronáací praidlo OID Syntaxe caseexactsubstringsmatch 2.5.13.7 Syntaxe adresářoého řetězce caseignoresubstringsmatch 2.5.13.4 Syntaxe adresářoého řetězce telephonenumbersubstringsmatch 2.5.13.21 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. Další informace najdete tématu Zobecněný čas a UTC čas na stránce 33. 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 Kapitola 4. Koncepce sereru adresářů 23

řazení přibližně 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. 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 24 IBM Directory Serer (LDAP)

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. Další podrobnosti o syntaxi těchto hodnot najdete tématu Zobecněný čas a UTC čas na stránce 33. 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 1000. Hodnoty celočíselných atributů syntaxe musí být rozmezí od -2147483648 do 2147483647. 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)555-5555, 555.555.5555 i +1 43 555 555 5555. 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 2000. Chcete-li se dozědět další podrobnosti, prostudujte si Zobecněný čas a UTC čas na stránce 33. 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 1.3.6.1.4.1.1466.115.121.1.3 Binární - oktetoý řetězec 1.3.6.1.4.1.1466.115.121.1.5 Booleoský - TRUE/FALSE 1.3.6.1.4.1.1466.115.121.1.7 OID Kapitola 4. Koncepce sereru adresářů 25

Syntaxe Syntaxe adresářoého řetězce 1.3.6.1.4.1.1466.115.121.1.15 Syntaxe popisu praidla obsahu DIT 1.3.6.1.4.1.1466.115.121.1.16 Syntaxe popisu praidla DITStructure 1.3.6.1.4.1.1466.115.121.1.17 DN - rozlišoací jméno 1.3.6.1.4.1.1466.115.121.1.12 Syntaxe zobecněného času 1.3.6.1.4.1.1466.115.121.1.24 Syntaxe řetězce IA5 1.3.6.1.4.1.1466.115.121.1.26 Popis typu atributu IBM 1.3.18.0.2.8.1 Syntaxe celočíselné proměnné - celé číslo 1.3.6.1.4.1.1466.115.121.1.27 Syntaxe popisu syntaxe LDAP 1.3.6.1.4.1.1466.115.121.1.54 Popis praidla poronáání 1.3.6.1.4.1.1466.115.121.1.30 Popis použití praidla poronáání 1.3.6.1.4.1.1466.115.121.1.31 Popis formy jména 1.3.6.1.4.1.1466.115.121.1.35 Syntaxe popisu třídy objektu 1.3.6.1.4.1.1466.115.121.1.37 Řetězec pro zahrnutí OID. OID je řetězec obsahující číslice (0-9) a desetinné tečky (.). Další informace najdete tématu Identifikátor objektu (OID). OID 1.3.6.1.4.1.1466.115.121.1.38 Syntaxe telefonního čísla 1.3.6.1.4.1.1466.115.121.1.50 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. Další informace najdete tématu Zobecněný čas a UTC čas na stránce 33. 1.3.6.1.4.1.1466.115.121.1.53 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 (International Telecommunication Union). Další informace o registraci jména organizace můžete nalézt na weboých stránkách ANSI (www.ansi.org). Arc OID úřadu ANSI pro organizace je 2.16.840.1. ANSI přiřadí číslo (NEWNUM) a ytoří noý podstrom arc OID: 2.16.840.1.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 2.16. 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 (www.iso.ch). 26 IBM Directory Serer (LDAP)

Úřad IANA (Internet Assigned Numbers Authority) přiděluje soukromým podnikům čísla OID podstromu arc 1.3.6.1.4.1. IANA přidělí číslo (NEWNUM) tak, aby noý arc OID byl 1.3.6.1.4.1.NEWNUM. Tato čísla je možné získat na weboých stránkách IANA (www.iana.org). 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 1.1.1. Žádné jiné organizaci nebyl přidělen OID, který začíná 1.1.1. Řadu pro LDAP můžete ytořit připojením.1, což ytoří 1.1.1.1. Dále je možno dělit tuto řadu do řad pro třídy objektů (1.1.1.1.1), typy atributů (1.1.1.1.2) a tak dále, a přiřadit OID 1.1.1.1.2.34 atributu foo. 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 se použíá pouze záznamu podschématu, a to takto: ( 1.3.18.0.2.6.174 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 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=* 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. Další informace o rozhraní API pro ldap_search najdete tématu Rozhraní API sereru adresářů. Dynamické schéma K proádění změn dynamického 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. Kapitola 4. Koncepce sereru adresářů 27

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 2.5.4.3), použijte ldap_modify()s: LDAPMod attr; LDAPMod *attrs[] = { &attr, NULL }; char *als [] = { "( 2.5.4.3 )", 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 20.20.20, který dědí od jména atributu a má délku 20 znaků: char *als1[] = { "( 20.20.20 NAME bar SUP name )" NULL }; char *als2[] = { "( 20.20.20 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 attributetypes: ( 20.20.20 NAME bar SUP name ) - add:ibmattributetypes ibmattributetypes: (20.20.20 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. 28 IBM Directory Serer (LDAP)

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. 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 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 Kapitola 4. Koncepce sereru adresářů 29

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 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 30 IBM Directory Serer (LDAP)

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 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 Kapitola 4. Koncepce sereru adresářů 31

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 iseries Naigator změnou hodnoty pole Kontrola schématu na straně Databáze/Přípony lastností sereru adresářů. Další informace o atributech konfigurace schématu najdete tématu Schéma konfigurace sereru adresářů na stránce 219. 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). 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. 32 IBM Directory Serer (LDAP)

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: ( 2.5.4.3 NAME cn DESC Standardní atribut SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.4.3 NAME commonname DESC Standardní atribut, alias pro cn SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) Toto je způsob, kterým je serer adresářů popisuje: ( 2.5.4.3 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: ( 2.5.4.3 NAME ( cn commonname ) DESC Standardní atribut SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) 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 2.3.4.3, 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 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/4 4.2.1999 04-FEB-1999 is 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] Vtomto 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í Kapitola 4. Koncepce sereru adresářů 33

č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: "19991106210627.3" je 6 minut, 27,3 sekund po 9. hodině odpoledne, 6. listopadu 1999, yjádřeno místním čase. "19991106210627.3Z" je koordinoaný unierzální čas. "19991106210627.3-0500" 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 hodiny-minuty předcházet znak + nebo - Syntaxe unierzálního času, která má formu: RRMMDDHHMM[SS][(+ -)HHMM)Z] Vtomto 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ď: "9901021200Z" nebo "9901020700-0500" 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ď: "0101021200Z" nebo "0101020700-0500" 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=199910061030 utc-timestamp-attribute>=991006 generalized-timestamp-attribute=* Platné nejsou tyto filtry: generalized-timestamp-attribute=1999* utc-timestamp-attribute>=*1010 Publikoání Operační systém i5/os 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. Operační systém i5/os má estaěnou podporu publikoání následujících informací na sereru 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 34 IBM Directory Serer (LDAP)

QGLDSSDD. Toto nastaení také synchronizuje adresář LDAP se změnami proáděnými systémoém distribučním adresáři. Informace o rozhraní API QGLDSSDD najdete tématu Rozhraní API sereru adresářů tématu Programoání. 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 klientům elektronické pošty typu POP3, jako např. Netscape Communicator nebo Microsoft Outlook Express, opráněným k tomu sererem LDAP). Publikoání užiatelů je možné použít také k podpoře autentizace 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 autentizaci LDAP a pokud byste chtěli umožnit stáajícím užiatelům proádět autentizaci 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í autentizaci LDAP. Další informace o rozhraní API QGLDPUBVL najdete tématu Rozhraní API sereru adresářů tématu Programoání. 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 Kapitola 4. Koncepce sereru adresářů 35

Když konfigurujete operační systém pro publikoání sdílení tiskárny, informace o sdílení ybrané tiskárny NetSerer iseries jsou publikoány na konfiguroaném aktiním sereru adresářů. Publikoání sdílení tisku aktiním adresáři umožňuje užiatelům pomocí průodce systému Windows 2000 přidat tiskárny systému iseries na jejich praconí plochu Windows 2000. K tomu je zapotřebí, abyste průodci pro přidání tiskárny zadali, že chcete tiskárnu yhledat aktiním adresáři Windows 2000. 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. Další informace najdete tématu Publikoání informací na serer adresářů na stránce 92 a Rozhraní API sereru adresářů tématu Programoání. 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á. Další informace o způsobech spráy replikací najdete tématu Jak proádět spráu replikací na stránce 129. Chcete-li se o replikacích dozědět íce, prostudujte si tyto části: Přehled replikací Terminologie replikace na stránce 39 Ujednání o replikacích na stránce 40 Způsob uložení informací replikace na sereru na stránce 41 Hlediska zabezpečení ochrany dat pro informace replikace na stránce 41 Replikace prostředí s ysokou dostupností na stránce 41 Přehled replikací 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. 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. 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. Vícerstenou topologii, která se označuje jako kaskádoá replikace. Přiřazení role sereru (hlaní nebo replika) podstromem. 36 IBM Directory Serer (LDAP)

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 dodaatele 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 dodaateli 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ěratelem a znou mu zasílat příslušná data. Replikace přes brány Kapitola 4. Koncepce sereru adresářů 37

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í (schopné zápisu). Následující obrázek znázorňuje, jak replikace přes brány funguje: Obrázek 2. 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ěratelů, 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. Serery bran musí být hlaní (schopné zápisu). Budete-li se pokoušet přidat třídu objektu brány - ibm-replicagateway - k podzápisu, který není hlaní, rátí se ám chyboá zpráa. 38 IBM Directory Serer (LDAP)