Настройка сервера аутентификации посредством связки kerberos+ldap на базе rosa enterprise linux server

Содержание:

Функциональное описание протокола
Example 4: LDAP name attributes
Системы настройки и управления LDAP
Для чего можно использовать LDAP?
Использование LDAP
Ссылки
Утилита ldapsearch (клиент OpenLDAP) и проверка подключения к контроллеру домена Active Directory
Область применения
Настраиваем RBAC-авторизацию
Конфигурирование IBM Directory Server
- Предварительные условия
Example 2: LDAP number filter
Стандарты
Механизм работы
Схемы LDAP
Реализации
- Серверная часть
- Клиентская часть
Структура

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

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

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

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

    (&(!(entryDN:dnSubtreeMatch:=dc=Piter,dc=Russia,ou=People,dc=example,dc=com))(objectClass=sambaSamAccount) (|(sn=Lazar*)(uid=Nakhims*)))

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

Example 4: LDAP name attributes

Как установить ubuntu server 14.04.1 lts? настройка сервера

The LDAP name attributes setting can be used to specify the “name” attributes of each record which are to be returned in the LDAP search results.

When you type in this field for example:cn sn displayNamethis requires to specify “cn”—>commonName means Full name of the user, “sn”—>Surname, last name or family name and “displayName” fields for each LDAP record.

See the following screenshot example of an Active Directory:

Further Examples:

cn sn displayNameRequires “cn”, “sn” and “displayName” fields for each LDAP record.
givenName Requires “givenName” field for each LDAP record.

vorName nachNameRequires “vorName” and “nachName” fields for each LDAP record.

Системы настройки и управления LDAP

Zentyal,
Webmin,
phpLDAPadmin,
Lume.

Установка и настройка терминального сервера на windows server

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

Установка и настройка сервера grafana на linux

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

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

Примеры промышленного использования служб каталогов:

Идентификация компьютеров
Аутентификация пользователей в единой системе
Группировка пользователей (в том числе системные группы)
Адресные книги
Представление штатно-кадровой структуры организации
Учет закрепления имущества организации за сотрудниками
Телефонные справочники
Управление пользовательскими ресурсами
Справочники адресов электронной почты
Хранение конфигурации приложений
Хранение конфигурации АТС

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

Какой тип информации может храниться в директориях? Информационная модель LDAP основана на записях (entry). Запись — это коллекция атрибутов (attribute), обладающая уникальным именем (Distinguished Name, DN). DN глобально-уникально для всего каталога и служит для однозначного указания на запись. Каждый атрибут записи имеет свой тип (type) и одно или несколько значений (value). Обычно типы — это мнемонические строки, в которых отражено назначение атрибута, например «cn» — для общепринятого имени (common name), или «mail» — для адреса электронной почты. Синтаксис значений зависит от типа атрибута. Например, атрибут cn может содержать значение Babs Jensen. Атрибут mail может содержать значение «babs@example.com». Атрибут jpegPhoto будет содержать фотографию в бинарном формате JPEG.
Как информация храниться в LDAP? Записи каталога LDAP выстраиваются в виде иерархической древовидной структуры. Традиционно, такая структура отражает географические и организационные границы. Записи, обозначающие страны, находятся наверху дерева. Чуть ниже располагаются записи о регионах и организациях. Еще ниже — информация об отделах, людях, принтерах, документах или о том, о чем вы подумаете. Дерево может быть создано, основываясь на доменных именах интернета такое именование позволяет узнать расположение службы директорий, используя Что такое DNS.
Как можно обратиться к информации? К записи обращаются по ее уникальному имени, которое состоит из собственно имени записи (так называемое относительное уникальное имя (Relative Distinguished Name, RDN) с прибавлением к нему имён записей-предков. Так, запись, описывающая Barbara Jensen в приведенном выше примере с Internet-именованием, имеет RDN uid=babs, и DN — uid=babs,ou=People,dc=example,dc=com.
Что такое slapd и что он может сделать? slapd (Stand-alone LDAP демон) это сервер директорий LDAP. Вы можете использовать его для обеспечения собственного сервера директорий. Ваша директория может содержать любую информацию, которую вы захотите. Вы так же можете подключить свою директорию к глобальной службе директорий LDAP или запустить службу директорий самостоятельно. Некоторые возможности slapd: пункт 1.9., например SASL, TLS (или SSL), поддерживает Unicode и языковые теги.
Что такое slurpd и что он может делать? slurpd(8) — демон, который, с помощью slapd(8), обеспечивает работу службы репликаций. Он отвечает за распространение изменений, сделанных в главной БД slapd, на другие БД slapd. Slurpd освобождает slapd от необходимости беспокоится, если другие БД slapd выключены или недоступны, когда произошли изменения в главной БД. Slurpd автоматически повторяет запросы на обновление. Slapd и Slurpd связаны через простой текстовый файл, который используется для записи изменений.

Ссылки

LDIF — формат обмена данными LDAP.
LDAP
PHP LDAP
Про LDAP по-русски: Руководство администратора OpenLDAP 2.4, Перевод учебника «LDAP for Rocket Scientists» и статьи.

samba_pdc + ddns + dhcp — с хранением всех данных в LDAP

Утилита ldapsearch (клиент OpenLDAP) и проверка подключения к контроллеру домена Active Directory

Проверку выполняем на примере Debian GNU/Linux 8 (Jessie). Сначала убедимся в том, что клиент OpenLDAP установлен в системе:

# dpkg -l | grep ldap

ii  ldap-utils          2.4.40+dfsg-1+deb8u2 amd64   OpenLDAP utilities
ii  libldap-2.4-2:amd64 2.4.40+dfsg-1+deb8u2 amd64   OpenLDAP libraries

Исходные данные для проверки подключения клиента OpenLDAP к LDAP-каталогу на примере контроллера домена Active Directory (AD):

ad.holding.com — Имя домена AD;
dc01.ad.holding.com — FQDN-имя контроллера домена AD;
s-LDAP-Check-User — Имя пользователь в домене AD, от имени которого выполняется подключение (уровень прав в домене — рядовой пользователь);
PaZsw0rd — Пароль пользователя s-LDAP-Check-User.
Test-User — Имя пользователя в домене AD, которого мы пытаемся найти в LDAP-каталоге.
«OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com» — DN-имя контейнера в AD, в котором выполняется поиск пользователя Test-User.

Проверка подключения по протоколу LDAP (TCP 389)

Используется подключение типа ldap:/. Учётные данные пользователя s-LDAP-Check-User передаются по сети в открытом виде:

$ ldapsearch -v -x \
 -D "s-LDAP-Check-User@ad.holding.com" -w "PaZsw0rd" \ 
 -b "OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com" \ 
 -H "ldap://dc01.ad.holding.com" sAMAccountName=Test-User

Проверка подключения по протоколу LDAPS (TCP 636)

Используется подключение типа ldaps:/. LDAP-сессия шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Чтобы LDAP-клиент доверял сертификату контроллера домена, нам нужно создать файл, содержащий корневые сертификаты доменных Центров сертификации, которыми подписан сертификат контроллера домена.
Назовём этот файл, например /etc/ssl/certs/cacerts.pem, и скопируем в него корневые сертификаты доменных ЦС в формате PEM и кодировке Base-64.

Изменим на время проверки конфигурационный файл клиента OpenLDAP /etc/ldap/ldap.conf, указав в переменной TLS_CACERT путь к созданному нами файлу с корневыми сертификатами доменных ЦС:

ldap.conf

...
#TLS_CACERT     /etc/ssl/certs/ca-certificates.crt
TLS_CACERT      etcsslcertscacerts.pem
...

После этого можно попробовать выполнить поиск по протоколу LDAPS:

$ ldapsearch -v -x \ 
 -D "s-LDAP-Check-User@ad.holding.com" -w "PaZsw0rd" \
 -b "OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com" \
 -H "ldaps://dc01.ad.holding.com" sAMAccountName=Test-User

Проверка подключения по протоколу LDAP с защитой StartTLS (TCP 389)

Используется подключение типа ldap:/ с дополнительными ключами, включающими TLS : -Z и -ZZ. LDAP-сессия также шифруется с помощью SSL-сертификата, предоставляемого контроллером домена. Первичное подключение к контроллеру домена AD происходит по порту 389, затем создаётся отдельный защищённый TLS-туннель, внутри которого и происходит весь LDAP-обмен между клиентом и сервером. Используется настроенный нами ранее файл корневых сертификатов доменных ЦС.

$ ldapsearch -Z -v -x \ 
 -D "s-LDAP-Check-User@ad.holding.com" -w "PaZsw0rd" \
 -b "OU=Test Users,OU=KOM,DC=ad,DC=holding,DC=com" \ 
 -H "ldap://dc01.ad.holding.com" sAMAccountName=Test-User

Автор первичной редакции:Алексей Максимов
Время публикации: 19.03.2017 18:04

Область применения

Элемент маркированного списка
Идентификация компьютеров
Аутентификация пользователей
Группировка пользователей (в том числе системные группы)
Адресные книги
Представление штатно-кадровой структуры организации
Учет закрепления имущества организации за сотрудниками
Телефонные справочники
Управление пользовательскими ресурсами
Справочники адресов электронной почты
Хранение конфигурации приложений

Хранение конфигурации АТС

Настраиваем RBAC-авторизацию

Для примера привяжем статического пользователя к системной роли cluster-admin, а пользователей группы developers – к роли view, позволяющей только просматривать ресурсы. Тогда содержимое файла crb.yml должно быть таким:

—

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRoleBinding

metadata:

  name: dex-admin

  namespace: kube-system

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: cluster-admin

subjects:

— kind: User

  name: «admin@dtln.cloud»

—

apiVersion: rbac.authorization.k8s.io/v1beta1

kind: ClusterRoleBinding

metadata:

  name: dex-developers

  namespace: kube-system

roleRef:

  apiGroup: rbac.authorization.k8s.io

  kind: ClusterRole

  name: view

subjects:

— kind: Group

  name: «developers»
Переключаемся на основной контекст и применяем созданный yaml-файл на кластер:

kubectl config set-context default

kubectl apply -f crb.yml
Смотрим доступные контексты и переключаемся обратно на нашего пользователя:

kubectl config get-contexts

kubectl config set-context johndoe-ash.dtln.cloud

На этом настройка Dex в связке с OpenLDAP закончена.

Пара советов напоследок:

Если возникают проблемы, первым делом нужно проверить форматирование yaml-файлов и обратить внимание на отступы.
Слэши в адресах должны соответствовать примерам.
Не забудьте посмотреть логи pod’ов Dex, Dex-auth, а также журналы юнитов kube-api на мастерах.

Конфигурирование IBM Directory Server

IBM Directory Server под управлением ОС AIX может быть сконфигурирован при
помощи следующих средств:

инструментальное средство с интерфейсом командной строки
;
аналог с графическим интерфейсом —
;
команда .

Необходимы следующие пакеты файлов для конфигурирования IBM Directory
Server:

пакеты файлов ldap.server
DB2 — база данных, которая требуется для работы с IBM Directory
Server

Предварительные
условия

Система должна работать в 64-битном режиме ядра. Для определения
режима ядра используется команда .
AIX требует 64-битное оборудование. Получить информацию об
оборудовании можно с помощью команды
Требуется минимум оперативной памяти 512MB (рекомендуется иметь не
менее 1GB).
IBM Directory Server требует по меньшей мере 80MB свободного
пространства на диске, где будет создана база данных DB2.
Если планируется установить InstallShield GUI, то нужно по крайней
мере 100MB свободного пространства в каталоге /var и по меньшей мере
свободных 400MB в каталоге /tmp.

AIX предоставляет команду для настройки серверов IBM
Directory и клиентов, которые будут работать с этими серверами:

Команда выполняет следующие действия при
осуществлении настройки нового сервера:

Создает базу данных с именем ldapdb2.
Создает дерево AIX DN (суффикс) для каждого пользователя или группы
пользователей ОС AIX.
Экспортирует пользователей и группы из базы данных локального хоста в
базу данных LDAP.
Устанавливает имя и пароль администратора LDAP-сервера.
Предоставляет в качестве дополнительной возможности серверу
использовать протокол Secure Sockets Layer (SSL).
Устанавливает плагин /usr/ccs/lib/libsecldapaudit для аудита
LDAP-сервера.
Запускает LDAP-сервер после того, как все действия, описанные выше,
выполнены.
Добавляет запись LDAP-сервера в файл /etc/inittab для автоматического
запуска после перезагрузки системы.

mksecldap -s -a cn=admin -p passwd -S rfc2307aix

Вся установочная информация хранится в файле /etc/ibmslapd.conf.

Example 2: LDAP number filter

Here you have to specify your search criteria for number look ups.

When you type in this field for example:(|(telephoneNumber=%)(Mobile=%)(ipPhone=%))the result of your search will be all LDAP records which have the “telephoneNumber” OR “Mobile” OR “ipPhone” field equal to the entered prefix.

When you type in this field: (&(telephoneNumber=%)(sn=*))the result of your search will be all LDAP records which have the “sn” field set AND the “telephoneNumber” field equal to the entered prefix.

Additionally as of version 10.1.27.0 the greater or equal, less or equal and approximate filters are supported. What is returned is dependent on the server implementation. When you type (telephoneNumber >= 5) , it could result in a numeric or lexicographic comparison, and the subsequent result. Likewise

Стандарты

Протокол LDAP определён в следующих RFC:

Кроме протокола, есть верхнеуровневые международные стандарты, описывающие все, что связано с моделью интеграции систем и каталогом (Directory), доступ к которому реализуется с помощью LDAP и DAP:

Recommendation ITU-T X.200 (1994) | ISO/IEC 7498-1:1994, Information technology – Open Systems Interconnection – Basic Reference Model: The basic model.
Recommendation ITU-T X.500 (2019) | ISO/IEC 9594-1:2020, Information technology – Open Systems Interconnection – The Directory: Overview of concepts, models and services.
Recommendation ITU-T X.501 (2019) | ISO/IEC 9594-2:2020, Information technology – Open Systems Interconnection – The Directory: Models.
Recommendation ITU-T X.509 (2019) | ISO/IEC 9594-8:2020, Information technology – Open Systems Interconnection – The Directory: Public-key and attribute certificate frameworks.
Recommendation ITU-T X.511 (2019) | ISO/IEC 9594-3:2020, Information technology – Open Systems Interconnection – The Directory: Abstract service definition.
Recommendation ITU-T X.518 (2019) | ISO/IEC 9594-4:2020, Information technology – Open Systems Interconnection – The Directory: Procedures for distributed operation.
Recommendation ITU-T X.519 (2019) | ISO/IEC 9594-5:2020, Information technology – Open Systems Interconnection – The Directory: Protocol specifications.
Recommendation ITU-T X.520 (2019) | ISO/IEC 9594-6:2020, Information technology – Open Systems Interconnection – The Directory: Selected attribute types.
Recommendation ITU-T X.521 (2019) | ISO/IEC 9594-7:2020, Information technology – Open Systems Interconnection – The Directory: Selected object classes.
Recommendation ITU-T X.525 (2019) | ISO/IEC 9594-9:2020, Information technology – Open Systems Interconnection – The Directory: Replication.

Механизм работы

LDAP использует клиент-серверную модель. Один или несколько серверов LDAP содержат информацию, образующую информационное дерево каталога (directory information tree, DIT). Клиент подключается к серверу и делает запрос. В ответ сервер отправляет результаты обработки запроса и/или указатель на то, где клиент может получить дополнительные сведения (обычно, на другой сервер LDAP). Независимо от того, к какому серверу LDAP подключается клиент, он увидит одинаковое представление каталога; на записи, расположенные на одном сервере LDAP, будут указывать правильные ссылки при обращении к другому серверу LDAP, и наоборот. Это важная особенность глобальной службы каталогов.
Перечень наиболее известных на сегодняшний день 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

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

top
organization
organizationalUnit
person
inetOrgPerson

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

slapcat

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

# slapcat
dn: dc=nodomain
objectClass: top
objectClass: dcObject
objectClass: organization
o: nodomain
dc: nodomain
structuralObjectClass: organization
entryUUID: 353459a6-590e-1034-99e4-6b77cb057f89
creatorsName: cn=admin,dc=nodomain
createTimestamp: 20150307120702Z
entryCSN: 20150307120702.099143Z#000000#000#000000
modifiersName: cn=admin,dc=nodomain
modifyTimestamp: 20150307120702Z

dn: cn=admin,dc=nodomain
objectClass: simpleSecurityObject
objectClass: organizationalRole
cn: admin
description: LDAP administrator
userPassword:: e1NTSEF9L3k1MTBJalk2WFRJMVBVY0t1NzVBSXBGVzFhSm9YTHM=
structuralObjectClass: organizationalRole
entryUUID: 3542135c-590e-1034-99e5-6b77cb057f89
creatorsName: cn=admin,dc=nodomain
createTimestamp: 20150307120702Z
entryCSN: 20150307120702.189090Z#000000#000#000000
modifiersName: cn=admin,dc=nodomain
modifyTimestamp: 20150307120702Z

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

Реализации

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

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 и т. д.).

Структура

Протокол доступа к каталогам LDAP соответствует модели X.500, принятой в качестве стандарта в 1993 году:

Каталог представляет собой дерево каталогов записей.
Запись состоит из набора атрибутов.
Атрибут имеет имя (атрибут типа или атрибут описания) и одно или несколько значений.
Каждая запись имеет уникальный идентификатор — отличительное имя (Distinguished Name, DN). Которое состоит из относительного отличительного имени (Relative Distinguished Name, RDN) составленное из атрибута(ов) записи, за которым следует родительская запись отличительного имени. То есть DN является полным именем файла, а RDN относительное имя в папке.

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

В LDAP запись может выглядеть примерно так:

dn: cn=Иван Иванов,dc=example,dc=com
cn: Иван Иванов
givenName: Иван
sn: Иванов
telephoneNumber: +1 888 555 6789
telephoneNumber: +1 888 555 1232
mail: ivan@example.com
manager: cn=Ася Александрова, dc=example,dc=com
objectClass: inetOrgPerson
objectClass: organizationalPerson
objectClass: person
objectClass: top

Здесь: dn — это имя записи, которое не является не атрибутом, не частью записи. «cn=Иван Иванов» — это RDN записи, a «dc=example,dc=com» — DN родительской записи, в которой dc обозначает доменный компонент. В остальных строках показаны атрибуты записи.

Сервер хранит подкаталог (subtree) начиная с конкретной записи, например, «dc=example,dc=com» и её расширения. На сервере также могут храниться ссылки на другие серверы, таким образом, попытка найти «ou=department,dc=example,dc=com» может вернуть предложение или постоянную ссылку на сервер, который хранит эту часть папки каталога. Клиент может подсоединиться к этому серверу. Некоторые серверы объединены в цепи, то есть отдельный сервер связывается с другим сервером и возвращает результат клиенту.