Kerberos 認証と Active Directory 認証を使用した自己管理型 MongoDB の構成
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 バイナリを使用していることを確認します。
Considerations
このチュートリアルでは、Kerberos 認証と AD 承認のための MongoDB の構成について説明します。
この手順を独自の MongoDB サーバーで実行するには、独自のインフラストラクチャ、特に Kerberos 構成、 ADクエリの構築、またはユーザーの管理に関して指定された手順を変更する必要があります。
トランスポート層のセキュリティ
デフォルトでは、MongoDB はMongoDBサーバーにバインドするときに TLS/SSL 接続を作成します。 これには、MongoDB サーバーのホストを、AD サーバーの証明機関(CA)証明書にアクセスできるように構成する必要があります。
このチュートリアルでは、必要なホスト構成に関する手順を説明します。
このチュートリアルでは、AD サーバーの CA 証明書にアクセスし、MongoDB サーバー上に証明書のコピーを作成できることを前提としています。
Active Directory スキーマの例
このチュートリアルでは、提供されたクエリ、構成、および出力の基礎として、次の例の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
Active Directory の認証情報
このチュートリアルでは、ユーザー名とパスワードを使用して、 ADサーバーでクエリを実行します。 提供された認証情報には、 security.ldap.userToDNMapping
またはsecurity.ldap.authz.queryTemplate
に関連するクエリをサポートするために、AD サーバー上で十分な特権が必要です。
レプリカセット
MongoDB LDAP 認可では、レプリカセット内のすべてのmongod
が少なくとも MongoDB 3.4.0 である必要があります。 以降に更新します。
シャーディングされたクラスター
MongoDB LDAP 認可では、シャーディングされたクラスター内のすべてのmongod
とmongos
が、少なくとも MongoDB 3.4.0以降である必要があります。
手順
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 を無効にします。
警告
transportSecurity
をnone
に設定すると、ユーザー認証情報を含むプレーンテキスト情報が MongoDB とADサーバー間で送信されます。
(Windows のみ) MongoDB Windows Service にサービスプリンシパル名を割り当てます。
Windows オペレーティング システムで実行されている MongoDB サーバーの場合は、 setspn.exe を使用する必要があります を使用して、MongoDB サービスを実行しているアカウントにサービスプリンシパル名(SPN)を割り当てます。
setspn.exe -S <service>/<fully qualified domain name> <service account name>
例
たとえば、 mongod
がサービスアカウント名mongodb_dev@example.com
を使用してmongodbserver.example.com
でmongodb
という名前のサービスとして実行する場合、SPN を割り当てるコマンドは次のようになります。
setspn.exe -S mongodb/mongodbserver.example.com mongodb_dev@example.com
注意
Windows Server 2003はsetspn.exe -S
をサポートしていません。 の完全なドキュメントについては、 setspn.exe を参照してくださいsetspn.exe
。
(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 ロール、 AD グループ、またはグループ メンバーシップを構成する場合。
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
に指定します。
例
activedirectory.example.net
にあるADサーバーに接続するには、構成ファイルに次の内容を含めます。
security: ldap: servers: "activedirectory.example.net"
MongoDB は、クエリを実行するには、 ADサーバーにバインドする必要があります。 デフォルトでは、MongoDB は単純な認証メカニズムを使用してMongoDBサーバーに自分自身をバインドします。
または、構成ファイルで次の設定を構成し、 SASL
を使用してMongoDBサーバーにバインドすることもできます。
security.ldap.bind.method
をsasl
に設定は、 AD サーバーがサポートするカンマ区切りの SASL
security.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 クエリに置き換えるためのプレースホルダー。
ユーザーのグループを取得するためのクエリ テンプレートを設計します。
注意
RFC4515 の完全な説明 、 RFC4516 、または AD クエリは、このチュートリアルの範囲外です。このチュートリアルで提供されているqueryTemplate
は 例のみであり、特定のAD配置には適用されない可能性があります。
例
次のクエリ テンプレートでは、再帰的なグループ メンバーシップに従って、 {USER}
をメンバーとしてリストするすべてのグループが返されます。 この LDAP クエリでは、グループ オブジェクトがmember
属性を使用して完全なユーザー識別名(DN)を保存し、ユーザー メンバーシップを追跡することを前提としています。 クエリには、 1.2.840.113556.1.4.1941
LDAP_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=com
とCN=engineering,CN=Users,DC=example,DC=com
を返します。
MongoDB は返された各グループDNをadmin
データベースのロールにマッピングします。 マッピングされたグループDNごとに、名前がDNと完全に一致する既存のロールがadmin
データベースに存在する場合、MongoDB はそのロールに割り当てられたロールと特権をユーザーに付与します。
一致ルールLDAP_MATCHING_RULE_IN_CHAIN
には、認証ユーザーの完全なDNを指定する必要があります。 Kerberos ではユーザーのuserPrincipalName
による認証が必要になるため、 を使用して受信したユーザー名を DN security.ldap.userToDNMapping
に変換する必要があります。次のステップでは、 queryTemplate
をサポートするように受信したユーザー名を変換するためのガイダンスを提供します。
Active Directory 経由の認証用に受信したユーザー名を変換します。
MongoDB 構成ファイルで、userToDNMapping
queryTemplate
を に設定して、認証ユーザーの指定されたユーザー名を、 をサポートするように 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
に置き換えます。
重要
userToDNMapping
substitution
の パラメーターを使用してグループ名を変換する場合、置換の結果は RFC4514 である 必要string があります エスケープされた 。
クエリ認証情報を構成します。
MongoDB では、 ADサーバーでクエリを実行するために認証情報が必要です。
構成ファイル で次の設定を構成します。
security.ldap.bind.queryUser
は、mongod
mongos
AD サーバーでクエリを実行するための 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"
例
この手順では、必要な権限を持つ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>
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
が含まれている必要があります。
返された AD グループをマッピングするためのロールを作成します。
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
データベースでロールを管理するには、 admin
のuserAdmin
を持つユーザー、 userAdminAnyDatabase
、または同等の権限を持つ のカスタムロールとして認証される必要があります。
オプション: 既存のユーザーを から$external
Active Directoryサーバーに移行します。
$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 でのみ利用可能です。