Что такое код ldap_connect


Содержание

Как включить доменное имя в этот код ldap_connect (php)

У меня есть приложение, которое использует этот блок кода для облегчения аутентификации LDAP. На странице входа в систему пользователи должны ввести в компанию \user.name — как я могу объединить часть «company \» с переменной usr в этом коде?

Все, что вам нужно сделать, включают «company \» часть в имени пользователя. Вы можете включить или User_CustomValidate(‘username’, ‘password’, ‘company’); подтверждение в домене компании: User_CustomValidate(‘username’, ‘password’, ‘company’); или установить значение по умолчанию для $domain в функции для обработки этого самостоятельно: function User_CustomVal ) <

ldap_connect function

The ldap_connect function establishes a connection with the server.

Syntax

Parameters

The session handle obtained from ldap_init.

A pointer to an LDAP_TIMEVAL structure that specifies the number of seconds to spend in an attempt to establish a connection before a timeout. If NULL, the function uses a default timeout value.

Return Value

If the function succeeds, LDAP_SUCCESS is returned.

If the function fails, an error code is returned. For more information, see Return Values.

Remarks

Although it is not required that a client call ldap_connect to establish a connection to the server, it is good programming practice to do so. If the connection does not exist, other functions, for example, ldap_bind_s, perform the call internally. However, if you have to troubleshoot this part of your application, establishing the connection prior to making the call to some other function, for example ldap_bind_s, will also separate the possible problems if the connection fails. Alternately, you can specify additional options on the connection block. For example, a client can call ldap_init to initialize a session, then call ldap_connect, with a non-NULL timeout parameter value, to connect to the server with a specified time-out.

If the call to ldap_connect succeeds, the client is connected to the LDAP server as an anonymous user. The session handle should be freed with a call to ldap_unbind when it is no longer required.

If the ldap_connect call fails, the session handle should be freed with a call to ldap_unbind when no longer required for error recovery.

MNorin.com

Блог про Linux, Bash и другие информационные технологии

LDAP: Установка и настройка LDAP-сервера

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

Установка OpenLDAP

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

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

Если вам нужна самая свежая версия OpenLDAP, то исходные коды можно скачать на официальном сайте.

Схемы LDAP

По умолчанию OpenLDAP включает уже готовые схемы. Схемы — это структуры, определяющие объекты, используемые в системе каталогов. Схемы включают в себя классы объектов, у каждого класса есть определенный набор атрибутов. Каждая запись может относиться к одному или нескольким классам и, соответственно, иметь те наборы атрибутов, которые включены в соответствующие классы. В терминологии LDAP классы так и называются — ObjectClass. Вот несколько классов объектов, которые можно использовать:

top
organization
organizationalUnit
person
inetOrgPerson

При создании объекта вы указываете, к каким классам он относится и, исходя из этого, можно задавать соответствующие атрибуты. Примеры чуть ниже. Файлы схем хранятся в директории /etc/ldap/slapd.d/cn=config/cn=schema. В них хранятся описания классов объектов и атрибутов. Для просмотра объектов, которые используются в данный момент, используется команда

Она выводит содержимое базы данных объектов.

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

Настройка OpenLDAP

После установки пакетов надо переконфигурировать сервер, задать свои данные. Первое, что мы сделаем — создадим свой домен «mydomain.com». Для этого выполним команду

Вы увидите такой экран:

Введем данные для нашего домена. У нас это будет «mydomain.com». Нажимаем OK.

Вводим название организации «mydomain». Нажимаем OK.

Вводим пароль администратора LDAP-сервера. Пароль желательно вводить сложный, это как-никак пароль администратора. Нажимаем ОК.

Повторяем пароль, нажимаем OK

Выбираем «HDB» для типа сервера, нажимаем ОК.

На вопрос удалять ли базу данных при вычистке slapd отвечаем утвердительно

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

На предложение включить старый протокол LDAPv2 отвечаем No/Нет

На этом первоначальная настройка завершена. Если сервис не стартовал, запускаем его вручную командой

Проверим, есть ли данные в базе:

Можно сразу проверить, правильно ли работает сервер OpenLDAP. Это можно сделать следующей командой:

После ввода команды будет запрошен пароль. Если вы не хотите вводить пароль в интерактивном режиме, вы можете использовать параметр -w:

Результат команды поиска будет выглядеть следующим образом:

Параметр «-b» определяет поисковую базу, то есть тот узел дерева объектов, с которого будет начинаться поиск.

Можно продолжать настройку

Создадим группу пользователей с названием «users» при помощи команды ldapmodify

Всё, начиная с «dn: » вводим руками точно так, как написано выше. После ввода строки описания («description: Domain Users») нажимаем Enter два раза. Если всё введено без ошибок, вы должны увидеть такое сообщение:

Нажимаем Ctrl+C для выхода

Теперь надо проверить, внесены ли данные:

Всё верно, и теперь можно внести первого пользователя. Сначала сгенерируем хэш пароля для пользователя.

Этот хэш нам понадобится при создании пользователя

Снова запускаем ldapmodify и создаем пользователя. По окончании ввода значений полей дважды нажимаем Enter

После ввода нажимаем Ctrl+C и выходим

Проверяем, есть ли запись с u >

Запись есть, отлично. Теперь надо проверить аутентификацию:

После ввода правильного пароля получаем запрошенную информацию

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

И задать для этой записи пароль. Эти две записи будут существовать в одно и то же время, поэтому вам нужно заранее подумать о том, какое поле вы будете использовать для аутентификации.

ldap_connect ведёт себя неожиданно

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

Мне потребовалось сделать авторизацию по LDAP. Читаем документацию.

Returns a positive LDAP link identifier on success, or FALSE on error.

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

Гугление мало помогло.

Как специалист по LDAP, и горе-специалист по php — перечитал 2 раза, так и не понял, что тебе не нравится.

Не нравится, что lpad_connect ведёт себя не так как в документации, и вместо FALSE в заведомо ошибочной ситуации возвращает ID ресурса.

можно же в исходниках php посмотреть, что там эта ldap_connect() у себя внутри творит

Returns a positive LDAP link identifier on success, or FALSE on error.

А следующее предложение прочитать?

Тебе ещё объяснить как пятилетнему?

When OpenLDAP 2.x.x is used, ldap_connect() will always return a resource as it does not actually connect but just initializes the connecting parameters. The actual connect happens with the next calls to ldap_* funcs, usually with ldap_bind().

When OpenLDAP 2.x.x is used, ldap_connect() will always return a resource as it does not actually connect but just initializes the connecting parameters. The actual connect happens with the next calls to ldap_* funcs, usually with ldap_bind().

Вся проблема в том, чтобы определить жив ли вообще LDAP-сервер до того, как станем передавать ему данные для авторизации тем же ldap_bind. Можно это сделать и общесетевыми функциями, но не очень хочется, особенно с учетом, что они позволят лишь понять принимает ли хост соединения по указанному порту. А вдруг там и не LDAP вовсе?

Returns a positive LDAP link identifier on success, or FALSE on error.

А вот это — ни в звезду ни в Красную Армию.

жив ли вообще LDAP-сервер до того, как станем передавать ему данные для авторизации тем же ldap_bind

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

А вот это — ни в звезду ни в Красную Армию.

А что не так? Функция возвращает false в случае ошибки.

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

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

А что не так? Функция возвращает false в случае ошибки.

Так в том то и дело, что FALSE оно не возвращает, даже если в качестве хоста указать заведомо несуществующий.

Поскольку соединения на этом этапе не происходит, это не ошибка) Можно попробовать сделать ldap_bind() анонимный и посмотреть ldap_errno().

Поскольку соединения на этом этапе не происходит

Забавный каламбур. При вызове функции connect, коннекта, собственно, и не происходит :-).

Это же Адъ и ПиздецЪ

Может вернуть, если ты в limits не уложился и новый ресурс нет возможности создать. Короче, в исходниках, как правильно сказали, больше инфы будет, когда эта тварь возвращает то, что нужно.

Предыстория.

Сразу оговорюсь, что я простой админ локал-хоста и в таких энтерпрайзных вещах, как сервера директорий ничего не понимал до сегодняшнего дня, так что статья из разряда «чайникам от чайника» — что и как понял, то и рассказываю. Энтерпрайзных задач тоже не стояло — пока просто сделать централизованную авторизацию сервисов, без всяких там ACL и прочих заморочек.
Конфигурированию OpenLDAP и прикручиванию к нему различных сервисов посвящено множество статей. Проблема в том, что большинство из них основной упор делают на то, что нужно сделать, некоторые уделяют внимание тому зачем это надо делать, но практически никто не говорит о том, почему надо делать именно так и как можно по-другому. Ну, по крайней мере, мне не удалось найти таких статей. В свете этого, я попробую пойти с обратной стороны — не буду много писать о том, что делать, а сконцентрируюсь на вопросах почему именно так делают.
Процесс настройки я разбил на три этапа — запуск OpenLDAP в базовой конфигурации с парой тестовых пользователей, организация ауторизации с авторегистрацией пользователей redmine из LDAP и доступ на чтение/запись в SVN. Излагать буду в том же порядке.

Итак, лдап — это сервис директорий. Директории — это дерево. Узлы дерева могут хранить произвольную информацию (текстовую). Информация эта представляется в виде пар ключ-значения, которые называются атрибутами. Админ волен строить дерево совершенно произвольным образом, исходя из своих потребностей. С другой стороны, если позволить в каждый узел пихать что угодно будет хаос. По-этому существуют схемы и классы. Классы описывают какие атрибуты может иметь объект и какие обязан, при этом объект может принадлежать к множеству классов, таким образом можно набирать нужный список атрибутов. Ну а схемы — это описания возможных атрибутов и классов. Существует несколько готовых схем, определённых в RFC или специфичных для конкретного LDAP-сервера.
Вот в общих чертах теория. Для практики я по-быстрому поднял FreeBSD 9.1 в виртуалбоке и поставил туда OpenLDAP. Почему именно его? В принципе, серверов, реализующих LDAP несколько, можно взять любой другой, просто этот наиболее распространённый.
Конфиг сервера хранится в файле slapd.conf, откуда инклудятся файлы схем. Помимо настроек, относящихся к серверу там находятся ACL, суффикс верхнего уровня и пароль рута в зашифрованном виде. Само дерево хранится в базе данных (по умолчанию предлагается BerkeleyDB, но можно использовать и другие бекенды). Физическое расположение базы зависит от бекенда, для bdb, например, задаётся опцией directory (что бы полностью очистить базу можно тупо удалить все файлы из этой директории).
Принцип именования узлов в чём-то близок к формированию имён в DNS, возможно по-этому суффикс принято делать из двух частей:
«dc=example,dc=org»
В принципе, здесь можно писать что угодно, хоть dc=vasia,dc=pupkin — никакой связи с именами DNS тут нет (хотя некоторые клиентские софтины и могут попытаться такую связь установить). Магическое dc — это сокращение от domain component.
Рутовый пользователь домена задаётся строчкой «cn= ,dc=example,dc=org» (cn — common name, имя объекта).

Илон Маск рекомендует:  Яндекс - крупнейшая поисковая система русскоязычного Интернета!

Как работать в базой данных? Так как оно не plain text, то в ручную править записи не получится. Нужно либо писать инструкции, что сделать, в файле ldif и применить эти инструкции командой ldapadd, либо пользоваться спецсофтом, типа ldapadmin, или ldapphpadmin. Для начала проще воспользоваться ldif’ами, а потом перейти на гуйню. Кстати, для работы из консоли есть забавные утилиты ldapvi (использует EDITOR для редактирования дерева) и shelldap (клиент в стиле шела).

Как я уже сказал, дерево можно стоить как угодно. Я решил пока создать две директории в корне — одну для юзеров и одну для групп. Скелет у меня получился такой

Здесь создаётся 4 объекта — корневая директория (не путать с rootdn который мы прописали в конфиге), две поддиректории и одна группа. DN — это имя директории (всегда пишется полностью). Самое интересное тут, конечно, это objectClass, а точнее, почему они именно такие. Зачем нужен top, честно сказать, сам толком не понял — некий абстрактный класс без атрибутов. А вот остальных могу попробовать объяснить. Дело в том, что в данном случае мы описываем некую компанию, в которой есть люди, разделённые на отделы (группы). Класс organization как раз и предназначен для описания всяких организаций. В принципе здесь спокойно можно этот класс и не вешать. Кроме того наш example по совместительству кусок доменного имени, а значит ему нужен атрибут dc для получения которого вешаем dcObject. Группы имеют тип organizationalUnit — это не совсем логично, но такова общепринятая практика. На самом деле, здесь подошёл бы любой класс, содержащий свойство ou. Ну или любой другой, просто название свойства было бы другим, что мало на что влияет. Последний абзац описывает группу разработчиков, в которую я буду добавлять тех, кто имеет доступ к SVN.
Ну и самое интересное — собственно учётные записи пользователей:

На самом деле классов тут сильно с избытком, для простой авторизации вполне достаточно было бы, например, shadowAccount, или даже person — главное, что бы было поле userPassword. Для хранения логина в никсовых соглашениях принято использовать поле uid, альтернативно в самбовой схеме для логина используют sAMAccountName.
Кроме обычных пользователей желательно держать специального служебного объекта, который имеет право на чтение информации о пользователях (кроме пароля). Я его создал таким образом:

Redmine

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

В ЛДАПе редмайн проводит авторизацию, но пользователь всё равно должен храниться в базе редмайна. Для того, что бы не заботиться о создании пользователей, предусмотрена галка авторегистрации (а что бы не заботиться об удалении есть плугин redmine_ldap_sync)
Можно заметить, что редмайн умеет брать из лдапа не только логин/пароль, но ещё и имя, фамилию и почту, которые потом использует для регистрации пользователя в своей базе. Именно для этого, кстати, понадобилось добавить класс inetOrgPerson.

Прикручивание SVN оказалось чуть менее тривиальной задачей, но в целом идея такая: заводим апач (обычно виртуал хост или локейшен), цепляем к нему svn по вебдав и ограничиваем доступ аутентификацией по LDAP. В принципе, можно обойтись без апача — сам svn тоже умеет авторизацию в лдапе, но настраивается чуть хуже.
Вот такой конфиг у меня получился:

Linux.yaroslavl.ru

Введение в LDAP

LDAP (Lightweight Directory Access Protocol) — Протокол Доступа к Директориям (каталогам), является протоколом, используемым для доступа к «Серверам Каталогов». Директория является специальной разновидностью базы данных, которая хранит информацию используя древовидную структуру.

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

Для ссылки на файл в подкаталоге на жестком диске используется нечто подобное

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

Эквивалентом полностью определенной ссылки в LDAP является «distinguished name» (различаемое имя), обозначаемое просто как «dn». Примером dn может быть:

cn=John Smith,ou=Accounts,o=My Company,c=US

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

country = US
organization = My Company
organizationalUnit = Accounts
commonName = John Smith

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

Поиск информации для всех записей, где фамилия начинается с «S», в сервере директории, вывод на дисплей и извлечение с именем и email-адресом.

Пример 1. Пример поиска в LDAP

Использование PHP LDAP вызовов

Вам потребуется установить и скомпилировать библиотеки LDAP-клиента или из пакета University of Michigan ldap-3.3, или из Netscape Directory SDK. Вам также потребуется перекомпилировать PHP с поддержкой LDAP для того чтобы применение PHP LDAP вызовов стало доступным.

Прежде чем использовать LDAP вызовы, необходимо знать ..

  • Имя или адрес сервера директории, который вы будете использовать
  • «Базовый dn» сервера (часть «мирового» каталога на данном сервере, которая может быть «o=My Company,c=US»)
  • Нужен ли пароль для доступа к данному серверу (многие серверы обеспечивают доступ для чтения для «anonymous связей» но требуют пароля для чего-либо еще)

Типичная последовательность LDAP-вызовов, которую вы можете применять в приложениях, представлена в следующем щаблоне:

ldap_connect() // установка соединения с сервером
|
ldap_bind() // анонимный или идентифицируемый «вход»
|
действия подобные поиску или обновлению каталога
с выводом результата

Дополнительная информация

Netscape SDK одержит полезное Руководство Программиста в .html формате.

ldap_add

ldap_add — добавляет записи в LDAP каталог

Описание

int ldap_add (целочисленный link_identifier, строковое dn, массив записи);

возвращает true при успехе и false при ошибке.

Функция ldap_add() используется для добавления записей в LDAP каталог. DN добавляемой записи выражается посредством dn. Массив записи определяет информацию о записи. Значения записей индексируются посредством индивидуальных атрибутов. В случае множественных значений для атрибута, они индексируются целыми числами начиная с 0.

запись[«атрибут1»] = значение
запись[«атрибут2»][0] = значение1
запись[«атрибут2»][1] = значение2

Пример 1. Полный прример с идентифицируемой связью

ldap_bind

ldap_bind — связь с LDAP каталогом

Описание

int ldap_bind (целое link_identifier, строковое bind_rdn, строковое bind_password);

Связь с LDAP каталогом с определенным RDN и паролем. Возвращает true при успехе и false при ошибке.

ldap_bind() осуществляет операцию связи с каталогом. bind_rdn и bind_password используются факультативно. Если не определено, применяется связь anonymous.

ldap_close

ldap_close — закрывает связь с LDAP сервером

Описание

int ldap_close (целое link_identifier);

Возвращает true при успехе, false при ошибке.

ldap_close() закрывает связь с LDAP сервером, которая ассоциировалась с определенным link_identifier.

Этот вызов внутренне идентичен ldap_unbind(). LDAP API использует вызов ldap_unbind(), поэтому возможно он предпочтительнее вызова ldap_close().

ldap_connect

ldap_connect — соединение с LDAP сервером

Описание

int ldap_connect (строковое hostname, целое port);

Возвращает положительный LDAP идентификатор связи при успехе, false при ошибке.

ldap_connect() устанавливает соединение с LDAP сервером по определенным hostname и port. Оба аргумента факультативные. Если аргументы не определены, то будет возвращен идентефикатор уже открытого соединения. Если определено только hostname, то по умолчанию используется порт 389.

ldap_count_entries

ldap_count_entries — подсчет количества записей при поиске

Описание

int ldap_count_entries (целое link_identifier, целое result_identifier);

Возвращает количество записей в результате или false при ошибке.

ldap_count_entries() возвращает количество записей хранимых в результате от предыдущей операции поиска. result_identifier идентифицирует внутренний ldap результат.

ldap_delete

ldap_delete — удаляет запись из каталога

Описание

int ldap_delete (целое link_identifier, строковое dn);

Возвращает true при успехе и false при ошибке.

ldap_delete() удаляет отдельную запись из LDAP каталога, определенную по dn.

ldap_dn2ufn

ldap_dn2ufn — конвертирует DN в User Friendly Naming формат

Описание

string ldap_dn2ufn (строковое dn);

ldap_dn2ufn() преобразует DN в более дружественную для пользователя форму, удаляя имена типа.

ldap_explode_dn

ldap_explode_dn — разбивает DN на составные части

Описание

array ldap_explode_dn (строковое dn, целое with_attrib);

ldap_explode_dn() разбивает DN возвращаемое по ldap_get_dn() на составные части. Каждая часть известна как Relative Distinguished Name, или RDN. ldap_explode_dn() возвращает массив всех компонентов. with_attrib используется для запроса, возвращать ли RDN толъко со значениями или также с их атрибутами. Чтобы получить RDN-части с атрибутами (т.е. в формате атрибут=значение) установите with_attrib в 1, чтобы получить только значения установите его в 0.

ldap_first_attribute

ldap_first_attribute — возвращает первый атрибут

Описание

string ldap_first_attribute (целое link_identifier, целое result_entry_identifier, целое ber_identifier);

Возвращает первый атрибут в записи при успехе и false при ошибке.

Подобно чтению записей, атрибуты также читаются один за другим из отдельной записи. ldap_first_attribute() возвращает первый атрибут в записи, отмеченной идентификатором записи. Оставшиеся атрибуты ищутся последовательными вызовами ldap_next_attribute(). ber_ >ber_identifier передается ldap_next_attribute() функции, которая изменяет этот указатель.

ldap_first_entry

ldap_first_entry — возвращает первый идентификатор (id) результата

Описание

int ldap_first_entry (целое link_identifier, целое result_identifier);

Возвращает идентификатор записи для первой записи результата при успехе и false при ошибке.

Записи в LDAP-результате считываются последовательно с использованием функций ldap_first_entry() и ldap_next_entry(). ldap_first_entry() возвращает идентификатор записи для первой записи в результате. Этот идентификатор записи передается затем в процедуру lap_next_entry() для получения последовательных записей из результата.

ldap_free_result

ldap_free_result — освобождает память результата

Описание

int ldap_free_result (целое result_identifier);

Возвращает true при успехе и false при ошибке.

ldap_free_result() освобождает внутреннюю память, предназначенную для хранения результата и отмечаемую посредством result_identifier. Вся память результата автоматически освобождается когда скрипт завершается.

Обычно вся память, выделяемая для ldap результата освобождается при окончании скрипта. В случае, когда скрипт выполняет последовательные поиски, которые возвращают большие наборы записей в результате, ldap_free_result() может быть вызвана для сохранения работоспособности оперативной памяти для следующей части скрипта..

ldap_get_attributes

ldap_get_attributes — получает атрибуты записи в результате от поиска

Описание

array ldap_get_attributes (целое link_identifier, целое result_entry_identifier);

Возвращает полную информацию о записи в многоразмерном массиве при успехе и false при ошибке.

ldap_get_attributes() используется для упрощения чтения атрибутов и значений из записи в результате от поиска. Возвращаемым значением функции является многоразмерный массив атрибутов и значений.

Разместив определенную запись в каталоге, вы можете узнать какая информация хранится для этой записи, используя данный вызов. Вы могли бы использовать этот вызов в приложении которое «просматривает» каталог записей и/или когда вам не известна структура каталога записей. Во многих приложениях вы можете искать определенные атрибуты, такие как email-адрес или фамилия, не озадачиваясь при этом содержимым других данных.

return_value[«count»] = количество атрибутов в записи
return_value[0] = первый атрибут
return_value[n] = n-ый атрибут

return_value[«attribute»][«count»] = количество значений атрибута
return_value[«attribute»][0] = первое значение атрибута
return_value[«attribute»][i] = i-тое значение атрибута

Пример 1. Показывает список атрибутов отдельной записи каталога

ldap_get_dn

ldap_get_dn — получает DN записи результата

Описание

string ldap_get_dn (целое link_identifier, целое result_entry_identifier);

Возвращает DN записи результата или false при ошибке.

ldap_get_dn() используется для нахождения DN записи в результате.

ldap_get_entries

ldap_get_entries — получает все записи результата

Описание

array ldap_get_entries (целое link_identifier, целое result_identifier);

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

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

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

return_value[«count»] = количество записей в результате
return_value[0] : ссылается на детали первой записи

return_value[i][«dn»] = DN i-той записи в результате

return_value[i][«count»] = количество атрибутов i-той записи
return_value[i][j] = j-тый атрибут i-той записи результата

return_value[i][«attribute»][«count»] = количество значений атрибута в i-той записи
return_value[i][«attribute»][j] = j-тое значение атрибута в i-той записи

ldap_get_values

ldap_get_values — получение всех значений из записи результата

Описание

array ldap_get_values (целое link_identifier, целое result_entry_identifier, строковое attribute);

Возвращает массив значений атрибута при успехе и false при ошибке.

ldap_get_values() используется для чтения всех значений атрибута в записи в данном результате. Запись определяется по result_entry_identifier. Количество значений может быть получено при индексации «счетчика» в результирующем массиве. Отдельные значения доступны по целочисленному индексу в массиве. Первый индекс начинается с 0.

Для данного вызова необходим result_entry_identifier, поэтому нужно предварительно сделать один вызов ldap поиска, и один из вызовов для получения отдельной записи.

Ваше приложение или может быть жестко настроено на поиск определенных атрибутов (таких как «фамилия» или «почта») или вы должны использовать вызов ldap_get_attributes() для получения информации о том, какие атрибуты существуют для данной записи.

В LDAP может быть более одной записи для атрибута, поэтому можно, например, хранить несколько адресов email в записи каталога для одной персоны, при этом все записи будут отмечены с атрибутом «mail»

return_value[«count»] = количество значений для атрибута
return_value[0] = первое значение атрибута
return_value[i] = i-тое значение атрибута

Пример 1. Список значений атрибута «mail» для записи каталога

ldap_list

ldap_list — одноуровневый поиск

Описание

int ldap_list (целое link_identifier, строковое base_dn, строковое filter);

Возвращает идентификатор результата поиска или false при ошибке.

ldap_list() выполняет поиск с определенным фильтром по каталогу с областью LDAP_SCOPE_ONELEVEL.

LDAP_SCOPE_ONELEVEL означает что такой поиск может вернуть только информацию, находящуюся на уровне непосредственно ниже базового dn, заданного в вызове. (Эквивалентно вводу «ls» и получению списка файлов и папок в текущем рабочем каталоге).

Этот вызов берет факультативно четвертый параметр который является массивом требуемых атрибутов. См. примечание к ldap_search().


Пример 1. Составление списка всех подразделений организации

ldap_modify

ldap_modify — изменение записи LDAP

Описание

int ldap_modify (целое link_identifier, строковое dn, массив entry);

Возвращает true при успехе и false при ошибке.

ldap_modify() используется для изменения существующих записей в каталоге LDAP. Структура записи такая же как и в ldap_add().

ldap_next_attribute

ldap_next_attribute — получает следующий атрибут в результате

Описание

string ldap_next_attribute (целое link_identifier, целое result_entry_identifier, целое ber_identifier);

Возвращает следующий атрибут в записи или false при ошибке.

ldap_next_entry

ldap_next_entry — получает следующую запись в результате

Описание

int ldap_next_entry (целое link_identifier, целое result_entry_identifier);

Возвращает идентефикатор записи для следующей записи в результате, записи которого начинали считываться функцией ldap_first_entry(). Если больше нет записей в результате, то возвращается false.

ldap_read

ldap_read — чтение записи

Описание

int ldap_read (целое link_ >attributes ]);

Возвращает идентификатор результата поиска или false при ошибке.

ldap_read() выполняет поиск при определенном фильтре по каталогу с областью LDAP_SCOPE_BASE. Таким образом, это эквивалентно чтению записи из каталога.

Пустой фильтр не допустим. Если вы хотите получить абсолютно всю информацию для данной записи, используйте фильтр «object .

Этот вызов берет факультативно четвертый параметр который является массивом требуемых атрибутов. См. примечание ldap_search().

ldap_search — поиск по дереву LDAP

Описание

int ldap_search (целое link_ >attributes ]);

Возвращает идентификатор результата поиска или false при ошибке.

ldap_search() осуществляет поиск для определенного фильтра по каталогу с областью LDAP_SCOPE_SUBTREE. Это эквивалентно поиску по всему каталогу. base_dn определяет базовый DN для данного каталога.

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

Четвертый параметр является стандартным строковым массивом PHP с требуемыми атрибутами, т.е. array(«mail»,»sn»,»cn»). Заметим, что «dn» требуется всегда, независимо от того, какие типы атрибутов запрашиваются.

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

Поисковый фильтр может быть простым или расширенным, использующим булевы операторы в формате описанном в документации LDAP (См. Netscape Directory SDK для дополнения информации по фильтрам).

Приведенный ниже пример отыскивает the отдел организации, фамилию, данное имя и адрес email для всех людей в «My Company» где фамилия или данное имя содержат подстроку $person. Этот пример использует логический фильтр для указания серверу на поиск информации более чем в одном атрибуте.

Пример 1. LDAP поиск

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

$normerr = error_reporting ();
error_reporting (0); // выключает предупреждение!
$sr = ldap_search ($ds, $dn, $searchfor);
$normerr = error_reporting ($normerr);
if (!$sr) <
print «слишком много записей!»;
> else .

Вы можете попробовать сузить эту область, добавив особый фильтр, т.е. (cn=a*), но было бы лучше иметь возможность захватить результаты в битах (т.е. 1-100, 101-200. ).

ldap_unbind

ldap_unbind — прекращение связи из каталога LDAP

Описание

int ldap_unbind (целое link_identifier);

Возвращает true при успехе и false при ошибке.

ldap_unbind() прекращает связь из каталога LDAP.

LDAP. Настройка отказоустойчивого LDAP сервера

В этой статье я расскажу вам о сервере службы каталогов 389 Directory Server (он же Fedora Directory Server, он же Redhat Directory Server). Так уж повелось, что для доступа к серверу каталогов используется протокол LDAP. Если вы не работали с LDAP, я очень рекомендую ознакомиться со статьями в Wikipedia (тут про cлужбу каталогов, а тут про протокол LDAP).

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

Казалось бы, вполне логичен вопрос: а почему именно LDAP? Что мешает хранить учетные записи в MySQL или PostgreSQL? Ответ очевиден — ничего =)

Но над любой RDBMS служба каталогов обладает целым рядом преимуществ:

  • Это стандарт. Многие приложения поддерживают аутентификацию/авторизацию через LDAP;
  • Данные хранятся как иерархическое дерево, что позволяет делать эффективные операции поиска, выделив нужную часть дерева;
  • Число операций чтения в тысячи раз превышают число операций записи, в связи с этим появляется огромное число плюсов: нет необходимости применения транзакций и rollback’ов, репликация работает без проблем, которые присущи RDBMS;
  • Приложение должно видеть одну и ту же информацию на всех серверах службы каталогов, если сервер не хранит информацию, нужную клиентскому приложению, он может сам запросить ее у другого сервера или перенаправить само приложение к другому серверу;
  • Из-за описанных выше свойств службы каталогов, этот сервис отлично масштабируется горизонтально.

Выбор сервера службы каталогов пал на 389 Directory Server. История этого LDAP сервера тесно связана с компанией Netscape (если интересно, почитать историю можно тут).

Ключевые особенности этого LDAP-сервера:

  • Мультимастер репликация. На все сервера, участники MM-репликации, можно записывать данные одновременно, причем конфликты репликации разрешаются автоматически благодаря ведению changelog базы и системе автоматического разрешения конфликтов. MM-репликацию можно комбинировать с master-slave и каскадной репликацией, благодаря чему можно получить гибкий и масштабируемый сервис. Так же поддерживается частичная репликация, что крайне полезно, если мы не хотим, чтобы некоторые данные присутствовали на реплике;
  • Мощный механизм ACL. С помощью ACL можно указать кому, когда, на каком LDAP-сервере, с каким атрибутом и какое действие выполнять. ACL хранится вместе с данными как операционные атрибуты, благодаря этому для них, как и для других данных, работают операции репликации и резервного копирования.
  • Синхронизация с Microsoft Active Directory. Поддерживается двунаправленная синхронизация пользователей, групп и паролей (для синхронизации паролей из AD в 389-ds необходимо поставить специальный софт на каждый контроллер домена)
  • SSL/TLS. Простой поддержкой SSL/TLS сейчас никого не удивишь. 389-ds поддерживает аутентификацию/авторизацию на основании SSL-сертификатов. Так же есть возможность шифрования атрибутов при записи на диск. При ручном вводе ключа при запуске сервера это может защитить от утечки данных путем копирования файлов с БД.
  • Управление сервером через протокол LDAP. Сервер поддерживает конфигурацию путем изменения атрибутов в cn=config, большинство параметров применяются без перезагрузки сервера. Так же на сервере можно запускать резервное копирование/восстановление и другие task-и путем добавления новой записи в cn=tasks,cn=config.
  • Plugins. Весь функционал реализован в виде plugin-ов (MM-репликация, синхронизация с AD, ACL, и т.п.). Написать и добавить свой plugin довольно легко, т.к. имеется хорошая документация с примерами.

После обзора возможностей 389 Directory Server познакомимся поближе с его структурой.

Общая структура 389 Directory Server

389 DS состоит из нескольких компонентов.

  • Сам сервер каталогов. Это приложение ns-slapd, именно этот процесс принимает и обрабатывает запросы от клиента, производит репликацию, читает и записывает данные в базу, передает управление плагинам, и т.д.
  • Сервер администрирования (Administration Server). Он управляет сервером каталогов. Сервер предоставляет интерфейс управления через протокол HTTP(S), так же предоставляет веб-интерфейс для просмотра логов и статуса репликации. Физически это apache + модули для управления ns-slapd.
  • Консоль администрирования. Java-приложение, которое подключается к серверу администрирования и позволяет настраивать сервер каталогов через удобный интерфейс. Есть версия под windows и linux, под mac os работает через проброс X-сессии с linux-машины.

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

Итак, задача. Необходимо настроить отказоустойчивый сервис службы каталогов. Для этого настроим два сервера, настроим multimaster-репликацию между ними и поднимем перемещающийся IP-адрес (pacemaker + openais).

Если один из серверов станет недоступен, другой возьмет на себя этот IP и сервис продолжит работу.

После восстановления сервера данные будут реплицированы на него и IP-адрес переключится обратно на LDAP00, или же, в зависимости от настройки кластера, останется на LDAP01.

На одном сервере может быть несколько изолированных инстансов ns-slapd со своими настройками, схемой, правилами репликации и т.д. Чтобы иметь возможность управлять этими инстансами из консоли управления на каждом сервере должен стоять сервер Administration Server (далее admin server). admin server сам нуждается в одном инстансе LDAP сервера, поскольку хранит там run-time конфигурацию. По умолчанию конфигурация admin server хранится вместе с пользовательскими данными, но я считаю это небезопасным, поэтому у нас будет два инстанса на каждом сервере: один будет содержать конфигурацию для admin server-а, а второй данные. В такой схеме в случае отказа одной из нод сохраняется не только работоспособность LDAP-сервиса, но и возможность управления им.

Для нашего сервиса службы каталогов мы используем два сервера ldap00 и ldap01. На каждом из них будут установлены два инстанса LDAP сервера, один для нужд admin server-ов, второй для наших данных.
План установки будет такой:

  1. Установка первого сервера на ldap00;
  2. Настройка репликации на ldap00;
  3. Установка и настройка ldap инстанса на ldap01;
  4. Установка admin server-а на ldap01;
  5. Установка и настройка ldap инстансов для хранения пользовательских данных.

Установка первого сервера на ldap00

Готовые rpm собраны в репозитории EPEL для Centos, RHEL и Fedora Core. Если у вас одна из этих систем — подключите репозиторий EPEL и выполните установку через yum.

Мы используем SLES, поэтому нам пришлось собирать все пакеты под эту систему в нашем OpenSUSE Build Service. Если у вас debian/ubuntu — прочтите этот документ.

Вместе с 389 DS идет набор perl скриптов, которые используются для установки инстансов сервера.

Вот некоторые из них:

  • setup-ds.pl — устанавливает инстанс LDAP-сервера, сервер создается не подключенным к admin server-у;
  • setup-ds-admin.pl — устанавливает admin server, при необходимости устанавливает инстанс LDAP-сервера для хранения своей конфигурации;
  • register-ds-admin.pl — подключает инстанс к admin server-у, при необходимости устанавливает admin server;
  • remove-ds.pl — удаляет инстанс;
  • remove-ds-admin.pl — удаляет admin server и все инстансы;
  • dsktune — выводит параметры системы, которые нужно изменить, чтобы добиться большей производительности.

Для начала запустим dsktune:

# dsktune
389 Directory Server system tuning analysis version 10-AUGUST-2007.

NOTICE: System is x86_64-unknown-linux2.6.27.42-0.1-xen (1 processor).

NOTICE: The net.ipv4.tcp_keepalive_time is set to 7200000 milliseconds
(120 minutes). This may cause temporary server congestion from lost
client connections.

WARNING: There are only 1024 file descriptors (hard limit) available, which
limit the number of simultaneous connections.

WARNING: There are only 1024 file descriptors (soft limit) available, which
limit the number of simultaneous connections.

Утилита написала о системных параметрах, которые нужно подкрутить. В моем случае это net.ipv4.tcp_keepalive_time и лимит открытых файлов.

tcp_keepalive_time — это время от последнего посланного пакета до первой посылки keepalive. При большом значении, если клиент «умер», соединение останется открытым долгое время (по умолчанию 120 минут). Установим это значение в 10 минут.

echo 600 > /proc/sys/net/ipv4/tcp_keepalive_time

Добавим в /etc/sysctl.conf:

для увеличения лимита открытых файлов добавляем в /etc/security/limits.conf:

запускаем еще раз dsktune и убедимся, что у нас все готово для установки.

Теперь запускаем скрипт setup-ds-admin.pl
Нас спросят, хотим ли мы установить 389 Directory и Administration Server, согласны ли мы с лицензией, еще раз запустят dsktune и, наконец, появится меню выбора типа установки.

1. Express
Allows you to quickly set up the servers using the most
common options and pre-defined defaults. Useful for quick
evaluation of the products.

2. Typical
Allows you to specify common defaults and options.

3. Custom
Allows you to specify more advanced options. This is
recommended for experienced server administrators only.

To accept the default shown in brackets, press the Enter key.

Choose a setup type [2]:

Выбираем третий пункт (мы же experienced server administrators =) )

Далее будет предложено указать FQDN и имя/группу, от которого(ой) будет запускаться LDAP-сервер.

If you do not yet have a configuration directory server, enter ‘No’ to
be prompted to set up one.

Do you want to register this software with an existing
configuration directory server? [no]:

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

Далее идут вопросы об admin server-е: administrator ID, пароль, Administration Domain, ответы на них оставляем по умолчанию (кроме пароля).

Затем надо будет указать, какой порт будет слушать LDAP-сервер. Мы договорились, что это инстанс, который хранит лишь конфигурацию для admin server-а, поэтому пересаживаем его на порт 6389. Далее указываем Directory server identifier. Назовем свой инстанс config-instance. На вопрос о суффиксе корневого дерева отвечаем по умолчанию, корневого дерева в этом инстансе не будет, так что его потом можно удалить.

Затем нас ждет вопрос о Directory Manager DN.

Directory Manager — это пользователь с правами root-а в LDAP-сервере. У каждого инстанса есть свой локальный Directory Manager.

Далее следуют вопросы о пароле к Directory Manager-у, хотим ли мы поставить примеры записей в наш root suffix и хотим ли мы заполнить наш новый инстанс какими-нибудь данными, спросят имя порта, IP-адрес и имя пользователя от которого admin server будет работать. После этого последний раз спросят подтверждение и начнут установку.

Настройка репликации на ldap00

Для подключения к серверу нужно поставить и запустить консоль управления 389-console.

В качестве Adminstration URL нужно ввести адрес admin server-а и порт который вы указали при установке.

Далее мы попадаем в панель управления серверами. У нас сейчас только один инстанс, выберем его.

Из консоли управления удаляем суффикс dc=edu,dc=scalaxy,dc=local

У нас остался всего один суффикс и база, в которой находятся конфигурационные данные для admin server-а.

Теперь немного теории о принципах репликации.

В репликации участвуют два типа серверов, supplier и consumer.

supplier — сервер, который копирует реплику на другой сервер.

обязанности supplier сервера:

  • отвечать на запросы клиентов на чтение и запись;
  • поддержание информации о состоянии изменений реплики;
  • инициализация репликации на consumer сервера.

supplier сервер должен быть всегда доступен, поскольку запись производится только на этом сервере, а потом реплицируется на другие севера.

Если связь с supplier сервером будет потеряна, то запись в каталог станет невозможна.

consumer — сервер, который сохраняет реплику с другого сервера. В случае с мультимастер репликацией, два сервера одновременно являются supplier-ом и consumer-ом.

consumer должен:

  • отвечать на read запросы клиентов;
  • пересылать запросы на обновления данных на сервер;
  • при получении запроса на добавление, удаление или обновления записи, запрос пересылается на supplier сервер.

Каждый supplier сервер имеет свой changelog, в котором хранится информация обо всех изменениях, которые произошли на реплике.

Supplier сервер повторяет эти изменения на каждом consumer сервере.

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

Ведение changelog-а изменений по умолчанию выключено, включается он во вкладке Replication. Changelog включается для всех баз одновременно.

Дальше включаем репликацию для базы NetscapeRoot. Необходимо указать Replica ID и Supplier DNs.

Supplier DN — это имя пользователя, которому разрешено выполнять репликацию на LDAP-сервере. Такого пользователя нужно создать на всех LDAP-серверах, которые участвуют в мультимастер репликации.

Быстрее всего это сделать через утилиту ldapmodify. Эта утилита позволяет модифицировать данные в LDAP в интерактивном режиме или брать команды из ldif файла.

ldapmodify -h 127.0.0.1 -p 6389 -x -D «cn=root» -W
Enter LDAP Password:
dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:

Ответ должен быть
adding new entry «cn=replication manager,cn=config»

Итого, у нас получилось:

Сразу же создадим Replication Agreement для второго сервера. В контекстном меню для базы NetscapeRoot выбираем New Replication Agreement и заполняем аналогичным образом:

Нас предупредят, что подключение к серверу невозможно (так как его еще нет), доходим до последнего пункта, ставим Do not initialize consumer.

Установка и настройка ldap инстанса на ldap01

Теперь нужно настроить второй LDAP-сервер. С ним несколько иначе, т.к. установка admin server-а должна уже происходить в установленный LDAP-сервер и первичную настройку мы будем производить из консоли с помощью утилиты ldapmodify (что является нехилым плюсом, если стоит задача разобраться, как же работает этот сервер каталогов).

Сначала на втором сервере с помощью скрипта setup-ds.pl нужно создать инстанс, который не управляется admin server-ом.

Ответы на вопросы скрипта аналогичны предыдущим.

После установки LDAP-сервера подключаемся к нему через ldapmodify и настраиваем.

Подключение производится примерно так:

ldapmodify -h 127.0.0.1 -p 6389 -D «cn=root» -W

dn: cn=changelog5,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
cn: changelog5
nsslapd-changelogdir: /var/lib/dirsrv/slapd-ldap01/changelogdb

changelogdir должен указывать на директорию с названием вашего инстанса.

2) добавляем пользователя replication manager:

dn: cn=replication manager,cn=config
changetype: add
objectClass: inetorgperson
objectClass: person
objectClass: top
objectClass: organizationalPerson
cn: replication manager
sn: RM
userPassword:

20380119031407Z означает, что срок действия пароля не ограничен.

3) Создаем суффикс netscaperoot:

dn: cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: add
objectclass: top
objectclass: extensibleObject
objectclass: nsMappingTree
nsslapd-state: backend
nsslapd-backend: NetscapeRoot
cn: «o=netscaperoot»

4) Создаем базу для суффикса netscaperoot:

dn: cn=NetscapeRoot,cn=ldbm database,cn=plugins,cn=config
changetype: add
objectclass: extensibleObject
objectclass: nsBackendInstance
nsslapd-suffix: o=netscaperoot

Кстати, 389 DS по умолчанию для хранения записей каталога использует модифицированную версию нереляционной базы данных Berkeley DB. Если есть желание, подробнее вы можете прочитать тут.

5) Создаем корневой o=NetScapeRoot:

dn: o=NetscapeRoot
changetype: add
objectClass: organization
objectClass: top
o: NetscapeRoot

6) Разрешаем репликацию для o=netscaperoot:

dn: cn=replica,cn=»o=netscaperoot», cn=mapping tree, cn=config
changetype: add
objectClass: nsDS5Replica
objectClass: top
nsDS5ReplicaId: 2
nsDS5ReplicaRoot: o=netscaperoot
cn: replica
nsDS5Flags: 1
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsds5ReplicaChangeCount: 0
nsds5ReplicaPurgeDelay: 604800
nsDS5ReplicaType: 3

Не забываем изменить nsDS5ReplicaId на номер вашего сервера (nsDS5ReplicaType — тип репликации, 3 — multimaster).

На данном этапе у нас уже есть настроенная репликация в одну сторону с ldap00 на ldap01.

Последним этапом будет:

7) Настройка репликации от ldap01 на ldap00:

dn: cn=Multimaster replication, cn=replica, cn=»o=netscaperoot», cn=mapping
tree, cn=config
changetype: add
objectClass: top
objectClass: nsDS5ReplicationAgreement
cn: Multimaster replication
description: replication for netscaperoot
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindMethod: SIMPLE
nsds5replicaChangesSentSinceStartup:
nsDS5ReplicaCredentials:

nsDS5ReplicaHost: ldap00.edu.scalaxy.local
nsDS5ReplicaPort: 6389
nsDS5ReplicaRoot: o=netscaperoot
nsDS5ReplicaTransportInfo: LDAP
nsds5replicaUpdateInProgress: FALSE

nsDS5ReplicaBindDN — имя пользователя, от имени которого будет производится репликация
nsDS5ReplicaCredentials — пароль

8) Первичная инициилизация репликации с ldap00 на ldap01:

На первом сервере выполняем эту команду:
dn: cn=Multimaster replication,cn=replica,cn=»o=netscaperoot»,cn=mapping tree,cn=config
changetype: modify
replace: nsds5beginreplicarefresh
nsds5beginreplicarefresh: start

Эта команда реплицирует данные с ldap00 на ldap01, эта операция обязательна, тк на втором сервер сейчас пустой o=netscaperoot.

Теперь мы имеем полностью реплицируемые каталоги с конфигурацией admin server-а.

Установка admin server-а на ldap01

Нужно поднять admin server на втором сервере. Запускаем скрипт register-ds-admin.pl

Когда нам предложат указать Configuration directory server URL, вводим LDAP URL второго сервера ldap://ldap01.edu.scalaxy.local:6389/o=NetscapeRoot

Дальнейшая настройка тривиальна, следуем указаниям скрипта.

Установка и настройка ldap инстансов для хранения пользовательских данных

Теперь подключаться через консоль управления можно к любому admin server-у.

На каждом из серверов в Server Group создаем новый инстанс LDAP server-а, это будет LDAP-server, в котором мы будем хранить наши данные.

Настраиваем мультимастер репликацию между двумя инстансами по тому же принципу (теперь вы можете настроить репликацию как через GUI, так и через консоль).

Поздравляю! Вы настроили отказоустойчивый сервис службы каталогов! Далее нужно настроить openais+pacemaker, чтобы исключить простои в работе сервиса.

Что такое код ldap_connect

(PHP 3, PHP 4, PHP 5)

ldap_connect — Connect to an LDAP server

Description resource ldap_connect ( [string hostname [, int port]] )

ldap_connect() establishes a connection to a LDAP server on a specified hostname and port . Both the arguments are optional. If no arguments are specified then the link identifier of the already opened link will be returned. If only hostname is specified, then the port defaults to 389.

If you are using OpenLDAP 2.x.x you can specify a URL instead of the hostname. To use LDAP with SSL, compile OpenLDAP 2.x.x with SSL support, configure PHP with SSL, and use ldaps://hostname/ as host parameter. The port parameter is not used when using URLs.

Замечание: URL and SSL support were added in 4.0.4.

Пример 1. Example of connecting to LDAP server.

// LDAP variables
$ldaphost = «ldap.example.com» ; // your ldap servers
$ldapport = 389 ; // your ldap server’s port number

// Connecting to LDAP
$ldapconn = ldap_connect ( $ldaphost , $ldapport )
or die( «Could not connect to $ldaphost» );

Пример 2. Example of connecting securely to LDAP server.

// make sure your host is the correct one
// that you issued your secure certificate to
$ldaphost = «ldaps://ldap.example.com/» ;

// Connecting to LDAP
$ldapconn = ldap_connect ( $ldaphost )
or die( «Could not connect to < $ldaphost >» );

Пред. Начало След.
ldap_compare Уровень выше ldap_count_entries

Если Вы не нашли что искали, то рекомендую воспользоваться поиском по сайту:

Что такое код ldap_connect

(PHP 3, PHP 4, PHP 5)

ldap_connect — Connect to an LDAP server

Description resource ldap_connect ( [string hostname [, int port]] )

ldap_connect() establishes a connection to a LDAP server on a specified hostname and port . Both the arguments are optional. If no arguments are specified then the link >hostname is specified, then the port defaults to 389.

If you are using OpenLDAP 2.x.x you can specify a URL instead of the hostname. To use LDAP with SSL, compile OpenLDAP 2.x.x with SSL support, configure PHP with SSL, and use ldaps://hostname/ as host parameter. The port parameter is not used when using URLs.

Note: URL and SSL support were added in 4.0.4.

Example 1. Example of connecting to LDAP server.

Example 2. Example of connecting securely to LDAP server.

Аутентификация LDAP — настройки

Страница Аутентификация 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” в сочетании с введенной пользователем строкой john.doe@nasa.gov и строкой привязки и начала поиска OU=Engineering,DC=NASA,DC=GOV определит DN пользователя: CN=john.doe@nasa.gov,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 (отличительное имя) пользователя, имеющего права чтения каталога LDAP. Введенная здесь учетная запись может не иметь административного доступа к каталогу. Прав чтения достаточно.

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

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

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

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

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

Строка состоит из пар «атрибут=значение», разделенных запятыми. Например:

При выборе способа «Имя и пароль пользователя устройства» в это поле можно ввести несколько несколько строк привязки, разделенных знаком вертикальной черты (‘|’, ASCII 0x7c). Это можно использовать, например, для указания альтернативных доменов LDAP. Устройство предпримет попытку привязать сервер LDAP, используя поочередно все строки в заданном порядке. После успешного выполнения привязки тот же корневой объект используется для поиска информации пользователя устройства.

Атрибут LDAP, соответствующий имени пользователя

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

Получение

адреса электронной почты, используя атрибут

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

и имя, используя атрибут

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

Тестирование

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

Илон Маск рекомендует:  Что такое код pg_host
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL