ldap server что это
/привет/мир/etc
Непериодические заметки о программировании
четверг, 31 октября 2013 г.
Что такое LDAP и с чем его едят
Как правило, служба каталогов
Для взаимодействия со службами каталогов X.500 широко используется протокол LDAP (Lightweight Directory Access Protocol), специфицированный в RFC4510. LDAP работает поверх TCP/IP и является легковесной альтернативой протокола DAP (Directory Access Protocol), весьма требовательного к вычислительным ресурсам.
LDAP реализует протокол взаимодействия со службой каталогов и задает модель данных, соответствующую X.500. Эта модель данных такова:
Запустим Softerra LDAP Browser и откроем одну из публичных служб каталогов, параметры соединения с которыми предустановлены по умолчанию. (Настроив соединение с MS Active Directory или OpenLDAP в вашей корпоративной сети, вы можете исследовать структуру и содержимое корпоративного каталога.)
Можно рассматривать DN как абсолютный путь к файлу (по аналогии с файловой системой) или как первичный ключ записи в таблице (по аналогии с реляционной БД).
В рассматриваемом DN o=CMRI,o=CMU,dc=cmu,dc=edu два верхних уровня названы по доменным именам Internet. А уровнем ниже текущей записи располагаются записи, идентифицируемые значением атрибута ou (см. картинку выше). Здесь имена атрибутов, идентифицирующие записи разных уровней, имеют следующие значения:
dc аббревиатура от domain component o аббревиатура от organization ou аббревиатура от organizational unit
Для поиска записей в LDAP-каталоге задаются три компонента:
Например, поиск по условию
На заметку: cуществуют специальные базовые DN для запроса информации о возможностях сервера, для доступа к схеме (schema) и данным мониторинга.
В Softerra LDAP Browser по Ctrl+F3 вызывается окно поиска, в котором удобно экспериментировать с параметрами поиска LDAP:
В фильтре можно использовать следующие проверки для атрибутов (атрибут ou взят для примера):
= использует фонетические сравнение. Расширенная проверка для сравнения образца со значением атрибута использует реализованное LDAP-сервером правило, идентификатор которого указан после двоеточия. Примеры выражений для проверки наличия подстроки (звездочка означает 0 или более символов):
Проверки в фильтре можно комбинировать при помощи логических операторов:
Чтобы хорошо освоить синтаксис фильтра, попробуйте разные проверки и их логические комбинации.
Как уже упоминалось, служба каталогов позволяет не только извлекать, но также добавлять и модифицировать записи. Softerra LDAP Browser поддерживает только просмотр данных в каталоге, поэтому для внесения изменений в каталог необходим другой инструмент (например, платный Softerra LDAP Administrator).
Для работы с LDAP практически из любого языка программирования можно воспользоваться существующими библиотекми для этого языка. В будущих статьях, посвященных LDAP, я рассмотрю работу с MS Active Directory в Oracle PL/SQL и в языке программирования Python.
Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
LDAP (Lightweight Directory Access Protocol)
Авторство | ||
В.Н. Давыдов | ||
Согласовано: 26.05.2016 |
Уровень (по модели OSI): | Прикладной |
---|---|
Семейство: | стек протоколов TCP/IP |
Порт/ID: | 389 / TCP или UDP |
Назначение протокола: | Доступ к службе каталогов |
Спецификация: | RFC 4510, RFC 4511, RFC 4512, RFC 4513, RFC 4514, RFC 4515, RFC 4516, RFC 4517, RFC 4518, RFC 4519, RFC 4520, RFC 4521 |
Вступил в силу с: | 1993 |
LDAP (англ. Lightweight Directory Access Protocol — «облегчённый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов (программному комплексу для хранения и каталогизации информации. По своей сути она очень похоже на обычную базу данных, но с «уклоном» скорее на чтение данных, нежели на их добавление или изменение. Обычно служба каталога базируется на клиент-серверной архитектуре. Одна из наиболее известных таких систем — DNS) X.500, разработанный IETF. Является облегченным и незначительно переработанным потомком протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.
Содержание
Использование
В UNIX/Linux-системах каталоги (и LDAP, как протокол доступа к ним) получили распространение для хранения системной информации, такой, например, как учётные записи пользователей и служебных настроек. Одним из наиболее распространённых LDAP-серверов в UNIX/Linux-системах является OpenLDAP. В Windows LDAP-сервер встроен в ActiveDirectory.
Функциональное описание протокола
В протоколе LDAP определены следующие операции для работы с Каталогом:
Пример обращения к службе каталога
Пример обращения к службе каталога по протоколу LDAP с помощью утилиты ldapsearch.
Аутентифицироваться при подключении к каталогу под именем cn=admin,dc=mydc,dc=com, использовать простую аутентификацию (-x), спросить пароль (-W). Результат выполнения команды ldapsearch представлен в формате LDIF (LDAP Interchange Format). В этом формате записи представляются как набор полей, каждое из которых записывается в отдельном поле в виде пары:
Найденная запись содержит поля dn, objectClass и ou и выглядит так:
Доступ к каталогу осуществляется от имени cn=admin,dc=mydc,dc=com, которое называется именем привязки (bind name). Имя привязки это полное имя (DN, distinguished name) учётной записи в каталоге пользователя, от имени которого будет производиться работа с каталогом.
Размещение записей в каталоге
Информационная модель LDAP основана на записях (entry). Запись — это коллекция атрибутов (attribute), обладающая уникальным именем (Distinguished Name, DN). DN глобально-уникально для всего каталога и служит для однозначного указания на запись. Каждый атрибут записи имеет свой тип (type) и одно или несколько значений (value). Обычно типы — это мнемонические строки, в которых отражено назначение атрибута, например «cn» — для общепринятого имени (common name), или «mail» — для адреса электронной почты. Синтаксис значений зависит от типа атрибута. Например, атрибут cn может содержать значение Babs Jensen. Атрибут mail может содержать значение «babs@example.com». Атрибут jpegPhoto будет содержать фотографию в бинарном формате JPEG.
Записи каталога LDAP выстраиваются в виде иерархической древовидной структуры. Традиционно, эта структура отражает географическое и/или организационное устройство хранимых данных. В вершине дерева располагаются записи, представляющие собой страны. Под ними располагаются записи, представляющие области стран и организации. Еще ниже располагаются записи, отражающие подразделения организаций, людей, принтеры, документы, или просто всё то, что Вы захотите включить в каталог. На рисунке показан пример дерева каталога LDAP, использующего традиционное именование записей.
Механизм работы
LDAP использует клиент-серверную модель. Один или несколько серверов LDAP содержат информацию, образующую информационное дерево каталога (directory information tree, DIT). Клиент подключается к серверу и делает запрос. В ответ сервер отправляет результаты обработки запроса и/или указатель на то, где клиент может получить дополнительные сведения (обычно, на другой сервер LDAP). Независимо от того, к какому серверу LDAP подключается клиент, он увидит одинаковое представление каталога; на записи, расположенные на одном сервере LDAP, будут указывать правильные ссылки при обращении к другому серверу LDAP, и наоборот. Это важная особенность глобальной службы каталогов. Перечень наиболее известных на сегодняшний день LDAP-серверов:
Область применения
В общем случае, службу каталогов можно использовать, когда Вам требуется надёжное хранение информации с возможностью централизованного управления и доступа к ней, с использованием стандартизированных методов.
Хранение конфигурации АТС
Стандарты
Протокол LDAP определён в следующих RFC:
Евгений Чайкин aka StraNNik
24 December 2008 г
Эта статья была написана для одного компьютерного журнала довольно давно. Поскольку с тех пор они так и не связались со мной по поводу её дальнейшей судьбы, делаю вывод о том, что она не пригодилась и выкладываю на суд общественности.
СЛУЖБЫ КАТАЛОГОВ. что это и для чего они нужны
В данном обзоре я кратко введу Вас в курс дела. Итак, что же такое службы каталогов?
Служба каталогов легко интегрируется с множеством сервисов, начиная от web-серверов, заканчивая CMS (content managment system). Загляните в документацию используемого Вами приложения, требующего авторизации и поищите там ключевое слово LDAP. Нашли? Так это оно и есть.
Но время шло. Сети росли и матерели. Становилось всё очевиднее, что нужны какие-то решения. То, что облегчит и без того нелёгкую жизнь системных и сетевых администраторов.
Одной из первых реализаций сервисов такого рода стала разработка комапании Sun Microsystems, первоначально названная Yellow Pages. Впоследствии, из за юридических трений, название было заменено на Network Information Service (NIS) под которым она до сих пор широко известна (в узких кругах).
Службой каталогов это назвать было сложно, но первые шаги в нужном направлении были сделаны.
Поскольку идея оказалась востребована, CCITT и ISO пошли дальше и разработали серию стандартов X.500, которые включали в себя следующие протоколы: DAP (Directory Access Protocol), DSP (Directory System Protocol), DISP (Directory Information Shadowing Protocol) и DOP (Directory Operational Bindings Management Protocol). Однако впоследствии выяснилось, что эти протоколы чрезмерно сложны и была проведена работа по разработке замены. Ей стал протокол LDAP (Lightweight Directory Access Protocol), послуживший основой для многих удачных решений.
NIS (хотя, строго говоря, это и не служба каталогов).
Итак, начнём с открытых и бесплатных. Их немного. Собственно, всего два.
Red Hat Directory Server и Fedora Directory Server
OpenLDAP
Novell eDirectory
Microsoft ActiveDirectory
Sun Java System Directory Server
IBM Tivoli Directory Server
Комментарии
Страницы комментариев: 1 :: 2 :: следующая
>>Elrock:
>>Вот возьмем к примеру Интернет. Огромные >>объемы информации,быстрые поиск и доступ и >>все без этих лдапов. Мне кажется и в >>корпоративе нужно переходить на проверенные >>десятилетиями интернет-технологии а не >>придумывать всякие велосипеды.
По моему ты не прав. Изучая LDAP, где-то я вычитал, что яндекс, гугл и другие поисковики пользуются единой базой (по-моему Yahoo), которая является каталогом LDAP.
2 Elrock, среда, 4 марта 2009 г. 11:52:55:
2 аноним, среда, 11 марта 2009 г. 23:22:16:
ну да. многие программы могут хранить свои настройки в LDAP.
Фуфло все это распиаренное.
Вот возьмем к примеру Интернет. Огромные объемы информации,быстрые поиск и доступ и все без этих лдапов. Мне кажется и в корпоративе нужно переходить на проверенные десятилетиями интернет-технологии а не придумывать всякие велосипеды.
Страницы комментариев: 1 :: 2 :: следующая
LDAP. Настройка отказоустойчивого LDAP сервера
В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).
Итак, сначала кратко о том, зачем же вообще использовать сервер службы каталогов (далее — LDAP-сервер). LDAP-сервера, в основном, применяются для централизованного хранения учетных записей, и всего, что с ними связано. LDAP-сервер представляет собой иерархическую БД, а значит в нем можно хранить любые данные.
Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)
Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:
Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).
Ключевые особенности этого LDAP-сервера:
После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.
Общая структура 389 Directory Server
389 DS состоит из нескольких компонентов.
Сначала я хотел написать теоретическую и практическую части отдельно, но потом стало ясно, что первая часть стала бы слишком скучной, а вторая слишком сухой. Поэтому сразу за куском теории будет идти практическое применение.
Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).
Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.
После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.
На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.
Установка первого сервера на ldap00
Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.
Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.
Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.
Вот некоторые из них:
Для начала запустим dsktune:
# dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.
NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).
NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.
WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.
WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.
Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.
tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.
echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time
Добавим в /etc/sysctl.conf:
для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:
запускаем еще раз dsktune и убедимся, что у нас все готово для установки.
Теперь запускаем скрипт setup-ds-admin.pl
Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.
1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.
2. Typical
Allows you to specify common defaults and options.
3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.
To accept the default shown in brackets, press the Enter key.
Choose a setup type [2]:
Выбираем третий пункт (мы же experienced server administrators =) )
Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.
If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.
Do you want to register this software with an existing
configuration directory server? [no]:
Тут нас спрашивают, хотим ли мы использовать существующий сервер каталогов для сохранения информации о сервере. Так как это наш первый сервер, отвечаем No.
Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).
Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.
Затем нас ждет вопрос о Directory Manager DN.
Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.
Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.
Настройка репликации на ldap00
Для подключения к серверу нужно поставить и запустить консоль управления 389-console.
В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.
Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.
Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local
У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.
Теперь немного теории о принципах репликации.
В репликации участвуют два типа серверов, supplier и consumer.
supplier — сервер, который копирует реплику на другой сервер.
Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.
consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.
Supplier сервер повторяет эти изменения на каждом consumer сервере.
Теперь, когда мы немного подкованы теоретически, можно настраивать мультимастер репликацию инстанса с конфигурацией.
Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.
Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.
Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.
Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.
Ответ должен быть
adding new entry «cn=replication manager,cn=config»
Итого, у нас получилось:
Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:
Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.
Установка и настройка ldap инстанса на ldap01
Теперь нужно настроить второй LDAP-сервер. С ним несколько иначе, т.к. установка admin server-а должна уже происходить в установленный LDAP-сервер и первичную настройку мы будем производить из консоли с помощью утилиты ldapmodify (что является нехилым плюсом, если стоит задача разобраться, как же работает этот сервер каталогов).
Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.
Ответы на вопросы скрипта аналогичны предыдущим.
После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.
Подключение производится примерно так:
dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb
changelogdir должен указывать на директорию с названием вашего инстанса.
2) добавляем пользователя replication manager:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:
20380119031407Z означает, что срок действия пароля не ограничен.
3) Создаем суффикс netscaperoot:
dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: «o=netscaperoot»
4) Создаем базу для суффикса netscaperoot:
dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot
Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.
5) Создаем корневой o=NetScapeRoot:
dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot
6) Разрешаем репликацию для o=netscaperoot:
dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3
Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).
На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.
Последним этапом будет:
7) Настройка репликации от ldap01 на ldap00:
dn: cn=Multimaster replication, cn=replica, cn=»o=netscaperoot», cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials:
nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE
nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль
8) Первичная инициилизация репликации с ldap00 на ldap01:
На первом сервере выполняем эту команду:
dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start
Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.
Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.
Установка admin server-а на ldap01
Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl
Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot
Дальнейшая настройка тривиальна, следуем указаниям скрипта.
Установка и настройка ldap инстансов для хранения пользовательских данных
Теперь подключаться через консоль управления можно к любому admin server-у.
На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.
Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).
Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.