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