Docs Menu
Docs Home
/
MongoDBマニュアル
/ / / /

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

項目一覧

  • 前提条件
  • Considerations
  • 手順
  • テストと検証

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

MongoDB Enterprise はKerberos サービスを使用する認証をサポートしています。 Kerberos は、大規模なクライアント/サーバー システム向けの業界標準の認証プロトコルです。

このチュートリアルでは、Kerberos サーバーを通じて認証を実行し、プラットフォーム ライブラリ経由で Active Directory(AD)サーバーを通じて認可を実行するように MongoDB を構成する方法について説明します。

重要

続行する前に、次の内容について十分に理解してください。

ADの完全な説明は、このチュートリアルの範囲外です。 このチュートリアルは、 ADに関する事前の知識がある を前提としています。

MongoDB は、MongoDB サーバーとADとの間のバインディングに SASL メカニズムを使用することをサポートしています。 SASL、SASL メカニズム、または特定の SASL メカニズムの具体的なAD構成要件の詳細な説明は、このチュートリアルの範囲外です。 このチュートリアルでは、SASL とそれに関連する事柄に関する事前の知識があることを前提としています。

Kerberos 配置の セットアップと構成 については、このドキュメントの範囲外です。 このチュートリアルでは、MongoDBmongos 配置の各mongod } インスタンスと インスタンスに対して Kerberos サービス プリンシパル を構成し、かつmongod }mongos インスタンスと インスタンスごとに の有効な キータブ ファイル があることを前提としています。

レプリカセットとシャーディングされたクラスターの場合は、IP アドレスや修飾されていないホスト名ではなく、構成で完全修飾ドメイン名(FQDN)が使用されていることを確認してください。 Kerberos レルムを正しく解決し、接続できるようにするには、GSSAPI 用の FQDN を使用する必要があります。

MongoDB Enterprise を使用していることを確認するには、 --versionコマンドライン オプションをmongodまたはmongosに渡します。

mongod --version

このコマンドの出力で string modules: subscriptionまたはmodules: enterpriseを探し、MongoDB Enterprise バイナリを使用していることを確認します。

このチュートリアルでは、Kerberos 認証と AD 承認のための MongoDB の構成について説明します。

この手順を独自の MongoDB サーバーで実行するには、独自のインフラストラクチャ、特に Kerberos 構成、 ADクエリの構築、またはユーザーの管理に関して指定された手順を変更する必要があります。

デフォルトでは、MongoDB はMongoDBサーバーにバインドするときに TLS/SSL 接続を作成します。 これには、MongoDB サーバーのホストを、AD サーバーの証明機関(CA)証明書にアクセスできるように構成する必要があります。

このチュートリアルでは、必要なホスト構成に関する手順を説明します。

このチュートリアルでは、AD サーバーの CA 証明書にアクセスし、MongoDB サーバー上に証明書のコピーを作成できることを前提としています。

このチュートリアルでは、提供されたクエリ、構成、および出力の基礎として、次の例のADオブジェクトを使用します。 各オブジェクトには、可能な属性のサブセットのみが表示されます。

dn:CN=bob,CN=Users,DC=marketing,DC=example,DC=com
userPrincipalName: bob@marketing.example.com
memberOf: CN=marketing,CN=Users,DC=example,DC=com
dn:CN=alice,CN=Users,DC=engineering,DC=example,DC=com
userPrincipalName: alice@engineering.example.com
memberOf: CN=web,CN=Users,DC=example,DC=com
memberOf: CN=PrimaryApplication,CN=Users,DC=example,DC=com
dn:CN=sam,CN=Users,DC=dba,DC=example,DC=com
userPrincipalName: sam@dba.example.com
memberOf: CN=dba,CN=Users,DC=example,DC=com
memberOf: CN=PrimaryApplication,CN=Users,DC=example,DC=com
dn:CN=joe,CN=Users,DC=analytics,DC=example,DC=com
userPrincipalName: joe@analytics.example.com
memberof: CN=marketing,CN=Users,DC=example,DC=com
dn:CN=marketing,CN=Users,DC=example,DC=com
member:CN=bob,CN=Users,DC=marketing,DC=example,DC=com
member:CN=joe,CN=Users,DC=analytics,DC=example,DC=com
dn:CN=engineering,CN=Users,DC=example,DC=com
member:CN=web,CN=Users,DC=example,DC=com
member:CN=dba,CN=users,DC=example,DC=com
dn:CN=web,CN=Users,DC=example,DC=com
member:CN=alice,CN=Users,DC=engineering,DC=example,DC=com
dn:CN=dba,CN=Users,DC=example,DC=com
member:CN=sam,CN=Users,DC=dba,DC=example,DC=com
dn:CN=PrimaryApplication,CN=Users,DC=example,DC=com
member:CN=sam,CN=Users,DC=dba,DC=example,DC=com
member:CN=alice,CN=Users,DC=engineering,DC=example,DC=com

このチュートリアルでは、ユーザー名とパスワードを使用して、 ADサーバーでクエリを実行します。 提供された認証情報には、 security.ldap.userToDNMappingまたはsecurity.ldap.authz.queryTemplateに関連するクエリをサポートするために、AD サーバー上で十分な特権が必要です。

MongoDB LDAP 認可では、レプリカセット内のすべてmongodが少なくとも MongoDB 3.4.0 である必要があります。 以降に更新します。

MongoDB LDAP 認可では、シャーディングされたクラスター内のすべてmongodmongosが、少なくとも MongoDB 3.4.0以降である必要があります。

1

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

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

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

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

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

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

警告

transportSecuritynoneに設定すると、ユーザー認証情報を含むプレーンテキスト情報が MongoDB とADサーバー間で送信されます。

2

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

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

たとえば、 mongodがサービスアカウント名mongodb_dev@example.comを使用してmongodbserver.example.commongodbという名前のサービスとして実行する場合、SPN を割り当てるコマンドは次のようになります。

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

注意

Windows Server 2003はsetspn.exe -Sをサポートしていません。 の完全なドキュメントについては、 setspn.exe を参照してくださいsetspn.exe

3

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

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

4

}--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>"

注意

Windows MongoDB 配置の場合、 mongoshmongo.exeに置き換える必要があります

5

ADを使用して MongoDB ユーザーを管理するには、 userAdminuserAdminAnyDatabaseによって提供されるロールを作成および管理できるロールを、 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 ロール、 AD グループ、またはグループ メンバーシップを構成する場合。

6

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

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

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

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

7

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

activedirectory.example.netにあるADサーバーに接続するには、構成ファイルに次の内容を含めます。

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

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

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

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

8

MongoDB 構成ファイルで、 security.authorizationenabledに、 setParameter authenticationMechanismsGSSAPIに設定します

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

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

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

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

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

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

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

注意

RFC4515 の完全な説明 、 RFC4516 、または AD クエリは、このチュートリアルの範囲外です。このチュートリアルで提供されているqueryTemplateは 例のみであり、特定のAD配置には適用されない可能性があります。

次のクエリ テンプレートでは、再帰的なグループ メンバーシップに従って、 {USER}をメンバーとしてリストするすべてのグループが返されます。 この LDAP クエリでは、グループ オブジェクトがmember属性を使用して完全なユーザー識別名(DN)を保存し、ユーザー メンバーシップを追跡することを前提としています。 クエリには、 1.2.840.113556.1.4.1941LDAP_MATCHING_RULE_IN_CHAIN の LDAP 固有の一致ルール OID が含まれています 。この一致するルールは、LDAP 検索フィルターに対するAD固有の拡張機能です。

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

クエリ テンプレートを使用すると、MongoDB は LDAP サーバーをクエリするために、 {USER}を認証されたユーザー名に置き換えます。

たとえば、ユーザーはCN=sam,CN=Users,DC=dba,DC=example,DC=comとして認証します。 MongoDB はqueryTemplateに基づいて LDAP クエリを作成し、 {USER}トークンを認証されたユーザー名に置き換えます。 Active Directory サーバーは、ユーザーを直接または推移的にリストするグループに対して、再帰的なグループ検索を実行します。 Active Directory グループに基づいて、 ADサーバーはCN=dba,CN=Users,DC=example,DC=comCN=engineering,CN=Users,DC=example,DC=comを返します。

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

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

10

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

次のuserToDNMapping構成では、指定されたユーザー名を取得するためにmatch正規表現フィルターを使用します。 MongoDB はクエリを実行する前に、取得されたユーザー名をldapQueryクエリ テンプレートに挿入します。

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

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

ユーザーはalice@ENGINEERING.EXAMPLE.COMとして認証します。 MongoDB は、 userToDNMappingで指定された変換を最初に適用します。 提供された構成に基づいて、MongoDB はmatchステージでユーザー名を取得し、LDAP クエリを実行します。

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

構成されたActive Directory ユーザーに基づいて、 ADサーバーはCN=alice,CN=Users,DC=engineering,DC=example,DC=comを返す必要があります。

次に、MongoDB はqueryTemplateで構成された LDAP クエリを実行し、 {USER}トークンを変換されたユーザー名CN=alice,CN=Users,DC=engineering,DC=example,DC=comに置き換えます。

重要

userToDNMappingsubstitutionの パラメーターを使用してグループ名を変換する場合、置換の結果は RFC4514 である 必要string があります エスケープされた 。

11

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

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

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

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

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

12

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

13

--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>
14

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

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

この手順では、必要な権限を持つadminデータベースのdn:CN=dba,CN=Users,DC=example,DC=comロールを構成しました。 このロールは、 ADグループに対応します。 構成されたAD ユーザーに基づいて、ユーザーsam@dba.example.comとして認証し、必要な権限を受け取ることができます。

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

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

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

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

注意

既存の$external以外のユーザーとして認証する場合は、 --authenticationMechanismを SCRAM 認証メカニズムに設定します(例: SCRAM-SHA-1またはSCRAM-SHA-256 )。 これには、MongoDB サーバーのsetParameter authenticationMechanismsに、必要に応じてSCRAM-SHA-1および/またはSCRAM-SHA-256が含まれている必要があります。

15

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

次の操作では、 ADグループ DN CN=PrimaryApplication,CN=Users,DC=example,DC=comにちなんで命名されたロールが作成され、そのグループに適切なロールと特権が割り当てられます。

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

構成されたActive Directory グループの場合、MongoDB はsam@DBA.EXAMPLE.COMまたはalice@ENGINEERING.EXAMPLE.COMとして認証するユーザーに、 PrimaryApplicationデータベースでreadWriteロールを付与します。

注意

adminデータベースでロールを管理するには、 adminuserAdminを持つユーザー、 userAdminAnyDatabase 、または同等の権限を持つ のカスタムロールとして認証される必要があります。

16

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

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

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

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

次のユーザーが$externalデータベースに存在します。

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

ユーザーがADグループCN=marketing,CN=Users,DC=example,DC=comに属していると仮定すると、次の操作は適切な特権を持つ一致するロールを作成します。

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

構成されたqueryTemplate に基づいて、MongoDB は、CN=marketing,CN=Users,DC=example,DC=com グループの直接または推移的なメンバーシップを持つすべてのユーザーに、read web_analyticsデータベースとPrimaryApplication データベースで 操作を実行することを許可します。

重要

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

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

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

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

この手順では、次の構成ファイルが作成されます。

security:
authorization: "enabled"
ldap:
servers: activedirectory.example.net"
bind:
queryUser: "mongodbadmin@dba.example.com"
queryPassword: "secret123"
userToDNMapping:
'[
{
match: "(.+)"
ldapQuery: "DC=example,DC=com??sub?(userPrincipalName={0})"
}
]'
authz:
queryTemplate: "DC=example,DC=com??sub?(&(objectClass=group)(member:1.2.840.113556.1.4.1941:={USER}))"
setParameter:
authenticationMechanisms: "GSSAPI"

重要

指定されたサンプル構成は、 ADスキーマ、ディレクトリ構造、および構成と一致するように変更する必要があります。 配置には追加の構成ファイル オプションも必要になる場合があります。

ロールと特権の設定の詳細については、以下を参照してください。

構成手順を完了したら、 mongokerberosツールを使用して構成を検証できます。

mongokerberosは、MongoDB で使用するプラットフォームの Kerberos 構成を確認し、MongoDB クライアントからの Kerberos 認証が期待どおりに機能することをテストするのに便利な方法を提供します。 詳しくは、 mongokerberosのドキュメントを参照してください。

mongokerberos は MongoDB Enterprise でのみ利用可能です。

戻る

トラブルシューティング