Служба каталогов (Directory Service) – это программный комплекс, позволяющий хранить в одном месте информацию о сетевых ресурсах (общие каталоги, серверы печати, принтеры, пользователи и т.д.) и обеспечивающий централизованное управление ими

Серверы, клиенты, протоколы и стандарты

Можно ли заменить службу каталогов от Microsoft открытыми продуктами? Этот вопрос регулярно поднимается в тематических linux-форумах. При такой его постановке возникает ощущение, что мы пытаемся найти свободный аналог изобретения программистов из Редмонда. Но это далеко не так – разработка протоколов для службы каталогов началась еще в 80-е годы прошлого века. Этим занималась международная организация International Telegraph and Telephone Consultative Committee, а созданный ею стандарт (частью которого являлся DAP – протокол доступа к каталогу), впоследствии стал называться X.500. Стоит отметить, что в современных службах каталогов (в том числе Active Directory) используется LDAP (Lightweight Directory Access Protocol) – облегченный вариант DAP. Это связано с избыточной функциональностью первоначальной версии протокола. Кроме того, если говорить о системном ПО, следует различать службу каталогов и прочие сервисы локальной сети (например, файловый сервер или сервер печати). Служба каталогов (Directory Service) – это программный комплекс, позволяющий хранить в одном месте информацию о сетевых ресурсах (общие каталоги, серверы печати, принтеры, пользователи и т.д.) и обеспечивающий централизованное управление ими. Прочие сетевые сервисы (например, файлсервер) могут выступать клиентами службы каталогов.

LDAP – основа службы каталогов

Протокол, используемый для организации доступа к службе каталогов X.500 – LDAP (Lightweight Directory Access Protocol). Это сетевой протокол, работающий поверх TCP/IP. Он позволяет производить операции аутентификации, поиска и сравнения записей. Кроме того, с помощью LDAP можно добавлять, изменять или удалять записи. Чаще всего LDAP-сервер «слушает» порт 389 (TCP или UDP). Для сеансов, инкапсулированных в SSL, обычно используется порт 636.

Записи в каталоге LDAP состоят из атрибутов и обладают уникальным именем (DN – Distinguished Name), которое может выглядеть так: «cn=Иван Иванов, ou=Работники, dc=company, dc=ru». Другими словами, уникальное имя часто состоит из нескольких относительных уникальных имен (Relative Distinguished Name), разделённых запятой. Относительные имена имеют вид «наименование=значение». К чему такие сложности? Это необходимо для создания древовидной иерархической структуры – на одном уровне каталога относительные уникальные имена не могут повторяться. Для наглядности можно сравнить уникальное имя «cn=Петр Сидоров, ou=Работники, dc=company, dc=ru» с предыдущим примером.

Атрибуты записи определяются в описаниях класса (object class), которые объединены в схемы (schema). Схема указывает, какие атрибуты являются обязательными, а также задает их тип и правила сравнения. В зависимости от типа атрибут записи может хранить несколько значений.

Что же касается серверов LDAP, среди открытых реализаций наиболее известен сервер OpenLDAP, а если говорить о проприетарных — это, безусловно, Microsoft Active Directory. Кроме того, службы каталогов, совместимые с LDAP, есть и у других разработчиков, например у Red Hat, Novell и Sun. В качестве LDAP-клиентов используются как ПО конечных пользователей (например, адресные книги почтовых программ), так и различные сетевые службы (файловые серверы, серверы DNS, SMTP и т.д.).

Службы Microsoft и стандарты

Поскольку мы будем довольно часто говорить о продуктах компании Microsoft, остановимся на них подробнее. В Windows NT использовалась собственная разработка Microsoft – Windows NT Directory Services (NTDS). Но уже в Windows 2000 ей на смену приходит Active Directory, основанная на стандартных протоколах. Система аутентификации новой службы каталогов базируется на протоколе Kerberos 5, а для разрешения имен используется DNS с возможностью динамического обновления. Доступ к информации об объектах домена AD осуществляется через LDAP. Естественно, что при таком подходе возникли проблемы обратной совместимости с доменами Windows NT, но освещение этих вопросов выходит за рамки нашей статьи. Главное было сделано – у Microsoft появился сервер каталогов, основанный на стандарте X.500. Казалось бы, все проблемы совместимости с разработками других производителей решены. Однако при реализации открытых протоколов программисты Microsoft внесли в них собственные расширения, затрудняющие взаимодействие между AD и прочими службами каталогов X.500. В цикле, который открывает эта статья, речь в основном пойдет о преодолении подобных трудностей, поскольку настройка служб каталогов (под Windows и Linux) сама по себе проблем администраторам не доставляет. Притом писать мы будем не только и не столько о замене одной службы каталогов на другую, сколько об их взаимодействии между собой. Для начала приведем небольшой обзор открытых программных продуктов.

Серверы каталогов – обзор

OpenLDAP Software

Cайт проекта: http://www.openldap.org/

В рамках OpenLDAP Project ведется разработка открытой кросс-платформенной реализации протокола LDAP. Программное обеспечение распространяется под собственной свободной лицензией (OpenLDAP Public License). В настоящее время доступны версии OpenLDAP для различных операционных систем: FreeBSD, GNU/Linux, IBM AIX, HP-UX, Mac OS X, Solaris, Microsoft Windows и других.

OpenLDAP состоит из трёх главных компонентов:

* slapd – демон LDAP и соответствующие инструменты;
* библиотеки, реализующие протокол LDAP;
* примеры клиентов LDAP: ldapsearch, ldapadd, ldapdelete и др.

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

* JLDAP – библиотеки классов LDAP для Java;
* JDBC-LDAP – драйвер интерфейса между Java JDBC – LDAP;
* ldapc++ – библиотеки классов LDAP для C++.

На самом деле, OpenLDAP, работающий в связке с файловым сервером Samba, является полноценной заменой Microsoft Active Directory и файловых серверов под Windows. Единственное, что может заставить UNIX-администратора отказаться от внедрения такого решения – сложность настройки сервера OpenLDAP. Существуют также определенные проблемы совместимости, затрудняющие эксплуатацию продукта в «смешанных» корпоративных сетях, где используются «серверные» продукты компании Microsoft и различные UNIX-системы. Службы каталогов, о которых говорится ниже, в той или иной степени позволяют справиться с этими затруднениями.

Fedora Directory Server (389 Directory Server)

Cайт проекта: http://directory.fedoraproject.org/ или http://port389.org

Сервер каталогов корпоративного уровня с открытым исходным кодом. Разработка проекта ведется сообществом при спонсорской поддержке компании Red Hat. Стоит отметить, что Fedora Directory Server (FDS) является составной частью FreeIPA – централизованного решения для управления информацией о пользователях, политиках и аудита на предприятии.

В 1996 году Netscape привлекает авторов оригинального LDAP-сервера (проект slapd, от которого произошел OpenLDAP) из Университета Мичиган для создания собственного сервера каталогов. В 1999 году AOL покупает Netscape и формирует альянс iPlanet, куда вошла также Sun Microsystems. Этот альянс просуществовал до 2001 года, после чего Nescape и SUN разрабатывали отдельные «форки» сервера каталогов. В 2005 году Red Hat приобретает права на исходные тексты Netscape Directory Server (NDS) и начинает их публикацию. Нетрудно догадаться, что FDS был разработан в рамках проекта Fedora на основе опубликованных компанией RedHat исходных текстов. Сервер состоит из нескольких компонентов, которые распространяются под различными свободными лицензиями (MPL/LGPL/GPL/X License и т.д.). Недавно разработчики решили переименовать проект, и теперь он называется 389 Directory Server (по номеру порта, который «слушает» служба LDAP). Это было сделано, чтобы избежать ассоциации с проектом Fedora, тормозящим (по мнению разработчиков) интеграцию продукта в другие дистрибутивы. К моменту написания статьи 389DS еще не вышел (последний стабильный релиз, доступный на сайте проекта – апрельский Fedora Directory Server 1.2.0), поэтому мы используем старое название.

Основные возможности Fedora Directory Server:

* –поддержка протокола LDAP v3;
* возможность использовать до четырёх равноправных мастер-серверов (предусмотрено автоматическое разрешение конфликтов, балансировка нагрузки и переключение на резервный мастер-сервер в случае выхода основного из строя);
* высокая масштабируемость – разработчики заявляют, что один сервер позволяет обрабатывать тысячи операций в секунду, заводить десятки тысяч пользователей, хранить сотни гигабайт данных и десятки миллионов записей;
* возможность синхронизации с контроллерами домена Active Directory 2000/2003 (необходима установка компонента Windows Sync на контроллер домена);
* консоль администрирования с графическим интерфейсом (доступна под Windows), есть возможность управления из командной строки, а также через Web-интерфейс;
* безопасная аутентификация и транспорт (SSL/TLS и SASL);
* механизм разграничения доступа вплоть до уровня отдельных атрибутов (имени пользователя, групп, IP-адреса, времени суток и т.д.).

Структура FDS довольно проста: ее основной компонент – сам сервер каталогов. Кратко рассмотрим его архитектуру. Здесь можно выделить часть, которая отвечает за сетевую коммуникацию, базовое древо каталогов (DIT) и механизм расширений, с помощью которого реализуются дополнительные функции (например, контроль доступа и репликация). Кроме того, существует прослойка между сервером каталогов и Berkeley DB, которая была адаптирована для NDS компанией Sleepycat Software.

Следующий важный компонент – сервер администрирования (Administration Server). Его задача – управление серверами каталогов (через Web-интерфейс или Java-консоль).

Основным инструментом системного администратора является написанная на Java Fedora Management Console. С ее помощью можно вызывать консоли управления сервером каталогов и сервером администрирования. Взаимодействует FMC с сервером администрирования по протоколам HTTP/HTTPS или напрямую, через LDAP. Кроме того, на сайте проекта доступна версия Fedora Management Console (в виде пакета msi). Еще в состав Fedora Directory Server входят вспомогательные утилиты командной строки для администрирования сервера, переноса данных, миграции пользователей и т.д.

Компания Red Hat выпускает коммерческий Red Hat Directory Server (RHDS) на основе FDS. Главным отличием RHDS от его свободного аналога является наличие технической поддержки с гарантированным временем отклика (включая вариант 24×7).

Mandriva Directory Server (MDS)

сайт проекта: http://mds.mandriva.org/

Компания Mandriva выпустила свой вариант свободно распространяемого сервера каталогов. В отличие от FDS, официальные бинарные сборки которого поставляются только для дистрибутива Fedora, на сайте проекта доступны пакеты для Mandriva Linux 2008.1 и 2009.0, Mandriva Corporate Server 4, а также Debian (Etch и Lenny). Кроме того, продукт включен в Mandriva Enterprise Server 5.

Mandriva Directory Server способен заменить контроллер домена Active Directory. Он позволяет администрировать пользователей, DNS и DHCP-серверы, а также почтовые и прокси-серверы. Архитектура MDS наглядно представлена на рисунке 1. Сервис состоит из двух основных блоков – веб-интерфейса администратора (MMC web interface) и модуля управления сервисами с плагинами, написанными на Python (MMC Agent). Остановимся подробнее на структуре веб-интерфейса. MMC Web interface включает несколько модулей:

* базовый модуль (base module);
* модуль файловых серверов SAMBA (SAMBA module);
* модуль прокси-серверов Squid/Squidguard (Web proxy);
* модуль почтового сервера PostFix (Mail service);
* модуль серверов ISC DHCP и BIND (DNS/DHCP).

MMC Web interface взаимодействует с MMC Agent через XML-RPC. Агент управляет сервисами через собственный API и работает с каталогом LDAP (поддерживаются OpenLDAP и FDS). Сервисы локальной сети в свою очередь являются клиентами службы каталогов.

Таким образом, мы видим, что MDS нельзя назвать полноценным сервером каталогов – скорее это административная надстройка над существующими решениями. Его основная задача – управление каталогом LDAP и сервисами локальной сети. Что же касается масштабирования – Mandriva Directory Server спроектирован с поддержкой от десятков до тысяч записей. Основное преимущество MDS перед аналогичными продуктами – простота установки и настройки. Кроме того, компания Mandriva предлагает коммерческую и техническую поддержку MDS, а также включает его в свои продукты для корпоративных клиентов.

Apache Directory Server

Cайт проекта: http://directory.apache.org/

Еще один сервер каталогов с открытым исходным кодом разрабатывает Apache Software Foundation. Apache Directory Server полностью написан на Java и распространяется под лицензией Apache. В 2006 году он был сертифицирован Open Group как совместимый с протоколом LDAPv3. Кроме LDAP, Apache DS поддерживает Kerberos5 и Change Password Protocol.

Разработчик позиционирует сервер как встраиваемое решение, предназначенное для интеграции в другие Java-приложения и работающее с ними в контексте одной VM. На сегодняшний день он встроен в такие продукты, как Apache Geronimo, JBoss и другие. Тем не менее, Apache DS можно запустить автономно, например, как службу Windows.

Поскольку программа полностью написана на Java, она успешно компилируется и работает на огромном количестве аппаратных и программных платформ. На сайте проекта доступны инсталляторы для GNU/Linux, Windows и MacOS, а также бинарные пакеты для Debian, Fedora и Solaris (для платформ SPARC и Intel), но на самом деле набор поддерживаемых ОС значительно шире.

Помимо стандартного функционала сервера LDAP, в Apache DS реализованы такие интересные расширения, как хранимые процедуры и триггеры. Автор проекта Алекс Карасулу (Alex Karasulu) в 2001 году предложил включить в сервер OpenLDAP поддержку этих объектов, которые давно используются в реляционных базах данных, но отсутствуют в спецификациях LDAP. Его попытка провалилась из-за сложности существующего программного обеспечения. В октябре 2002 года Алекс начинает разработку собственного сервера каталогов, написанного на Java. Затем, в октябре 2003 года, он передает права на код своей разработки в Apache Software Foundation.

К моменту написания данной статьи, на сайте проекта доступны две версии Apache DS: 1.0.2 и 1.5.4. Кроме того, в рамках проекта разрабатывается Apache Directory Studio, которая включает LDAP-браузер, браузер схем, редактор LDIF, редактор DSML и другие клиентские программы, необходимые для администрирования сервера каталогов.

Заключение

Как мы видим, свободных реализаций сервера каталогов X.500 существует не так уж много. В следующих статьях мы обязательно поговорим о них подробнее, поскольку русскоязычной документации по использованию серверов LDAP в Сети явно недостаточно. Помимо чисто практических моментов, мы сосредоточимся на подробном описании архитектуры существующих решений, а также расскажем о перспективах развития протокола LDAP. Разумеется, не будем забывать и о главной проблеме использования свободных DS – интеграции с Microsoft Active Directory. Во второй статье цикла речь пойдет об установке и настройке Mandriva Directory Server.