LDAPユーザー認証

Elastic Stackのセキュリティ機能を構成して、ユーザーを認証するためにLightweight Directory Access Protocol (LDAP)サーバーと通信することができます。 LDAPレルムの構成を参照してください。

LDAPは、ユーザーとグループを階層的に保存します。これは、ファイルシステム内のフォルダーがグループ化される方法に似ています。LDAPディレクトリの階層は、組織単位(ou)、組織(o)、およびドメインコンポーネント(dc)などのコンテナから構築されます。

エントリへのパスは、ユーザーまたはグループを一意に識別する識別名 (DN)です。ユーザー名とグループ名には、通常、共通名(cn)や一意のID(uid)などの属性があります。DNは文字列として指定されます。たとえば、"cn=admin,dc=example,dc=com"（空白は無視されます）。 

  3. ## LDAPグループをロールにマッピング
  5. レルム認証プロセスの重要な部分は、認証されたユーザーに関連付けられたロールを解決することです。ロールは、ユーザーがクラスター内で持つ特権を定義します。  
  7. `````ldap`````レルムでは、ユーザーはLDAPサーバーで外部的に管理されるため、彼らのロールもそこで管理されることが期待されます。実際、LDAPはグループの概念をサポートしており、これらはしばしば組織内の異なるシステムのユーザーロールを表します。  
  9. `````ldap`````レルムでは、LDAPユーザーをそのLDAPグループまたは他のメタデータを介してロールにマッピングできます。このロールマッピングは、[ロールマッピングAPIを追加する](/read/elasticsearch-8-15/2e6f16fee973f843.md)を介して構成するか、各ノードに保存されたファイルを使用して構成できます。ユーザーがLDAPで認証されると、そのユーザーの特権は、ユーザーがマッピングされているロールによって定義されたすべての特権の和になります。
  12. ## LDAPレルムの構成
  14. LDAPと統合するには、`````ldap`````レルムを構成し、LDAPグループをユーザーロールにマッピングします。  
  16. - 1*.* 使用したいモードを決定します。`````ldap`````レルムは、ユーザー検索モードとユーザーDNの特定のテンプレートを使用するモードの2つの動作モードをサポートしています。  
  17. LDAPユーザー検索は最も一般的な動作モードです。このモードでは、LDAPディレクトリを検索する権限を持つ特定のユーザーが、提供されたユーザー名とLDAP属性に基づいて認証ユーザーのDNを検索するために使用されます。見つかった場合、ユーザーは見つかったDNと提供されたパスワードを使用してLDAPサーバーにバインドしようとすることで認証されます。  
  18. LDAP環境がユーザーに対して特定の標準命名条件を使用している場合、ユーザーDNテンプレートを使用してレルムを構成できます。この方法の利点は、ユーザーDNを見つけるために検索を実行する必要がないことです。ただし、正しいユーザーDNを見つけるために複数のバインド操作が必要になる場合があります。  
  19. - 2*.* ユーザー検索を使用して`````ldap`````レルムを構成するには：  
  20.   - 2*.*1*.* `````elasticsearch.yml`````の下の`````xpack.security.authc.realms.ldap`````名前空間にレルム構成を追加します。最低限、LDAPサーバーの`````url`````と`````order`````を指定し、ユーザーが検索されるコンテナDNに`````user_search.base_dn`````を設定する必要があります。`````ldap`````レルムに設定できるすべてのオプションについては、[LDAPレルム設定](d1e2d0944ccc2737.md#ref-ldap-settings)を参照してください。  
  21. たとえば、次のスニペットは、ユーザー検索で構成されたLDAPレルムを示しています：
  24. #### Yaml
  26. ``````yaml
  27. xpack:
  28.    security:
  29.    authc:
  30.    realms:
  31.    ldap:
  32.    ldap1:
  33.    order: 0
  34.    url: "ldaps://ldap.example.com:636"
  35.    bind_dn: "cn=ldapuser, ou=users, o=services, dc=example, dc=com"
  36.    user_search:
  37.    base_dn: "dc=example,dc=com"
  38.    filter: "(cn={0})"
  39.    group_search:
  40.    base_dn: "dc=example,dc=com"
  41.    files:
  42.    role_mapping: "ES_PATH_CONF/role_mapping.yml"
  43.    unmapped_groups_as_roles: false
  44. `
  3. #### Shell
  5. ``````shell
  6. bin/elasticsearch-keystore add \
  7.   xpack.security.authc.realms.ldap.ldap1.secure_bind_password
  8. `
  1. - 3*.* ユーザーDNテンプレートを使用して`````ldap`````レルムを構成するには：  
  2.   - 3*.*1*.* `````elasticsearch.yml`````の`````xpack.security.authc.realms.ldap`````名前空間にレルム構成を追加します。最低限、LDAPサーバーの`````url`````と`````order`````を指定し、`````user_dn_templates`````オプションで少なくとも1つのテンプレートを指定する必要があります。`````ldap`````レルムに設定できるすべてのオプションについては、[LDAPレルム設定](d1e2d0944ccc2737.md#ref-ldap-settings)を参照してください。  
  3. たとえば、次のスニペットは、ユーザーDNテンプレートで構成されたLDAPレルムを示しています：
  6. #### Yaml
  8. ``````yaml
  9. xpack:
  10.    security:
  11.    authc:
  12.    realms:
  13.    ldap:
  14.    ldap1:
  15.    order: 0
  16.    url: "ldaps://ldap.example.com:636"
  17.    user_dn_templates:
  18.                 - "cn={0}, ou=users, o=marketing, dc=example, dc=com"
  19.                 - "cn={0}, ou=users, o=engineering, dc=example, dc=com"
  20.    group_search:
  21.    base_dn: "dc=example,dc=com"
  22.    files:
  23.    role_mapping: "/mnt/elasticsearch/group_to_role_mapping.yml"
  24.    unmapped_groups_as_roles: false
  25. `
  1. - 4*.* (オプション) 複数のLDAPサーバーとのセキュリティ機能の相互作用を構成します。  
  2. `````load_balance.type`````設定はレルムレベルで使用できます。Elasticsearchのセキュリティ機能は、フェイルオーバーと負荷分散の両方の動作モードをサポートしています。 [LDAPレルム設定](d1e2d0944ccc2737.md#ref-ldap-settings)を参照してください。  
  3. - 5*.* (オプション) パスワードを保護するために、[ElasticsearchとLDAPサーバー間の通信を暗号化します](fe27aa266a189863.md#tls-ldap)。  
  4. - 6*.* Elasticsearchを再起動します。  
  5. - 7*.* LDAPグループをロールにマッピングします。  
  6. `````ldap`````レルムでは、LDAPユーザーをそのLDAPグループまたは他のメタデータを介してロールにマッピングできます。このロールマッピングは、[ロールマッピングAPIを追加する](/read/elasticsearch-8-15/2e6f16fee973f843.md)を介して構成するか、各ノードに保存されたファイルを使用して構成できます。ユーザーがLDAPで認証されると、そのユーザーの特権は、ユーザーがマッピングされているロールによって定義されたすべての特権の和になります。  
  7. マッピング定義内では、グループをその識別名を使用して指定します。たとえば、次のマッピング構成は、LDAP `````admins`````グループを`````monitoring`````および`````user`````ロールの両方にマッピングし、`````users`````グループを`````user`````ロールにマッピングします。  
  8. ロールマッピングAPIを介して構成されます：
  11. #### Python
  13. ``````python
  14. resp = client.security.put_role_mapping(
  15.    name="admins",
  16.    roles=[
  17.    "monitoring",
  18.    "user"
  19.    ],
  20.    rules={
  21.    "field": {
  22.    "groups": "cn=admins,dc=example,dc=com"
  23.    }
  24.    },
  25.    enabled=True,
  26.   )
  27.   print(resp)
  28. `

Js

  1. const response = await client.security.putRoleMapping({
  2.    name: "admins",
  3.    roles: ["monitoring", "user"],
  4.    rules: {
  5.    field: {
  6.    groups: "cn=admins,dc=example,dc=com",
  7.    },
  8.    },
  9.    enabled: true,
  10.   });
  11.   console.log(response);

Console

  1. PUT /_security/role_mapping/admins
  2.   {
  3.    "roles" : [ "monitoring" , "user" ],
  4.    "rules" : { "field" : {
  5.    "groups" : "cn=admins,dc=example,dc=com"
  6.    } },
  7.    "enabled": true
  8.   }
adminsグループのLDAP識別名(DN)。

Python

  1. resp = client.security.put_role_mapping(
  2.    name="basic_users",
  3.    roles=[
  4.    "user"
  5.    ],
  6.    rules={
  7.    "field": {
  8.    "groups": "cn=users,dc=example,dc=com"
  9.    }
  10.    },
  11.    enabled=True,
  12.   )
  13.   print(resp)

Js

  1. const response = await client.security.putRoleMapping({
  2.    name: "basic_users",
  3.    roles: ["user"],
  4.    rules: {
  5.    field: {
  6.    groups: "cn=users,dc=example,dc=com",
  7.    },
  8.    },
  9.    enabled: true,
  10.   });
  11.   console.log(response);

Console

  1. PUT /_security/role_mapping/basic_users
  2.   {
  3.    "roles" : [ "user" ],
  4.    "rules" : { "field" : {
  5.    "groups" : "cn=users,dc=example,dc=com"
  6.    } },
  7.    "enabled": true
  8.   }
usersグループのLDAP識別名(DN)。

または、代わりにロールマッピングファイルを介して構成されます：

Yaml

  1. monitoring:
  2.     - "cn=admins,dc=example,dc=com"
  3.   user:
  4.     - "cn=users,dc=example,dc=com"
  5.     - "cn=admins,dc=example,dc=com"
マッピングされたロールの名前。
adminsグループのLDAP識別名(DN)。
usersグループのLDAP識別名(DN)。

詳細については、LDAPグループをロールにマッピングおよびユーザーとグループをロールにマッピングを参照してください。
LDAPレルムは、ロールマッピングの代替として認可レルムをサポートしています。

  • 8. (オプション) ユーザーのメタデータに追加フィールドを含めるために、LDAPレルムのmetadata設定を構成します。
    デフォルトでは、ldap_dnおよびldap_groupsがユーザーのメタデータに入力されます。詳細については、LDAPレルムのユーザーメタデータを参照してください。
    以下の例では、ユーザーの共通名(cn)をメタデータの追加フィールドとして含めています。

Yaml

  1. xpack:
  2.    security:
  3.    authc:
  4.    realms:
  5.    ldap:
  6.    ldap1:
  7.    order: 0
  8.    metadata: cn

LDAPレルムにおけるユーザーメタデータ

ユーザーがLDAPレルムを介して認証されると、次のプロパティがユーザーのメタデータに入力されます：

フィールド 説明
ldap_dn ユーザーの識別名。
ldap_groups ユーザーのために解決された各グループの識別名（DN）。これらのグループがロールにマッピングされているかどうかに関係なく。

このメタデータは、認証APIで返され、ロールでテンプレート化されたクエリと共に使用できます。

追加のフィールドは、LDAPレルムのmetadata設定を構成することによってユーザーのメタデータに含めることができます。このメタデータは、ロールマッピングAPIやテンプレート化されたロールクエリで使用できます。

負荷分散とフェイルオーバー

  2. [負荷分散とフェイルオーバー](d1e2d0944ccc2737.md#load-balancing)を参照してください。
  5. ## ElasticsearchとLDAP間の通信の暗号化
  7. LDAPレルムで認証のために送信されるユーザー資格情報を保護するために、ElasticsearchとLDAPサーバー間の通信を暗号化することを強く推奨します。SSL/TLSを介して接続することで、Elasticsearchがユーザー資格情報を送信する前にLDAPサーバーのアイデンティティが認証され、接続の内容が暗号化されます。TLSを介してLDAPサーバーに接続するクライアントとノードは、LDAPサーバーの証明書またはサーバーのルートCA証明書をキーストアまたはトラストストアにインストールする必要があります。  
  9. 詳細については、[LDAPユーザー認証](/read/elasticsearch-8-15/fe27aa266a189863.md)を参照してください。  
  11. - 1*.* 各ノードでレルムのTLS設定を構成して、LDAPサーバー証明書に署名したCAの署名された証明書を信頼します。次の例は、Elasticsearchの[構成ディレクトリ](cbd51842921e98c1.md#config-files-location)内にあるCA証明書`````cacert.pem`````を信頼する方法を示しています：
  14. #### Shell
  16. ``````shell
  17. xpack:
  18.    security:
  19.    authc:
  20.    realms:
  21.    ldap:
  22.    ldap1:
  23.    order: 0
  24.    url: "ldaps://ldap.example.com:636"
  25.    ssl:
  26.    certificate_authorities: [ "cacert.pem" ]
  27. `

上記の例では、CA証明書はPEMエンコードされている必要があります。
PKCS#12およびJKSファイルもサポートされています - LDAPレルム設定のssl.truststore.pathの説明を参照してください。
CA証明書の代わりに個々のサーバー証明書を指定することもできますが、これは単一のLDAPサーバーがある場合や証明書が自己署名されている場合にのみ推奨されます。

  • 2. レルム構成でurl属性を設定して、LDAPSプロトコルとセキュアポート番号を指定します。たとえば、url: ldaps://ldap.example.com:636。
  • 3. Elasticsearchを再起動します。

デフォルトでは、Elasticsearchを使用してLDAPサーバーに接続するように構成すると、レルム構成でurl属性で指定されたホスト名またはIPアドレスを証明書内の値と照合しようとします。証明書内の値とレルム構成の値が一致しない場合、ElasticsearchはLDAPサーバーへの接続を許可しません。これは、中間者攻撃から保護するために行われます。必要に応じて、ssl.verification_modeプロパティをcertificateに設定することで、この動作を無効にすることができます。