Kerberos と Active Directory 承認の構成

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

TLS/SSL を介して AD (AD) サーバーに接続するには、mongod または mongos で AD サーバーの証明書発行者 (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 を無効にします。

（Windows のみ） MongoDB Windows Service にサービスプリンシパル名を割り当てます。

Windows オペレーティング システムで実行されている MongoDB サーバーの場合は、 setspn.exe を使用する必要があります を使用して、MongoDB サービスを実行しているアカウントにサービスプリンシパル名（SPN）を割り当てます。

setspn.exe -S <service>/<fully qualified domain name> <service account name>

setspn.exe -S mongodb/mongodbserver.example.com mongodb_dev@example.com

（Linux のみ） MongoDB サーバーのキータブ ファイルを作成します。

Linux プラットフォームで実行されている MongoDB サーバーの場合、そのサーバー上で実行されている MongoDB インスタンスに固有のキータブ ファイルのコピーがサーバーにあることを確認する必要があります。

MongoDB サービスを実行している Linux ユーザーに、キータブ ファイルに対する読み取り権限を付与する必要があります。 キータブ ファイルの場所の完全なパスをメモします。

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

Connect to the MongoDB server using mongosh using the --host and --port options.

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

If your MongoDB server currently enforces authentication, you must authenticate to the admin database as a user with role management privileges, such as those provided by userAdmin or userAdminAnyDatabase. Include the appropriate --authenticationMechanism for the MongoDB server's configured authentication mechanism.

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

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

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

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

Given the available Active Directory groups,the following operation:

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

security:
  ldap:
    servers: "activedirectory.example.net"

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

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

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

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

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

Kerberos 認証用に MongoDB を構成します。

MongoDB 構成ファイルで、 security.authorizationをenabledに、 setParameter authenticationMechanismsをGSSAPIに設定します

Kerberos 経由の認証を有効にするには、 構成ファイル に以下を含めます。

security:
  authorization: "enabled"
setParameter:
  authenticationMechanisms: "GSSAPI"

認可用の 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データベースのロールにマッピングします。マッピングされたグループ 識別名 ごとに、その名前が 識別名 と完全に一致する既存のロールが admin データベース上にある場合、MongoDB はそのロールに割り当てられたロールと権限をユーザーに付与します。

マッチングルール LDAP_MATCHING_RULE_IN_CHAIN は、認証するユーザーの完全な 識別名 を提供する必要があります。Kerberos はユーザーのuserPrincipalName を使用して認証する必要があるため、受信したユーザー名を を使用して DN security.ldap.userToDNMappingに変換する必要があります。次のステップでは、queryTemplateをサポートするために、受信したユーザー名を変換する方法についてのガイダンスを提供します。

Active Directory 経由の認証用に受信したユーザー名を変換します。

MongoDB 構成ファイルで、`userToDNMapping ` をサポートするために、認証するユーザーが提供したユーザー名を ` AD ` 識別名に変換するように、` `queryTemplate を設定します。

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は、mongod mongosAD サーバーでクエリを実行するための Kerberos ユーザー または バインドを指定します。

• 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 クエリを実行する権限が必要です。

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

構成に必要な追加オプションを含めます。 たとえば、リモート クライアントを使用して配置に接続する場合や、配置ノードを異なるホスト上で実行する場合は、 net.bindIp設定を指定します。

Kerberos 認証と Active Directory 認証を使用して MongoDB サーバーを起動します。

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

Linux MongoDB Servers

Linux では、 KRB5_KTNAME環境変数を指定して、MongoDB サーバーのキータブ ファイルへのパスを指定する必要があります。

env KRB5_KTNAME <path-to-keytab> mongod --config <path-to-config-file>

Microsoft Windows MongoDB Servers

Windows では、手順の前半で構成されたように、MongoDB サーバーをサービスプリンシパル アカウントとして起動する必要があります。

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

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

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

Use mongosh to authenticate to the MongoDB server, set the following options:

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

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

• --username ユーザーの userPrincipalName

• --password to the user's password (or omit to have mongosh prompt for the password)

• --authenticationMechanism 次の行動をします: "GSSAPI"

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

mongosh --username sam@DBA.EXAMPLE.COM --password  --authenticationMechanisms="GSSAPI" --authenticationDatabase "$external" --host <hostname> --port <port>

Windows MongoDB deployments must use mongo.exe instead of mongosh.

Given the configured Active Directory users, the user authenticates successfully and receives the appropriate permissions.

返された 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 Active Directoryサーバーに移行します。

$external データベースでユーザーが構成された既存のインストールをアップグレードする場合、Kerberos 認証と 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: "GSSAPI,SCRAM-SHA-1,SCRAM-SHA-256"

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