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.

Пример

<clickhouse>
    <!- ... -->
    <ldap_servers>
        <!- Типичный сервер LDAP. -->
        <my_ldap_server>
            <host>localhost</host>
            <port>636</port>
            <bind_dn>uid={user_name},ou=users,dc=example,dc=com</bind_dn>
            <verification_cooldown>300</verification_cooldown>
            <enable_tls>yes</enable_tls>
            <tls_minimum_protocol_version>tls1.2</tls_minimum_protocol_version>
            <tls_require_cert>demand</tls_require_cert>
            <tls_cert_file>/path/to/tls_cert_file</tls_cert_file>
            <tls_key_file>/path/to/tls_key_file</tls_key_file>
            <tls_ca_cert_file>/path/to/tls_ca_cert_file</tls_ca_cert_file>
            <tls_ca_cert_dir>/path/to/tls_ca_cert_dir</tls_ca_cert_dir>
            <tls_cipher_suite>ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:AES256-GCM-SHA384</tls_cipher_suite>
        </my_ldap_server>

        <!- Типичный Active Directory с настроенной детекцией DN пользователей для дальнейшего сопоставления ролей. -->
        <my_ad_server>
            <host>localhost</host>
            <port>389</port>
            <bind_dn>EXAMPLE\{user_name}</bind_dn>
            <user_dn_detection>
                <base_dn>CN=Users,DC=example,DC=com</base_dn>
                <search_filter>(&amp;(objectClass=user)(sAMAccountName={user_name}))</search_filter>
            </user_dn_detection>
            <enable_tls>no</enable_tls>
        </my_ad_server>
    </ldap_servers>
</clickhouse>

Обратите внимание, что вы можете определить несколько серверов 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, используя предоставленные учётные данные, и если это удачно, пользователь считается аутентифицированным. Это часто называется методом "простого связывания".

Пример

<clickhouse>
    <!- ... -->
    <users>
        <!- ... -->
        <my_user>
            <!- ... -->
            <ldap>
                <server>my_ldap_server</server>
            </ldap>
        </my_user>
    </users>
</clickhouse>

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

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

Запрос:

CREATE USER my_user IDENTIFIED WITH ldap SERVER 'my_ldap_server';

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

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

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

Пример

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

<clickhouse>
    <!- ... -->
    <user_directories>
        <!- Типичный сервер LDAP. -->
        <ldap>
            <server>my_ldap_server</server>
            <roles>
                <my_local_role1 />
                <my_local_role2 />
            </roles>
            <role_mapping>
                <base_dn>ou=groups,dc=example,dc=com</base_dn>
                <scope>subtree</scope>
                <search_filter>(&amp;(objectClass=groupOfNames)(member={bind_dn}))</search_filter>
                <attribute>cn</attribute>
                <prefix>clickhouse_</prefix>
            </role_mapping>
        </ldap>

        <!- Типичный Active Directory с сопоставлением ролей, которое зависит от обнаруженного DN пользователя. -->
        <ldap>
            <server>my_ad_server</server>
            <role_mapping>
                <base_dn>CN=Users,DC=example,DC=com</base_dn>
                <attribute>CN</attribute>
                <scope>subtree</scope>
                <search_filter>(&amp;(objectClass=group)(member={user_dn}))</search_filter>
                <prefix>clickhouse_</prefix>
            </role_mapping>
        </ldap>
    </user_directories>
</clickhouse>

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

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

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

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

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

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

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