mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-11-08 00:24:41 +00:00
149 lines
14 KiB
Markdown
149 lines
14 KiB
Markdown
# LDAP {#external-authenticators-ldap}
|
||
|
||
Для аутентификации пользователей ClickHouse можно использовать сервер LDAP. Существует два подхода:
|
||
|
||
- Использовать LDAP как внешний аутентификатор для существующих пользователей, которые определены в `users.xml` или в локальных путях управления контролем.
|
||
- Использовать LDAP как внешний пользовательский каталог и разрешить аутентификацию локально неопределенных пользователей, если они есть на LDAP сервере.
|
||
|
||
Для обоих подходов необходимо определить в конфиге ClickHouse LDAP сервер с внутренним именем, чтобы другие части конфига могли ссылаться на него.
|
||
|
||
## Определение LDAP сервера {#ldap-server-definition}
|
||
|
||
Чтобы определить LDAP сервер, необходимо добавить секцию `ldap_servers` в `config.xml`.
|
||
|
||
**Пример**
|
||
|
||
```xml
|
||
<yandex>
|
||
<!- ... -->
|
||
<ldap_servers>
|
||
<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>
|
||
</ldap_servers>
|
||
</yandex>
|
||
```
|
||
|
||
Обратите внимание, что можно определить несколько LDAP серверов внутри секции `ldap_servers`, используя различные имена.
|
||
|
||
**Параметры**
|
||
|
||
- `host` — имя хоста сервера LDAP или его IP. Этот параметр обязательный и не может быть оставлен пустым.
|
||
- `port` — порт сервера LDAP. По-умолчанию: `636` при значении `true` настройки `enable_tls`, иначе `389`.
|
||
- `bind_dn` — шаблон для создания DN для привязки.
|
||
- Конечный DN будет создан заменой всех подстрок `{user_name}` шаблона на фактическое имя пользователя при каждой попытке аутентификации.
|
||
- `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` — путь к файлу ЦС сертификата.
|
||
- `tls_ca_cert_dir` — путь к каталогу, содержащая сертификаты ЦС.
|
||
- `tls_cipher_suite` — разрешенный набор шифров (в нотации OpenSSL).
|
||
|
||
## Внешний аутентификатор LDAP {#ldap-external-authenticator}
|
||
|
||
Удаленный сервер LDAP можно использовать как метод верификации паролей локально определенных пользователей (пользователей, которые определены в `users.xml` или в локальных путях управления контролем). Для этого укажите имя определенного до этого сервера LDAP вместо `password` или другой похожей секции в определении пользователя.
|
||
|
||
При каждой попытке авторизации, ClickHouse пытается "привязаться" к DN, указанному в [определении LDAP сервера](#ldap-server-definition) параметром `bind_dn`, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается аутентифицированным. Обычно это называют методом "простой привязки".
|
||
|
||
**Пример**
|
||
|
||
```xml
|
||
<yandex>
|
||
<!- ... -->
|
||
<users>
|
||
<!- ... -->
|
||
<my_user>
|
||
<!- ... -->
|
||
<ldap>
|
||
<server>my_ldap_server</server>
|
||
</ldap>
|
||
</my_user>
|
||
</users>
|
||
</yandex>
|
||
```
|
||
|
||
Обратите внимание, что пользователь `my_user` ссылается на `my_ldap_server`. Этот LDAP сервер должен быть настроен в основном файле `config.xml`, как это было описано ранее.
|
||
|
||
При включенном SQL-ориентированным [Управлении доступом](../access-rights.md) пользователи, аутентифицированные LDAP серверами, могут также быть созданы выражением [CREATE USER](../../sql-reference/statements/create/user.md#create-user-statement).
|
||
|
||
Запрос:
|
||
|
||
```sql
|
||
CREATE USER my_user IDENTIFIED WITH ldap SERVER 'my_ldap_server';
|
||
```
|
||
|
||
## Внешний пользовательский каталог LDAP {#ldap-external-user-directory}
|
||
|
||
В добавок к локально определенным пользователям, удаленный LDAP сервер может быть использован как источник определения пользователей. Для этого укажите имя определенного до этого сервера LDAP (см. [Определение LDAP сервера](#ldap-server-definition)) в секции `ldap` внутри секции `users_directories` файла `config.xml`.
|
||
|
||
При каждой попытке авторизации ClicHouse пытается локально найти определение пользователя и авторизовать его как обычно. Если определение не будет найдено, ClickHouse предполагает, что оно находится во внешнем LDAP каталоге, и пытается "привязаться" к DN, указанному на LDAP сервере, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается существующим и аутентифицированным. Пользователю будут присвоены роли из списка, указанного в секции `roles`. Кроме того, может быть выполнен LDAP поиск, а его результаты могут быть преобразованы в имена ролей и присвоены пользователям, если была настроена секция `role_mapping`. Все это работает при условии, что SQL-ориентированное [Управлением доступом](../access-rights.md#access-control) включено, а роли созданы выражением [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement).
|
||
|
||
**Пример**
|
||
|
||
В `config.xml`.
|
||
|
||
```xml
|
||
<yandex>
|
||
<!- ... -->
|
||
<user_directories>
|
||
<!- ... -->
|
||
<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>(&(objectClass=groupOfNames)(member={bind_dn}))</search_filter>
|
||
<attribute>cn</attribute>
|
||
<prefix>clickhouse_</prefix>
|
||
</role_mapping>
|
||
</ldap>
|
||
</user_directories>
|
||
</yandex>
|
||
```
|
||
|
||
Обратите внимание, что `my_ldap_server`, указанный в секции `ldap` внутри секции `user_directories`, должен быть настроен в файле `config.xml`, как это было описано ранее. (см. [Определение LDAP сервера](#ldap-server-definition)).
|
||
|
||
**Параметры**
|
||
|
||
- `server` — одно из имен сервера LDAP, определенного в секции конфига `ldap_servers` выше. Этот параметр обязательный и не может быть оставлен пустым.
|
||
- `roles` — секция со списком локально определенных ролей, которые будут присвоены каждому пользователю, полученному от сервера LDAP.
|
||
- Если роли не указаны здесь или в секции `role_mapping` (ниже), пользователь не сможет выполнять никаких операций после аутентификации.
|
||
- `role_mapping` — секция c параметрами LDAP поиска и правилами отображения.
|
||
- При аутентификации пользователя, пока еще связанного с LDAP, производится LDAP поиск с помощью `search_filter` и имени этого пользователя. Для каждой записи, найденной в ходе поиска, выделяется значение указанного атрибута. У каждого атрибута, имеющего указанный префикс, удаляется этот префикс, а остальная часть значения становится именем локальной роли, определенной в ClickHouse, причем предполагается, что эта роль была создана выражением [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement) до этого.
|
||
- Внутри одной секции `ldap` может быть несколько секций `role_mapping`. Все они будут применены.
|
||
- `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.
|
||
- `attribute` — имя атрибута, значение которого будет возвращаться LDAP поиском.
|
||
- `prefix` — префикс, который, как предполагается, будет находиться перед началом каждой строки в исходном списке строк, возвращаемых LDAP поиском. Префикс будет удален из исходных строк, а сами они будут рассматриваться как имена локальных ролей. По-умолчанию пусто.
|
||
|
||
[Оригинальная статья](https://clickhouse.tech/docs/en/operations/external-authenticators/ldap.md) <!--hide-->
|