Active Directory user authentication

Active Directory ユーザー認証

Elastic Stack のセキュリティ機能を構成して、Active Directory と通信し、ユーザーを認証できます。詳細は Active Directory レルムの構成 を参照してください。

セキュリティ機能は LDAP を使用して Active Directory と通信するため、active_directory レルムは ldap レルム に似ています。LDAP ディレクトリと同様に、Active Directory はユーザーとグループを階層的に保存します。ディレクトリの階層は、組織単位 (ou)、組織 (o)、および ドメインコンポーネント (dc) などのコンテナから構築されます。

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

セキュリティ機能は、Active Directory セキュリティグループのみをサポートします。配布グループをロールにマッピングすることはできません。

Active Directory を認証に使用する場合、ユーザーが入力したユーザー名は sAMAccountName または userPrincipalName と一致する必要があり、共通名とは一致しません。

Active Directory レルムは、LDAP バインドリクエストを使用してユーザーを認証します。ユーザーを認証した後、レルムは Active Directory でユーザーのエントリを検索します。ユーザーが見つかると、Active Directory レルムはユーザーのエントリの tokenGroups 属性からユーザーのグループメンバーシップを取得します。

Active Directory レルムの構成

Active Directory と統合するには、active_directory レルムを構成し、Active Directory ユーザーとグループをロールマッピングファイルのロールにマッピングします。

• 1. xpack.security.authc.realms.active_directory 名前空間の elasticsearch.yml に active_directory タイプのレルム構成を追加します。最低限、Active Directory domain_name と order を指定する必要があります。
  active_directory レルムに設定できるすべてのオプションについては、Active Directory レルム設定 を参照してください。
  ドメイン名が DNS にマッピングされていない場合、Active Directory へのバインディングは失敗します。Windows DNS サーバーが DNS を提供していない場合は、ローカル /etc/hosts ファイルにドメインのマッピングを追加します。
  例えば、次のレルム構成は、Elasticsearch が ldaps://example.com:636 に接続して Active Directory を介してユーザーを認証するように構成します:

Yaml

xpack:
   security:
   authc:
   realms:
   active_directory:
   my_ad:
   order: 0
   domain_name: ad.example.com
   url: ldaps://ad.example.com:636

elasticsearch.yml でレルムを構成する場合、指定したレルムのみが認証に使用されます。native または file レルムも使用したい場合は、それらをレルムチェーンに含める必要があります。

• 2. 複数のドメインにまたがってユーザーを認証する場合は、追加の手順が必要です。構成やユーザーの認証方法にはいくつかの小さな違いがあります。
  domain_name 設定をフォレストのルートドメイン名に設定します。
  url 設定も設定する必要があります。これは、グローバルカタログに対して認証する必要があり、異なるポートを使用し、すべてのドメインコントローラーで実行されているわけではないためです。
  例えば、次のレルム構成は、特定のドメインコントローラーに接続し、グローバルカタログポートでフォレストルートにドメイン名を設定します:

Yaml

xpack:
   security:
   authc:
   realms:
   active_directory:
   my_ad:
   order: 0
   domain_name: example.com
   url: ldaps://dc1.ad.example.com:3269, ldaps://dc2.ad.example.com:3269
   load_balance:
   type: "round_robin"

この構成では、ユーザーはフルユーザー プリンシパル名 (UPN) またはダウンレベルログオン名のいずれかを使用する必要があります。UPN は通常、ユーザー名と @<DOMAIN_NAME の連結です。例えば [email protected] のようになります。ダウンレベルログオン名は、NetBIOS ドメイン名の後に \ とユーザー名が続きます。例えば AD\johndoe のようになります。ダウンレベルログオン名の使用には、NetBIOS 名からドメイン名を取得するために構成コンテナをクエリするために、通常の LDAP ポート (389 または 636) への接続が必要です。

• 3. (オプション) Elasticsearch が複数の Active Directory サーバーとどのように相互作用するかを構成します。
  load_balance.type 設定はレルムレベルで使用できます。2 つの動作モードがサポートされています: フェイルオーバーと負荷分散。詳細は Active Directory レルム設定 を参照してください。
• 4. (オプション) パスワードを保護するために、Elasticsearch と Active Directory サーバー間の通信を暗号化します。
• 5. Elasticsearch を再起動します。
• 6. (オプション) バインドユーザーを構成します。
  Active Directory レルムは、LDAP バインドリクエストを使用してユーザーを認証します。デフォルトでは、すべての LDAP 操作は、Elasticsearch が認証しているユーザーによって実行されます。場合によっては、通常のユーザーが Active Directory 内のすべての必要なアイテムにアクセスできないことがあり、バインドユーザーが必要です。バインドユーザーを構成でき、ユーザーによって提供された資格情報を認証するために必要な LDAP バインドリクエスト以外のすべての操作を実行するために使用されます。
  バインドユーザーの使用により、実行機能 を Active Directory レルムで使用でき、Active Directory への接続のプールを維持することができます。これらのプール接続は、ユーザー認証ごとに作成および破棄する必要があるリソースの数を削減します。
  次の例は、bind_dn および secure_bind_password 設定を使用してバインドユーザーを構成する方法を示しています:

Yaml

xpack:
   security:
   authc:
   realms:
   active_directory:
   my_ad:
   order: 0
   domain_name: ad.example.com
   url: ldaps://ad.example.com:636
   bind_dn: es_svc_user@ad.example.com

bind_dn ユーザーのパスワードは、適切な secure_bind_password 設定を Elasticsearch キーストアに追加することで構成する必要があります。例えば、次のコマンドは、上記の例のレルムのパスワードを追加します:

Shell

bin/elasticsearch-keystore add  \
  xpack.security.authc.realms.active_directory.my_ad.secure_bind_password

バインドユーザーが構成されている場合、接続プーリングはデフォルトで有効になります。接続プーリングは user_search.pool.enabled 設定を使用して無効にできます。

• 7. Active Directory ユーザーとグループをロールにマッピングします。
  レルム認証プロセスの重要な部分は、認証されたユーザーに関連付けられたロールを解決することです。ロールは、ユーザーがクラスター内で持つ特権を定義します。
  active_directory レルムでは、ユーザーは Active Directory サーバーで外部的に管理されるため、ロールもそこで管理されることが期待されます。実際、Active Directory はグループの概念をサポートしており、これらはしばしば組織内の異なるシステムのユーザーロールを表します。
  active_directory レルムを使用すると、Active Directory ユーザーをその Active Directory グループまたは他のメタデータを介してロールにマッピングできます。このロールマッピングは、ロールマッピング API を介して構成するか、各ノードに保存されたファイルを使用して構成できます。ユーザーが Active Directory レルムに対して認証されると、そのユーザーの特権は、ユーザーがマッピングされているロールによって定義されたすべての特権の和になります。
  マッピング定義内では、グループをその識別名を使用して指定します。例えば、次のマッピング構成は、Active Directory admins グループを monitoring および user ロールの両方にマッピングし、users グループを user ロールにマッピングし、John Doe ユーザーを user ロールにマッピングします。
  ロールマッピング API を介して構成されます:

Python

resp = client.security.put_role_mapping(
   name="admins",
   roles=[
   "monitoring",
   "user"
   ],
   rules={
   "field": {
   "groups": "cn=admins,dc=example,dc=com"
   }
   },
   enabled=True,
  )
  print(resp)

Js

const response = await client.security.putRoleMapping({
   name: "admins",
   roles: ["monitoring", "user"],
   rules: {
   field: {
   groups: "cn=admins,dc=example,dc=com",
   },
   },
   enabled: true,
  });
  console.log(response);

Console

PUT /_security/role_mapping/admins
  {
   "roles" : [ "monitoring" , "user" ],
   "rules" : { "field" : {
   "groups" : "cn=admins,dc=example,dc=com"
   } },
   "enabled": true
  }

Python

resp = client.security.put_role_mapping(
   name="basic_users",
   roles=[
   "user"
   ],
   rules={
   "any": [
   {
   "field": {
   "groups": "cn=users,dc=example,dc=com"
   }
   },
   {
   "field": {
   "dn": "cn=John Doe,cn=contractors,dc=example,dc=com"
   }
   }
   ]
   },
   enabled=True,
  )
  print(resp)

Js

const response = await client.security.putRoleMapping({
   name: "basic_users",
   roles: ["user"],
   rules: {
   any: [
   {
   field: {
   groups: "cn=users,dc=example,dc=com",
   },
   },
   {
   field: {
   dn: "cn=John Doe,cn=contractors,dc=example,dc=com",
   },
   },
   ],
   },
   enabled: true,
  });
  console.log(response);

Console

PUT /_security/role_mapping/basic_users
  {
   "roles" : [ "user" ],
   "rules" : { "any": [
   { "field" : {
   "groups" : "cn=users,dc=example,dc=com"
   } },
   { "field" : {
   "dn" : "cn=John Doe,cn=contractors,dc=example,dc=com"
   } }
   ] },
   "enabled": true
  }

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

Yaml

monitoring:
    - "cn=admins,dc=example,dc=com"
  user:
    - "cn=users,dc=example,dc=com"
    - "cn=admins,dc=example,dc=com"
    - "cn=John Doe,cn=contractors,dc=example,dc=com"

詳細については、ユーザーとグループをロールにマッピングする を参照してください。

• 8. (オプション) Active Directory レルムの metadata 設定を構成して、ユーザーのメタデータに追加のプロパティを含めます。
  デフォルトでは、ldap_dn と ldap_groups がユーザーのメタデータに設定されます。詳細については、Active Directory レルムのユーザーメタデータ を参照してください。

Active Directory レルムのユーザーメタデータ

ユーザーが Active Directory レルムを介して認証されると、次のプロパティがユーザーの メタデータ に設定されます:

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

追加のメタデータは、Active Directory サーバーから metadata 設定を構成することによって抽出できます。

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

load_balance.type 設定は、レルムレベルで使用して、セキュリティ機能が複数の Active Directory サーバーとどのように相互作用するかを構成できます。2 つの動作モードがサポートされています: フェイルオーバーと負荷分散。

詳細は 負荷分散とフェイルオーバー を参照してください。

Elasticsearch と Active Directory 間の通信の暗号化

認証のために送信されるユーザー資格情報を保護するために、Elasticsearch と Active Directory サーバー間の通信を暗号化することを強く推奨します。SSL/TLS 経由で接続することで、Elasticsearch がユーザー資格情報を送信する前に Active Directory サーバーのアイデンティティが認証され、ユーザー名とパスワードが転送中に暗号化されます。

SSL/TLS 経由で Active Directory サーバーに接続するクライアントとノードは、Active Directory サーバーの証明書またはサーバーのルート CA 証明書をキーストアまたはトラストストアにインストールする必要があります。

• 1. xpack.security.authc.realms 名前空間のレルム構成を elasticsearch.yml ファイルに作成します。詳細は Active Directory レルムの構成 を参照してください。
• 2. レルム構成で url 属性を設定して、LDAPS プロトコルとセキュアポート番号を指定します。例えば、url: ldaps://ad.example.com:636 のように。
• 3. 各ノードを構成して、Active Directory サーバー証明書に署名した証明書機関 (CA) によって署名された証明書を信頼します。
  次の例は、構成ディレクトリ内にある CA 証明書 ( cacert.pem ) を信頼する方法を示しています:

Shell

xpack:
   security:
   authc:
   realms:
   active_directory:
   ad_realm:
   order: 0
   domain_name: ad.example.com
   url: ldaps://ad.example.com:636
   ssl:
   certificate_authorities: [ "ES_PATH_CONF/cacert.pem" ]

CA 証明書は PEM 形式の証明書でなければなりません。
これらの設定に関する詳細は、Active Directory レルム設定 を参照してください。

• 4. Elasticsearch を再起動します。

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