Что такое код ldap_get_dn

Содержание

/привет/мир/etc

Периодические заметки о программировании

четверг, 31 октября 2013 г.

Что такое LDAP и с чем его едят

Эта статья — кратчайшее введение в LDAP и службы каталогов. Для иллюстрации излагаемого материала я буду пользоваться инструментом Softerra LDAP Browser, который можно свободно скачать с сайта производителя.

Концепцию служб каталогов и требования к их реализации определяет серия стандартов X.500 ITU-T. Здесь каталог — это специализированная база данных, оптимизированная для поиска и извлечения информации, также поддерживающая добавление и изменение данных.

Среди реализаций служб каталогов наиболее известные — OpenLDAP и MS Active Directory. Клиентами каталогов являются адресные книги почтовых клиентов, сетевые службы, такие как DNS, SMTP, корпоративные приложения и информационные системы.

Как правило, служба каталогов

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

Для взаимодействия со службами каталогов X.500 широко используется протокол LDAP (Lightweight Directory Access Protocol), специфицированный в RFC4510. LDAP работает поверх TCP/IP и является легковесной альтернативой протокола DAP (Directory Access Protocol), весьма требовательного к вычислительным ресурсам.

LDAP реализует протокол взаимодействия со службой каталогов и задает модель данных, соответствующую X.500. Эта модель данных такова:

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

Запустим Softerra LDAP Browser и откроем одну из публичных служб каталогов, параметры соединения с которыми предустановлены по умолчанию. (Настроив соединение с MS Active Directory или OpenLDAP в вашей корпоративной сети, вы можете исследовать структуру и содержимое корпоративного каталога.)

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

Текущая выбранная запись в каталоге Carnegie Mellon University (см. картинку выше) имеет уникальное имя DN o=CMRI,o=CMU,dc=cmu,dc=edu . Компоненты DN — имена узлов иерархической структуры от корневого до текущего (справа налево). Самый левый компонент DN называется относительным уникальным именем (Relative Distinguished Name, RDN). Таким образом, DN o=CMRI,o=CMU,dc=cmu,dc=edu состоит из RDN o=CMRI и DN родительской записи o=CMU,dc=cmu,dc=edu .

Можно рассматривать DN как абсолютный путь к файлу (по аналогии с файловой системой) или как первичный ключ записи в таблице (по аналогии с реляционной БД).

В рассматриваемом DN o=CMRI,o=CMU,dc=cmu,dc=edu два верхних уровня названы по доменным именам Internet. А уровнем ниже текущей записи располагаются записи, идентифицируемые значением атрибута ou (см. картинку выше). Здесь имена атрибутов, идентифицирующие записи разных уровней, имеют следующие значения:

dc аббревиатура от domain component o аббревиатура от organization ou аббревиатура от organizational unit

Эти имена, как и десятки других, — имена стандартных атрибутов, специфицированных в RFC 2256 и предназначенных для использования в объектных классах, описывающих людей, организации, их подразделения и т.п. Все реализациии LDAP поддерживают эти стандартные типы атрибутов. Вот еще несколько примеров: telephoneNumber , name , givenName , postalAddress , sn (аббревиатура от surname).

В рассматриваемой записи с DN o=CMRI,o=CMU,dc=cmu,dc=edu имеются три атрибута, objectClass , o и businessCategory , по каждому из которых можно искать эту запись в каталоге.

Для поиска записей в LDAP-каталоге задаются три компонента:

base DN (базовое уникальное имя) показывает, откуда в иерархии начать поиск scope (область поиска) показывает область поиска, одно из:

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

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

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

вернет все записи из поддерева с корнем o=CMU,dc=cmu,dc=edu , удовлетворяющие фильтру (синтаксис фильтра в этом примере легко читаемый, но неправильный, см. далее).

На заметку: cуществуют специальные базовые DN для запроса информации о возможностях сервера, для доступа к схеме (schema) и данным мониторинга.

В Softerra LDAP Browser по Ctrl+F3 вызывается окно поиска, в котором удобно экспериментировать с параметрами поиска LDAP:

В фильтре можно использовать следующие проверки для атрибутов (атрибут ou взят для примера):

Заметьте, что отсутствуют проверки > и . Проверка на приближенное равенство

= использует фонетические сравнение. Расширенная проверка для сравнения образца со значением атрибута использует реализованное LDAP-сервером правило, идентификатор которого указан после двоеточия. Примеры выражений для проверки наличия подстроки (звездочка означает 0 или более символов):

Проверки в фильтре можно комбинировать при помощи логических операторов:

Внимание! Последний фильтр с NOT вернет также записи, не содержащие атрибута cn .

Формируя запрос, можно указать типы атрибутов, которые должны быть включены сервером каталога в ответ. Если список типов атрибутов пуст, то окно поиска LDAP Browser отображает идентифицирующие атрибуты найденных записей (это RDN) и DN родительских записей — вместе они образуют DN найденных записей. Поиск LDAP всегда возвращает DN найденных записей, помимо и независимо от списка атрибутов. Зададим явно список атрибутов, которые мы хотим видеть и повторим запрос (несуществующие типы атрибутов в списке игнорируются сервером и не приводят к ошибке):

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

Как уже упоминалось, служба каталогов позволяет не только извлекать, но также добавлять и модифицировать записи. Softerra LDAP Browser поддерживает только просмотр данных в каталоге, поэтому для внесения изменений в каталог необходим другой инструмент (например, платный Softerra LDAP Administrator).

Для работы с LDAP практически из любого языка программирования можно воспользоваться существующими библиотекми для этого языка. В будущих статьях, посвященных LDAP, я рассмотрю работу с MS Active Directory в Oracle PL/SQL и в языке программирования Python.

MNorin.com

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

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

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

Установка OpenLDAP

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

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

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

Схемы LDAP

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

top
organization
organizationalUnit
person
inetOrgPerson

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

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

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

Настройка OpenLDAP

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Илон Маск рекомендует:  hebrevc - Преобразует текст на иврите из логической кодировки в визуальную с преобразованием

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

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

Илон Маск рекомендует:  Собираем компьютер за 40000 рублей. Игровая система

Именование и ссылки на записи в 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.

Active Directory LDAP понять как работает поиск по каталогам?

Вообщем столкнулся со следующей проблемой (непониманием):

Когда мне необходимо выбрать всех юзеров из AD я пишу примерно следующее:

И получаю результаты. Обратите внимание, в $base_dn находится корень AD, хотя сами юзеры не лежат в корне, а находятся в CN=Users

Теперь у меня возникает необходимость выбрать все Подсети из AD и если я в качестве BaseDn укажу корень (DC=example,DC=org), то получаю 0 результатов. Если же указать путь полностью (CN=Subnets,CN=Sites,CN=Configuration,DC=example,DC=org), то оно начинает работать.

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

  • Вопрос задан более трёх лет назад
  • 6163 просмотра

Во-первых: в параметрах поиска вы опускаете один параметр — область поиска (scope). Область поиска по-умолчанию обычно поддерево (SubTree) для заданного basedn.
Во-вторых: следует понимать, что у вас в каталоге AD изначально существует (в типовой конфигурации) 5 разделов. Так вот поиск работает только в пределах одного раздела.
При этом «DC=example,DC=org» — корень раздела домена, а «CN=Configuration,DC=example,DC=org» — корень раздела конфигурации. Поэтому при поиске с basedn = «DC=example,DC=org» и scope = SubTree вы не получите объекты из ветки CN=Configuration,DC=example,DC=org» — они расположены в другом разделе каталога.

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

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

Илон Маск рекомендует:  Что такое код extract

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

Redmine

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

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

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

Что такое код ldap_get_dn

#include
char *ldap_get_dn( LDAP *ld, LDAPMessage *entry )
int ldap_str2dn( const char *str, LDAPDN *dn, unsigned flags )
void ldap_dnfree( LDAPDN dn )
int ldap_dn2str( LDAPDN dn, char **str, unsigned flags )
char **ldap_explode_dn( const char *dn, int notypes )
char **ldap_explode_rdn( const char *rdn, int notypes )
char *ldap_dn2ufn( const char * dn )
char *ldap_dn2dcedn( const char * dn )
char *ldap_dcedn2dn( const char * dn )
char *ldap_dn2ad_canonical( const char * dn )

DESCRIPTION

The ldap_get_dn() routine takes an entry as returned by ldap_first_entry(3) or ldap_next_entry(3) and returns a copy of the entry’s DN. Space for the DN will be obtained dynamically and should be freed by the caller using ldap_memfree(3).

ldap_str2dn() parses a string representation of a distinguished name contained in str into its components, which are stored in dn as ldap_ava structures, arranged in LDAPAVA, LDAPRDN, and LDAPDN terms. Space for dn will be obtained dynamically and should be freed by the caller using ldap_dnfree(3). The LDAPDN is defined as:

The attribute types and the attribute values are not normalized. The la_flags can be either LDAP_AVA_STRING or LDAP_AVA_BINARY, the latter meaning that the value is BER/DER encoded and thus must be represented as, quoting from RFC 4514, » . an octothorpe character (‘#’ ASCII 35) followed by the hexadecimal representation of each of the bytes of the BER encoding of the X.500 AttributeValue.» The flags parameter to ldap_str2dn() can be

which defines what DN syntax is expected (according to RFC 4514, RFC 1779 and DCE, respectively). The format can be ORed to the flags

The latter is a shortcut for all the previous limitations.

LDAP_DN_P_NO_SPACES does not allow extra spaces in the dn; the default is to silently eliminate spaces around AVA separators (‘=’), RDN component separators (‘+’ for LDAPv3/LDAPv2 or ‘,’ for DCE) and RDN separators (‘,’ LDAPv3/LDAPv2 or ‘/’ for DCE).

LDAP_DN_P_NO_SPACE_AFTER_RDN does not allow a single space after RDN separators.

ldap_dn2str() performs the inverse operation, yielding in str a string representation of dn. It allows the same values for flags as ldap_str2dn(), plus

for user-friendly naming (RFC 1781) and AD canonical.

The following routines are viewed as deprecated in favor of ldap_str2dn() and ldap_dn2str(). They are provided to support legacy applications.

The ldap_explode_dn() routine takes a DN as returned by ldap_get_dn() and breaks it up into its component parts. Each part is known as a Relative Distinguished Name, or RDN. ldap_explode_dn() returns a NULL-terminated array, each component of which contains an RDN from the DN. The notypes parameter is used to request that only the RDN values be returned, not their types. For example, the DN «cn=Bob, c=US» would return as either < "cn=Bob", "c=US", NULL >or < "Bob", "US", NULL >, depending on whether notypes was 0 or 1, respectively. Assertion values in RDN strings may included escaped characters. The result can be freed by calling ldap_value_free(3).

Similarly, the ldap_explode_rdn() routine takes an RDN as returned by ldap_explode_dn(dn,0) and breaks it up into its «type=value» component parts (or just «value», if the notypes parameter is set). Note the value is not unescaped. The result can be freed by calling ldap_value_free(3).

ldap_dn2ufn() is used to turn a DN as returned by ldap_get_dn(3) into a more user-friendly form, stripping off all type names. See «Using the Directory to Achieve User Friendly Naming» (RFC 1781) for more details on the UFN format. Due to the ambiguous nature of the format, it is generally only used for display purposes. The space for the UFN returned is obtained dynamically and the user is responsible for freeing it via a call to ldap_memfree(3).

как получить DN в LDAP с идентификатором пользователя, используя UnboundID LDAP SDK

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

также я использую UnboundID Ldap SDK, как вы можете увидеть:

давайте предположим, что мой UID принадлежит к следующему DN

Спасибо от головы

Создан 26 июл. 12 2012-07-26 08:35:59 Nir

1 ответ

Проблемы в данном случае является то, что «соответствует DN » это не то, что вы думаете. Это не DN записи, которая соответствует критериям поиска (на самом деле это может быть ноль, одна или несколько записей). Соответствующий элемент DN ответа может быть предоставлен, если цель операции не существует. Для операции поиска, если вы указали DN базы поиска, которая не существует, соответствующее согласованное DN может указывать DN ближайшей записи на то, что вы указали на самом деле на сервере. Например, если вы указали DN базы поиска «ou = nonexistent, dc = example, dc = com», который не существует, но запись «dc = example, dc = com» существует, тогда сервер может возвращать согласованное значение DN для «dc = example, dc = com».

Если ваш поиск совпадает с одной или несколькими элементами, то (если вы не использовали прослушиватель результатов поиска, что не было в примере, указанном выше), соответствующие записи будут доступны через метод getSearchEntries. Например:

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

Создан 26 июл. 12 2012-07-26 17:21:23 Neil Wilson

LDAP_SERVER_EXTENDED_DN_O >05/31/2020
  • 3 minutes to read
  • The LDAP_SERVER_EXTENDED_DN_OID control is used with an extended LDAP search function to request an extended form of an Active Directory object distinguished name. The extended form includes a string representation of the object objectGUID property. For security principal objects such as users, groups, and computers, the extended form also includes a string representation of the object objectSID property.

    To use this control, set the members of the LDAPControl structure as follows:

    Members

    ldctl_oid

    LDAP_SERVER_EXTENDED_DN_OID, which is defined as «1.2.840.113556.1.4.529».

    ldctl_value

    Specifies the BER-encoded sequence of parameters that enables the application to specify the string format of the returned GUID and SID. In the berval structure, set bv_val to a pointer to the sequence that contains the flag data and set bv_len to the length of the sequence. For more information, see the Remarks section.

    ldctl_iscritical

    Can be TRUE or FALSE depending on whether the search is critical to your application.

    Remarks

    The Extended DN Control enables the client to request that the results returned by an LDAP search that uses this control return the GUID and SID data of an object along with the object distinguishedName, which is returned as follows.

    Where xxxxxxxx is a string that contains the GU >

    The flag value passed in the ldctl_value field specifies the string format of the returned GUID and SID values, and is set to the following Ber-encoded sequence:

    A flag value specifies that the GU >» and » «.

    A flag value of 1 will return the GU >» and » «.

    The following C++ example code shows how to manually format the sequence data. The ber_printf function is used to create the sequence data. The flags portion contains the GUID/SID string format specifier.

    The following C++ example code shows how to use the extended DN control with the ldap_search_ext_s function.

    Настройка LDAP, интеграция сервиса с AD

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

    Например есть у меня винда 2008. Есть некий сервис, который необходимо интегрировать с AD, чтобы авторизация шла доменные учетки.

    есть домен domain.office. В нем есть несколько групп (компьютеры, пользователи, другие группы, которые я сам создаю). Пусть будет grup1, grup2. в них я создаю пользователей и группы соответственно grup1 и grup2.

    Пытаюсь всякие параметры вбить и ничего не получается.

    Может что необходимо на саму винду поставить дополнительно? или ещё что-то надо делать прежде чем коннектиться другим сервисом к АД.

    Список параметров, которые я пытаюсь подключить :

    Что такое код ldap_get_dn

    The ldap_get_dn function retrieves the distinguished name for a given entry.

    Syntax

    Parameters

    The session handle.

    The entry whose distinguished name is to be retrieved.

    Return value

    If the function succeeds, it returns the distinguished name as a pointer to a null-terminated character string.

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

    Remarks

    The ldap_get_dn function retrieves the distinguished name for an entry that was returned by ldap_first_entry, or ldap_next_entry. When the returned name is no longer needed, free the string by calling ldap_memfree.

    Requirements

    Minimum supported client

    Minimum supported server

    Windows Server 2008

    Wldap32.lib Wldap32.dll

    Unicode and ANSI names

    ldap_get_dnW (Unicode) and ldap_get_dnA (ANSI)

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