Перейти к основному содержимому
Перейти к основному содержимому

LDAP

Not supported in ClickHouse Cloud
примечание

Эта страница не применима к ClickHouse Cloud. Функция, описанная здесь, недоступна в сервисах ClickHouse Cloud. Смотрите руководство по совместимости с Cloud для получения дополнительной информации.

Сервер LDAP может использоваться для аутентификации пользователей ClickHouse. Существуют два различных подхода для этого:

  • Использование LDAP как внешнего аутентификатора для существующих пользователей, которые определены в users.xml или в локальных путях контроля доступа.
  • Использование LDAP как внешнего каталога пользователей и возможность аутентификации локально неопределённых пользователей, если они существуют на сервере LDAP.

Для обоих этих подходов в конфигурации ClickHouse должен быть определён сервер LDAP с внутренним именем, чтобы другие части конфигурации могли ссылаться на него.

Определение сервера LDAP

Чтобы определить сервер LDAP, необходимо добавить раздел ldap_servers в config.xml.

Пример

Обратите внимание, что вы можете определить несколько серверов LDAP внутри раздела ldap_servers с использованием различных имен.

Параметры

  • host — имя хоста или IP-адрес сервера LDAP, этот параметр обязателен и не может быть пустым.
  • port — порт сервера LDAP, по умолчанию 636, если enable_tls установлен в true, иначе 389.
  • bind_dn — Шаблон, используемый для создания DN для связывания.
    • Результирующий DN будет построен путем замены всех подстрок {user_name} шаблона на фактическое имя пользователя при каждой попытке аутентификации.
  • user_dn_detection — Раздел с параметрами поиска LDAP для обнаружения фактического DN пользователя, к которому осуществляется связывание.
    • Это в основном используется в фильтрах поиска для дальнейшего сопоставления ролей, когда сервер является Active Directory. Результирующий DN пользователя будет использоваться при замене подстрок {user_dn} там, где это разрешено. По умолчанию DN пользователя устанавливается равным DN связывания, но после выполнения поиска он будет обновлён на фактическое значение обнаруженного DN пользователя.
      • base_dn — Шаблон, используемый для создания базового DN для поиска LDAP.
        • Результирующий DN будет построен путем замены всех подстрок {user_name} и {bind_dn} шаблона на фактическое имя пользователя и DN связывания во время поиска LDAP.
      • scope — Область поиска LDAP.
        • Принимаемые значения: base, one_level, children, subtree (по умолчанию).
      • search_filter — Шаблон, используемый для создания фильтра поиска для поиска LDAP.
        • Результирующий фильтр будет построен путем замены всех подстрок {user_name}, {bind_dn} и {base_dn} шаблона на фактическое имя пользователя, DN связывания и базовый DN во время поиска LDAP.
        • Обратите внимание, что специальные символы должны быть правильно экранированы в XML.
  • verification_cooldown — Период времени в секундах после успешной попытки связывания, в течение которого пользователь будет считаться успешно аутентифицированным для всех последующих запросов без обращения к серверу LDAP.
    • Укажите 0 (по умолчанию), чтобы отключить кэширование и заставить обращаться к серверу LDAP для каждого запроса аутентификации.
  • enable_tls — Флаг для включения использования защищённого соединения с сервером LDAP.
    • Укажите no для протокола открытого текста ldap:// (не рекомендуется).
    • Укажите yes для протокола LDAP через SSL/TLS ldaps:// (рекомендуется, по умолчанию).
    • Укажите starttls для устаревшего протокола StartTLS (протокол открытого текста ldap://, обновлённый до TLS).
  • tls_minimum_protocol_version — Минимальная версия протокола SSL/TLS.
    • Принимаемые значения: ssl2, ssl3, tls1.0, tls1.1, tls1.2 (по умолчанию).
  • tls_require_cert — Поведение проверки сертификата SSL/TLS.
    • Принимаемые значения: never, allow, try, demand (по умолчанию).
  • tls_cert_file — Путь к файлу сертификата.
  • tls_key_file — Путь к файлу ключа сертификата.
  • tls_ca_cert_file — Путь к файлу сертификата CA.
  • tls_ca_cert_dir — Путь к директории, содержащей сертификаты CA.
  • tls_cipher_suite — Допустимый набор шифров (в нотации OpenSSL).

Внешний аутентификатор LDAP

Удалённый сервер LDAP может использоваться как метод проверки паролей для локально определённых пользователей (пользователей, определённых в users.xml или в локальных путях контроля доступа). Для достижения этого укажите ранее определённое имя сервера LDAP вместо разделов password или аналогичных в определении пользователя.

При каждой попытке входа ClickHouse пытается "связаться" с указанным DN, определённым параметром bind_dn в определении сервера LDAP, используя предоставленные учётные данные, и если это удачно, пользователь считается аутентифицированным. Это часто называется методом "простого связывания".

Пример

Обратите внимание, что пользователь my_user ссылается на my_ldap_server. Этот сервер LDAP должен быть настроен в основном файле config.xml, как описано ранее.

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

Запрос:

Внешний каталог пользователей LDAP

В дополнение к локально определённым пользователям удалённый сервер LDAP может использоваться как источник определения пользователей. Для этого укажите ранее определённое имя сервера LDAP (см. Определение сервера LDAP) в разделе ldap внутри раздела users_directories файла config.xml.

При каждой попытке логина ClickHouse пытается найти определение пользователя локально и аутентифицировать его как обычно. Если пользователь не определён, ClickHouse будет предполагать, что определение существует во внешнем каталоге LDAP и попытается "связаться" с указанным DN на сервере LDAP, используя предоставленные учётные данные. Если это удачно, пользователь будет считаться существующим и аутентифицированным. Пользователю будут назначены роли из списка, указанного в разделе roles. Кроме того, может быть выполнен поиск LDAP и результаты могут быть преобразованы и трактованы как имена ролей, которые затем могут быть назначены пользователю, если также настроен раздел role_mapping. Всё это подразумевает, что включен SQL-управляемый Контроль доступа и управление учётными записями, и роли создаются с помощью оператора CREATE ROLE.

Пример

Добавляется в config.xml.

Обратите внимание, что my_ldap_server, упомянутый в разделе ldap внутри раздела user_directories, должен быть ранее определённым сервером LDAP, который настроен в config.xml (см. Определение сервера LDAP).

Параметры

  • server — Одно из названий серверов LDAP, определённых в вышеуказанном разделе конфигурации ldap_servers. Этот параметр обязателен и не может быть пустым.
  • roles — Раздел со списком локально определённых ролей, которые будут назначены каждому пользователю, полученному с сервера LDAP.
    • Если здесь не указаны роли или они не назначены во время сопоставления ролей (ниже), пользователь не сможет выполнять никаких действий после аутентификации.
  • role_mapping — Раздел с параметрами поиска LDAP и правилами сопоставления.
    • Когда пользователь аутентифицируется, оставаясь связанный с LDAP, выполняется поиск LDAP с использованием search_filter и имени вошедшего пользователя. Для каждого найденного во время этого поиска элемента извлекается значение указанного атрибута. Для каждого значения атрибута, имеющего указанный префикс, префикс удаляется, и оставшаяся часть значения становится именем локальной роли, определённой в ClickHouse, которая должна быть заранее создана с помощью оператора CREATE ROLE.
    • В одном и том же разделе ldap может быть определено несколько секций role_mapping. Все они будут применены.
      • base_dn — Шаблон, используемый для создания базового DN для поиска LDAP.
        • Результирующий DN будет построен путем замены всех подстрок {user_name}, {bind_dn} и {user_dn} шаблона на фактическое имя пользователя, DN связывания и DN пользователя во время каждого поиска LDAP.
      • scope — Область поиска LDAP.
        • Принимаемые значения: base, one_level, children, subtree (по умолчанию).
      • search_filter — Шаблон, используемый для создания фильтра поиска для поиска LDAP.
        • Результирующий фильтр будет построен путем замены всех подстрок {user_name}, {bind_dn}, {user_dn} и {base_dn} шаблона на фактическое имя пользователя, DN связывания, DN пользователя и базовый DN во время каждого поиска LDAP.
        • Обратите внимание, что специальные символы должны быть правильно экранированы в XML.
      • attribute — Имя атрибута, значения которого будут возвращены поиском LDAP. cn, по умолчанию.
      • prefix — Префикс, который ожидается в начале каждой строки в исходном списке строк, возвращённых поиском LDAP. Префикс будет удалён из исходных строк, и результирующие строки будут рассматриваться как имена локальных ролей. По умолчанию пустой.