Ldap linux что это
Обновлено: 04.07.2024
Атрибут имеет тип (имя/описание) и одно или несколько значений.
Каждый атрибут должен быть определен как минимум в одном 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".
Установка
Установка сервиса сервера 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 протокол:
Объяснение по записям:
cn=config: глобальные настройки
cn=module,cn=config: динамически загружаемый модуль
cn=schema,cn=config: содержит жестко запрограммированную схему системного уровня
cn=core,cn=schema,cn=config: жестко запрограммированная схема ядра (core)
cn=cosine,cn=schema,cn=config: схема cosine
cn=nis,cn=schema,cn=config: схема nis
cn=inetorgperson,cn=schema,cn=config: схема inetorgperson
olcDatabase=frontend,cn=config: база переднего плана, настройка по умолчанию для других баз данных
olcDatabase=config,cn=config: конфигурационная база slapd (cn=config)
olcDatabase=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:
Важно, чтобы значения uid и gid в вашем каталоге не совпадали с локальными значениями. Используйте диапазон больших чисел, начинающийся, например, с 5000. Устанавливая значения uid и gid высокими для ldap, вы сможете проще контролировать что могут делать локальные пользователи, а что ldap. Подробнее далее.Мы можем проверить, что информация добавлена правильно с помощью утилиты ldapsearch:
Объяснения по параметрам:
-x: "простое" связывание; не будет использоваться метод SASL по умолчанию
-LLL: отключить вывод посторонней информации
uid=john: "фильтр" для нахождения пользователя john
cn gidNumber: запрос на вывод определенных атрибутов (по умолчанию выводятся все атрибуты)
Изменение базы данных настройки slapd
Дерево (DIT) slapd-config также может запрашиваться и изменяться. Здесь приведено несколько примеров.
Используйте ldapmodify для добавления индекса (атрибут DbIndex) для вашей hdb,cn=config базы (dc=example,dc=com). Создайте файл с названием uid_index.ldif следующего содержания:
Затем выполните команду:
Вы можете подтвердить изменения следующим способом:
Давайте добавим схему. Это будет первый раз, когда потребуется конвертация в LDIF формат. Вы можете найти несконвертированные схемы в добавление к сконвертированным в каталоге /etc/ldap/schema.
Удаление схемы из базы slapd-config - нетривиальная задача. Потренируйтесь добавлять схемы на тестовой системе.
Перед добавлением любой схемы, вам следует проверить какие схемы уже установлены (показан вывод по умолчанию, для состояния "из коробки"):
В следующем примере мы добавим схему CORBA.
Создайте конфигурационный файл преобразования schema_convert.conf, содержащий следующие строки:
Создайте каталог назначения ldif_output.
Определите индекс схемы:
Когда slapd вводит объекты с тем же родительским DN, он создает индекс для этого объекта. Индекс обрамляется скобками: .Используйте slapcat для выполнения преобразования:
Сконвертированная (преобразованная) схема теперь в cn=corba.ldif
Редактируйте cn=corba.ldif, по достижении следующих атрибутов:
Также удалите следующие строки в конце:
Значения ваших атрибутов могут быть другими.
Наконец, используйте ldapadd для добавления новой схемы к дереву slapd-config:
Проверьте текущую загруженную схему:
Ведение журналов
Создайте файл logging.ldif со следующим содержимым:
Вы можете решить изменить настройки 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:
Убедитесь, что следующие атрибуты имеют корректные значения:
binddn (DN администратора, которым вы пользуетесь)
credentials (пароль для DN администратора, который вы используете)
searchbase (суффикс базы, которую вы используете)
olcUpdateRef (hostname сервера Поставщика или его IP адрес)
rid (Replica ID, уникальное трехзначное число, идентифицирующее данную копию. Каждый Потребитель должен иметь минимум один rid)
Добавьте новый контент:
Вы сделали это! Две базы (суффикс: dc=example,dc=com) будут теперь синхронизированы.
Проверка
Как только репликация стартует, вы можете отслеживать ее запустив:
Если contextCSN Потребителя отсутствует или не совпадает со значением Поставщика, вы должны остановиться и понять причину проблемы перед тем как продолжить. Попробуйте проверить slapd (syslog - системный журнал) и файлы журналов авторизации Поставщика, чтобы увидеть удачны ли были запросы авторизации Потребителя и не возвращались ли ошибки в ответ на запросы данных (они будут видны как множество записей ldapsearch).
Чтобы проверить, что все работает, просто запросите на Потребителе DN из базы:
Контроль доступа
Управление какой тип доступа (чтение, запись и пр.) пользователей должен быть предоставлен к ресурсам известен как контроль доступа. Сочетания подобных директив называются Списками контроля доступа (ACL ).
Это может быть представлено по-другому для лучшего понимания:
Атрибут userPassword не доступен для всех других пользователей за исключением rootDN, который имеет полный доступ.
Для того чтобы пользователи могли менять собственные пароли, используя passwd или иные утилиты, атрибут shadowLastChange должен быть доступен как только пользователь авторизовался.
Как указывалось ранее, никаких административных пользователей не создается для базы 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:
Создаем самоподписанный сертификат центра:
Создаем секретный ключ для сервера:
Замените ldap01 в имени файла на имя вашего сервера (hostname). Имена сертификата и ключа для узла и сервиса, которые будут их использовать, помогут сохранять ясность понимания.Создаем информационный файл /etc/ssl/ldap01.info, содержащий следующее:
Данный сертификат будет действителен 10 лет (3650 дней). Вы можете выбрать другое значение.
Создаем серверный сертификат:
Используйте команду 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 со следующим содержимым:
Применяем эти изменения:
И перестартуем slapd:
На Постащике:
Установление подлинности через LDAP
Результат диалога можно увидеть в /etc/ldap.conf. Если ваш сервер требует опции, недоступные в меню, редактируйте этот файл самостоятельно.
Настраиваем систему на использование LDAP для аутентификации:
Теперь вы имеете возможность входить в систему, используя учетные записи на основе LDAP .
Запросы имеют таймаут и будет попытка обратиться к Потребителю (ldap02), если Поставщик (ldap01) станет недоступным.
Альтернативой пакету libnss-ldap является пакет libnss-ldapd. Однако он добавит в систему пакет nscd, который, возможно, нежелателен. Просто впоследствии удалите его.Управление пользователями и группами
Пакет ldap-utils поставляется с достаточным количеством утилит для управления каталогами, но необходимость использовать длинные строки с опциями делает их применение обременительным. Пакет ldapscripts содержит оберточные сценарии (wrapper scripts) для этих утилит, которые некоторые находят более удобными в использовании.
Затем редактируем файл /etc/ldapscripts/ldapscripts.conf для получения нечто похожего на следующее:
Теперь создаем файл ldapscripts.passwd чтобы разрешить rootDN доступ к каталогу:
Замените "secret" на действующий пароль для пользователя rootDN вашей базы.Сценарии теперь готовы помогать в управлении вашим каталогом. Здесь несколько примеров как их использовать:
Создать нового пользователя:
Это создаст пользователя с uid george и установит gid example в качестве первичной пользовательской группы.
Классная статья, спасибо автору
По просьбам трудящихся, из-за отсутствия простого мануала для всех начинающих, светлых администраторов UNIX , и внедрению технологий светлых в тыл компаний и корпораций использующих темные силы Микрософта - посвящается сие писание =).
- Организовать общую адресную книгу для предприятия.
- Научится просто и эффективно управлять OpenLDAP и адресной книгой.
- Подсадить пользователей на правильный почтовый клиент.
Предисловие
На любом предприятии рано или поздно возникает вопрос о централизованном хранилище электронных адресов, принтеров и тп. Это все может реализовать с помощью OpenLDAP. В данной статье, я опишу основные параметры необходимые для работы OpenLDAP в качестве адресной книги и по дополнительным просьбам я расширю и дополню, если вам будет чего либо не хватать. Но я уверен, что вы и сами сможете расширить функционал OpenLDAP без лишних просьб, а лишь чтением манов и гуглением.
Основные термины
OpenLDAP Software - открытая реализация LDAP, разработанная проектом OpenLDAP Project. Распространяется под собственной лицензией, называемой OpenLDAP Public License. LDAP - платформенно-независимый протокол. В числе прочих есть реализации для различных модификаций BSD, а также GNU/Linux , AIX, HP-UX, Mac OS X, Solaris, Microsoft Windows (2000, XP) и z/OS.
LDAP (Lightweight Directory Access Protocol) представляет средства доступа к логически иерархической БД. Каталог (БД) состоит из записей (объектов). Иерархическая совокупность объектов (вложение контейнеров) определяет дерево каталога. Правила связывания определяются набором правил, который называется схемой каталога (в схему входят также описания классов). Дерево начинается от корневого объекта (класс Top в Active Directory).
Тип объекта (класс) определяется набором атрибутов: имя, тип значения, обязательность. Строки в кодировке UTF-8. Объект может ассоциироваться с несколькими классами. Класс может быть расширением другого класса (наследование). Кроме простых объектов имеются контейнеры (группировка объектов и контейнеров), псевдонимы (символьные ссылки), переадресация клиента к другому каталогу (переход по ссылкам, chasing referrals).
Каждый объект имеет относительное отличительное имя (Relative Distinguished Name). Полное отличительное имя объекта (DN) образуется конкатенацией RDN объекта с DN объекта верхнего уровня (порядок записи - от младшего к старшему, разделитель - точка). Каждый объект имеет владельца. В качестве идентификатора аутентификации также используется DN (cn=,dc=). Имеется выделенный администратор каталога, обладающий корневыми полномочиями. Для аутентификации используется расширяемый механизм SASL.
Поиск объекта в иерархии производится с помощью составного имени с корня вниз (как в DNS). Есть возможность анонимного доступа. Права доступа - чтение и запись и поддерживается репликация LDAP сервера.
Общие имена атрибутов:
- c - страна
- st - регион
- l - местность
- o - организация
- ou - подразделение
- dc - domain container
- cn - имя
- sn - фамилия
- mail - электронный адрес
- подключиться к серверу БД (запрос привязки), для аутентификации используются механизмы SASL
- читать значения определённых атрибутов конкретного объекта
- сравнить значения с атрибутом объекта (полезно для аутентификации сравнением хеша)
- искать объекты по значениям атрибутов (указывается корень поддерева, максимальное количество результатов, максимальное время поиска, фильтр поиска, перечень желаемых атрибутов)
- получить список объектов ниже по иерархии
- отменить предыдущий запрос
- добавить, изменить или удалить объект
- переименовать объект
Компоненты OpenLDAP
Открытое программное обеспечение OpenLDAP состоит из нескольких основных компонентов:
- slapd - независимый LDAP демон (сервер)
- slurpd - независимый LDAP демон обновления и репликации
- библиотеки реализующие протокол LDAP, утилиты, инструменты и элементарные клиенты.
Примеры клиентов: ldapsearch, ldapadd, ldapdelete и других.
Также содержится для OpenLDAP проекта:
- JLDAP - библиотеки классов LDAP для Java
- JDBC-LDAP - драйвер интерфейса между Java JDBC - LDAP
Установка
Ставим OpenLDAP
Установка OpenLDAP стандартна и поэтому, вкратце пройдемся по ней:
Мы нашли две версии этого порта 2.3 и 2.4, и я остановился на 2.4 ввиду ее перспективности.
Сконфигурируем и выберем необходимые модули:
Настройка OpenLDAP
Приступим к настройке OpenLDAP.
Внесем в /etc/rc.conf следующее:
По умолчанию ldap слушает все интерфейсы ldap://0.0.0.0/, но я укажу конкретно, что ему слушать это localhost и интерфейс сетевой платы. Например, вот так:
Теперь необходимо откорректировать конфигурационный файл OpenLDAP. Скопируем дефолтный конфигурационный файл:
Пройдемся по конфигурационному файлу:
include - подключаемые схемы; в поставке OpenLDAP их довольно много. И вы подключите только те, которые будете использовать. В принципе, схемы являются частью конфигурационного файла, но для наглядности они вынесены в отдельные фрагменты. С указанием пути откуда они берутся.
modulepath и moduleload - запускаемый сервис и модуль используемого способа хранения данных.
access - для управления доступом используются списки доступа ACL. В данном примере приводятся два списка — в первом из них ограничивается доступ к атрибуту userPassword (полный доступ к нему могут иметь только сам объект либо администратор базы; для всех остальных доступ запрещён). Второе правило гласит, что всем даётся доступ на чтение любых данных (кроме ограниченного предыдущим правилом).
database - способ хранения данных используемый нами.
suffix - корнем иерархической структуры будет являться некоторый объект например dc=example,dc=com (я буду использовать для примера суффикс
dc=ampul,dc=local) у вас он соответственно будет другим. Суффикс для каталога можно взять любой.
rootdn - DN, описывающий администратора
rootpw - хешированый SSHA пароль администратора (см. slappasswd(8))
Утилита slappasswd позволяет создавать хеш пароля для дальнейшего использования в качестве значения атрибута userPassword или опции rootpw файла slapd.conf.
Параметры:
-v - многословный режим
-u - (пока по умолчанию; создавать хеш для userPassword в формате, определённом RFC 2307)
-s - пароль (если не задан здесь или с помощью ключа -T, то запрашивается в диалоге)
-T - имя файла с паролем
-h - схема (; метод хеширования пароля: , , , , , )
-c - формат (формат как в sprintf(3) для преобразования случайной строки символов из диапазона [A-Za-z0-9./]; например, "%.2s" даёт соль для стандартной функции crypt(3); "$1$%.8s" приводит к использованию функцией crypt(3) алгоритма MD5, так что результат можно использовать в /etc/shadow)
Создать хешированный пароль для пользователя root можно так:
Запуск OpenLDAP
После изменение slapd.conf запускаем сервис и проверяем работу.
Если вы все корректно сконфигурировали, то openldap запустится без проблем.
Сейчас нам необходимо создать корень:
Добавим нашу схему в OpenLDAP.
Управление
Web интерфейс
Я давно подсел на web приложения потому, что я могу запускать их отовсюду и из любой системы будь то *NIX, Windows , Linux и т.п. Простота в обслуживании, обновлении, единая точка входа и управления и т.п. Для OpenLDAP есть несколько приложений которые могут помочь в администрировании OpenLDAP - мой выбор остановился на phpLDAPadmin.
- Добавьте в конфигурационный файл Apache следующие строки предварительно настроив под себя
Программное обеспечение
Есть несколько программных продуктов, которые позволяют управлять LDAP серверами, но они, в основном, платные. Я остановился на LDAP Admin, он быстрый, бесплатный и простой, что позволяет его использование обычному пользователю. Настроить его очень легко см скриншоты.
Адресная книга в почтовых клиентах
Mozilla Thunderbird
Thunderbird использует LDAPv3. Добавим LDAP-сервер в адресную книгу.
Введем корректный адрес и данные сервера OpenLDAP
Поиск производится при введении строки поиска в поле (ничего нажимать не надо, поиск производится по мере ввода) по cn, givenName, sn и считывает следующий список атрибутов: modifytimestamp, xmozillausehtmlmail, description, notes, custom4, custom3, custom2, custom1, birthyear, homeurl, workurl, nscpaimscreenname, countryname, company, o, departmentnumber, department, orgunit, ou, title, zip, postalcode, region, st, locality, l, streetaddress, postofficebox, carphone, cellphone, mobile, pagerphone, pager, facsimiletelephonenumber, fax, homephone, telephonenumber, xmozillasecondemail, mail, xmozillanickname, displayname, commonname, cn, surname, sn, givenname.
Outlook Express.
Outlook Express использует LDAPv2. Добавим LDAP-сервер в адресную книгу для этого выбираем в меню Сервис -> Учётные записи -> Добавить -> Служба каталогов -> Сервер каталогов (LDAP).
Затем изменить свойствах созданной службы каталогов во вкладке Дополнительно вставте свою Основу поиска например (ou=addressbook,dc=ampul,dc=local).
Поиск производится по нажатию кнопки "Поиск людей", вводу параметров и нажатию кнопки "Найти". Предварительно опрашивается список возможности сервера: subschemaSubentry, dsServiceName, namingContexts, defaultNamingContext, schemaNamingContext, configurationNamingContext, rootDomainNamingContext, supportedControl, supportedLDAPVersion, supportedLDAPPolicies, supportedSASLMechanisms, dnsHostName, ldapServiceName, serverName, supportedCapabilities.
По умолчанию поиск по атрибутам cn, givenName, sn, но можно искать по "имя и адрес" (cn), "электронная почта" (mail), имени (givenName), фамилии (sn), организации (o). Считывает следующий список атрибутов: display-name, cn, commonName, mail, otherMailbox, givenName, sn, surname, st, c, co, organizationName, o, ou, organizationalUnitName, URL, homePhone, facsimileTelephoneNumber, otherFacsimileTelephoneNumber, OfficeFax, mobile, otherPager, OfficePager, pager, info, title, telephoneNumber, l, homePostalAddress, postalAddress, streetAddress, street, department, comment, postalCode, physicalDeliveryOfficeName, initials, conferenceInformation, userCertificate;binary, userSMIMECertificate;binary, labeledURI, Manager, Reports, IPPhone.
Чтобы сохранять всю необходимую информацию о человеке его запись должна иметь классы: top, person, organizationalPerson, inetOrgPerson, residentialPerson.
Outlook 2003
Схема подключения Outlook 2003 к OpenLDAP см прикрепленные файлы к статье.
В) Как в адресной книге вывести всех клиентов у которых есть электронная почта
O) Ввести в поле поиска символ "@"
В) Какой порт использует LDAP сервер
О) Стандартный TCP порт LDAP сервера - 389. Для защиты соединения может использоваться TLS (SSL ) (порт 636).
LDAP Linux HOWTO
В этом документе представлена информация об установке, настройке, запуске и обслуживании LDAP (Lightweight Directory Access Protocol) сервера на Linux. Также приводятся детали создания LDAP баз данных, способов обновления и удаления информации из базы данных, путей реализации роуминга и способов использования Netscape Address Book. В основном этот документ основывается на информационных страницах о LDAP Мичиганского Университета (University of Michigan) и OpenLDAP Administrator's Guide.
Введение
Главная цель этого документа - установка и использование сервера каталогов LDAP на вашей Linux машине. Вы научитесь устанавливать, настраивать, запускать и обслуживать LDAP сервер. Далее вы научитесь способам помещения, извлечения и обновления информации в вашем каталоге с помощью клиентов LDAP и утилит. Демон для LDAP сервера каталогов называется slapd , и он запускается на многих различных UNIX платформах.
Также есть другой демон, который заботится о репликации между LDAP серверами. Он называется slurpd и, в данный момент, вам не следует о нем беспокоится. В этом документе вы запускаете slapd, который предоставляет службу каталогов только для вашего домена, без репликации, следовательно, без slurpd.
Такие простые настройки сервера хороши для начала, и, если вы захотите, позже их легко можно обновить до другой конфигурации. Представленная в этом документе информация представляет собой хорошее введение в использование протокола LDAP. Возможно, после прочтения этого документа вы почувствуете себя увереннее для расширения возможностей вашего сервера, и даже написания собственных клиентов, используя доступные C, C++ и Java Development Kits.
Что такое LDAP?
LDAP - клиент-серверный протокол для доступа к службе каталогов. Изначально он использовался как надстройка над X.500, но он также может быть использован с автономными и прочими видами служб каталогов.
Что такое служба каталогов?
Каталог подобен базе данных, но склонен содержать более описательную, основанную на атрибутах информацию. Обычно информация в каталоге более часто считывается, чем записывается. И, как следствие, каталоги обычно не реализуют сложные транзакции или схемы отката, которые используются в обычных базах данных для выполнения сложных и объемных обновлений. Обновления каталога обычно простые изменения вида все-или-ничего, если они вообще разрешены.
Каталоги настроены для обеспечения быстрого отклика при обзоре большого объема данных или операциях поиска. Они могут иметь способность широко реплицировать информацию, для обеспечения высокой доступности и надежности, при одновременном уменьшении времени ответа. Когда информация каталога реплицирована, допустимы временные несоответствия между репликациями, пока они, в конечном счете, не синхронизируются.
Существует много различных путей реализовать службу каталогов. Различные методы позволяют помещать в каталоге информацию различного типа, помещать различные требования на то, как на эту информацию можно ссылаться, запрашивать и обновлять, как она защищается от несанкционированного доступа и т.п. Некоторые службы каталогов локальны, и предоставляют службы в ограниченном контексте (например, служба finger на одной машине). Другие службы глобальны, и предоставляют обслуживание в более обширном контексте.
Как работает LDAP?
Служба каталогов LDAP основана на клиент-серверной модели. Один или более серверов LDAP содержат данные составляющие дерево каталога LDAP, или базу данных LDAP. Клиент LDAP подключается к LDAP серверу и задает ему вопросы. Сервер выдает ответ или указатель места, где клиент может получить более подробную информацию (обычно, другой LDAP сервер). Не имеет значения, к какому LDAP серверу подключается клиент, он видит один и тот же каталог; имя представленное в одном LDAP сервере ссылается на тот же элемент что и другой LDAP сервер. Это важное свойство глобальной службы каталогов LDAP.
Механизмы баз данных LDAP, объекты и атрибуты
Slapd поставляется с тремя различными механизмами баз данных, которые вы можете выбрать. Это: LDBM - высокоскоростная дисковая база данных; SHELL - интерфейс базы данных к обычным UNIX командам и shell скриптам; и PASSWD - простая база данных на основе файла паролей.
В этом документе я предполагаю, что вы выбрали базу данных LDBM.
База данных LDBM работает, назначая компактный уникальный четырехбайтовый идентификатор каждому элементу базы данных. Она использует этот идентификатор для ссылок на записи из индексов. База данных состоит из одного главного файла индексов под названием id2entry, который устанавливает соответствие уникального индекса элемента (EID) текстовому представлению самого элемента. Также поддерживаются другие индексные файлы.
Для импортирования или экспортирования информации каталога между серверами каталогов основанных на LDAP или для описания набора вносимых в каталог изменений, обычно используется формат LDIF, т.е. LDAP Data Interchange Format. Файл LDIF хранит информацию об объектно-ориентированной иерархии элементов. Пакет LDAP, который вы собираетесь использовать, поставляется с утилитой конвертирования LDIF файлов в LDBM формат.
Типичный LDIF файл выглядит так:
Вы можете заметить, что каждый элемент уникально идентифицируется отличительным именем DN. Отличительное имя состоит из имени элемента плюс путь имен ведущих к вершине иерархии каталога.
В LDAP, класс объектов определяет набор атрибутов, которые используются для определения элемента. Стандарт LDAP определяет такие основные виды классов объектов:
Группа каталогов, включая неупорядоченный список индивидуальных объектов или групп объектов.
Местоположение, такое как имя страны и описание.
Организации в каталоге.
Люди в каталоге.
Элемент может принадлежать более чем одному классу. Например, элемент человека определен классом объектов person , но также могут быть определены атрибуты в классах объектов inetOrgPerson, groupOfNames и organization. Структура классов объектов сервера (его схема) определяет общий список требуемых и разрешенных атрибутов отдельного элемента.
Данные каталога представлены в виде пар атрибут-значение. Любая определенная часть информации ассоциируется с этим описательным атрибутом.
Требуемые атрибуты включают атрибуты, которые могут представляться в элементах, используя класс объектов. Все элементы требуют наличия атрибута objectClass, в котором перечислены классы объектов, к которым принадлежит элемент.
Разрешенные атрибуты включают атрибуты, которые могут быть представлены в элементах класса объектов. Например, в классе объектов person, обязательны атрибуты cn и sn. Атрибуты description, telephoneNumber, seeAlso, и userpassword разрешены, но не обязательны.
Каждый атрибут имеет соответствующее синтаксическое определение. Синтаксическое определение описывает тип предоставляемой атрибутом информации:
bin "binary" двоичный
ces "case exact string" строка с соответствием регистра (регистр символов должен совпадать при сравнении)
cis "case ignore string" строка с игнорированием регистра (регистр символов игнорируется при сравнении)
tel строка с номером телефона (подобен cis но пробелы и тире `- ' игнорируются при сравнении)
dn "distinguished name" отличительное имя
Новые версии этого документа
В этот документ могут вноситься исправления и обновления на основе обратной связи с читателями. Новые версии этого HOWTO следует искать на:
Мнения и предложения
Если у вас есть какие-либо сомнения по поводу приведенной в этом документе информации, пожалуйста, свяжитесь со мной по следующему email адресу:
Также дайте мне знать, если у вас есть комментарии и/или предложения!
История издания
В этой секции перечислены отсортированные по дате выпуски этого документа. Каждый выпуск включает в себя изменения, внесенные в более ранние версии плюс новые дополнения и корректировки:
v1.0: 20 Июня 1999, Первоначальная версия
v1.01: 15 Февраля 2000, дополнен следующими секциями:
Утилиты миграции LDAP
Аутентификация с помощью LDAP
Графические утилиты LDAP
v1.02: 13 Сентября 2000, коррекция опечаток и дополнения в следующих секциях:
v1.03: 28 Сентября 2000, представлен OpenLDAP 2.0, который охватывает LDAPv3, определенный в RFC2251.
v1.04: 28 Февраля 2001, исправления опечаток и обновления в следующих секциях:
Аутентификация с помощью LDAP
v1.05: 22 Июня 2001, исправления длинных строк, которые вызывали несовместимость с PDF версией этого документа.
Благодарности
Этот Howto - результат моей интернатуры в TUDelft University - Нидерланды. Я хотел бы поблагодарить людей, которые помогали мне в написании этого документа: Rene van Leuken и Wim Tiwon. Огромное им спасибо. Они такие же поклонники Linux, как и я.
Также я хотел бы поблагодарить Thomas Bendler, автора Немецкого варианта Ldap-Howto - Joshua Go, за его дополнения к моему документу, великих добровольцев из проекта LDP и Hugo van der Kooij, за его подсказки по секции Роуминг.
Авторские права и отречение
За содержимое этого документа не может возлагаться никакая ответственность. Я не ответственен за последствия приведенных в этом документе шагов.
Если у вас есть вопросы, пожалуйста, свяжитесь с координатором HOWTO по адресу
Данное открытое руководство о LDAP, OpenLDAP 2.x и ApacheDS на Linux и BSD (FreeBSD, OpenBSD и NetBSD). Оно предназначено для как для новичков, так и для светил науки, а также для всех тех, кто находится между ними.
LDAP — сложный предмет. Данное руководство родилось из наших жалких попыток понять LDAP, поскольку он обещал настоящую нирвану — общий источник информации, неограниченную масштабируемость путём использования модели репликации, врождённую устойчивость, высокоскоростное получение данных, детальный контроль над тем, кто, что и с какими данными может сделать — этот список можно продолжать. Чудесная вещь!
Плохая новость заключается в том, что, по нашему скромному мнению, никогда не было написано так много непонятного об одном предмете, за исключением, пожалуй, BIND и . и ещё . Есть бесчисленные отличные HOWTO, разбросанные по Интернету, которые прекрасны, если Вам нужно тактическое решение частной проблемы, и Вы готовы смириться со смутным неприятным чувством, что полностью зависите от чего-то такого, чего на самом деле не понимаете. Нам не нужно тактическое решение, нам было нужно стратегическое решение целого комплекса проблем, каждая из которых кажется идеально предназначенной для LDAP, но нам нужно было понять предмет . нам нужно было WHYTO. Эта и есть наша, — возможно, жалкая, — попытка создать его.
Давным-давно OpenLDAP был единственной звездой на небосклоне Open Source LDAP. Он до сих пор считается эталонной реализацией LDAP и остается отличной системой с большим количеством реализованных возможностей, активно развивающейся и необыкновенно комплексной, что позволяет использовать его для решения нетривиальных задач. Однако, это уже не единственная звезда на небосклоне. Теперь есть 389 Directory Server (бывший Fedora Directory Server), другая производная от проекта Мичиганского Университета, OpenDJ (ответвление от OpenDS — оригинальной реализации на Java от Sun, разработка которой прекращена), и проект ApacheDS (Apache Directory). Всё это чудесные проекты, и, вместе с OpenLDAP, они ошеломляют обилием продвинутых возможностей и функциональности в пространстве Open Source LDAP. Некоторые заметки об этих проектах и наши о них рассуждения Вы найдете здесь, если, конечно, Вас интересуют подобного рода вещи.
Во все будущие версии данного руководства будет постепенно добавляться материал, описывающий использование ApacheDS, при этом документирование OpenLDAP будет продолжено.
<Предупреждение> Эта работа ещё далека от завершения. Если Вы нашли ошибку — не ворчите, сообщите нам. Посмотрите также наш список доработок, и если Вы хотите внести вклад — милости просим. И за этот тяжкий труд мы можем пообещать Вам лишь тёплые чувства нашего доброго отношения и признание Ваших заслуг в лицензии. </Предупреждение>
Читайте также: