LDAP
Эта страница не применима к 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}
шаблона на фактическое имя пользователя при каждой попытке аутентификации.
- Результирующий DN будет построен путем замены всех подстрок
user_dn_detection
— Раздел с параметрами поиска LDAP для обнаружения фактического DN пользователя, к которому осуществляется связывание.- Это в основном используется в фильтрах поиска для дальнейшего сопоставления ролей, когда сервер является Active Directory. Результирующий DN пользователя будет использоваться при замене подстрок
{user_dn}
там, где это разрешено. По умолчанию DN пользователя устанавливается равным DN связывания, но после выполнения поиска он будет обновлён на фактическое значение обнаруженного DN пользователя.base_dn
— Шаблон, используемый для создания базового DN для поиска LDAP.- Результирующий DN будет построен путем замены всех подстрок
{user_name}
и{bind_dn}
шаблона на фактическое имя пользователя и DN связывания во время поиска LDAP.
- Результирующий DN будет построен путем замены всех подстрок
scope
— Область поиска LDAP.- Принимаемые значения:
base
,one_level
,children
,subtree
(по умолчанию).
- Принимаемые значения:
search_filter
— Шаблон, используемый для создания фильтра поиска для поиска LDAP.- Результирующий фильтр будет построен путем замены всех подстрок
{user_name}
,{bind_dn}
и{base_dn}
шаблона на фактическое имя пользователя, DN связывания и базовый DN во время поиска LDAP. - Обратите внимание, что специальные символы должны быть правильно экранированы в XML.
- Результирующий фильтр будет построен путем замены всех подстрок
- Это в основном используется в фильтрах поиска для дальнейшего сопоставления ролей, когда сервер является Active Directory. Результирующий DN пользователя будет использоваться при замене подстрок
verification_cooldown
— Период времени в секундах после успешной попытки связывания, в течение которого пользователь будет считаться успешно аутентифицированным для всех последующих запросов без обращения к серверу LDAP.- Укажите
0
(по умолчанию), чтобы отключить кэширование и заставить обращаться к серверу LDAP для каждого запроса аутентификации.
- Укажите
enable_tls
— Флаг для включения использования защищённого соединения с сервером LDAP.- Укажите
no
для протокола открытого текстаldap://
(не рекомендуется). - Укажите
yes
для протокола LDAP через SSL/TLSldaps://
(рекомендуется, по умолчанию). - Укажите
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.
- Результирующий DN будет построен путем замены всех подстрок
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. Префикс будет удалён из исходных строк, и результирующие строки будут рассматриваться как имена локальных ролей. По умолчанию пустой.
- Когда пользователь аутентифицируется, оставаясь связанный с LDAP, выполняется поиск LDAP с использованием