ITx group Rambler's Top100
Home | О нас | Статьи | Проекты | Программы | Форум | Поиск

Краткое введение в LDAP

 

ITx group

 

Ростов-на-Дону

Сентябрь 2002г..


 

Оглавление.

Введение.. 5

История создания. 5

Модель директории. 5

Дерево директории. 6

Распределенная модель. 7

Функциональная модель. 7

Размышления о перспективах. 8

Современные тенденции. 8

Пример реализации директории. 8

Приложение 1. 9

Примеры команд для взаимодействия с OLDAP сервером. 9

ldapadd -rc < /etc/Organisation_X.ldif /usr/local/etc/openldap/slapd.confї 9

/etc/Organisation_X.ldif. 9

 


ї

Введение

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

История создания.

LDAP является упрощенным вариантом DAP X.500, разработанного еще в 1988 году для нужд телекоммуникаций. X.500 был достаточно сложным в реализации в сетях TCP/IP, поэтому IETF приступила к разработке измененного и упрощенного варианта X.500. Разработанная спецификация получила название LDAP-1 и определяла основные понятия, такие как LDAP-клиент и шлюз, через который обрабатываются клиентские запросы, адресованные к директории. Появившийся достаточно скоро очередной вариант - LDAP-2 (RFC1777) содержал в себе возможность создания внутренних директорий, хранящихся на LDAP сервере (понятие которого появилось также в LDAP-2), не зависящих от X.500. На сегодняшний день широко используется LDAP-3, в котором устранено множество недостатков предыдущих версий протоколов. В рамках стандарта LDAP-3 (RFC2251) LDAP сервер превращается в мощнейшее средство для создания глобальных информационных каталогов. Стадартом RFC2256 также определяется общая схема (common schema), которая устанавливается на всех серверах LDAP. Админинистратор также может расширить схему, добавив описания новых элементов каталога (классы) и их свойств (атрибуты).

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

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

Модель директории.

Данные размещаются в директории в виде объектов. Каждый объект директории является отображением какого либо реально существующего объекта - человека, принтера, компьютера и т.д. Каждый объект имеет несколько атрибутов, последний в свою очередь имеет название и значение фиксированного в LDAP типа. Тип определяет формат значения, вид его представления, способы сопоставления и упорядочивания.

 

Объекту присваивается класс (или классы) к которому он принадлежит с помощью обязательного атрибута objectClass, значением которого является имя класса.


  Пример:

objectClass: top
objectClass: organizationalPerson
objectClass: posixAccount
uid: Postnikov
mailAddress: postnikov@nordcomp.ru
phone: 7 8212 310310

 

Классы объектов объявлены в схеме директории (directory schema), где задаются имя класса, атрибуты, тип атрибутов а также указывается их обязательность или опциональность. Также могут быть указаны и родительские классы, определения которых будут наследоваться. Естественно, атрибут, который упоминался в родительском классе, как обязательный, для дочернего класса также будет обязательным. Аналогично и с опциональными атрибутами.


Особенность представления схемы в LDAP является то, что определение атрибутов не включается в объявление классов, а дается самостоятельно. Таким образом в схеме сначала дается определение атрибутов, который затем используется при построении классов объектов. Эта особенность вызвана тем, что необходимо предотвратить ситуацию появления в классах атрибутов с одинаковым именем, но с разными типами значений.

Дерево директории.

Объекты в директории компонуются в виде древовидной структуры. Логическое местоположение объектов в дереве отражает какую либо подчиненность (географическую, физическую, организационную). При создании нового объекта необходимо указать его принадлежность к классу, атрибуты, указать существующий объект, к которому он будет подчинен и задать относительное уникальное имя (Relative Distinguished Name). RDN задается посредством указания одного или нескольких значений атрибутов, при этом если объект имеет несколько атрибутов, то задается один из них.

 

Пример:

Здесь RDN является uid. Объект имеет атрибут с именем uid, и этот атрибут и его значение указано в качестве RDN.

dn: uid=Postnikov, ou=People, dc=Nordcomp, dc=ru
objectClass: top
objectClass: organizationalPerson
objectClass: posixAccount
uid: Postnikov
mailAddress: postnikov@nordcomp.ru
phone: 7 8212 310310

Уникальные имена (Distinguished Name), позволяющие однозначно идентифицировать объекты в директории, образуются с посредством конкатенации RDN вышестоящих по иерархии объектов (по аналогии со службой DNS), записываемые от объекта к корню. Для разделения RDN внутри DN используется запятая.

Распределенная модель.

LDAP директория изначально проектировалась как распределенная система хранения информации. При использовании распределенной модели различные фрагменты информационного дерева физически хранятся на разных серверах. Идентифицируются распределенные серверы LDAP в глобальных сетях с помощью интернет-адреса вида ldap://URL:port. Где URL есть DNS имя или IP адрес, а port - номер порта (для обычного 389 и для защищенного 686). К интернет-адресу LDAP сервера также может быть добавлен DN, идентифицирующий соответствующий объект в директории. Например, объект, имеющий в директории DN uid=Postnikov,ou=People,dc=nordcomp,dc=ru адресуется с помощью интернет-адреса в следующем виде:


     ldap://ldap.nordcomp.ru/uid=Postnikov,ou=People,dc=nordcomp,dc=ru.


В распределенной модели каждый сервер хранит собственную базу данных, содержащую один или несколько фрагментов директории, являющиеся поддеревьями информационного дерева директории. Идентификация каждого объекта осуществляется посредством задания суффикса - DN-имени объекта, являющегося корнем этого поддерева. Поддерево, определяемое суффиксом, может воспользоваться переадресацией на другой LDAP сервер с помощью ссылок (referrals). Внешние ссылки позволяют исключить некоторую информацию из поддерева и передать ее на обслуживание другому серверу, позволяя представить как единое целое распределенную директорию. Ссылки представляются в виде отдельного специального объекта, принадлежащего к классу (objectClass) Referral, с помощью атрибута ref. Атрибут ref как раз и содержит ссылку на объект в виде ldap://URL:port/DN.


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


Репликационный механизм организуется с   помощью мастер-сервера и вторичных серверов (по аналогии с серверами DNS), причем любой LDAP сервер одновременно может являться как получателем, так и поставщиком данных. Для повышения эффективности репликации, на мастер-сервере используется журналирование изменений, и реплицируются именно изменения, которые имели место с последнего момента репликации, а не все данные.

Функциональная модель.

Функциональная модель LDAP основана на клиент-серверной технологии. Существует достаточно большое количество API для различных языков программирования (C/C++, Perl, JAVA и др.) для доступа к LDAP директориям. Базовыми функциями LDAP-клиента являются следующие: открытие соединения клиента с сервером, аутентификация, выполнение поиска, модификация данных, закрытие соединения.


Современные операционные системы содержат в себе основные утилиты для работы с LDAP серверами, например в UNIX это утилиты ldapsearch, ldapmodify и т.д. Существуют также графические клиентские программы (так называемый LDAP-Browser), позволяющие просматривать, производить поиск и изменять содержимое LDAP директорий. В следующей таблице приведен список наиболее важных операций в LDAP, утилит, их реализующих, и соответствующее описание в соответствии со стандартом RFC1823.
  

Операция

Утилита

Описание

Search

ldapsearch

Производит поиск в директории и возвращает результат поиска в виде списка значений найденных объектов

Add

ldapadd

Осуществляет добавление новых объектов в директорию. При добавлении объектов указывается их DN, objectClassи значения атрибутов.

Modify

ldapmodify

Производит удаление объектов из директории. Удаление же контейнерных (поддеревьев) объектов возможно только с помощью рекурсивных операций.

Delete

ldapdelete

Осуществляет возможность модифицирования атрибутов (удаление, замена, добавление) и их значений у существующих объектов в директории.

Bind

 

Производит открытие сессии клиента с сервером, предоставляет данные для аутентификации

Unbind

 

Закрывает соединение между клиентом и сервером

Abandon

 

Завершает выполнение асинхронной операции на сервере


  

Размышления о перспективах.

Современные тенденции.

В настоящее время архитектура LDAP приобретает все большее значение. Приведем несколько примеров:

Bigfoot

Infospace

Infospace Busines

NetCenter Member Directory

SwitchBoard

Verisign

WhoWhere

Yahoo People Search

MS Outlook

TheBat

Netscape messenger

Mozila

Linux RedHat 7.3

Novell NetWare 5.0 (eDirectory)

Sun Solaris (Sun ONE)

На основании вышесказанного можно предположить, что в перспективе LDAP может стать основой для межсистемной интеграции хранения информации. В частности это могут быть единые системы управления сетях с гетерогенным системным и прикладным ПО. Более того, данная архитектура, может органично войти в совершенно новые, революционные ИТ технологии.її

Пример реализации директории.

Автором было произведено внедрение данной технологии в крупной международной корпорации. Назовем ее Organisation_X (название и некоторые детали реализации не приводится по соображениям конфиденциальности).

На платформе FreeBSD 4.0, был инсталлирован сервер OLDAP. Примеры конфигурационных файлов и команд управления сервером приведены в приложении 1. Хранение информации сервером базировалось на применении БД FreeBSD - ldbm. Данный сервер использовался в корпоративной сети, как корпоративная адресная книга (см. /etc/Organisation_X.ldif). В качестве клиентского ПО выступали:

 


Приложение 1.

Примеры команд для взаимодействия с OLDAP сервером.

Ldif2ldbm -i / Organisation_X etc/.ldif

ldapdelete "cn=Ivanov, o=Organisation_X, c=RU"

ldapmodifyї -rc < /etc/Organisation_X.ldif

ldapadd -rc < /etc/Organisation_X.ldif /usr/local/etc/openldap/slapd.conf

gw[/usr/home/nimda]# m /usr/local/etc/openldap/slapd.conf

#

# See slapd.conf(5) for details on configuration options.

# This file should NOT be world readable.

#

includeїїїїїїїї /usr/local/etc/openldap/slapd.at.conf

includeїїїїїїї ї/usr/local/etc/openldap/slapd.oc.conf

schemacheckїїїї off

#referralїїїїїї ldap://root.openldap.org/

ї

pidfileїїїїїїїї /var/run/slapd.pid

argsfileїїїїїїї /var/run/slapd.args

ї

#######################################################################

# ldbm database definitions

#######################################################################

ї

databaseїїїїїїї ldbm

#suffixїїїїїїїї "dc=Organisation_X, dc=com"

#suffixїїїїїїїї "o=Organisation_X, c=RU"

suffixїїїїїїїїї "c=RU"

#rootdnїїїїїїїї "cn=Manager, dc=my-domain, dc=com"

#rootdnїїїїїїїї "cn=Admin, o=Organisation_X, c=RU"

#rootpwїїїїїїїї secret

# cleartext passwords, especially for the rootdn, should

# be avoid.ї See slapd.conf(5) for details.

directoryїїїїїї /usr/tmp

defaultaccessїї write

/etc/Organisation_X.ldif

dn: o=Organisation_X, c=RU

o: Organisation_X

objectclass: organization

ї

dn: o=world, c=RU

o: world

objectclass: organization

ї

 

dn: cn=Ivanov, o=Organisation_X, c=RU

cn: (Rostov) ivanov

cn: _ivanov

mail: ivanov@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Boss, o=Organisation_X, c=RU

cn: (Rostov) boss

cn: _boss

mail: boss@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Sale, o=Organisation_X, c=RU

cn: (Rostov) Sale

cn: _Sale

mail: sale@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Urist, o=Organisation_X, c=RU

cn: (Rostov) Urist

cn: _Urist

mail: urist@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Buh1, o=Organisation_X, c=RU

cn: (Rostov) Buh1

cn: _Buh1

mail: buh1@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Buh2, o=Organisation_X, c=RU

cn: (Rostov) Buh2

cn: _Buh2

mail: buh2@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Buh5, o=Organisation_X, c=RU

cn: (Rostov) Buh5

cn: _Buh5

mail: buh5@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Kassir, o=Organisation_X, c=RU

cn: (Rostov) Kassir

cn: _Kassir

mail: kassir@Organisation_X.don.ru

objectclass: person

ї

dn: cn=Admin, o=world, c=RU

cn: (Moskva) Admin

cn: _Admin

mail: admin@Organisation_X.impuls.ru

objectclass: person

ї

dn: cn=ORP, o=world, c=RU

cn: (Moskva) ORP

cn: _ORP

mail: orp@Organisation_X.impuls.ru

objectclass: person

ї

dn: cn=Ofis, o=world, c=RU

cn: (Moskva) Ofis

cn: _Ofis

mail: ofis@Organisation_X.impuls.ru

objectclass: person

ї

dn: cn=Reklama, o=world, c=RU

cn: (Moskva) Reklama

cn: _Reklama

mail: reklama@Organisation_X.impuls.ru

objectclass: person

ї

Copyright (С) 2002 ITx. All right reserved.

Rambler's Top100 rax.ru: показано число хитов за 24 часа, посетителей за 24 часа и за сегодня
Последнее изменение