Kerberos と Active Directory 認証を使用した自己管理型MongoDB の構成

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 を無効にします。

（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 サーバーに接続します。

}--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:
  ldap:
    servers: "activedirectory.example.net"

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

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

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

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

このチュートリアルでは、デフォルトの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データベースのロールにマッピングします。 マッピングされたグループDNごとに、名前がDNと完全に一致する既存のロールがadminデータベースに存在する場合、MongoDB はそのロールに割り当てられたロールと特権をユーザーに付与します。

一致ルールLDAP_MATCHING_RULE_IN_CHAINには、認証ユーザーの完全なDNを指定する必要があります。 Kerberos ではユーザーのuserPrincipalName による認証が必要になるため、 を使用して受信したユーザー名を DN security.ldap.userToDNMappingに変換する必要があります。次のステップでは、 queryTemplateをサポートするように受信したユーザー名を変換するためのガイダンスを提供します。

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

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は、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 ロールに対応する直接または推移的なグループ メンバーシップを持つユーザーとして認証します。

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

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

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

• --username ユーザーの userPrincipalName

• --passwordにユーザーのパスワードを入力します（または省略すると、 mongoshはパスワードの入力を要求します）

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

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

mongosh --username sam@DBA.EXAMPLE.COM --password  --authenticationMechanisms="GSSAPI" --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 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に移行します。