Kerberos と Active Directory 承認の構成

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

To connect to the AD (AD) server via TLS/SSL, the mongod or mongos require access to the AD server's Certificate Authority (CA) certificate.

On Linux, specify the AD server's CA certificates via the TLS_CACERT or TLS_CACERTDIR option in the ldap.conf file.

プラットフォームのパッケージ マネージャーは、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>"

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

To manage MongoDB users using AD, you need to create at least one role on the admin database that can create and manage roles, such as those provided by userAdmin or userAdminAnyDatabase.

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

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

• Creates a role named for the AD group CN=dba,CN=Users,DC=example,DC=com, and

• 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 を構成します。

In the MongoDB configuration file, set security.ldap.servers to the host and port of the AD server. If your AD infrastructure includes multiple AD servers for the purpose of replication, specify the host and port of the servers as a comma-delimited list to security.ldap.servers.

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

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

Alternatively, you can configure the following settings in the configuration file to bind to the AD server using SASL:

• 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 maps each returned group DN to a role on the admin database. For each mapped group DN, if there is an existing role on the admin database whose name exactly matches the DN, MongoDB grants the user the roles and privileges assigned to that role.

The matching rule LDAP_MATCHING_RULE_IN_CHAIN requires providing the full DN of the authenticating user. Since Kerberos requires authenticating with a user's userPrincipalName, you must transform the incoming usernames into DNs using security.ldap.userToDNMapping. The next step provides guidance on transforming incoming usernames to support the queryTemplate.

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

In the MongoDB configuration file, set userToDNMapping to transform the authenticating user's provided username into an AD DN to support the 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"

On Windows MongoDB servers, you can set security.ldap.bind.useOSDefaults to true to use the credentials of the OS user instead of queryUser and queryPassword.

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.

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

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

For each group on the AD server you wish to use for MongoDB authorization, you must create a matching role on the MongoDB server's admin database.

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に移行します。