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

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

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

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

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

オンプレミスの前提条件

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

  • Windows Server 2016 以降のバージョン。
  • ターゲット データベース システムへの接続、および login.microsoftonline.com、その他の Microsoft Online ServicesAzure ドメインへの送信接続。 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

汎用 SQL コネクタのテーブル ベース メソッドでは、列名の大文字と小文字は区別されません。 MySQL は Linux では大文字と小文字が区別され、Postgres はプラットフォーム全体で大文字と小文字が区別されます。 その結果、テーブル ベースのメソッドでは現在サポートされておらず、これらのデータベースへのユーザーのプロビジョニングの構成は、この記事の範囲外となります。

クラウドの要件

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

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

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

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

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

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

[テーブル列] source
ContosoLogin Azure AD ユーザー プリンシパル名
FirstName Azure AD 指定された名前
LastName Azure AD 姓
Email 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 ステートメント、SELECTINSERTUPDATE、および 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 サーバーにインストールする必要があります。

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

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

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

    ODBC 管理を示すスクリーンショット。

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

    [ファイル 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 ローカル アカウントを必要とする場合は、代わりにそれらの資格情報を指定します。 [次へ] を選択します。

    Windows 認証を示すスクリーンショット。

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

    データベース名の入力を示すスクリーンショット。

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

    完了の選択を示すスクリーンショット。

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

    テスト データ ソースを示すスクリーンショット。

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

    成功を示すスクリーンショット。

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

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

  1. プロビジョニング エージェントをダウンロードし、SQL サーバーに接続できる Windows Server にコピーします。

    Note

    オンプレミス アプリケーションのプロビジョニングと Azure AD Connect クラウド同期または人事主導のプロビジョニングには、異なるプロビジョニング エージェントを使用してください。 3 つのすべてのシナリオを同じエージェントで管理することはできません。

  2. プロビジョニング エージェント インストーラーを開き、サービス使用条件に同意して、[次へ] を選択します。

  3. プロビジョニング エージェント ウィザードを開きます。

  4. [拡張機能を選択] ステップで、オンプレミスのプロビジョニングを選択し、[次へ] を選択します。

    オンプレミスのプロビジョニングを選択する方法を示すスクリーンショット。

  5. 承認を求められたら、Azure AD 管理者の資格情報を入力します。 ハイブリッド ID 管理者または全体管理者のロールが必要です。

  6. [確認] を選択して、インストールが成功したことを確認します。

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

  1. Azure portal にサインインします。

  2. [エンタープライズ アプリケーション][新しいアプリケーションを追加] に移動します。

  3. [On-premises ECMA app](オンプレミス ECMA アプリ) のアプリケーションを検索し、テナント イメージに追加します。

  4. メニューから、[プロビジョニング] を選択します。

  5. [Get started](作業を開始する) を選択します。

  6. [プロビジョニング] ページで、モードを [自動] に変更します。

    モードの [自動] への変更を示すスクリーンショット。

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

    エージェントを選択して割り当てる方法を示すスクリーンショット。

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

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

  1. プロビジョニング エージェントがインストールされている Windows Server で、スタート メニューから Microsoft ECMA2Host 構成ウィザードを起動します。

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

    設定の構成を示すスクリーンショット。

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

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

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

6.1 SQL 接続を構成する

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

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

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

    新しいコネクタの選択を示すスクリーンショット。

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

    プロパティの入力を示すスクリーンショット。

    プロパティ
    名前 SQL
    AutoSync タイマー (分) 120
    シークレット トークン ここに自身のキーを入力します。 任意の好きな値を選択できます。 キーは 12 文字以上である必要があります。
    拡張 DLL Generic SQL コネクタの場合、Microsoft.IAM.Connector.GenericSql.dll を選択します。
  4. [接続性] ページでは、画像の下にある表に指定される値をボックスに入力し、 [次へ] を選択します。

    [接続性] ページを示すスクリーンショット。

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

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

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

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

    [スキーマ 1] ページを示すスクリーンショット。

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

    [スキーマ 2] ページを示すスクリーンショット。

    プロパティ
    ユーザー: 属性の検出 テーブル
    ユーザー: テーブル/ビュー/SP Employees

    注意

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

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

    [スキーマ 3] ページを示すスクリーンショット。

    プロパティ 説明
    [:User] に[アンカー] を選択します User:ContosoLogin
    ユーザーの DN 属性を選択してください AzureID
  4. [次へ] を選択すると、Employee テーブルの各列のデータ型と、コネクタがそれらをインポート、またはエクスポートする必要があるかどうかを確認するための次のページが自動的に表示されます。 [スキーマ 4] ページでは、既定値のままにし、 [次へ] を選択します。

    [スキーマ 4] ページを示すスクリーンショット。

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

    [グローバル] ページを示すスクリーンショット。

    プロパティ 説明
    データ ソースの日付と時刻の形式 yyyy-MM-dd HH:mm:ss
  6. [パーティション] ページで [次へ] を選択します。

    [パーティション] ページを示すスクリーンショット。

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

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

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

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

    [実行プロファイル] ページを示すスクリーンショット。

    プロパティ 説明
    エクスポート データを SQL にエクスポートする実行プロファイル。 この実行プロファイルは必須です。
    フル インポート 前に指定した SQL ソースからすべてのデータをインポートする実行プロファイル。
    差分インポート 最後のフルまたは差分インポート以降の SQL からの変更のみをインポートする実行プロファイル。
  2. [次へ] を選択すると、[エクスポート] 実行プロファイルのメソッドを構成するための次のページが自動的に表示されます。 [エクスポート] ページで、ボックスに入力し、 [次へ] を選択します。 個々のボックスのガイダンスについては、画像の下にある表を参照してください。

    [エクスポート] ページを示すスクリーンショット。

    プロパティ 説明
    操作方法 テーブル
    テーブル/ビュー/SP Employees
  3. [フル インポート] ページで、ボックスに入力し、 [次へ] を選択します。 個々のボックスのガイダンスについては、画像の下にある表を参照してください。

    [フル インポート] ページを示すスクリーンショット。

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

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

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

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

    • アンカー: この属性の値は、ターゲット データベース内のオブジェクトごとに一意である必要があります。 Azure AD プロビジョニング サービスでは、初期サイクル後、この属性を使用して ECMA コネクタ ホストに対してクエリを実行します。 このアンカー値は、先にスキーマ 3 のページで構成したアンカー値と同じである必要があります。
    • クエリ属性: この属性はアンカーと同じである必要があります。
    • DN: ほとんどの場合、Autogenerated オプションを選択する必要があります。 選択解除されている場合、DN 属性が、CN = anchorValue, Object = objectType の形式で、DN を格納している Azure AD 内の属性に確実にマップされるようにします。 アンカーと DN の詳細については、「アンカー属性と識別名について」を参照してください。
    プロパティ 説明
    ターゲット オブジェクト ユーザー
    アンカー ContosoLogin
    クエリ属性 ContosoLogin
    DN ContosoLogin
    自動生成 オン
  2. ECMA コネクタ ホストにより、ターゲット データベースがサポートする属性が検出されます。 Azure AD に公開する属性を選択できます。 プロビジョニングのために、これらの属性を Azure portal で構成できます。 [属性の選択] ページで、ドロップダウン リストのすべての属性を 1 つずつ追加します。

    [属性の選択] ページを示すスクリーンショット。

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

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

    プロビジョニング解除のページを示すスクリーンショット。

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

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

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

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

    サービスが稼働中であることを示すスクリーンショット。

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_SQL/scim
  3. コネクタの作成時に定義したシークレット トークンの値を入力します。

    注意

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

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

    エージェントの割り当てを示すスクリーンショット。

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

    エージェントのテストを示すスクリーンショット。

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

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

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

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

  3. [マッピング] を展開して [Azure Active Directory ユーザーをプロビジョニングする] を選択します。

    ユーザーのプロビジョニングを示すスクリーンショット。

  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. Azure portal で、 [エンタープライズ アプリケーション] を選択します。

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

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

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

    ユーザーの追加を示すスクリーンショット。

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

    [選択なし] を示すスクリーンショット。

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

    ユーザーの選択を示すスクリーンショット。

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

    ユーザーの割り当てを示すスクリーンショット。

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

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

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

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

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

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

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

    プロビジョニングのテストを示すスクリーンショット。

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

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

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

    プロビジョニングの開始を示すスクリーンショット。#lightbox)

  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

次のステップ