Microsoft Entra ID ドメイン サービスを使用したユーザー認証と承認の構成

ドメイン用に Microsoft Entra ID ドメイン サービスを構成します。

Microsoft Entra ID ドメイン サービスを構成するには、次の手順に従ってください: Azure ドキュメントにあるCustom domain names DNS 名オプションを使用するチュートリアルを参照してください。

マネージド ドメインを構成するときは、 DNS domain nameフィールドに入力する値を必ずメモしておきます。 この値が<managed-domain>です。 このチュートリアルの複数の場所で指定する必要があります。

安全な LDAP の SSL 証明書を取得します。

Microsoft Entra ID ドメイン サービスは SSL 証明書を使用して LDAP を保護します。 証明書は、 Azure ドキュメントに記載されている要件に準拠している必要があります。

証明書を取得するには、次のいずれかを行います。

• 組織が使用する公開認証局またはエンタープライズ認証局 (CA) から 1 つを取得します。

  • 安全な LDAP が Microsoft Entra ID ドメイン サービスで正しく動作するようにするには、ワイルドカード証明書を取得する必要があります。

  • 証明書のサブジェクト名は、Microsoft Entra ID ドメイン サービスの構成時に使用した<managed-domain>と一致する必要があります。

    例

    *.aadds.example.com

• 自己署名証明書を生成します。 自己署名証明書は本番環境には推奨されません。

テスト 目的で MacOS または Linux システムで自己署名証明書を生成するには、次の手順に従います。

brew install openssl

1. opensslを使用して秘密キーを生成します。 次のコマンドは、 <your-key-name>.keyという名前の秘密キーファイルを生成します。

   openssl genrsa -out <your-key-name>.key 2048

2. 次の構成ファイルのテンプレートを編集します。 組織に関連する値で、 [dn-param]セクションの属性を更新します。 サブジェクト名（ CN ）が次のテンプレートと一致していることを確認します。 *.<managed-domain>

   例

   *.aadds.example.com

   # openssl x509 extfile params
   extensions = extend
   [req] # openssl req params
   prompt = no
   distinguished_name = dn-param
   [dn-param] # DN fields
   C = US
   ST = NY
   L  = New York
   O = MongoDB
   OU = Atlas
   CN = *.aadds.example.com
   [extend] # openssl extensions
   subjectKeyIdentifier = hash
   authorityKeyIdentifier = keyid:always
   keyUsage = digitalSignature,keyEncipherment,keyCertSign
   extendedKeyUsage=serverAuth,clientAuth

3. ファイルを<your-config-name>.cfgとして保存します。

4. 作成したキーと構成ファイルを使用して、証明書署名リクエストを生成します。 次のコマンドは、 <your-csr-name>.csrという名前の証明書署名リクエストを生成します。

   openssl req -new -key <your-key-name>.key \
   -out <your-csr-name>.csr -config <your-config-name>.cfg \
   -extensions extend

5. 作成したキー、構成、および証明書署名リクエスト ファイルを使用して、 自己署名証明書 を生成します。 次のコマンドは、 <your-cert-name>.crtという名前の自己署名証明書ファイルを生成します。

   openssl x509 -req -sha256 -days 365 -in <your-csr-name>.csr \
   -signkey <your-key-name>.key -out <your-cert-name>.crt \
   -extfile <your-config-name>.cfg

テスト目的 で Windows システム上で自己署名証明書を生成する方法について詳しくは、 Azure のドキュメント を参照してください。

秘密キーを含む SSL 証明書を取得します。

Microsoft Entra ID ドメイン サービスは秘密キーを使用して安全な LDAP トラフィックを復号化します。 秘密キーを含む証明書はPKCS#12形式を使用し、 .pfxファイル形式を使用します。 パブリック インターネット経由で送信された安全な LDAP トラフィックを復号化するには、この形式の証明書を Microsoft Entra ID ドメイン サービスにアップロードする必要があります。

MacOS または Linux システムで.pfx証明書を生成するには:

1. 公開鍵と SSL 証明書をローカル マシンに保存します。

   注意

   証明書にはPEM形式を使用する必要があります。

   証明書に秘密キーが含まれていない場合は、秘密キーを.key形式ファイルに保存できます。

2. 秘密キーとopenssl証明書を使用して.pfx証明書を生成します。 次のコマンドは、 <your-cert-name>.pfxという名前の.pfx証明書ファイルを生成します。

   openssl pkcs12 -export -out <your-cert-name>.pfx \
   -inkey <your-key-name>.key -in <your-cert-name>.crt

   プロンプトが表示されたら、ファイルを暗号化するためのパスワードを入力して確認します。 このパスワードは、 .pfx証明書を Microsoft Entra ID ドメイン サービスにアップロードするときに、秘密キーを復号化するために入力します。

.pfxWindows システム上で 証明書を生成する方法について詳しくは、 Azure のドキュメント を参照してください。

Microsoft Entra ID ドメイン サービスで安全な LDAP を有効にします。

Microsoft Entra ID ドメイン サービスで安全な LDAP を有効にするには、 Azure のドキュメントを参照してください。

DNS プロバイダーを設定します。

Atlas とデータベース ノードが Microsoft Entra ID Domain Services が管理するカスタム ドメイン内の LDAP サーバーに接続できるように DNS プロバイダーを構成する必要があります。

<managed-domain>のサブドメインを Microsoft Entra ID Domain Services LDAP サービスが使用する外部 IP アドレスに解決する LDAP トラフィックのホスト レコードを作成します。

Microsoft Entra ID Domain Services LDAP サービスが使用する外部 IP アドレスを見つけるには、 Azure のドキュメントを参照してください。

カスタム ドメインの Microsoft Entra ID への追加

カスタム ドメイン名を Microsoft Entra ID に追加して、追加したドメインに属するユーザーを作成します。ドメインを追加したら、TXT レコードでお使いの DNS プロバイダーに Microsoft Entra ID の DNS 情報を追加して、構成を確認します。

カスタム ドメインの Microsoft Entra ID への追加方法について詳しくは、 Azure のドキュメント を参照してください。

インバウンド LDAP トラフィック用に Microsoft Entra ID ドメイン サービスを構成します。

Microsoft Entra ID ドメイン サービスを Atlas の LDAP プロバイダーとして使用するには、パブリック インターネットからポート636へのすべてのポート経由のすべてのトラフィックを許可する必要があります。

ポート でインバウンド LDAP トラフィックを許可するインバウンド セキュリティ636 ルールを追加する方法について詳しくは、 Azure のドキュメント を参照してください。

バインド ユーザーを作成します。

バインド ユーザーを作成します。 バインド ユーザーは 、Atlas データベースに接続するときにデータベースユーザーの認証情報を認証するために使用する Microsoft Entra ID ユーザーです。 バインド ユーザーは、Microsoft Entra ID に追加したカスタム ドメインに属している必要があります。

Microsoft Entra ID ユーザーを作成する方法について詳しくは、 Azure のドキュメント を参照してください。

Microsoft Entra ID ドメイン サービスのバインド ユーザー アカウントを有効にします。

バインド ユーザーが Microsoft Entra ID ドメイン サービスを使用する前に、Kerberos および NTM 認証用のバインド ユーザーのパスワード ハッシュを生成する必要があります。 手順は、Microsoft Entra ID ユーザー アカウントの種類によって異なります。

ユーザーのパスワード ハッシュを生成する方法については、 Azure のドキュメントを参照してください。

バインド ユーザー アカウントにディレクトリ読み取りロールを割り当てます。

Microsoft Entra ID をクエリするには、バインド ユーザーは ディレクトリ リーダー によって付与される権限を持っている必要があります。 のロール。

バインド ユーザーにディレクトリ読み取りロールを割り当てる方法について詳しくは、 Azure のドキュメント を参照してください。

Microsoft Entra ID ユーザーの作成

ユーザがまだ存在しない場合は、Microsoft Entra ID ドメイン サービスでデータベース アクセスを許可するユーザーを作成します。 ユーザーは、Microsoft Entra ID に追加したカスタム ドメインに属している必要があります。

Microsoft Entra ID ユーザーを作成する方法について詳しくは、 Azure のドキュメント を参照してください。

AtlasGoAdvancedAtlas で、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。

3. サイドバーで、 Security見出しの下のAdvancedをクリックします。

   詳細ページが表示されます。

LDAP Authentication の横にあるボタンを On に切り替えます。

パネルに、すべての LDAP Configure Your LDAP Server サーバーのサーバー詳細とバインド認証情報を入力します。

複数のサーバーをカンマで区切って一覧表示できます。 異なるポートは使用できません。

DN マッピングにユーザーを追加する。

次の例のようなユーザーと DN のマッピングを追加して、クライアントが Atlas データベースに接続するときに完全な DN の代わりにユーザー名を提供できるようにします。

[
  {
      "match":"(.+)",
      "substitution":"CN={0},OU=AADDC Users,DC=<managed-domain>,DC=com"
  }
]

<managed-domain>が 1 つ以上のサブドメインで構成されている場合は、それぞれの識別名にDC （domainComponent）属性を追加する必要があります。

CA Root Certificate フィールドに、LDAP サーバー用の認証局（CA）から発行された証明書をカンマ区切りで入力します。

自己署名証明書を提供できます。

[Verify and Save] をクリックします。

Atlas が変更を配置するまで待ちます。 Atlas は、提供した構成の詳細を使用して、クラスターが LDAP サーバーに接続、認証、クエリを実行できることを確認します。

AtlasGoDatabase AccessAtlas で、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。

3. サイドバーで、 Security見出しの下のDatabase Accessをクリックします。

   [データベース アクセス ]ページが表示されます。

Atlas に LDAP ユーザーを追加します。

Azure ADで管理されているユーザーを Atlas に追加します。

1. Add New Database User をクリックします。

2. [LDAP User] をクリックします。

3. 次のいずれかを実行します。

   1. User to DN Mappingを入力していない場合は、 LDAPユーザーの完全な DN を入力します。 このテンプレートに従います。

      CN=<user-name>,OU=AADDC Users,DC=<managed>,DC=<domain>,DC=com

      たとえば、 <user-name>がJane Doeで、 <managed-domain>がaadds.example.comの場合、ユーザーの DN は次のようになります。

      CN=Jane Doe,ou=AADDC Users,DC=aadds,DC=example,DC=com

   2. User to DN Mappingを入力した場合は、マッピングに必要なユーザー名を入力します。

4. ユーザーに付与するデータベースアクセスレベルを選択します。

5. [Add User] をクリックします。

AtlasGoDatabase AccessAtlas で、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。

3. サイドバーで、 Security見出しの下のDatabase Accessをクリックします。

   [データベース アクセス ]ページが表示されます。

データベース アクセス LDAP グループを Atlas に追加します。

作成した各 Azure データベース グループを Atlas に追加します。 追加したグループのノードには、グループに付与されたデータベースアクションを実行する権限が付与されます。

1. Add New Database User をクリックします。

1. [ LDAP Groupをクリックし、 User to DN Mappingを有効にした場合でも、データベースユーザーを含むグループの完全な DN を入力します。 このテンプレートに従います。

   CN=<group-name>,OU=AADDC Users,DC=<managed-domain>,DC=com

   注意

   Microsoft Entra ID ドメイン サービスの場合、識別名の属性は大文字である必要があります。

   <managed-domain>が 1 つ以上のサブドメインで構成されている場合は、それぞれの識別名にDC （domainComponent）属性を追加する必要があります。

   例

   <managed-domain>がaadds.example.comの場合、ドメイン コンポーネントは次のようになります。

   DC=aadds,DC=example,DC=com

   たとえば、 <group-name>がAtlas read onlyで、 <managed-domain>がaadds.example.comの場合、ユーザーの DN は次のようになります。

   CN=Atlas read only,OU=AADDC Users,DC=aadds,DC=example,DC=com

1. このグループ内のユーザーに付与するデータベース アクセス レベルを選択します。

2. [Add User] をクリックします。

AtlasGoAdvancedAtlas で、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、プロジェクトを含む組織をナビゲーション バーの Organizations メニューで選択します。

2. まだ表示されていない場合は、ナビゲーション バーの Projects メニューからプロジェクトを選択します。

3. サイドバーで、 Security見出しの下のAdvancedをクリックします。

   詳細ページが表示されます。

LDAP Authorization の横にあるボタンを On に切り替えます。

Configure Your LDAP Server パネルで、LDAP サーバーのサーバー詳細とバインド認証情報が正しいことを確認します。

クエリ テンプレートを Query Template に入力します。

ユーザーがアクションを実行しようとすると、Atlas はLDAP クエリ テンプレートを実行して、認証されたユーザーが属する LDAP グループを取得します。 Atlas では、アクションの実行が許可されているグループが少なくとも 1 つクエリで返される場合、アクションは許可されます。 クエリがアクションを実行する権限を持つグループを返さない場合、Atlas ではアクションは許可されません。

Atlas はクエリを実行するときに、 {USER}プレースホルダー内の認証されたユーザー名を置き換えます。 クエリは、 Server Hostnameで指定されたホストに対して相対的です。

クエリの形式は RFC4515 に準拠する必要があります。

ユーザーがメンバーであるグループを識別する場合は、デフォルトのQuery Templateを使用できます。

{USER}?memberOf?base

[Verify and Save] をクリックします。

Atlas が変更を配置するまで待ちます。 Atlas は、提供された構成の詳細を使用して、クラスターが LDAP サーバーに接続、認証、クエリを実行できることを確認します。

AtlasGoClustersAtlas で、プロジェクトの ページにGoします。

1. まだ表示されていない場合は、希望するプロジェクトを含む組織を選択しますナビゲーション バーのOrganizationsメニュー

2. まだ表示されていない場合は、ナビゲーション バーのProjectsメニューから目的のプロジェクトを選択します。

3. まだ表示されていない場合は、サイドバーの [Clusters] をクリックします。

   [ Clusters （クラスター） ] ページが表示されます。

mongosh を使用して、Atlas に追加したユーザー認証情報でクラスターに接続します。

接続文字列をコピーする方法は、次のとおりです。

1. [Connect] をクリックします。

2. [ LDAPをクリックし、 Copyをクリックします。

3. ユーザー DN とパスワードを含む string を貼り付けて編集します。

<managed-domain>が 1 つ以上のサブドメインで構成されている場合は、それぞれの識別名にDC （domainComponent）属性を追加する必要があります。

ユーザーまたはユーザーの完全な DN 内のグループ名内のエスケープ スペース。

--username CN=Jane\ Doe,OU=AADDC\ Users,DC=aadds,DC=example,DC=com

クラスターに接続した後、コマンドを実行して、割り当てた読み取りまたは書込み特権がユーザーにあることを確認します。