3.4. Служба каталогів eDirectory

Загальна характеристика eDirectory

В основі архітектурної концепції Netware є eDirectory (Служба каталогів Netware, попередня назва – Netware Directory Services -NDS). Згідно з цією концепцією всі ресурси мережі зображені об’єктами, занесеними в спеціальну розподілену базу даних - Netware Directory Database. Визначено різні можливі типи об’єктів: користувач, сервер, том, група користувачів та ін. Окремі об’єкти можуть відображати як реальні (наприклад, комп’ютер або користувач), так і абстрактні сутності. Ці об’єкти згруповані в ієрархічному дереві. Ієрархічна деревоподібна структура відображає взаємну підпорядкованість об’єктів. Кожен об’єкт конкретного типу має власний набір властивостей та їхніх значень. Зокрема, об’єкт типу ‘користувач’ має такі властивості: ім’я, пароль, поштову адресу, адресу електронної пошти, номер телефону, належність до груп користувачів тощо. Людина, що працює в мережі, а також і зовнішня програма, може аналізувати властивості об’єктів у eDirectory.

Служба eDirectory повністю відповідає стандарту X.500 і діє на базі структури об’єктів, яку називають деревом каталогів (Directory tree). Вона має три структурні типи об’єктів:

• кореневий об’єкт (Root );

• контейнерний об’єкт (Container object);

• кінцевий об’єкт (Leaf object).

Кожне дерево має тільки один кореневий об’єкт. Йому умовно відповідає об’єкт - весь світ. Контейнерні містять інші об’єкти. Кінцеві об’єкти є головними, з якими працюють.

Контейнерні об’єкти, як уже зазначено, містять інші об’єкти. Вони призначені для організації та групування кінцевих об’єктів. Визначено такі типи контейнерних об’єктів:

• C - Країна (Country) - містить код позначення країни та не є обов’язковим. Кожне дерево може мати не більше одного рівня країн.

• O- Організація (Organization) містить назву організації та є обов’язковим. Кожне дерево повинно мати не менше одного об’єкта цього типу. Однак допустимий тільки один структурний рівень об’єктів-організацій.

• OU - Організаційний підрозділ (Organizational Unit) зберігає інформацію про певний підрозділ організації та його параметри. Кількість об’єктів OU у дереві довільна, вони можуть бути довільно вкладені один в одний.

Згідно з вимогами стандарту X.500 eDirectory підтримує і такі контейнерні об’єкти, як

• S – Штат (State) містить позначення певного штату США;

• L – Розташування (Location) визначає розміщення ресурсу.

Кiнцевi об’єкти. Для кінцевих об’єктів використовують позначення CN (Common Name). Для зручності наведення кінцевих об’єктів згрупуємо їх відповідно до функційного призначення.

Зазначимо, що об’єктом eDirectory є не сам фізичний об’єкт (сервер або принтер), а лише інформація про нього, що зберігається у розподіленій базі даних. Кількість типів можливих об’єктів у eDirectory є змінною. Базова версія Netware 5 визначає 34 класи об’єктів, які не можуть бути знищені. Novell Netware API дає змогу розробникам застосувань визначати нові типи об’єктів або ж додавати нові властивості до наявних. Наприклад, використання Windows у мережі відображене застосуванням об’єктів, що відтворюють специфіку цієї ОС. Водночас кожен новий тип об’єкта повинен бути зареєстрований у Novell Developer Support, щоб уникнути суперечностей та спотворень даних.

Приклад дерева для гіпотетичного міжнародного університету зображений на рис. 6.17.

Іменування об’єктів eDirectory

Для правильної роботи eDirectory перед її запровадженням потрібно розробити систему правил називання об’ктів. Им’я об’єкта для зручності роботи користувачів повинно віддображати його функційне призначення.

Деякі компоненти назв задає сама система. До них належать типи імен. Позначення типів визначені у стандарті X.500. Наприклад, контейнерні об’єкти мають такі позначення: С - країна, L - розміщення, S - штат, O - організація, OU – підрозділ. Для позначення типу кінцевого об’єкта зарезервовано одне позначення - CN.

Розрізняють такі імена.

Повні ідентифікаційні (Distinguished name). У них відображено шлях від об’єкта до кореня дерева. Корінь дерева в імені не зазначено. Наприклад, повне ім’я для користувача VCoval таке: cn=vcoval.ou=ailab.ou=computer.ou=lviv.o=tech_univ.

Відносне ім’я (relative distinguished name), тобто ім’я щодо поточного контейнера. Наприклад, якщо поточний контейнер ailab, то відносне ім’я користувача Vcoval буде cn=vcoval. Для забезпечення унікальності відносних імен eDirectory не дає змоги створювати в одному контейнері декілька об’єктів з однаковими іменами (навіть різних типів.)

Рис.6.17. Дерево каталогів для міжнародного університету

Часткове ім’я (partial name), тобто ім’я щодо якогось проміжного контейнера. Приклад часткового імені:

cn=vcoval.ou=ailab. Воно визначене щодо контейнера ou=computer.ou=tech_univ.

Для зручності роботи, крім типізованих імен, у яких зазначено типи кожного об’єкта, визначені також нетипізовані імена, у яких типи об’єктів називати не треба. Наприклад, повне нетипізоване ім’я для об’єкта server таке: server.ailab.computer.lviv.tech_university.

Аналогічно до того, як під час роботи з файловою системою визначено поточний каталог, під час роботи з eDirectory треба брати до уваги місце (контейнер), щодо якого визначають відносні імена. Адресу такого контейнера називають контекстом. Наприклад, контекстом для користувача vcoval є ailab.computer.lviv.tech_university.

Поточний контекст змінюють спеціальною командою CX; її аргументом стає адреса певного контейнера, який і стає поточним.

Використання крапок у позначенні контексту таке: крапка всередині імені розділяє частини; крапка спочатку (ліворуч) означає, що треба ігнорувати поточний контекст і шукати з кореня дерева. Наприклад, .boston.tech_univ свідчить про те, що треба визначити контекст, починаючи з кореня. У кінці імені (праворуч) може бути декілька крапок. Кожна з них переміщує на один контейнер уверх. Наприклад, якщо поточний контекст ailab.computer.lviv.tech_univ, то команда cx boston.. змінить контекст на boston.tech_univ.

Імена деяких об’єктів повинні бути унікальними в межах мережі (файлові сервери та сервери друкування). Це пов’язано з роботою протоколу SAP (Service advertisement protocol).

Схема Netware Directory database та керування нею

База даних eDirectory, як і будь-яка інша база даних, має схему. Схема eDirectory містить правила, які використовуються під час створення об’єктів eDirectory, опису їхніх властивостей, виконання всіх операцій з eDirectory. Для поліпшення продуктивності схему eDirectory зберігають на кожному сервері Netware.

Визначення схеми передбачає таке:

• класи об’єктів визначають певний тип об’єкта та інкапсулюють його властивості;

• типи властивостей (для кожного об’єкта класу визначають перелік його властивостей);

• синтаксис властивостей (визначають правила запису значення властивості);

• кожен об’єкт eDirectory належить до певного класу, від чого залежать його властивості.

Клас визначають за такими компонентами:

• Structure rules – залежності між об’єктами в дереві. Правила називання (Naming properties), правила вкладення об’єкта в контейнер (Containment Class);

• Super classes - суперклас для заданого класу. Через визначення супекласів у схемі eDirectory описують використання одних класів для побудови інших;

• Mandatory properties – обов’язкові властивості об’єкта;

• Optional properties – необов’язкові властивості об’єкта;

• Object class flags – прапорці класів. Визначають, наприклад, що за даний клас відповідає контейнерам, поточний статус, заборону знищення.

Нові типи об’єктів запроваджують шляхом визначення нового класу.Для роботи зі схемою використовують утиліту Schema Manager. Функції утіліти: перегляд об’єктів та властивостей, розширення схеми, створення нових класів і властивостей; додавання властивостей до наявних класів, звіти про стан вибраного класу.

Керування доступом до об'єктів eDirectory

Система обмежень доступу до об'єктів eDirectory розділяє всі права доступу на дві групи:

• Права на об’єкти;

• Права на властивості

Права на об'єкти задають обмеження доступу до об'єкта як єдиного цілого. Об'єкт можна створювати, знищувати, перейменовувати, однак немає доступу до його конкретних властивостей. Права на властивості задають для кожної властивості об'єкта окремо. Вони дають змогу читати значення властивості, змінювати його, шукати. Якщо якомусь об'єкту (наприклад, користувачу) присвоєно якесь право доступу до іншого об'єкта (наприклад, тому), то перший об'єкт (користувача) називають довірителем (довіреною особою, trustee) другого об'єкта. Головні права доступу наведені у таблицях 6. 8., 6.9.

Таблиця 6.8. Права на об’єкти

Позначка	Назва	Зміст права
S	Supervise - адміністрування	Дає всі права на об'єкт та його властивості. Право адміністрування може бути блоковане за допомогою IRF нижче того місця дерева, де його виділено
B	Browse – перегляд	Право бачити об'єкт у дереві. Якщо триває шукання об'єкта, це право дає змогу знаходити об'єкт
C	Create - створення	Право створювати новий об'єкт у межах заданого контейнерного об'єкта.
D	Delete - знищення	Дає змогу знищити об'єкт з дерева каталогів. Контейнерний об'єкт можна знищити, якщо попередньо знищити всі його кінцеві об'єкти.
R	Rename - перейменування	Дає змогу змінювати ім’я об’єкта

Таблиця 6.9. Права на властивості

Позначка	Назва	Зміст права
S	Supervise - адміністрування	Всі права на властивість. Це право може бути блоковане IRF на нижчому рівні дерева
C	Compare – порівняння	Дає змогу порівнювати довільне значення зі значенням властивості. Не забезпечує змоги бачити значення властивості
R	Read - читання	Дає змогу читати значення властивості. Передбачає право “Сompare”
W	Write - записування	Дає змогу додавати, змінювати або знищувати значення у властивостях. Це право передбачає право “Add or delete self ” та еквівалентно праву “Supervise”
A	Add or delete self – додавання або знищення свого об’єкту	Дає змогу додавати або знищувати себе як частину властивості. Діє в таких списках, як списки членів групи. Інші частини списків змінювати не можна

Кожен об’єкт має серед властивостей компоненту, яку називають Access Control List(ACL). ACL - це список об'єктів-довірених осіб цього об'єкта з зазначенням їхніх прав. Приклад ACL показано на рис. 6.18.

Trustees of this object: student (Довірителі об'єкту: студент )
property, rights, trustee (властивість, права, довірителі.)
[All properties right]	[ R ]	another_student
[Object rights]	[ R ]	another_student
[All properties rights]	[CRWAS]	admin
City	[CRWA ]	a_student

Рис. 6.18. Приклад ACL

З метою спростити призначення прав виділено такі дві групи прав: усі права на властивості та всі права на об'єкт. Виділені права позначають їхньою першою літерою. Якщо право не виділене, то відповідної літери немає. У третій колонці рис. 6.18 наведено об'єкти, що мають ці права.

Кожному об'єкту на рівні контейнера або директорії можна бути виділити певні права. В цьому випадку ці права успадковують усі для всіх об'єкти цього контейнера або всі вкладені директорії. Для обмеженого успадкування прав використовують фільтр наслідуваних прав (Inherited Rights Filter IRF), тобто список прав, для яких треба обмежити успадкування вниз по дереву. Приклад визначення IRF зображено на рис. 6.19.

Inherited rights filters (Фільтр успадкованих прав)
[Object rights]	[CR A ]
City	[CRWA ]

Рис. 6.19. Приклад фільтра успадкованих прав.

У лівій частині списку фільтрів успадкованих прав зазначено всі права, на які задано фільтри, у правій частині в квадратних дужках – усі права, які успадковують. Розглянемо приклад успадкування прав та використання фільтрів успадкованих прав (рис. 6.20). Користувачу Ніку на рівні контейнера SALES виділено набір прав на контейнер [ BCDR]. У цьому списку немає права S. Такі права користувач Нік автоматично успадковує на всі вкладені у контейнер об'єкти: профайл MANAGEMENT, групу ACCOUNTING, відображення каталогу SPREADSHEET. Водночас, для об'єкта SPREADSHEET задано IRF [SB ]. Тому користувач Нік для цього об'єкта має в ефективних правах тільки [ B ]. Для групи ACCOUNTING взагалі задано порожній фільтр успадкування. Тому Нік для цієї групи ніяких прав не успадковує.

Рис. 6.20 Приклад успадкування та фільтрування прав.

Кожен об’єкт-користувач за правами може бути прирівняний до іншого об'єкта. Однією з властивостей об'єкта-користувача є список, який називають “еквівалентність прав” (security equivalence). У цьому списку задані інші об'єкти (користувачі, групи користувачів, посадові особи), які за правами еквівалентні правам цього користувача. Присвоєння прав через список еквівалентності - це найшвидший спосіб присвоєння прав користувачу, що не потребує глибокого обдумування деталей прав доступу; його використовують для тимчасового присвоєння прав. Вислідні права користувача, які формуються як комбінація прав ACL, успадкованих прав, прав, присвоєних через еквівалентність, називають ефективними правами.

Проектування eDirectory

Проектування eDirectory має на меті ефективну організацію ресурсів мережі, забезпечення можливостей її постійного розвитку, зручність адміністрування. Правильно спроектована eDirectory ліпше працює, у ній виникає менше помилок, і в цілому вона дешевша у підтримці. Під час проектування не можна просто скопіювати організаційну структуру підприємства в eDirectory, оскільки потрібно враховувати реальне розташування обладнання та вимоги доступу до нього. Наприклад, нехай принтер розміщено в одному з відділів, проте ним користуються декілька інших відділів. Тоді ліпше розмістити об’єкт „Принтер” у контейнері, спільному для всіх відділів. Перед початком інсталювання eDirectory треба розробити угоду про іменування об’єктів, схему дерева та стратегію його оновлення.

Проектування eDirectory можна розділити на такі етапи:

• збирання документів про компанію;

• проектування верхніх рівнів дерева;

• проектування нижніх рівнів дерева.

Під час збирання документів вивчають та складають такі документи:

• карту регіональної мережі з зазначенням маршрутизаторів, каналів, перепускних здатностей, окремих локальних мереж, з'єднаних цими каналами; схему кампусної мережі;

• список ресурсів, серверів, робочих станцій, принтерів. Кожен ресурс записують у таблицю з зазначенням місця розміщення (відділу, організації);

• організаційну структуру підприємства.

Проектування верхніх рівнів дерева враховує териториальний розподіл компанії, а також перепускну здатність каналів зв'язку, яким з'єднано окремі підрозділи. У цьому разі система має вигляд піраміди. Це означає, що на кожному наступному рівні відбувається поділ на дві-три гілки. Альтернативою є пласка система, в якій на одному з рівнів виникає розгалуження на багато гілок. У такій системі бувають проблеми з підтримкою реплік, вона незручна для адміністрування.

Окремий випадок – проектування eDirectory для невеликої фірми. Фірму вважають невеликою, якщо вона має до 1000 об’єктів та використовує надійні й високошвидкісні канали зв’язку. Для такої мережі ліпше:

• зберігати базу даних в одному розділі;

• мати тільки одне дерево каталогів та один об”єкт типу ‘організація’ у ньому.

Якщо фірма більша за розмірами або ж має повільні чи ненадійні канали зв’язку, то її ліпше розділити на частини, з’єднані цим каналами. Кожна частина повинна мати свої сервери eDirectory, де зберігатиметься інформація про локальні об’єкти. Якщо в кампусній мережі декілька будинків з’єднані повільними каналами, то треба розділити eDirectory на частини, які відповідають цим будинкам. Для ресурсів, об'єднаних локальною мережею, виділяють нижні рівні дерева. Структура дерева на нижніх рівнях відповідає організаційній структурі підприємства. Таке дерево легко перебудувати у випадку зміни структури.