LDAP
このページは ClickHouse Cloud には当てはまりません。ここで文書化されている機能は ClickHouse Cloud サービスでは利用できません。 詳細については ClickHouse の Cloud Compatibility ガイドをご覧ください。
LDAPサーバーはClickHouseユーザーの認証に使用できます。これを行うためのアプローチは二つあります。
users.xml
またはローカルアクセスポイントに定義された既存のユーザーに対してLDAPを外部認証システムとして使用する。- LDAPを外部ユーザーディレクトリとして使用し、LDAPサーバーに存在する場合はローカルで定義されていないユーザーを認証できるようにする。
これらのアプローチのいずれにおいても、ClickHouseの設定内で内部名のLDAPサーバーを定義する必要があります。これにより、設定の他の部分で参照できるようになります。
LDAPサーバーの定義
LDAPサーバーを定義するには、config.xml
にldap_servers
セクションを追加する必要があります。
例
ldap_servers
セクション内では、異なる名前を使用して複数のLDAPサーバーを定義することができます。
パラメーター
host
— LDAPサーバーのホスト名またはIP。必須で、空にはできません。port
— LDAPサーバーポート。enable_tls
がtrue
に設定されている場合はデフォルトが636
、それ以外は389
です。bind_dn
— バインドに使用されるDNを構築するためのテンプレート。- 結果として得られるDNは、各認証試行時にテンプレートのすべての
{user_name}
部分文字列を実際のユーザー名に置き換えることで構築されます。
- 結果として得られるDNは、各認証試行時にテンプレートのすべての
user_dn_detection
— バインドされたユーザーの実際のユーザーDNを検出するためのLDAP検索パラメータのセクション。- これは主にサーバーがActive Directoryの場合の役割マッピングのための検索フィルターで使用されます。結果として得られるユーザーDNは、
{user_dn}
部分文字列が許可される場所で置き換えられます。デフォルトでは、ユーザーDNはバインドDNと同じに設定されますが、検索が行われると、実際に検出されたユーザーDNの値に更新されます。base_dn
— LDAP検索のためにbase DNを構築するためのテンプレート。- 結果として得られるDNは、LDAP検索時にテンプレートのすべての
{user_name}
および{bind_dn}
部分文字列を実際のユーザー名とバインドDNに置き換えることで構築されます。
- 結果として得られるDNは、LDAP検索時にテンプレートのすべての
scope
— LDAP検索のスコープ。- 受け入れられる値は以下です:
base
,one_level
,children
,subtree
(デフォルト)。
- 受け入れられる値は以下です:
search_filter
— LDAP検索のための検索フィルターを構築するためのテンプレート。- 結果として得られるフィルターは、LDAP検索時にテンプレートのすべての
{user_name}
、{bind_dn}
、および{base_dn}
部分文字列を、実際のユーザー名、バインドDN、およびbase DNに置き換えることで構築されます。 - 特殊文字はXMLで正しくエスケープする必要があります。
- 結果として得られるフィルターは、LDAP検索時にテンプレートのすべての
- これは主にサーバーがActive Directoryの場合の役割マッピングのための検索フィルターで使用されます。結果として得られるユーザーDNは、
verification_cooldown
— 成功したバインド試行の後、ユーザーがLDAPサーバーに接触せず、すべての連続リクエストに対して成功裏に認証されると見なされる時間(秒)です。- キャッシュを無効にし、各認証リクエストでLDAPサーバーに接触させるようにするには、
0
(デフォルト)を指定してください。
- キャッシュを無効にし、各認証リクエストでLDAPサーバーに接触させるようにするには、
enable_tls
— LDAPサーバーへの安全な接続を使用するためのフラグ。- プレーンテキストの
ldap://
プロトコル(推奨されません)にはno
を指定します。 - SSL/TLS
ldaps://
プロトコル(推奨、デフォルト)にはyes
を指定します。 - レガシーのStartTLSプロトコル(プレーンテキストの
ldap://
プロトコルからTLSにアップグレード)にはstarttls
を指定します。
- プレーンテキストの
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
またはローカルアクセス制御経路に定義されたユーザー)のパスワード確認の手段として使用できます。これを実現するには、ユーザー定義の中でpassword
またはそれに類似したセクションの代わりに、事前に定義されたLDAPサーバー名を指定します。
各ログイン試行時に、ClickHouseはbind_dn
パラメーターで定義された指定されたDNに"バインド"しようとし、提供された認証情報が成功すればユーザーは認証されたと見なされます。これはしばしば"シンプルバインド"メソッドと呼ばれます。
例
ユーザーmy_user
はmy_ldap_server
を参照しています。このLDAPサーバーは、前述のようにconfig.xml
ファイルのメイン設定で構成されている必要があります。
SQL駆動の アクセス制御とアカウント管理 が有効な場合、LDAPサーバーによって認証されたユーザーも CREATE USER ステートメントを使用して作成できます。
クエリ:
LDAP外部ユーザーディレクトリ
ローカルで定義されたユーザーに加えて、リモートLDAPサーバーはユーザー定義のソースとして使用できます。これを実現するには、config.xml
ファイルのusers_directories
セクション内のldap
セクションで事前に定義されたLDAPサーバー名を指定します(LDAPサーバーの定義を参照)。
各ログイン試行時に、ClickHouseはローカルでユーザー定義を検索し、通常通り認証を試みます。ユーザーが定義されていない場合、ClickHouseは外部LDAPディレクトリに定義が存在するものと見なし、提供された認証情報を使用して指定されたDNに"バインド"しようとします。成功すると、ユーザーは存在すると見なされ認証されます。ユーザーはroles
セクションで指定されたリストから役割を割り当てられます。加えて、LDAP "検索"を実行し、結果を役割名として変換し、role_mapping
セクションが構成されていればユーザーに割り当てることもできます。これにはSQL駆動の アクセス制御とアカウント管理 が有効であり、役割は CREATE ROLE ステートメントを使用して作成されている必要があります。
例
config.xml
に入れます。
user_directories
セクション内のldap
セクションで参照されるmy_ldap_server
は、config.xml
で構成された事前定義されたLDAPサーバーである必要があります(LDAPサーバーの定義を参照)。
パラメーター
server
— 上記のldap_servers
設定セクションで定義されたLDAPサーバー名の一つ。必須で、空にはできません。roles
— LDAPサーバーから取得される各ユーザーに割り当てられるローカルに定義された役割のリストを含むセクション。- ここに役割が指定されていない場合や、役割マッピング中に割り当てられない場合、ユーザーは認証後に何のアクションも実行できません。
role_mapping
— LDAP検索パラメータおよびマッピングルールを含むセクション。- ユーザーが認証される際、LDAPにバインドされている間に、
search_filter
とログインユーザーの名前を使用してLDAP検索が実行されます。その検索中に見つかった各エントリについて、指定された属性の値が抽出されます。指定されたプレフィックスを持つ各属性値からプレフィックスが削除され、その残りの値がClickHouseに事前に定義され、作成されていることが期待されるローカル役割の名前になります。 - 同じ
ldap
セクション内に複数のrole_mapping
セクションを定義することができます。すべてが適用されます。base_dn
— LDAP検索のためにbase DNを構築するためのテンプレート。- 結果として得られるDNは、各LDAP検索時にテンプレートのすべての
{user_name}
、{bind_dn}
、および{user_dn}
部分文字列を実際のユーザー名、バインドDN、およびユーザーDNに置き換えることで構築されます。
- 結果として得られるDNは、各LDAP検索時にテンプレートのすべての
scope
— LDAP検索のスコープ。- 受け入れられる値は以下です:
base
,one_level
,children
,subtree
(デフォルト)。
- 受け入れられる値は以下です:
search_filter
— LDAP検索のための検索フィルターを構築するためのテンプレート。- 結果として得られるフィルターは、各LDAP検索時にテンプレートのすべての
{user_name}
、{bind_dn}
、{user_dn}
、および{base_dn}
部分文字列を実際のユーザー名、バインドDN、ユーザーDN、およびbase DNに置き換えることで構築されます。 - 特殊文字はXMLで正しくエスケープする必要があります。
- 結果として得られるフィルターは、各LDAP検索時にテンプレートのすべての
attribute
— LDAP検索によって返される値の属性名。デフォルトはcn
。prefix
— LDAP検索によって返される元の文字列リストの各文字列の前に存在することが期待されるプレフィックス。プレフィックスは元の文字列から削除され、結果の文字列はローカル役割名として扱われます。デフォルトでは空です。
- ユーザーが認証される際、LDAPにバインドされている間に、