Організація серверу служби каталогів для підприємства програмними засобами OpenLDAP

ЗМІСТ ВСТУП

1. СЛУЖБА КАТАЛОГІВ. ТЕХНОЛОГІЯ ОPENLDAP

1.1 Опис впроваджуваної технології

1.2 Вимоги замовника до проекту

2. РОЗРОБКА СТРАТЕГІЇ ВПРОВАДЖЕННЯ ТА РЕАЛІЗАЦІЇ ПРОЕКТУ

3 УСТАНОВКА І НАСТРОЙКА СЕРВЕРА СЛУЖБИ КАТАЛОГІВ ЗАСОБАМИ OPENLDAP

3.1 Установка і настройка сервера

3.2 Настройка клієнтів Windows

ВИСНОВКИ ТА ПРОПОЗИЦІЇ

ПЕРЕЛІК ПОСИЛАНЬ

ВСТУП У користувачів стали виникати проблеми з пошуком людей та їх поштових адрес. Очевидною стала необхідність у великих спеціалізованих базах даних, які б зберігали тисячі, а то і мільйони записів, а також в механізмах доступу до цих даних по мережі, включаючи надійну аутентифікацію.

Взагалі, у світі UNIX завжди існували методи і утиліти пошуку, типу finger або whois, але вони добре працювали, в основному, в масштабах одного сервера — і для нових реалій не підходили.

Завдання полягало у створенні централізованих адресних книг для цілих корпорацій з розвиненою мережею відділень, а також з міжнародними філіями, які підключаються по Інтернету. До всього, було прийнято рішення зробити цей каталог платформонезалежним. Тому IBM, Lotus, Microsoft і Netscape домовилися про застосування єдиного методу доступу — LDAP — для доступу до адресної інформації. До цієї угоди доклали зусилля і багато інших грандів мережевого комп’ютингу, наприклад Sun і Novell.

При адмініструванні мережі на певному етапі виникає проблема централізованого контролю аутентифікації. Це особливо актуально для великих мереж (100 і більше користувачів). Раніше єдиним прийнятним виходом у такій ситуації була установка Novell Netware як центрального сервера, або служби NIS, якщо мережа заснована на nix машинах, що буває досить рідко. У Netware (версії 4 і старше) існує дуже грамотний механізм NDS (служба директорій Novell), що дозволяє створити єдине дерево мережі, в якому кожен компонент мережі є об'єктом служби директорій. Причому кожен об'єкт володіє певними параметрами для його ідентифікації. Наприклад, об'єкт користувач має своє ім'я, телефон, відділ, службове становище, скрипт для входу в систему. Кожен користувач має певні права, деякі з яких успадковуються з прав групи, якій даний користувач належить. При вході в систему каталогів, користувач отримує доступ тільки до «своїх» файлів. При цьому сама система каталогів може перебувати на декількох серверах.

В цій роботі я зроблю установку і настройку серверу служби каталогів на базі відкритого протоколу OpenLDAP. Це дозволить користувачам більш мобільно і продуктивно працювати в корпоративній мережі.

1 СЛУЖБА КАТАЛОГІВ. ТЕХНОЛОГІЯ OPENLDAP

1.1 Опис впроваджуваної технології

Служба каталогів (англ. Directory Service) — засіб ієрархічного подання ресурсів, що належать деякій окремо взятій організації, та інформації про ці ресурси. Під ресурсами можуть розумітися матеріальні ресурси, персонал, мережеві ресурси і т. д.

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

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

Каталоги мають тенденцію містити описову інформацію, засновану на атрибутах, і підтримують складні способи фільтрації. Каталоги зазвичай не підтримують механізми транзакцій і відкатів (roll-back), що застосовуються в СУБД, орієнтованих на комплексні поновлення великого обсягу даних. Оновлення в каталогах (якщо вони взагалі дозволені), зазвичай відбуваються за простою схемою: «змінити все або нічого». Каталоги зазвичай оптимізуються на якнайшвидшу видачу результату при пошуку серед великих обсягів інформації. Вони також можуть мати можливість реплікації інформації, тобто створення віддалених копій каталогу з метою підвищення доступності інформації, надійності її зберігання і зниження часу відгуку. У процесі реплікації, до повного її закінчення, допустима тимчасова неузгодженість інформації між репліками.

Існує багато методів організації служби каталогів. Відмінності можуть стосуватися типів інформації, збереженої в каталозі, висунення різних вимог до звернення і оновлення цієї інформації, посиланням на неї, організації системи розмежування доступу до інформації, і т. д. Деякі служби каталогів можуть бути локальними, що надають послуги в обмеженому контексті (наприклад, для служби finger на окремій машині). Інші служби глобальні, надають послуги в набагато ширшому контексті (наприклад, всьому Internet). Глобальні служби зазвичай є розподіленими. Це означає, що міститься в них інформація розподілена між багатьма комп’ютерами, взаємодіючими один з одним для надання послуг служби каталогів. Зазвичай глобальна служба каталогів визначає уніфікований простір імен, щоб користувач отримував однаковий результат незалежно від того, звідки він виробляє запит і до якого сервера служби звертається.

Веб-каталог, такий як Open Directory Project, — хороший приклад служби каталогів. Ця служба каталогізує веб-сторінки і спеціально розроблена для перегляду та пошуку.

Деякі приводять Domain Name System (DNS) як приклад глобально розподіленої служби каталогів, однак DNS не доступний ні для перегляду, ні для пошуку в прямому сенсі цього слова. Більш правильно було б назвати його глобально розподіленої службою відповідей на конкретно поставлені питання.

Служби каталогів мають цілий ряд комерційних і вільних програмних реалізацій.

комерційні:

— MS Active Directory

— Novell NDS

— iPlanet Directory

некомерційні:

— OpenLDAP

— Apache Directory Server

— Fedora Directory Server в 2009 році перейменовано в 389 Directory Server

У загальному випадку, службу каталогів можна використовувати, коли нам потрібне надійне зберігання інформації з можливістю централізованого управління та доступу до неї, з використанням стандартизованих методів.

Ось ряд найпоширеніших прикладів промислового використання служб каталогів:

— Ідентифікація комп’ютерів

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

— Угруповання користувачів (у тому числі системні групи)

— Адресні книги

— Подання штатно-кадрової структури організації

— Облік закріплення майна організації за співробітниками

— Телефонні довідники

— Управління клієнтськими ресурсами

— Довідники адрес електронної пошти

— Зберігання конфігурації додатків

— Зберігання конфігурації АТС

— і т. д. …

Для організації каталогу під настільки різні завдання існують різні, засновані на стандартах файли наборів схеми, поширювані з дистрибутивом. Також Ви можете створити свою власну специфікацію схеми для вирішення вашого завдання.

Завжди знайдуться нові способи використання каталогів та застосування принципів LDAP для вирішення різних проблем.

OpenLDAP Software — відкрита реалізація LDAP, розроблена проектом OpenLDAP Project. Розповсюджується під власною ліцензією, званою OpenLDAP Public License.

Початок OpenLDAP Project було покладено в 1998 Куртом Зейленгою. Початковий код OpenLDAP був скопійований з реалізації LDAP Мічиганського університету, де в кінцевому рахунку і була продовжена розробка та еволюція протоколу LDAP.

На сьогодні існує декілька версій OpenLDAP. Найбільш сучасна версія OpenLDAP Version 2.4.31.

Інформаційна модель LDAP заснована на записах. Запис — це колекція атрибутів (атрибут), що володіє унікальним ім'ям (Distinguished Name, DN). DN — глобально унікальне для всього каталогу і служить для однозначної вказівки на запис. Кожен атрибут запису має свій тип (вид) і одне або кілька значень. Зазвичай типи — це мнемонічні рядки, в яких відображено призначення атрибута, наприклад «сn» — для загальноприйнятого імені, або «пошта» — для адреси електронної пошти. Синтаксис значень залежить від типу атрибута. Наприклад, атрибут CN може містити значення Ivan Ivanov. Атрибут пошта може містити значення «[email protected]». Атрибут jpegPhoto буде містити фотографію в бінарному форматі JPEG.

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

Рисунок 1.1 — Дерево каталогу LDAP (Інтернет — іменування записів) Крім того, LDAP, за допомогою спеціального атрибута ObjectClass, дозволяє контролювати, які атрибути обов’язкові і які допустимі в тому чи іншому записові. Значення атрибута ObjectClass визначаються правилами схеми, яким повинні підкорятися записи. Можливість побудови мереж каталогів — це основа для поступового розгортання служб OpenLDAP: можна почати з одного мінімально налаштованого сервера і поступово розширювати його функціональність.

Власне OpenLDAP реалізується у вигляді клієнта та сервера. Останнім часом для адміністрування, у тому числі віддаленого, все частіше застосовується веб-інтерфейс. Сервери, згідно X.500, можуть об'єднуватися в мережу, так що користувач у пошуках потрібної інформації може переходити від одного сервера до іншого. Крім того, для підвищення продуктивності існують і LDAP-проксі сервери, які ефективно кешують часті запити.

Клієнтом найчастіше виступає поштовий клієнт. Він містить форму запиту до віддаленого серверу, на зразок тієї, що використовується для пошуку в ICQ. Зазвичай клієнтське ПО реалізує не всі можливості (яких дуже багато), а якусь їх підмножину. В тій чи іншій мірі OpenLDAP підтримують всі сучасні поштові клієнти, такі як Outlook Express, Eudora, Netscape, OS X Mail і т.д. Часто доступ до OpenLDAP-сервера, особливо глобальному, можна отримати через веб-інтерфейс.

Швидко отримати вікно пошуку на заданому сервері зазвичай можна, ввівши у вікні браузера URL виду ldap :/ / server [: port]. Наприклад, у нашій локальній мережі це буде ldap :/ / 192.168.0.99. Через косу риску ви можете відразу вказати параметри пошуку (звичайно ж, зазвичай цей рядок буде формувати якийсь додаток). Так, введення в браузер ldap :/ / 192.168.0.99/cn = Antonchuk, dc = comizdat, dc = com безпосередньо відобразить інформацію про головне. Цей тип URL підтримується Internet Explorer і Firefox (Netscape) — але не підтримується, наприклад, в Opera.

Як вже було сказано, LDAP, крім системи обслуговування запитів, спочатку включає і систему аутентифікації. Адміністратор задає привілеї користувачів і визначає записи, до яких той чи інший з них може здійснювати доступ. Списки правил доступу (ACL, Access Control List) дозволяють налаштувати доступ будь-яким чином: у типовому випадку користувач має право змінювати власну приватну інформацію, а все решта — переглядати її. Однак можна, наприклад, захистити окремі поля приватної записи від перегляду або модифікації.

Власне, існують і громадські OpenLDAP — сервери, доступні для пошуку всьому світу (наприклад, BigFoot або Infospace) — але все-таки основне застосування протокол знаходить на рівні великих і середніх корпорацій. Не припиняються спроби створити методи об'єднання окремих серверів з метою створення «глобального каталогу». Але до реального втілення поки далеко.

Також OpenLDAP використовується для каталогів мережевих ресурсів і інших речей, відмінних від персональних даних. Наприклад, той же Netscape Communicator при створенні користувальницького акаунта створює запис в централізованій базі даних OpenLDAP і намагається зберігати там всі ваші настройки, такі як закладки часто відвідуваних вами сторінок. У цьому сенсі OpenLDAP в деяких сферах може по конкурувати з методом доступу SQL, оскільки працює безпосередньо через TCP / IP і добре адаптований до роботи в мережі. Однак врахуйте, що OpenLDAP орієнтований на швидкий пошук і доступ (читання) даних — але внесення змін не є настільки ж швидкою і ефективною операцією. Так що цей протокол орієнтований, скоріше, на статичні дані: адреси, телефони, паролі, мережеві ресурси — і не підійде для інформації, яка схильна швидко мінятися.

Три підходи до нормалізації баз даних в OpenLDAP.

Перший з них полягає в повній нормалізації, тобто в примінені кожного типу атрибута, незалежно від того, які дані в ньому зберігаються, в окрему таблицю. У найпростішому випадку в якості первинного ключа можна використовувати DN, але це вкрай марнотратно, тому напрошується присвоєння записи унікального числового ідентифікатора, який в головній таблиці буде зіставлятися DN, а потім використовуватися як в якості зовнішнього ключа в підлеглих таблицях. Такий підхід в будь-якому випадку буде неефективним, коли будуть потрібні дані відразу з декількох атрибутів для однієї або ряду записів каталогу. Тим не менш, з такою базою даних можна працювати з SQL-додатків.

Другий підхід полягає в тому, щоб поміщати цілком всі дані про запис в одному blob-поле таблиці, в якій будуть зберігатися всі записи каталогу, незалежно від їх об'єктних класів, і мати додаткові таблиці, що містять індекси для першої. І це будуть не індекси бази даних, а величини, що застосовуються для оптимізації пошуку в конкретній реалізації LDAP-сервера. Однак, подібні бази даних стають непридатними для SQL-запитів. Таким чином, використання повноцінної реляційної СУБД не забезпечує практично ніяких переваг, і тому марно. Набагато краще використовувати щось більш легке і швидке, начебто Berkeley DB.

Нарешті, зовсім відмінний підхід полягає у відмові від реалізації повноцінної моделі даних каталогу. В цьому випадку LDAP використовується як протокол доступу до даних, які можна назвати каталогом лише з обмеженнями. Наприклад, це може бути каталог в режимі «тільки для читання», або, якщо дозволені операції оновлення, накладаються різні обмеження, такі як присвоєння тільки одного значення атрибутам, які у повноцінній реалізації могли б мати кілька значень. Або відсутність можливості додати новий об'єктний клас до існуючої записи, або прибрати один з тих, які у неї вже є. Діапазон обмежень може варіюватися від цілком нешкідливих (на кшталт тих, що накладаються в результаті контролю доступу), до прямого порушення моделі даних, але за рахунок цього можна спробувати організувати LDAP-доступ до вже існуючими даними, які використовуються іншими додатками. І все ж треба розуміти, що таку систему «каталогом» можна назвати з великою натяжкою.

В існуючих комерційних реалізаціях LDAP-серверів, що використовують реляційні бази даних, застосовується або перший, або третій підхід. Все ж хотілося б відзначити, що в жодній з них застосування реляційної СУБД не дозволило зробити роботу ефективніше, ніж при використанні BDB.

OpenLDAP включає в себе back-sql — механізм маніпуляції даними, який робить це можливим. Він використовує ODBC + додаткову метаінформацію про трансляцію LDAP-запитів в SQL-запити в схему даних нашої СУБД, організовує різні рівні доступу від «тільки для читання» до повного доступу, в залежності від СУБД, яку ви використовуєте, і вашої схеми даних.

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

Simple Authentication and Security Layer: slapd підтримує сувору автентифікацію та безпеку (цілісність і конфіденційність) даних з використанням SASL. Реалізація SASL в slapd заснована на застосуванні програмного забезпечення Cyrus SASL з підтримкою ряду механізмів, у тому числі DIGEST-MD5, EXTERNAL і GSSAPI.

Transport Layer Security: slapd підтримує аутентифікацію на базі сертифікатів та безпеки (цілісність і конфіденційність) даних з використанням TLS (або SSL). Реалізація TSL в slapd може бути заснована на застосуванні програмного забезпечення OpenSSL, GnuTLS або MozNSS.

Контроль доступу на основі мережевої топології: slapd може бути налаштований на заборону доступу на рівні підключень на основі інформації про топологію мережі. Дана можливість заснована на застосуванні TCP wrappers.

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

Інтернаціоналізація: slapd підтримує Unicode і мовні теги.

Вибір механізму маніпуляції даними: slapd поставляється з набором різних механізмів маніпуляції на ваш вибір. Ось деякі з них: BDB, високопродуктивний механізм маніпуляції з підтримкою транзакцій; HDB, ієрархічної високопродуктивний механізм з підтримкою транзакцій; SHELL, механізм для виконання довільних shell-скриптів; PASSWD, простий механізм доступу до файлу passwd. Механізми BDB і HDB засновані на застосуванні Oracle Berkeley DB.

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

Різноманітні API-модулі: Якщо нам потрібна ще більша гнучкість налаштувань, slapd дозволяє вам без праці написати власні модулі. slapd складається з 2-х окремих частин: інтерфейс прийому запитів, що обслуговує спілкування з клієнтами за допомогою протоколу LDAP, і модулі, що виконують специфічні завдання, такі як операції з базами даних. Оскільки ці 2 частини взаємодіють один з одним через чітко визначений C API, ви можете на його основі писати власні модулі, що може значно розширити функціональність slapd. Також доступний ряд програмованих модулів доступу до баз даних, які дозволяють визначити зовнішні джерела даних для slapd з використанням популярних мов програмування (Perl, shell, and SQL).

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

Реплікація: slapd може бути налаштований для виконання фонового копіювання даних каталогу. Подібна схема реплікації «один головний / кілька підлеглих серверів» має життєво важливе значення в великих високо-завантажених системах, де один сервер slapd просто не в змозі забезпечити необхідну доступність і надійність. В екстремально складних системах з підвищеними вимогами до безвідмовності можливо також використання схеми реплікації «кілька головних серверів». В slapd включена підтримка LDAP Sync-реплікації.

Проксі-кешування: slapd може бути налаштований в якості кешуючого проксі-сервера LDAP.

Настроюваність: slapd може дуже гнучко і різноманітно налаштовуватися з допомогою одного єдиного конфігураційного файлу, який дозволяє нам змінити все, що нам тільки заманеться змінити. Опції конфігурації мають розумні значення за умовчанням, щоб максимально полегшити нашу працю. Конфігурація також може бути проведена динамічно за допомогою самого LDAP, що значно підвищує керованість.

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

Як правило, бажано встановити обмеження на те, скільки ресурсів сервера може споживатися кожним клієнтом LDAP. OpenLDAP надає два набори обмежень: обмеження за розміром, лімітуючи кількість записів, які клієнт може отримати за одну операцію, і обмеження за часом, лімітуючи проміжок часу на виконання операції. Обидва типи обмежень можуть приймати різні значення в залежності від того, ким ініційована операція.

Адміністратор сервера може визначити як м’які, так і жорсткі обмеження. М’які обмеження можна розглядати як значення обмежень за замовчуванням. Жорсткі обмеження не можуть бути перевищені непривілейованим LDAP-користувачами.

При запиті пошукових операцій клієнти LDAP можуть визначати свої власні обмеження за розміром і за часом. Ця можливість існувала ще з часів ранніх версій X.500.

Якщо клієнт визначив обмеження, то найменше значення з певного їм і жорсткого обмеження стане фактичним обмеженням при виконанні операції.

Якщо клієнт не визначив обмеження, тоді сервер застосовує м’яке обмеження.

М’які і жорсткі обмеження часто розглядаються разом як адміністративні обмеження. Тому, коли клієнт LDAP намагається виконати пошукову операцію, яка поверне більше даних, ніж дозволяють обмеження, він отримає помилку adminLimitExceeded (перевищені адміністративні обмеження). Сервер зазвичай повертає деяка кількість результатів, навіть якщо обмеження перевищені: дана можливість корисна клієнтам, які хочуть тільки переконатися в існуванні певних записів і не потребують отримання їх усіх.

На rootdn не накладаються ніякі обмеження.

Механізми маніпуляції даними виконують реальну роботу по зберіганню і вилученню даних у відповідь на запити LDAP. Вони можуть бути статично скомпільовані в slapd, або, якщо включена підтримка модулів, вони можуть бути завантажені динамічно.

Якщо ваша інсталяція slapd використовує динамічні модулі, вам може знадобитися додати відповідні директиви moduleload як показано в наступних прикладах.

Механізм bdb є первинним і рекомендованим механізмом для нормальної бази даних slapd. Для зберігання даних він використовує пакет Oracle Berkeley DB (BDB). Цей механізм дозволяє широко застосовувати індексування і кешування для прискорення доступу до даних (дивіться розділ Налаштування продуктивності).

hdb — це варіант механізму bdb, що використовує ієрархічну структуру бази даних з підтримкою перейменувань на рівні піддерев. У всьому іншому його поведінка аналогічно поведінці bdb, і до обох застосовні однакові параметри конфігурації.

1.2 Вимоги замовника до проекту Компанія замовник вирішила зробити роботу своїх працівників більш мобільною, упорядкованою. Іноді буває потрібно забезпечити роботу з комп’ютером, не прив’язуючи до нього певних користувачів. При вході в систему каталогів, користувач отримує доступ тільки до «своїх» файлів. Це було головною вимогою замовника. Також потрібно було зробити так щоб кожен співробітник міг знайти інформацію про певного користувача (співробітника) в межах корпоративної мережі. Інформацію користувача: телефон, адресу електронної пошти, та інше. Компанія хоче щоб система була розгорнута швидко и без великих витрат на її придбання. Так як фірма має обмежений бюджет і не може собі витрачувати великі суми грошей на програмне забезпечення і його установку, яка проводиться спеціалістами в галузі адміністрування комп’ютерних систем. Вибір пав на систему OpenLDAP. OpenLDAP зарекомендувала себе як система надійна, не гірша ніж LDAP, і в той же час значно дешевша ніж аналогічні системи. Все це відіграє велике значення при виборі системи в нашому випадку.

Потрібно: Встановити сервер OpenLDAP, налаштувати його для роботи в корпоративній мережі організації. Прив’язати наше дерево каталогів до нашого локального DNS серверу. Додати туди облікові записи наших користувачів, а саме до якого підрозділу відноситься певний співробітник організації, вказати його ім'я і фамілію, а також його логін і пароль для входу в систему дерева каталогів. Налаштувати робочі станції на використання сервера OpenLDAP для інформації про облікові записи користувачів і аутентифікації. До всього, було прийнято рішення зробити цей каталог платформонезалежним. Тобто потрібно щоб він працював на комп’ютерах з операційною системою Microsoft Windows і з операційною системою Linux Debian основаною на ядрі версії 2.6.

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

2. РОЗРОБКА СТРАТЕГІЇ ВПРОВАДЖЕННЯ ТА РЕАЛІЗАЦІЇ ПРОЕКТУ Для точної стратегії впровадження проекту потрібно знати структуру дерева каталогів компанії замовника. Структура дерева каталогів зображена на додатку А. Сервер OpenLDAP буду будувати з традиційним іменуванням записів. Разом з сервері OpenLDAP потрібно настроїти DNS сервер, щоб можна було використовувати свої доменні імена. Я розбив структурні підрозділи фірми на вісім підрозділів (контейнерів) дерева каталогів. Адміністратора мережі я виніс окремо як структурну одиницю що здійснює контроль над мережею. Схема представлена на рисунку 2.1. Він має всі права доступу до інформації в мережі. В першу чергу після установки пакета OpenLDAP потрібно буде сконфігурувати файл openldap. сonf, після побудувати базу даних користувачів корпоративної мережі. Настроїти машини співробітників для роботи з системою OpenLDAP. Розпишу сам процес більш детально.

Каталог OpenLDAP, аналогічно файловій системі UNIX, побудований у вигляді дерева: кореневий вузол містить посилання на записи, деякі з яких можуть вказувати на інші каталоги. Зазвичай всієї організації відповідає кореневої каталог. Як підкаталогів виступають відділи, філії або будь-які інші мають для вас сенс атрибути. Підкаталоги можуть бути автоматично репліковані в обох напрямках — будь-яка зі сторін може ініціювати процес синхронізації підкаталогу. Типове застосування автоматичних оновлень — синхронізація між головним каталогом компанії та каталогами підрозділів.

Записи каталогу LDAP шикуються у вигляді ієрархічної деревоподібної структури. Традиційно, ця структура відображає географічне і / або організаційний устрій збережених даних. У вершині дерева розташовуються записи, що представляють собою країни. Під ними розташовуються записи, які представляють області країн і організації. Ще нижче розташовуються записи, що відображають підрозділи організацій, людей, принтери, документи, або просто все те, що Ви захочете включити в каталог. На рисунку 2.1 показаний приклад дерева каталогу LDAP, що використовує традиційне іменування записів. Можна відразу ж визначитися зі скороченнями, прийнятими в службі директорій:

С (сountry) — країна

ST (state) — ім'я регіону, області або штату

L (location) — ім'я міста, селища, села

O (organization) — ім'я компанії

O (organizational) U (unit) — розділ компанії

Рисунок 2.1 — Структура дерева каталогів фірми замовника.

Рисунок 2.2 — Дерево каталогу LDAP (традиційне іменування записів) Дані об'єкти дерева є основними, тому є контейнерами для інших об'єктів і можна здійснювати пошук певного об'єкта, наприклад, в даної компанії. На основі вищеперілічених об'єктів зазвичай будується дерево каталогів. Самий верхній рівень представляє об'єкт root, Від нього відбуваються скелетні об'єкти, усередині яких і полягають конкретні об'єкти дерева. Взагалі деревоподібна структура має безліч переваг в порівнянні з лінійної (/ etc / passwd), тому що дозволяє точно визначити знаходження користувача чи іншого об'єкта. / Etc / passwd надає лише жалюгідна подоба даної моделі - поле GECOS, але, працюючи з LDAP, просто необхідно вказувати повний опис об'єкта. Для позначення повного опису об'єкта щодо скелета дерева використовується термін DN (distinguished name — призначене ім'я, контекст) Сервер OpenLDAP зберігає і індексує записи певного формату. В якості полів виступають ім'я користувача, його фізична та електронна адреси, телефони і т.д. Адміністрування сервера проводиться за правилами середовища: для Linux це файли налаштування і командний рядок, для Windows і Mac OS — графічні додатки.

По суті, OpenLDAP — не реляційна база даних. Структура бази OpenLDAP швидше нагадує XML, де запис являє собою комбінацію атрибут: значення. Оскільки існує можливість визначати нові типи полів, то в OpenLDAP можна зберегти будь-яку текстову чи бінарну інформацію. Це обумовлює більшу гнучкість для опису нових полів і структур, але в загальному випадку пошук по неіндексованому полю — операція досить повільна.

Використання вбудованої бази даних і простої системи індексування дозволяє OpenLDAP забезпечувати високу продуктивність і масштабованість без втрати надійності. OpenLDAP використовує багатокористувацьку СУБД Berkeley DB з підтримкою транзакцій. Те ж саме програмне забезпечення використовується у провідних комерційних службах каталогів.

Використання в якості сховища каталогу реляційної СУБД вирішить всі подібні проблеми. Але тут криється підступ. Вся справа в тому, що інформаційні моделі каталогу й реляційної БД дуже різні. Спроба проектування даних каталогу в реляційну БД зажадає розділення даних на кілька таблиць.

Візьмемо, приміром, об'єктний клас person. У ньому визначені обов’язкові типи атрибутів objectClass, sn і cn, а також необов’язкові типи атрибутів userPassword, telephoneNumber, seeAlso і description. Всі ці атрибути можуть мати кілька значень, таким чином нормалізація зажадає помістити кожен тип атрибута в окрему таблицю.

Тепер потрібно подумати про ключові полях для цих таблиць. В якості первинного ключа може бути використаний DN, але в більшості реалізацій баз даних це буде дуже неефективно.

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

У головну таблицю, що зберігає відомості про записи каталогу, можуть бути поміщені тільки дані з обов’язкових для об'єктного класу типів атрибутів, які можуть мати тільки одне значення. Крім того, туди можна помістити дані з необов’язкових атрибутів з одним значенням, і записувати в такі поля NULL (або ще що-небудь), якщо атрибут не заданий.

Однак, у запису каталогу може бути кілька об'єктних класів, і вони можуть ієрархічно успадковуватися один від одного. Запис об'єктного класу organizationalPerson матиме атрибути об'єктного класу person плюс ряд додаткових, до того ж деякі раніше необов’язкові атрибути можуть стати обов’язковими.

Доступ до нашого каталогу може бути налаштований двома методами, перший з яких використовує Конфігураційний файл slapd, а другий використовує формат slapd-config.

Політика контролю доступу за замовчуванням — дозволити доступ на читання всім клієнтам. Незалежно від того, яка політика контролю доступу визначена, для rootdn завжди дозволені повні права (тобто аутентифікація, пошук, порівняння, читання і запис) над чим завгодно і де завгодно в каталозі.

При прийнятті рішення про надання будь-кому доступу до того чи іншого запису та / або атрибуту, slapd порівнює запитувані запис і / або атрибут до критеріїв відбору, заданими в конфігураційному файлі. Для кожного запису спочатку застосовуються директиви контролю доступу, що відносяться до тієї бази даних, в якій цей запис міститься (або глобальні директиви, якщо цей запис не міститься ні в одній з баз даних), а потім застосовуються глобальні директиви контролю доступу. Існує деяка тонкість при застосуванні списків контролю доступу. Глобальні списки контролю доступу додаються до списків, визначеним для кожної бази даних, і, якщо після такого складання результуючий список виявляється непустою, тоді в його кінець додається неявна директива access to * by * none. Якщо ж результуючий список порожній, тобто для будь-якого механізму маніпуляції даними не задано директив, то за замовчуванням надається доступ на читання.

Слідуючи цьому пріоритету, директиви access перевіряються в порядку їх зазначення в конфігураційному файлі. Slapd зупиняє перевірку на першому критерії відбору, який відповідає цільової запису та / або атрибуту. Директива access з цим критерієм відбору і буде тією, за якою slapd буде приймати рішення про надання доступу.

Потім slapd порівнює сутність, запитуючу доступ, до критеріїв відбору обраної вище директиви access в порядку їх вказівки. Він зупиняє порівняння на першому критерії відбору, який відповідає цільової сутності. Так визначається, чи буде сутність, запитуюча доступ, реально мати доступ до запису та / або атрибуту.

Нарешті, slapd порівнює рівень доступу, наданий в обраному умови, з рівнем доступу, який запитує клієнт. Якщо в умові дозволений більший або рівний рівень доступу, то клієнту надається доступ. В іншому випадку доступ забороняється.

Порядок оцінки директив access робить важливим порядок їх розміщення в конфігураційному файлі. Якщо одна директива access висуває більш конкретні умови відбору записів, ніж інша, вона повинна бути вказана раніше в конфігураційному файлі. Аналогічно, якщо один критерій відбору висуває більш конкретні умови відбору, ніж інший, він повинен вказуватися раніше в директиві access.

У середовищі Active Directory Windows клієнти взаємодіють з контролерами домену за допомогою протоколу Lightweight Directory Access Protocol (LDAP). Як і більшість інших протоколів, LDAP призначений для використання певних номерів портів. Наприклад, LDAP зазвичай використовує порт 389 для запитів каталогів. Якщо LDAP взаємодію потрібно зашифрувати, то використовується порт 636. Контролери доменів, що функціонують в ролі серверів глобальних каталогів, використовують порти 3268 і 3269 для операцій, пов’язаних з глобальними каталогами.

програмний каталог openldap сервер

3. УСТАНОВКА І НАСТРОЙКА СЕРВЕРА СЛУЖБИ КАТАЛОГІВ ЗАСОБАМИ OPENLDAP

3.1 Установка і настройка сервера

Інсталяція системи OpenLDAP відбувається на сервер з системою Debian 6.0. На машини співробітників установлено операційні системи сімейства Windows.

Установимо службу каталогів OpenLDAP в автоматичному режимі без компіляції. Інсталяція OpenLDAP і необхідних утиліт відбувається в автоматичному режимі, після вводу команди: apt-get install slapd ldap-utils

Установку наведено нижче в лістингу 3.1:

# apt-get install slapd ldap-utils

Лістинг 3.1 — Установка OpenLDAP

Після установки я матиму установлені:

Бібліотеки LDAP (бібліотека класів JLDAP та інші);

Сервер LDAP (slapd);

slurpd — демон реплікації;

pam_ldap і nss_ldap для аутентифікації через LDAP.

Тепер необхідно сконфігурувати LDAP-директорію на підставі своїх вимог. Насамперед слід зупинити сервіс: slapd

# /etc/init.d/slapd stop

Stopping OpenLDAP: slapd.

Лістинг 3.2 — Зупинка процесу slapd

Після чого треба налаштувати сервер на роботу у нашій службі каталогів. Відкриваємо файл конфігурації / etc / openldap / slapd. conf (лістинг 3.3). Він містить приблизно наступне:

include / usr / share / openldap / schema / core. schema

include / usr / share / openldap / schema / cosine. schema

include / usr / share / openldap / schema / corba. schema

include / usr / share / openldap / schema / inetorgperson. schema

include / usr / share / openldap / schema / java. schema

include / usr/share/openldap/schema/krb5-kdc.schema

include / usr / share / openldap / schema / kerberosobject. schema

include / usr / share / openldap / schema / misc. schema

include / usr / share / openldap / schema / nis. schema

include / usr / share / openldap / schema / openldap. schema

# Включаємо базові визначення об'єктів директорій і додаткові #класи

# Об'єктів, файли схем

# Включаємо файл, що описує права доступу до БД:

include / etc / openldap / slapd.access.conf

# Стандартні файли, необхідні для роботи демона: файл #ідентифікатора і

# Командного рядка

pidfile / var / run / ldap / slapd. pid

argsfile / var / run / ldap / slapd. args

# Шлях до додаткових модулів сервера

modulepath / usr / lib / openldap

# Описуємо параметри з'єднання через SSL

# Хост для безпечної аутентифікації SASL

sasl-host localhost

# Якщо ви хочете дозволити з'єднання через TLS то приберіть #коментар з

# Наступних рядків (в даному прикладі він є)

# TLSRandFile / dev / random

# TLSCipherSuite HIGH: + SSLv2

# TLSCertificateFile / etc / openldap / ldap. pem

# TLSCertificateKeyFile / etc / openldap / ldap. pem

# Шлях до файлу ключа

# TLSCACertificatePath / etc / openldap /

# TLSCACertificateFile / etc / openldap / ldap. pem

# Шлях до сертифікату хоста

# TLSVerifyClient 0

# Перевірка ключа клієнта

#Опис бази даних LDAP

database ldbm

# Тип бази даних ldbm

suffix «o = firma, l = Odessa, c = UKR «

# Це основний суфікс БД. У визначенні системи директорій існує так

# Званий кореневий об'єкт root. Суфікс визначає цей об'єкт.

rootdn «cn = admin, o = firma, l = Odessa, c = UKR «

# Це поле містить пароль адміністратора об'єкта root (тобто всієї БД LDAP).

# Пароль може зберігатися як у відкритому вигляді (не #рекомендується!) Так і в

# Зашифрованому вигляді з зазначенням алгоритму шифрування ({crypt}, # {MD5}, {SSHA},

# Бажано встановлювати програмою slappasswd, що дозволяє встановити потрібний

# Алгоритм шифрування

rootpw secret

# Папка, де зберігається база даних LDAP.

directory / var / lib /Openldap

# Визначення первинних і вторинних індексів БД може прискорити #пошук по БД

index objectClass, uid, uidNumber, gidNumber eq

index cn, mail, surname, givenname eq, subinitial

# Права доступу за умовчанням

access to attr = userPassword

by self write

by anonymous auth

by dn = «cn = root, o = firma, l = Odessa, c = UKR

by * none

# Тут визначається доступ до атрибуту пароль користувача. Тобто #іншими словами ніхто,

# Окрім адміністратора і самого користувача не мають доступу до #пароля

access to *

by dn = «dn = root, o = firma, c = UKR» write

by * read

# Доступ до інших полів бази LDAP — всі можуть читати атрибути # # #(крім пароля,

# Так як заборона має більш високий пріоритет, а користувач з правами

# root може писати все що завгодно.

Лістинг 3.3 — Настройка файлу slapd. conf

В цьому файлі можна ще вказувати додаткові параметри для взаємодії декількох серверів (реплік), зокрема основний сервер, вторинні сервера, паролі доступу до них і т.д. Я зробив самі необхідні 3 речі: встановив суфікс БД і вибрав тип контексту (глобальної мережі чи організації); вказав контекст адміністратора LDAP, встановив пароль (secret) адміністратора LDAP за допомогою програми slappasswd.

Створюємо базу даних служби каталогів. Назвемо файл «baza»:

dn: o = firma, l = Odessa, c = UKR

objectclass: dcObject

objectclass: organization

o: firma

dn: сn = root, o = firma, l = Odessa, c = UKR

objectclass: organizationalRole

cn: admin

dn: ou=directors, o = firma, l = Odessa, c = UKR

ou: directors

objectclass: top

objectclass: organizationalUnit

dn: cn= Ivan Ivanov, ou= directors, o = firma, l = Odessa, c = UKR

cn= Ivan Ivanov

sn: Ivanov

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 10

gidnumber: 10

homedirectory: /home/ Ivan Ivanov

gecos: Ivanov

userpassword: 123

…

Описання користувачів відділу маркетингу:

dn: ou= marketing department, o = firma, l = Odessa, c = UKR

ou: marketing department

objectclass: top

objectclass: organizationalUnit

dn: cn= Victor Smirnov, ou= marketing department, o = firma, l = Odessa, c = UKR

cn= Victor Smirnov

sn: Smirnov

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 20

gidnumber: 20

homedirectory: /home/ Victor Smirnov

gecos: Smirnov

userpassword: 1234

…

Описання користувачів відділу Випуску продукції:

dn: ou= Department of procurement, o = firma, l = Odessa, c = UKR

ou: Department of procurement

objectclass: top

objectclass: organizationalUnit

dn: cn= Irina Fedotova, ou= Department of procurement, o = firma, l = Odessa, c = UKR

cn= Irina Fedotova

sn: Fedotova

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 30

gidnumber: 30

homedirectory: /home/ Irina Fedotova

gecos: Fedotova

userpassword: 12 345

…

Описання користувачів відділу сертифікації:

dn: ou= Certification department, o = firma, l = Odessa, c = UKR

ou: Certification department

objectclass: top

objectclass: organizationalUnit

dn: cn= Irina Konovalova, ou= Certification department, o = firma, l = Odessa, c = UKR

cn= Irina Konovalova

sn: Konovalova

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 40

gidnumber: 40

homedirectory: /home/ Irina Konovalova

gecos: Konovalova

userpassword: 123 456

…

Описання користувачів відділу Готової продукції:

dn: ou= Production department, o = firma, l = Odessa, c = UKR

ou: Production department

objectclass: top

objectclass: organizationalUnit

dn: cn= Pavel Grigoriev, ou= Production department, o = firma, l = Odessa, c = UKR

cn= Pavel Grigoriev

sn: Grigoriev

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 50

gidnumber: 50

homedirectory: /home/ Pavel Grigoriev

gecos: Grigoriev

userpassword: 1 234 567

…

Описання користувачів відділу кадрів:

dn: ou= Personnel department, o = firma, l = Odessa, c = UKR

ou: Personnel department

objectclass: top

objectclass: organizationalUnit

dn: cn= Vadim Tolkachev, ou= Personnel department, o = firma, l = Odessa, c = UKR

cn= Vadim Tolkachev

sn: Tolkachev

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 60

gidnumber: 60

homedirectory: /home/ Vadim Tolkachev

gecos: Tolkachev

userpassword: 12 345 678

…

Описання користувачів відділу охорони:

dn: ou= Protection, o = firma, l = Odessa, c = UKR

ou: Protection

objectclass: top

objectclass: organizationalUnit

dn: cn= Ivan Shiryaev, ou= Protection, o = firma, l = Odessa, c = UKR

cn= Ivan Shiryaev

sn: Shiryaev

objectclass: account

objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 70

gidnumber: 70

homedirectory: /home/ Ivan Shiryaev

gecos: Shiryaev

userpassword: 123 456 789

…

Описання користувачів відділу бухгалтерії:

dn: ou= Bookkeeping department, o = firma, l = Odessa, c = UKR

ou: Bookkeeping department

objectclass: top

objectclass: organizationalUnit

dn: cn= Olga Maslova, ou= Bookkeeping department, o = firma, l = Odessa, c = UKR

cn= Olga Maslova

sn: Maslova

objectclass: account objectclass: posixAccount

objectclass: top

objectclass: cnObject

loginshell: /bin/zsh

cnnumber: 110

gidnumber: 110

homedirectory: /home/ Olga Maslova

gecos: Maslova

userpassword: 1 234 567 891

…

Лістинг 3.4 — Файл бази даних користувачів сервісу OpenLDAP

Я представив фрагмент конфігураційного файла бази даних, де показано організацію відділів організації-замовника (firma) і описується по одному співробітнику із кожного відділу. Загалом у організації працюють 108 людей. В цьому файлі забороняється писати коментарі, тому усі пояснення приведені нижче в лістингу 3.5.

dn: o = firma, l = Odessa, c = UKR

# Унікальний контекст імені

objectclass: dcObject

# Клас об'єкта — контейнерний об'єкт

objectclass: organization

# Той же самий контекст може являти собою різні об'єкти

o: firma

# Ім'я організації

# ————————————————————————- ——————-;

dn: сn = root, o = firma, l = Odessa, c = UKR

# Контекст адміністратора

objectclass: organizationalRole

# Клас — посадова особа

cn: admin

# Ім'я людини (псевдонім)

# ————————————————————————- ——————-;

dn: ou=directors, o = firma, l = Odessa, c = UKR

# Контекст групи користувачів

ou: directors

# Значення групи

objectclass: top

objectclass: organizationalUnit

# Клас група

# ————————————————————————- ——————-;

dn: cn= Ivan Ivanov, ou= directors, o = firma, l = Odessa, c = UKR

# Контекст конкретного користувача з / etc / passwd

uid: Ivan Ivanov

# Його користувальницький псевдонім

cn: Ivanov

# Реальний псевдонім

objectclass: account

# Клас користувальницький профіль

objectclass: posixAccount

# Клас користувача POSIX

objectclass: top

objectclass: uidObject

loginshell: / bin / zsh

# Всі наступні параметри збігаються з аналогічними в / etc / passwd

uidnumber: 10

gidnumber: 10

homedirectory: / home / Ivan Ivanov

gecos: Ivanov

userpassword: 123

Лістинг 3.5 — Фрагмент файлу бази даних користувачів сервісу OpenLDAP

Для пришвидшення написання бази даних було складено багато скриптів, які входять в стандартний пакет openldap-migration, який містить набір скриптів для перенесення існуючих файлів і баз мережевих служб в OpenLDAP. Скрипти знаходяться в директорії /usr/share/openldap/migration. В нашому випадку я їх не використовував.

3.2 Настройка клиентів Windows

Для клієнтської частини мережі встановлені операційні системи сімейства Windows. На ОС Windows служба LDAP встановлена по замовчуванню її тільки треба увімкнути і прописати у властивостях локальної мережі домене ім'я OpenLDAP. Наприклад Ivan Ivanov.Directors.UKR.

Опишу процес настройки Windows клієнта:

Увійдемо в систему як Адміністратор. Для запуску майстра виберіть команду Пуск | Виконати (Start | Run) і введіть команду dcpromo. Альтернативний варіант — вибрати команду Пуск | Програми | Адміністрування | Налаштування сервера (Start | Programs | Administrative Tools | Configure Your Server), у вікні, послідовно натиснути кнопки Active Directory і Запустити (Start). Виберемо перемикач Контролер домену в новому домені (Domain controller for a new domain) і натиснемо кнопку Далі. Введемо повне DNS-ім'я, вибране для першого домену, наприклад, Ivan Ivanov.Directors.UKR. Утиліта DCpromo перевіряє, чи використовується вже дане ім'я. Потім для домену також визначається NetBIOS-ім'я, за яким ідентифікують домен клієнти нижнього рівня, наприклад, Windows NT 4.0.

У наступних вікнах майстра встановлюються додаткові параметри (місце розташування бази даних Active Directory, журналів реєстрації подій, реплицируємого системного тому). DNS-сервер я не інсталюю, його не потрібно, він є на машині з сервером OpenLDAP.

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

Після натискання кнопки Далі починається власне процес установки Active Directory.

По завершенні всіх операцій майстер інсталяції Active Directory виводить інформаційне вікно, в якому потрібно натиснути кнопку Готово (Finish), і пропонує перезавантажити комп’ютер: натиснемо кнопку Перезавантажити зараз (Restart Now).

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

ВИСНОВКИ та ПРОПОЗИЦІЇ

Настройка серверу в корпоративній мережі будь-якого підприємства чи закладу — це багатоступенева задача, розв’язання якої потребує знання новітніх комп’ютерних технологій. У цій випускній роботі показано на прикладі настроювання серверу служби каталогів з допомогою OpenLDAP. Також я розкрив у цій роботі такі питання, як установка серверу служби каталогів, його настройка. Результати роботи такі.

1) Встановили сервер OpenLDAP.

2) Додали туди облікові записи наших користувачів.

3) Налаштували робочі станції на використання сервера OpenLDAP для інформації про облікові записи користувачів і аутентифікації.

ПЕРЕЛІК ПОСИЛАНЬ

1. www.tldp.org — LDAP HOWTO і LDAP-implementation HOWTO.

2. www.openldap.org — ldap guide.

3. www.mandrakesecure.net/en/docs/ldap-auth.php.

4. www.opennet.ru.

5. RFC 2252 OpenLDAP визначення атрибутів.

6. RFC 2255 Формат LDAP URL.

7. RFC 2256 Використані частини протоколу X.500 в OpenLDAP.