LDAP в середине пути

Упрощенный протокол доступа к каталогу представляет собой мостик между службой каталогов и различными приложениями.

С переходом от простых локальных сетей с их такими же простыми файловыми сервисами к сложным гетерогенным сетям, которые на основе различных аппаратных платформ и операционных систем предоставляют услуги электронной почты, сервера Web, баз данных и многих других приложений и сервисов, растет и сложность управления этими сетями и приложениями. Программное обеспечение различных производителей хранит информацию о настройках, пользователях и рабочей среде пользователей в своих собственных конфигурационных файлах. Это приводит к дублированию информации в различных приложениях, усложняя администрирование (например, для каждого используемого приложения администратору приходится вносить учетные данные о конкретном пользователе) и невозможности использования конфигурационной информации одного приложения другими. В то же время конечным пользователям становится все сложнее работать с сетевыми ресурсами (например, при смене пароля необходимо изменить его во всех приложениях). Все это, естественно, увеличивает вероятность ошибок и стоимость владения системой в целом. Таким образом, назрела потребность в универсальной службе каталогов (directory services). Крупнейшие игроки сетевой отрасли -- Sun, Netscape, Novell и Microsoft -- предпринимали попытки создать собственные решения в области предоставления сервисов каталогов. Все они находятся на разных стадиях разработки, задействуют различные методологии, но так или иначе используют в своих продуктах протокол LDAP.

ЧТО ТАКОЕ LDAP

Посмотрим, что же собой представляет протокол LDAP и когда он необходим. В типичной корпоративной сети пользователям нужен доступ к различным службам и приложениям, таким, как сетевые файловые сервисы, принтеры, почтовые серверы, серверы баз данных и проч. Обобщенно говоря, им требуется доступ к множеству защищенных сервисов на различных аппаратных и программных платформах. Следовательно, для комфортной работы необходима единая служба каталогов с аутентификацией доступа ко всем ресурсам сети. Такая служба должна централизованным образом хранить не только имена пользователей и их пароли, но и множество данных различных типов (например, контактную информацию, конфигурацию приложений, пользовательские настройки приложений и рабочих сред). Кроме того, она должна предоставлять пользователям возможность доступа к собственным данным с любого компьютера как в локальной сети, так и в любой точке глобальной сети.

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

Для создания единой учетной записи пользователя и получения доступа к разным файловым серверам, базам данных и другим приложениям необходим мостик между службой каталогов и различными приложениями, который и предоставляет LDAP (Lightweight Directory Access Protocol).

Протокол LDAP был разработан исследователями из Мичиганского университета для упрощения доступа к сервисам каталогов X.500. Стандарт CCITT X.500 описывает базовую структуру и функциональную модель службы каталогов, но он очень сложен и громоздок, а его реализация требует использования стека протоколов OSI. В результате стандарт X.500 не нашел широкого применения в сетях TCP/IP.

В соответствии с Х.500 служба каталогов состоит из пяти основных элементов.

1. Служба каталогов включает модель базовой структуры хранимой информации. Она состоит из записей (entries), атрибутов (attributes) и значений (values). Записи представляют элементы службы каталогов, соответствующие сетевым пользователям, разделяемым ресурсам, сетевым принтерам, приложениям и т. д. Каждая запись содержит атрибуты. Атрибуты представляют свойства, в соответствии с которыми службы каталогов классифицирует записи. Например, пользователь может иметь такие атрибуты, как фамилия, имя, отчество, адрес электронной почты, пользовательское имя и пароль. Каждый атрибут, в свою очередь, имеет конкретное значение. К примеру, атрибут "Фамилия" может иметь значение "Иванов".
   
   Таким образом, служба каталогов представляет собой объектную ассоциативную базу данных, куда входят объекты - записи, характеризуемые парами атрибут-значение.
2. Информация службы каталогов иерархически организована в виде дерева, которое носит название информационного дерева каталога (Directory Information Tree, DIT). DIT хранит записи каталога и использует пространство имен для однозначной идентификации точного местоположения каждой записи в дереве. В качестве вершины дерева обычно используется двухбуквенный код страны. Конструкции, располагающиеся ниже, предоставляют все более конкретные сведения: например, название компании, далее названия отделов и т. д. Подобно пути к файлу, в файловой системе отличительное имя записи (Distinguished Name, DN) указывает путь к ней и однозначно определяет как саму запись, так и ее местоположение в DIT.
3. Служба каталогов содержит набор команд, которые можно использовать для управления записями. Команды выполняют такие операции, как: Чтение, Запись, Поиск, Сравнение, Удаление, Модификация.
4. Служба каталогов содержит систему для аутентификации пользователей, без регистрации в которой доступ к сервису каталогов не предоставляется. Для своей аутентификации пользователи могут задействовать различные методы, такие, как простая комбинация - имя, пароль, Kerberos и др.
5. Сервис каталогов может строиться по распределенной модели, чтобы клиенты (пользовательские агенты каталога) могли видеть данные, расположенные на различных серверах (системных агентах каталога), сведенными воедино.

Если сервер получает запрос на предоставление данных, находящихся на другом сервере, он передает запрос соответствующему серверу с помощью метода цепочек (chaining) или метода ссылок (referral).

Метод цепочек заключается в том, что при получении сервером запроса от клиента, который он не может удовлетворить, сервер посылает идентичный запрос на следующий сервер. Если и этот сервер не содержит требуемых данных, он посылает запрос следующему. Процесс продолжается до тех пор, пока не отыщется сервер, который хранит необходимые данные, или пока не будет достигнут последний сервер в цепочке. Ответ возвращается по результирующей цепочке обратно клиенту. В качестве альтернативы сервер может вернуть клиенту в ответ на запрос, который он не в состоянии удовлетворить сам, ссылку на сервер, содержащий требуемые данные. Клиент по полученной ссылке посылает новый запрос непосредственно тому серверу, где находятся интересующие его данные.

В настоящее время большинство поставщиков служб каталогов используют спецификацию Х.500 как основу для построения своих продуктов.

Стандарт Х.500 описывает не только модель построения сервиса каталогов, но и протокол доступа к каталогу (Directory Access Protocol, DAP), т. е. правила взаимодействия клиента и сервера сервиса каталогов. Однако протокол DAP требует от клиента использования стека протоколов OSI, и его реализация отнимает много системных ресурсов. И в 1989 г. в Мичиганском университете был разработан протокол LDAP, подмножество протокола DAP. Из DAP были исключены редко используемые возможности и осуществлен перенос со стека протоколов OSI на стек TCP/IP.

Текущая версия LDAP (версия 2) определена IETF в документах RFC 1777 и RFC 1778. Спецификация LDAPv2 описывает порядок обмена сообщениями в формате Х.500 между клиентом и сервером. Сервер LDAP может быть как самостоятельным приложением, использующим шлюз LDAP для взаимодействия с сервером X.500, так и частью реализации сервера Х.500.

Следует отметить, что отличия между LDAP и Х.500 этим не ограничиваются. Во-первых Серверы LDAP используют ту же структуру службы каталогов и пространства имен, что и сервер Х.500, но поддерживают меньшее количество команд, обеспечивая при этом сопоставимый уровень функциональности. Во-вторых, в отличие от клиентов Х.500 клиенты LDAP не участвуют в процессе обработки ссылок. Сервер LDAP обрабатывает ссылки и перенаправляет запрос на соответствующий сервер. Клиент LDAP получает от сервера либо запрошенные данные, либо сообщение об ошибке, если сервер не может обработать запрос. В-третьих, серверы LDAP используют упрощенный процесс кодирования при передаче отличительных имен (DN) записей. X.500 не предусматривает такой возможности.

Чем больше компании используют LDAP, тем больше применений они для него находят. Например, в связи с тем, что LDAP работает по протоколу TCP/IP, доступ к данным, хранящимся на серверах Х.500, более не ограничивается только клиентами, на которых установлен стек OSI. Для доступа к частным каталогам Х.500 клиенты могут использовать Internet. Этот факт нашел отражение в форме адресных книг приложений электронной почты Netscape Communicator и Internet Explorer.

Другое новое приложение LDAP - для упрощения использования LDAP в Internet, RFC 1959 -- описывает формат URL для прямого доступа к серверам LDAP посредством браузера Web. Этот формат вводит новый префикс протокола - ldap. И Netscape Communicator и Internet Explorer поддерживают LDAP URL. Netscape Communicator отображает результат запроса в той же манере, как и обычную страницу HTML, а Internet Explorer добавляет результат запроса в адресную книгу.

Функциональность LDAP не ограничивается теперь исключительно доступом к каталогам Х.500. Несмотря на быстрое замещение протоколом LDAP протокола DAP, каталоги Х.500 остались столь же сложными для реализации и обслуживания, как и прежде, в связи с чем их применение эффективно только в очень больших организациях. Как следствие, крупнейшие производители программного обеспечения стали предпринимать попытки использования серверов LDAP для взаимодействия с другими службами каталогов или в качестве самих каталогов.

Если компании Netscape удалось достичь значительных успехов в реализации LDAP как самостоятельной службы каталогов, то другие производители чаще всего терпели неудачу при использовании LDAP для доступа к другим службам каталогов. Это в основном было обусловлено тем фактом, что LDAPv2 разрабатывался как средство доступа к каталогам Х.500. Данное обстоятельство заставило разработчиков заняться третьей версией протокола - LDAPv3. Текущая черновая спецификация описывает LDAPv3 как способ доступа к каталогам, реализованным в соответствии с моделью Х.500, но не тождественным каталогам Х.500.

Одним из существенных преимуществ LDAPv3 должна стать возможность модификации структуры каталога в соответствии с требованиями конкретных приложений. Данная модификация приводит к изменению схемы каталога. Схема -- это набор правил, отражающих сущность записи ее атрибутов и синтаксис значений данных атрибутов.

Модификация схемы -- не очень сложная операция. Проблемы возникают при взаимодействии каталогов с различными схемами. LDAPv2 не решает данной проблемы, так как сервер LDAP всегда предполагает, что он взаимодействует с каталогом Х.500.

Черновая спецификация LDAPv3 предлагает универсальное решение проблемы несовместимости схем за счет введения специализированных подсхем. Использование подсхем позволяет опубликовать детали схемы каталога и разделить данные детали с другими серверами каталогов. Чтобы серверы каталогов могли обмениваться данными, сначала они должны обменяться схемами.

Другое важное нововведение в спецификацию протокола - улучшенная поддержка аутентификации пользователей. В дополнение к простым текстовым паролям спецификация предусматривает применение широко используемого в обменах данными в Internet стандарта Secure Sockets Layer (SSL), а также нового механизма Simple Authentication and Security Layer (SASL). Обращаясь к SSL и SASL, пользователи получают реальную альтернативу сервисам аутентификации третьих производителей, например Kerberos, если по каким-либо причинам они им не подходят.

LDAPv3 предусматривает использование национальных языков, возможность возвращения клиенту в ответ на запрос ссылки на другой сервер и получения результатов поиска в виде отдельных страниц.

Спецификация RFC 2307 описывает использование LDAP в качестве сетевого информационного сервиса, в котором операционные системы могут хранить информацию о пользователях, протоколах и проч. В настоящее время данную спецификацию поддерживает Sun Solaris 8, и с сервера http://www.padl.com можно получить модули для Linux и Sun Solaris 2.6, 7 и сценарии для миграции данных с операционной системы в LDAP.

Таким образом, цель использования сервиса каталогов состоит в создании единого хранилища всей идентификационной и конфигурационной информации и контроля доступа к ней со стороны пользователей и приложений. Для создания такого центра хранения всей информации о правах доступа к сервисам, файловым серверам, базам данных и другим приложениям необходима связь между сервисом каталогов и приложениями. Lightweight Directory Access Protocol (LDAP) и предоставляет такую связь. Как было описано выше, LDAP вырос из основанного на TCP/IP средства доступа к каталогам X.500 к своему сегодняшнему статусу - потенциального стандарта на взаимодействие служб каталогов.

Несмотря на то что третья версия протокола находится в стадии разработки, крупнейшие производители уже используют ее в своих продуктах. Ниже мы рассмотрим реализацию протокола тремя крупнейшими производителями -- Netscape, Novell и Microsoft.

NOVELL NDS И LDAP

По сравнению с другими компаниями Novell имеет существенное преимущество, так как ее служба каталогов появилась на рынке в 1993 г., раньше, чем продукты Netscape и Microsoft. Изначально продукт носил название NetWare Directory Services (NDS), поскольку он использовался исключительно для хранения информации о ресурсах сети NetWare. Впоследствии Novell сделала возможным хранение информации о всей сети предприятия. Дабы отразить данный факт, в 1996 г. название продукта было изменено на Novell Directory Services.

NDS много позаимствовала у Х.500: в частности, она использует те же принципы организации, большинство классов объектов и слегка измененное пространство имен. Подобно Х.500, распределенный каталог NDS позволяет пользователям видеть находящиеся на нескольких серверах данные как единое целое. Основное отличие от Х.500 состоит в том, что взаимодействие между серверами осуществляется с помощью протокола IPX.

Стремясь расширить функциональность NDS и выйти за рамки сети NetWare, Novell реализовала версии сервера каталогов для UNIX и NT. Однако в настоящее время для работы с NDS в основном применяются серверы NetWare.

В конце 1996 г. Novell выпустила продукт под названием LDAP Services for NDS в виде загружаемого модуля (NLM) для преобразования данных из NDS в LDAP. NLM реализует LDAPv2, и, соответственно, клиенты могут иметь доступ к любой информации из каталога NDS, но не получают доступ к каталогам, отличным от Х.500. Для обхода данного ограничения Novell добавила возможность ручного отображения классов объектов и атрибутов NDS в эквиваленты LDAP.

WINDOWS 2000 ACTIVE DIRECTORY И LDAP

Active Directory (AD) использует технологию поиска сервисов в DNS, именование объектов в стиле Х.500 и обмен данными по протоколу LDAP. В реализации AD отдельные домены со своими сервисами каталогов NT преобразованы в домены DNS, а те, в свою очередь, объединены в дерево доменов и составляют унифицированную сеть.

Одной из важнейших особенностей AD является возможность подключения и управления другими службами каталогов из такой же сети, благодаря чему хранимая в AD информация может использоваться для аутентификации пользователей при доступе к приложениям, у которых имеются собственные каталоги, например к Lotus Notes. Кроме того, AD позволяет производить тиражирование данных из других служб каталогов, например NDS, и задействовать средства AD для управления такими данными.

AD включает в себя подмножество различных коммуникационных протоколов, таких, как Х.500, LDAPv2 и LDAPv3. Эти протоколы являются частью интерфейса прикладного программирования Active Directory Service Interfaces (ADSI). ADSI предназначен для организации интерфейсов между AD и другими приложениями или службами каталогов.

Для аутентификации и обеспечения безопасности в AD используются внешние провайдеры, такие, как Kerberos и SSL. Данные провайдеры используют интерфейс Security Support Provider Interface (SSPI) для подключения средств аутентификации и обеспечения безопасности.

AD поддерживает различные системы именования объектов, так что пользователь может употреблять любые удобные для него соглашения по именованию. Кроме отличительных имен LDAP и Х.500, AD позволяет использовать формат LDAP URL, описанный в RFC 1959, стандарт на имена Internet (RFC 822) и родные универсальные для NT соглашения (Universal Naming Convention, UNC). Стратегия AD основывается на соглашении об именовании в предположении, что в сети работают другие службы каталогов (например, Lotus Notes и NDS).

Таким образом, Microsoft AD может функционировать как служба метакаталогов.

NETSCAPE (IPLANET) DIRECTORY SERVER 4.12

Компания Netscape внесла наибольший вклад в развитие LDAP и его версии 3. Netscape Directory Server использует LDAP как основу для службы каталогов, а не как шлюз доступа к каталогам, находящимся на серверах других типов (для организации шлюзов и объединения различных серверов каталогов в единое целое используется другой продукт - Netscape Meta Directory).

Directory Server реализует большинство потенциальных возможностей протокола LDAPv3, такие, как интеллектуальные ссылки, поддержка механизмов аутентификации SSL и SASL, расширяемая схема. Для аутентификации пользователей Directory Server может синхронизироваться с доменом WinNT 4.

Разработчикам предоставляются средства разработки программ на Java, C/C++ и Perl.

После создания Sun-Netscape Alliance компания Sun добавила к Netscape Directory Server пакет Directory Extensions for Solaris, реализующий шлюз к NIS (Network Information Services) и RADIUS (Remote Authentication Dial-In User Service).

В отличие от NDS и AD, Directory Server поддерживает только тиражирование по схеме главный/подчиненный (в бета-версии iPlanet Directory Server 5.0 реализовано тиражирование с несколькими главными серверами), при которой все изменения в каталоге должны производиться на главном сервере, откуда они переносятся на подчиненный.

В настоящее время Netscape Directory Server можно считать лучшим среди серверов LDAP.

XML И LDAP

В декабре 1999 г. специализирующаяся на построении массовых систем электронной коммерции компания Bowstreet при поддержке Sun-Netscape Alliance, IBM, Novell, Oracle и Microsoft предложила стандарт на универсальный язык службы каталогов -- так называемый язык разметки службы каталогов (Directory Services Markup Language, DSML). Спецификация DSML 1.0 позволяет описывать содержимое службы каталогов на языке XML, что упрощает клиентам доступ к службам каталогов различных производителей.

На появление DSML сразу отреагировали поставщики служб каталогов и продуктов электронной коммерции. Sun Microsystems реализует DSML в Java Naming and Directory Interface (JNDI), части платформы Java 2. Novell недавно добавила функциональность DSML в свой продукт DirXML. Critical Path использует его в своих метакаталогах и службах каталогов. iPlanet реализовал поддержку DSML в своем LDAP SDK.

DSML 1.0 содержит только описание хранимых в каталогах данных и схем. В настоящее время ведутся работы над DSML 2.0, куда планируется добавить иерархическую организацию записей каталогов, унификацию отличительных имен и методов доступа к каталогам, манипулирование содержимым каталогов и поддержку информации о доступе к каталогам.

КРАТКОЕ РЕЗЮМЕ

Таким образом, LDAP сегодня единственное реальное средство реализации единого защищенного информационного каталога. Централизация хранимой информации о пользователях, приложениях, сетевых ресурсах, рабочих средах пользователей позволяет уменьшить стоимость владения информационной системой, упрощает ее администрирование и снижает вероятность возникновения ошибок при этом, а также устраняет дублирование информации. Наличие систем аутентификации, разграничения и аудита доступа к службам каталогов дает весомые основания утверждать о защищенности и целостности хранимых данных при попытках воздействия на них неавторизованных пользователей.

К сожалению, за рамками данной статьи остались весьма важные области применения протокола LDAP в средствах обеспечения информационной безопасности вычислительных систем и сетей. В частности, LDAP является основой для построения систем управления цифровыми сертификатами, используемых для электронной подписи, аутентификации пользователей и устройств и распределения ключей шифрования в виртуальных частных сетях.