ユーザーを SQL データベースにプロビジョニングするための Microsoft Entra ID の構成

このドキュメントでは、ユーザーを Microsoft Entra ID から SQL データベースに自動的にプロビジョニングおよびプロビジョニング解除するために実行する必要がある手順について説明します。

このサービスが実行する内容、しくみ、よく寄せられる質問の重要な詳細については、Microsoft Entra ID による SaaS アプリへのユーザー プロビジョニングとプロビジョニング解除の自動化およびオンプレミス アプリケーション プロビジョニング アーキテクチャに関する記事を確認してください。

次のビデオでは、オンプレミス プロビジョニングの概要を紹介しています。

SQL Database にプロビジョニングするための前提条件

オンプレミスの前提条件

アプリケーションは SQL データベースに依存します。このデータベースでは、ユーザーのレコードを作成、更新、および削除できます。 プロビジョニング エージェントを実行するコンピューターには、次のものが必要です。

• Windows Server 2016 以降のバージョン。
• ターゲット データベース システムへの接続、および login.microsoftonline.com、その他の Microsoft Online Services、Azure ドメインへの送信接続。 1 つの例は、Azure IaaS でホストされているか、またはプロキシの背後にある Windows Server 2016 仮想マシンです。
• 少なくとも 3 GB の RAM。
• .NET Framework 4.7.2。
• SQL データベース用の ODBC ドライバー。

アプリケーションのデータベースへの接続の構成は、ウィザードを使用して行います。 選択するオプションによっては、ウィザードの一部の画面を使用できない場合があり、情報も多少異なる可能性があります。 次の情報を使用して構成を進めます。

サポートされるデータベース

• Microsoft SQL Server と Azure SQL
• IBM DB2 9.x
• IBM DB2 10.x
• IBM DB2 11.5
• Oracle 10g および 11g
• Oracle 12c および 18c
• MySQL 5.x
• MySQL 8.x
• Postgres

クラウドの要件

• Microsoft Entra ID P1 あるいは Premium P2 (または EMS E3 または E5) を使用する、Microsoft Entra テナント。

  この機能を使用するには、Microsoft Entra ID P1 ライセンスが必要です。 自分の要件に適したライセンスを探すには、「一般提供されている Microsoft Entra ID の機能の比較」を参照してください。

• プロビジョニング エージェントを構成するためのハイブリッド ID 管理者ロールと、Azure portal でプロビジョニングを構成するためのアプリケーション管理者またはクラウド アプリケーション管理者ロール。

• データベースにプロビジョニングされる Microsoft Entra ユーザーには、データベース スキーマで必要とされ、データベース自体によって生成されない属性が既に設定されている必要があります。

サンプル データベースの準備

この記事では、アプリケーションのリレーショナル データベースと対話するように Microsoft Entra SQL コネクタを構成します。 通常、アプリケーションは、ユーザーごとに 1 行ずつある SQL データベース内のテーブルで、アクセスを管理します。 既にデータベースとアプリケーションがある場合は、次のセクションに進みます。

適切なテーブルを持つデータベースがまだない場合は、デモンストレーション用に、Microsoft Entra による使用を許可したテーブルを作成する必要があります。 SQL Server を使用している場合は、「付録 A」に記載されている SQL スクリプトを実行します。このスクリプトは、1つのテーブル Employees を含む、CONTOSO という名前のサンプル データベースを作成します。 これは、ユーザーをプロビジョニングするデータベース テーブルです。

[テーブル列]	source
ContosoLogin	Microsoft Entra ユーザー プリンシパル名
FirstName	Microsoft Entra 名
姓	Microsoft Entra 姓
電子メール	Exchange Online 電子メールアドレス
InternalGUID	データベース自体によって生成されます
AzureID	Microsoft Entra オブジェクト ID
textID	Microsoft Entra ID メール ニックネーム

Microsoft Entra AD SQL コネクタがデータベースとどのように対話するかを決定する

SQL インスタンスに、データベースのテーブル内のデータを更新する権限を持つユーザー アカウントが存在する必要があります。 SQL データベースが他のユーザーによって管理されている場合は、そのユーザーに連絡して、データベースに対する認証に Microsoft Entra ID で使用するアカウント名とパスワードを入手してください。 SQL インスタンスが別のコンピューターにインストールされている場合は、SQL データベースでエージェント コンピューター上の ODBC ドライバーからの受信接続を許可する必要もあります。

アプリケーションに既存のデータベースが既にある場合、Microsoft Entra ID がそのデータベースと対話する方法を決定する必要があります。これは、テーブルとビューを直接操作する方法、データベース内に既に存在するストアド プロシージャを使用する方法、クエリと更新用に指定する SQL ステートメントを使用する方法です。 この設定は、より複雑なアプリケーションが、そのデータベースに他の補助テーブルを持ち、何千人ものユーザーを持つテーブルのページングを必要としたり、暗号化、ハッシュ化、妥当性チェックなどの追加のデータ処理を実行するストアド プロシージャを Microsoft Entra ID が呼び出す必要があったりする可能性があるからです。

アプリケーションのデータベースと対話するようにコネクタの構成を作成する場合は、まず、コネクタ ホストがデータベースのスキーマを読み取る方法についてのアプローチを構成してから、次に実行プロファイルを介してコネクタが継続的に使用するアプローチを構成します。 各実行プロファイルでは、コネクタが SQL ステートメントを生成する方法を指定します。 実行プロファイルの選択と実行プロファイル内のメソッドは、データベース エンジンがサポートする内容とアプリケーションで必要とされるものによって異なります。

• 構成が完了すると、プロビジョニング サービスが開始する際、完全インポート実行プロファイルで構成された相互作用が自動的に実行されます。 この実行プロファイルでは、コネクタは、通常 SELECT ステートメントを使用して、アプリケーションのデータベースからのユーザーのすべてのレコードを読み取ります。 この実行プロファイルは、後で＠ユーザーの Microsoft Entra ID に変更を加える必要がある場合に、そのユーザーに対して新しいレコードを作成するのではなく、データベース内のそのユーザーの既存のレコードを更新することを認識するために必要になります。

• 新しいユーザーをアプリケーションに割り当てる場合や既存のユーザーを更新する場合など、Microsoft Entra ID で変更が行われるたびに、プロビジョニング サービスは、SQL データベース相互作用によって構成されたエクスポート実行プロファイルを実行します。 エクスポート実行プロファイルでは、データベースの内容を Microsoft Entra ID と同期させるために、Microsoft Entra ID が SQL ステートメントを発行してデータベースのレコードを挿入、更新、および削除します。

• データベースでサポートされている場合は、必要に応じて 差分インポート実行プロファイルを構成することもできます。 この実行プロファイルでは、前回の完全インポート、または差分インポート以降に Microsoft Entra ID 以外のデータベースで行われた変更が Microsoft Entra ID によって読み取られます。 この実行プロファイルは、変更を読み取ることができるようにデータベースを構造化する必要があるため、省略可能です。

コネクタの各実行プロファイルの構成では、Microsoft Entra コネクタがテーブルまたはビューに対して独自の SQL ステートメントを生成するか、ストアド プロシージャを呼び出すか、または指定したカスタム SQL クエリを使用するかどうかを指定します。 通常は、コネクタ内のすべての実行プロファイルに同じ方法を使用します。

• 実行プロファイルのテーブルまたはビューメソッドを選択すると、Microsoft Entra コネクタによって、データベース内のテーブルまたはビューと対話するために必要な SQL ステートメント、SELECT、INSERT、UPDATE、および DELETE が生成されます。 この方法は、データベースに 1 つのテーブル、または既存の行数が少ない更新可能なビューがある場合に、最も簡単なアプローチです。
• ストアド プロシージャのメソッドを選択した場合、データベースには、ユーザーのページの読み取り、ユーザーの追加、ユーザーの更新、ユーザーの削除という 4 つのストアド プロシージャが必要になります。Microsoft Entra コネクタは、呼び出すストアド プロシージャの名前とパラメーターを使用して構成することになります。 この方法では、SQL データベースにより多くの構成が必要となります。通常は、アプリケーションで、ユーザーに対する変更ごとまたは大規模な結果セットをページングするため追加の処理が必要な場合にのみ必要になります。
• SQL クエリ メソッドを選択した場合は、実行プロファイルの実行時にコネクタが発行する特定の SQL ステートメントを入力します。 コネクタは、SQL ステートメントにコネクタが入力するパラメーター (インポート時の結果セットのページング、エクスポート中に作成される新しいユーザーの属性を設定するなど) を使用して構成します。

この記事では、エクスポートとフル インポートの実行プロファイルで、サンプル データベースのテーブル Employeesと対話するためにテーブル メソッドを使用する方法について説明します。 ストアド プロシージャまたは SQL クエリ メソッドの構成の詳細情報と具体的な要件については、「汎用 SQL 構成ガイド」を参照してください。

アプリケーションのデータベース スキーマで一意の識別子を選択する

ほとんどのアプリケーションは、アプリケーションのユーザーごとに一意の識別子を持ちます。 既存のデータベース テーブルにプロビジョニングする場合は、各ユーザーの値を持つそのテーブルのカラムを特定する必要があり、その値は一意であり、変更されることはありません。 この列はアンカーとなり、Microsoft Entra ID が既存の行を識別して更新や削除ができるようにするために使用します。 アンカーの詳細については、「アンカー属性と識別名について」を参照してください。

アプリケーションのデータベースが既に存在していて、その中にユーザーが存在し、Microsoft Entra ID でそれらのユーザーを最新に保ちたい場合は、アプリケーションのデータベースと Microsoft Entra のスキーマの間で同じ各ユーザーの識別子を用意する必要があります。 たとえば、Microsoft Entra ID でアプリケーションにユーザーを割り当て、そのユーザーが既にそのデータベースに存在する場合、Microsoft Entra ID でそのユーザーに変更を加えると、新しい行が追加されるのではなく、そのユーザーの既存の行が更新されます。 Microsoft Entra ID は、そのユーザーのアプリケーションの内部識別子を保存しない可能性が高いので、データベースのクエリに使用する別の列を選択することになります。 この列の値には、アプリケーションのスコープ内にある各ユーザーの Microsoft Entra ID に存在するユーザー プリンシパル名、メールアドレス、従業員 ID、またはその他の識別子を指定することができます。 アプリケーションが使用するユーザー識別子が、ユーザーの Microsoft Entra 表現に格納されている属性でない場合は、Microsoft Entra ユーザー スキーマを拡張して拡張属性を指定してデータベースからその属性を設定する必要はありません。 PowerShell を使用して Microsoft Entra スキーマを拡張し、拡張値を設定できます。

Microsoft Entra ID 内の属性をデータベース スキーマにマップする

Microsoft Entra ID 内のユーザーとデータベース内のレコードの間にリンクが Microsoft Entra ID で確立されている場合は、データベースに既に存在するユーザーであっても新しいユーザーであっても、Microsoft Entra ID で属性の変更を Microsoft Entra ユーザーからデータベースにプロビジョニングできます。 一意の識別子に加え、データベースを調べて他に必要なプロパティがあるかどうかを特定します。 存在する場合は、データベースにプロビジョニングされるユーザーに、必要なプロパティにマップできる属性があることを確認します。

プロビジョニング解除の動作を構成することもできます。 Microsoft Entra ID でアプリケーションに割り当てられているユーザーが削除された場合、Microsoft Entra ID は削除操作をディレクトリ サーバーに送信します。 また、ユーザーがアプリケーションを使用できるスコープから外れる場合に、Microsoft Entra ID にデータベースを更新させることもできます。 ユーザーがアプリから割り当て解除されたか、Microsoft Entra ID で論理的に削除されたか、またはサインインがブロックされた場合は、Microsoft Entra ID が属性の変更を送信するように構成できます。 既存のデータベース テーブルにプロビジョニングする場合は、そのテーブルの列を isSoftDeleted にマップできます。 ユーザーがスコープから外れると、Microsoft Entra ID によってそのユーザーの値が True に設定されます。

1. ODBC ドライバーをインストールする

プロビジョニング エージェントをインストールする Windows Server には、ターゲット データベース用の ODBC ドライバーが必要です。 SQL Server または Azure SQL データベースに接続する予定がある場合は、ODBC driver for SQL Server (x64) をダウンロードし、Windows サーバーにインストールする必要があります。 他の SQL データベースについては、ODBC ドライバーのインストール方法について独立系ソフトウェア ベンダーによるガイダンスを参照してください。

2. DSN 接続ファイルを作成する

Generic SQL コネクタでは、SQL エンドポイントに接続するためにデータソース名 (DSN) のファイルが必要です。 最初に、ODBC 接続情報を含むファイルを作成する必要があります。

1. サーバー上で ODBC 管理ユーティリティを起動します。 64 ビット版を使用します。

   

2. [ファイル DSN] タブを選択し、 [追加] を選択します。

   

3. SQL Server または Azure SQL を使用している場合は、[SQL Server Native Client 11.0] を選択し、[次へ] を選択します。 別のデータベースを使用している場合は、その ODBC ドライバーを選択します。

   

4. ファイルに GenericSQL などの名前を付け、 [次へ] を選択します。

5. [完了] を選択します。

   

6. ここで接続を構成します。 次の手順は、使用している ODBC ドライバーによって異なります。 この図では、ドライバーを使って SQL Server に接続していることが想定されています。 SQL Server が別のサーバー コンピューターにある場合は、サーバーの名前を入力します。 次に、 [次へ] を選択します。

   

7. この手順を実行しているユーザーがデータベースに接続するためのアクセス許可を持っている場合は、Windows 認証を選択したままにします。 SQL Server 管理者が SQL ローカル アカウントを必要とする場合は、代わりにそれらの資格情報を指定します。 [次へ] を選択します。

   

8. データベースの名前を入力します。このサンプルでは、CONTOSO になります。

   

9. この画面はすべて既定値のままにし、 [完了] を選択します。

   

10. 問題なく動作することを確認するには、 [データ ソースのテスト] を選択します。

    

11. テストの成功を確認します。

    

12. [OK] を 2 回選びます。 ODBC データ ソース アドミニストレーターを閉じます。 既定では、DSN 接続ファイルは Documents フォルダーに保存されます。

3.Microsoft Entra Connect のプロビジョニング エージェントをインストールして構成する

プロビジョニング エージェントを既にダウンロードし、別のオンプレミス アプリケーション用に構成している場合は、次のセクションに進んでください。

1. Azure portal にサインインします。
2. [エンタープライズ アプリケーション] に移動し、[新規アプリケーション] を選択します。
3. オンプレミスの ECMA アプリ アプリケーションを検索し、アプリに名前を付けて、[作成] を選択してテナントに追加します。
4. メニューから、アプリケーションの [プロビジョニング] ページに移動します。
5. [Get started](作業を開始する) を選択します。
6. [プロビジョニング] ページで、モードを [自動] に変更します。

7. [オンプレミス接続] で、[ダウンロードしてインストール] を選択し、[条項に同意してダウンロード] を選択します。

8. ポータルから移動してプロビジョニング エージェント インストーラーを実行し、サービス使用条件に同意して、[インストール] を選びます。
9. Microsoft Entra プロビジョニング エージェント構成ウィザードを待ってから、[次へ] を選択します。
10. [拡張機能を選択] ステップで、[オンプレミス アプリケーションのプロビジョニング] を選択し、[次へ] を選択します。
11. プロビジョニング エージェントは、オペレーティング システムの Web ブラウザーを使用して、Microsoft Entra ID (および場合によっては組織の ID プロバイダー) に対する認証を行うためのポップアップ ウィンドウを表示します。 Windows Server でブラウザーとして Internet Explorer を使用している場合は、JavaScript を正しく実行できるように、ブラウザーの信頼済みサイト リストに Microsoft Web サイトを追加する必要がある場合があります。
12. 承認を求められたら、Microsoft Entra 管理者の資格情報を入力します。 ユーザーは、少なくともハイブリッド ID 管理者ロールを持っている必要があります。
13. [Confirm] を選択して設定を確認します。 インストールが成功したら、[終了] を選択し、プロビジョニング エージェント パッケージ インストーラーも閉じます。

4. オンプレミスの ECMA アプリを構成する

1. ポータルに戻り、[オンプレミス接続] セクションで、デプロイしたエージェントを選択し、[エージェントの割り当て] を選択します。

   

2. このブラウザー ウィンドウを開いたままにして、構成ウィザードを使用して構成の次の手順を完了します。

5.Microsoft Entra ECMA コネクタ ホストの証明書を構成する

1. プロビジョニング エージェントがインストールされている Windows Server で、スタート メニューから Microsoft ECMA2Host 構成ウィザードを右クリックし、管理者として実行します。 ウィザードで必要な Windows イベント ログを作成するには、Windows 管理者として実行する必要があります。

2. このウィザードを初めて実行する場合は、ECMA Connector Host 構成の開始後に証明書の作成を求められます。 既定のポート 8585 のままにし、[証明書の生成] を選択して証明書を生成します。 自動生成された証明書は、信頼ルートの一部として自己署名されます。 証明書の SAN はホスト名と一致します。

   

3. [保存] を選択します。

注意

新しい証明書を生成することを選択した場合は、証明書の有効期限を記録した後、構成ウィザードに戻り、有効期限が切れる前に証明書を生成し直すようにしてください。

6. 汎用 SQL コネクタを作成する

このセクションでは、データベースのコネクタ構成を作成します。

6.1 SQL 接続を構成する

汎用 SQL コネクタを作成するには、以下の手順に従ってください。

1. コネクタに対する Microsoft Entra ID の認証のために使用するシークレット トークンを生成します。 これは、アプリケーションごとに最小 12 文字で、一意である必要があります。

2. まだ実行していない場合は、Windows スタート メニューから Microsoft ECMA2Host 構成ウィザードを起動します。

3. [新しいコネクタ] を選択します。

   

4. [プロパティ] ページでは、画像の下にある表に指定される値をボックスに入力し、 [次へ] を選択します。

   

   プロパティ	値
   名前	コネクタに対して選択した名前。これは、環境内のすべてのコネクタで一意である必要があります。 たとえば、SQL データベースが 1 つしかない場合は、SQL とします。
   AutoSync タイマー (分)	120
   シークレット トークン	このコネクタ用に生成したシークレット トークンを入力します。 キーは 12 文字以上である必要があります。
   拡張 DLL	Generic SQL コネクタの場合、Microsoft.IAM.Connector.GenericSql.dll を選択します。

5. [接続性] ページでは、画像の下にある表に指定される値をボックスに入力し、 [次へ] を選択します。

   

   プロパティ	説明
   DSN ファイル	SQL インスタンスに接続するために使用される、前の手順で作成したデータ ソース名ファイル。
   [ユーザー名]	SQL インスタンスのテーブルを更新する権限を持つアカウントのユーザー名。 ターゲット データベースが SQL Server であり、Windows 認証を使用している場合は、ユーザー名は、スタンドアロン サーバーの場合は hostname\sqladminaccount、ドメイン メンバー サーバーの場合は domain\sqladminaccount の形式にする必要があります。 他のデータベースの場合、ユーザー名はデータベース内のローカル アカウントになります。
   Password	指定したユーザー名のパスワード。
   DN is Anchor (DN はアンカー)	お使いの環境でこれらの設定が必要であるとわかっている場合を除いて、 [DN is Anchor](DN はアンカー) および [エクスポートの種類: オブジェクトの置換] チェックボックスを選択しないでください。

6.2 データベースからスキーマを取得する

資格情報を提供すると、ECMA コネクタ ホストはデータベースのスキーマを取得する準備が整います。 SQL 接続の構成を続けます。

5. [スキーマ 1] ページで、オブジェクトの種類の一覧を指定します。 このサンプルでは、オブジェクトの種類は User の 1 つです。 画像の下にある表に指定される値をボックスに入力し、[次へ] を選択します。

   

   プロパティ	値
   オブジェクトの種類の検出方法	Fixed Value
   固定値のリスト/テーブル/ビュー/SP	ユーザー

6. [次へ] を選択すると、User オブジェクトの種類を構成するための次のページが自動的に表示されます。 [スキーマ 2] ページで、データベースでのユーザーの表示方法を指定します。 このサンプルでは、Employees という名前の 1 つの SQL テーブルです。 画像の下にある表に指定される値をボックスに入力し、[次へ] を選択します。

   

   プロパティ	値
   ユーザー: 属性の検出	テーブル
   ユーザー: テーブル/ビュー/SP	データベース内のテーブルの名前 (Employees など)

   Note

   エラーが発生した場合は、データベース構成を調べて、[接続] ページで指定したユーザーがデータベースのスキーマへの読み取りアクセス権を持っていることを確認します。

7. [次へ] を選ぶと次のページが自動的に表示され、前に指定したテーブル (この例では Employees テーブル) で、ユーザーの Anchor および DN として使う列を選択できます。 これらの列には、データベース内で一意の識別子が含まれます。 同じ列でも異なる列でもかまいませんが、このデータベースに既に存在する行で、これらの列の値が一意であることを確認してください。 [スキーマ 3] ページでは、画像の下にある表に指定される値をボックスに入力し、 [次へ] を選択します。

   

   プロパティ	説明
   [:User] に [アンカー] を選択します	アンカーとして使うデータベース テーブルの列 (User:ContosoLogin など)
   ユーザーの DN 属性を選択してください	DN 属性として使うデータベースの列 (AzureID など)

8. [次へ] を選択すると、Employee テーブルの各列のデータ型と、コネクタがそれらをインポート、またはエクスポートする必要があるかどうかを確認するための次のページが自動的に表示されます。 [スキーマ 4] ページでは、既定値のままにし、 [次へ] を選択します。

   

9. [グローバル] ページで、ボックスに入力し、 [次へ] を選択します。 個々のボックスのガイダンスについては、画像の下にある表を参照してください。

   

   プロパティ	説明
   Delta Strategy (デルタ戦略)	IBM DB2 の場合は、None を選びます
   ウォーター マーク クエリ	IBM DB2 の場合は、「SELECT CURRENT TIMESTAMP FROM SYSIBM.SYSDUMMY1;」と入力します
   データ ソースの日付と時刻の形式	SQL Server の場合は yyyy-MM-dd HH:mm:ss、IBM DB2 の場合は YYYY-MM-DD

10. [パーティション] ページで [次へ] を選択します。

    

6.3 実行プロファイルを構成する

次に、エクスポートと完全インポートの実行プロファイルを構成します。 エクスポート実行プロファイルは、ECMA コネクタ ホストが Azure AD からデータベースに変更を送信し、レコードの挿入、更新、削除を行う必要がある場合に使用されます。 完全インポート実行プロファイルは、ECMA コネクタ ホスト サービスの開始時に、データベースの現在のコンテンツを読み取るために使用されます。 このサンプルでは、ECMA コネクタ ホストが必要な SQL ステートメントを生成するように、両方の実行プロファイルでテーブル メソッドを使用します。

SQL 接続の構成を続けます。

11. [プロファイルの実行] ページで [エクスポート] チェックボックスを選択したままにします。 [フル インポート] チェックボックスを選択して、 [次へ] を選択します。

    

    プロパティ	説明
    エクスポート	データを SQL にエクスポートする実行プロファイル。 この実行プロファイルは必須です。
    フル インポート	前に指定した SQL ソースからすべてのデータをインポートする実行プロファイル。
    差分インポート	最後のフルまたは差分インポート以降の SQL からの変更のみをインポートする実行プロファイル。

12. [次へ] を選択すると、[エクスポート] 実行プロファイルのメソッドを構成するための次のページが自動的に表示されます。 [エクスポート] ページで、ボックスに入力し、 [次へ] を選択します。 個々のボックスのガイダンスについては、画像の下にある表を参照してください。

    

    プロパティ	説明
    操作方法	テーブル
    テーブル/ビュー/SP	[スキーマ 2] タブで構成されているのと同じテーブル (Employees など)

13. [フル インポート] ページで、ボックスに入力し、 [次へ] を選択します。 個々のボックスのガイダンスについては、画像の下にある表を参照してください。

    

    プロパティ	説明
    操作方法	テーブル
    テーブル/ビュー/SP	[スキーマ 2] タブで構成されているのと同じテーブル (Employees など)

6.4 Microsoft Entra ID で属性がどのように表示されるかを構成する

SQL 接続設定の最後の手順で、Microsoft Entra ID で属性がどのように表示されるかを構成します。

14. [オブジェクトの種類] ページで、ボックスに入力し、 [次へ] を選択します。 個々のボックスのガイダンスについては、画像の下にある表を参照してください。

    • アンカー: この属性の値は、ターゲット データベース内のオブジェクトごとに一意である必要があります。 Microsoft Entra プロビジョニング サービスでは、初期サイクル後、この属性を使用して ECMA コネクタ ホストに対してクエリを実行します。 このアンカー値は、先に [スキーマ 3] ページで構成したアンカー列と同じにする必要があります。
    • クエリ属性: この属性はアンカーと同じである必要があります。
    • DN: ほとんどの場合、Autogenerated オプションを選択する必要があります。 オフになっている場合は、CN = anchorValue, Object = objectType という形式で DN が格納されている Microsoft Entra ID の属性に、DN 属性がマップされるようにします。 アンカーと DN の詳細については、「アンカー属性と識別名について」を参照してください。

    プロパティ	説明
    ターゲット オブジェクト	ユーザー
    アンカー	[スキーマ 3] タブで構成されている列 (ContosoLogin など)
    クエリ属性	アンカーと同じ列 (ContosoLogin など)
    DN	[スキーマ 3] タブで構成されているのと同じ列 (ContosoLogin など)
    自動生成	オン

15. ECMA コネクタ ホストにより、ターゲット データベースがサポートする属性が検出されます。 Microsoft Entra ID に公開する属性を選択できます。 プロビジョニングのために、これらの属性を Azure portal で構成できます。 [属性の選択] ページで、ドロップダウン リストのすべての属性を 1 つずつ追加します。

[属性] ドロップダウン リストには、ターゲット データベースで検出され、先ほどの [属性の選択] ページでは選択 "されなかった" 属性が示されます。 関連するすべての属性が追加されたら、[次へ] を選択します。

16. [プロビジョニング解除] ページの [フローを無効化] で [削除] を選択します。 前のページで選択した属性を [プロビジョニング解除] ページで選択することはできません。 [完了] を選択します。

注意

[Set attribute value](Set 属性値)を使用すると、ブール値のみが許可されることに注意してください。

7. ECMA2Host サービスが実行されていることを確認する

1. Microsoft Entra ECMA コネクタ ホストを実行しているサーバーで、[開始] を選択します。

2. 「run」 と入力し、ボックスに 「services.msc」 と入力します。

3. サービス リストで、Microsoft ECMA2Host が確実に存在し、実行中であるようにします。 そうでない場合は、 [開始] を選択します。

   

新しいデータベース、または空でユーザーがいないデータベースに接続している場合は、次のセクションに進んでください。 それ以外の場合は、次の手順に従って、コネクタがデータベースから既存のユーザーを識別したことを確認してください。

1. 最近サービスを開始し、データベースに多数のユーザー オブジェクトがある場合は、コネクタがデータベースとの接続を確立するまで数分待ってください。

8. Azure portal でアプリケーション接続を構成する

1. アプリケーション プロビジョニングを構成していた Web ブラウザー ウィンドウに戻ります。

   注意

   ウィンドウがタイムアウトした場合は、エージェントを再選択する必要があります。

   1. Azure portal にサインインします。
   2. [エンタープライズ アプリケーション] の [On-premises ECMA app](オンプレミス ECMA アプリ) アプリケーションに移動します。
   3. [プロビジョニング] を選択します。
   4. [作業の開始] が表示された場合は、モードを [自動] に変更し、[オンプレミス接続] セクションで、デプロイしたエージェントを選択し、[エージェントの割り当て] を選択します。 それ以外の場合は、[プロビジョニングの編集] に移動します。

2. [管理者資格情報] セクションで、次の URL を入力します。 {connectorName} の部分を ECMA コネクタ ホスト上のコネクタの名前 (SQL など) に置き換えます。 コネクタ名は大文字と小文字が区別され、ウィザードで構成したのと同じ大文字と小文字の区別にする必要があります。 localhost をマシンのホスト名に置き換えることもできます。

   プロパティ	値
   テナントの URL	https://localhost:8585/ecma2host_{connectorName}/scim

3. コネクタの作成時に定義したシークレット トークンの値を入力します。

   Note

   アプリケーションにエージェントを割り当てたばかりの場合は、登録が完了するまで 10 分間お待ちください。 登録が完了するまで、接続テストは機能しません。 サーバーでプロビジョニング エージェントを再起動してエージェントの登録を強制的に完了すると、登録プロセスを高速化することができます。 サーバーに移動して、Windows 検索バーでサービスを検索し、Microsoft Entra Connect プロビジョニング エージェント サービスを見つけたら、サービスを右クリックして再起動します。

4. [接続のテスト] をクリックし、1 分待ちます。

   

5. 接続テストが成功し、指定された資格情報が認証されてプロビジョニングが有効になったことが示されたら、[保存] を選択します。

   

9. 属性マッピングを構成する

次に、Microsoft Entra ID のユーザーの表現と、オンプレミス アプリケーションの SQL データベースのユーザーの表現との間で属性をマップする必要があります。

Azure portal を使って、Microsoft Entra ユーザーの属性と、ECMA ホスト構成ウィザードで前に選んだ属性との間の、マッピングを構成します。

1. Microsoft Entra スキーマに、データベースによって必要とされる属性が含まれていることを確認します。 ユーザーに uidNumber などの属性があることがデータベースによって要求され、その属性がユーザーの Microsoft Entra スキーマにまだ含まれていない場合は、ディレクトリ拡張機能を使用して、その属性を拡張機能として追加する必要があります。

2. Microsoft Entra 管理センターの [エンタープライズ アプリケーション] で、[オンプレミス ECMA アプリ] アプリケーションを選んでから、[プロビジョニング] ページを選びます。

3. [プロビジョニングの編集] を選択し、10 秒待ちます。

4. [マッピング] を展開し、[Microsoft Entra ID ユーザーをプロビジョニングする] マッピングを選びます。 このアプリケーションの属性マッピングを初めて構成する場合、これがプレースホルダーとして存在する唯一のマッピングになります。

   

5. データベースのスキーマが Microsoft Entra ID で使用可能であることを確認するには、[詳細オプションの表示] チェック ボックスをオンにし、[ScimOnPremises の属性リストの編集] を選択します。 構成ウィザードで選択したすべての属性が一覧表示されていることを確認します。 そうでない場合は、スキーマが更新されるまで数分待ってから、ページを再読み込みします。 属性が一覧表示されたら、このページを閉じてマッピング一覧に戻ります。

6. ここで、userPrincipalName PLACEHOLDER のマッピングをクリックします。 このマッピングは、オンプレミス プロビジョニングを初めて構成するときに既定で追加されます。

属性の値を次のように変更します。

マッピングの種類	ソース属性	ターゲット属性
直接	userPrincipalName	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:ContosoLogin

4. ここで [新しいマッピングの追加] を選択し、マッピングごとに次の手順を繰り返します。

   

5. 次の表のマッピングごとにソース属性とターゲット属性を指定します。

   

   マッピングの種類	ソース属性	ターゲット属性
   直接	userPrincipalName	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:ContosoLogin
   直接	objectId	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:AzureID
   直接	mail	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:Email
   直接	givenName	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:FirstName
   直接	surname	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:LastName
   直接	mailNickname	urn:ietf:params:scim:schemas:extension:ECMA2Host:2.0:User:textID

6. マッピングをすべて追加したら、[保存] を選択します。

10. アプリケーションにユーザーを割り当てる

これで Microsoft Entra ECMA コネクタ ホストが Microsoft Entra ID と通信するようになり、属性マッピングが構成されたので、プロビジョニングのスコープに含めるユーザーの構成に進むことができます。

重要

このセクションでは、ハイブリッド ID の管理者ロールを使用してサインインしている場合、一度サインアウトし、少なくともこのセクションのアプリ管理者ロールを持つアカウントでサインインする必要があります。 ハイブリッド ID の管理者の役割には、ユーザーをアプリケーションに割り当てるためのアクセス許可がありません。

SQL データベースに既存のユーザーが存在する場合は、それらの既存のユーザー向けのアプリケーション ロールの割り当てを作成する必要があります。 アプリケーション ロールの割り当てを一括で作成する方法について詳しくは、Microsoft Entra ID でのアプリケーションの既存ユーザーの管理に関する記事をご覧ください。

それ以外の場合、アプリケーションの現在のユーザーが存在しなければ、アプリケーションがプロビジョニングされるテスト ユーザーを Microsoft Entra から選択します。

1. データベース スキーマの必須属性にマップされるすべてのプロパティをユーザーが持っていることを確認します。

2. Azure portal で、 [エンタープライズ アプリケーション] を選択します。

3. [オンプレミスの ECMA アプリ] アプリケーションを選択します。

4. 左側のウィンドウの [管理] で、 [ユーザーとグループ] を選択します。

5. [Add user/group](ユーザーまたはグループの追加) を選択します。

   

6. [ユーザー] で [選択なし] を選択します。

   

7. 右側からユーザーを選択し、 [選択] ボタンを選択します。

   

8. [割り当て] を選択します。

   

11. プロビジョニングをテストする

属性がマップされ、ユーザーが割り当てられたので、ユーザーの 1 人でオンデマンド プロビジョニングをテストできます。

1. Azure portal で、 [エンタープライズ アプリケーション] を選択します。

2. [オンプレミスの ECMA アプリ] アプリケーションを選択します。

3. 左側で プロビジョニング を選択します。

4. [Provision on demand] (オンデマンドでプロビジョニングする) を選択します。

5. テスト ユーザーのものを検索し、 [プロビジョニング] を選択します。

   

6. 数秒後に、ターゲット システムでユーザーが正常に作成されましたというメッセージが表示され、ユーザー属性の一覧が表示されます。

12. ユーザーのプロビジョニングを開始する

1. オンデマンド プロビジョニングが成功したら、プロビジョニングの構成ページに戻ります。 スコープが割り当てられたユーザーとグループのみに確実に設定されているようにし、プロビジョニングを [オン] にして、 [保存] を選択します。

   

2. プロビジョニングが開始されるまで数分待機します。 最大 40 分かかる場合があります。 プロビジョニング ジョブが完了した後、テストが終了している場合は、次のセクションで説明されているように、プロビジョニングの状態を [オフ] に変更し、[保存] を選択できます。 これにより、プロビジョニング サービスは今後実行されなくなります。

プロビジョニング エラーのトラブルシューティング

エラーが表示された場合は、[プロビジョニング ログの表示] を選択します。 [状態] が [失敗] になっている行をログで確認し、その行を選択します。

エラー メッセージがユーザーを作成できませんでしたである場合は、データベース スキーマの要件に照らして表示される属性を確認します。

詳細については、[トラブルシューティングと推奨事項] タブに移動します。ODBC ドライバーがメッセージを返した場合は、ここに表示される場合があります。 たとえば、メッセージ ERROR [23000] [Microsoft][ODBC SQL Server Driver][SQL Server]Cannot insert the value NULL into column 'FirstName', table 'CONTOSO.dbo.Employees'; column does not allow nulls. は ODBC ドライバーのエラーです。 この場合、column does not allow nulls は、データベース内の FirstName 列は必須ですが、プロビジョニングされるユーザーに givenName 属性がないため、ユーザーをプロビジョニングできなかったことを示している可能性があります。

ユーザーが正常にプロビジョニングされたことを確認する

待機した後、SQL データベースを確認して、ユーザーがプロビジョニングされているのを確認します。

Azure BLOB ストレージ アカウントにデータを取得/アップロードする方法については、

SQL Server を使用している場合は、次の SQL スクリプトを使用して、サンプル データベースを作成できます。

---Creating the Database---------
Create Database CONTOSO
Go
-------Using the Database-----------
Use [CONTOSO]
Go
-------------------------------------

/****** Object:  Table [dbo].[Employees]    Script Date: 1/6/2020 7:18:19 PM ******/
SET ANSI_NULLS ON
GO

SET QUOTED_IDENTIFIER ON
GO

CREATE TABLE [dbo].[Employees](
	[ContosoLogin] [nvarchar](128) NULL,
	[FirstName] [nvarchar](50) NOT NULL,
	[LastName] [nvarchar](50) NOT NULL,
	[Email] [nvarchar](128) NULL,
	[InternalGUID] [uniqueidentifier] NULL,
	[AzureID] [uniqueidentifier] NULL,
	[textID] [nvarchar](128) NULL
) ON [PRIMARY]
GO

ALTER TABLE [dbo].[Employees] ADD  CONSTRAINT [DF_Employees_InternalGUID]  DEFAULT (newid()) FOR [InternalGUID]
GO

次のステップ

• オンプレミス アプリケーションのプロビジョニングのトラブルシューティング
• 既知の制限事項のレビュー