Openldap сервер, російськомовна документація по ubuntu

Легкий протокол доступу до каталогів, або LDAP - це протокол запитів і змін до сервісу каталогів на базі X.500, що працює поверх TCP / IP. Поточна версія LDAP це LDAPv3, як визначено в RFC4510. а реалізація LDAP в Ubuntu - це OpenLDAP, поточної версії 2.4.25 (Oneiric) (2.4.28 для Precise - прим. перекладача).

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

LDAP каталог - це дерево даних у вигляді записів. ієрархічних по своїй натурі, зване Дерево каталогів інформації (DIT).

Запис містить набір атрибутів.

Атрибут має тип (ім'я / опис) і одне або кілька значень.

Кожен атрибут повинен бути визначений як мінімум в одному objectClass.

Атрибути і об'єктні класи визначаються в схемах (об'єктний клас фактично розглядається як спеціальний вид атрибута).

Кожен запис має унікальний ідентифікатор: своє Відмітна ім'я (DN або dn). Вона складається зі свого Відносного відмітної імені (RDN), наступним за записом батьківського DN.

DN записи - це не атрибут. Воно не є розглянутої частиною власне записи.

Терміни об'єкт. контейнер і вузол (node) мають певний підтекст, але вони все по суті позначають таку річ, як запис, технічно коректний термін.

Наприклад, далі ми маємо одну запис, що містить 11 атрибутів. Її DN - це "cn = John Doe, dc = example, dc = com"; її RND - це "cn = John Doe"; а батьківський DN - "dc = example, dc = com".

Вищенаведена запис - це формат LDIF (формат обміну даними LDAP). Будь-яка інформація, яку ви ставите в ваш DIT повинна бути в такому форматі. Це визначено в RFC2849.

Установка сервісу сервера OpenLDAP і звичних утиліт управління LDAP. Вони знаходяться в пакетах slapd і ldap-utils відповідно.

Установка slapd створить працюючу конфігурацію. Зокрема вона створить екземпляр бази даних, яку ви можете використовувати для зберігання своїх даних. Однак суфікс (або базовий DN) цього примірника буде визначено з доменного імені localhost. Якщо ви хочете використовувати щось інше, відредагуйте / etc / hosts і замініть доменне ім'я на відповідне. Як приклад, якщо вам потрібен суфікс dc = example, dc = com. то ваш файл повинен мати подібну рядок:

Ви можете скасувати зміни після установки пакета.

Це керівництво буде використовувати суфікс бази даних dc = example, dc = com.

Продовжимо з установкою:

Починаючи з Ubuntu 8.10 slapd проектується, щоб налаштовуватися самостійно, виділяючи окремий DIT для цієї мети. Це дозволяє динамічно налаштовувати slapd без необхідності перестартовивать сервіс. Ця конфігураційна база даних містить колекцію текстових LDIF файлів, розташованих в /etc/ldap/slapd.d. Цей варіант роботи відомий під різними іменами: метод slapd-config, RTC метод (настройка в реальному часі) або cn = config метод. Ви все ще можете використовувати традиційний метод плоского файлу (slapd.conf), але це не рекомендується; дана функціональність в кінцевому рахунку буде прибрана.

Ubuntu тепер використовує метод slapd-config для настройки slapd і цей посібник це відображає.

Деякі класичні схеми (cosine, nis, inetorgperson) випускаються тепер для slapd. Це також включає базову (core) схему, яка передбачається для будь-якої робочої схеми.

Процес установки створить 2 DIT. Один для slapd-config і один для ваших даних (dc = example, dc = com). Давайте поглянемо:

Тут показано як виглядає дерево (DIT) бази даних slapd-config. Нагадаємо, що ця база заснована на LDIF і знаходиться в /etc/ldap/slapd.d:

Чи не редагуйте базу slapd-config безпосередньо. Вносьте зміни через протокол LDAP (утилітами).

Тут показано як виглядає дерево slapd-config через LDAP протокол:

Пояснення по записах:

Ви зробили це! Дві бази (суфікс: dc = example, dc = com) будуть тепер синхронізовані.

Як тільки реплікація стартує, ви можете відстежувати її запустивши:

Якщо ваше з'єднання повільне і / або ваша база LDAP велика, процес приведення у відповідність contextCSN Споживача і Постачальника може бути протяжним. Але, ви повинні знати, що процес запускається як тільки contextCSN Споживача неминуче збільшується.

Щоб перевірити, що все працює, просто запитайте на Споживача DN з бази:

Ви повинні побачити користувача # 'John #' і групу # 'Miners #', також як Ноди # 'People #' і # 'Groups #'.

Управління який тип доступу (читання, запис та ін.) Користувачів повинен бути наданий до ресурсів відомий як контроль доступу. Сполучення подібних директив називаються Списками контролю доступу (ACL).

Коли ми встановлюємо пакет slapd різні ACL встановлюються автоматично. Ми розглянемо деякі важливі наслідки цих замовчувань і, займаючись цим, ми зрозуміємо ідею того, як працюють ACL і як їх налаштовувати.

Для отримання ефективних ACL для запиту LDAP нам треба подивитися на ACL записи запитуваної бази даних також як і на записі спеціального примірника бази даних переднього плану. За замовчуванням використовуються ACL. отримані останньою дією, в разі, якщо вони не збігаються з правилами з попереднього варіанту. База даних переднього плану опитується в другу чергу і застосовується ACL за першим збігом серед цих двох джерел ACL. Наступні команди покажуть відповідно ACL бази hdb ( "dc = example, dc = com") і вони ж з бази переднього плану:

залишений оригінал попереднього абзацу, оскільки не впевнений, що правильно зрозумів сенс:

To get the effective ACL for an LDAP query we need to look at the ACL entries of the database being queried as well as those of the special frontend database instance. The ACLs belonging to the latter act as defaults in case those of the former do not match. The frontend database is the second to be consulted and the ACL to be applied is the first to match ( «first match wins») among these 2 ACL sources. The following commands will give, respectively, the ACLs of the hdb database ( «dc = example, dc = com») and those of the frontend database:

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

Найперший ACL дуже важливий:

Це може бути представлено по-іншому для кращого розуміння:

Цей складовою ACL (їх два) наказує наступне:

Атрибут userPassword не доступний для всіх інших користувачів за винятком rootDN, який має повний доступ.

Пошук по цьому DIT може бути проведено анонімно через # 'By * read #' в даному ACL.

Як зазначалося раніше, ніяких адміністративних користувачів не створюється для бази slapd-config. Однак існує ідентифікація SASL, яка забезпечує повний доступ до неї. Вона подібна до суперкористувачеві для localhost (root / sudo). Ось вона:

Наступна команда покаже ACL бази slapd-config:

Оскільки це SASL ідентифікація, нам буде потрібно механізм SASL, коли запитується LDAP утиліта, про яку йде мова і ми побачимо це багато разів в цьому посібнику. Це зовнішній (EXTERNAL) механізм. Дивіться попередню команду в якості прикладу. Зверніть увагу:

Ви повинні використовувати sudo для ідентифікації як root щоб ACL спрацювали.

Короткий шлях для отримання всіх ACL виглядає наступним чином:

Є ще багато що сказати по контролю доступу. Дивіться сторінку керівництва по slapd.access.

Коли відбувається аутентифікація на OpenLDAP сервері, найкраще це робити використовуючи зашифровану сесію. Це може бути досягнуто використанням транспортного рівня шифрування (TLS).

Тут ми організуємо свій власний Центр сертифікатів (Certificate Authority - CA) і потім створимо і підпишемо сертифікат нашого LDAP сервера від імені цього CA. Оскільки slapd скомпільовано з використанням бібліотеки gnutls. ми будемо використовувати для виконання цих завдань утиліту certtool.

Встановлюємо пакети gnutls-bin і ssl-cert:

Створюємо секретний ключ Центру сертифікатів: