LDAP-аутентификация для OpenSearch: минимальный config.yml и production-конфигурация

LDAP-аутентификация в OpenSearch настраивается в два этапа. Сначала подключите минимальную конфигурацию, проверьте вход тестовой учетной записью и убедитесь, что каталог отвечает корректно. После этого добавьте TLS, несколько контроллеров домена и маппинг групп.

Минимальный вариант помогает быстро найти ошибки в адресе LDAP-сервера, Base DN, фильтре поиска и учетных данных. Production-конфигурация решает эксплуатационные задачи: шифрует соединение, повышает доступность каталога и назначает права через LDAP-группы. Значения в примерах условные, их нужно заменить параметрами вашей среды.

LDAP-аутентификация OpenSearch: что настроить сначала

Файл config.yml содержит настройки Security plugin OpenSearch. В нем задаются HTTP-аутентификатор, способ проверки учетных данных, адреса LDAP-серверов, учетная запись для поиска и параметры каталога.

Рабочий порядок состоит из четырех действий:

1. Подготовить минимальный блок LDAP.
2. Проверить вход по логину и паролю.
3. Зафиксировать результат базового теста.
4. Добавить TLS, резервные контроллеры домена и группы.

Минимальная и расширенная конфигурация: различие по цели

Не смешивайте эти этапы. Если вход не работает в минимальной схеме, TLS и маппинг групп усложнят диагностику и не устранят ошибку в базовых параметрах.

OpenSearch LDAP минимальная конфигурация в config.yml

Ниже приведен ориентировочный блок для Security plugin OpenSearch. Он показывает минимальный состав настроек: базовую HTTP-аутентификацию, один LDAP-сервер и поиск пользователя по атрибуту uid.

config:
  dynamic:
    authc:
      ldap:
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: false
            enable_start_tls: false
            hosts:
              - ldap.example.org:389
            bind_dn: cn=opensearch,dc=example,dc=org
            password: CHANGE_ME
            userbase: ou=People,dc=example,dc=org
            usersearch: '(uid={0})'
            username_attribute: uid

В конкретной версии OpenSearch и Security plugin расположение секции может отличаться. Перед применением сверяйте структуру файла с конфигурацией вашей версии и сохраняйте резервную копию рабочего config.yml.

Какие значения заменить перед запуском

• ldap.example.org:389, адрес и порт LDAP-сервера в вашей сети.
• cn=opensearch,dc=example,dc=org, DN сервисной учетной записи, которая выполняет поиск пользователей.
• CHANGE_ME, пароль сервисной учетной записи. Не храните его в открытом виде в общем репозитории.
• ou=People,dc=example,dc=org, база поиска пользователей.
• (uid={0}), фильтр поиска. Для Active Directory часто используют другой атрибут, например sAMAccountName.
• uid, атрибут, из которого OpenSearch получает имя пользователя.

Значения example.org, dc=example, opensearch и CHANGE_ME служат заглушками. Они не подходят для копирования без изменений.

Проверка входа по логину и паролю

1. Сохраните резервную копию текущего config.yml.
2. Внесите LDAP-блок и примените конфигурацию способом, который используется в вашей установке OpenSearch.
3. Выполните вход в OpenSearch тестовой учетной записью каталога.
4. Зафиксируйте результат: успешный вход подтверждает базовую проверку логина и пароля.

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

Если вход завершился ошибкой, не переходите сразу к TLS. Сначала проверьте адрес и порт LDAP, Base DN, DN и пароль сервисной учетной записи, фильтр usersearch, атрибут имени пользователя и доступность каталога с узла OpenSearch.

Как диагностировать минимальную LDAP-настройку до усложнения схемы

Диагностику удобно разделить на два класса ошибок:

• Ошибка подключения: OpenSearch не устанавливает соединение с LDAP-сервером, не достигает порта или получает таймаут.
• Ошибка учетных данных: сервер доступен, но пользователь не найден либо пароль не прошел проверку.

Проверьте примененный файл, а не только его локальную копию. Затем отдельно проверьте доступность LDAP с хоста OpenSearch, корректность DN сервисной учетной записи и поиск тестового пользователя. Для расширенного алгоритма с командами ldapwhoami, tcpdump и анализом логов используйте шпаргалку по диагностике LDAP-аутентификации.

Успешный вход тестового пользователя служит контрольной точкой. Запишите его до перехода к TLS и группам: после каждого изменения будет понятно, какой блок повлиял на результат.

OpenSearch LDAP production настройка: расширенный config.yml

Production-вариант сохраняет базовую логику минимальной схемы и добавляет три слоя: защищенное соединение, несколько адресов каталога и поиск LDAP-групп.

config:
  dynamic:
    authc:
      ldap:
        http_enabled: true
        transport_enabled: true
        order: 1
        http_authenticator:
          type: basic
          challenge: false
        authentication_backend:
          type: ldap
          config:
            enable_ssl: true
            enable_start_tls: false
            enable_ssl_client_auth: false
            verify_hostnames: true
            hosts:
              - dc01.example.org:636
              - dc02.example.org:636
            bind_dn: cn=opensearch,dc=example,dc=org
            password: CHANGE_ME
            userbase: dc=example,dc=org
            usersearch: '(sAMAccountName={0})'
            username_attribute: sAMAccountName
            rolesearch: '(member={0})'
            rolebase: ou=Groups,dc=example,dc=org
            rolename: cn
            resolve_nested_roles: true

Пример объединяет типовые production-настройки, но не определяет структуру вашего каталога. Для OpenLDAP могут потребоваться uid, member или другой атрибут членства. Для Active Directory часто применяют sAMAccountName и группы с атрибутом member.

TLS для защищенного подключения к LDAP

Параметр enable_ssl: true включает защищенное LDAP-соединение. В примере используется порт 636, который обычно применяют для LDAPS. Вариант с StartTLS требует отдельной схемы и другого набора значений, поэтому не смешивайте его с LDAPS.

• Проверьте, что сертификат LDAP-сервера доверен узлу OpenSearch.
• Проверьте имя сервера в сертификате и значение verify_hostnames: true.
• Убедитесь, что каждый адрес из hosts доступен по защищенному порту.
• Проверьте срок действия сертификатов до переключения пользователей.

Для отдельной настройки шифрования и проверки сертификатов используйте руководство LDAP vs LDAPS. Сначала подтвердите TLS-соединение, затем проверяйте группы.

Несколько контроллеров домена

Список hosts содержит несколько контроллеров домена. В примере OpenSearch может обратиться к dc01.example.org:636 и dc02.example.org:636. Замените эти адреса реальными серверами каталога и проверьте их доступность с каждого узла OpenSearch.

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

Маппинг LDAP-групп и управление доступом

Параметры rolesearch, rolebase, rolename и resolve_nested_roles позволяют найти группы пользователя и передать их в Security plugin. Они отвечают за поиск ролей в каталоге. Связь найденных ролей с правами OpenSearch задается маппингом ролей Security plugin.

sg_all_access:
  reserved: false
  hidden: false
  backend_roles:
    - opensearch-admins

sg_readall:
  reserved: false
  hidden: false
  backend_roles:
    - opensearch-readers

Названия opensearch-admins и opensearch-readers должны совпадать с именами групп или ролей, которые возвращает LDAP-поиск. Для группы администратора проверьте полный доступ отдельно. Для группы читателей убедитесь, что лишние операции запрещены.

Точный файл и способ загрузки маппинга зависят от версии Security plugin. Не помещайте этот блок внутрь config.yml, если ваша установка ожидает его в отдельной конфигурации ролей. Сначала подтвердите успешный LDAP-вход, затем проверяйте членство в группах и выданные разрешения.

Проверка production-конфигурации LDAP в OpenSearch

Что проверить после изменения config.yml

1. Тестовый пользователь входит через защищенное LDAP-соединение.
2. Вход работает с первым контроллером домена.
3. Вход сохраняется после временного отключения первого контроллера и проверки второго.
4. OpenSearch распознает ожидаемую LDAP-группу.
5. Администратор получает назначенные права, а читатель не получает административный доступ.
6. Неверный пароль отклоняется.
7. Пользователь без разрешенной группы не получает доступ сверх заданной политики.

Фиксируйте результаты до и после каждого изменения. Такая последовательность отделяет проблемы TLS, отказоустойчивости и авторизации по группам.

Когда минимальный вариант нельзя оставлять в production

Минимальный config.yml подходит для первичной проверки логина и пароля. Оставлять его в production нельзя, если политика среды требует шифрования LDAP-трафика, резервирования контроллеров домена или централизованного управления правами.

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

Минимальный и production-вариант: итоговое сравнение

Начните с минимального варианта и зафиксируйте успешный результат. Затем включите TLS, добавьте второй контроллер домена, настройте поиск групп и проверьте фактические права каждой тестовой учетной записи. Такой порядок сокращает область поиска при ошибках и дает предсказуемый путь к production-настройке OpenSearch LDAP.