Что такое код ldap_first_entry

Содержание

аутентификация — PHP ldap_get_entries () возвращает счетчик = ноль

Я пытаюсь аутентифицировать логин пользователей по LDAP (сервер Mac El Capitan).

Я могу успешно подключиться и привязаться к серверу ldap.

Я могу искать и сортировать результат.

Но когда я выполняю «ldap_get_entries», я получаю запись «Ноль».

Я перепробовал все от StackOverFlow до второй страницы Google.

Любые предложения или идеи, почему это может происходить?

‘; echo » «; $fentry= ldap_first_entry($ldap, $result); echo «First Entry = «.$fentry; for ($i=0; $i 1) break; echo «

You are accessing «. $info[$i][«sn»][0] .», » . $info[$i][«givenname»][0] .»
(» . $info[$i][«samaccountname»][0] .»)

\n»; echo »; $userDn = $info[$i][«distinguishedname»][0]; > ldap_close($ldap); > else< echo "Cannot Connect To LDAP."; >>> ?>

Я могу подключиться — связать — поиск Но «ldap_get_entries ()» возвращает ноль.

Решение

Во-первых: вы можете пропустить or die «Could not connect to LDAP Server» как это почти никогда не произойдет. ldap_connect только проверяет параметр на синтаксическую корректность и делает не на самом деле подключиться к серверу. Фактическое соединение происходит при первом обращении к серверу, который обычно ldap_bind , Вот почему проблемы с убеждениями часто всплывают на ldap_bind и не на ldap_connect ,

Второе: где вы взяли samAccountName от? Это поле, которое обычно используется ActiveDirectory. В Apple OpenDirectory пользователь обычно идентифицируется uid атрибута по. Так что ваш фильтр должен быть sprintf(‘u >,

Третье: я сомневаюсь, что только пользователи в группе «Администраторы открытого каталога» могут привязывать против LDAP. Они, конечно, единственные, кому разрешено редактировать каталог, но любой другой пользователь может привязывать также.

В-четвертых: ldap_sort сейчас устарела. Это не сортировка на стороне сервера, а на стороне клиента. Таким образом, сортируются только возвращенные результаты. Если у вас есть постраничные результаты, это означает, что — даже если вы отсортировали результат — все равно будут записи, которые будут помещаться прямо между вашими результатами. В настоящее время я работаю над способом использования серверной сортировки, но это зависит от функции, которая будет доступна на сервере. Таким образом, вы можете использовать ldap_sort, но вы также можете реализовать собственную сортировку в наборе результатов.

Так что поменяйте фильтр на u > и вы получите ожидаемые результаты. mail Атрибут также может содержать полный адрес электронной почты и поэтому может потерпеть неудачу! Вы также можете адаптировать фильтр для поиска более одного поля. Посмотри на этот слайд для коротких примеров.

Другие решения

Решил это. Я использовал «почту» вместо «sAMAccountName».
Вот подробности —

Уроки учатся здесь —

Используйте «LDAP Admin Tool» или какой-нибудь LDAP Tool, чтобы понять структуру вашей среды LDAP, прежде чем приступать к программированию. Большой урок усвоен.

ldap_first_attribute function

For a given directory entry, the ldap_first_attribute function returns the first attribute.

Syntax

Parameters

The session handle.

The entry whose attributes are to be stepped through, as returned by ldap_first_entry or ldap_next_entry.

The address of a pointer used internally to track the current position in the entry.

Return Value

A pointer to a null-terminated string. If the function succeeds, it returns a pointer to an allocated buffer that contains the current attribute name. When there are no more attributes to step through, it returns NULL. The session error parameter in the LDAP data structure is set to 0 in either case.

If the function fails, it returns NULL and sets the session error parameter in the LDAP data structure to the LDAP error code.

Remarks

Use ldap_first_attribute in conjunction with ldap_next_attribute to step through the list of attribute types returned with an entry. You can then pass these attribute names in a call to ldap_get_values to retrieve their associated values.

A call to ldap_first_attribute allocates, and returns through the ptr parameter, a pointer to a BerElement structure. Pass this pointer to ldap_next_attribute to track the current position in the list of attributes. When you have finished stepping through a list of attributes and ptr is non-NULL, free the pointer by calling ber_free( ptr, 0 ). Be aware that you must pass the second parameter as 0 (zero) in this call.

Both ldap_first_attribute and ldap_next_attribute return a pointer to an allocated buffer containing the current attribute name. Free this buffer, when no longer required, by calling ldap_memfree. Because this buffer is overwritten on the next call to either ldap_first_attribute or
ldap_next_attribute, the user should make a copy of the attribute name if it must be preserved for processing.

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

XLIX. Функции LDAP

LDAP это Lightweight Directory Access Protocol — протокол, используемый для доступа к «Directory Servers». Directory это особый вид базы данных, которая содержит информацию как древовидную структуру.

Концепция аналогична структуре директорий жёсткого диска, но в данном контексте root/корневая директория это «The world/Земной шар», а первый уровень поддиректорий это «countries/страны». Ещё ниже идут уровни структуры директорий, содержащие вхождения для companies/компаний, organisations/организаций или мест, а ещё ниже находятся вхождения директорий для people/людей и, возможно, оборудования или документов.

Чтобы обратиться к файлу в поддиректории на жёстком диске, вы вводите что-нибудь вроде

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

Илон Маск рекомендует:  Шаблон сайта путешествие HTML, CSS, Шрифты, Photoshop (psd), 2 страницы

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

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

Запятая работает как слэш, а последовательность читается справа налево. Вы можете прочитать это dn как .

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

Точно так же, поскольку нет твёрдых правил организации структуры директорий на жёстком диске, directory server manager (менеждер сервера директорий) может настроить любую структуру, необходимую для осуществления поставленных задач. Однако есть некоторые соглашения, которые при этом используются: вы не можете записать код для доступа к серверу директорий, если не знаете его структуру, хотя можете использовать БД без знания того, что доступно.

Запрашиваем информацию для всех вхождений, где фамилия начинается с «S», с сервера директорий и отображаем их с именем и email-адресом.

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

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

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


Имя или адрес сервера директорий, который вы будете использовать

«base dn» сервера (часть world-директории, которая содержится на этом сервере, которая может быть «o=My Company,c=US»)

Нужен ли вам пароль для доступа к этому серверу (многие серверы предоставляют доступ для чтения для «anonymous bind», но требуют пароля для других действий)

Типичная последовательность вызова LDAP в вашем приложении будет соответствовать такому патэрну:

ldap_connect() // установить соединение с сервером
|
ldap_bind() // anonymous/анонимный или аутентифицированный «login»
|
сделать что-нибудь типа поиска или обновления директории
и вывести результаты
|
ldap_close() // «logout»

Большое количество информации о LDAP можно найти на:

Netscape SDK содержит хороший Programmer’s Guide в формате .php.

Основы протокола 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).

Записи организации (папки) часто используют организационный объект 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.

Централизованная аутентификация с использованием OpenLDAP

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

Contents

Введение в OpenLDAP

Что такое LDAP?

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

X.500 является моделью для сервисов каталога (Directory Services) в концепции OSI. Он содержит определения пространства имен (namespace) и протоколы для запросов и обновления каталога. Однако, существует немало случаев, когда полноценная функциональность X.500 не требуется. Встречайте LDAP. Как и X.500, он обеспечивает модель данные/пространство имен для каталога и протокола. Однако LDAP разработан для прямой работы через стек TCP/IP. Можно считать LDAP сокращенной версией X.500.

Что такое каталог (directory)?

Каталог — это специализированная база данных, созданная для частых запросов, но нечастых обновлений. В отличие от обычных баз данных, каталог не поддерживает транзакции (transaction) или функциональности отката (roll-back). Каталоги легко дублируются для улучшения доступности и надежности. При дублировании каталогов допускаются временные противоречия при условии, что позже они будут синхронизированы.

Как осуществляется структурирование информации?

Вся информация в каталоге структурирована иерархически. Более того, для того, чтобы внести данные в каталог, каталог должен знать, как хранить эти данные в дереве. Рассмотрим вымышленную компанию и дерево, подобное Интернет:

Поскольку данные не записываются в базу в подобной манере ascii-art, каждый элемент этого дерева должен быть определен. Для названий элементов LDAP использует схему наименований. Большая часть дистрибутивов LDAP (включая OpenLDAP) включает в себя определенное количество предопределенных (и одобренных) схем, таких как inetOrgPerson, или часто используемая схема для определения пользователей, которую могут использовать Unix/Linux-системы, которая называется posixAccount. Существуют утилиты графического интерфейса, основанные на веб, для упрощения управления LDAP: раздел Работа с OpenLDAP содержит неполный список таких утилит.

Заинтересованным пользователям рекомендуется прочитать OpenLDAP Admin Guide.

Для чего же его можно использовать?

LDAP можно использовать для разнообразных нужд. В этой статье описывается централизованное управление пользователями, хранение всех учетных записей пользователей в одном местонахождении LDAP (что не означает, что оно находится на одном сервере — LDAP поддерживает высокую доступность (high availability) и резервирование (redundancy)), однако LDAP может использоваться и в других целях.

  • инфраструктура открытых ключей
  • общий календарь
  • общая адресная книга
  • хранилище для DHCP, DNS, .
  • System > Настройка сервера OpenLDAP

    Общие примечания

    Это руководство использует домен genfic.org в качестве примера. Естественно, вам нужно будет изменить это название. Однако убедитесь, что верхний элемент является официальным доменом верхнего уровня (net, com, cc, be, . ).

    USE flags for net-nds/openldap LDAP suite of application and development tools

    berkdb Add support for sys-libs/db (Berkeley DB for MySQL)
    crypt Add support for encryption — using mcrypt or gpg where applicable
    cxx Build support for C++ (bindings, extra libraries, code generation, . )
    debug Enable extra debug codepaths, like asserts and extra output. If you want to get meaningful backtraces see https://wiki.gentoo.org/wiki/Project:Quality_Assurance/Backtraces
    experimental Enable experimental backend options
    gnutls Prefer net-libs/gnutls as SSL/TLS prov >
    iodbc Add support for iODBC library
    ipv6 Add support for IP version 6
    kerberos Add kerberos support
    kinit Enable support for kerberos init
    libressl Use dev-libs/libressl instead of dev-libs/openssl when applicable (see also the ssl useflag)
    minimal Build libraries & userspace tools only. Does not install any server code
    odbc Enable ODBC and SQL backend options
    overlays Enable contributed OpenLDAP overlays
    pbkdf2 Enable support for pbkdf2 passwords
    perl Add optional support/bindings for the Perl language
    samba Add support for SAMBA (Windows File and Printer sharing)
    sasl Add support for the Simple Authentication and Security Layer
    selinux !!internal use only!! Security Enhanced Linux support, this must be set by the selinux profile or breakage will occur
    sha2 Enable support for pw-sha2 password hashes
    slp Add Service Locator Protocol support
    smbkrb5passwd Enable overlay for syncing ldap, unix and lanman passwords
    ssl Add support for SSL/TLS connections (Secure Socket Layer / Transport Layer Security)
    static-libs Build static versions of dynamic libraries as well
    syslog Enable support for syslog
    tcpd Add support for TCP wrappers
    test Enable dependencies and/or preparations necessary to run tests (usually controlled by FEATURES=test but can be toggled independently)

    Сначала установим OpenLDAP. Убедитесь в том, что USE-флаги syslog , -minimal (отключено) и tcpd установлены.

    OpenLDAP поддерживает два механизма аутентификации:

    1. стандартный пользователь/пароль (в терминологии LDAP пользователь подразумевает binddn), называемый SIMPLE
    2. запросы проксирования авторизации SASL (Simple Authentication and Security Layer, смотрите RFC4422)

    Although the OpenLDAP default is to use SASL, the initial version of this article used only password-based authentication. With the OLC add-on the article starts to describe the use of the simplest SASL mechanism called EXTERNAL, which relies on the system authentication.

    У OpenLDAP есть основной пользователь, «rootdn» (Root Distinguished Name), встроенный в приложение. В отличие от традиционного пользователя root Unix, пользователю rootdn необходимо предоставить соответствующие права доступа. Пользователя rootdn можно использовать только в контексте конфигурации, однако его также можно использовать в определении каталога. В этом случае пользователь может аутентифицироваться как rootdn либо с помощью пароля конфигурации, либо с помощью пароля дерева (основанного на каталоге).

    В целях верификации, пароли пользователей (как пользователей rootdn, так и других) можно хранить в виде простого текста, либо в хешированном (hashed) виде. Доступно несколько хеш-алгоритмов, но не рекомендуется использовать слабые алгоритмы (вплоть до MD5). На данный момент, SHA считается достаточно безопасным с точки зрения криптографии.

    В нижеприведенной команде хешированное значение создается для данного пароля; результат этой команды можно использовать в файле конфигурации slapd.conf либо во внутреннем определении пользователя в каталоге:

    Устаревшая конфигурация (через slapd.conf)

    Теперь отредактируйте конфигурацию сервера LDAP в файле /etc/openldap/slapd.conf . Предоставленный файл slapd.conf , взят из оригинального архива исходного кода OpenLDAP. Ниже приведен пример файла конфигурации, которым его можно заменить.

    Для более подробного анализа файла конфигурации рекомендуем изучить OpenLDAP Administrator’s Gu >man 5 slapd.conf будет достаточно.

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

    Измените уровень отладки («-d 1» выше), чтобы получить больше информации. Если все в порядке, будет отображено сообщение config file testing succeeded. В случае ошибки, slaptest выведет номер строки в файле slapd.conf , содержащей ошибку.

    By default slapd writes the log events to the local4 syslog facility.

    Миграция с slapd.conf на OLC

    Чтобы иметь возможность изменения конфигурации сервера OpenLDAP, необходимо определить как минимум доступ для записи write (или, как правило, для управления manage ) в cn=config .

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

    Затем, мы вызываем утилиту slaptest с параметрами -f и -F чтобы сконвертировать файл slapd.conf в каталог конфигураций ( slapd.d ).

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

    Для дополнительных инструкций прочитайте in-line комментарии сгенерированных файлов.

    Нижеприведенная строка включает метод конфигурации slapd.d/ .

    Наконец, создайте структуру /var/lib/openldap-data :

    Initial setup with OLC

    An initial configuration is shipped as a standard LDAP database dump, available as slapd.ldif or config.ldif .

    It can be loaded (and only loaded, unlike ordinary LDAP databases) by the slapadd utility:

    When using a root account, be sure to correct ownership of the files created by root, as described below in migrate section.

    For the right to change the configuration database, proper permissions must be prov >root system user:

    Для более подробной информации смотрите man 5 slapd-config .

    When using OLC, never manually edit the configuration files. The directory files can be used to check the consistency of the configuration through:

    Обслуживание каталога

    После завершения конфигурации запустите slapd :

    Большинство пользователей также захотят запускать демон OpenLDAP автоматически:

    Теперь можно использовать сервер каталога для аутентификации пользователей в apache/proftpd/qmail/samba.

    The directory server can be managed with tools such as net-nds/phpldapadmin, app-admin/diradm and net-nds/jxplorer from the Gentoo ebuild repository, or app-misc/ldapexplorertool from the poly-c overlay available through Layman or eselect repository.

    Server management with OLC

    Ниже приводится несколько примеров обновления конфигурации в стиле OLC.

    Например, чтобы изменить местонахождение каталога конфигурации OLC (необходимо после миграции с конфигурационного файла на каталог конфигураций):

    Чтобы изменить уровень журнала, используемого процессом OpenLDAP:

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

    Журналирование в OpenLDAP

    OpenLDAP produces numerous log events, which might not be obvious to interpret, but are necessary for debugging purposes.

    As OpenLDAP by default writes the log events into the system log, it is advisable to reconfigure the system logger to direct OpenLDAP log events into a dedicated log file.

    It is advisable to use the stats stats2 log level in OpenLDAP standalone server and stats stats2 sync in OpenLDAP cluster. In such case query results logs session-related information such as the following:

    Most common errors in server log are err=49 :

    Which means «invalid credentials» (i.e. wrong password).

    Which means «No such object». Usually this error appears when binddn (user) has no permissions on requested object. So either try to do something wrong, or there is a mistake in the set ACLs.

    Управление доступом (ACL)

    Механизм авторизации и контроль доступа, используемые в OpenLDAP, описан в man-странице slaps.access . Основной синтаксис выглядит следующим образом:

    Таблица ниже показывает уровни доступа доступные в OpenLDAP:

    Access level Privileges Description
    none no access
    disclose d needed for information disclosure on error
    auth dx needed to authenticate (bind)
    compare cdx needed to compare
    search scdx needed to apply search filters
    read rscdx needed to read search results
    add|delete> wrscdx needed to modify/rename
    manage mwrscdx needed to manage

    For details about the exact privilege settings, see the manual pages and official OpenLDAP documentation.

    Конфигурационный файл

    ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. For more information, see Access Control Evaluation.

    Конфигурационный каталог

    ACLs are parsed in the order they are set in the configuration, and are applied based on the specificity (meaning that, when an ACL rule is considered, the remainder of ACL rules is no longer checked). As such, more specific definitions should go first, before more generic ones are listed. This order, when using OLC, is handled through the olcAccess directives.

    The following example inserts a new ACL on top, making the existing olcAccess entries to shift by one:

    Чтобы удалить ACL:

    Дублирование

    Высокая доступность

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

    Replication within OpenLDAP is, in this guide, set up using a specific replication account ( ldapreader ) which has read rights on the primary LDAP server and which pulls in changes from the primary LDAP server to the secondary.

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

    Настройка дублирования

    Для того, чтобы настроить дублирование, сначала настройте второй сервер OpenLDAP подобно тому, как описано выше. Однако обратите внимание на то, что в файле конфигурации:

      sync replication prov > Заметка
      Using a mirrored installation means that the OpenLDAP service should be configured like a single server installation, so the serverID value on each of the nodes must be the same. Instances are identified by rid values, which must be unique.

    Synchronisation account

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

    Enabling syncprov overlay

    Overlay can be linked statically and dynamically. When it is built dynamically, you’ll need to load module. For now in Gentoo it’s usually built statically. To ensure type:

    Load syncprov module (optional)

    To load syncprov module, use the following ldif file:

    Setting up replication for database

    Next step, mandatory for everybody, is to setup replication for database (must be done on both nodes):

    Final configuration

    Finally, add replication’s definition.

    secret traditionally means the password string.

    The only difference is in server’s ident (rid) and provider uri.

    If LDAP master (mirror node with initially loaded database) is unavailable (slapd daemon not started, or 389/tcp port is blocked by a packet filter) slapd daemon on secondary node fails to start with the following error message:

    Almost certainly the database will not fit into default limits. So, you will need to increase ldapreader ‘s limits. For example:

    Performance tuning

    Default daemon settings significantly limitates LDAP server performance.

    Sympthoms

    When server load fits system limit client applications fails with different kind of timeout errors.

    In server log this produces error messages like following:

    Encreasing OS limits

    First, read ldap system user limits:

    The first parameter, you need to increase, is the open files limit.

    Maximum available value is described in Documentation/sysctl/fs.txt file of kernel documentation:

    PAM system limits are stored in /etc/security/limits.conf file or, optionally, in /etc/security/limits.d/ directory. Daemons, started with sys-apps/openrc init system use these parameters (see sys-apps/openrc: start-stop-daemon should use system-services PAM stack for details), so you need just to put in the file:

    And restart daemon.

    The next limitation is sysctl ‘s net.core.somaxconn parameter.

    During run time, this value can be updated via:

    After verifying new value do not forget to fix it:

    And, possibly, some other application-specific parameters.

    Настройка клиентских утилит OpenLDAP

    Отредактируйте файл конфигурации клиента LDAP. Этот файл читается командой ldapsearch и другими ldap-утилитами командной строки.

    Запущенный сервер можно протестировать с помощью следующей команды:

    В случае возникновения ошибки, попробуйте добавить -d 255 для увеличения детализации вывода.

    Настройка клиента для централизованной аутентификации

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

    • SSSD (Single Sign-on Services Daemon). Его основная функция — обеспечение доступа к identity и аутентификационного удаленного ресурса посредством общей структуры, которая способна предоставлять кеширование и оффлайн поддержку для системы. Он предоставляет модули PAM и NSS, и в будущем будет поддерживать интерфейсы D-Bus для расширенной пользовательской информации. Он также предоставляет лучшую базу данных для хранения локальных пользователей, а также расширенных пользовательских данных.
    • Используйте pam_ldap для входа на сервер LDAP и аутентификации. Пароли не посылаются по сети в виде простого текста.
    • NSLCD (Name Service Look up Daemon). Схож с SSSD, но старше его.
    • NSS (Name Service Switch) с использованием традиционного модуля pam_unix для загрузки хешей паролей по сети. Чтобы разрешить пользователям обновлять пароли, этот метод нужно использовать совместно с методом pam_ldap .

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

    Настройка клиента PAM метод SSSD

    Здесь представлен более краткий метод. Ниже приводятся три файла, которые необходимо отредактировать.

    Добавьте sss в конце как показано ниже, чтобы включить передачу поиска имени системному сервису sssd. После завершения редактирования запустите демон sssd.

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

    Теперь попробуйте войти в систему с другого компьютера.

    Настройка клиента PAM метод модуль pam_ldap

    Сначала настроим PAM таким образом, чтобы разрешить авторизацию LDAP. Установите sys-auth/pam_ldap, чтобы PAM поддерживал авторизацию LDAP, и sys-auth/nss_ldap, чтобы система могла справиться с серверами LDAP для дополнительной информации (используется файлом nsswitch.conf ).

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

    Теперь отредактируйте /etc/ldap.conf следующим образом:

    Далее скопируйте файл (OpenLDAP) ldap.conf с сервера на клиент, чтобы клиенты знали об окружении LDAP:

    Наконец, настройте клиентов таким образом, чтобы они проверяли LDAP на наличие системных учетных записей:

    Возможно, вы заметили, что одна из строк, скопированных в файл /etc/ldap.conf , была закомментирована (строка rootbinddn ): она нужна только в том случае, если требуется изменять пароли пользователей пользователем root. В этом случае нужно поместить пароль пользователя root с помощью команды echo в файл /etc/ldap.secret в виде простого текста. Это ОПАСНО, и права доступа к этому файлу следует установить в 600. Возможный вариант — держать этот файл пустым, и в случае возникновения необходимости изменить чей-либо пароль, находящийся и в LDAP и в /etc/passwd , поместить в этот файл пароль на 10 секунд, пока производится изменение пароля пользователя, после чего удалить его.

    Перенесение существующих данных на LDAP

    Настройка OpenLDAP для централизованного администрирования и управления привычными объектами Linux/Unix непроста, но, благодаря некоторым утилитам и сценариям, доступным в Интернете, задача перенесения системы с администрирования одной системы на центрально управляемую систему на основе OpenLDAP не так уж сложна.

    Загрузите сценарии с https://www.padl.com/OSS/MigrationTools.html. Вам понадобятся утилиты перенесения и сценарий make_master.sh .

    Затем распакуйте утилиты и скопируйте сценарий make_master.sh в распакованное местонахождение:

    Следующий шаг — перенести информацию с системы на OpenLDAP. Это осуществляется с помощью сценария make_master.sh , после предоставления ему информации о структуре и окружении LDAP.

    На момент написания, утилитам требуется следующий ввод:

    Ввод Описание Пример
    LDAP BaseDN Базовое местонахождение (root) дерева dc=genfic,dc=org
    Почтовый домен Домен, используемый для адресов электронной почты genfic.org
    Почтовый хост FQDN инфраструктуры почтового сервера smtp.genfic.org
    LDAP Root DN Информация об административной учетной записи структуры LDAP cn=Manager,dc=genfic,dc=org
    Пароль пользователя Root LDAP Пароль для административной учетной записи, cfr ранее команда slappasswd

    Утилита также запросит, какие учетные записи и настройки следует перенести.

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

    Сразу оговорюсь, что я простой админ локал-хоста и в таких энтерпрайзных вещах, как сервера директорий ничего не понимал до сегодняшнего дня, так что статья из разряда «чайникам от чайника» — что и как понял, то и рассказываю. Энтерпрайзных задач тоже не стояло — пока просто сделать централизованную авторизацию сервисов, без всяких там 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 тоже умеет авторизацию в лдапе, но настраивается чуть хуже.
    Вот такой конфиг у меня получился:

    Активируем LDAP over SSL (LDAPS) в Windows Server 2012 R2

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

    Так, например, операция смены пароля должна обязательно осуществляться через безопасный канал (например Kerberos или SSL/TLS). Это означает, что например, с помощью функции-php, обеспечивающей работу с AD по протоколу LDAP изменить пароль пользователя в домене не удастся.

    Защитить данные, передаваемых по протоколу LDAP между клиентом и контроллером домена можно с помощью SSL версии протокола LDAP – LDAPS, который работает по порту 636 (LDAP «живет» на порту 389). Для этого на контроллере домена необходимо установить специальный SSL сертификат. Сертификат может быть как сторонним, выданным 3-ей стороной (например, Verisign), самоподписанным или выданным корпоративным центром сертификации.

    В этой статье мы покажем, как с помощью установки сертификата задействовать LDAPS (LDAP over Secure Sockets Layer) на котроллере домена под управление Windows Server 2012 R2. При наличии требуемого сертификата служба LDAP на контроллере домена может устанавливать SSL соединения для передачи трафика LDAP и трафика сервера глобального каталога (GC).

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

    Предположим, в вашей инфраструктуре уже развернут корпоративный удостоверяющий сервер Certification Authority (CA). Это может быть как полноценная инфраструктура PKI, так и отдельной-стоящий сервер с ролью Certification Authority.

    На севере с ролью Certification Authority запустите консоль Certification Authority Management Console, выберите раздел шаблонов сертификатов (Certificate Templates ) и в контекстном меню выберите Manage.

    Найдите шаблон Kerberos Authentication certificate и создайте его копию, выбрав в меню Duplicate Template.

    На вкладке General переименуйте шаблон сертификата в LDAPoverSSL, укажите период его действия и опубликуйте его в AD (Publish certificate in Active Directory).

    На вкладке Request Handling поставьте чекбокс у пункта Allow private key to be exported и сохраните шаблон.

    На базе созданного шаблона, опубликуем новый тип сертификата. Для этого, в контекстном меню раздела Certificate Templates выберем пункт New -> Certificate Template to issue.

    Из списка доступных шаблонов выберите LDAPoverSSL и нажмите OK.

    На контроллере домена, для которого планируется задействовать LDAPS, откройте оснастку управления сертификатами и в хранилище сертификатов Personal запросим новый сертификат (All Tasks -> Request New Certificate).

    В списке доступных сертификатов выберите сертификат LDAPoverSSL и нажмите Enroll (выпустить сертификат).

    Следующее требование – необходимо, чтобы контроллер домена и клиенты, которые будут взаимодействовать через LDAPS доверяли удостоверяющему центру (CA), который выдал сертификат для контроллера домена.

    Если это еще не сделано, экспортируем корневой сертификат удостоверяющего центра в файл, выполнив на сервере с ролью Certification Authority команду:
    certutil -ca.cert ca_name.cer

    А затем добавьте экспортированный сертификат в контейнере сертификатов Trusted Root Certification Authorities хранилища сертификатов на клиенте и контроллере домена. Сделать это можно через вручную через оснастку управления сертификатами, через GPO или из командной строки (подробнее здесь).

    certmgr.exe -add C:\ca_name.cer -s -r localMachine ROOT

    Необходимо перезапустить службы Active Directory на контроллере домена, либо целиком перезагрузить DC.

    Осталось протестировать работу по LDAPS. Для этого на клиенте запустим утилиту ldp.exe и в меню выбираем Connection-> Connect->Укажите полное (FQDN) имя контроллера домена, выберите порт 636 и отметьте SSL -> OK. Если все сделано правильно, подключение должно установиться.

    ldap_first_entry

    ldap_first_entry — Return first result id

    Описание

    Returns the entry >ldap_next_entry() routine to get successive entries from the result.

    Entries in the LDAP result are read sequentially using the ldap_first_entry() and ldap_next_entry() functions.

    Список параметров

    Возвращаемые значения

    Returns the result entry identifier for the first entry on success and FALSE on error.

    Смотрите также

    НОВОСТИ ФОРУМА
    Рыцари теории эфира
    01.10.2020 — 05:20: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
    [center][Youtube]69vJGqDENq4[/Youtube][/center]
    [center]14:36[/center]
    Osievskii Global News
    29 сент. Отправлено 05:20, 01.10.2020 г.’ target=_top>Просвещение от Вячеслава Осиевского — Карим_Хайдаров.
    30.09.2020 — 12:51: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
    [center][Ok]376309070[/Ok][/center]
    [center]11:03[/center] Отправлено 12:51, 30.09.2020 г.’ target=_top>Просвещение от Дэйвида Дюка — Карим_Хайдаров.
    30.09.2020 — 11:53: ВОСПИТАНИЕ, ПРОСВЕЩЕНИЕ, ОБРАЗОВАНИЕ — Upbringing, Inlightening, Education ->
    [center][Youtube]VVQv1EzDTtY[/Youtube][/center]
    [center]10:43[/center]

    интервью Раввина Борода https://cursorinfo.co.il/all-news/rav.
    мой телеграмм https://t.me/peshekhonovandrei
    мой твиттер https://twitter.com/Andrey54708595
    мой инстаграм https://www.instagram.com/andreipeshekhonow/

    [b]Мой комментарий:
    Андрей спрашивает: Краснодарская синагога — это что, военный объект?
    — Да, военный, потому что имеет разрешение от Росатома на манипуляции с радиоактивными веществами, а также иными веществами, опасными в отношении массового поражения. Именно это было выявлено группой краснодарцев во главе с Мариной Мелиховой.

    [center][Youtube]CLegyQkMkyw[/Youtube][/center]
    [center]10:22 [/center]

    Доминико Риккарди: Россию ждёт страшное будущее (хотелки ЦРУ):
    https://tainy.net/22686-predskazaniya-dominika-rikardi-o-budushhem-rossii-sdelannye-v-2000-godu.html

    Завещание Алена Даллеса / Разработка ЦРУ (запрещено к ознакомлению Роскомнадзором = Жид-над-рус-надзором)
    http://av-inf.blogspot.com/2013/12/dalles.html

    [center][b]Сон разума народа России [/center]

    [center][Youtube]CLegyQkMkyw[/Youtube][/center]
    [center]10:22 [/center]

    Доминико Риккарди: Россию ждёт страшное будущее (хотелки ЦРУ):
    https://tainy.net/22686-predskazaniya-dominika-rikardi-o-budushhem-rossii-sdelannye-v-2000-godu.html

    Завещание Алена Даллеса / Разработка ЦРУ (запрещено к ознакомлению Роскомнадзором = Жид-над-рус-надзором)
    http://av-inf.blogspot.com/2013/12/dalles.html

    [center][b]Сон разума народа России [/center]

    Что такое код ldap_first_entry

    ldap_first_entry — возвращает первый результирующий id.

    Описание

    resource ldap_first_entry (resource link_identifier, resource result_identifier)

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

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

    Илон Маск рекомендует:  Opengl полезные и бесполезные мелочи
Понравилась статья? Поделиться с друзьями:
Кодинг, CSS и SQL