3.2. Історія розвитку служб каталогів

Розвиток служб каталогiв був значно зумовлений вирiшенням проблеми усунення багаторазової реєстрацiї клiєнта.

Спочатку була окрема мережева ОС. Клiєнт, входячи у мережу, реєструвався на певному серверi. У цьому випадку перевiрялися його повноваження та права доступу. Отже, клiєнт був ‘прикрiплений‘ до цього сервера. Наприклад, у Novell Netware 3.11 iнформацiя каталогу зберiгалася в базi даних ‘bindery` кожного сервера. Кожен сервер мав свою базу, i для роботи з iншим сервером потрібна була повторна реєстрацiя.

Такий же принцип діє в UNIX системах і сьогодні, тобто клієнт реєструється на кожному сервері окремо. Адміністратор повинен стежити, щоби користувачі мали однакові реєстраційні параметри на всіх серверах. Однак під час роботи з системою, що має велику кiлькiсть серверiв, перереєстрацiя є незручною.

Наступним кроком став перехiд до доменних СК. У цьому випадку користувач реєструвався один раз у визначеному доменi. Доменну систему використовували в ОС Windows NT. Заради сумісності з попередніми версіями цю систему підтримувано і в наступних версіях Windows поряд зі службою каталогів Active Directory. Доменна система є проміжною в переході від посерверного вирішення до повноцінних СК. У такій системі мережеві ресурси (комп’ютери, принтери, користувачі) ґрупують за спеціальними логічними сутностями, які називають доменами. Один домен може об’єднувати багато серверів та робочих станцій. У межах одного домену реєстрація користувачів відбувається прозоро. Інформація про ресурси зберігається централізовано на призначених для цього серверах (контролерах домену). Для зменшення тривалості часу доступу бази даних продубльовані в первинних та вторинних контролерах домену. Недоліки доменної структури: недостатня масштабованість, неможливість групування мережевих ресурсів відповідно до специфіки організації бізнес-процесів, мала кількість типів мережевих ресурсів, неможливість додавання нових типів даних та ін. Доменну архітектуру доцільно використовувати в невеликих мережах з малим набором функцій.

Iєрархiчна структура виявилася зручнішою порiвняно з доменною. Пiсля реєстрацiї користувач може працювати з усiма ресурсами дерева. Перша повноцінна служба каталогів (Netware directory service (NDS)) з’явилася в ОС Novell Netware 4.0. Пізніше розроблено служби LDAP, MS Active Directory, NIS+ та ін.

Деякі з наявних сьогодні служб каталогів (MS Active Directory, NIS+) успішно працюють у мережах тільки однієї ОС. Інші (eDirectory, LDAP) мають засоби для роботи в гетерогенних мережах. Загалом проблему роботи в гетерогенних мережах можна вирiшити, максимально поширивши найпопулярніший продукт СК або розробивши продукти-посередники, якi забезпечують взаємодiю рiзних СК (наприклад, продукт VIA фiрми Zoomit), або використовуючи єдиний протокол доступу до каталогiв (такий як LDAP або Х.500). Iсторiю розвитку конфiгурацiй СК відображено на рис. 6.15.

Розглянемо найпопулярніші СК детальніше.

Рис. 6.15. Різні органiзацiї служб каталогів

3.3. Стандарти X.500 та ldap

LDAP (Lightweight Directory access protocol) є головною СК для мереж TCP/IP завдяки підтримці IETF, а також міжнародному, не фірмовому характеру специфікації.

Спочатку міжнародні організації зі стандартизації розробили та прийняли стандарт служби каталогів X.500, що надавав багато можливостей, однак виявився занадто складним і працював тільки на потужних Unix-серверах. Водночас більшість потенційних клієнтів СК працювало на персональних комп’ютерах. Виникла потреба організувати сполучення цих клієнтів з серверами каталогів X.500 – розробити відповідний протокол, який би працював у мережах стека TCP/IP. Першими такими протоколами були Dixie (RFC-1249) та DAS (Directory Assistance Service, RFC-1202). У 1992 р. IETF почало розробляти стандарт цих протоколів, які працювали б з усіма версіями X.500. Завдяки цьому з’явився LDAP, який і затверджено як попередній стандарт 1995 р.

З часом відставання у розвитку та недостатня підтримка виробниками обладнання стандарту X.500 спонукала розробити slapd – сервер LDAP. Це дало змогу системі LDAP працювати незалежно і без систем X.500. Версію LDAP 3 затверджено як проект стандарту 1997 р.

LDAP складається з таких компонент.

• Інформаційна модель. Складається з рядків (entries). Кожний рядок має атрибут та список значень цього атрибута. Ця модель повністю відповідає моделі Х.500; дає змогу додавати іншу інформацію.

• Схема LDAP. Визначає типи елементів, інформація про які може зберігатися в БД LDAP. Визначено такі елементи, як країни, організації, користувачі, їхні групи. Сервери можуть визначити свої елементи.

• Модель найменування. Визначає структуру інформації та її позначення. Імена ієрархічні та складаються з атрибутів і значень відповідного рядка БД LDAP (рис. 6.16).

• Модель найменування LDAP походить з X.500 та сумісна з ним, однак вона гнучкіша, накладає менше обмежень.

• Модель безпеки. Розширені засоби автентифікації дають змогу клієнтам та серверам взаємно підтверджувати автентичність.

• Функційна модель визначає те, як клієнти можуть отримати інформацію в LDAP, як маніпулювати нею. LDAP передбачає виконання дев’яти базових операцій: додати, знищити, модифікувати, приєднатися (bind), від’єднатися (unbind), шукати, порівняти, припинити (abandon), змінити DN (distinguished name). Операції приєднатися та від’єднатися керують автентифікацією між серверами та клієнтами, операція пошуку дає змогу шукати користувачів та послуги на дереві каталогів, операція порівняння – застосуванням порівнювати свої значення зі значеннями в LDAP, зміна DN – змінити ім’я запису в БД, операція ‘припинити’ на вимогу клієнта припиняє поточну операцію на сервері.

Рис. 6.16. Модель найменування ресурсів в LDAP

Протокол LDAP визначає взаємодію між клієнтами та серверами і відображення на LDAP. Наприклад, протокол визначає, що окремі записи, які надходять у відповідь на команду пошуку, передаються окремими пакетами, це дає змогу передавати багато даних, не перевантажуючи мережу.

Програмні інтерфейси (API). Визначають функції та програми доступу до інформації LDAP.

Формат обміну даними (LDAP data interchange format). Простий текстовий формат для наведення записів БД і змін до них. Дає змогу синхронізувати БД LDAP з іншими базами даних.

Застосування LDAP звертаються до бази LDAP з використанням визначених API. Система LDAP надає такі сервіси:

• пошук користувачів та ресурсів мережі;

• керування ними;

• аутентифікація користувачів та ресурсів.

Використання LDAP як мережевої БД має певні обмеження а саме:

• LDAP не замінює традиційних СУБД. Він не має механізмів опрацювання транзакцій, двох фазних операцій commit, можливостей будувати звіти та розробляти застосування, його не оптимізовано для інтенсивних операцій з даними, нема єдиної мови доступу, подібної до SQL;

• LDAP не заміняє DNS, тому що DNS масово розгорнута, добре працює (хоча LDAP виконує споріднені функції);

• LDAP не замінює файлової системи. Його не пристосовано до роботи з великими бінарними файлами. Він не підтримує блокування записів та деяких інших функцій, властивих файловій системі.

В IETF над розширенням LDAP працюють дві робочі групи:

• LDAP Directory update розробляє стандарти реплікації;

• LDAP Extensions розробляє стандартні розширення до LDAP, такі як контроль доступу, розширення API.