LDAP

Not supported in ClickHouse Cloud

примечание

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

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

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

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

Определение сервера 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. Префикс будет удален из исходных строк, и полученные строки будут трактоваться как имена локальных ролей. По умолчанию пусто.