Active Directory/LDAP
Active Directory (AD) – проприетарная реализация от компании Microsoft службы каталогов – совокупности программных сервисов и баз данных для иерархического представления информационных ресурсов в сети (компьютеров, принтеров, сетевых дисков и пр.) и настройки доступа к ним. LDAP (Lightweight Directory Access Protocol) – облегчённый протокол доступа к каталогам, открытый стандартизированный протокол, применяемый для работы с различным реализациям служб каталогов, в том числе и Active Directory. Основной задачей Active Directory является хранение информации обо всех объектах в сети и предоставление её внешним системам. В свою очередь, LDAP позволяет пользователям получить доступ к ресурсам в зависимости от прав, настроенных администратором службы каталогов. Для работы протокола LDAP по-умолчанию используется TCP-порт 389.
Существует защищённая версия протокола LDAP – LDAPS (LDAP over SSL), которая использует безопасное TLS/SSL-соединение для передачи данных. Протокол LDAPS по умолчанию использует TCP-порт 636.
9 Настройка интеграции с AD/LDAP в деталях
Далее описаны основы Active Directory, более подробную информацию смотрите в официальной документации на сайте Microsoft.
Что такое леса, деревья и домены в Active Directory?
- домен – группа объектов (пользователей, компьютеров и пр.), основная административная единица AD. Для каждого домена настраиваются правила доступа к нему и политики взаимодействия с другими доменами (отношения доверия);
- структурное подразделение – необязательный наименьший возможный контейнер, в который при желании можно сгруппировать объекты домена (другие контейнеры, аккаунты пользователей и компьютеров). Могут использоваться, чтобы определить групповые политики и административный доступ для небольшой совокупности ресурсов в пределах одного домена;
- дерево доменов – коллекция доменов, сгруппированных в иерархическую структуру и имеющих связанное пространство имён;
- лес – контейнер высшего уровня, включающий в себя все домены каждого конкретного экземпляра AD.
Таким образом, в иерархии Active Directory должен быть как минимум один лес, одно дерево и один домен.
Для каждого домена настраивается минимум один сервер с ролью контроллер домена, на котором работают сервисы AD. Он хранит информацию об объектах своего домена, и реализует операции поиска в каталоге, входа пользователей и проверки подлинности.
Контроллер домена, который содержит данные о каждом объекте в лесу AD, называется глобальный каталог. Он хранит полный набор атрибутов объектов своего домена и частичную реплику основных атрибутов (список которых можно настроить) объектов всех остальных доменов. Это позволяет быстро находить информацию независимо от её физического расположения на различных доменах.
В лесу обязательно должен быть минимум один глобальный каталог. По умолчанию им назначается первый контроллер домена, на который устанавливается роль доменных служб Active Directory.
14 интеграция по протоколу LDAP со службой каталогов
Для связи с глобальным каталогом используется TCP-порт 3268 или 3269 при работе по протоколу LDAP и LDAPS соответственно.
Как работает Active Directory?
Сервисы Active Directory являются частью операционной системы Microsoft Windows Server и устанавливаются в качестве одной или нескольких её ролей.
Основной из них является роль доменные службы Active Directory (Active Directory Domain Services, AD DS) – она используется для организации в защищённую логическую структуру всех объектов сети. Полученная иерархическая схема является независимой от физического расположения объектов и топологии сети. Это значительно упрощает администрирование и настройку доступа, например, изменение физического расположения компьютера не повлияет на его роль в структуре AD.
Основными операциями при работе с Active Directory являются аутентификация пользователей, а также поиск, модификация и сравнение объектов. Эти функции реализуются с помощью протокола LDAP.
Кроме AD DS, могут устанавливаться дополнительные роли, расширяющие возможности использования AD: шифрование чувствительных данных, единый вход без повторной аутентификации пользователей на различные веб-сервисы в сети, и пр.
Active Directory содержит:
- хранилище данных – часть службы каталогов, которая управляет хранением и предоставлением информации на каждом контроллере домена. Данные хранятся в структурированной базе данных (БД), которая иначе называется каталог и содержит совокупность всех объектов AD. Каждый из них относится к определённому классу (пользователи, компьютеры, домены и т.д.). В свою очередь, все объекты каждого класса имеют одинаковый набор атрибутов;
- схему – совокупность определений классов и атрибутов (именованных параметров) объектов. Она стандартизирует как данные хранятся в хранилище и благодаря этому позволяет получать информацию (как сказано выше, используется для этого протокол LDAP);
- леса, деревья, домены и организационные подразделения – ключевые элементы логической структуры AD, которые были подробно рассмотрены ранее.
Для конвертации зарегистрированных в структуре Active Directory имён сетевых ресурсов (компьютеров, принтеров и пр.) в IP-адреса используется интеграция с DNS (Domain Name System, системой доменных имён). Это позволяет, например, пользователям получить доступ к компьютерам, а компьютерам – к контроллерам доменов.
В итоге вся запись для сотрудника, принадлежащего классу employee , может иметь такой вид:
Источник: trueconf.ru
LDAP для учёных-ракетчиков
Данное открытое руководство о LDAP, OpenLDAP 2.x и ApacheDS на Linux и BSD (FreeBSD, OpenBSD и NetBSD). Оно предназначено для как для новичков, так и для светил науки, а также для всех тех, кто находится между ними. LDAP — сложный предмет.
Данное руководство родилось из наших жалких попыток понять LDAP, поскольку он обещал настоящую нирвану — общий источник информации, неограниченную масштабируемость путём использования модели репликации, врождённую устойчивость, высокоскоростное получение данных, детальный контроль над тем, кто, что и с какими данными может сделать — этот список можно продолжать. Чудесная вещь!
На этом хорошие новости заканчиваются. Плохая новость заключается в том, что, по нашему скромному мнению, никогда не было написано так много непонятного об одном предмете, за исключением, пожалуй, BIND и . и ещё . Есть бесчисленные отличные HOWTO, разбросанные по Интернету, которые прекрасны, если Вам нужно тактическое решение частной проблемы, и Вы готовы смириться со смутным неприятным чувством, что полностью зависите от чего-то такого, чего на самом деле не понимаете.
Нам не нужно тактическое решение, нам было нужно стратегическое решение целого комплекса проблем, каждая из которых кажется идеально предназначенной для LDAP, но нам нужно было понять предмет . нам нужно было WHYTO. Эта и есть наша, — возможно, жалкая, — попытка создать его. Давным-давно OpenLDAP был единственной звездой на небосклоне Open Source LDAP.
Он до сих пор считается эталонной реализацией LDAP и остается отличной системой с большим количеством реализованных возможностей, активно развивающейся и необыкновенно комплексной, что позволяет использовать его для решения нетривиальных задач. Однако, это уже не единственная звезда на небосклоне.
Теперь есть 389 Directory Server (бывший Fedora Directory Server), другая производная от проекта Мичиганского Университета, OpenDJ (ответвление от OpenDS — оригинальной реализации на Java от Sun, разработка которой прекращена), и проект ApacheDS (Apache Directory). Всё это чудесные проекты, и, вместе с OpenLDAP, они ошеломляют обилием продвинутых возможностей и функциональности в пространстве Open Source LDAP.
Некоторые заметки об этих проектах и наши о них рассуждения Вы найдете здесь, если, конечно, Вас интересуют подобного рода вещи. Во все будущие версии данного руководства будет постепенно добавляться материал, описывающий использование ApacheDS, при этом документирование OpenLDAP будет продолжено. Эта работа ещё далека от завершения. Если Вы нашли ошибку — не ворчите, сообщите нам.
Посмотрите также наш список доработок, и если Вы хотите внести вклад — милости просим. И за этот тяжкий труд мы можем пообещать Вам лишь тёплые чувства нашего доброго отношения и признание Ваших заслуг в лицензии.
Что нового в Руководстве версии 0.1.18
1. Соглашения и терминология
- 1.1 Цели и сфера применения
- 1.2 Как читать данное руководство
- 1.3 Используемая терминология и условные обозначения
- 1.4 Благодарности
- 1.5 Авторские права и лицензия
Раздел 1 — Обзор и концепции
2. Обзор LDAP
- 2.1 Краткая история LDAP
- 2.2 Обзор LDAP
- 2.3 LDAP и базы данных
- 2.3.1 Использование LDAP — резюме
- 2.4.1 Структура дерева объектов
- 2.4.2 Объектные классы
- 2.4.3 Атрибуты
- 2.4.4 Описание дерева путём добавления данных
- 2.4.5 Навигация по дереву (DN и RDN)
- 2.5.1 Отсылки
- 2.5.2 Репликация
3. Схема данных, объектные классы и атрибуты LDAP
- 3.1 Обзор элементов LDAP
- 3.2 Наборы схемы данных
- 3.3 Объектные классы
- 3.4 Атрибуты
- 3.5 Правила соответствия
- 3.6 Операционные атрибуты и объекты LDAP
Раздел 2 — Поехали!
4. Установка LDAP
5. Примеры конфигураций OpenLDAP
6. Конфигурационные файлы
7. Репликация и отсылки
Раздел 3 — Справочная
8. LDIF и DSML
9. Функциональная модель LDAP
10. LDAP API
Раздел 4 — Операции OpenLDAP
11. OpenLDAP HowTo
12. Ошибки и устранение неисправностей OpenLDAP
13. Производительность OpenLDAP
14. Инструменты LDAP
Инструменты OpenLDAP
ldapadd — добавление LDIF-записи в каталог LDAP
ldapauth — добавление LDIF-записи в каталог LDAP
ldapdelete — удаление LDAP-записи
ldapmodify — модификация существующих записей LDAP
ldapmodrdn — модификация DN записи LDAP
ldappasswd — модификация пароля записи
ldapsearch — поиск записей LDAP
ldapwhoami — выполнение LDAP-операции Who Am I на сервере
slapacl — проверка доступа к атрибутам путём изучения конфигурации DIT
slapadd — добавление записи LDAP в базу данных
slapauth — проверка данных SASL на соответствие с DIT
slapcat — экспорт LDIF из базы данных LDAP
slapdn — проверка DN на соответствие конфигурации DIT
slapindex — переиндексация базы данных LDAP
slappasswd — генерация пароля
slaptest — проверка файла slapd.conf или директории cn=config (slapd.d)
LDAP-браузеры
LDAPBrowser/Editor — некоторые заметки по использованию
Инструменты ApacheDS
Раздел 5 — Безопасность LDAP
15. Безопасность LDAP
- 15.1 Обзор безопасности OpenLDAP
- 15.4 Настройка TLS/SSL в OpenLDAP
Приложения: Ресурсы
- Приложение A: Заметки и пояснения к LDAP
- Приложение B: Ресурсы LDAP
- Приложение C: LDAP RFC и документация
- Приложение D: Глоссарий LDAP
- Приложение E: Наборы схемы данных, объектные классы и атрибуты LDAP
Технологическая информация о книге
Проблемы, комментарии, предположения, исправления (включая битые ссылки) или есть что добавить? Пожалуйста, выкроите время в потоке занятой жизни чтобы написать нам, вебмастеру или в службу поддержки. Оставшийся день Вы проведёте с чувством удовлетворения.
| Закладки на сайте Проследить за страницей |
Created 1996-2022 by Maxim Chirkov Добавить, Поддержать, Вебмастеру |
Источник: www.opennet.ru
LDAP
LDAP (Lightweight Directory Access Protocol — облегчённый протокол доступа к каталогам) — это сетевой протокол для доступа к службе каталогов. По сути это базы данных, хранящие в себе информацию о пользователях, узлах и объектах сети. Цель их создания — упростить администрирование. LDAP — простой протокол, использующий TCP/IP.
Он позволяет компоновать (bind), искать (search) и сравнивать (compare) записи, а также производить операции добавления, изменения или удаления. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.
Обзор протокола
Сессия LDAP начинается с того, что клиент подсоединяется к LDAP-серверу — по умолчанию это ТСР порт 389. клиент отправляет запрос на операцию, после чего получает ответ с сервера. В большинстве случаев клиент не должен ждать ответ перед отправкой следующего запроса, сервер же посылает ответы в произвольном порядке.
Запрос на операции
- Старт TLS (Transport Layer Security) используя расширение LDAPv3 для обеспечения надёжного соединения.
- Аутентификация и указание версии протокола LDAP.
- Поиск записей в каталоге.
- Сравнение содержит ли запись искомый атрибут.
- Добавление новой записи.
- Удаление записи.
- Модификация записи.
- Модификация отличительного имени (Distinguished Name, DN) — перемещение или переименование записи
- Отмена предыдущего запроса.
- Расширенные операции
- Закрытие соединения.
Кроме того, сервер может послать не запрошенное уведомление, которое не является ответом на запрос. Например, прежде чем разорвать соединение.
Структура
Протокол доступа к каталогам LDAP соответствует модели X.500, принятой в качестве стандарта в 1993 году:
- Каталог представляет собой дерево каталогов записей.
- Запись состоит из набора атрибутов.
- Атрибут имеет имя (атрибут типа или атрибут описания) и одно или несколько значений.
- Каждая запись имеет уникальный идентификатор — отличительное имя (Distinguished Name, DN). Которое состоит из относительного отличительного имени (Relative Distinguished Name, RDN) составленное из атрибута(ов) записи, за которым следует родительская запись отличительного имени. То есть DN является полным именем файла, а RDN относительное имя в папке.
Имейте ввиду, что DN может меняться в течение существования записи. На пример, когда запись перемещается внутри дерева каталога. Чтобы надёжно и однозначно определить позиции записи в набор её оперативных атрибутов может быть включён UUID.
В LDAP запись может выглядеть примерно так:
Здесь: dn — это имя записи, которое не является не атрибутом, не частью записи. «cn=Иван Иванов» — это RDN записи, a «dc=example,dc=com» — DN родительской записи, в которой dc обозначает доменный компонент. В остальных строках показаны атрибуты записи.
Сервер хранит подкаталог (subtree) начиная с конкретной записи, например, «dc=example,dc=com» и её расширения. На сервере также могут храниться ссылки на другие серверы, таким образом, попытка найти «ou=department,dc=example,dc=com» может вернуть предложение или постоянную ссылку на сервер, который хранит эту часть папки каталога. Клиент может подсоединиться к этому серверу. Некоторые серверы объединены в цепи, то есть отдельный сервер связывается с другим сервером и возвращает результат клиенту.
Операции
Клиент предоставляет каждому запросу положительный идентификатор сообщения, и ответ сервера имеет тот же идентификатор сообщения. Ответ включает в себя результирующий числовой код, который может быть успешным, указывать на ошибки или предоставлять другие данные. Перед ответом сервер может отправить другие сообщения с другими результирующими данными — например, в этом сообщении могут быть отправлены все записи, найденные во время операции поиска.
Протокол LDAP определён в следующих RFC:
- RFC 4510 — Lightweight Directory Access Protocol (LDAP) Technical Specification Roadmap (заменяет RFC 3377)
- RFC 4511 — Lightweight Directory Access Protocol (LDAP): The Protocol
- RFC 4512 — Lightweight Directory Access Protocol (LDAP): Directory Information Models
- RFC 4513 — Lightweight Directory Access Protocol (LDAP): Authentication Methods and Security Mechanisms
- RFC 4514 — Lightweight Directory Access Protocol (LDAP): String Representation of Distinguished Names
- RFC 4515 — Lightweight Directory Access Protocol (LDAP): String Representation of Search Filters
- RFC 4516 — Lightweight Directory Access Protocol (LDAP): Uniform Resource Locator
- RFC 4517 — Lightweight Directory Access Protocol (LDAP): Syntaxes and Matching Rules
- RFC 4518 — Lightweight Directory Access Protocol (LDAP): Internationalized String Preparation
- RFC 4519 — Lightweight Directory Access Protocol (LDAP): Schema for User Applications
- RFC 4520 (aka BCP 64) — Internet Assigned Numbers Authority (IANA) Considerations for the Lightweight Directory Access Protocol (LDAP) (заменяет RFC 3383)
- RFC 4521 (aka BCP 118) — Considerations for Lightweight Directory Access Protocol (LDAP) Extension
Серверная часть
LDAP является одним из самых распространённых стандартов доступа к службам каталогов. Из свободно распространяемых открытых реализаций наиболее популярен сервер OpenLDAP, из платных служб каталогов, которые поддерживают протокол, можно выделить Active Directory от компании Microsoft, предназначенной для централизации управления сетями Windows. Свои реализации служб каталогов, поддерживающие LDAP как протокол доступа, предлагают и другие крупные компании, например, Novell и Sun.
Клиентская часть
В качестве клиентов LDAP выступают как адресные книги почтовых клиентов, так и back-end’ы различных сетевых служб (серверы DNS, SMTP, Samba, UTS и т. д.). LDAP также получила широкую поддержку со стороны таких компаний, как:
- Apache (на основе сервера каталогов Apache)
- Apple (на основе Open Directory / OpenLDAP)
- AT https://www.tadviser.ru/index.php/%D0%A1%D1%82%D0%B0%D1%82%D1%8C%D1%8F:LDAP» target=»_blank»]www.tadviser.ru[/mask_link]
Записки IT специалиста
Службы каталогов. Часть 2 — Реализации служб каталогов.
В прошлой статье мы разобрались, что такое служба каталогов и какие преимущества можно получить от ее использования. Сегодня мы расскажем о существующих реализациях служб каталогов, их достоинствах и недостатках, чтобы вы могли осознанно сделать выбрать решение, которое наиболее полно удовлетворит ваши запросы.
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Что такое LDAP?
Начнем, как всегда, с краткого ликбеза. Стандартом доступа к службам каталогов является протокол LDAP, на его базе построены практически все современные реализации служб каталогов. Использование LDAP позволяет унифицировать структуру записей каталога, что необходимо для совместимости продуктов различных производителей, поддержка LDAP гарантирует поддержку базовых возможностей любого современного сервера служб каталогов.
Любая запись каталога имеет уникальное имя — DN, которое в свою очередь состоит из относительного уникального имени — CN, раздела — OU и класса объекта — DC. Например запись:
cn=SALES, ou=Отдел продаж, dc=example, dc=com
обозначает компьютер SALES, находящийся в Отделе продаж и входящий в домен example.com, при этом не имеет значения какую именно из служб каталогов вы используете, запись будет выглядеть одинаково в любом из них. Однако кроме протокола LDAP, многие реализации имеют собственные расширения, которые могут быть несовместимы с LDAP, что делает невозможным их использование программными продуктами не имеющими полной поддержки конкретной реализации.
Active Directory
LDAP-совместимая реализация службы каталогов от Microsoft, является наиболее функциональной и самой популярной для Windows сетей. Входит в состав Windows Server и не требует дополнительного лицензирования. Active Directory является основополагающей частью инфраструктуры Windows.
Помимо LDAP поддерживает большое количество собственных расширений, таких как групповые политики, позволяющие централизованно и единообразно настраивать пользовательское окружение рабочих компьютеров, устанавливать, удалять и обновлять ПО. Легок в администрировании. Наиболее полно все возможности Active Directory раскрываются в сочетании с другими продуктами Microsoft.
Если вы используете инфраструктуру на базе продуктов Microsoft, то лучшим решением будет использование Active Directory в качестве службы каталогов. В тоже время поддержка LDAP позволяет без особых проблем интегрировать в каталог многие открытые решения на базе Linux / UNIX, однако они не смогут в полной мере использовать все возможности AD, например групповые политики.
OpenLDAP
Открытая, кроссплатформенная реализация LDAP, наиболее полно поддерживает все возможности протокола, в связке с Samba представляет хорошую альтернативу AD, однако не поддерживает расширенные возможности последней (самые значимые из них — групповые политики). Однако все богатые возможности омрачаются сложностью настройки и администрирования, которое производится с помощью конфигурационных файлов, что требует от администратора глубоких знаний и осложняет освоение продукта. Кроме того OpenLDAP имеет ряд проблем совместимости с AD, что затрудняет его использование в «смешанных» сетях, где имеются серверные продукты Microsoft.
OpenLDAP может являться хорошей заменой для AD в небольших сетях, а может стать большой головной болью для системного администратора, поэтому перед внедрением этого продукта мы советуем трезво оценить свои силы и знания, также не будет лишним пробное внедрение в тестовой среде.
389 Directory Server
Сервер каталогов корпоративного уровня разрабатываемый сообществом Fedora при поддержке Red Hat и входящий в коммерческие продукты последней. Ранее это проект назывался Fedora Directory Server, переименование связано с тем, что разработчики позиционируют продукт как универсальный, а не исключительно для Fedora / RHEL. Продукт, кроме всех возможностей LDAP предоставляет довольно удобные графические инструменты администрирования, в том числе и для Windows платформы, что делает его довольно простым в освоении, неплохо вписывается в Windows инфраструктуру.
Если вы собираетесь внедрять данный продукт, то следует помнить, что на сегодняшний день готовые пакеты существуют только для Fedora / RHEL, при использовании других дистрибутивов будьте готовы к решению проблем по установке собственными силами.
Apache Directory
Еще одна открытая реализация сервера каталогов от известного разработчика. Кроссплатформенн, так как написан на Java. Состоит из двух функциональных частей: сервера каталогов ApacheDS и средства администрирования Apache Directory Studio, которое отличительно тем, что поддерживает любой LDAP-совместимый сервер каталогов, а не только «родной». Это позволяет использовать данный продукт например для администрирования OpenLDAP, особенно ценной является возможность запуска средства Apache Directory Studio в среде Windows.
Apache Directory — крайне интересный продукт, предоставляющий администратору весьма широкие возможности, если вы ищете бесплатный сервер каталогов, мы бы советовали обратить внимание именно на него. В дальнейшем мы предполагаем вести цикл публикаций по Службам каталогов в разрезе двух продуктов: Apache Directory и Active Directory.
Все реализации служб каталогов рассмотреть в рамках одной статьи невозможно, поэтому мы ограничились на самых интересный и зрелых из них. Что же осталось за кадром? Мы не касались дорогих брендовых систем типа Lotus Domino, имеющих в своем составе сервер служб каталогов, также не затрагивали продукты, будущее которых под вопросом, например Mandriva Directory Server.
Отдельный абазац мы отведем домену Samba, данная реализация позволяет организовать простейший домен уровня Windows NT4, который сложно назвать полноценной службой каталогов, скорее единой точкой авторизации. Кроме того данное решение несовместимо с LDAP, а следовательно при росте инфраструктуры вы столкнетесь с проблемой миграции на полноценную службу каталогов. Поэтому рекомендовать и рассматривать домен Samba мы не будем.
В следующих материалах нашего цикла мы рассмотрим устройство и практическую реализацию служб каталогов на базе Active Directory и Apache Directory.
Дополнительные материалы:
- Службы каталогов. Часть 1 — Общие понятия
- Службы каталогов. Часть 2 — Реализации служб каталогов
- Службы каталогов. Часть 3 — Структура Active Directory
- Active Directory — от теории к практике. Часть 1 — общие вопросы
- Active Directory — от теории к практике. Часть 2 — разворачиваем доменную структуру
- Active Directory — от теории к практике. Часть 3 — настройка DHCP
- Active Directory — от теории к практике. Часть 4 — перенос учетных записей в домен
- Настраиваем высокодоступный DHCP-сервер в Windows Server 2012
- Быстрое развертывание Active Directory с отказоустойчивой конфигурацией DHCP
- Синхронизация времени Active Directory с внешним источником
- Обновление схемы Active Directory
- Управление ролями FSMO при помощи Ntdsutil
- Управление ролями FSMO с помощью PowerShell
- Восстанавливаем доверительные отношения в домене
- Очистка метаданных контроллера домена в Active Directory
Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.
Источник: interface31.ru
LDAP
LDAP (англ. Lightweight Directory Access Protocol — «легковесный протокол доступа к каталогам») — протокол прикладного уровня для доступа к службе каталогов X.500, разработанный IETF как облегчённый вариант разработанного ITU-T протокола DAP. LDAP — относительно простой протокол, использующий TCP/IP и позволяющий производить операции аутентификации (bind), поиска (search) и сравнения (compare), а также операции добавления, изменения или удаления записей. Обычно LDAP-сервер принимает входящие соединения на порт 389 по протоколам TCP или UDP. Для LDAP-сеансов, инкапсулированных в SSL, обычно используется порт 636.
Всякая запись в каталоге LDAP состоит из одного или нескольких атрибутов и обладает уникальным именем (DN — англ. Distinguished Name ). Уникальное имя может выглядеть, например, следующим образом: «cn=Иван Петров,ou=Сотрудники,dc=example,dc=com» [1] . Уникальное имя состоит из одного или нескольких относительных уникальных имён (RDN — англ. Relative Distinguished Name ), разделённых запятой.
Относительное уникальное имя имеет вид ИмяАтрибута=значение. На одном уровне каталога не может существовать двух записей с одинаковыми относительными уникальными именами. В силу такой структуры уникального имени записи в каталоге LDAP можно легко представить в виде дерева.
Запись может состоять только из тех атрибутов, которые определены в описании класса записи (object class), которые, в свою очередь, объединены в схемы (schema). В схеме определено, какие атрибуты являются для данного класса обязательными, а какие — необязательными. Также схема определяет тип и правила сравнения атрибутов. Каждый атрибут записи может хранить несколько значений.
- 1 Стандарты
- 2 Функциональное описание протокола
- 2.1 Операция запроса возможностей
- 2.2 Операция запроса схемы
- 3.1 Серверная часть
- 3.2 Клиентская часть
- 6.1 Ресурсы
- 6.2 Серверы
- 6.3 Клиенты
- 6.4 Программные интерфейсы (API)
Источник: wiki2.org