АРХИВА 10 Help

LDAP

АРХИВА поддерживает аутентификацию пользователей через LDAP-сервисы (OpenLDAP, 389 Directory Server, FreeIPA и др.), что позволяет централизованно управлять доступом в организации. Для Active Directory предназначен отдельный способ авторизации — Active Directory (Kerberos).

Процесс аутентификации

При использовании LDAP-аутентификации система выполняет следующие этапы:

  1. Поиск пользователя

    1. АРХИВА подключается к службе каталогов, используя учетную запись службы (Service DN) и соответствующий пароль.

    2. Система осуществляет поиск пользователя, начиная с Base DN, сопоставляя введенное имя пользователя со значением Bind Attribute (например, uid или sAMAccountName).

    3. Извлекается Distinguished Name (DN) найденного пользователя.

  2. Проверка пароля

    • АРХИВА открывает новое соединение и выполняет операцию Bind, используя:

      • Найденный DN пользователя.

      • Пароль, введенный пользователем (фактическая проверка выполняется на стороне сервера LDAP).

  3. Завершение входа

    • АРХИВА читает служебный атрибут entryUUID — неизменяемый уникальный идентификатор записи. Именно по нему пользователь опознаётся системой (см. раздел «Идентификатор пользователя (entryUUID)»).

    • После успешной аутентификации пользователю назначается роль согласно правилам сопоставления.

    • Из LDAP извлекается адрес электронной почты.

    • Дополнительно могут быть получены отображаемое имя и номер мобильного телефона.

Полезные инструменты

Для диагностики и изучения структуры вашего каталога рекомендуем использовать:

  • Утилиту ldapsearch (для Linux).

  • Графические LDAP-браузеры: Apache Directory Studio, Softerra, JXplorer и другие.

Основные параметры конфигурации

Поле

Описание

Пример

DNS Сервер IP адрес

Опционально. IP-адрес DNS-сервера, если требуется использовать альтернативный

8.8.8.8

DNS сайт

Опционально. DNS-суффикс для разрешения локальных имен

company.local

Адрес LDAP сервера

Полное доменное имя (FQDN) и порт LDAP-сервера

openldap.company.com:389

Базовый DN (Base DN)

DN, с которого начинается поиск пользователей

dc=company,dc=com

Вход в учетную запись службы (Service DN)

DN учетной записи с правами чтения каталога

cn=ldapreader,cn=Users,dc=company,dc=com

Пароль учетной записи службы

Пароль для Service DN

(ввести вручную)

Атрибуты поиска и сопоставления

Поле

Описание

Пример

Атрибут привязки

Атрибут, по которому идентифицируется пользователь (логин)

uid или sAMAccountName

Атрибут электронной почты

Основной атрибут, содержащий email-адрес пользователя

mail

Значение электронной почты

Регулярное выражение для извлечения email

(.*)

Основной атрибут email

Альтернативный атрибут для email-адреса

proxyAddresses

Основное значение email

Регулярное выражение для альтернативного email-адреса

SMTP:(.*)

Атрибут отображаемого имени

Атрибут, содержащий полное имя пользователя

displayName или cn

Атрибут мобильного

Атрибут, содержащий номер мобильного телефона

mobile или telephoneNumber

Идентификатор пользователя (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

Убедитесь, что сервер отдаёт идентификатор под той же учётной записью службы, которая указана в настройках АРХИВА:

ldapsearch -x -H ldap://openldap.company.com:389 \ -D "cn=ldapreader,cn=Users,dc=company,dc=com" -W \ -b "dc=company,dc=com" \ "(uid=ivanov)" dn uid entryUUID

Ожидаемый результат содержит строку entryUUID:

dn: uid=ivanov,ou=People,dc=company,dc=com uid: ivanov entryUUID: 159a166c-e61a-11de-8a39-0800200c9a66

Если атрибут entryUUID в выводе отсутствует, сервер не поддерживает RFC 4530 либо у учётной записи службы нет прав на чтение этого атрибута. В таком случае вход в АРХИВА выполняться не будет.

Назначение ролей

После настройки подключения необходимо создать правила сопоставления ролей:

  1. Перейдите в Настройки → Авторизация.

  2. Выберите LDAP в качестве метода авторизации.

  3. Нажмите «Назначить новую роль», чтобы связать LDAP-пользователей с ролями в АРХИВА.

  4. В поле соответствия можно использовать регулярные выражения (например, .* для назначения роли всем пользователям).

Рекомендации

  • Убедитесь, что Service DN обладает всеми необходимыми правами доступа к атрибутам поиска и входа, включая чтение entryUUID.

  • Проверьте поддержку entryUUID (RFC 4530) до ввода системы в эксплуатацию — см. раздел «Проверка поддержки entryUUID».

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

09 September 2026