Аутентификация с помощью LDAP¶

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

Picodata Enterprise

Данная функция доступна только в коммерческой версии Picodata.

Общие сведения¶

Lightweight Directory Access Protocol (далее LDAP) — это легковесный протокол для доступа к службе каталогов X.500, которая часто используется организациями для контроля доступа к ресурсам и управления доменными учетными записями. Существует множество серверов, которые поддерживают данный протокол: OpenLDAP, GLAuth и прочие.

Механизм аутентификации пользователей¶

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

В качестве запроса в Picodata используется BIND, позволяющий произвести аутентификацию пользователя с использованием заранее известного Distinguished Name (DN) и факторов аутентификации (например, пароля).

Для использования протокола LDAP в Picodata следует задать для учетной записи пользователя тип аутентификации ldap. Примеры см. ниже.

Особенности работы LDAP¶

Коммуникация с сервером LDAP происходит один раз при установке новой пользовательской сессии. Если аутентификация пройдена успешно, сессия будет установлена, и до самого её конца повторная аутентификация производиться не будет.
Метод отвечает только за аутентификацию. Для синхронизации групп, прав и владения объектами с удаленным сервером LDAP следует использовать плагин Argus.
Метод требует дополнительной настройки кластера через файл конфигурации Picodata.
Метод невозможно использовать в случае отказа удаленного сервера LDAP.
Метод не кеширует результаты аутентификации.

Поддержка защищённого режима¶

Зашифрованная коммуникация по протоколу LDAP возможна в двух вариантах:

LDAP over TLS (implicit): подключение выполняется к отдельному порту (636), и полностью инкапсулируется внутри TLS/SSL. В этом случае никакой незашифрованный LDAP-трафик по каналу не проходит.
LDAP + StartTLS (start_tls): изначальное подключение выполняется к обычному порту (389) и начинается в незашифрованном виде. Потом клиент посылает серверу команду StartTLS и подключение начинает использовать шифрование.

Оба варианта обеспечивают конфиденциальность и безопасность данных при доступе к службам каталогов. Если сервер слушает отдельный порт для LDAPS (обычно 636), необходимо использовать метод implicit; если шифрование настроено поверх стандартного LDAP-порта (389) — start_tls.

Для включения любого из этих режимов необходимо выставить параметр instance.ldap.tls.enabled в значение true.

За выбор метода использования TLS отвечает параметр instance.ldap.tls.method: implicit использует LDAP over TLS (LDAPS), а start_tls — LDAP + StartTLS.

После выполнения настроек зашифрованное подключение будет работать автоматически если на стороне LDAP-сервера используется сертификат, подписанный корневым сертификатом (CA), которому доверяет клиент.

В случае если такой корневой сертификат не находится в системном хранилище доверенных сертификатов, возможно использование опции instance.ldap.tls.ca_file для указания альтернативных доверенных корневых сертификатов.

Настройка¶

Для использования LDAP-аутентификации под определенным пользователем в Picodata требуется:

наличие в сети запущенного сервера LDAP, на котором заведен этот пользователь
установленные настройки узлов Picodata
наличие пользователя с таким же именем и типом аутентификации ldap в Picodata

Настройка инстанса для аутентификации LDAP¶

Для корректной работы метода нужно установить следующие параметры Picodata на каждом инстансе, который должен принимать LDAP-аутентификацию:

instance.ldap.enabled — признак поддержки LDAP-аутентификации на инстансе. Необходимое значение — true.
instance.ldap.connect — строка <host>:<port>, указывающая на удаленный сервер LDAP.
instance.ldap.dn_format — формат-строка DN для запроса BIND.
instance.ldap.tls.enabled — включение/выключение TLS.
instance.ldap.tls.method — метод TLS-подключения.
instance.ldap.tls.ca_file — путь к файлу с альтернативными доверенными корневыми сертификатами (опционально).

Пример конфигурационного файла инстанса i1, подключающегося к 127.0.0.1:1389 с использованием LDAP over TLS:

i1.yml

cluster:
  name: my_cluster
  tier:
    default:

instance:
  instance_dir: './i1'
  name: 'i1'
  tier: 'default'
  peer: [ 127.0.0.1:3301 ]

  iproto:
      listen: '0.0.0.0:3301'
      advertise: '127.0.0.1:3301'
  http:
      listen: '0.0.0.0:8081'
  pgproto:
    listen: '0.0.0.0:4327'
    advertise: '127.0.0.1:4327'
  ldap:
    enabled: true
    connect: '127.0.0.1:1636'
    dn_format: 'cn=$USER,ou=users,dc=example,dc=org'
    tls:
      enabled: true
      method: 'implicit'
      # если необходимо использовать Root CA не из системного хранилища
      # ca_file: '/etc/picodata/ldap-ca.pem'

Здесь 1636 используется как нестандартный порт, типичный для тестовых LDAP-серверов (например, GLAuth). В продуктовой среде обычно используется стандартный порт 636 для LDAPS либо 389 для LDAP/StartTLS.

Для того чтобы такая конфигурация работала, имя сервера, указанное в instance.ldap.connect, должно совпадать с именем, указанным в сертификате LDAP-сервера (SAN или CN), а также этот сертификат должен быть доверенным.

В текущей реализации Picodata строка форматирования DN общая для всех пользователей. Кроме того, нет возможности установить персональный DN для конкретного пользователя. В строке dn_format доступна только подстановка имени пользователя через $USER.

Запуск кластера, состоящего из одного инстанса i1, с авторизацией в LDAP:

picodata run --config i1.yml

Настройка пользователей LDAP в Picodata¶

Как и другие методы аутентификации, ldap можно указать при создании нового пользователя через параметр USING:

CREATE USER "username" USING ldap;

Помимо этого, можно сменить метод аутентификации уже существующего пользователя:

ALTER USER "username" USING ldap;

Обратите внимание, что при использовании метода LDAP не требуется указывать пароль пользователя. Это связано с тем, что Picodata не хранит пароли: при каждой попытке аутентификации клиент будет отправлять пароль отдельно; в свою очередь, Picodata будет использовать полученный пароль при взаимодействии с сервером LDAP. Также рекомендуется включить TLS для передачи пароля по сети в зашифрованном виде.

См. также:

Управление доступом

Устранение неполадок¶

После запуска инстанса и настройки пользователя попробуйте подключиться под созданным пользователем через psql; в случае ошибки проверьте журналы инстанса.

В отличие от других методов аутентификации, LDAP требует дополнительной настройки, без которой аутентификация с использованием этого метода будет невозможна. Также важно понимать, что любые проблемы с удаленным сервером LDAP немедленно отразятся на возможности аутентифицировать пользователей. Для решения этой проблемы администраторам предлагается временно изменить метод аутентификации (например, на 'md5') для затронутых пользователей при помощи функции смены пароля:

ALTER USER "username" WITH PASSWORD 'new_password' USING md5;

LDAP BIND-запросы регистрируются в журнале на уровне verbose. Ошибки взаимодействия регистрируются на уровне warn, а также сообщаются клиенту, подключающемуся по PostgreSQL-протоколу.