mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-20 08:40:50 +00:00
Update ldap.md
This commit is contained in:
parent
4878ad5b6c
commit
c068538a8e
@ -55,7 +55,7 @@
|
|||||||
- Возможные значения: `never`, `allow`, `try`, `demand` (по-умолчанию).
|
- Возможные значения: `never`, `allow`, `try`, `demand` (по-умолчанию).
|
||||||
- `tls_cert_file` — путь к файлу сертификата.
|
- `tls_cert_file` — путь к файлу сертификата.
|
||||||
- `tls_key_file` — путь к файлу ключа сертификата.
|
- `tls_key_file` — путь к файлу ключа сертификата.
|
||||||
- `tls_ca_cert_file` — путь к файлу ЦС сертификата.
|
- `tls_ca_cert_file` — путь к файлу ЦС (certification authority) сертификата.
|
||||||
- `tls_ca_cert_dir` — путь к каталогу, содержащему сертификаты ЦС.
|
- `tls_ca_cert_dir` — путь к каталогу, содержащему сертификаты ЦС.
|
||||||
- `tls_cipher_suite` — разрешенный набор шифров (в нотации OpenSSL).
|
- `tls_cipher_suite` — разрешенный набор шифров (в нотации OpenSSL).
|
||||||
|
|
||||||
@ -96,7 +96,7 @@ CREATE USER my_user IDENTIFIED WITH ldap SERVER 'my_ldap_server';
|
|||||||
|
|
||||||
В дополнение к локально определенным пользователям, удаленный LDAP сервер может служить источником определения пользователей. Для этого укажите имя определенного ранее сервера LDAP (см. [Определение LDAP сервера](#ldap-server-definition)) в секции `ldap` внутри секции `users_directories` файла `config.xml`.
|
В дополнение к локально определенным пользователям, удаленный LDAP сервер может служить источником определения пользователей. Для этого укажите имя определенного ранее сервера LDAP (см. [Определение LDAP сервера](#ldap-server-definition)) в секции `ldap` внутри секции `users_directories` файла `config.xml`.
|
||||||
|
|
||||||
При каждой попытке авторизации ClickHouse пытается локально найти определение пользователя и аутентифицировать его как обычно. Если пользователь не находится локально, ClickHouse предполагает, что он определяется во внешнем LDAP каталоге и пытается "привязаться" к DN, указанному на LDAP сервере, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается существующим и аутентифицированным. Пользователю присваиваются роли из списка, указанного в секции `roles`. Кроме того, если настроена секция `role_mapping`, то выполняется LDAP поиск, а его результаты преобразуются в имена ролей и присваиваются пользователям. Все это работает при условии, что SQL-ориентированное [управлением доступом](../access-rights.md#access-control) включено, а роли созданы запросом [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement).
|
При каждой попытке аутентификации ClickHouse пытается локально найти определение пользователя и аутентифицировать его как обычно. Если пользователь не находится локально, ClickHouse предполагает, что он определяется во внешнем LDAP каталоге и пытается "привязаться" к DN, указанному на LDAP сервере, используя предоставленные реквизиты для входа. Если попытка оказалась успешной, пользователь считается существующим и аутентифицированным. Пользователю присваиваются роли из списка, указанного в секции `roles`. Кроме того, если настроена секция `role_mapping`, то выполняется LDAP поиск, а его результаты преобразуются в имена ролей и присваиваются пользователям. Все это работает при условии, что SQL-ориентированное [управлением доступом](../access-rights.md#access-control) включено, а роли созданы запросом [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement).
|
||||||
|
|
||||||
**Пример**
|
**Пример**
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user