Что такое код ldap_first_attribute


Содержание

Что такое код ldap_first_attribute

(PHP 3, PHP 4, PHP 5)

ldap_first_attribute — Return first attribute

Description string ldap_first_attribute ( resource link_identifier, resource result_entry_identifier, int &ber_identifier )

Returns the first attribute in the entry on success and FALSE on error.

Similar to reading entries, attributes are also read one by one from a particular entry. ldap_first_attribute() returns the first attribute in the entry pointed by the result_entry_identifier . Remaining attributes are retrieved by calling ldap_next_attribute() successively. ber_identifier is the identifier to internal memory location pointer. It is passed by reference. The same ber_identifier is passed to the ldap_next_attribute() function, which modifies that pointer.

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

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

Что такое код ldap_first_attribute

#include
char *ldap_first_attribute(
LDAP *ld, LDAPMessage *entry, BerElement **berptr )
char *ldap_next_attribute(
LDAP *ld, LDAPMessage *entry, BerElement *ber )

DESCRIPTION

It also returns, in berptr, a pointer to a BerElement it has allocated to keep track of its current position. This pointer should be passed to subsequent calls to ldap_next_attribute() and is used to effectively step through the entry’s attributes. The caller is solely responsible for freeing the BerElement pointed to by berptr when it is no longer needed by calling ber_free(3). When calling ber_free(3) in this instance, be sure the second argument is 0.

The attribute names returned are suitable for inclusion in a call to ldap_get_values(3) to retrieve the attribute’s values.

Национальная библиотека им. Н. Э. Баумана
Bauman National Library

Персональные инструменты

LDAP (Lightweight Directory Access Protocol)

Авторство
В.Н. Давыдов
Согласовано: 26.05.2020
LDAP
Уровень (по модели OSI): Прикладной
Семейство: стек протоколов TCP/IP
Порт/ID: 389 / TCP или UDP
Назначение протокола: Доступ к службе каталогов
Спецификация: RFC 4510, RFC 4511, RFC 4512, RFC 4513, RFC 4514, RFC 4515, RFC 4516, RFC 4517, RFC 4518, RFC 4519, RFC 4520, RFC 4521
Вступил в силу с: 1993

LDAP (англ. Lightweight Directory Access Protocol — «облегчённый протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов (программному комплексу для хранения и каталогизации информации. По своей сути она очень похоже на обычную базу данных, но с «уклоном» скорее на чтение данных, нежели на их добавление или изменение. Обычно служба каталога базируется на клиент-серверной архитектуре. Одна из наиболее известных таких систем — DNS) X.500, разработанный IETF. Является облегченным и незначительно переработанным потомком протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.

Содержание

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

В UNIX/Linux-системах каталоги (и LDAP, как протокол доступа к ним) получили распространение для хранения системной информации, такой, например, как учётные записи пользователей и служебных настроек. Одним из наиболее распространённых LDAP-серверов в UNIX/Linux-системах является OpenLDAP. В Windows LDAP-сервер встроен в ActiveDirectory.

Функциональное описание протокола

В протоколе LDAP определены следующие операции для работы с Каталогом:

  • Операции подключения/отключения
    • Подключение (bind) — позволяет ассоциировать клиента с определённым объектом Каталога (фактическим или виртуальным) для осуществления контроля доступа для всех прочих операций чтения/записи. Для того, чтобы работать с Каталогом, клиент обязан пройти аутентификацию как объект, отличительное имя (Distinguished Name) которого находится в пространстве имён, описываемом Каталогом. В запросе операции bind клиент может не указывать отличительное имя, в таком случае будет осуществлено подключение под специальным псевдонимом anonymous (обычно это что-то наподобие гостевой учетной записи с минимальными правами)
    • Отключение (unbind) — позволяет клиенту в рамках сеанса соединения с LDAP-сервером переключиться на аутентификацию с новым отличительным именем. Команда unbind возможна только после аутентификации на сервере с использованием bind, в противном случае вызов unbind возвращает ошибку
  • Поиск (search) — чтение данных из Каталога. Операция сложная, на вход принимает множество параметров, среди которых основными являются:
    • База поиска (baseDN) — ветка DIT, от которой начинается поиск данных
    • Глубина поиска (scope) — может иметь значения (в порядке увеличения охватываемой области): base, one, sub
      • base — поиск непосредственно в узле — базе поиска
      • one — поиск по всем узлам, являющимся прямыми потомками базового в иерархии, то есть лежащим на один уровень ниже него
      • sub — поиск по всей области, нижележащей относительно базы поиска (baseDN)

Логические операторы представлены стандартным «набором»: & (логическое «И»), | (логическое «ИЛИ») и ! (логическое «НЕ»). Пример фильтра поиска:

  • Операции модификации — позволяют изменять данные в Каталоге, при этом в понятие модификации входит как добавление, удаление и перемещение записей целиком, так и редактирование записей на уровне их атрибутов. Подтипы модификации:
    • Добавление (add) — добавление новой записи
    • Удаление (delete) — удаление записи
    • Модификация RDN (modrdn) — перемещение/копирование записи
    • Модификация записи (modify) — позволяет редактировать запись на уровне её атрибутов,
      • добавляя новый атрибут или новое значение многозначного атрибута (add)
      • удаляя атрибут со всеми его значениями (delete)
      • заменяя одно значение атрибута на другое (replace)
      • а также увеличивая (уменьшая) значение атрибута в рамках атомарной операции (increment)
  • Операция сравнения (compare) — позволяет для определённого отличительного имени сравнить выбранный атрибут с заданным значением

Пример обращения к службе каталога

Пример обращения к службе каталога по протоколу LDAP с помощью утилиты ldapsearch.

Аутентифицироваться при подключении к каталогу под именем cn=admin,dc=mydc,dc=com, использовать простую аутентификацию (-x), спросить пароль (-W). Результат выполнения команды ldapsearch представлен в формате LDIF (LDAP Interchange Format). В этом формате записи представляются как набор полей, каждое из которых записывается в отдельном поле в виде пары:

Найденная запись содержит поля dn, objectClass и ou и выглядит так:

Доступ к каталогу осуществляется от имени cn=admin,dc=mydc,dc=com, которое называется именем привязки (bind name). Имя привязки это полное имя (DN, distinguished name) учётной записи в каталоге пользователя, от имени которого будет производиться работа с каталогом.

How does Keycloak use the LDAP attributes defined in User Federation?

In setting up User Federation from an LDAP provider, there are three LDAP attributes:


  • Username LDAP attribute
  • RDN LDAP attribute
  • UUID LDAP attribute

How does the value of each of these impact Keycloak or the sync process?

For instance, if the directory ensures unique email addresses, are there any negatives to using mail as the UUID LDAP attribute?

Where can I find details on each of these attributes—specific to Keycloak?

1 Answer 1

In Keycloak admin console, you may hover over the tooltip — a tiny question mark — next to the LDAP attribute label if you want as much info as possible about it. I checked this on Keycloak v6.0.1 but I assume it applies to most recent versions. Such tooltip will often give more info than you can find on the Keycloak documentation website. More details about these attributes:

Username LDAP attribute: Name of LDAP attribute which is mapped as Keycloak username. For many LDAP server vendors it can be ‘uid’. For Active Directory it can be ‘sAMAccountName’ or ‘cn’. The attribute should be filled for all LDAP user records you want to import from LDAP to Keycloak. So there you could use the mail attribute if you want this as username in Keycloak. Then users would log on to Keycloak with their email address. If you enable LDAP synchronization to Keycloak local database (switch on Import Users ), this will be recorded there as username.

RDN LDAP attribute: Name of LDAP attribute which is used as RDN (top attribute) of typical user DN. Usually it’s the same as Username LDAP attribute, however it’s not required. For example for Active directory it’s common to use ‘cn’ as RDN attribute when username attribute might be ‘sAMAccountName’. For example with a conventional LDAP directory (not Active Directory) where user DNs are typically u >, you would use ‘uid’ there.

[EDIT 2020-05-31] The RDN attribute is actually used for instance when you create a new user in Keycloak. If you have the Edit Mode option set to WRITABLE in the settings, Keycloak synchronizes it back to the LDAP directory, i.e. creates the new user entry in LDAP. For that, it needs (among other things) the RDN and the Users DN (another option below the RDN) to make the full DN of the new user LDAP entry.

UUID LDAP attribute: Name of LDAP attribute which is used as unique object identifier (UUID) for objects in LDAP. For many LDAP server vendors, it’s ‘entryUUID’ however some are different. For example for Active Directory it should be ‘objectGUID’. If your LDAP server really doesn’t support the notion of UUID, you can use any other attribute, which is supposed to be unique among LDAP users in tree. For example ‘uid’ or ‘entryDN’. Any standard LDAP v3 directory should use entryUUID (OpenLDAP, OpenDJ. ).

Regarding best practices on UUID in LDAP directories, you may look at the RFC 4530 standard.

In general, I would advise against using ‘mail’ as UUID, because a user’s ‘mail’ may change (see reasons down below), whereas an entry UUID — whether it is a user entry or not — is meant to be a globally uniquely generated number (or at least contain such a number), usually generated on server side, and fixed once and for all for the entry. (Furthermore, it shall not be reused ever, even after the entry is deleted, as UUIDs should be unique in time and space.) In particular, it should be independent from any of the user’s variable attributes, like email address.

Indeed, a user’s email address may change during his/her lifetime in the organization for various reasons, just to name a few:

  • Users — women typically — may get married or divorced, and therefore may change their last name.
  • Top management decides to rebrand the company and therefore change the mail domain.
  • The company is going through a merger or an acquisition with/by another company and therefore the mail domain changes again.

ASA. Настройка перехватывающей аутентификации через AD и LDAP

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

А здесь я расскажу, как используя ASA, напрямую аутентифицироваться в AD

На МСЭ часто возникает задача проверить пользователя до предоставления ему доступа к определенным ресурсам. На ASA такая проверка называется «перехватывающая аутентификация» (cut-through proxy).

Этот сервис использует инфраструктуру ААА (Authentication, Authorization, Accounting).

Илон Маск рекомендует:  Глава 7 доступ к дискетам

Примечание: в английском слове authentication нет слога «фи», который появился в русском «аутентификация» скорее всего из-за созвучия слову «идентификация». Причем, в нашем могучем языке есть и «аутентичность». Без всякого «фи» :) Не попадитесь!

Аутентификация.
Отвечает на вопрос «есть ли такой пользователь». Поиск этого пользователя может производиться как в локальной (LOCAL) базе данных, так и во внешних (TACACS+, RADIUS, AD по протоколу LDAP).

Настройка сервера LDAP подразумевает указание учетной записи пользователя из AD, с которой ASA будет входить в LDAP, тип сервера, «корень» поиска и т.д.

aaa-server protocol ldap
aaa-server () host
ldap-base-dn <корневой уровень>
ldap-scope
ldap-naming-attribute <передаваемый атрибут>
ldap-login-dn <имя пользователя ASA>
ldap-login-password <пароль на пользователя ASA>
server-type

Пример:
aaa-server AD (dmz) host 172.16.1.100
ldap-base-dn ou=Employers, dc=anticisco, dc=ru
ldap-scope subtree
ldap-naming-attribute sAMAccountName
ldap-login-dn cn=ASA, cn=users, dc=anticisco, dc=ru
ldap-login-password ASALDAPPASS
server-type microsoft

После того, как настроены сервера, самое время определить, какой трафик нам интересно проверять и не пропускать без аутентификации. На ASA за это отвечает…конечно список доступа, где строчками permit указывается такой трафик. Сам список доступа для аутентификации применяется командой

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

Например, хотим проверить весь трафик из локальной сети 10.1.1.0/24 (за интерфейсом inside), идущий во все сети, кроме 172.16.1.0/24:
access-list AUTH deny ip 10.1.1.0 255.255.255.0 172.16.1.0 255.255.255.0
access-list AUTH permit ip 10.1.1.0 255.255.255.0 any
aaa authentication match AUTH inside RAD

А как же спросить у пользователя его логин/пароль? Ведь не может же какой-нибудь пинг инициировать запрос?
Перехватить сессию и спросить логин и пароль ASA может по протоколам http/https, ftp, telnet. Если же необходимо аутентифицировать другой трафик, то надо сделать 2 телодвижения: пойти куда-нибудь за ASA по одному из указанных протоколов, ввести свои логин/пароль либо в броузере либо в telnet либо в ftp окошке. Надо учитывать, что такой трафик обязательно должен быть указан в списке доступа для интересного трафика.

Например, мы хотим, чтобы пользователь мог пойти по telnet или http на хост 1.1.1.1 и его бы спросили логин и пароль. Тогда этот трафик обязательно должен попадать в список доступа. Вот такой не подойдет, т.к. по telnet работать не будет:
access-list AUTH permit tcp any any eq 80
access-list AUTH permit udp any any

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

timeout uauth

Пример:
timeout uauth 0:15:0 inactivity
timeout uauth 20:00:00 absolute

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

Гораздо более интересный момент – авторизация, то есть ограничение прав пользователя.

Для авторизации по LDAP нам нужен «костыль» — специальная конструкция, которая сопоставит атрибуту LDAP атрибут RADIUS, который поймет ASA. Такая конструкция называется

ldap attribute-map
map-name
map-value

Пример. Сопоставим атрибуту ipPhone базы AD атрибут IETF-Radius-Filter-Id (список доступа). И опишем, что если в указанном атрибуте мы получим слово «BUHG», то на пользователя применим список доступа BUH, который уже написан на ASA:
ldap attribute-map AD
map-name ipPhone IETF-Radius-Filter-Id
map-value ipPhone BUHG BUH

Важно: если в указанном атрибуте мы ничего не получили, мы его игнорируем, а если получили слово, не описанное в значениях для данного атрибута, то доступ будет запрещен. Таким образом, администратор AD может влиять на права доступа. Например, может перекрыть интернет неугодному пользователю, не прикасаясь к ASA:)

Осталось только применить этот список атрибутов в конкретном сервере LDAP

aaa-server () host
ldap-attribute-map

Пример:
aaa-server AD (dmz) host 172.16.1.100
ldap-attribute-map AD

Приятного авторизования, дорогие хабрачитатели-цисколюбы :)

ЗЫ Я сам: «На нормальных ОС это делается половиной команды» :) Так что поможем админам «ненормальных» :)

Основы протокола LDAP: иерархия данных и компоненты записей

LDAP (или Lightweight Directory Access Protocol) – открытый протокол, используемый для хранения и извлечения данных из иерархической структуры каталогов. Обычно используется для хранения информации об организации и ее активах и пользователях. LDAP – это гибкое решение для определения любого объекта и его качеств.

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

Что такое служба каталогов?

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

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

Что такое LDAP?

LDAP (или lightweight directory access protocol) – это протокол, который определяет методы, с помощью которых можно получить доступ к службе каталогов. В более широком смысле LDAP формирует способ отображения данных в службе каталогов для пользователей, определяет требования к компонентам, используемым для создания записей данных, и описывает способ использования разных примитивных элементов для составления записей.

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

Основные компоненты данных LDAP


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

Атрибуты

Сами данные в системе LDAP в основном хранятся в элементах, называемых атрибутами. Атрибуты – это в основном пары ключ-значение. В отличие от некоторых других систем, ключи – это предопределенные имена, которые продиктованы объектными классами записи (мы обсудим это немного позже). Кроме того, данные в атрибуте должны соответствовать типу, указанному в первоначальном определении атрибута.

Атрибут состоит из имени атрибута и значения, которые разделяются двоеточием и пробелом. Например, атрибут mail, который определяет адрес электронной почты, будет выглядеть так:

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

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

Записи

Атрибуты сами по себе бессмысленны. Чтобы иметь смысл, они должны быть связаны с чем-то. В LDAP атрибуты находятся внутри записи. Запись представляет собой набор атрибутов под описательным именем.

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

Запись, отображаемая в LDIF (LDAP Data Interchange Format), будет выглядеть примерно так:

dn: sn=Amber,ou=people,dc=8host,dc=com
objectclass: person
sn: Amber
cn: Justin Amber

Вышеприведенный пример может быть допустимой записью в системе LDAP.

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

Например, если возможно иметь записи для пользователя и для элемента инвентаря, как их отличить? Один из способов различать записи разных типов – это установить отношения и группы. Это по сути функция, где помещается запись при ее создании. Все записи добавляются в систему LDAP в виде веток в деревьях, называемых информационными деревьями каталога, или DIT.

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

Таким образом, у вас может быть запись people и отдельная запись inventoryItems. А фактические записи данных могут быть дочерними по отношению к ним, что позволит различать их тип. Ваши организационные записи можно произвольно определить для наилучшего представления ваших данных.

В примере, приведенном в предыдущем разделе, мы видим один признак DIT в строке dn:

Эта строка называется различительным именем записи (подробнее об этом позже) и используется для идентификации записи. Она функционирует как полный путь назад к root DIT. В этом случае есть запись sn=Amber. Прямым родителем является запись по имени ou=people, которая, вероятно, используется в качестве контейнера для записей, описывающих людей. Родители этой записи происходят из домена 8host.com, который функционирует как root DIT.

Компоненты данных LDAP

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

Определения атрибутов

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

Например, это определение атрибута name:

attributetype ( 2.5.4.41 NAME ‘name’ DESC ‘RFC4519: common supertype of name attributes’
EQUALITY caseIgnoreMatch
SUBSTR caseIgnoreSubstringsMatch
SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 <32768>)

‘name’ – это имя атрибута. Число в первой строке – это глобальный уникальный идентификатор OID (Object ID), присвоенный атрибуту, чтобы отличать его от остальных атрибутов. Остальная часть записи определяет, как ее можно сравнивать во время поиска, и указывает, где найти информацию о типе данных атрибута.

Важной частью определения атрибута является то, может ли атрибут быть определен в записи более чем один раз. Например, фамилия может быть определена только один раз для каждой записи, но атрибут родства (например niece) может присутствовать в одной записи несколько раз. Атрибуты по умолчанию многозначны; если атрибут можно установить только один раз для каждой записи, он должен содержать флаг SINGLE-VALUE.

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

Определения ObjectClass

Атрибуты собираются внутри объектов, называемых objectClasses. ObjectClasses – это просто группы связанных атрибутов, которые были бы полезны при описании конкретной вещи. Например, «person» является objectClass.

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

Поэтому, если вы создаете запись для описания человека, в том числе objectClass person, вы можете использовать в нем все атрибуты:

dn: . . .
objectClass: person

Тогда у вас будет возможность установить эти атрибуты внутри записи:

  • cn: имя
  • description: удобочитаемое описание записи
  • seeAlso: ссылка на соответствующие записи
  • sn: фамилия
  • telephoneNumber: номер телефона
  • userPassword: пароль для пользователя

Атрибут objectClass можно использовать несколько раз, если вам нужны атрибуты из разных objectClasses, но есть правила, их использования.

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

Определения ObjectClass указывают, требуются ли предлагаемые атрибуты (указывается спецификацией MUST) или их использовать необязательно (обозначается спецификацией MAY). Несколько objectClasses могут предоставлять одинаковые атрибуты, а атрибут MAY или MUST может отличаться.

Например, objectClass person определяется так:

objectclass ( 2.5.6.6 NAME ‘person’ DESC ‘RFC2256: a person’ SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )

Он определяется как структурный objectClass, что означает, что его можно использовать для создания записи. Созданная запись должна указывать атрибуты surname и commonname и может указывать атрибуты userPassword, telephoneNumber, seeAlso или description.

Схемы

Определения ObjectClass и определения атрибутов, в свою очередь, группируются в схемы. В отличие от традиционных реляционных баз данных, схемы в LDAP – это просто коллекции связанных объектов и атрибутов. Один DIT может иметь множество разных схем, чтобы создавать записи и атрибуты, которые ему нужны.

Схемы часто включают дополнительные определения атрибутов и могут потребовать атрибуты, определенные в других схемах. Например, objectClass person, о котором мы говорили ранее, требует, чтобы атрибут surname или sn были установлены во всех записях, которые используют objectClass person. Если они не определены на LDAP-сервере, схема, содержащая эти определения, может использоваться для добавления этих определений в словарь.

Формат схемы в основном представляет собой комбинацию указанных выше записей, например:

. . .
objectclass ( 2.5.6.6 NAME ‘person’ DESC ‘RFC2256: a person’ SUP top STRUCTURAL
MUST ( sn $ cn )
MAY ( userPassword $ telephoneNumber $ seeAlso $ description ) )
attributetype ( 2.5.4.4 NAME ( ‘sn’ ‘surname’ )
DESC ‘RFC2256: last (family) name(s) for which the entity is known by’ SUP name )
attributetype ( 2.5.4.4 NAME ( ‘cn’ ‘commonName’ )
DESC ‘RFC4519: common name(s) for which the entity is known by’ SUP name )
. . .


Организация данных

Мы рассмотрели общие элементы, которые используются для создания записей в системе LDAP, и узнали о том, как эти блоки определяются в системе. Теперь нужно посмотреть, как в LDAP DIT организована и структурирована информация.

Размещение записей в DIT

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

Вершина DIT – это самая широкая категория, которая так или иначе является родительской для всех узлов. Как правило, самая верхняя запись просто используется как метка, указывающая организацию, для которой используется DIT. Эти записи могут быть представлены любыми объектными классами, но обычно они создаются с помощью компонентов домена (dc=example,dc=com для example.com), расположения (l=new_york,c=us) или организационных сегментов (ou=marketing,o=Example_Co).

Илон Маск рекомендует:  Программирование клиентских приложений с использованием flash

Записи организации (папки) часто используют организационный объект object >

Именование и ссылки на записи в DIT

Мы ссылаемся на записи по их атрибутам. Это означает, что каждая запись должна иметь атрибут или группу атрибутов, которые однозначны на своем уровне в иерархии DIT. Этот атрибут или группа атрибутов называется относительным отличительным именем записи (или RDN) и функционирует как имя файла.

Чтобы однозначно сослаться на запись, используйте RDN записи в сочетании со всеми RDN-элементами своих родительских записей. Эта цепочка RDN возвращает к вершине иерархии DIT и обеспечивает однозначный путь к рассматриваемой записи. Эта цепочка называется отличительным именем записи (или DN). DN для записи указывается во время создания, чтобы система LDAP знала, где разместить новую запись (тогда RDN записи не будет использоваться другой записью).

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

Например, запись для человека по имени John Smith может быть помещена под записью «People» для организации example.com. Поскольку в организации может быть несколько человек по имени John Smith, ID пользователя может быть лучшим выбором для RDN записи. Запись может быть указана следующим образом:

dn: u > objectClass: inetOrgPerson
cn: John Smith
sn: Smith
uid: jsmith1

Здесь нужно использовать objectClass inetOrgPerson, чтобы получить доступ к атрибуту uid в этом экземпляре (у вас все еще есть доступ ко всем атрибутам, определенным в объекте personClass).

Наследование LDAP

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

Наследование objectClass

Каждый objectClass – это класс, который описывает характеристики объектов этого типа.

Однако, в отличие от простого наследования, объекты в LDAP могут быть и часто являются экземплярами нескольких классов (некоторые языки программирования предоставляют аналогичную функциональность посредством множественного наследования). Это возможно, потому что концепция LDAP класса – это просто набор атрибутов, которые он должен или может иметь (MUST или MAY). Это позволяет указать для записи несколько классов (хотя может и должен присутствовать только один objectClass STRUCTURAL), в результате чего объект просто имеет доступ к объединенной коллекции атрибутов с наивысшим объявлением MUST или MAY.

В своем определении objectClass может идентифицировать родительский objectClass, из которого можно наследовать его атрибуты. Это делается с помощью SUP, за которым следует objectClass для наследования. Например, objectClass organizationalPerson начинается следующим образом:

objectclass ( 2.5.6.7 NAME ‘organizationalPerson’ SUP person STRUCTURAL
. . .

Родительский objectClass следует за идентификатором SUP. Родитель должен использовать тип objectClass определяемого objectClass (например, STRUCTURAL или AUXILIARY). Дочерний objectClass автоматически наследует атрибуты и требования родительского.

При назначении objectClass нужно указать только конкретного потомка цепочки наследования, чтобы получить доступ ко всем атрибутам. В последнем разделе мы использовали это, чтобы указать inetOrgPerson как единственный objectClass для записи John Smith, все еще имея доступ к атрибутам, определенным в классах person и organizationPerson. Иерархия наследования inetOrgPerson выглядит следующим образом:

inetOrgPerson -> organizationalPerson -> person -> top

Почти все деревья наследования objectClass заканчиваются специальным objectClass под названием «top». Это абстрактный objectClass, единственная цель которого – потребовать, чтобы объект objectClass был установлен. Он используется для обозначения верхушки цепочки наследования.

Наследование атрибутов

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

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

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

Варианты протокола LDAP

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

Стоит отметить некоторые варианты LDAP в обычном формате:

  • ldap://: Это базовый протокол LDAP, который позволяет осуществлять структурированный доступ к службе каталогов.
  • ldaps://: Этот вариант используется для поддержки LDAP по протоколу SSL/TLS. Обычный LDAP-трафик не зашифрован, хотя большинство реализаций LDAP поддерживают его. Этот метод шифрования соединений LDAP фактически устарел, и вместо этого рекомендуется использовать шифрование STARTTLS. Если вы работаете с LDAP по небезопасной сети, настоятельно рекомендуется перестать это делать и настроить шифрование.
  • ldapi://: Поддержка LDAP на IPC. Это часто используется для безопасного соединения с локальной системой LDAP в административных целях. Он связывается с внутренними сокетами вместо открытого сетевого порта.

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

Заключение

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

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

ldap_get_attributes

ldap_get_attributes — получает атрибуты из вхождения результата поиска.

Описание

array ldap_get_attributes (resource link_identifier, resource result_entry_identifier)

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

ldap_get_attributes() используется для упрощения чтения атрибутов и значений из вхождения в результате поиска.
return-значение это многомерный массив атрибутов и значений.

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

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

Мой список ошибок выглядит следующим образом

Я не буду теперь делать то, что должен сделать код, но исключение говорит вам, что вы вставляете только

Код ошибки 32 — это объект, который не найден, или ошибка неправильного пути DN. Вы должны дать ему реальный и действительный DN для использования.

Вы отправили сообщение на печать так, чтобы строка ошибки: оставшееся имя ‘cn = name1 name2, ou = mycompany’ изменило значения или является реальным кодом ошибки?

Илон Маск рекомендует:  Моделирование при сжатии текстовых данных адаптированные и неадаптированные модели


Это выглядит странно, поскольку в другом месте вы не ссылаетесь на этот путь в своем коде. Я отмечаю, что вы используете домен (возможно, AD) с dc = mydomain, dc = com.

Вы, вероятно, можете уйти с относительными путями, но я сомневаюсь, что во время переименования, где вы меняете RDN, важно точно знать, что вы меняете (и неявно) туда.

Что такое код ldap_first_attribute

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.

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