OpenLDAP сервер

Содержание

OpenLDAP сервер

Запись содержит набор атрибутов.

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

Каждый атрибут должен быть определен как минимум в одном objectClass.

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

Каждая запись имеет уникальный идентификатор: свое Отличительное имя (DN или dn). Она состоит из своего Относительного отличительного имени (RDN), следующим за записью родительского DN.

DN записи — это не атрибут. Оно не является рассматриваемой частью собственно записи.

Например, далее мы имеем одну запись, содержащую 11 атрибутов. Ее DN — это «cn=John Doe,dc=example,dc=com«; ее RND — это «cn=John Doe«; а родительский DN — «dc=example,dc=com«.

Установка

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

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

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

Продолжим с установкой:

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

Некоторые классические схемы (cosine, nis, inetorgperson) выпускаются теперь для slapd. Это также включает базовую (core) схему, которая предполагается для любой рабочей схемы.

Проверка после установки

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

Здесь показано как выглядит дерево (DIT) базы данных slapd-config. Напомним, что эта база основана на LDIF и находится в /etc/ldap/slapd.d:

Здесь показано как выглядит дерево slapd-config через LDAP протокол:

Объяснение по записям:

cn=config: глобальные настройки

cn=module<0>,cn=config: динамически загружаемый модуль

cn=schema,cn=config: содержит жестко запрограммированную схему системного уровня

cn=<0>core,cn=schema,cn=config: жестко запрограммированная схема ядра (core)

cn=<1>cosine,cn=schema,cn=config: схема cosine

cn=<2>nis,cn=schema,cn=config: схема nis

cn=<3>inetorgperson,cn=schema,cn=config: схема inetorgperson

olcBackend=<0>hdb,cn=config: тип хранилища ‘hdb’ заднего плана

olcDatabase=<-1>frontend,cn=config: база переднего плана, настройка по умолчанию для других баз данных

olcDatabase=<0>config,cn=config: конфигурационная база slapd (cn=config)

olcDatabase=<1>hdb,cn=config: экземпляр вашей базы данных (dc=examle,dc=com)

А здесь показано как выглядит дерево dc=example,dc=com:

Объяснение по записям:

dc=example,dc=com: базовый уровень вашего дерева (DIT)

cn=admin,dc=example,dc=com: администратор (rootDN) данного дерева (заполняется в процессе установки пакета)

Изменение/заполнение вашей базы данных

Давайте введем некоторые данные в нашу базу. Мы добавим следующее:

ноду с названием People (сохранять пользователей)

ноду с названием Groups (сохранять группы)

группу с названием miners

пользователя с именем john

Создайте следующий LDIF файл и назовите его add_content.ldif:

Мы можем проверить, что информация добавлена правильно с помощью утилиты ldapsearch:

Объяснения по параметрам:

-x: «простое» связывание; не будет использоваться метод SASL по умолчанию

-LLL: отключить вывод посторонней информации

uid=john: «фильтр» для нахождения пользователя john

cn gidNumber: запрос на вывод определенных атрибутов (по умолчанию выводятся все атрибуты)

Изменение базы данных настройки slapd

Дерево (DIT) slapd-config также может запрашиваться и изменяться. Здесь приведено несколько примеров.

Используйте ldapmodify для добавления индекса (атрибут DbIndex) для вашей <1>hdb,cn=config базы (dc=example,dc=com). Создайте файл с названием uid_index.ldif следующего содержания:

Затем выполните команду:

Вы можете подтвердить изменения следующим способом:

Давайте добавим схему. Это будет первый раз, когда потребуется конвертация в LDIF формат. Вы можете найти несконвертированные схемы в добавление к сконвертированным в каталоге /etc/ldap/schema.

Удаление схемы из базы slapd-config — нетривиальная задача. Потренируйтесь добавлять схемы на тестовой системе.

Перед добавлением любой схемы, вам следует проверить какие схемы уже установлены (показан вывод по умолчанию, для состояния «из коробки»):

В следующем примере мы добавим схему CORBA.

Создайте конфигурационный файл преобразования schema_convert.conf, содержащий следующие строки:

Создайте каталог назначения ldif_output.

Определите индекс схемы:

Используйте slapcat для выполнения преобразования:

Сконвертированная (преобразованная) схема теперь в cn=corba.ldif

Редактируйте cn=corba.ldif, по достижении следующих атрибутов:

Также удалите следующие строки в конце:

Значения ваших атрибутов могут быть другими.

Наконец, используйте ldapadd для добавления новой схемы к дереву slapd-config:

Проверьте текущую загруженную схему:

Ведение журналов

Ведение журнала активности для slapd обязательно, когда осуществляется решение на базе OpenLDAP, поэтому его требуется включить вручную после установки приложения. Иначе только элементарные сообщения будут доступны в журналах. Ведение журналов, как и другие настройки slapd, подключаются через базу данных slapd-config.

OpenLDAP поставляется с несколькими подсистемами (уровнями) журналирования, каждая из которых включает подчиненную (дополнительную). Хороший вариант, который стоит попробовать — это stats. Страница руководства slapd-config содержит больше информации по иным подсистемам.

Создайте файл logging.ldif со следующим содержимым:

Это породит значительный объем записи в журнал и вы захотите уменьшить уровень детализации когда ваша система станет боевой. С таким уровнем детализации система журналирования вашего хоста (rsyslog) может отнимать значительное время процессора, а также пропускать сообщения:

Вы можете решить изменить настройки rsyslog. В файл /etc/rsyslog.conf поместите следующее:

А затем перезапустите сервис rsyslog:

Репликация

Репликация доступна через механизм Syncrepl. Он позволят синхронизировать изменения используя модель Потребитель-Поставщик. Специфический вид репликации, который мы будем реализовывать в этом руководстве, является комбинацией следующих режимов: refreshAndPersist и delta-syncrepl. Это подразумевает что Потребитель передает измененные записи Поставщику, как только они появляются, но при этом посылаются только актуальные изменения, а не все записи.

Настройка Поставщика

Начнем с настройки Поставщика.

Создадим LDIF файл со следующим содержимым и назовем его provider_sync.ldif:

Замените rootDN в LDIF файле на соответствующий вашему каталогу.

Профиль apparmor для slapd нужно будет отрегулировать для расположения базы accesslog. Отредактируйте /etc/apparmor.d/local/usr.sbin.slapd, добавив следующее:

Создаем каталог, устанавливаем файл настроек базы данных и перегружаем профиль apparmor:

Добавляем новый контент и, поскольку изменили apparmor, перестартуем сервис:

Поставщик теперь настроен.

Настройка Потребителя

А теперь настроим Потребителя.

Установим программное обеспечение как указано в Установке. Убедитесь, что база slapd-config аналогична базе Поставщика. Особенно проверьте, что одинаковы схемы и суффикс базы.

Создайте LDIF файл со следующим содержимым и назовите его consumer_sync.ldif:

Убедитесь, что следующие атрибуты имеют корректные значения:

provider (hostname сервера Поставщика — ldap01.example.com в этом примере — или IP адрес)

binddn (DN администратора, которым вы пользуетесь)

credentials (пароль для DN администратора, который вы используете)

searchbase (суффикс базы, которую вы используете)

olcUpdateRef (hostname сервера Поставщика или его IP адрес)

rid (Replica ID, уникальное трехзначное число, идентифицирующее данную копию. Каждый Потребитель должен иметь минимум один rid)

Добавьте новый контент:

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

Проверка

Как только репликация стартует, вы можете отслеживать ее запустив:

как на Поставщике, так и на Потребителе. Как только вывод (20120201193408.178454Z#000000#000#000000 в примере выше) на обеих машинах совпадет, вы провели репликацию. Каждый раз, как происходят изменения на Поставщике, это значение будет изменяться и должно стать таким же на Поставщике.

Если contextCSN Потребителя отсутствует или не совпадает со значением Поставщика, вы должны остановиться и понять причину проблемы перед тем как продолжить. Попробуйте проверить slapd (syslog — системный журнал) и файлы журналов авторизации Поставщика, чтобы увидеть удачны ли были запросы авторизации Потребителя и не возвращались ли ошибки в ответ на запросы данных (они будут видны как множество записей ldapsearch).

Чтобы проверить, что все работает, просто запросите на Потребителе DN из базы:

Вы должны увидеть пользователя ‘john’ и группу ‘miners’, также как ноды ‘People’ и ‘Groups’.

Контроль доступа

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

Это может быть представлено по-другому для лучшего понимания:

Анонимный ‘auth’ доступ обеспечивается к атрибуту userPassword для осуществления изначального соединения. Возможно потребуется counter-intuitively для ‘by anonymous auth’ даже когда анонимный доступ к DIT не требуется. Как только удаленное соединение установлено, требуется авторизация (см. следующий пункт).

Должна пройти авторизация, поскольку все пользователи имеют доступ на чтение (вследствие ‘by self write’) к атрибуту userPassword.

Атрибут userPassword не доступен для всех других пользователей за исключением rootDN, который имеет полный доступ.

Для того чтобы пользователи могли менять собственные пароли, используя passwd или иные утилиты, атрибут shadowLastChange должен быть доступен как только пользователь авторизовался.

Поиск по этому DIT может быть проведен анонимно из-за ‘by * read’ в данном ACL :

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

Следующая команда покажет ACL базы slapd-config:

Вы должны использовать sudo для идентификации как root чтобы ACL сработали.

Механизм EXTERNAL работает через IPC (доменные сокеты UNIX). Это означает , что вы должны использовать ldapi формат адресации (URI ).

Короткий путь для получения всех ACL выглядит следующим образом:

Есть еще много что сказать по контролю доступа. Смотрите страницу руководства по slapd.access.

Когда происходит аутентификация на OpenLDAP сервере, лучше всего это делать используя зашифрованную сессию. Это может быть достигнуто использованием транспортного уровня шифрования (TLS).

Устанавливаем пакеты gnutls-bin и ssl-cert:

Создаем секретный ключ Центра сертификатов:

Создаем временный файл /etc/ssl/ca.info для определения CA:

Создаем самоподписанный сертификат центра:

Создаем секретный ключ для сервера:

Создаем информационный файл /etc/ssl/ldap01.info, содержащий следующее:

Данный сертификат будет действителен 10 лет (3650 дней). Вы можете выбрать другое значение.

Создаем серверный сертификат:

Создайте файл certinfo.ldif со следующим содержимым (подставляйте свои значения, наш пример предполагает использование https://www.cacert.org):

Используйте команду ldapmodify, чтобы сказать slapd о работе нашего TLS через базу данных slapd-config:

Вопреки распространенному мнению, вам не обязательно указывать ldaps:// в /etc/default/slapd чтобы использовать шифрование. Вам достаточно указать:

Сужаем права на владение и доступ:

Проверьте ваши системные журналы (/var/log/syslog) чтобы убедиться что сервер запустился правильно.

Репликация и TLS

Если вы настроили репликацию между серверами, существует общая практика шифровать (StartTLS) трафик репликации для исключения прослушивания. Лучше всего использовать шифрование с аутентификацией как мы делали выше. В этой секции мы будем основываться на проделанной работе по TLS-аутентификации.

Здесь предполагается, что вы настроили репликацию между Поставщиком и Провайдером в соответствии с секцией Репликация и настроили TLS для аутентификации на Поставщике следуя инструкциям секции TLS.

На Поставщике:

Создаем промежуточный каталог (который будет использоваться для переноса) и затем секретный ключ Потребителя:

Создаем информационный файл ldap02.info для сервера Потребителя; подставляйте свои соответствующие значения:

Создаем сертификат Потребителя:

Получаем копию сертификата CA:

Все готово. Теперь переносим каталог ldap02-ssl на сервер Потребителя. Здесь мы использовали scp (данные изменяем соответственно):

На Потребителе:

Настраиваем TLS аутентификацию:

Создаем файл /etc/ssl/certinfo.ldif со следующим содержимым (исправляйте соответственно):

Настраиваем базу slapd-config:

Настраиваем /etc/default/slapd как на Поставщике (SLAPD_SERVICES).

На Потребителе:

Настраиваем TLS для репликации на стороне Потребителя. Изменяем существующий атрибут olcSyncrepl присоединяя некоторые TLS опции. Делая это, мы увидим в первый раз как изменять значения атрибутов.

Создаем файл consumer_sync_tls.ldif со следующим содержимым:

Дополнительные опции определяют, соответственно, что Потребитель должен использовать StartTLS и что CA сертификат требуется для идентификации Поставщика. Также обратите внимание на LDIF синтаксис для изменения значений атрибута (‘replace’).

Применяем эти изменения:

И перестартуем slapd:

На Постащике:

Проверяем, что TLS сессия устанавливается. В /var/log/syslog, предполагая что вы настроили уровень журналирования ‘conns’, вы сможете увидеть подобные записи:

Установление подлинности через LDAP

Результат диалога можно увидеть в /etc/ldap.conf. Если ваш сервер требует опции, недоступные в меню, редактируйте этот файл самостоятельно.

Настраиваем систему на использование LDAP для аутентификации:

Теперь вы имеете возможность входить в систему, используя учетные записи на основе LDAP .

Запросы имеют таймаут и будет попытка обратиться к Потребителю (ldap02), если Поставщик (ldap01) станет недоступным.

Управление пользователями и группами

Пакет ldap-utils поставляется с достаточным количеством утилит для управления каталогами, но необходимость использовать длинные строки с опциями делает их применение обременительным. Пакет ldapscripts содержит оберточные сценарии (wrapper scripts) для этих утилит, которые некоторые находят более удобными в использовании.

Затем редактируем файл /etc/ldapscripts/ldapscripts.conf для получения нечто похожего на следующее:

Теперь создаем файл ldapscripts.passwd чтобы разрешить rootDN доступ к каталогу:

Сценарии теперь готовы помогать в управлении вашим каталогом. Здесь несколько примеров как их использовать:

Создать нового пользователя:

Это создаст пользователя с uid george и установит gid example в качестве первичной пользовательской группы.