ネイティブ LDAP による自己管理型 Active Directory を使用したユーザーの認証と承認

MongoDB を実行しているサーバーの TLS/SSL を構成する

TLS/SSL 経由でAD （AD）サーバーに接続するには、 mongodまたはmongosがADDサーバーの証明機関（CA）証明書にアクセスする必要があります。

Linux では、 ldap.confファイルのTLS_CACERTまたはTLS_CACERTDIRオプションを使用して、 ADサーバーの CA 証明書を指定します。

プラットフォームのパッケージ マネージャーは、MongoDB Enterprise のlibldap依存関係をインストール中にldap.confファイルを作成します。 構成ファイルまたは参照されるオプションに関する完全なドキュメントについては、 ldap.conf を参照してください 。

Microsoft Windows では、プラットフォームの認証情報管理ツールを使用して、 ADサーバーの証明機関（CA）証明書をロードします。 具体的には、 Windowsのバージョンによって異なります。 ツールを使用するには、ご使用のWindowsバージョン向けのドキュメントを参照してください。

mongodまたはmongosがAD CA ファイルにアクセスできない場合、Active Directory サーバーへの TLS/SSL 接続を作成できません。

オプションとして、 security.ldap.transportSecurityをnoneに設定して、TLS/SSL を無効にします。

MongoDB サーバーに接続します。

}--port オプションと オプションを使用してmongosh --hostを使用して MongoDB サーバーに接続します。

mongosh --host <hostname> --port <port>

MongoDB サーバーが現在認証を強制している場合は、 userAdminまたはuserAdminAnyDatabaseによって提供されるロール管理特権を持つユーザーとして、 adminデータベースで認証を受ける必要があります。 MongoDB サーバーの設定された認証メカニズムに適した--authenticationMechanismを含めます。

mongosh --host <hostname> --port <port> --username <user> --password <pass> --authenticationDatabase="admin" --authenticationMechanism="<mechanism>"

ユーザー管理ロールを作成します。

ADを使用して MongoDB ユーザーを管理するには、 userAdminやuserAdminAnyDatabaseによって提供されるロールを作成および管理できるロールを、 adminデータベースに少なくとも 1 つ作成する必要があります。

ロールの名前は、 ADグループの識別名と完全に一致する必要があります。 グループには、ノードとして少なくとも 1 人のADユーザーが必要です。

使用可能なActive Directory グループがある場合、次の操作は実行されます。

• ADグループCN=dba,CN=Users,DC=example,DC=comに対して という名前のロールを作成し、

• adminデータベースのuserAdminAnyDatabaseロールを割り当てます。

var admin = db.getSiblingDB("admin")
admin.createRole(
   {
     role: "CN=dba,CN=Users,DC=example,DC=com",
     privileges: [],
     roles: [ "userAdminAnyDatabase" ]
   }
)

あるいは、ユーザーがユーザー管理特権を付与する必要があるデータベースごとにuserAdminロールを付与することもできます。 これらのロールは、ロールの作成と管理に必要な特権を提供します。

MongoDB の構成ファイルを作成します。

MongoDB構成ファイルは、 .confファイル拡張子を持つプレーンテキストの YAML ファイルです。

• 既存の MongoDB デプロイをアップグレードする場合は、現在の構成ファイルをコピーし、そのコピーから作業します。

• （Linux のみ） これが新しい配置で、プラットフォームのパッケージ マネージャーを使用して MongoDB Enterprise をインストールした場合、インストールには/etc/mongod.confのデフォルト構成ファイルが含まれます。 そのデフォルトの構成ファイルを使用するか、そのファイルのコピーを使用して操作します。

• そのようなファイルが存在しない場合は、 .conf拡張子を持つ空のファイルを作成し、その新しい構成ファイルを操作します。

Active Directory に接続するように MongoDB を構成します。

MongoDB 構成ファイルで、security.ldap.servers AD サーバーのホストとポートに設定します。MongoDBインフラストラクチャにレプリケーション目的で複数のMongoDBサーバーが含まれている場合は、サーバーのホストとポートをカンマ区切りのリストとしてsecurity.ldap.serversに指定します。

また、 security.authorizationをenabledに、 setParameter authenticationMechanismsをPLAINに設定して、LDAP 認証を有効にする必要があります。

security:
  authorization: "enabled"
  ldap:
    servers: "activedirectory.example.net"
setParameter:
  authenticationMechanisms: 'PLAIN'

MongoDB は、クエリを実行するには、 ADサーバーにバインドする必要があります。 デフォルトでは、MongoDB は単純な認証メカニズムを使用してMongoDBサーバーに自分自身をバインドします。

または、構成ファイルで次の設定を構成し、 SASLを使用してMongoDBサーバーにバインドすることもできます。

• security.ldap.bind.methodをsaslに設定

• は、 AD サーバーがサポートするカンマ区切りの SASLsecurity.ldap.bind.saslMechanisms メカニズムの を指定します。string

このチュートリアルでは、デフォルトのsimple LDAP 認証メカニズムを使用します。

認可用の LDAP クエリ テンプレートを構成します。

MongoDB 構成ファイルで、 をsecurity.ldap.authz.queryTemplate RFC4516 に設定 形式の LDAP クエリ URL テンプレート。

テンプレートでは、次のいずれかを使用できます。

• {USER} プレースホルダーを使用して、認証されたユーザー名を LDAP クエリ URL に置き換えます。

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

security:
  ldap:
    authz:
      queryTemplate:
        "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"

MongoDB は返された各グループDNをadminデータベースのロールにマッピングします。 マッピングされたグループDNごとに、名前がDNと完全に一致する既存のロールがadminデータベースに存在する場合、MongoDB はそのロールに割り当てられたロールと特権をユーザーに付与します。

一致ルールLDAP_MATCHING_RULE_IN_CHAINには、認証ユーザーの完全なDNを指定する必要があります。 ユーザーがuser principal name などの異なるユーザー名形式を使用して認証する場合は、 を使用して受信ユーザー名を DN security.ldap.userToDNMappingに変換する必要があります。

オプション: Active Directory 経由の認証用に受信したユーザー名を変換する

ユーザーが完全な LDAP DN ではないユーザー名で認証される場合は、LDAP 認証または認可をサポートするためにユーザー名を変換する必要がある場合があります。 MongoDB は、認証と認可の両方に変換されたユーザー名を使用します。

MongoDB 構成ファイルで、userToDNMappingqueryTemplate を に設定して、認証ユーザーの指定されたユーザー名を、 をサポートするように AD DN に変換します。

security:
  ldap:
    userToDNMapping:
      '[
         {
            match : "(.+)",
            ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
         }
    ]'

指定されたサンプル構成を、配置に合わせて変更する必要があります。 たとえば、 ldapQueryのベースDNは、ユーザー エンティティを含むベースDNと一致する必要があります。 AD配置をサポートするには、他の変更が必要になる場合があります。

DC=example,DC=com??sub?(userPrincipalName=alice@ENGINEERING.EXAMPLE.COM)

クエリ認証情報を構成します。

MongoDB では、 ADサーバーでクエリを実行するために認証情報が必要です。

構成ファイル で次の設定を構成します。

• security.ldap.bind.queryUserは、 ADサーバーでクエリを実行するための Active Directory ユーザー としてmongodまたはmongosバインドを指定します。

• security.ldap.bind.queryPasswordは、指定されたqueryUserのパスワードを指定します。

security:
  ldap:
    bind:
      queryUser: "mongodbadmin@dba.example.com"
      queryPassword: "secret123"

Windows MongoDB サーバーでは、 security.ldap.bind.useOSDefaultsをtrueに設定すると、 queryUserとqueryPasswordの代わりにOSユーザーの認証情報を使用できます。

queryUserには、MongoDB に代わってすべての LDAP クエリを実行する権限が必要です。

任意: 追加の構成設定を追加します。

配置に必要な追加の構成オプションを追加します。 たとえば、任意のstorage.dbPathを指定するか、デフォルトのnet.port数値を変更できます。

mongodとmongosは、デフォルトで localhost にバインドされます。 配置のノードが異なるホスト上で実行されている場合、またはリモート クライアントを配置に接続する場合は、 net.bindIp設定を指定する必要があります。

Active Directory 認証と認可で MongoDB サーバーを起動します。

--configオプションを使用して MongoDB サーバーを起動し、この手順中に作成された構成ファイルへのパスを指定します。 MongoDB サーバーが現在実行中の場合は、適切な準備をしてサーバーを停止します。

mongod --config <path-to-config-file>

Windows MongoDB 配置では、 mongod ではなくmongod.exeを使用する必要があります

MongoDB サーバーに接続します。

MongoDB サーバーに接続し、 userAdmin 、 userAdminAnyDatabase 、または同等の権限を持つカスタムロールを持つadminデータベースの MongoDB ロールに対応する直接または推移的なグループ メンバーシップを持つユーザーとして認証します。

mongoshを使用して MongoDB サーバーに認証し、次のオプションを設定します。

• --host で、MongoDB サーバーのホスト名が

• --port と MongoDB サーバーのポート

• --username にユーザーのユーザー名を設定

• --password にユーザーのパスワードを設定

• --authenticationMechanism 次の行動をします: 'PLAIN'

• --authenticationDatabase 次の行動をします: '$external'

mongosh --username sam@DBA.EXAMPLE.COM --password  --authenticationMechanism 'PLAIN' --authenticationDatabase '$external' --host <hostname> --port <port>

Windows MongoDB 配置では、 mongosh ではなくmongo.exeを使用する必要があります

構成されたActive Directory ユーザーの場合、ユーザーは正常に認証され、適切な権限を受け取ります。

返された AD グループをマッピングするためのロールを作成します。

MongoDB 認証に使用するADサーバー上のグループごとに、MongoDB サーバーのadminデータベースに一致するロールを作成する必要があります。

db.getSiblingDB("admin").createRole(
   {
     role: "CN=PrimaryApplication,CN=Users,DC=example,DC=com",
     privileges: [],
     roles: [
       { role: "readWrite", db: "PrimaryApplication" }
     ]
   }
)

既存のユーザーを から$external ActiveDirectoryサーバーに移行する

$externalデータベースで構成されたユーザーを使用して既存のインストールをアップグレードする場合は、 AD認証および認可用に MongoDB を構成した後にアクセスを確保するために、各ユーザーに対して次の要件を満たす必要があります。

• ユーザーは、 ADサーバー上に対応するユーザー オブジェクトがあります。

• ユーザーは、 ADサーバー上の適切なグループのメンバーシップを持っています。

• MongoDB には、認可されたユーザーが特権を保持するように、ユーザーのADグループに対して という名前のadminデータベース上のロールが含まれています。

{
  user : "joe@ANALYTICS.EXAMPLE.COM",
  roles: [
    { role : "read", db : "web_analytics" },
    { role : "read", db : "PrimaryApplication" }
  ]
}

db.getSiblingDB("admin").createRole(
   {
     role: "CN=marketing,CN=Users,DC=example,DC=com",
     privileges: [],
     roles: [
       { role: "read", db: "web_analytics" }
       { role: "read", db: "PrimaryApplication" }
     ]
   }
)

$external以外のデータベースのユーザーによる MongoDB へのアクセスを引き続き許可する場合は、SCRAM 認証メカニズム（例: { setParameter authenticationMechanisms構成オプションのSCRAM-SHA-1および/またはSCRAM-SHA-256 ）。 例:

setParameter:
  authenticationMechanisms: "PLAIN,SCRAM-SHA-1,SCRAM-SHA-256"

または、上記の手順に従って、 $external以外のユーザーをADDに移行します。