Ldap

Содержание:

Содержание статьи

Эта статья состоит из следующих разделов:

: общие инструкции по подключению LDAP-клиентов, не упомянутых в этой статье.
: инструкции по подключению к сервису Secure LDAP некоторых LDAP-клиентов, например Atlassian Jira и OpenVPN. Последовательность действий зависит от типа клиента.
: общие инструкции для приложений на базе Java с функциями LDAP.
: инструкции с дополнительной информацией о подключении LDAP-клиентов, не поддерживающих цифровые сертификаты.

В приведенных ниже инструкциях подразумевается, что файл ключа имеет название ldap-client.key, а файл сертификата – ldap-client.crt.

пример

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

DN = отличительное имя. Это означает, в какой части базы данных вы работаете. Может быть пользователем или группой (или даже настройками конфигурации).
Запись: объект, например пользователь.
Атрибут: что-то внутри записи, например имя, номер телефона и адрес электронной почты.

соединительный

Сначала мы определяем следующее:

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

Настройка параметров

Во-первых, мы объявляем эти параметры. В зависимости от конфигурации вашего сервера вы можете оставить это.

переплет

Предположим, вы используете admin и пароль pass123notsafe

Это очень мило. Мы находимся. Теперь мы можем выполнять много разных операций. Например, мы можем искать, читать, писать и изменять пользователей и даже группы.

поиск

Представьте, что мы хотим отобразить всех членов группы «пользователи».

Вы можете использовать петли foreach для отображения данных в хорошем виде.

Хорошо, понял? Теперь приступим к некоторой фильтрации. Мы хотим отображать только пользователей в группе «bikeowners», которые зарегистрировали адрес электронной почты

Важно знать, что все пользователи находятся в cn = users. Кроме того, они также могут быть членами других групп

И теперь переходите к снова.

Эффективность в получении записей

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

Представьте, что мы хотим искать пользователей, которые находятся в группе «bikeowners». Внутри этих записей хранится много информации, скажем, они имеют следующие атрибуты: cn, uid, name, displayname, mail, initials, mobile, telephonenumber, street, postaladdress, postalcode и jpegphoto. Теперь нам нужны только их uid, имя и инициалы.

Для этого мы используем необязательный 4-й параметр ldap_search:

И вуаля, запускающая , даст вам только эти данные.

Расширенная фильтрация

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

В качестве отправной точки возьмите один из приведенных выше примеров, но измените фильтр $ в соответствии с приведенной ниже строкой. В нашем примере мы хотим отображать данные активных пользователей. Обычно для хранения этой информации используется атрибут . Однако это может различаться между различными системами LDAP. Мы не только хотим отображать активных пользователей, но и их имя должно начинаться с «а», и они должны жить в Амстердаме.

В принципе, мы хотим сделать три вещи:

Самый простой: должен жить в Амстердаме. В этом примере место жительства хранится в атрибуте ‘postaladdress’

Имя должно начинаться с символа «a». В этом примере UID состоит из имени, поэтому:

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

Теперь самая интересная часть: объедините все три примера. Мы можем сделать это с помощью скобок, AND, OR и NOT выражений

Наконец, мы могли бы построить инструкцию OR с помощью «|», например, если мы хотим, чтобы все пользователи, начинающие с «a» или «b»,

Вы можете комбинировать бесконечно и создавать довольно впечатляющие фильтры, попробовать!

Previous
Next

Краткий обзор архитектуры LDAP

LDAP — это стандартный протокол для осуществления доступа к серверам
каталогов. IBM Directory Server должен быть настроен так, чтобы
поддерживать аутентификацию пользователей на LDAP способом, определенным в
RFC 2307.

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

показывает схему LDAP.

Рисунок 1. Схема LDAP

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

Загрузочный модуль безопасности LDAP впервые появился в AIX 4.3. Этот
загрузочный модуль обеспечивал аутентификацию пользователей и выполнял
функции по централизованному управлению пользователями и группами при
помощи IBM SecureWay Directory. Учетная запись пользователя на
LDAP-сервере может быть настроена так, чтобы пользователь мог загружаться
в LDAP-клиенте на компьютерах, где он даже не зарегистрирован. Загрузочный
модуль LDAP полностью интегрирован с операционной системой AIX.

Backup and Restore

Now we have ldap running just the way we want, it is time to ensure we can save all of our work and restore it as needed.

What we need is a way to backup the directory database(s), specifically the configuration backend (cn=config) and the DIT (dc=example,dc=com). If we are going to backup those databases into, say, , we could use slapcat as shown in the following script, called :

Then, it is just a matter of having a cron script to run this program as often as you feel comfortable with. For many, once a day suffices. For others, more often is required. Here is an example of a cron script called that is run every night at 22:45h:

Now the files are created, they should be copied to a backup server.

Assuming we did a fresh reinstall of ldap, the restore process could be something like this:

This is a simplistic backup strategy, of course. It’s being shown here as a reference for the basic tooling you can use for backups and restores.

Устанавливаем и настраиваем OpenLDAP-сервер

В качестве LDAP будем использовать OpenLDAP на дистрибутиве ubuntu 18.04.

Имя нашего сервера: openldap.dtln.cloud.

Подключаемся к серверу и приступаем к установке OpenLDAP. В процессе установки нам предложат установить пароль:

sudo apt update

sudo apt install slapd ldap-utils
Переконфигурируем OpenLDAP для нашего домена:

sudo dpkg-reconfigure slapd
Выбираем No:
Вводим доменное имя:
Вводим имя организации:
Повторяем ввод пароля:
Включаем поддержку STARTTLS. Ставим необходимые пакеты:

sudo apt install gnutls-bin ssl-cert
Генерируем CA-ключ:

sudo sh -c «certtool —generate-privkey > /etc/ssl/private/cakey.pem»
Описываем нашу организацию в /etc/ssl/ca.info:

cn = DTLN Company

ca

cert_signing_key
Генерируем CA-сертификaт и ключ, который в дальнейшем будем использовать:

sudo certtool —generate-self-signed —load-privkey /etc/ssl/private/cakey.pem —template /etc/ssl/ca.info —outfile /etc/ssl/certs/cacert.pem

sudo certtool —generate-privkey —bits 1024 —outfile /etc/ssl/private/openldap_key.pem
Создаем шаблон для сертификата /etc/ssl/openldap.info:

organization = DTLN Company

cn = openldap.dtln.cloud

tls_www_server

encryption_key

signing_key

expiration_days = 3650
Генерируем сам сертификат:

sudo certtool —generate-certificate —load-privkey /etc/ssl/private/openldap_key.pem —load-ca-certificate /etc/ssl/certs/cacert.pem —load-ca-privkey /etc/ssl/private/cakey.pem —template /etc/ssl/openldap.info —outfile /etc/ssl/certs/openldap.pem
Настраиваем OpenLDAP для работы со STARTTLS. Вот что должно быть внутри файла certinfo.dif:

dn: cn=config

add: olcTLSCACertificateFile

olcTLSCACertificateFile: /etc/ssl/certs/cacert.pem

—

add: olcTLSCertificateFile

olcTLSCertificateFile: /etc/ssl/certs/openldap.pem

—

add: olcTLSCertificateKeyFile

olcTLSCertificateKeyFile: /etc/ssl/private/openldap_key.pem
Применяем созданный нами файл следующей командой:

sudo ldapmodify -Y EXTERNAL -H ldapi:/// -f certinfo.dif
Назначаем права доступа на сертификат и перезапускаем наш сервис:

sudo chgrp openldap /etc/ssl/private/openldap_key.pem

sudo chmod 0640 /etc/ssl/private/openldap_key.pem

sudo gpasswd -a openldap ssl-cert

sudo systemctl restart slapd.service
Чтобы проверить работу нашего сервиса с сертификатами, добавляем в /etc/ldap/ldap.conf строчку:

TLS_CACERT /etc/ssl/certs/cacert.pem
Проверяем работу через STARTTLS:

ldapwhoami -H ldap://openldap.dtln.cloud -x -ZZ

В случае успеха получаем:

В случае проблемы проверяем еще раз пути до сертификатов и выполнение команд:

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

Функции контроля доступа представленные в > очень
мощные. В этой секции приводятся примеры их использования. Для начала несколько простых примеров:

access to * by * read

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

defaultaccess read

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

access to dn=".*, o=U of M, c=US" 
by * search 
access to dn=".*, c=US" 
by * read

Доступ на чтение (read) назначается элементам в поддереве c=US, за
исключением элементов в поддереве «o=University of Michigan, c=US», к которым
дается доступ на поиск (search). Если сохранен порядок следования этих
директив, U-M-специфичная директива никогда не совпадет, так как все
U-M элементы являются также c=US элементами.

Следующий пример снова показывает важность порядка следования, как директив
доступа, так и выражений «by». Он также показывает использование
селектора атрибута для предоставления доступа к указанным атрибутам и различным селекторам

access to dn=".*, o=U of M, c=US" attr=homePhone 
by self write 
by dn=".*, o=U of M, c=US" search 
by domain=.*\.umich\.edu read 
by * compare 
access to dn=".*, o=U of M, c=US" 
by self write 
by dn=".*, o=U of M, c=US" search 
by * none

Этот пример применяется к элементам поддерева «o=U of M, c=US».
Сам элемент имеет доступ на запись ко всем атрибутам, кроме homePhone, другие U-M элементы
могут выполнять поиск по ним, все остальные не имеют доступа.
Атрибут homePhone доступен на запись самому элементу, для поиска прочим U-M
элементам, для чтения клиентам, подключающимся из домена umich.edu,
и для сравнения всем остальным.

Иногда полезно разрешить отдельному отличительному имени добавлять или удалять самого себя из атрибута. Например,
Если вы хотите создать группу и разрешить людям добавлять или удалять только их собственное отличительное имя
в атрибуте member, вы могли бы добиться этого с помощью такой access директивы:

access to attr=member,entry 
by dnattr=member selfwrite

Селектор dnattr <кому> говорит, что доступ применяется к элементам, перечисленным в атрибуте member.
Селектор доступа selfwrite говорит, что эти члены могут удалять только их собственное отличительное имя
из атрибута, но не другие значения.
Добавление элемента атрибута необходимо, так как для доступа к любым атрибутам элемента необходим доступ к элементу.

Обратите внимание, что конструкция attr=member в выражении , является сокращением выражения «dn=* attr=member» (т.е., оно соответствует атрибуту member во всех элементах)

Example Configuration

You can use the below settings as a starting point and adjust the filter and display attributes according to your needs.

LDAP name filter(&(telephoneNumber=*)(sn=%)) —> Example 1
LDAP number filter (&(telephoneNumber=%)(sn=*)) —> Example 2
LDAP Name Filter During Call (&(telephoneNumber=*)(sn=%)) —> Example 1
LDAP Number Filter During Call (&(telephoneNumber=%)(sn=*)) —> Example 2
Port
Base DC=domain,DC=com —> Example 3
Username Admin
Password PASSWORD
Max.Hits 50
LDAP Name Attributes cn sn displayName —> Example 4
LDAP Number Atrributes Mobile telephoneNumber ipPhone —> Example 5
LDAP display Name %displayName —> Example 6
Countrycode +49
Areacode 030

Make also sure, that the Number Display Style is set accordingly to return either name, number or both.

Я всё прочитал и поменял все параметры. Что теперь?

Теперь, если всё продолжает работать, можно измерить производительность того, что мы наделали. Не наоборот. Т.е. после тюнинга LDAP-политик в первую очередь всё должно продолжить функционировать, а во вторую – улучшить какие-либо характеристики.

Надеюсь, что данный материал поможет Вам эффективнее работать с инфраструктурой на базе Active Directory, а также покажет, что в данном сервисе есть достаточно много такого, что гораздо интереснее, чем унылые инструкции про “Next->Next->Finish->вроде-кое-как-заработало”.

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

Удач!

LDAP-политики (Query Policy) в Active Directory

Что такое политики LDAP в Active Directory и зачем они нужны
Базовые операции с политиками
Как узнать, какие политики Query Policy поддерживаются
Настраиваем параметры фильтрации доступа к LDAP
Параметры функционирования LDAP
Настраиваем параметры функционирования LDAP в Windows Server 2016
Формат Query Policy
Параметры, существующие с Windows 2000 Server
- Параметр Query Policy – MaxActiveQueries
- Параметр Query Policy – InitRecvTimeout
- Параметр Query Policy – MaxConnections
- Параметр Query Policy – MaxConnIdleTime
- Параметр Query Policy – MaxDatagramRecv
- Параметр Query Policy – MaxNotificationPerConn
- Параметр Query Policy – MaxPoolThreads
- Параметр Query Policy – MaxReceiveBuffer
- Параметр Query Policy – MaxPageSize
- Параметр Query Policy – MaxQueryDuration
- Параметр Query Policy – MaxResultSetSize
- Параметр Query Policy – MaxTempTableSize
Параметры, существующие с Windows Server 2003
Параметры, существующие с Windows Server 2008 R2
- Параметр Query Policy – MaxResultSetsPerConn
- Параметр Query Policy – MinResultSets
Параметры, существующие с Windows Server 2012
Параметры, существующие с Windows Server 2016
Отключаем жестко заданные лимиты настроек
Создаём новую Query Policy

Начнём.

Глобальные директивы

Директивы, описанные в этой секции, применяются ко всем механизмам баз данных и базам данных,
если не переопределяются в определениях механизмов баз данных или баз данных. Аргументы, которые
необходимо заменить соответствующим текстом, приведены в скобках <>.

access to <что> +

Директива предоставляет доступ (указанный в <уровень доступа>) к набору записей и/или 
атрибутов (указанных в <что>) одному или более запрашивающих  (указанных в <кому>). 
Более детальное описание смотрите в примерах контроля доступа.

attributetype <RFC2252 описание типа атрибута>

Эта директива определяет тип атрибута.

defaultaccess { none | compare | search | read | write }

Эта директива указывает доступ по умолчанию для всех запрашивающих, если не указана директива 
access. Любой назначенный уровень доступа включает в себя все нижележащие уровни доступа (например, 
read доступ предполагает также search и compare, но не write).

По-умолчанию:
defaultaccess read

idletimeout <целое число>

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

include <имя файла>

Эта директива указывает slapd перед чтением следующей строчки конфигурационного файла 
читать дополнительную конфигурационную информацию. Включаемый файл должен быть обычным 
файлом в формате конфигурационного файла slapd. Файл часто используется для включения 
файлов содержащих спецификации схем.

Заметка: вы должны быть осторожны с этой директивой — нет предела числу вложенных директив
include, также нет никакого способа обнаружения циклов.

loglevel <целое число>

Эта директива указывает уровень, на котором должны регистрироваться в syslog  отладочные 
сообщения и статистика работы (на данный момент регистрация ведется с помощью  syslogd(8) 
LOCAL4). Чтобы эта функция работала (за исключением двух уровней статистики, которые всегда
включены), вам следует сконфигурировать OpenLDAP с опцией --enable-debug (по умолчанию).
Уровни доступа аддидивны. Для отображения номеров соответствующих определенному типу 
отладочной информации вызовите slapd с ключом -? или сверьтесь со следующей таблицей.
Для <целое число> возможны значения:

-1 включает всю отладочную информацию
0 без отладочной информации
1 трассировать вызовы функций
2 отладка обработки пакетов
4 тщательная отладочная трассировка
8 управление соединением
16 печать принятых и отправленных пакетов
32 обработка фильтра поиска
64 обработка конфигурационного файла
128 обработка списка контроля доступа
256 регистрировать статистику соединения/обработки/результатов
512 регистрировать статистику отправленных элементов 
1024 печать коммуникаций с shell механизмом баз данных 
2048 печать отладки анализа элемента  

Пример: 
loglevel 255 или loglevel -1
Это приведет к занесению в syslog большого количества отладочной информации. 
По умолчанию:
loglevel 256

objectclass <RFC2252 описание класса объектов>

Эта директива определяет класс объектов.

referral <URI>

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

Пример:
referral ldap://root.openldap.org

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

sizelimit <целое число>

эта директива указывает максимальное количество элементов возвращаемых одной операцией поиска.

По умолчанию:
sizelimit 500

timelimit <целое число>

Modifying the slapd Configuration Database

The slapd-config DIT can also be queried and modified. Here are some common operations.

Adding an index

Use ldapmodify to add an “Index” to your {1}mdb,cn=config database definition (for dc=example,dc=com). Create a file, call it , with the following contents:

Then issue the command:

You can confirm the change in this way:

Change the rootDN password:

First, run slappasswd to get the hash for the new password you want:

Now prepare a file with this content:

Finally, run the ldapmodify command:

We still have the actual cn=admin,dc=example,dc=com dn in the dc=example,dc=com database, so let’s change it too. Since this is a regular entry in this database suffix, we can use ldappasswd:

Adding a schema

Schemas can only be added to cn=config if they are in LDIF format. If not, they will first have to be converted. You can find unconverted schemas in addition to converted ones in the directory.

In the following example we’ll add the password policy (ppolicy) schema. This schema exists in both converted (.ldif) and native (.schema) formats, so we don’t have to convert it and can use ldapadd directly:

If the schema you want to add does not exist in LDIF format, a nice conversion tool that can be used is provided in the package.

Logging

Activity logging for slapd is very useful when implementing an OpenLDAP-based solution yet it must be manually enabled after software installation. Otherwise, only rudimentary messages will appear in the logs. Logging, like any other such configuration, is enabled via the slapd-config database.

OpenLDAP comes with multiple logging levels with each one containing the lower one (additive). A good level to try is stats. The slapd-config man page has more to say on the different subsystems.

Create the file with the following contents:

Implement the change:

This will produce a significant amount of logging and you will want to throttle back to a less verbose level once your system is in production. While in this verbose mode your host’s syslog engine (rsyslog) may have a hard time keeping up and may drop messages:

You may consider a change to rsyslog’s configuration. In , put:

And then restart the rsyslog daemon:

»Configuration

Auth methods must be configured in advance before users or machines can
authenticate. These steps are usually completed by an operator or configuration
management tool.

Enable the ldap auth method:
Configure connection details for your LDAP server, information on how to
authenticate users, and instructions on how to query for group membership. The
configuration options are categorized and detailed below.

Connection parameters

(string, required) — The LDAP server to connect to. Examples: , . This can also be a comma-delineated list of URLs, e.g. , in which case the servers will be tried in-order if there are errors during the connection process.
(bool, optional) — If true, issues a command after establishing an unencrypted connection.
— (bool, optional) — If true, skips LDAP server SSL certificate verification — insecure, use with caution!
— (string, optional) — CA certificate to use when verifying LDAP server certificate, must be x509 PEM encoded.
— (string, optional) — Client certificate to provide to the LDAP server, must be x509 PEM encoded.
— (string, optional) — Client certificate key to provide to the LDAP server, must be x509 PEM encoded.

Binding parameters

There are two alternate methods of resolving the user object used to authenticate the end user: Search or User Principal Name. When using Search, the bind can be either anonymous or authenticated. User Principal Name is a method of specifying users supported by Active Directory. More information on UPN can be found .

Binding — Authenticated Search

(string, optional) — Distinguished name of object to bind when performing user and group search. Example:
(string, optional) — Password to use along with when performing user search.
(string, optional) — Base DN under which to perform user search. Example:
(string, optional) — Attribute on user attribute object matching the username passed when authenticating. Examples: , ,

Binding — Anonymous Search

(bool, optional) — If true, use anonymous bind to discover the bind DN of a user
(string, optional) — Base DN under which to perform user search. Example:
(string, optional) — Attribute on user attribute object matching the username passed when authenticating. Examples: , ,
(bool, optional) — This option prevents users from bypassing authentication when providing an empty password. The default is .
(bool, optional) — Use anonymous binds when performing LDAP group searches. Defaults to .

Binding — User Principal Name (AD)

upndomain (string, optional) — userPrincipalDomain used to construct the UPN string for the authenticating user. The constructed UPN will appear as @UPNDomain. Example: example.com, which will cause vault to bind as username@example.com.

Group Membership Resolution

Once a user has been authenticated, the LDAP auth method must know how to resolve which groups the user is a member of. The configuration for this can vary depending on your LDAP server and your directory schema. There are two main strategies when resolving group membership — the first is searching for the authenticated user object and following an attribute to groups it is a member of. The second is to search for group objects of which the authenticated user is a member of. Both methods are supported.

(string, optional) — Go template used when constructing the group membership query. The template can access the following context variables: . The default is , which is compatible with several common directory schemas. To support nested group resolution for Active Directory, instead use the following query: .
(string, required) — LDAP search base to use for group membership search. This can be the root containing either groups or users. Example:
(string, optional) — LDAP attribute to follow on objects returned by in order to enumerate user group membership. Examples: for groupfilter queries returning group objects, use: . For queries returning user objects, use: . The default is .

Note: When using Authenticated Search for binding parameters (see above) the distinguished name defined for is used for the group search. Otherwise, the authenticating user is used to perform the group search.

Use for more details.

Порты Active Directory

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

Реализации

Серверная часть

LDAP является широко используемым стандартом доступа к службам каталогов. Из свободно распространяемых открытых реализаций наиболее известен сервер OpenLDAP, из проприетарных — поддержка протокола имеется в Active Directory — службе каталогов от компании Microsoft, предназначенной для централизации управления сетями Windows. Сервер IBM Lotus Domino в своем составе также имеет службу LDAP. Свои реализации служб каталогов, поддерживающие LDAP как протокол доступа, предлагают и другие крупные компании, например, Novell и Sun — OpenDS и, впоследствии, OpenDJ.

Перечень наиболее известных на сегодняшний день LDAP-серверов:

OpenLDAP
ForgeRock OpenDJ
Novell eDirectory
Apple Open Directory (форк проекта OpenLDAP)
Microsoft Active Directory
Samba4 LDAP (OpenSource-реализация MS AD)
RedHat Directory Server
389 Directory Server (по сути тестовая версия предыдущего)
Oracle Directory Server
Apache Directory Server
IBM Tivoli Directory Server
IBM Domino LDAP
CommuniGate LDAP

Клиентская часть

В качестве клиентов LDAP выступают как адресные книги почтовых клиентов, так и back-end’ы различных сетевых служб (серверы DNS, SMTP, Samba, UTS и т. д.).