Главная
Мобильные советы
Протокол LDAP. Что такое LDAP и с чем его едят

Протокол LDAP. Что такое LDAP и с чем его едят

24.06.2019

У LDAP, и особенно у OpenLDAP, есть ряд возможностей обеспечения безопасности, которые на первый (да и на второй и третий) взгляд могут показаться немного сложными. Рисунок 15-1 показывает общую картину проблемы, перед тем как углубиться в детали. Далее демонстрируются различные методы доступа и интерфейсы к LDAP-системе, а затем описываются проблемные вопросы безопасности и доступные методы управления рисками. Цель данного упражнения — либо определиться с набором политик безопасности, либо выделить приоритеты реализации.

Рисунок 15-1. Общая картина вопросов обеспечения безопасности

Все номера, встречающиеся в описании ниже, ссылаются на рисунок 15-1.

Взаимодействие с удалёнными абонентами (1): Обеспечение безопасности при взаимодействии с удалёнными абонентами может как быть, так и не быть проблемным вопросом. При предоставлении неограниченного (анонимного) доступа к неконфиденциальной LDAP-информации вопросы обеспечения безопасности не ставятся. Внимание: в этих условиях Ваш сервер всё равно становится потенциальным объектом DoS/DDoS-атак посредством нагрузки его вредоносными LDAP-запросами. Таким образом, даже такая на первый взгляд тривиальная реализация может потребовать тщательного проектирования.

Если все взаимодействия с LDAP гарантированно происходят в доверенной сети, то Вы можете остановить свой выбор на работе с простыми паролями в открытом виде без дополнительных заморочек с безопасностью. Однако, даже в таких случаях, в зависимости от топологии доверенной сети, бывает достаточно просто перехватывать трафик и получать либо конфиденциальные данные (1-2), либо пароли (1-1), посылаемые в открытом виде.

Когда взаимодействие с LDAP осуществляется через ненадёжные сети, у деструктивных личностей в сети сразу находится, чем заняться: будьте готовы к тому, что перехваты, отслеживания, атаки типа "человек посередине" ("man-in-the-middle") и т.п. будут постоянным явлением. Также имейте в виду, что использование онлайн-конфигурации OLC (cn=config) и функций мониторинга (cn=monitor) может привести к тому, что LDAP-браузеры станут обычным инструментом для удалённого администрирования и управления LDAP-серверами. А этот трафик по своей природе невероятно конфиденциален.

Если решено, что некоторый уровень обеспечения безопасности всё же необходим, то первый вопрос, возникающий в этом случае: нужно ли нам защищать только пароли (1-1), или нужно защищать и данные (1-2), и пароли (1-1)? В зависимости от ответа на этот вопрос будут определяться наши следующие шаги.

Пароли (1-1): Не следует путать защиту паролей во время передачи по сети с защитой их в конфигурационных файлах или в DIT. Даже если Вы защитили все пароли в конфигурационных файлах или в DIT с помощью методов хэширования, таких как {SSHA}, при отправке пароля клиентом серверу для аутентификации он посылается в открытом виде, хэшируется на сервере и сравнивается с хранимым значением. Без принятия дополнительных мер он, таким образом, может быть перехвачен (или отслежен, в зависимости от ваших предпочтений к подобным терминам). Примечание: Когда клиент запрашивает запись, содержащую, скажем, атрибут userPassword , значение которого захэшировано, допустим, по алгоритму {CRYPT}, то этот пароль посылается не в открытом виде, а в своей хэшированной форме (то есть в той, в которой он хранится). Однако, когда осуществляется доступ от имени этой же самой записи, клиент посылает пароль (с помощью которого он проходит аутентификацию) в открытом виде, и, естественно, если аутентификация прошла успешно, перехватывающий может вполне резонно предположить, что посланный в открытом виде пароль был верен.

При пересылке хэшированных паролей в потоке данных, который может подвергнуться перехвату, они становятся уязвимыми к атакам по словарю — получив хэшированный пароль, атакующий прогоняет список паролей (так называемый словарь) через алгоритм хэширования, пока не найдёт совпадения. Использование соли (одного или нескольких байт, — в зависимости от реализации, — добавляемых к паролю перед хэшированием и отбрасываемых перед сравнением) значительно повышает безопасность хэшированных паролей, и, если у Вас нет веских причин к обратному, нужно всегда использовать форму того или иного алгоритма хэширования с солью . Нужно также использовать ACL для предоставления доступа к паролям только определённому кругу авторизованных пользователей. Например, подразумевая, что пароли хранятся в атрибуте userPassword , следующий ACL будет разрешать доступ к данному атрибуту только владельцу записи и определённой группе пользователей (admin):

# Форма OLC (cn=config) olcAccess: to attrs=userpassword by self write by anonymous auth by group.exact="cn=admin,ou=groups,dc=example,dc=com" write by * none # Формат slapd.conf access to attrs=userpassword by self write by anonymous auth by group.exact="cn=admin,ou=groups,dc=example,dc=com" write by * none

Если требуется защитить только пароли, то решением может стать использование SASL с каким-либо алгоритмом (например CRAM-MD5), обеспечивающим выполнение безопасного диалога подключения (с помощью общей секретной последовательности), во время которого пароли никогда не передаются в открытом виде (). Альтернативой может стать использование TLS/SSL (с или без SASL) или Kerberos 5. В этом случае можно использовать простые механизмы паролей, поскольку весь обмен по сети шифруется, и потому не может быть подвержен перехвату.

До сих пор мы обсуждали вопросы только простого получения доступа к данным. А как насчёт изменения или модификации этих данных? OpenLDAP предоставляет две возможности для ведения аудита: наложение auditlog (для получения дополнительной информации смотрите man-страницу slapo-auditlog) и наложение accesslog . У обоих есть функции журналирования изменений, вносимых в рабочее DIT, а у accesslog даже есть возможность помещать в журнал информацию о подключениях, доступах для чтения/поиска, а также предыдущее содержимое записей или атрибутов.

Локальный доступ (2): Под локальным доступом подразумеваются любые события, происходящие непосредственно на LDAP-сервере или кластере серверов (либо посредством защищённого удалённого доступа к серверу с помощью, например, ssh). Наиболее очевидно, под эту категорию попадают манипуляции с конфигурационными файлами/директориями (2-1) и локально выполняемые команды (2-2).

Конфигурационные файлы (2-1): Здесь мы должны рассмотреть два компонента:

Владельцы и права: По умолчанию, современные системы LDAP работают от имени учетных записей пользователя/группы с ограниченными привилегиями (обычно ldap:ldap). OpenLDAP загружается с правами root (чтобы открыть привилегированные порты), а затем очень быстро переходит к работе со своими нормальными (низкими) рабочими привилегиями. При использовании OLC (cn=config) OpenLDAP требует, чтобы у содержимого конфигурационной директории были права как минимум 0750 для учётной записи, от имени которой он будет работать (обычно ldap:ldap), однако самостоятельно соответствующие привилегии он не выставляет. Это поведение отличается от работы с конфигурационным файлом slapd.conf, которому автоматически назначаются права 0600.

Пароли: Пароли, встречающиеся в директориях slapd.d (при использовании OLC (cn=config)) и конфигурационном файле (slapd.conf), такие как olcRootPw/rootpw , относятся к категории особо конфиденциальных. Лучше вообще полностью удалить и olcRootDn/rootdn , и olcRootPw/rootpw после того, как DIT было запущено в эксплуатацию. Ну и, конечно, все пароли следует хранить в хэшированной форме для предотвращения случайной компрометации (это должно оговариваться на уровне политики безопасности).

Команды (2-2): Исторически LDAP администрировался через локальный интерфейс, в основном из командной строки. Предполагалось, что локальный (внутрисерверный) трафик не подвержен отслеживанию, и потому даже применение простых паролей в открытом виде считалось адекватной мерой защиты для большинства административных сервисов. Однако, как отмечалось выше, увеличение количества реализаций каталогов с конфигурацией времени исполнения (OLC, cn=config) и мониторингом (cn=monitor) может означать, что удалённые LDAP-браузеры становятся нормой в вопросах администрирования LDAP-систем. В этом случае доступ к указанным сервисам порождает передачу по сети информации высокой степени важности, которую необходимо защищать с помощью специальных технологий обеспечения безопасности данных, таких как TLS/SSL.

Наконец, поскольку при конфигурации времени исполнения все настройки хранятся в DIT (cn=config), стоит рассмотреть использование мощных возможностей наложения accesslog — инструмента генерации журнала для аудита изменений, вносимых в данное DIT.

DIT (3): Безопасность DIT определяется моделью безопасности LDAP и реализуется исключительно при помощи olcAccess/access to Права должны ограничиваться насколько это возможно более строго, и ACL должны тестироваться с помощью slapacl после каждого изменения.

Репликация (1-3): Даже если обычный клиентский доступ к LDAP-системе не требует серьёзных мер безопасности, иная ситуация может быть при репликации того же DIT. Во время цикла репликации на том или ином этапе все данные в DIT (пользовательские и операционные атрибуты) будут передаваться по сети. Вероятно, часть этой информации будет весьма важной. Сетевое взаимодействие при репликации заслуживает отдельного рассмотрения. Вы можете настроить смешанное соединение TLS/SSL и другого защищённого (или даже незащищённого) типа к одному серверу (смотрите примеры конфигурации смешанного доступа TLS/SSL и SASL ).

Настройка SASL в OpenLDAP

Мы закончим этот раздел уже совсем скоро (one day real soon now ™)

Настройка SASL TLS/SSL в OpenLDAP

В руководстве администратора OpenLDAP утверждается, что при использовании TLS с механизмом EXTERNAL SASL и клиенту, и серверу необходимо иметь действительный сертификат X.509. Если это правда, то мы получаем излишне сложную конфигурацию, а уровень безопасности повышается незначительно, и потому в большинстве случаев её использование представляется сомнительным (но есть заметные исключения, такие как репликация). В настоящее время подробно обсуждать это мы не будем.

Настройка TLS/SSL в OpenLDAP

Обзор

TLS (Transport Level Security) — это просто название стандартизированной IETF версии Secure Sockets Layer (SSL) от Netscape. Практически нет никаких различий между SSL(v3) и TLS(v1), и в этой документации данные термины считаются синонимами. TLS/SSL поддерживается OpenLDAP начиная с версии 2.1.

Обычно для работы TLS/SSL требуется сертификат X.509 (более известный как сертификат SSL), который можно приобрести в коммерческом центре сертификации или удостоверяющем центре (Certificate Authority, CA), либо это может быть самоподписанный сертификат. В этой документации дано пошаговое руководство по созданию самоподписанных сертификатов, а также, в случае необходимости, приводятся дополнительные замечания по использованию коммерческих сертификатов.

Примечания:

cn=config: скоро будет.

Ожидаем подключения только для LDAPS URL: аргумента -h при запуске slapd. По умолчанию данное значение не задаётся, что (обычно) соответствует -h ldap:///. По требованиям данной конфигурации мы должны разрешить только операции ldaps, поэтому при запуске slapd должна использоваться команда:

Slapd -h ldaps:/// -u ldap -g ldap

slapd_flags="ldaps:///" .

Если Вы переживаете о конфигурации фаервола, то LDAPS может быть настроен на использование порта 389 (LDAPS — это схема URL, говорящая о том, что будет использоваться TLS, а не о том, какой будет использоваться порт). В этом случае команда запуска будет такая:

Slapd -h ldaps://:389/ -u ldap -g ldap # при подключении ldaps URL должны быть в форме: ldaps://ldap.server.name:389

Директивы disallow, require и security: Ожидание подключений только на порту (портах) LDAPS приводит к принудительному использованию TLS/SSL при всех соединениях. Никакие другие типы соединений не будут приниматься в данной конфигурации сервера. Чтобы обязать пользователей проходить LDAP-аутентификацию, используется директива require bind , а для предотвращения анонимных подсоединений используется директива disallow bind_anon . Таким образом, чтобы получить какой-либо доступ к DIT, при любом подключении должна выполняться операция подсоединения (bind), и это подсоединение не может быть анонимным. Если указать только директиву security simple_bind=128 , это не приведёт к обеспечению требуемого уровня защиты. Данная директива просто говорит: если выполняется простое подсоединение (simple bind), то должно использоваться TLS/SSL. Она не требует, чтобы подсоединение выполнялось обязательно. Единственная цель использования security simple_bind=128 в данной конфигурации — определить минимальное значение SSF. Если это не нужно, данную директиву можно не указывать.
Доступ к rootDSE: Побочный эффект данной политики — запрет анонимного доступа к rootDSE , что, как уже отмечалось, может быть вполне оправдано для защищённых серверов.
Директивы ACL: В данной конфигурации не предусмотрено дополнительных мер безопасности, основанных на применении ACL — безопасность сервера полностью обеспечивается глобальными директивами конфигурации и ограничением подключений только на LDAPS портах. ACL может использоваться для установления необходимого разграничения доступа на основании учётных данных пользователей.

Настройка клиентов: Из требования, что сервер LDAP будет обслуживать только соединения TLS, следует, что все клиенты при подключении должны использовать URL со схемой LDAPS и выполнять проверку сертификата X.509 сервера, для чего требуется доступ к CA (корневому) сертификату. В нашем контексте под клиентами подразумеваются утилиты и инструменты ldap , а также серверы LDAP, на которых выполняется сервис репликации с использованием syncrepl . Очевидно, что, поскольку утилиты и инструменты ldap являются клиентами, они получают свои настройки из файла ldap.conf . Возможно менее очевидно, что LDAP-серверы, на которых выполняется сервис репликации, также являются TLS-клиентами, и потому также получают информацию по CA (корневым) сертификатам из ldap.conf. Конфигурация ldap.conf:

# скопируйте сертификат, сгенерированный на шаге 1, # в подходящее место на клиентской системе # подразумевается: /certs/ldapscert.pem # добавьте в ldap.conf TLS_CACERT /certs/ldapscert.pem

Конфигурация LDAP-сервера, на котором запущена реплика:

# slapd.conf # раздел глобальных настроек... # Безопасность - раздел TLS # нет никаких настроек # реплицируемое DIT database bdb suffix "d=example,dc=com" ... # настройки потребителя репликации syncrepl rid=000 type=RefreshandPersist provider=ldaps://ldap-master.example.com bindmethod=simple searchbase="dc=example,dc=com" retry="5 3 300 +" attrs="*,+" binddn="...." credentials=.... ...

Примечания:

CA (корневой) сертификат, используемый в примере потребителем syncrepl (и определяемый директивой TLS_CACERT в ldap.conf), является тем же самым, что используется и в качестве сертификата сервера поставщиком главного DIT. Это следствие применения метода с единственным сертификатом, который мы использовали для генерации данного сертификата: он функционирует сразу и как сертификат сервера, и как сертификат CA. При использовании других методов генерации самоподписанных сертификатов сертификат сервера и сертификат CA могут быть различными, и, конечно, они всегда различны при использовании коммерческих сертификатов.

Если, как обсуждалось выше, сервис ldaps обслуживается на порту 389 (например, для устранения вопросов блокировки трафика фаерволом), то определение syncrepl будет использовать расширенный формат URL с указанием порта:
Syncrepl ... provider=ldaps://ldap-master.example.com:389 ...

LDAP-серверы в качестве TLS-клиентов: Когда сервер LDAP выступает в качестве потребителя репликации syncrepl, он выступает в роли TLS-клиента, и потому ему требуется осуществлять проверку подлинности серверного сертификата с помощью CA (корневого) сертификата, которым он подписан. Поскольку данный сервер выступает в роли TLS-клиента, он будет использовать директивы TLS (и, соответственно, файлы сертификатов TLS), определяемые для клиентов LDAP — в частности, он будет использовать директиву TLS_CACERT в ldap.conf. Клиенту TLS требуется сгенерировать сообщение обмена ключами (key-exchange message), зашифрованное с помощью открытого ключа (public key) сервера, который извлекается из посылаемого сервером сертификата X.509. Также клиент TLS при первоначальной установке соединения по протоколу TLS на этапе ClientHello посылает список разрешенных наборов шифров, который контролируется директивой настройки клиента TLS TLS_CIPHER_SUITE (по умолчанию посылаются все возможные наборы шифров (ALL), что эквивалентно команде openssl ciphers -v ALL ). Перед прочтением следующего предложения сделайте глубокий вдох. Если сервер LDAP, являющийся потребителем репликации syncrepl и потому клиентом TLS, также предоставляет доступ к другому DIT (например, к cn=config) и при этом подразумевается, что для контроля этого доступа также необходима поддержка TLS, то он одновременно будет сервером TLS и для него требуется задать все директивы сервера TLS, которые определялись выше на шаге 2 и 3.

Настройка смешанного доступа TLS/SSL в OpenLDAP

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

Конфигурация — кто-то использует TLS, кто-то — нет

В данном случае выдвигается требование, что некоторые пользователи будут использовать TLS, а другие — нет. Например, политика может быть следующей:

Разрешён анонимный доступ (и незащищённый обмен данными) к ограниченному набору общедоступных записей LDAP.
Пользователям, прошедшим LDAP-аутентификацию (простое подключение с незащищённым обменом данными) разрешён доступ на чтение к общедоступным записям LDAP, плюс ограниченные права на обновление только той записи, владельцем которой является данный пользователь.
Пользователи с привилегиями на обновление более одной собственной записи должны использовать TLS и проходить аутентификацию (подразумевается, что все они члены группы admins).
Все потребители репликации должны использовать TLS/SSL.
При удалённом доступе к cn=config должен использоваться TLS/SSL.

Данное решение требует применения ACL и директив настройки сервера, как показано ниже:

Генерация сертификатов LDAP-сервера и CA: На данном этапе будет сгенерирован самоподписанный сертификат — если будет использоваться коммерческий сертификат X.509 (SSL), данный процесс не требуется и может быть полностью пропущен. Для генерации единого сертификата X.509, который может применяться и для проверки подлинности сервера, и в качестве CA (корневого) сертификата для клиента, используется простой метод в одну команду. Данный метод детально (со всеми диалогами) документирован . Последовательность команд:

# создаём новые директории (опционально) mkdir /certs mkdir /certs/keys cd /certs # создаём сертификат сервера/CA и закрытый ключ без парольной фразы # действительный в течение 10 лет, использующий текущие рекомендации RSA по размеру ключа # RSA используется в качестве протокола обмена ключами openssl req -x509 -nodes -days 3650 -newkey rsa:2048 -keyout keys/ldapskey.pem -out ldapscert.pem # сертификат может использоваться в качестве сертификата сервера или сертификата CA # помещаем сертификат в: /certs/ldapscert.pem # помещаем закрытый ключ в: /certs/keys/ldapskey.pem # устанавливаем права доступа chown -R ldap:ldap /certs/* chmod 0400 keys/ldapskey.pem

Примечания:

Полное объяснение параметров команды openssl смотрите .

У файлов ключей обычно есть парольная фраза (пароль) для защиты конфиденциальных данных. Если сертификат генерируется для сервера, подобная парольная фраза никогда не используется (её генерация подавляется аргументом -nodes).

В зависимости от требований, предъявляемых к сертификату, могут использоваться другие методы генерации самоподписанных сертификатов, описанные .

Добавление директив TLS и ACL в slapd.conf: (замечания по cn=config смотрите в конце раздела). Необходимые директивы TLS добавляются в раздел глобальных настроек:

# slapd.conf # раздел глобальных настроек... # Безопасность - раздел TLS TLSCertificateFile /certs/ldapscert.pem TLSCertificateKeyFile /certs/keys/ldapskey.pem TLSCipherSuite TLSv1+RSA:!NULL # значение следующей директивы установлено так по умолчанию, # однако мы приводим её здесь для наглядности TLSVerifyClient never ... # пользовательское DIT database bdb suffix "d=example,dc=com" # нет директив rootdn и rootpw # смотрите примечания по обеспечению безопасности доступа от имени rootdn ... # ACL # ACL1 - доступ для потребителя репликации # (подразумевается подсоединение от имени cn=replica,dc=example,dc=com) # потребителю, использующему TLS, разрешён доступ на чтение ко всему DIT # все остальные переходят к ACL2 (break) access to * by dn.exact="cn=replica,dc=example,dc=com" tls_ssf=128 read by * break # ACL2 - доступ к атрибуту userpassword # анонимные пользователи могут только проходить аутентификацию # пользователи, прошедшие аутентификацию, могут модифицировать свои собственные пароли (self) # члены группы admins, использующие TLS, могут модифицировать пароли access to attrs=userPassword by self write by anonymous auth by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write # ACL3 # ограниченный анонимный доступ только на чтение к поддереву public # любые пользователи, прошедшие аутентификацию, могут модифицировать свои # собственные записи (self) в пределах поддерева # члены группы admins, использующие TLS, имеют право на запись во всём поддереве public access to dn.subtree="ou=public,dc=example,dc=com" by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write by self write by anonymous read by users read # ACL4 # члены группы admins, использующие TLS, имеют право на запись в остальном DIT access to * by by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 write # последний ACL4 слишком прямолинеен - если требуются дополнительные правила, # его нужно заменить приведённым ниже, который будет отфильтровывать всех пользователей, # не использующих TLS. В данном случае break означает, что если пользователь использует TLS, # он переходит к следующему ACL, в противном случае - обработка останавливается. # ACL4 access to * by group.exact "cn=admins,ou=groups,dc=example,dc=com" tls_ssf=128 break # ACL5 etc. access .... # поставщик репликации overlay syncprov # cn=config DIT database config rootdn "cn=admin,cn=config" rootpw {SSHA} hfkhfhfldkhlkhh # SSF больший или равный 128 используется для обеспечения безопасного доступа к cn=config security simple_bind=128

Примечания:

Дополнительная информация по TLSCipherSuite . Используемые параметры исключают применение NULL-шифров (без шифрования). TLSv1 охватывает SSLv3. Разрешены EXPORT-шифры — допускаются международные подключения. Если вопросы производительности и нагрузки стоят остро, лучше явно задать список шифров с приемлемыми характеристиками производительности и загрузки системы, чем оставлять возможность произвольного выбора шифра во время переговоров TLS/SSL.

Конфигурация DSA: скоро будет.

cn=config: скоро будет.

Примечания по ACL:
1. ACL1: Данный ACL, который можно с тем же успехом поместить в раздел глобальных настроек, разработан с целью вычленить на раннем этапе подключения потребителей репликации (DN cn=replica,dc=example,dc=com должен присутствовать в DIT с соответствующим паролем). by dn.exact="cn=replica,dc=example,dc=com" tls_ssf=128 read содержит два условия, которые работают (хотя явно не документированы), и совпадения по которым будут найдены в том случае, если потребитель успешно прошёл аутентификацию И использовал SSF (TLS) не ниже 128. Для того чтобы потребитель репликации (да и все остальные) смог пройти аутентификацию (или просто получить доступ к DIT), необходимо наличие условия by * break , позволяющего перейти к ACL2 и продолжить анализ подключения.
  
  ACL2: Позволяет любому пользователю, прошедшему аутентификацию, модифицировать свой пароль. Анонимный доступ предоставляется в целях аутентификации (auth ). Любой член группы cn=admins,ou=groups,dc=example,dc=com, использующий при подключении TLS, может осуществлять изменения любого пароля.
  
  ACL3: В указанном порядке — любому члену группы cn=admins,ou=groups,dc=example,dc=com, использующему при подключении TLS, разрешено производить запись в любой атрибут любой записи поддерева public базы данных. Анонимным пользователям предоставляется доступ на чтение к поддереву public DIT (за исключением атрибутов userPassword). Пользователю, прошедшему аутентификацию, разрешено изменять любую часть своей записи. Наконец, пользователю, прошедшему аутентификацию (подключающемуся с использованием или без использования TLS), разрешён доступ только для чтения к поддереву public, за исключением атрибутов userPassword (а также за исключением своих собственных записей, контроль доступа к которым был указан в условии self).
  
  ACL4: Только членам группы cn=admins,ou=groups,dc=example,dc=com, использующим при подключении TLS, разрешён доступ на осуществление записи во все остальные части DIT. Всем остальным пользователям запрещён любой доступ (неявное условие by * none ).

Ожидаем подключения для LDAPS и LDAP URL: Управление портами, на которых ожидаются подключения, осуществляется с помощью аргумента -h при запуске slapd. По умолчанию данное значение не задаётся, что (обычно) соответствует -h ldap:///. По требованиям данной конфигурации мы должны разрешить как операции ldap , так и ldaps , поэтому при запуске slapd должна использоваться команда:

Slapd -h "ldap:/// ldaps:///" -u ldap -g ldap

Чтобы это выполнялось автоматически, необходимо подправить сценарии запуска в linux (/etc/rc.d/init.d/slapd), а в BSD /etc/rc.conf должен содержать такую строку: slapd_flags="ldap:/// ldaps:///" .

Безопасность доступа от имени rootdn: После того, как DIT было первоначально загружено, какие функции выполняет rootdn ? Во всех штатных случаях привилегии типа rootdn для DIT могут быть предоставлены какому-либо конкретному пользователю (назовём его псевдо-суперпользователь ) с помощью ACL, и потому директиву rootdn можно смело удалять. В хорошо продуманной системе контроля можно предоставить новому псевдо-суперпользователю необходимые полномочия с помощью стандартных ACL — собственно, для этого они и предназначаются. Единственный подводный камень данного подхода — то, что ошибка в ACL может привести к ограничению необходимых полномочий. В худшем случае, rootdn может быть временно восстановлен, а потом удалён вновь, когда проблема будет решена. Лучшим решением обеспечения безопасности доступа от имени rootdn к обычному DIT будет удаление самого rootdn . И точка. Как в приведённой выше конфигурации.

В тех случаях, когда rootdn является единственным методом доступа, таких как cn=config в приведённом выше примере, для принудительного включения механизмов защиты в конкретном разделе database используется директива security simple_bind=128 .

Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни, чтобы написать нам , вебмастеру или в службу поддержки . Оставшийся день Вы проведёте с чувством удовлетворения.

Эта статья - кратчайшее введение в 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. Эта модель данных такова:

В каталоге хранятся записи (entry).
Запись - это коллекция атрибутов (attribute), имеющая уникальное имя (Distinguished Name, DN).
Каждый атрибут имеет тип (type) и одно или несколько значений. Синтаксис значений зависит от типа.
Атрибут objectClass позволяет контролировать, какие атрибуты обязательны и какие допустимы в записи. Таким образом, записи, как и атрибуты, имеют тип (object class).
Записи в каталоге организованы иерархически в виде дерева.
Определения типов записей (object classes) и типов атрибутов сами являются записями в каталоге, в специальном поддереве, известном как schema.

Запустим 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 (область поиска) показывает область поиска, одно из:

одна запись, идентифицированная base DN
записи уровнем ниже base DN, т.е. дочерние, но не внучатые
поддерево с корнем base DN, включая корень

filter (фильтр) задает условие отбора записей

Например, поиск по условию

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, или Lightweight Directory Access Protocol – это протокол для управления информацией из централизованного места за счет использования иерархии файлов и каталогов. Его работа чем-то похожа на реляционные базы данных.

LDAP позволяет систематизировать и хранить любого рода информацию. Этот протокол часто используется для централизованной аутентификации.

Данное руководство покажет, как установить и настроить сервер OpenLDAP на выделенный сервер Ubuntu 12.04, а также создать все необходимые группы и пользователей.

Примечание : О настройке LDAP для авторизации можно прочесть в этой серии.

Установка LDAP

Сервер OpenLDAP можно загрузить из стандартных репозиториев Ubuntu. Искомый пакет называется slapd. Кроме того, нужно установить несколько дополнительных утилит.

sudo apt-get update
sudo apt-get install slapd ldap-utils

Система предложит выбрать и подтвердить пароль администратора LDAP.

Настройка slapd

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

sudo dpkg-reconfigure slapd

Система задаст ряд вопросов, чтобы перенастроить пакет.

Omit OpenLDAP server configuration? No
DNS domain name? (Это создаст базовую структуру путей к каталогам; чтобы понять, как это работает, читайте подсказку программы. В целом, общепринятых правил для этой настройки нет. Если у вас есть домен, укажите его здесь. В руководстве используется тестовый домен test.com).
Organization name? (Укажите любое имя; в руководстве – example)
Administrator password? (Укажите пароль, выбранный во время установки пакета, или установите другой пароль).
Database backend to use? HDB
Remove the database when slapd is purged? No
Move old database? Yes
Allow LDAPv2 protocol? No

Установка PHPldapadmin

Для управления LDAP понадобится веб-интерфейс PHPldapadmin. Его тоже можно скачать из репозиториев Ubuntu.

sudo apt-get install phpldapadmin

Эта команда установит необходимый пакет и его PHP-зависимости.

Настройка PHPldapadmin

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

Откройте конфигурации с правами 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: ,

Страница Аутентификация LDAP служит для настройки сервера LDAP с целью аутентификации пользователей устройств (многофункциональное периферийное устройство, цифровой копир или устройство цифровой отправки). Если аутентификация LDAP выбрана в качестве Способа регистрации для одного или нескольких Функций устройств на странице Диспетчер аутентификации , пользователь должен ввести действительные имя пользователя и пароль для получения доступа к этим функциям.

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

На странице Аутентификация LDAP можно задать параметры доступа к серверу LDAP и поиска информации пользователя. Обратите внимание, что данную страницу можно использовать только в том случае, если LDAP выбран в качестве Способа регистрации на странице Диспетчер аутентификации .

Подключение к серверу LDAP

Способ привязки сервера LDAP

Параметр Способ привязки сервера LDAP определяет, как устройство будет осуществлять подключение к серверу LDAP. Обратитесь к администратору сервера LDAP, чтобы определить наиболее оптимальный для вас способ.

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

Сервер LDAP

Параметр Сервер LDAP представляет собой имя хоста или IP-адрес сервера LDAP, которое будет использоваться для аутентификации пользователей устройства. В случае использования SSL введенное здесь имя или адрес должны соответствовать имени в сертификате, направляемом сервером.

В этом поле можно указать несколько серверов, разделяя их адреса знаком вертикальной полосы ("|", ASCII 0x7c). Эту функцию можно, например, использовать для указания основного и резервного серверов. Сетевой интерфейс поддерживает поддерживает только один сертификат CA, поэтому все серверы LDAP в этом списке должны использовать один сертификат CA.

Порт

Параметр Порт определяет номер порта TCP/IP, на котором сервер обрабатывает запросы LDAP. Обычно это порт 389 для Простой привязки или 636 для привязок Простой через SSL .

Имя пользователя и пароль для поиска

В аутентификации LDAP используется два способа аутентификации пользователя.

Первый способ называется ; он предполагает “конструирование” 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.

Имя и пароль пользователя устройства

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

Префикс привязки

Параметр Префикс привязки - это атрибут LDAP, используемый для построения DN пользователя для целей аутентификации. Этот префикс комбинируется с именем пользователя, введенным на панели управления, образуя относительное отличительное имя (RDN). Обычно используется префикс "CN" (для общего имени) или "UID" (для идентификатора пользователя).

Использование имени пользователя и пароля администратора

DN администратора

Это DN (отличительное имя) пользователя, имеющего права чтения каталога LDAP. Введенная здесь учетная запись может не иметь административного доступа к каталогу. Прав чтения достаточно.

Пароль администратора

Пароль пользователя, чей DN введен в поле "DN администратора".

Поиск по базе данных LDAP

Привязка и начало поиска

При выборе способа Имя и пароль пользователя устройства значение Привязка и начало поиска используется на обоих этапах аутентификации. На этапе проверки имени пользователя и пароля это значение комбинируется с 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, появляется сообщение об успешном выполнении проверки. В противном случае появится сообщение об ошибке с указанием на отрицательный результат аутентификации.

Directory Information Base - DIB ). Информация включает имя объекта , а также различные атрибуты, характеризующие этот объект . Данные рекомендации носят название стандарта Х.500.

Для доступа к объектам этой распределенной базы данных был разработан Протокол Доступа к Каталогу ( Directory Access Protocol – DAP ).

LDAP ( Lightweight Directory Access Protocol ) предоставляет большинство возможностей DAP при существенно меньшей стоимости реализации. Например, удалены избыточные и редко используемые операции . LDAP , в отличие от Х.500, использует стек ТСР, а не OSI .

Однако не существует взаимно однозначного соответствия между операциями протокола LDAP и операциями протокола DAP стандарта Х.500.

LDAP - это протокол, который используется для доступа к информации, хранящейся на распределенных в сети серверах.

Эта информация представляет собой данные, хранящиеся в атрибутах. При этом предполагается, что такие данные чаще читаются, чем модифицируются. LDAP основан на клиент-серверной модели взаимодействия.

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

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

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

Запись идентифицируется глобально уникальным именем (Distinguished Name – DN ) – подобно имени домена в структуре DNS .

Каталог является специализированной базой данных, которая может использоваться в повседневной жизни – телефонная книга, программа передач и т.п. Предполагается, что данные Каталога достаточно статичны. Классическим примером подобной специализированной базы данных является сервис DNS .

Преимущества LDAP

Основные причины роста популярности LDAP связаны с тем, что:

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

Сравнение LDAP и базы данных

Сравним два наиболее популярных на сегодня способа хранения информации, реляционные базы данных и серверы LDAP, по следующим характеристикам:

Соотношение чтение-запись – LDAP, в отличие от реляционных баз данных, оптимизирован для чтения.
Расширяемость – схемы LDAP легче изменить в процессе функционирования, чем схемы баз данных.
Распределенность – данные LDAP могут располагаться на не-скольких серверах, поиск на которых может осуществляться с использованием одной команды. В результате можно создавать оптимально расположенные конфигурации серверов LDAP, в зависимости от того, где требуется та или иная информация, одновременно обеспечивая возможность поиска всей информации, хранящейся на всех серверах LDAP. Тем самым достигается более высокая степень распределенности по сравнению с реляционными базами данных.
Репликация – данные LDAP могут храниться на нескольких серверах, при этом существует возможность использования различных способов синхронизации информации.
Применение данных – LDAP разработан для эффективного использования данных, хранящихся в Каталоге, разными приложениями, базы данных разрабатываются для одного приложения.
Сложность взаимосвязей между объектами – объекты баз данных имеют более сложные взаимосвязи, чем записи LDAP.
Транзакции – в LDAP транзакции проще, обычно изменяется одна запись, транзакции в базах данных более сложные.
Тип хранимой информации – LDAP хранит информацию в атрибутах.
Способ именования – LDAP является иерархической структурой данных. Имя объекта представляет собой путь к этому объекту в дереве иерархии, аналогично путям к файлам в обычных файловых системах.
Схемы – схемы реляционных баз данных полностью определяются разработчиком соответствующей базы данных, LDAP имеет стандартные схемы, включая схему Ядра (Core), общую для любого Каталога. Этим достигается большая интеропера-бельность по сравнению с базами данных.
Стандарты – использование стандартных схем хранения информации и стандартного протокола доступа является преимуществом LDAP по сравнению с базами данных, так как в этом случае клиенты LDAP могут общаться с любым сервером LDAP, а клиенты баз данных могут взаимодействовать только с базой данных, для которой они разработаны.
Возможность отката при неудачных операциях – реляционные базы данных имеют более гибкие возможности отката, следовательно, они больше подходят для модификации информации, чем LDAP. Для динамичных объектов возможностей LDAP может быть недостаточно.

Принципы развертывания серверов LDAP

При развертывании серверов LDAP необходимо выполнить следующие задачи:

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