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

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

このサービスが実行する内容、しくみ、よく寄せられる質問の重要な詳細については、Azure Active Directory による 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 10.x
• IBM DB2 9.x
• Oracle 10g および 11g
• Oracle 12c および 18c
• MySQL 5.x
• MySQL 8.x
• Postgres

クラウドの要件

• Azure AD Premium P1 または Premium P2 (または EMS E3 または E5) を持つ Azure AD テナント。

  この機能を使用するには、Azure AD Premium P1 ライセンスが必要です。 ご自分の要件に対して適切なライセンスを探すには、一般提供されている Azure AD の機能の比較に関するページをご覧ください。

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

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

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

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

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

[テーブル列]	source
ContosoLogin	Azure AD ユーザー プリンシパル名
FirstName	Azure AD 指定された名前
LastName	Azure AD 姓
電子メール	Exchange Online 電子メールアドレス
InternalGUID	データベース自体によって生成されます
AzureID	Azure AD object ID
textID	Azure AD メール ニックネーム

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

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

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

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

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

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

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

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

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

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

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

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

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

Azure AD 内の属性をデータベース スキーマにマップする

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

プロビジョニング解除の動作を構成することもできます。 Azure AD でアプリケーションに割り当てられているユーザーが削除された場合、Azure AD は削除操作をデータベースに送信します。 また、ユーザーがアプリケーションを使用できるスコープから外れる場合に、Azure AD にデータベースを更新させることもできます。 ユーザーがアプリから割り当て解除されたか、Azure AD で論理的に削除されたか、またはサインインがブロックされた場合は、Azure AD が属性の変更を送信するように構成できます。 既存のデータベース テーブルにプロビジョニングする場合は、そのテーブルの列を isSoftDeleted にマップできます。 ユーザーがスコープから外れると、Azure AD によってそのユーザーの値が 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. ここで接続を構成します。 SQL Server が別のサーバー コンピューターにある場合は、サーバーの名前を入力します。 次に、 [次へ] を選択します。 次の手順は、使用している ODBC ドライバーによって異なります。 これらの設定は、SQL Server に接続するドライバーを使用していることを前提としています。

   

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

   

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

   

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

   

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

    

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

    

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

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

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

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

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

8. ポータルをそのままにして、プロビジョニング エージェント インストーラーを開き、サービス使用条件に同意して、[次へ] を選択します。
9. プロビジョニング エージェント ウィザードを開きます。
10. [拡張機能を選択] ステップで、[オンプレミス アプリケーションのプロビジョニング] を選択し、[次へ] を選択します。

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

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

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

   

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

5. Azure AD ECMA Connector Host の証明書を構成する

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

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

   

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

注意

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

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

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

6.1 SQL 接続を構成する

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

1. コネクタに対して Azure AD を認証するために使用されるシークレット トークンを生成します。 これは、アプリケーションごとに最小 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

   注意

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

7. [次へ] を選択すると、ユーザーの Anchor および DN として使用する Employees テーブルの列を選択するための次のページが自動的に表示されます。 [スキーマ 3] ページでは、画像の下にある表に指定される値をボックスに入力し、 [次へ] を選択します。

   

   プロパティ	説明
   [:User] に [アンカー] を選択します	User:ContosoLogin
   ユーザーの DN 属性を選択してください	AzureID

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

   

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

   

   プロパティ	説明
   データ ソースの日付と時刻の形式	yyyy-MM-dd HH:mm:ss

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

    

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

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

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

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

    

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

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

    

    プロパティ	説明
    操作方法	テーブル
    テーブル/ビュー/SP	Employees

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

    

    プロパティ	説明
    操作方法	テーブル
    テーブル/ビュー/SP	Employees

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

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

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

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

    プロパティ	説明
    ターゲット オブジェクト	ユーザー
    アンカー	ContosoLogin
    クエリ属性	ContosoLogin
    DN	ContosoLogin
    自動生成	オン

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

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

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

注意

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

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

1. Azure AD ECMA Connector Host を実行しているサーバーで、 [開始] をクリックします。

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 検索バーでサービスを検索し、Azure AD Connect プロビジョニング エージェント サービスを特定し、サービスを右クリックして再起動します。

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

   

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

   

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

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

Azure portal を使用して、Azure AD ユーザーの属性と、ECMA ホスト構成ウィザードで以前に選択した属性との間のマッピングを構成します。

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

2. Azure AD ポータルの [エンタープライズ アプリケーション] で、[On-premises ECMA app] (オンプレミスの ECMA アプリ) アプリケーション、[プロビジョニング] ページの順に選択します。

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

4. [マッピング] を展開して [Azure Active Directory ユーザーをプロビジョニングする] を選択します。 このアプリケーションの属性マッピングを初めて構成した場合、プレースホルダーのマッピングは 1 つだけ存在します。

   

5. データベースのスキーマが Azure AD で使用可能であることを確認するには、[詳細オプションの表示] チェック ボックスをオンにし、[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. アプリケーションにユーザーを割り当てる

これで Azure AD ECMA Connector Host が Azure AD と通信できるようになり、属性マッピングが構成されたので、プロビジョニングのスコープに含めるユーザーの構成に進むことができます。

重要

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

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

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

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

次のステップ

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