LDAP
АРХИВА поддерживает аутентификацию пользователей через LDAP-сервисы (OpenLDAP, 389 Directory Server, FreeIPA и др.), что позволяет централизованно управлять доступом в организации. Для Active Directory предназначен отдельный способ авторизации — Active Directory (Kerberos).
Процесс аутентификации
При использовании LDAP-аутентификации система выполняет следующие этапы:
Поиск пользователя
АРХИВА подключается к службе каталогов, используя учетную запись службы (Service DN) и соответствующий пароль.
Система осуществляет поиск пользователя, начиная с Base DN, сопоставляя введенное имя пользователя со значением Bind Attribute (например,
uidилиsAMAccountName).Извлекается Distinguished Name (DN) найденного пользователя.
Проверка пароля
АРХИВА открывает новое соединение и выполняет операцию Bind, используя:
Найденный DN пользователя.
Пароль, введенный пользователем (фактическая проверка выполняется на стороне сервера LDAP).
Завершение входа
АРХИВА читает служебный атрибут
entryUUID— неизменяемый уникальный идентификатор записи. Именно по нему пользователь опознаётся системой (см. раздел «Идентификатор пользователя (entryUUID)»).После успешной аутентификации пользователю назначается роль согласно правилам сопоставления.
Из LDAP извлекается адрес электронной почты.
Дополнительно могут быть получены отображаемое имя и номер мобильного телефона.
Полезные инструменты
Для диагностики и изучения структуры вашего каталога рекомендуем использовать:
Утилиту
ldapsearch(для Linux).Графические LDAP-браузеры: Apache Directory Studio, Softerra, JXplorer и другие.
Основные параметры конфигурации
Поле | Описание | Пример |
|---|---|---|
DNS Сервер IP адрес | Опционально. IP-адрес DNS-сервера, если требуется использовать альтернативный |
|
DNS сайт | Опционально. DNS-суффикс для разрешения локальных имен |
|
Адрес LDAP сервера | Полное доменное имя (FQDN) и порт LDAP-сервера |
|
Базовый DN (Base DN) | DN, с которого начинается поиск пользователей |
|
Вход в учетную запись службы (Service DN) | DN учетной записи с правами чтения каталога |
|
Пароль учетной записи службы | Пароль для Service DN | (ввести вручную) |
Атрибуты поиска и сопоставления
Поле | Описание | Пример |
|---|---|---|
Атрибут привязки | Атрибут, по которому идентифицируется пользователь (логин) |
|
Атрибут электронной почты | Основной атрибут, содержащий email-адрес пользователя |
|
Значение электронной почты | Регулярное выражение для извлечения email |
|
Основной атрибут email | Альтернативный атрибут для email-адреса |
|
Основное значение email | Регулярное выражение для альтернативного email-адреса |
|
Атрибут отображаемого имени | Атрибут, содержащий полное имя пользователя |
|
Атрибут мобильного | Атрибут, содержащий номер мобильного телефона |
|
Идентификатор пользователя (entryUUID)
Для однозначного распознавания пользователя АРХИВА использует атрибут entryUUID — уникальный универсальный идентификатор записи (UUID), который сервер каталогов присваивает каждой записи в момент её создания. Формат и правила поведения атрибута определены официальным стандартом RFC 4530.
Свойства entryUUID:
Создаётся сервером. Значение генерирует LDAP-сервер; клиент не может ни задать его, ни изменить — атрибут доступен только для чтения.
Неизменяем. Не меняется при переименовании записи, переносе её в другую ветку каталога, смене логина, e-mail, отображаемого имени, телефона и роли.
Служебный (операционный) атрибут. При обычном поиске сервер отдаёт его только в том случае, если атрибут запрошен явно (или запрошены все операционные атрибуты —
+).Сохраняется при репликации. Реплики той же базы каталога отдают то же значение.
Требования к каталогу
Сервер каталогов реализует RFC 4530 и отдаёт значение
entryUUID— например OpenLDAP 2.4 и новее, 389 Directory Server, ForgeRock/OpenDJ, FreeIPA и другие серверы, соответствующие спецификации.Учётная запись службы (Service DN) имеет право на чтение атрибута
entryUUIDу записей пользователей.Active Directory атрибут
entryUUIDне отдаёт. Реализация LDAP в AD покрывает спецификации RFC не полностью, поэтому наборы атрибутов у AD и у классического LDAP-сервера различаются. Для AD предназначен способ авторизации Active Directory (Kerberos), в котором идентификатором служитobjectGUID. Настраивать способ LDAP для Active Directory нельзя.Каталоги и шлюзы, которые имитируют LDAP или Active Directory, но не отдают
entryUUID(objectGUID), не поддерживаются. С точки зрения протокола такие сервисы не являются ни LDAP, ни AD, и подстраивать под них механизм авторизации невозможно.
Проверка поддержки entryUUID
Убедитесь, что сервер отдаёт идентификатор под той же учётной записью службы, которая указана в настройках АРХИВА:
Ожидаемый результат содержит строку entryUUID:
Если атрибут entryUUID в выводе отсутствует, сервер не поддерживает RFC 4530 либо у учётной записи службы нет прав на чтение этого атрибута. В таком случае вход в АРХИВА выполняться не будет.
Назначение ролей
После настройки подключения необходимо создать правила сопоставления ролей:
Перейдите в Настройки → Авторизация.
Выберите LDAP в качестве метода авторизации.
Нажмите «Назначить новую роль», чтобы связать LDAP-пользователей с ролями в АРХИВА.
В поле соответствия можно использовать регулярные выражения (например,
.*для назначения роли всем пользователям).
Рекомендации
Убедитесь, что Service DN обладает всеми необходимыми правами доступа к атрибутам поиска и входа, включая чтение
entryUUID.Проверьте поддержку
entryUUID(RFC 4530) до ввода системы в эксплуатацию — см. раздел «Проверка поддержки entryUUID».При миграции с других LDAP-систем внимательно проверьте совместимость схем атрибутов. Учитывайте, что значения
entryUUIDмежду разными базами каталога не переносятся.