mirror of
https://github.com/ClickHouse/ClickHouse.git
synced 2024-09-20 08:40:50 +00:00
Semi-final kerberos + ldap (ru)
This commit is contained in:
zvonand
parent
fbb6a931cc
commit
652899e631
@ -11,4 +11,4 @@ ClickHouse supports authenticating and managing users using external services.
|
||||
The following external authenticators and directories are supported:
|
||||
|
||||
- [LDAP](./ldap.md#external-authenticators-ldap) [Authenticator](./ldap.md#ldap-external-authenticator) and [Directory](./ldap.md#ldap-external-user-directory)
|
||||
- [Kerberos](./kerberos.md#external-authenticators-kerberos)
|
||||
- Kerberos [Authenticator](./kerberos.md#external-authenticators-kerberos)
|
||||
|
||||
@ -2,47 +2,14 @@
|
||||
|
||||
Existing and properly configured ClickHouse users can be authenticated via Kerberos authentication protocol.
|
||||
|
||||
Currently, Kerberos can only be used as an external authenticator for existing users, which are defined in `users.xml` or in local access control paths. Those users may only use HTTP requests, and must be able to authenticate using GSS-SPNEGO mechanism.
|
||||
Currently, Kerberos can only be used as an external authenticator for existing users, which are defined in `users.xml` or in local access control paths. Those users may only use HTTP requests and must be able to authenticate using GSS-SPNEGO mechanism.
|
||||
|
||||
For this approach, Kerberos must be configured in the system and must be enabled in ClickHouse config.
|
||||
|
||||
|
||||
## Enabling Kerberos in ClickHouse {#enabling-kerberos-in-clickhouse}
|
||||
|
||||
To enable Kerberos, presence of a single `kerberos` section in `config.xml` is enough. However, depending on the directions that involve Kerberos, configurations in other places may be necessary.
|
||||
|
||||
Example (goes into `config.xml`):
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
<!- ... -->
|
||||
<kerberos />
|
||||
</yandex>
|
||||
```
|
||||
|
||||
...or:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
<!- ... -->
|
||||
<kerberos>
|
||||
<principal>HTTP/clickhouse.example.com@EXAMPLE.COM</principal>
|
||||
</kerberos>
|
||||
</yandex>
|
||||
```
|
||||
|
||||
...or:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
<!- ... -->
|
||||
<kerberos>
|
||||
<realm>EXAMPLE.COM</realm>
|
||||
</kerberos>
|
||||
</yandex>
|
||||
```
|
||||
|
||||
Note that you can define only one `kerberos` section. Presence of multiple `kerberos` sections will force ClickHouse to disable Kerberos authentication.
|
||||
To enable Kerberos, one should include `kerberos` section in `config.xml`. This section may contain additional parameters.
|
||||
|
||||
#### Parameters:
|
||||
|
||||
@ -53,14 +20,49 @@ Note that you can define only one `kerberos` section. Presence of multiple `kerb
|
||||
- `realm` - a realm, that will be used to restrict authentication to only those requests whose initiator's realm matches it.
|
||||
- This parameter is optional, if omitted, no additional filtering by realm will be applied.
|
||||
|
||||
Note that `principal` and `realm` sections cannot be specified at the same time. Presence of both `principal` and `realm` sections will force ClickHouse to disable Kerberos authentication.
|
||||
Example (goes into `config.xml`):
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
<!- ... -->
|
||||
<kerberos />
|
||||
</yandex>
|
||||
```
|
||||
|
||||
With principal specification:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
<!- ... -->
|
||||
<kerberos>
|
||||
<principal>HTTP/clickhouse.example.com@EXAMPLE.COM</principal>
|
||||
</kerberos>
|
||||
</yandex>
|
||||
```
|
||||
|
||||
With filtering by realm:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
<!- ... -->
|
||||
<kerberos>
|
||||
<realm>EXAMPLE.COM</realm>
|
||||
</kerberos>
|
||||
</yandex>
|
||||
```
|
||||
|
||||
!!! warning "Note"
|
||||
You can define only one `kerberos` section. The presence of multiple `kerberos` sections will force ClickHouse to disable Kerberos authentication.
|
||||
|
||||
!!! warning "Note"
|
||||
`principal` and `realm` sections cannot be specified at the same time. The presence of both `principal` and `realm` sections will force ClickHouse to disable Kerberos authentication.
|
||||
|
||||
|
||||
## Kerberos as an external authenticator for existing users {#kerberos-as-an-external-authenticator-for-existing-users}
|
||||
|
||||
Kerberos can be used as a method for verifying the identity of locally defined users (users defined in `users.xml` or in local access control paths). Currently, **only** requests over HTTP interface can be *kerberized* (via GSS-SPNEGO mechanism).
|
||||
Kerberos can be used as a method for verifying the identity of locally defined users (users defined in `users.xml` or in local access control paths). Currently, **only** requests over the HTTP interface can be *kerberized* (via GSS-SPNEGO mechanism).
|
||||
|
||||
Kerberos principal name format usualy follows this pattern:
|
||||
Kerberos principal name format usually follows this pattern:
|
||||
|
||||
- *primary/instance@REALM*
|
||||
|
||||
@ -68,7 +70,12 @@ The */instance* part may occur zero or more times. **The *primary* part of the c
|
||||
|
||||
### Enabling Kerberos in `users.xml` {#enabling-kerberos-in-users-xml}
|
||||
|
||||
In order to enable Kerberos authenication for the user, specify `kerberos` section instead of `password` or similar sections in the user definition. Note that Kerberos authentication cannot be used alongside with any other authentication mechanism. Presence of any other sections like `password` alongside with `kerberos` will force ClickHouse to shutdown.
|
||||
In order to enable Kerberos authentication for the user, specify `kerberos` section instead of `password` or similar sections in the user definition.
|
||||
|
||||
Parameters:
|
||||
|
||||
- `realm` - a realm that will be used to restrict authentication to only those requests whose initiator's realm matches it.
|
||||
- This parameter is optional, if omitted, no additional filtering by realm will be applied.
|
||||
|
||||
Example (goes into `users.xml`):
|
||||
|
||||
@ -87,16 +94,15 @@ Example (goes into `users.xml`):
|
||||
</yandex>
|
||||
```
|
||||
|
||||
Note, that now, once user `my_user` uses `kerberos`, Kerberos must be enabled in the main `config.xml` file as described previously.
|
||||
!!! warning "Warning"
|
||||
Note that Kerberos authentication cannot be used alongside with any other authentication mechanism. The presence of any other sections like `password` alongside `kerberos` will force ClickHouse to shutdown.
|
||||
|
||||
Parameters:
|
||||
|
||||
- `realm` - a realm that will be used to restrict authentication to only those requests whose initiator's realm matches it.
|
||||
- This parameter is optional, if omitted, no additional filtering by realm will be applied.
|
||||
!!! info "Reminder"
|
||||
Note, that now, once user `my_user` uses `kerberos`, Kerberos must be enabled in the main `config.xml` file as described previously.
|
||||
|
||||
### Enabling Kerberos using SQL {#enabling-kerberos-using-sql}
|
||||
|
||||
When SQL-driven Access Control and Account Management is enabled in ClickHouse, users identified by Kerberos can also be created using SQL statements.
|
||||
When [SQL-driven Access Control and Account Management](../access-rights.md#access-control) is enabled in ClickHouse, users identified by Kerberos can also be created using SQL statements.
|
||||
|
||||
```sql
|
||||
CREATE USER my_user IDENTIFIED WITH kerberos REALM 'EXAMPLE.COM'
|
||||
|
||||
@ -0,0 +1,14 @@
|
||||
---
|
||||
toc_folder_title: External User Authenticators and Directories
|
||||
toc_priority: 48
|
||||
toc_title: Introduction
|
||||
---
|
||||
|
||||
# Внешние аутентификаторы и каталоги {#external-authenticators}
|
||||
|
||||
ClickHouse поддерживает аутентификацию и управление учётными записями с помощью внешних сервисов.
|
||||
|
||||
Поддерживаемые внешние аутентификаторы и внешние каталоги:
|
||||
|
||||
- [LDAP](./ldap.md#external-authenticators-ldap) [аутентификатор](./ldap.md#ldap-external-authenticator) и [External Directory](./ldap.md#ldap-external-user-directory)
|
||||
- Kerberos [аутентификатор](./kerberos.md#external-authenticators-kerberos)
|
||||
@ -1,15 +1,25 @@
|
||||
# Kerberos {#external-authenticators-kerberos}
|
||||
|
||||
ClickHouse поддерживает аутентификацию существующих (и правильно сконфигурированных) пользователей с использованием Kerberos.
|
||||
ClickHouse предоставляет возможность аутентификации существующих (и правильно сконфигурированных) пользователей с использованием Kerberos.
|
||||
|
||||
В настоящее время возможна Kerberos-аутентификация уже существующих пользователей, определённых в конфигурационном файле `users.xml` или с помощью выражений SQL. Пользователи, имеющие конфигурацию для аутентификации через Kerberos, могут работать только через HTTP-интерфейс, причём сами клиенты должны иметь возможность аутентификации с использованием механизма GSS-SPNEGO.
|
||||
В настоящее время возможно использование Kerberos только как внешнего аутентификатора, то есть для аутентификации уже существующих пользователей с помощью Kerberos. Пользователи, настроенные для Kerberos-аутентификации, могут работать с ClickHouse только через HTTP-интерфейс, причём сами клиенты должны иметь возможность аутентификации с использованием механизма GSS-SPNEGO.
|
||||
|
||||
Для Kerberos-аутентификации необходимо предварительно корректно настроить Kerberos на стороне клиента, на сервере и в конфигурационных файлах самого ClickHouse. Ниже описана лишь конфигурация ClickHouse.
|
||||
|
||||
!!! info "!!!"
|
||||
Для Kerberos-аутентификации необходимо предварительно корректно настроить Kerberos на стороне клиента, на сервере и в конфигурационных файлах самого ClickHouse. Ниже описана лишь конфигурация ClickHouse.
|
||||
|
||||
|
||||
## Настройка Kerberos в ClickHouse {#enabling-kerberos-in-clickhouse}
|
||||
|
||||
Для того, чтобы включить Kerberos-аутентификацию в ClickHouse, необходимо добавить одну-единственную секцию `kerberos` в `config.xml`. Заметим, что это не единственная необходимая для работы Kerberos настройка.
|
||||
Для того, чтобы задействовать Kerberos-аутентификацию в ClickHouse, в первую очередь необходимо добавить одну-единственную секцию `kerberos` в `config.xml`.
|
||||
|
||||
В секции могут быть указаны дополнительные параметры:
|
||||
|
||||
- `principal` — задаёт имя принципала (canonical service principal name, SPN), используемое при авторизации ClickHouse на Kerberos-сервере.
|
||||
- Это опциональный параметр, при его отсутствии будет использовано стандартное имя.
|
||||
|
||||
- `realm` — обеспечивает фильтрацию по реалм (realm). Пользователям, чей реалм не совпадает с указанным, будет отказано в аутентификации.
|
||||
- Это опциональный параметр, при его отсутствии фильтр по реалм применяться не будет.
|
||||
|
||||
Примеры, как должен выглядеть файл `config.xml`:
|
||||
|
||||
@ -20,7 +30,7 @@ ClickHouse поддерживает аутентификацию существ
|
||||
</yandex>
|
||||
```
|
||||
|
||||
...или:
|
||||
Или, с указанием принципала:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
@ -31,7 +41,7 @@ ClickHouse поддерживает аутентификацию существ
|
||||
</yandex>
|
||||
```
|
||||
|
||||
...или:
|
||||
Или, с фильтрацией по реалм:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
@ -42,17 +52,12 @@ ClickHouse поддерживает аутентификацию существ
|
||||
</yandex>
|
||||
```
|
||||
|
||||
**Важно**: в конфигурационном файле может быть не более одной секции `kerberos`. В противном случае, аутентификация с помощью Kerberos будет недоступна для всех пользователей.
|
||||
!!! Warning "Важно"
|
||||
В конфигурационном файле не могут быть указаны одновременно оба параметра. В противном случае, аутентификация с помощью Kerberos будет недоступна для всех пользователей.
|
||||
|
||||
#### Параметры:
|
||||
!!! Warning "Важно"
|
||||
В конфигурационном файле может быть не более одной секции `kerberos`. В противном случае, аутентификация с помощью Kerberos будет отключена для всех пользователей.
|
||||
|
||||
- `principal` — задаёт имя принципала (canonical service principal name, SPN), используемое при авторизации ClickHouse на Kerberos-сервере.
|
||||
- Это опциональный параметр, при его отсутствии будет использовано стандартное имя.
|
||||
|
||||
- `realm` &mdash обеспечивает фильтрацию по реалм (realm). Пользователям, чей реалм не совпадает с указанным, будет отказано в аутентификации.
|
||||
- Это опциональный параметр, при его отсутствии фильтр по реалм применяться не будет.
|
||||
|
||||
*Важно*: в конфигурационном файле не могут быть указаны одновременно оба параметра. В противном случае, аутентификация с помощью Kerberos будет недоступна для всех пользователей.
|
||||
|
||||
## Аутентификация пользователей с помощью Kerberos {#kerberos-as-an-external-authenticator-for-existing-users}
|
||||
|
||||
@ -62,13 +67,16 @@ ClickHouse поддерживает аутентификацию существ
|
||||
|
||||
- *primary/instance@REALM*
|
||||
|
||||
Для успешной аутентификации необходимо, чтобы *primary* совпадало с именем пользователя ClickHouse, настроенного для использования Kerberos.
|
||||
Для успешной аутентификации необходимо, чтобы *primary* совпало с именем пользователя ClickHouse, настроенного для использования Kerberos.
|
||||
|
||||
### Настройка Kerberos в `users.xml` {#enabling-kerberos-in-users-xml}
|
||||
|
||||
Для того, чтобы пользователь имел возможность аутентификации с помощью Kerberos, достаточно включить секцию `kerberos` в описание пользователя в `users.xml` (например, вместо секции `password` или аналогичной ей).
|
||||
Для того, чтобы пользователь имел возможность производить аутентификацию с помощью Kerberos, достаточно включить секцию `kerberos` в описание пользователя в `users.xml` (например, вместо секции `password` или аналогичной ей).
|
||||
|
||||
**Важно**: если пользователь настроен для Kerberos-аутентификации, другие виды уатентификации будут для него недоступны. Если наряду с `kerberos` в определении пользователя будет указан какой-либо другой способ аутентификации, ClickHouse завершит работу.
|
||||
В секции могут быть указаны дополнительные параметры:
|
||||
|
||||
- `realm` — обеспечивает фильтрацию по реалм (realm): аутентификация будет возможна только при совпадении реалм клиента с указанным.
|
||||
- Этот параметр является опциональным, при его отсутствии фильтрация применяться не будет.
|
||||
|
||||
Пример, как выглядит конфигурация Kerberos в `users.xml`:
|
||||
|
||||
@ -87,24 +95,23 @@ ClickHouse поддерживает аутентификацию существ
|
||||
</yandex>
|
||||
```
|
||||
|
||||
Note, that now, once user `my_user` uses `kerberos`, Kerberos must be enabled in the main `config.xml` file as described previously.
|
||||
Ещё раз отметим, что кроме `users.xml`, необходимо также включить Kerberos в `config.xml`.
|
||||
|
||||
Параметры:
|
||||
!!! Warning "Важно"
|
||||
Если пользователь настроен для Kerberos-аутентификации, другие виды уатентификации будут для него недоступны. Если наряду с `kerberos` в определении пользователя будет указан какой-либо другой способ аутентификации, ClickHouse завершит работу.
|
||||
|
||||
- `realm` — обеспечивает фильтрацию по реалм (realm): аутентификация будет возможна только при совпадении реалм клиента с указанным.
|
||||
- Этот параметр является опциональным, при его отсутствии фильтрация применяться не будет.
|
||||
!!! info ""
|
||||
Ещё раз отметим, что кроме `users.xml`, необходимо также включить Kerberos в `config.xml`.
|
||||
|
||||
### Настройка Kerberos через SQL {#enabling-kerberos-using-sql}
|
||||
|
||||
Пользователей, использующих Kerberos-аутентификацию, можно создавать не только в конфигурационном файле `users.xml`.
|
||||
Пользователей, использующих Kerberos-аутентификацию, можно создать не только с помощью изменения конфигурационных файлов.
|
||||
Если SQL-ориентированное управление доступом включено в ClickHouse, можно также создать пользователя, работающего через Kerberos, с помощью SQL.
|
||||
|
||||
```sql
|
||||
CREATE USER my_user IDENTIFIED WITH kerberos REALM 'EXAMPLE.COM'
|
||||
```
|
||||
|
||||
...или, без фильтрации по реалм:
|
||||
Или, без фильтрации по реалм:
|
||||
|
||||
```sql
|
||||
CREATE USER my_user IDENTIFIED WITH kerberos
|
||||
|
||||
@ -61,10 +61,9 @@
|
||||
|
||||
Удалённый LDAP-сервер можно использовать для проверки паролей пользователей, определённых локально, в ClickHouse (в конфигурационных файлах или через SQL-воркфлоу). Для этого при определении пользователя укажите имя предварительно описанного LDAP-сервера вместо секции `password` или ей аналогичной.
|
||||
|
||||
При каждой попытке логина ClickHouse будет пытаться подключиться как DN, указанному в параметре `bind_dn` в [Определении сервера LDAP](#ldap-server-definition)
|
||||
At each login attempt, ClickHouse will try to "bind" to the specified DN defined by the `bind_dn` parameter in the [LDAP server definition](#ldap-server-definition) using the provided credentials, and if successful, the user will be considered authenticated. This is often called a "simple bind" method.
|
||||
При каждой попытке логина ClickHouse будет пытаться авторизоваться как DN, указанный в параметре `bind_dn` в [Определении сервера LDAP](#ldap-server-definition) с использованием указанных учётных данных. Если попытка увенчается успехом, то пользователь будет аутентифицирован. Инода это также называют простым подсоединением (simple bind).
|
||||
|
||||
For example,
|
||||
Пример конфигурации:
|
||||
|
||||
```xml
|
||||
<yandex>
|
||||
@ -81,22 +80,23 @@ For example,
|
||||
</yandex>
|
||||
```
|
||||
|
||||
Note, that user `my_user` refers to `my_ldap_server`. This LDAP server must be configured in the main `config.xml` file as described previously.
|
||||
|
||||
When SQL-driven [Access Control and Account Management](../access-rights.md#access-control) is enabled in ClickHouse, users that are authenticated by LDAP servers can also be created using the [CRATE USER](../../sql-reference/statements/create/user.md#create-user-statement) statement.
|
||||
Отметим, что пользователь `my_user` относится к `my_ldap_server`. Этот сервер нужно предварительно определить в главном конфигурационном файле `config.xml`, как описывалось ранее.
|
||||
|
||||
Если [управление доступом через SQL-воркфлоу](../access-rights.md#access-control) включено в ClickHouse, то с его помощью также можно создавать пользователей для аутентификации через LDAP, используя выражение [CREATE USER](../../sql-reference/statements/create/user.md#create-user-statement)
|
||||
|
||||
```sql
|
||||
CREATE USER my_user IDENTIFIED WITH ldap_server BY 'my_ldap_server'
|
||||
```
|
||||
|
||||
## LDAP Exernal User Directory {#ldap-external-user-directory}
|
||||
## Внешний каталог пользователей LDAP {#ldap-external-user-directory}
|
||||
|
||||
In addition to the locally defined users, a remote LDAP server can be used as a source of user definitions. In order to achieve this, specify previously defined LDAP server name (see [LDAP Server Definition](#ldap-server-definition)) in the `ldap` section inside the `users_directories` section of the `config.xml` file.
|
||||
Кроме описанного выше использования LDAP в качестве внешнего аутентификатора, ClickHouse также предоставляет возможность использования LDAP как внешний пользовательские каталог. Для этого необходимо указать предварительно описанное (см. [определение LDAP-сервера](#ldap-server-definition)) имя LDAP-сервера в секции `ldap` внутри `users_directories` в конфигурационном файле `config.xml`
|
||||
|
||||
At each login attempt, ClickHouse will try to find the user definition locally and authenticate it as usual, but if the user is not defined, ClickHouse will assume it exists in the external LDAP directory, and will try to "bind" to the specified DN at the LDAP server using the provided credentials. If successful, the user will be considered existing and authenticated. The user will be assigned roles from the list specified in the `roles` section. Additionally, LDAP "search" can be performed and results can be transformed and treated as role names and then be assigned to the user if the `role_mapping` section is also configured. All this implies that the SQL-driven [Access Control and Account Management](../access-rights.md#access-control) is enabled and roles are created using the [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement) statement.
|
||||
При каждой попытке авторизации ClickHouse сначала пытается найти пользователя среди определённых локально (посредством конфигурационных файлов или SQL-воркфлоу). Если там пользователь не найден, то полагается, что он существует во внешнем каталоге, и ClickHouse попытается выполнить "привязку" к уникальному имени (DN) на LDAP-сервере, используя предоставленные ему данные. Если попытка увенчается успехом, то пользователь будет сочтён существующим и прошедшим аутентификацию.
|
||||
|
||||
Example (goes into `config.xml`):
|
||||
Пользователю будут присвоены роли из списка, приведённого в секции `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>
|
||||
@ -121,33 +121,26 @@ Example (goes into `config.xml`):
|
||||
</yandex>
|
||||
```
|
||||
|
||||
Note that `my_ldap_server` referred in the `ldap` section inside the `user_directories` section must be a previously
|
||||
defined LDAP server that is configured in the `config.xml` (see [LDAP Server Definition](#ldap-server-definition)).
|
||||
!!! info "Note"
|
||||
LDAP-сервер `my_ldap_server`, упоминаемый в секции `ldap` внутри секции `user_directories`, должен быть предварительно определён в конфигурационном файле `config.xml` (см. [Определение LDAP-сервера](#ldap-server-definition)).
|
||||
|
||||
Parameters:
|
||||
Параметры:
|
||||
|
||||
- `server` - one of LDAP server names defined in the `ldap_servers` config section above.
|
||||
This parameter is mandatory and cannot be empty.
|
||||
- `roles` - section with a list of locally defined roles that will be assigned to each user retrieved from the LDAP server.
|
||||
- If no roles are specified here or assigned during role mapping (below), user will not be able
|
||||
to perform any actions after authentication.
|
||||
- `role_mapping` - section with LDAP search parameters and mapping rules.
|
||||
- When a user authenticates, while still bound to LDAP, an LDAP search is performed using `search_filter`
|
||||
and the name of the logged in user. For each entry found during that search, the value of the specified
|
||||
attribute is extracted. For each attribute value that has the specified prefix, the prefix is removed,
|
||||
and the rest of the value becomes the name of a local role defined in ClickHouse,
|
||||
which is expected to be created beforehand by the [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement) statement.
|
||||
- There can be multiple `role_mapping` sections defined inside the same `ldap` section. All of them will be applied.
|
||||
- `base_dn` - template used to construct the base DN for the LDAP search.
|
||||
- The resulting DN will be constructed by replacing all `{user_name}` and `{bind_dn}`
|
||||
substrings of the template with the actual user name and bind DN during each LDAP search.
|
||||
- `scope` - scope of the LDAP search.
|
||||
- Accepted values are: `base`, `one_level`, `children`, `subtree` (the default).
|
||||
- `search_filter` - template used to construct the search filter for the LDAP search.
|
||||
- The resulting filter will be constructed by replacing all `{user_name}`, `{bind_dn}`, and `{base_dn}`
|
||||
substrings of the template with the actual user name, bind DN, and base DN during each LDAP search.
|
||||
- Note, that the special characters must be escaped properly in XML.
|
||||
- `attribute` - attribute name whose values will be returned by the LDAP search.
|
||||
- `prefix` - prefix, that will be expected to be in front of each string in the original
|
||||
list of strings returned by the LDAP search. Prefix will be removed from the original
|
||||
strings and resulting strings will be treated as local role names. Empty, by default.
|
||||
- `server` - один из LDAP-серверов, определённых в секции `ldap_servers`/
|
||||
Этот параметр является обязательным к указанию и не может быть пустым.
|
||||
|
||||
- `roles` - секция, содержащая список локально определённых ролей, присваеваемых каждому пользователю, авторизованному посредством обращения к LDAP-серверу.
|
||||
- Если ни одна роль здесь не указана или не присвоена пользователю (см. ниже), пользователь не будет иметь возможности совершать никакие действия после аутентификации.
|
||||
- `role_mapping` - секция, содержащая параметры поиска LDAP и сопоставления ролей.
|
||||
- При аутентификации пользователя выполняется LDAP-поиск по `search_filter` и имени авторизованного пользователя. Для каждой найденной записи извлекается значение указанного атрибута. Специальный префикс атрибутов ударяется, и полученное значение становится именем роли, определённой в ClickHouse. Ожидается, что эта роль уже создана командой [CREATE ROLE](../../sql-reference/statements/create/role.md#create-role-statement).
|
||||
- Допускается наличие более одной секции `role_mapping` внутри секции `ldap`. Каждая из них будет принята к сведению.
|
||||
- `base_dn` - шаблон, используемый для построения основного DN для LDAP-поиска.
|
||||
- DN получается из шаблона заменой всех подстрок `{user_name}` и `{bind_dn}` на реальное имя пользователя и bind DN (см. [определение LDAP-сервера](#ldap-server-definition)) во время каждого поиска LDAP.
|
||||
- `scope` - область поиска.
|
||||
- Возможные значения: `base`, `one_level`, `children`, `subtree` (по умолчанию).
|
||||
- `search_filter` - шаблон для построения поискового фильтра.
|
||||
- Фильтр получается заменой всех подстрок `{user_name}`, `{bind_dn}` и `{base_dn}` на реальные значения этих параметров.
|
||||
- Не забудьте, что все специальные символы (если они есть) должны быть экранированы при их использовании в XML.
|
||||
- `attribute` - имя атрибут, значения которого будут возвращены после поиска.
|
||||
- `prefix` - префикс, который ожидается в начале каждой строки исходного списка строк, полученного LDAP-поиском. В дальнейшем префикс будет удалён их строк и полученные строки будут трактованы как имена ролей.
|
||||
- По умолчанию, этот параметр пустой.
|
||||
|
||||
Loading…
Reference in New Issue
Block a user