Docs Menu
Docs Home
/
MongoDBマニュアル
/
自己管理型配置
/
セキュリティ
/
ロールベースのアクセス制御

自己管理型配置での LDAP 認可

項目一覧

  • Considerations
  • 構成
  • Tutorials
  • LDAP 承認を使用した MongoDB サーバーへの接続
  • LDAP 承認のための MongoDB ロール

バージョン3.4の新機能: MongoDB Enterpriseは 、認証されたユーザーが属する LDAP グループに対する LDAP サーバーのクエリをサポートしています。 MongoDB は、返された各グループの識別名（DN）を adminデータベースのロールにマッピングします。 MongoDB は、マップされたロールとそれに関連付けられた特権に基づいてユーザーを認可します。 詳細については、「 LDAP 認可」を参照してください。

LDAP 認証プロセスの概要は次のとおりです。

  1. クライアントは MongoDB に接続し、外部認証をサポートする任意の認証メカニズムを使用して、認証を行います。

    $external認証ユーザー（Kerberos、LDAP、または x.509 ユーザー）でクライアント セッションと因果整合性の保証を使用するには、ユーザー名を 10k バイトより大きくすることはできません。

  2. MongoDB は、security.ldap.bind.queryUser と security.ldap.bind.queryPassword で指定された認証情報を使用して、security.ldap.servers で指定された LDAP サーバーにバインドします。

    MongoDB はデフォルトでシンプル バインディングを使用しますが、security.ldap.bind.method および security.ldap.bind.saslMechanisms で構成されている場合は、代わりに sasl バインディングを使用できます。

  3. MongoDB は security.ldap.authz.queryTemplate を使用して LDAP クエリを構築し、認証されたユーザーのグループ ノードについて LDAP サーバーにクエリを実行します。

    MongoDB は、security.ldap.userToDNMapping オプションを使用して、クエリ テンプレートをサポートするためにユーザー名を変換できます。

  4. LDAP サーバーはクエリを評価し、認証されたユーザーが属するグループのリストを返します。

  5. MongoDB は、返された各グループの識別名(DN)を admin データベースのロールにマッピングすることで、ユーザーがサーバー上でアクションを実行することを承認します。返されたグループ DN が admin データベース上の既存のロールの名前と完全に一致する場合、MongoDB はそのロールに割り当てられたロールと権限をユーザーに付与します。 詳細については、「 LDAP 認証のための MongoDB ロール 」を参照してください。

  6. クライアントは、認証されたユーザーに付与されたロールまたは権限を必要とするアクションを MongoDB サーバー上で実行できます。

  7. ldapUserCacheInvalidationInterval で定義された間隔で、MongoDB は $external キャッシュをフラッシュします。外部で承認されたユーザーによって実行される後続の操作を実行する前に、MongoDB は LDAP サーバーからグループ メンバーシップを再取得します。

Considerations

LDAP の完全な説明は、このドキュメントの範囲外です。このページは LDAP に関する予備知識を前提としています。

このドキュメントは、MongoDB LDAP 承認についてのみ説明し、LDAP 上の他のリソースを置き換えるものではありません。LDAP 認証を設定する前に、LDAP とそれに関連する事柄について十分に理解することをお勧めします。

MongoDB は、お客様の MongoDB 配置に LDAP 認証を最適に構成するための プロフェッショナル サービス を提供できます。

互換性のある認証メカニズム

MongoDB は、次の認証方法による LDAP 承認をサポートしています。

この構成では、MongoDB は LDAP、X.509、または Kerberos 承認を使用してクライアント接続を認証します。

接続プール

認証および承認のために LDAP サーバーに接続する場合、MongoDB はデフォルトで次のことを行います。

  • 次の場合は、接続プーリングを使用します。

    • Windows の場合または

    • MongoDB Enterprise バイナリが libldap_r にリンクされている Linux の場合。

  • 次の場合は、接続プーリングを使用しません。

    • MongoDB Enterprise バイナリが libldap にリンクされている Linux の場合。

接続プーリングの動作を変更するには、ldapUseConnectionPool パラメーターをアップデートします。

libldap および libldap_r

libldap にリンクされた MongoDB 4.2 Enterprise バイナリ（RHEL で実行している場合など）の場合、libldap へのアクセスは同期され、パフォーマンスおよびレイテンシのコストが発生します。

libldap_r にリンクされた MongoDB 4.2 Enterprise バイナリの場合、前の MongoDB バージョンから動作に変更はありません。

ユーザー管理

LDAP 承認では、ユーザーの作成と管理は LDAP サーバー上で行われます。MongoDB では、admin データベース上にロールを作成する必要があります。各ロールの名前は、LDAP グループ識別名（DN）と完全に一致する必要があります。これは、$external データベースにユーザーを作成する必要がある MongoDB 管理承認とは対照的です。

MongoDB Server上のロールを管理するには、userAdmin によって提供されるようなロール管理権限を持つ admin データベース ロールに対応するグループ メンバーシップを持つユーザーとして認証します。LDAP グループ DN に対応するロールを作成または更新して、そのグループのメンバーシップを持つユーザーが適切なロールと権限を受け取るようにします。

たとえば、データベース管理者の LDAP グループには、管理ロールと権限を持つロールがあります。マーケティング ユーザーまたは分析ユーザーの LDAP グループには、特定のデータベースに対する読み取り権限のみを持つロールがある場合があります。

重要

対応する LDAP グループに対してロールを構成する場合、そのグループのメンバーシップを持つすべてのユーザーが、構成されたロールと権限を受け取ることができることを覚えておいてください。MongoDB ロール、LDAP グループ、またはグループ メンバーシップを構成する際には、最小権限の原則を適用することを検討してください。

ロール管理権限を持つロールが存在せず、かつこれらの権限を持つ $external 以外のユーザーも存在しない場合は、LDAP サーバー上のグループまたはグループ メンバーシップへの追加や変更を反映するように新しいロールまたは既存のロールを変更できないため、事実上、ユーザー管理を実行することはできません。

MongoDB サーバーでロールを管理できない状況に対処するには、次の手順を実行します。

  1. 認証と LDAP 承認を使用せず MongoDB サーバーを再起動

  2. 適切な LDAP グループ識別名に対応する名前を持つロールを admin データベースに作成します。グループ DN を選択するときは、どのグループがデータベース管理に最も適しているかを考慮してください。

  3. 認証と LDAP 承認を使用して MongoDB サーバーを再起動

  4. 作成された管理ロールに対応するグループのメンバーシップを持つユーザーとして認証します。

既存ユーザー

承認に LDAP を使用する MongoDB サーバーは、$external データベース上の既存のユーザーにアクセスできなくなります。$external データベースに既存のユーザーが存在する場合、継続的なアクセスを保証するには、$external データベースの各ユーザーに対して次の要件を満たす必要があります。

  • ユーザーは LDAP サーバー上に対応するユーザー オブジェクトを持っています。

  • ユーザー オブジェクトは適切な LDAP グループのメンバーシップを持っています。

  • MongoDB には、ユーザーの LDAP グループにちなんで名付けられた admin データベースのロールがあり、付与されたロールと権限は、$external 以外のユーザーに付与されたものと同じです。

$external データベースに存在しないユーザーによるアクセスを引き続き許可する場合は、authenticationMechanisms パラメーターに、必要に応じて SCRAM-SHA-1 および/または SCRAM-SHA-256 が含まれていることを確認してください。または、上記の要件を適用して、それらのユーザーを LDAP 認証に移行します。

レプリカセット

レプリカセットの場合は、プライマリを構成する前に、まずセカンダリ ノードとアービタ ノードで LDAP 承認を構成します。これは、シャード レプリカセット、またはコンフィギュレーションサーバー レプリカセットにも適用されます。書き込みの可用性のために大多数のノードを維持するには、一度に 1 つのレプリカセット ノードを構成します。

シャーディングされたクラスター

シャーディングされたクラスターでは、クラスター レベルのユーザーに対してコンフィギュレーションサーバー上で LDAP 承認を構成する必要があります。オプションとして、シャード ローカル ユーザーに対し、各シャードで LDAP 承認を構成できます。

構成

LDAP 承認を使用するには、次の設定を構成する必要があります。

オペレーティング システム ライブラリ経由の承認に LDAP を使用するには、mongod または mongos 構成ファイルの一部として次の設定を指定します。

オプション
説明
必須
host[:port] 形式の、引用符で囲まれカンマで区切りられた LDAP サーバーのリスト。
はい

RFC4515 と RFC4516 ユーザーが属する LDAP グループを取得するために MongoDB によって実行される LDAP 形式のクエリ URL テンプレート。クエリは、 serversで指定されたホストに対して相対的です。

テンプレートでは、次のトークンを使用できます。

  • {USER}
    認証されたユーザー名、または transformed ユーザー名を LDAP クエリに置き換えます。
  • {PROVIDED_USER}
    指定されたユーザー名（つまり、認証または LDAP 変換の前）を LDAP クエリに置き換えます。

このパラメーターをサポートするのは mongod のみです。mongos は、コンフィギュレーションサーバーで構成されているこの設定に従います。

はい

MongoDB サーバーが LDAP サーバーに接続して操作とクエリを実行するときにバインドする ID。

queryPassword と一緒に使用します。

指定されたユーザーには、構成された queryTemplate で生成された LDAP クエリをサポートするための適切な権限が必要です。

はい
queryUser を使用するときに LDAP サーバーにバインドするために使用されるパスワード。
はい

mongod または mongos が LDAP サーバーに認証またはバインドする方法を指定するために使用されます。security.ldap.bind.saslMechanisms で定義されている SASL プロトコルの 1 つを使用するには、sasl を指定します。

デフォルトは simple です。

いいえ。ただし、LDAP サーバーへのバインディングに sasl を使用する場合を除きます。

LDAP サーバーへの認証またはバインディング時に mongod または mongos が使用できる SASL メカニズムを指定するために使用されます。MongoDB と LDAP サーバーは少なくとも 1 つの SASL メカニズムに同意する必要があります。

デフォルトは DIGEST-MD5 です。

いいえ。ただし、method を sasl に設定し、別の SASL メカニズムまたは追加の SASL メカニズムが必要な場合を除きます。
Windows MongoDB 配置では、LDAP サーバーに接続するときに、認証またはバインディングで queryUser と queryPassword の代わりにオペレーティング システムの認証情報を使用できます。
いいえ。ただし、queryUser と queryPassword を置き換える場合を除きます。
queryTemplate によっては、認証されたクライアントのユーザー名を変換して、LDAP クエリ URL をサポートする必要がある場合があります。userToDNMapping によって、MongoDB は受信したユーザー名を変換できます。
いいえ。ただし、クライアントのユーザー名をLDAP DNに変換する必要がある場合を除きます。

LDAP 承認を構成したら、mongod または mongos を再起動します。サーバーは、X.509、Kerberos、または LDAP による LDAP 承認を使用して、クライアント接続を認証するようになりました。

LDAP クエリ テンプレート

MongoDBは、security.ldap.authz.queryTemplate を使用して RFC4516 形式の LDAP クエリ URLを作成します。テンプレートでは、次のいずれかを使用できます。

  • {USER} プレースホルダーを使用して、認証されたユーザー名を LDAP クエリ URL に置き換えます。MongoDB が userToDNMapping を使用してユーザー名を変換した場合、MongoDB は LDAP クエリ URL を構築するときに {USER} トークンを変換されたユーザー名に置き換えます。

  • {PROVIDED_USER} 指定されたユーザー名（つまり、認証または LDAP 変換の前）を LDAP クエリに置き換えるためのプレースホルダー。

ユーザーのグループを取得するためのクエリ テンプレートを設計します。

例

次のクエリ テンプレートは、LDAP ユーザー オブジェクトの memberOf 属性にリストされているすべてのグループを返します。このクエリは、memberOf 属性が存在することを前提としています。特定の LDAP 配置では、グループ メンバーシップを追跡するために異なる属性または方法が使用される場合があります。このクエリでは、ユーザーが、ユーザー名として完全な LDAP DN を使用して認証することも想定しています。

"{USER}?memberOf?base"

LDAP クエリ URL は、 RFC4516 で定義されている形式に準拠する必要があります :

[ dn  [ ? [attributes] [ ? [scope] [ ? [filter] [ ? [Extensions] ] ] ] ] ]

RFC4516 から引用した各コンポーネントの定義を考慮します。

dn は、RFC4514 で説明されている 文字列形式を使用する LDAP Distinguished Name（識別名）です。これは、LDAP 検索の基本オブジェクトまたは非検索操作のターゲットを識別します。

attributes 構造は、エントリからどの属性が返されるかを示すために使用されます。

scope 構造は、指定された LDAP サーバーで実行する検索の範囲を指定するために使用されます。許容されるスコープは、基本オブジェクト検索の場合は "base"、1 レベル検索の場合は "one"、サブツリー検索の場合は "sub" です。

filter は、検索中に指定されたスコープ内のエントリに適用する検索フィルターを指定するために使用されます。[RFC4515] で指定されている形式です。

extensions 構造は、LDAP URL に拡張性メカニズムを提供し、将来的に URL の機能を拡張できるようにします。

クエリに attribute が含まれている場合、MongoDB では、このエンティティがノードである DN をクエリが検索すると想定します。

クエリに属性が含まれていない場合、MongoDB は、クエリが検索するのはユーザーがメンバーであるすべてのエンティティであると想定します。

MongoDB は現在、LDAP クエリで指定された拡張子を無視します。

重要

RFC4516 または LDAP クエリ URL の構築の説明は、このドキュメントの範囲外です。

Tutorials

次のチュートリアルには、オペレーティング システムの LDAP ライブラリを介して LDAP サーバーに接続する手順が含まれています。

LDAP 承認を使用した MongoDB サーバーへの接続

承認に LDAP を使用する場合、mongosh 経由で接続しているユーザーは次の操作を行う必要があります。

MongoDB サーバーの--hostと--portに加えて、配置に関連するその他のオプションを含めます。

たとえば、次の操作は、LDAP 認証と承認で実行されている MongoDB サーバーに対して認証を行います。

mongosh --username alice@dba.example.com --password  --authenticationDatabase '$external' --authenticationMechanism "PLAIN"  --host "mongodb.example.com" --port 27017

-passwordコマンドライン オプションにパスワードを指定しない場合、 mongoshはパスワードの入力を要求します。

重要

shell が $external を変数と解釈するのを防ぐには、$external 引数を二重引用符ではなく一重引用符で囲む必要があります。

LDAP 承認のための MongoDB ロール

MongoDB は、LDAP query によって返された各グループ識別名（DN）を admin データベースのロールにマッピングします。

DN が既存のロールの名前と完全に一致するグループを MongoDB が取得した場合、MongoDB は、そのロールに関連付けられたロールと権限を認証されたユーザーに付与します。MongoDB が返されたグループをロールにマップできない場合、ユーザーには権限が付与されません。

注意

LDAP および Kerberos 認証では通常、$external データベースにユーザーを作成する必要があります。認証に LDAP も使用する場合は、$external データベースにユーザーを作成する必要はありません。必要なのは、admin データベースに適切なロールを作成するだけです。ユーザは引き続き、$external データベースに対して認証を行います。

重要

認可に LDAP を使用しており、LDAP グループ DN に RFC4514 が含まれている場合 エスケープ シーケンスでは、admin データベースで作成するロールも RFC4514 に従ってエスケープする必要があります。

例

データベースには、admin データベースに次のロールが構成されています。

{
    role: "CN=dba,CN=Users,DC=example,DC=com",
    privileges: [],
    roles: [ "dbAdminAnyDatabase", "clusterAdmin" ]
}
{
   role: "CN=analytics,CN=Users,DC=example,DC=com"
   privileges: [],
   roles: [
         { role : "read", db : "web_statistics" },
         { role : "read", db : "user_statistics" }
       ]
}

ユーザー alice@dba.example.com を $external データベースに対して認証した後、MongoDB サーバーは構成された query template から派生したクエリを実行して、認証されたユーザーをメンバーとして含むグループを検索します。この例では、MongoDB サーバーは、ユーザーの次のグループ DN を検索します。

dn:CN=dba,CN=Users,dc=example,dc=com
dn:CN=admin,CN=Users,dc=example,dc=com

MongoDB はこれらのグループ DN を admin データベースのロールにマッピングします。最初のグループ DN は最初のロールと一致し、MongoDB は認証されたユーザーにロールと権限を付与します。2 番目のグループ DN はサーバー上のどのロールにも一致しないため、MongoDB は追加の権限を付与しません。

新しいユーザー bob@analytics.example.com は $external データベースに対して認証します。MongoDB サーバーは、クエリ テンプレートで指定されたユーザー名を使用して、クエリ プロセスを繰り返します。この例では、MongoDB サーバーは、ユーザーの次のグループ DN を検索します。

dn:cn=analytics,CN=Users,dc=example,dc=com

MongoDB はこれらのグループ DN を admin データベースのロールにマッピングし、認証されたユーザーに 2 番目のロールのロールと権限を付与します。

新しいユーザー workstation@guest.example.com は $external データベースに対して認証します。MongoDB サーバーは、クエリ テンプレートで指定されたユーザー名を使用して、クエリ プロセスを繰り返します。この例では、MongoDB サーバーは、ユーザーの次のグループ DN を検索します。

dn:cn=guest,CN=Users,dc=example,dc=com

MongoDB はグループを admin データベースのロールにマッピングしますが、一致するロールが存在しないため、ユーザーに追加の権限は付与されません。

戻る

コレクション レベルのアクセス

次へ

監査