Эта статья - кратчайшее введение в LDAP и службы каталогов. Для иллюстрации излагаемого материала я буду пользоваться инструментом Softerra LDAP Browser, который можно свободно скачать с сайта производителя .
Концепцию служб каталогов и требования к их реализации определяет серия стандартов X.500 ITU-T. Здесь каталог - это специализированная база данных, оптимизированная для поиска и извлечения информации, также поддерживающая добавление и изменение данных.
Среди реализаций служб каталогов наиболее известные - OpenLDAP и MS Active Directory. Клиентами каталогов являются адресные книги почтовых клиентов, сетевые службы, такие как DNS, SMTP, корпоративные приложения и информационные системы.
Как правило, служба каталогов
Для взаимодействия со службами каталогов 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 в вашей корпоративной сети, вы можете исследовать структуру и содержимое корпоративного каталога.)
Иерархическая организация данных в каталоге часто отражает географическую или организационную структуру. Записи на верхнем уровне могут представлять страны, на нижних - области стран и организации, еще ниже - отделы внутри организаций, людей, оборудование, ресурсы. А можно построить дерево по доменным именам Internet.
Текущая выбранная запись в каталоге Carnegie Mellon University (см. картинку выше) имеет уникальное имя DN o=CMRI,o=CMU,dc=cmu,dc=edu . Компоненты DN - имена узлов иерархической структуры от корневого до текущего (справа налево). Самый левый компонент DN называется относительным уникальным именем (Relative Distinguished Name, RDN). Таким образом, DN o=CMRI,o=CMU,dc=cmu,dc=edu состоит из RDN o=CMRI и DN родительской записи o=CMU,dc=cmu,dc=edu .
Можно рассматривать DN как абсолютный путь к файлу (по аналогии с файловой системой) или как первичный ключ записи в таблице (по аналогии с реляционной БД).
В рассматриваемом DN o=CMRI,o=CMU,dc=cmu,dc=edu два верхних уровня названы по доменным именам Internet. А уровнем ниже текущей записи располагаются записи, идентифицируемые значением атрибута ou (см. картинку выше). Здесь имена атрибутов, идентифицирующие записи разных уровней, имеют следующие значения:
Dc аббревиатура от domain component o аббревиатура от organization ou аббревиатура от organizational unit
Эти имена, как и десятки других, - имена стандартных атрибутов, специфицированных в RFC 2256 и предназначенных для использования в объектных классах, описывающих людей, организации, их подразделения и т.п. Все реализациии LDAP поддерживают эти стандартные типы атрибутов. Вот еще несколько примеров: telephoneNumber , name , givenName , postalAddress , sn (аббревиатура от surname).
В рассматриваемой записи с DN o=CMRI,o=CMU,dc=cmu,dc=edu имеются три атрибута, objectClass , o и businessCategory , по каждому из которых можно искать эту запись в каталоге.
Для поиска записей в LDAP-каталоге задаются три компонента:
Base DN (базовое уникальное имя) показывает, откуда в иерархии начать поиск scope (область поиска) показывает область поиска, одно из:
Например, поиск по условию
BaseDN: o=CMU,dc=cmu,dc=edu scope: поддерево filter: objectClass=organizationalUnit & ou=*Student*
вернет все записи из поддерева с корнем o=CMU,dc=cmu,dc=edu , удовлетворяющие фильтру (синтаксис фильтра в этом примере легко читаемый, но неправильный, см. далее).
На заметку: cуществуют специальные базовые DN для запроса информации о возможностях сервера, для доступа к схеме (schema) и данным мониторинга.
В Softerra LDAP Browser по Ctrl+F3 вызывается окно поиска, в котором удобно экспериментировать с параметрами поиска LDAP:
В фильтре можно использовать следующие проверки для атрибутов (атрибут ou взят для примера):
Присутствие атрибута (ou=*) Равенство значения (ou=School) Наличие подстроки (ou=S*) Больше или равно (ou>=School) Меньше или равно (ou
Заметьте, что отсутствуют проверки > и < . Проверка на приближенное равенство ~= использует фонетические сравнение. Расширенная проверка для сравнения образца со значением атрибута использует реализованное LDAP-сервером правило, идентификатор которого указан после двоеточия. Примеры выражений для проверки наличия подстроки (звездочка означает 0 или более символов):
В начале Sch* в середине *oo* в конце *ol в начале и в конце Sc*ol
Проверки в фильтре можно комбинировать при помощи логических операторов:
AND (&(sn=Иванов)(phone=*)(GivenName=И*)) OR (|(cn=Багира)(cn=Балу)) NOT (!(cn=Пикачу))
Внимание! Последний фильтр с NOT вернет также записи, не содержащие атрибута cn .
Формируя запрос, можно указать типы атрибутов, которые должны быть включены сервером каталога в ответ. Если список типов атрибутов пуст, то окно поиска LDAP Browser отображает идентифицирующие атрибуты найденных записей (это RDN) и DN родительских записей - вместе они образуют DN найденных записей. Поиск LDAP всегда возвращает DN найденных записей, помимо и независимо от списка атрибутов. Зададим явно список атрибутов, которые мы хотим видеть и повторим запрос (несуществующие типы атрибутов в списке игнорируются сервером и не приводят к ошибке):
Чтобы хорошо освоить синтаксис фильтра, попробуйте разные проверки и их логические комбинации.
Как уже упоминалось, служба каталогов позволяет не только извлекать, но также добавлять и модифицировать записи. Softerra LDAP Browser поддерживает только просмотр данных в каталоге, поэтому для внесения изменений в каталог необходим другой инструмент (например, платный Softerra LDAP Administrator).
Для работы с LDAP практически из любого языка программирования можно воспользоваться существующими библиотекми для этого языка. В будущих статьях, посвященных LDAP, я рассмотрю работу с MS Active Directory в Oracle PL/SQL и в языке программирования Python.
Страница Аутентификация LDAP служит для настройки сервера LDAP с целью аутентификации пользователей устройств (многофункциональное периферийное устройство, цифровой копир или устройство цифровой отправки). Если аутентификация LDAP выбрана в качестве Способа регистрации для одного или нескольких Функций устройств на странице Диспетчер аутентификации , пользователь должен ввести действительные имя пользователя и пароль для получения доступа к этим функциям.
Процедура аутентификации состоит из двух взаимозависимых этапов. На первом этапе устройство проверяет имя пользователя и пароль на сервере LDAP. После ввода правильного имени пользователя и пароля и их проверки устройство ищет адрес электронной почты пользователя и его имя. При возникновении ошибки хотя бы на одном этапе блокируется доступ пользователя к функциям, требующим аутентификации LDAP.
На странице Аутентификация LDAP можно задать параметры доступа к серверу LDAP и поиска информации пользователя. Обратите внимание, что данную страницу можно использовать только в том случае, если LDAP выбран в качестве Способа регистрации на странице Диспетчер аутентификации .
Параметр Способ привязки сервера LDAP определяет, как устройство будет осуществлять подключение к серверу LDAP. Обратитесь к администратору сервера LDAP, чтобы определить наиболее оптимальный для вас способ.
Параметр Сервер LDAP представляет собой имя хоста или IP-адрес сервера LDAP, которое будет использоваться для аутентификации пользователей устройства. В случае использования SSL введенное здесь имя или адрес должны соответствовать имени в сертификате, направляемом сервером.
В этом поле можно указать несколько серверов, разделяя их адреса знаком вертикальной полосы ("|", ASCII 0x7c). Эту функцию можно, например, использовать для указания основного и резервного серверов. Сетевой интерфейс поддерживает поддерживает только один сертификат CA, поэтому все серверы LDAP в этом списке должны использовать один сертификат CA.
Параметр Порт определяет номер порта TCP/IP, на котором сервер обрабатывает запросы LDAP. Обычно это порт 389 для Простой привязки или 636 для привязок Простой через SSL .
Первый способ называется ; он предполагает “конструирование” DN (отличительного имени) пользователя для аутентификации (“привязки”) в каталоге LDAP. В начало информации, вводимой пользователем на панели управления, добавляется Префикс DN , и данная строка добавляется к строке Привязка и начало поиска . Например префикс DN “CN” в сочетании с введенной пользователем строкой [email protected] и строкой привязки и начала поиска OU=Engineering,DC=NASA,DC=GOV определит DN пользователя: [email protected],OU=Engineering,DC=NASA,DC=GOV
Второй способ называется Использование имени пользователя и пароля администратора и позволяет искать DN пользователя вместо его "реконструкции". В данном способе для первоначальной привязки используются регистрационные данные администратора (DN и пароль), и начинается поиск DN пользователя, проходящего аутентификацию. При обнаружении DN этого пользователя устройство предпримет попытку выполнить аутентификацию с помощью полученного значения DN и пароля, введенного пользователем на панели управления устройства. Если аутентификация выполнена успешно, считывается адрес электронной почты пользователя и он получает доступ к функциям устройства.
Способ Имя и пароль пользователя устройства следует использовать, когда все пользователи находятся в одном контейнере каталога LDAP, а первым следует слагаемое DN, которое пользователь обычно использует для аутентификации. Обратите внимание, что допускается ввод нескольких строк привязки и начала поиска при условии разделения их знаком “|”, и устройство предпримет попытки поочередно аутентифицировать пользователя по каждому из значений привязки и начала поиска. Данный способ может быть применен, если пользователи находятся в нескольких контейнерах каталога LDAP.
Способ следует применять в том случае, если пользователи находятся в нескольких контейнерах, либо если первое слагаемое DN обычно неизвестно некоторым пользователям или не используется для аутентификации в других системах. При использовании этого способа пользователю может быть предложено ввести уникальный атрибут LDAP, такой как SAMAccountName или даже номер телефона пользователя - атрибут TelephoneNumber.
Параметр Префикс привязки - это атрибут LDAP, используемый для построения DN пользователя для целей аутентификации. Этот префикс комбинируется с именем пользователя, введенным на панели управления, образуя относительное отличительное имя (RDN). Обычно используется префикс "CN" (для общего имени) или "UID" (для идентификатора пользователя).
DN администратора
Это DN (отличительное имя) пользователя, имеющего права чтения каталога LDAP. Введенная здесь учетная запись может не иметь административного доступа к каталогу. Прав чтения достаточно.
Пароль администратора
Пароль пользователя, чей DN введен в поле "DN администратора".
При выборе способа Имя и пароль пользователя устройства значение Привязка и начало поиска используется на обоих этапах аутентификации. На этапе проверки имени пользователя и пароля это значение комбинируется с RDN для воссоздания полного отличительного имени пользователя (DN). На этапе поиска информации пользователя это значение является DN записи LDAP, с которой начинается поиск.
При выборе способа Использование имени пользователя и пароля администратора строка Привязка и начало поиска используется только как начало поиска. Начало поиска в базе каталога LDAP может быть задано, и устройство выполнит поиск по всему дереву LDAP объекта пользователя, соответствующего введенному имени пользователя.
Строка состоит из пар "атрибут=значение", разделенных запятыми. Например:
ou=engineering,o=Hewlett Packard,c=US
ou=marketing,o=Hewlett Packard,c=US
ou=engineering,cn=users,dc=hp,dc=com
При выборе способа "Имя и пароль пользователя устройства" в это поле можно ввести несколько несколько строк привязки, разделенных знаком вертикальной черты ("|", ASCII 0x7c). Это можно использовать, например, для указания альтернативных доменов LDAP. Устройство предпримет попытку привязать сервер LDAP, используя поочередно все строки в заданном порядке. После успешного выполнения привязки тот же корневой объект используется для поиска информации пользователя устройства.
При выполнении поиска информации пользователя в базе данных LDAP значение атрибута, указанного в этом поле, сравнивается с именем пользователя, введенного при аутентификации. Обычно этот атрибут такой же, как Префикс привязки .
После того, как пользователь устройства найден в базе данных LDAP, его электронный адрес находят в базе данных с помощью атрибута LDAP, указанного в поле адрес электронной почты, используя атрибут .
и имя, используя атрибут
Экранное имя пользователя получают из атрибута LDAP, указанного в поле имя, используя атрибут .
Функция Тестирование используется для проверки правильности параметров перед их применением. При нажатии этой кнопки вам будет предложено ввести имя пользователя и пароль, как если бы вы регистрировались на панели управления устройства. Если введенные регистрационные данные прошли аутентификацию и информация пользователя найдена в базе данных LDAP, появляется сообщение об успешном выполнении проверки. В противном случае появится сообщение об ошибке с указанием на отрицательный результат аутентификации.
Для некоторых специалистов первая встреча с LDAP состоялась при переходе с доменов Windows NT на домены Active Directory или при работе с Novell NDS/eDirectory. В других случаях поддержка LDAP была вторичной по отношению к основной функциональности. Так, у многих знакомство с LDAP произошло при настройке почтовых серверов Exchange 5.5 или Netscape Messaging, создании сайтов Web с требованиями аутентификации, в процессе работы с Web Proxy и т. д. В результате каталоги LDAP стали восприниматься как сугубо утилитарный инструмент для решения той или иной конкретной задачи. Цель настоящей статьи - дать читателям более широкое представление о возможностях применения этой технологии и о внутренней структуре каталогов LDAP.
Каталогом LDAP называют любое хранилище данных с поддержкой протокола LDAP. Наиболее распространенные на сегодняшний день каталоги - Microsoft Active Directory, Sun ONE Directory Server (и более ранние версии того же продукта под марками Netscape и iPlanet) и Novell eDirectory (ранее известный как Novell NDS).
В более общем значении под каталогом (directory) обычно подразумевают хранилище относительно статичных данных, т. е. тех, которые считываются во много раз чаще, нежели изменяются. Основные типы данных, хранящиеся в каталогах LDAP, как раз удовлетворяют условию относительной статичности. К их числу принадлежат:
Заметим, что в компьютерном мире уже существует одна масштабная система, являющаяся, по сути, каталогом - это система серверов DNS. Имеющаяся специализированная технология DNS отлично себя зарекомендовала и не требует улучшений (хотя Microsoft и приняла решение реализовать DNS в Windows 2000 Server на основе Active Directory, т. е. по сути на основе технологии LDAP).
По способу применения большинство каталогов LDAP можно разделить на несколько основных групп.
Каталоги сетевой операционной системы (Network Operating System, NOS) . В настоящий момент наиболее часто встречающийся пример такого использования - построение корпоративной сети под управлением Windows на основе Microsoft Active Directory или Novell eDirectory.
Каталоги NOS содержат информацию обо всех объектах в сети: данные о пользователях, группах пользователей, рабочих станциях, серверах, принтерах и т. д. Внедрение такого каталога обеспечивает централизованное администрирование сети и управление аутентификацией и авторизацией при обращении к сетевым ресурсам. Это позволяет отказаться от дублирования учетной информации в разных точках ее использования. (Надо отметить, что функциональность Active Directory и eDirectory неравнозначна - естественным образом Active Directory лучше интегрирована с ОС Windows NT и 2000. Оба решения имеют как сильные, так и слабые стороны, а потому перед принятием решения необходимо тщательно взвесить целый набор факторов.)
Похожим способом может быть устроена аутентификация пользователей в сетях под управлением различных вариантов UNIX; в данном случае используются модуль PAM и любой каталог LDAP.
Каталоги для хранения данных о пользователях приложений. Многие производители корпоративного программного обеспечения решили не изобретать велосипед и не создавать собственную систему хранения данных. Вместо этого пользовательские пароли, права доступа и профили помещаются в каталоги LDAP.
Характерным примером подобного подхода является линейка продуктов Sun ONE, включающая в себя, помимо прочего, сервер электронной почты, Web Proxy, календарный сервер, сервер Web. Эти продукты изначально рассчитаны на работу с Sun ONE Directory Server, причем все приложения могут хранить данные о пользователях в одном и том же сервере каталогов. Аналогично, почтовый сервер Exchange 2000 опирается на Active Directory как на хранилище данных о своих пользователях.
LDAP поддерживается большим количеством приложений, выпускаемых более мелкими производителями. В особенности это касается продуктов, имеющих отношение к технологиям Web, - серверам Web, серверам порталов и серверам приложений.
Каталоги в качестве адресных книг организаций. В каталоге может располагаться справочная информация о сотрудниках - адрес электронной почты, номер телефона, комнаты, название должности и т. п. В качестве пользовательского интерфейса применяется обычно почтовый клиент наподобие Microsoft Outlook или Netscape Messenger (только для поиска и чтения) или специально создаваемый клиент, как правило, доступный через Web. Адресная книга служит для поиска и просмотра информации, автоматического заполнения адресов электронной почты и хранения сертификатов PKI, необходимых для организации электронного обмена конфиденциальной информацией.
Каталоги внешних пользователей. При построении приложений Web, с которыми работают бизнес-партнеры или клиенты организации, требуется создать механизм аутентификации; для этого традиционно также используются каталоги LDAP.
Важно отметить, что с точки зрения управления информационной средой количество сформированных на предприятии каталогов (и в целом - число хранилищ данных о пользователях) желательно свести к минимуму. Поэтому всегда нелишне рассмотреть возможности по применению одного каталога для различных предназначений. Например, каталог NOS может взять на себя роль адресной книги, а каталог какого-либо конкретного приложения можно предоставить в распоряжение других приложений. Подобный подход (консолидация данных о пользователях) в явном виде предлагается крупнейшими производителями каталогов и использующего их ПО - в первую очередь, речь идет о Microsoft и Sun.
Таким образом, один и тот же каталог LDAP способен выполнять целый ряд задач.
Упрощенный протокол доступа к каталогам (Lightweight Directory Access Protocol, LDAP) представляет собой протокол прикладного уровня; он поддерживает обмен информацией между клиентом и сервером и работает поверх протокола TCP/IP (по умолчанию LDAP использует TCP-порт 389). Идея создания LDAP возникла в ходе экспериментов с ранними реализациями стандарта X.500 в конце 1980-х - начале 1990-х гг. (эти реализации оказались очень сложны и чересчур требовательны к вычислительным ресурсам с клиентской стороны, что привело к необходимости разработки другого клиентского протокола). Технические спецификации нового протокола (RFC 1487 для LDAP версии 2 и RFC 1777 для повсеместно распространенного ныне LDAP версии 3) увидели свет в 1993 и 1995 гг., соответственно.
Первоначально LDAP использовался в качестве дополнения к основному клиентскому протоколу X.500 - протоколу DAP. Таким образом, информационная модель каталогов LDAP полностью унаследована от X.500. В современных каталогах протоколы X.500 либо не поддерживаются вовсе, либо существуют наравне с LDAP, но информационная модель X.500 все равно реализуется - клиент LDAP просто «не знает», от кого он получает информацию - от шлюза между LDAP и DAP или от независимого сервера LDAP.
Протокол LDAP с самого начала ориентировался на максимальную простоту: например, в нем отсутствует поддержка сложных транзакций. Стандарт определяет девять операций:
Названия этих операций в основном говорят сами за себя и пояснения не требуют. Обратим только внимание на отсутствие операции read - ее функции выполняет search. (Далее мы поясним по механизму работы операции search.)
Спецификации протокола не указывают, в каком именно формате должны храниться сами данные, и производители решают эту задачу по-разному. В большинстве серверов каталогов хранилища сконструированы специальным образом с учетом относительной статичности данных каталога. Каталоги, совмещающие поддержку X.500 и LDAP, используют формат хранения, предписываемый X.500. В каталогах Oracle Internet Directory и IBM SecureWay данные хранятся в реляционных СУБД соответствующих производителей (Oracle и DB2). Наконец, в качестве каталогов LDAP могут выступать и системы, для которых эта функциональность вторична, - например, почтовый сервер Exchange или среда Lotus Domino, где данные представлены в «родных» форматах.
Заметим, что при построении системы каталогов LDAP на базе продуктов, в основе которых лежит СУБД, заметная часть функционала этого хранилища останется неиспользованной и может отрицательно влиять на производительность системы. Поэтому достаточно логично, что наибольшее распространение получили каталоги, базирующиеся не на СУБД, а на специализированных хранилищах.
Наконец, продукты, наподобие MaXware Virtual Directory (MVD), представляют собой «виртуальные каталоги». MVD работает в качестве шлюза между любым форматом хранения данных (стандартным или нестандартным - к нему прилагается собственная библиотека API для обработки нестандартных форматов) и LDAP. При помощи MVD практически любое хранилище может быть представлено как каталог LDAP.
Данные в каталогах LDAP представлены как объекты; информация о каждом объекте хранится в наборе атрибутов (точнее, в виде пар «название атрибута - значение атрибута»). Важным отличием от СУБД является возможность присваивать одному объекту несколько атритубов с общим названием: например, объект, описывающий пользователя, может содержать несколько телефонных номеров или адресов электронной почты.
Набор возможных атрибутов задается для каждого каталога заранее. Стандартный набор при необходимости может быть изменен или расширен. Вместе с названием атрибута фиксируется его синтаксис (строка, число, дата и проч.), а потому, в отличие от мира СУБД, название атрибута почти всегда неизменно от каталога к каталогу. Так, атрибут c (country) повсюду означает название страны, l (locality) - населенного пункта, ou (organizational unit) - подразделения организации, cn (common name) - комбинацию имени и фамилии и т. д. В каталогах Active Directory широко применяется атрибут dc (domain component) , обозначающий название сегмента корпоративной сети.
Каждый объект каталога принадлежит к одному или нескольким объектным классам. Объектный класс описывает тип объекта и определяет:
Объектные классы формируют собственную древовидную иерархию; объект, принадлежащий какому-либо объектному классу, автоматически принадлежит всем его надклассам (все классы являются подклассами универсального класса top ) - на этот объект накладываются все заданные для подклассов ограничения, равно как и ограничения его собственного класса.
К примеру, объект, относящийся к классу person , обязан иметь непустые атрибуты cn и sn (фамилия, surname) и может иметь атрибуты telephonenumber, description и некоторые другие. Объект, принадлежащий подклассу organizationalPerson (подкласс person), должен удовлетворять тем же требованиям и может вдобавок содержать иные атрибуты, среди которых title (должность) и ou .
Наиболее распространенным объектным классом для хранения информации о пользователях является на сегодняшний момент inetOrgPerson (здесь inet используется как сокращение от Internet). Это подкласс класса organizationalPerson , он описан в RFC 2798 (в отличие от классов person и organizationalPerson , которые включены в стандарт X.521). Причина в том, что стандарты X.500 формулировались в 1980-х гг. еще до повсеместного распространения Internet, и в описанных там классах отсутствует, например, стандартное поле для адреса электронной почты.
Объектные классы каталога делятся на основные и дополнительные (auxiliary). Каждый объект обязан принадлежать хотя бы к одному основному классу и может принадлежать к дополнительному классу(-ам). Как правило, атрибуты последнего относятся к конкретному приложению. Например, в случае причисления объекта класса inetOrgPerson к дополнительному классу nsmessagingserveruser он объявляется пользователем почтового сервера Sun ONE Messaging; данный класс позволяет добавить к объекту атрибут nsmsgdisallowaccess , необходимый для работы этого сервера. Таким образом, механизм дополнительных классов позволяет задействовать уже имеющийся каталог в качестве хранилища данных о пользователях нового приложения.
Набор типов атрибутов и объектных классов, определенных для данного каталога, называется его схемой (schema). Схема всех основных каталогов LDAP настраивается администратором, хотя в настоящий момент стандартный способ ее настройки отсутствует, что приводит к определенной степени несовместимости: приложение, которому понадобится каталог LDAP для хранения данных о пользователях, должно поставляться с процедурами адаптации схемы каталога отдельно для каждого (широко используемого) сервера каталогов.
Объекты каталога организуются в иерархическую логическую структуру - дерево. Его корнем служит пустой корневой объект root ; объекты следующего уровня называются суффиксами.
У каждого объекта выделяется один именующий атрибут (Relative Distinguished Name, RDN). Полным идентификатором объекта (Distinguished Name, DN) является строка, полученная конкатенацией всех RDN при перемещении по дереву от данного объекта к корневому (см. пример далее). Заметим, что RDN не обязан быть уникальным в масштабах всего каталога: для обеспечения уникальности DN достаточно, чтобы RDN был уникален среди близлежащих объектов (тех, что расположены непосредственно под объектом, находящимся на один уровень выше).
Иерархия накладывает определенные ограничения на возможности удаления объектов каталога: объект, ниже которого остаются другие объекты, не может быть удален.
Формат обмена данными LDAP (LDAP Data Interchange Format, LDIF) - это стандартный способ представления данных каталога в виде текстовых файлов. Благодаря LDIF информация может быть считана из каталога, отредактирована при помощи обыкновенного текстового редактора и экспортирована в тот же или в другой каталог. Файл LDIF может содержать данные о любом количестве объектов каталога.
В качестве примера посмотрим LDIF одного объекта Sun ONE Directory Server:
| dn: uid=vshabat,ou=ICT,o=NIICHAVO Cn;lang-ru:: 0JLQsNGB0LjQu9C40Lkg0Kj Nsmsgdisallowaccess: pop http Preferredlanguage: ru Mailhost: mail.niichavo.ru Maildeliveryoption: mailbox Givenname;lang-ru:: 0JLQsNGB0LjQu9C Mail: [email protected] Objectclass: top Objectclass: person Objectclass: organizationalPerson Objectclass: inetorgperson Objectclass: mailrecipient Objectclass: nsmessagingserveruser Cn: Vasily Shabat Sn;lang-ru:: 0KjQsNCx0LDRgg== Givenname: Vasily Ou: Administrators |
Из примера видно, что:
При простой аутентификации клиент должен либо объявить себя анонимным, либо представить DN пользователя и пароль в ходе операции подключения (bind ). Содержащиеся в каталоге данные о контроле доступа позволяют установить, дано ли ему право на выполнение запрошенной операции.
Операция bind зачастую используется и другими приложениями, когда в работе с данными каталога нет непосредственной необходимости. Например, приложение может запросить имя пользователя и пароль, сформировать из них запрос к каталогу на операцию bind и проверить ее выполнение. Если операция проходит без ошибок, то аутентификация считается успешной. Заметим только, что в большинстве случаев, когда аутентификация проводится конечными пользователями, детали работы с DN не видны: приложение запрашивает имя пользователя и пароль, затем (соединившись с каталогом в соответствии с собственными правами) находит DN объекта с конкретным именем пользователя и только потом пытается выполнить команду bind .
Аутентификация может производиться и более сложными (но и более безопасными) способами, например при помощи ключей PKI.
Методы представления информации о контроле доступа (Access Control Information, ACI) до сих пор не стандартизованы и реализуются в различных серверах LDAP по-разному.
Для выполнения операции поиска (search ) в каталоге LDAP клиенту нужны следующие параметры:
Фильтр поиска может состоять из требования к объектному классу. Например, фильтру «objectclass=inetOrgPerson » соответствуют все объекты этого класса в области поиска.
Заметим, что в большинстве серверов предусмотрена зависимость контроля доступа от типа поисковой операции. Например, администратор может задать условие, чтобы объект был виден определенному пользователю исключительно при поиске base , т. е. когда пользователь ищет этот конкретный объект.
В примере, приведенном на Рисунке 1, фильтр поиска составлен как логическая связка AND условий на должность пользователя и его имя.
К каталогам, как к часто используемым системам, предъявляются высокие требования в отношении доступности их сервиса. Это означает, что данные каталога необходимо размещать на нескольких связанных между собой серверах, что позволит реализовать:
Для реализации подобных систем нужен механизм разностного тиражирования данных между отдельными серверами каталогов (по сети передаются только изменения в содержании каталога). Такие механизмы предусмотрены во всех распространенных серверах каталогов, но они все еще не стандартизованы, а значит, организовать тиражирование между серверами различных производителей без привлечения сторонних средств невозможно.
Тиражирование бывает двух видов - с одним или несколькими главными серверами. Первый способ предусматривает, что каждый объект каталога может быть изменен на одном из серверов; его копии на других серверах доступны только для чтения. Второй снимает это ограничение. Полноценная отказоустойчивая система, т. е. система, которая продолжает обрабатывать запросы на редактирование данных после отказа одного из серверов, возможна только во втором случае. Тиражирование с несколькими главными серверами реализовано в каталогах Active Directory, eDirectory и Sun ONE Directory (в последнем случае главных серверов может быть не более двух). Заметим, что подобная схема потенциально опасна: при отсутствии механизма контроля за транзакциями изменения, внесенные на главных серверах, могут конфликтовать друг с другом. Соответствующий механизм решает, какие изменения в итоге осуществятся, а какие - нет (и, как следствие, будут потеряны).
Для реализации отказоустойчивых систем и систем высокой доступности требуются дополнительные средства по распределению нагрузки. Таким инструментом может стать proxy-сервер LDAP, DNS Round Robin или аппаратное решение, наподобие Cisco Local Director.
Несколько серверов можно увязать в единую систему и другими способами. При использовании переадресации (referral) сервер LDAP сообщает, что для обработки запроса клиент должен обратиться к другому серверу LDAP. Переадресация требует, чтобы все принимающие в этом участие клиенты LDAP правильно интерпретировали referral - к сожалению, большинство имеющихся на рынке клиентов этого не делают.
С другой стороны, передача эстафетных запросов (chaining ) от клиента LDAP не предполагает никакой дополнительной функциональности: серверы LDAP разделяют дерево каталога между собой и сами пересылают запрос от сервера к серверу. Клиент LDAP в этом случае даже «не знает», что применялся эстафетный запрос. Эстафетные запросы реализованы в серверах каталогов, поддерживающих X.500, - Siemens DirX, Critical Path Directory Server, Nexor. Соответствующий протокол, DSP, является частью стандарта X.500.
Каждый сервер каталога поставляется с интерфейсом, при помощи которого производится как конфигурация и управление сервером, так и администрирование данных каталога. Однако полностью вопрос администрирования данных этими средствами не решается.
Начнем с того, что некоторые из интерфейсов для работы с данными каталога просто неудобны при регулярном обращении к ним; например, структура конкретного дерева каталога может быть такова, что для редактирования одного атрибута одного пользователя нужно около десяти раз щелкнуть мышью. В подобных интерфейсах не предусмотрена возможность автоматизации или упрощения часто исполняемых задач.
С другой стороны, на рынке отсутствуют продукты, применение которых дало бы возможность полностью отказаться от средств администрирования любого из каталогов LDAP. Проблема в том, что такое средство должно позволять не только редактировать данные, но и управлять правами доступа и изменениями в схеме каталога, а подобные функции реализуются в разных серверах по-разному. Тем не менее в последнее время большую популярность приобрели такие инструменты, как Softerra LDAP Administrator и бесплатное средство для управления данными каталога LDAP Browser. Функционирование и того и другого ограничивается управлением данными каталога.
Вообще говоря, управление данными каталога совершенно не обязательно должно осуществляться системными администраторами. Разумным с точки зрения распределения обязанностей является делегирование прав администрирования - набор механизмов и соглашений, при котором за ввод данных каталога отвечают пользователи вне отдела ИТ. Например, общее управление информацией о персонале поручается отделу кадров, а некоторые атрибуты, например телефонный номер, могут редактировать сами сотрудники.
Наконец, различные хранилища пользовательских данных можно объединить в единую систему каталогов - при этом за синхронизацию между хранилищами отвечают метакаталоги. Так, при помощи метакаталога используемый в корпоративной сети каталог Active Directory можно объединить с Sun ONE Directory Server, используемым приложениями Sun ONE, к примеру Messaging Server, а также с корпоративной системой учета кадров. В результате управление содержимым каталога осуществляется автоматически на основе данных других систем.
Василий Шабат - менеджер отдела развития решений компании «Открытые технологии». С ним можно связаться по адресу:
|LDAP, или Lightweight Directory Access Protocol – это протокол для управления информацией из централизованного места за счет использования иерархии файлов и каталогов. Его работа чем-то похожа на реляционные базы данных.
LDAP позволяет систематизировать и хранить любого рода информацию. Этот протокол часто используется для централизованной аутентификации.
Данное руководство покажет, как установить и настроить сервер OpenLDAP на выделенный сервер Ubuntu 12.04, а также создать все необходимые группы и пользователей.
Примечание : О настройке LDAP для авторизации можно прочесть в этой серии.
Сервер OpenLDAP можно загрузить из стандартных репозиториев Ubuntu. Искомый пакет называется slapd. Кроме того, нужно установить несколько дополнительных утилит.
sudo apt-get update
sudo apt-get install slapd ldap-utils
Система предложит выбрать и подтвердить пароль администратора LDAP.
Когда установка будет завершена, нужно перенастроить пакет LDAP. Чтобы открыть инструмент для конфигурации пакета, введите:
sudo dpkg-reconfigure slapd
Система задаст ряд вопросов, чтобы перенастроить пакет.
Для управления LDAP понадобится веб-интерфейс PHPldapadmin. Его тоже можно скачать из репозиториев Ubuntu.
sudo apt-get install phpldapadmin
Эта команда установит необходимый пакет и его PHP-зависимости.
Прежде чем запустить интерфейс, нужно изменить некоторые настройки в конфигурационных файлах.
Откройте конфигурации с правами root:
sudo nano /etc/phpldapadmin/config.php
Найдите следующий раздел и отредактируйте его, как показано ниже:
$servers->setValue("server","host","domain_nam_or_IP_address");
Примечание : Значения, выделенные красным, нужно заменить своими данными.
Следующий раздел должен содержать доменное имя (или IP), указанное при перенастройке slapd. Домен нужно преобразовать в формат, который понимает LDAP; для этого нужно разделить все компоненты домена.
Примечание : Компоненты домена – это те его части, что разделены точками.
К примеру, доменное имя imaginary.lalala.com LDAP видит как dc=imaginary,dc=lalala,dc=com. Отредактируйте следующую запись, указав свой домен в правильном формате; условное доменное имя test.com указывается так:
$servers->setValue("server","base",array("dc=test,dc=com"));
Следующее значение, которое нужно изменить, также должно использовать компоненты домена, которые были добавлены в последней записи. Внесите их после cn=admin:
$servers->setValue("login","bind_id","cn=admin,dc=test,dc=com");
Найдите следующий раздел, а в нём – атрибут hide_template_warning. Раскомментируйте строку и установите значение true, чтобы отключить некоторые несущественные предупреждения.
$config->custom->appearance["hide_template_warning"] = true;
Сохраните и закройте файл.
Откройте в браузере свой домен или IP, добавив сегмент /phpldapadmin.
domain_name_or_IP_address/phpldapadmin
На экране появится приветственная страница интерфейса.
На экране появится форма входа. Если все настройки были выполнены верно, Login DN (имя) будет уже указано (в данном случае это cn=admin,dc=test,dc=com).
Введите пароль, установленный во время настройки slapd.
На экране появится интерфейс с довольно небольшим списком опций.
Нажмите плюсик рядом с доменным именем слева (в данном случае dc=test,dc=com), чтобы развернуть список и увидеть используемую учётную запись.
Сервер LDAP очень гибок. Он позволяет создавать иерархии и отношения разными способами в зависимости от информации и требований пользователя.
Создайте базовую структуру и заполните её информацией.
В левой панели нажмите Create new entry here.
Это меню содержит множество различных типов записей.
Чтобы создать простое подразделение, выберите шаблон «Generic: Organizational Unit».
Программа предложит выбрать имя подразделения. Введите groups. Затем нужно зафиксировать изменения.
После этого слева появится новая запись.
Создайте ещё одно подразделение. Повторите описанную выше процедуру, указав имя users.
Теперь в выпадающем списке слева появятся добавленные только что подразделения (чтобы просмотреть список, нажмите плюс рядом с dc=test,dc=com).
Группы позволяют управлять доступом и привилегиями пользователей.
Для примера создадим группы admin, irc и user. После этого нужно настроить аутентификацию пользователей различных групп.
Создайте группы в подразделении groups. Для этого кликните по groups и выберите опцию Create a child entry.
После этого выберите шаблон «Generic: Posix Group». В соответствующем поле укажите имя admin, а затем нажмите Create Object.
Повторите этот процесс, чтобы создать группы irc и user. Будьте внимательны: проверяйте текущую категорию (это должна быть ou=groups), иначе можно создать группу в других категориях.
Чтобы просмотреть созданные группы, откройте в левом меню ou=groups и выберите View 3 children.
Теперь нужно создать пользователей и добавить их в группы. Выберите категорию ou=users и нажмите Create a child entry. Выберите шаблон «Generic: User Account». На экране появится довольно большая форма. Заполните её соответствующими данными.
Обратите внимание: Значение Common Name должно быть уникальным для каждой записи в категории. Потому вместо автоматически вносимых в это поле значений рекомендуется указывать имя пользователя.
Нажмите Create Object.
Чтобы создать дополнительных пользователей, можно воспользоваться функцией копирования записей.
Кликните по только что созданному пользователю в левой панели и выберите опцию Copy or move this entry.
Отредактируйте cn=user, указав уникальное значение для common name, а затем нажмите Copy.
На экране появится уже заполненная форма для создания пользователя. При необходимости отредактируйте внесённую информацию. Обязательно измените uidNumber. Нажмите Create Object.
Чтобы добавить пользователя в группу, кликните по требуемой группе и выберите Add new attribute.
В выпадающем меню выберите memberUid. В текстовом поле укажите пользователя, которого нужно добавить, и нажмите Update Object.
Чтобы добавить в группу других пользователей, выберите modify group members и выберите из списка доступных пользователей.
Теперь сервер LDAP установлен и готов к работе. Также на нём есть несколько пользователей и групп.
Чтобы узнать, как настроить аутентификация клиентов при помощи LDAP, читайте следующее руководство.
Tags: ,Dn: DC=localhost
Вы можете настроить параметры соединения с LDAP в утилите TrackStudio Server Manager, либо, если ее нет — в любом текстовом редакторе.
Если у вас отсутствует возможность запустить Server Manager, вы можете настроить интеграцию с LDAP в файле trackstudio.security.properties
Для того, чтобы пользователи, зарегистрированные в LDAP, имели доступ к TrackStudio, для них должны быть созданы учетные записи. Эти учетные записи должны совпадать с записями в LDAP по названию аккаунта, либо по имени пользователя.
Если установлено trackstudio.useLDAP yes
, TrackStudio будет соединяться с указанным LDAP-сервером при попытке входа пользователя и выполнять авторизацию средствами LDAP, используя учетную запись, указанную в ldap.userDN
и ldap.userDNpass
. TrackStudio затем выполнит локальный поиск в своей базе данных пользователя, соответствущего указанному логину. После этого TrackStudio будет искать в сервере LDAP пользователя, запись ldap.loginAttrLDAP
которого соответствует имени
или логину
(в зависимости от ldap.loginAttrTS
) найденного пользователя. Затем этот пользователь будет авторизован паролем, указанным в окне входа в систему.
TrackStudio поддерживает работу с фильтрами LDAP. Вы можете вписывать свои фильтры в "Поле поиска в LDAP". Таким образом TrackStudio будет работать только с теми пользователями, которые удовлетворяют условиям указанного фильтра. Подробнее о фильтрах вы можете прочитать в этой статье .
