Power BI からオンプレミス データ ソースへの SSO (シングル サインオン) に Kerberos を使用するUse Kerberos for SSO (single sign-on) from Power BI to on-premises data sources

オンプレミスのデータ ゲートウェイと Kerberos を構成することにより、シームレスなシングル サインオン接続を確立して、Power BI のレポートとダッシュボードをオンプレミスのデータで更新することができます。You can get seamless single sign-on connectivity, enabling Power BI reports and dashboards to update from on-premises data, by configuring your on-premises data gateway with Kerberos. オンプレミス データ ゲートウェイにより、DirectQuery を使うシングル サインオン (SSO) が容易になります。この場合、オンプレミスのデータ ソースへの接続に使われます。The on-premises data gateway facilitates single sign-on (SSO) using DirectQuery, which it uses to connect to on-premises data sources.

現在、SQL Server、SAP HANA、Teradata の各データ ソースがサポートされています。これらはすべて、Kerberos の制約付き委任に基づきます。The following data sources are currently supported, SQL Server, SAP HANA, and Teradata, all based on Kerberos Constrained Delegation.

  • SQL ServerSQL Server
  • SAP HANASAP HANA
  • TeradataTeradata

ユーザーが Power BI サービスで DirectQuery レポートを操作すると、クロスフィルター、スライス、並べ替え、レポート編集の各操作で、基になるオンプレミス データ ソースに対してクエリがライブ実行される場合があります。When a user interacts with a DirectQuery report in the Power BI Service, each cross-filter, slice, sorting, and report editing operation can result in queries executing live against the underlying on-premises data source. データ ソースにシングル サインオンが構成されていると、Power BI を操作しているユーザーの ID でクエリが実行されます (つまり、Web エクスペリエンスまたは Power BI モバイル アプリで)。When single sign-on is configured for the data source, queries execute under the identity of the user interacting with Power BI (that is, through the web experience or Power BI mobile apps). これにより、各ユーザーには、そのユーザーが基になるデータ ソースでアクセス許可を持っているデータだけが表示されます。シングル サインオンを構成すると、異なるユーザー間で共有されるデータ キャッシュはありません。Thereby, each user sees precisely the data for which they have permissions in the underlying data source – with single sign-on configured, there is no shared data caching across different users.

SSO でのクエリ実行手順Running a query with SSO - steps that occur

SSO を使ったクエリ実行は、次の図に示す 3 つのステップで構成されます。A query that runs with SSO consists of three steps, as shown in the following diagram.

注意

Oracle 用の SSO は、まだ有効になっていませんが、開発中であり近日公開予定です。SSO for Oracle is not enabled yet, but is under development and coming soon.

これらの手順の詳細を次に示します。Here are additional details about those steps:

  1. 各クエリに対し、Power BI サービスは構成されたゲートウェイに送信するクエリ要求にユーザー プリンシパル名 (UPN) を組み込みます。For each query, the Power BI service includes the user principal name (UPN) when sending a query request to the configured gateway.
  2. ゲートウェイは、Azure Active Directory の UPN を Active Directory のローカル ID にマップする必要があります。The gateway needs to map the Azure Active Directory UPN to a local Active Directory identity.

    a.a. AAD DirSync (AAD Connect とも呼ばれる) が構成されている場合は、マッピングがゲートウェイで自動的に動作します。If AAD DirSync (also known as AAD Connect) is configured, then the mapping works automatically in the gateway.

    b.b. それ以外の場合、ゲートウェイは、ローカルの Active Directory ドメインに対して検索を実行することにより、Azure AD UPN を参照し、これをローカル ユーザーにマップします。Otherwise, the gateway can look up and map the Azure AD UPN to a local user by performing a lookup against the local Active Directory domain.

  3. ゲートウェイ サービスのプロセスは、マップされたローカル ユーザーを偽装して、基になるデータベースへの接続を開き、クエリを送信します。The gateway service process impersonates the mapped local user, opens the connection to the underlying database and sends the query. ゲートウェイはデータベースと同じコンピューターにインストールされている必要はありません。The gateway does not need to be installed on the same machine as the database.

    • ユーザーの偽装やデータベースへの接続が成功するのは、ゲートウェイ サービス アカウントがドメイン アカウント (またはサービス SID) である場合、およびゲートウェイ サービス アカウントからの Kerberos チケットを受け入れるようにデータベースに対して Kerberos 制約付き委任が構成されている場合のみです。The user impersonation and connection to the database is only successful if the gateway service account is a domain account (or service SID), and if Kerberos constrained delegation was configured for the database to accept Kerberos tickets from the gateway service account.

    注意

    サービス SID に関して、AAD DirSync/Connect が構成されていて、ユーザー アカウントが同期されている場合、ゲートウェイは実行時にローカル AD 参照を実行する必要はなく、ゲートウェイ サービスに対して (ドメイン アカウントを要求する代わりに) ローカル サービス SID を使うことができます。Regarding the service sid, if AAD DirSync / Connect is configured and user accounts are synchronized, the gateway service does not need perform local AD lookups at runtime, and you can use the local Service SID (instead of requiring a domain account) for the gateway service. このドキュメントで説明する Kerberos の制約付き委任の構成手順は同じものです (ドメイン アカウントではなく、単にサービス SID に基づいて適用されます)。The Kerberos constrained delegation configuration steps outlined in this document are the same (just applied based on the service SID, instead of domain account).

注意

SAP HANA で SSO を有効にするには、SAP で次の HANA 固有の構成を満たす必要があります。To enable SSO for SAP HANA, you need to ensure the following HANA-specific configurations are met for SAP:

  1. SAP HANA サーバーでバージョン 2.00.022* 以上/以降を実行します。Ensure the SAP HANA server is running version 2.00.022* or higher / later.
  2. ゲートウェイ マシンに、SAP の最新の HANA ODBC ドライバーをインストールする。On the gateway machine, install SAP’s latest HANA ODBC driver. 最小バージョンは 2017 年 8 月の HANA ODBC バージョン 2.00.020.00 です。The minimum version is HANA ODBC version 2.00.020.00 from August 2017.

SAP が提供する次のパッチ/アップグレード リンクが役に立つことがあります。The following links to patches and upgrades from SAP may be useful. SAP サポート アカウントを利用して次のリソースにログインする必要があることと、SAP がこれらのリンクを変更または更新する可能性があることにご注意ください。Note that you must log in to the following resources using your SAP Support account, and that SAP may change or update these links.

Kerberos の不適切な構成によるエラーErrors from an insufficient Kerberos configuration

基になっているデータベース サーバーとゲートウェイが Kerberos の制約付き委任用に正しく構成されていない場合、次のエラー メッセージが表示される可能性があります。If the underlying database server and gateway are not configured properly for Kerberos Constrained Delegation, you may receive the following error message:

また、エラー メッセージに関連付けられている技術的な詳細は次のようになります。And the technical details associated with the error message may look like the following:

つまり、Kerberos の構成が不十分なため、ゲートウェイは元のユーザーを適切に偽装できず、データベース接続の試行は失敗しました。The result is that the because of insufficient Kerberos configuration, the gateway could not impersonate the originating user properly, and the database connection attempt failed.

Kerberos の制約付き委任のための準備Preparing for Kerberos Constrained Delegation

Kerberos の制約付き委任が正しく機能するためには、サービス プリンシパル名 (SPN) やサービス アカウントでの委任の設定など、いくつかのことを構成する必要があります。Several items must be configured in order for Kerberos Constrained Delegation to work properly, including Service Principal Names (SPN) and delegation settings on service accounts.

前提条件 1: オンプレミス データ ゲートウェイをインストールして構成するPrerequisite 1: Install & configure the on-premises data gateway

オンプレミス データ ゲートウェイのこのリリースでは、インプレース アップグレードだけでなく既存のゲートウェイの引き継ぎの設定がサポートされています。This release of the on-premises data gateway supports an in-place upgrade, as well as settings take-over of existing gateways.

前提条件 2: ゲートウェイの Windows サービスをドメイン アカウントとして実行するPrerequisite 2: Run the gateway Windows service as a domain account

標準のインストールでは、ゲートウェイは、次の図のようにコンピューター ローカル サービス アカウントとして実行されます (具体的には、NT Service\PBIEgwService)。In a standard installation, the gateway runs as a machine-local service account (specifically, NT Service\PBIEgwService) such as what's shown in the following image:

AAD が既に (AAD DirSync/Connect を使って) ローカルの Active Directory と同期されている場合を除き、Kerberos の制約付き委任を有効にするには、ゲートウェイをドメイン アカウントとして実行する必要があります。To enable Kerberos Constrained Delegation, the gateway must run as a domain account, unless your AAD is already synchronized with your local Active Directory (using AAD DirSync/Connect). このアカウント変更を正常に動作させるには、次の 2 つのオプションがあります。For this account change to work correctly, you have two options:

  • 前のバージョンのオンプレミス データ ゲートウェイから始める場合は、次の記事で説明されている 5 ステップのすべての手順を正確に順番に実行します (ステップ 3 のゲートウェイ構成ウィザードの実行を含めて)。If you started with a previous version of the on-premises data gateway, follow precisely all five steps in sequence (including running the gateway configurator in step 3) described in the following article:

    • ドメイン ユーザーへのゲートウェイ サービス アカウントの変更Changing the gateway service account to a domain user
    • オンプレミス データ ゲートウェイのプレビュー バージョンを既にインストールした場合は、ゲートウェイ構成ウィザード内から直接サービス アカウントを切り替える新しい UI ガイド付きアプローチがあります。If you already installed the Preview version of the on-premises data gateway, there is a new UI-guided approach to switch service accounts directly from within the gateway’s configurator. この記事の最後近くにある「ゲートウェイをドメイン アカウントに切り替える」セクションをご覧ください。See the Switching the gateway to a domain account section near the end of this article.

注意

AAD DirSync/Connect が構成されていて、ユーザー アカウントが同期されている場合、ゲートウェイは実行時にローカル AD 参照を実行する必要はなく、ゲートウェイ サービスに対して (ドメイン アカウントを要求する代わりに) ローカル サービス SID を使うことができます。If AAD DirSync / Connect is configured and user accounts are synchronized, the gateway service does not need to perform local AD lookups at runtime, and you can use the local Service SID (instead of requiring a domain account) for the gateway service. この記事で説明する Kerberos の制約付き委任の構成手順は、その構成と同じです (ドメイン アカウントではなく、サービス SID に基づいて単に適用されます)。The Kerberos Constrained Delegation configuration steps outlined in this article are the same as that configuration (they are simply applied based on the service SID, instead of domain account).

前提条件 3: SPN (SetSPN) および Kerberos 制約付き委任の設定を構成するためのドメイン管理者権限があるPrerequisite 3: Have domain admin rights to configure SPNs (SetSPN) and Kerberos Constrained Delegation settings

ドメイン管理者権限を要求せず、ドメイン管理者が SPN および Kerberos 委任を構成する権限を一時的または永続的に他のユーザーに許可することは技術的には可能ですが、そのような方法はお勧めできません。While it is technically possible for a domain administrator to temporarily or permanently allow rights to someone else to configure SPNs and Kerberos delegation, without requiring domain admin rights, that's not the recommended approach. 次のセクションで、前提条件 3 に必要な構成手順を詳しく説明します。In the following section, the configuration steps necessary for Pre-requisite 3 in detail.

ゲートウェイとデータ ソースに対して Kerberos の制約付き委任を構成するConfiguring Kerberos Constrained Delegation for the gateway and data source

システムを正しく構成するには、次の 2 つのことを構成または検証する必要があります。To properly configure the system, we need to configure or validate the following two items:

  1. 必要な場合は、ゲートウェイ サービスのドメイン アカウントに SPN を構成します (まだ作成されていない場合)。If needed, configure an SPN for the gateway service domain account (if none are created yet).
  2. ゲートウェイ サービスのドメイン アカウントに委任設定を構成します。Configure delegation settings on the gateway service domain account.

これら 2 つの構成手順はドメイン管理者が実行する必要があることに注意してください。Note that you must be a domain administrator to perform those two configuration steps.

以下のセクションでは、これらの手順を順番に説明します。The following sections describe these steps in turn.

ゲートウェイ サービス アカウントに SPN を構成するConfigure an SPN for the gateway service account

最初に、以下の手順に従って、ゲートウェイ サービス アカウントとして使われるドメイン アカウントに SPN が既に作成されているかどうかを調べます。First, determine whether an SPN was already created for the domain account used as the gateway service account, but following these steps:

  1. ドメイン管理者として [Active Directory ユーザーとコンピューター] を起動しますAs a domain administrator, launch Active Directory Users and Computers
  2. ドメインを右クリックし、[検索] を選んで、ゲートウェイ サービス アカウントのアカウント名を入力しますRight-click on the domain, select Find, and type in the account name of the gateway service account
  3. 検索結果で、ゲートウェイ サービス アカウントを右クリックして、[プロパティ] を選びます。In the search result, right-click on the gateway service account and select Properties.

    • [委任] タブが [プロパティ] ダイアログに表示される場合、SPN は既に作成されており、委任設定の構成に関する次のサブセクションに進むことができます。If the Delegation tab is visible on the Properties dialog, then an SPN was already created and you can jump ahead to the next subsection about configuring Delegation settings.

[委任] タブが [プロパティ] ダイアログにない場合は、そのアカウントに SPN を手動で作成でき、作成すると [委任] タブが追加されます (これが、委任設定を構成する最も簡単な方法です)。If there is no Delegation tab on the Properties dialog, you can manually create an SPN on that account which adds the Delegation tab (that is the easiest way to configure delegation settings). SPN の作成は、Windows に付属する setspn ツールを使って行うことができます (SPN を作成するにはドメイン管理者権限が必要です)。Creating an SPN can be done using the setspn tool that comes with Windows (you need domain admin rights to create the SPN).

たとえば、ゲートウェイ サービス アカウントが "PBIEgwTest\GatewaySvc" で、ゲートウェイ サービスを実行しているコンピューターの名前が Machine1 であるとします。For example, imagine the gateway service account is “PBIEgwTest\GatewaySvc”, and the machine name with the gateway service running is called Machine1. この例のコンピューターにゲートウェイ サービス アカウントの SPN を設定するには、次のコマンドを実行します。To set the SPN for the gateway service account for that machine in this example, you would run the following command:

このステップが完了したら、委任設定の構成に進むことができます。With that step completed, we can move on to configuring delegation settings.

ゲートウェイ サービス アカウントで委任設定を構成するConfigure delegation settings on the gateway service account

2 番目の構成要件は、ゲートウェイ サービス アカウントでの委任の設定です。The second configuration requirement is the delegation settings on the gateway service account. この手順は複数のツールを使って実行できます。There are multiple tools you can use to perform these steps. この記事では [Active Directory ユーザーとコンピューター] を使います。これは、ディレクトリ内の情報の管理と発行に使うことができる Microsoft 管理コンソール (MMC) のスナップインであり、ドメイン コントローラーでは既定で利用できます。In this article, we'll use Active Directory Users and Computers, which is a Microsoft Management Console (MMC) snap-in that you can use to administer and publish information in the directory, and available on domain controllers by default. 他のコンピューターでの Windows 機能の構成により有効にすることもできます。You can also enable it through Windows Feature configuration on other machines.

プロトコル遷移のある Kerberos の制約付き委任を構成する必要があります。We need to configure Kerberos Constrained Delegation with protocol transiting. 制約付き委任では、委任先のサービスが明確にわかっている必要があります (たとえば、SQL Server または SAP HANA サーバーだけがゲートウェイ サービス アカウントからの委任呼び出しを受け付けるなど)。With constrained delegation, you must be explicit with which services you want to delegate to – for example, only your SQL Server or your SAP HANA server will accept delegation calls from the gateway service account.

このセクションでは、基になるデータ ソース (SQL Server、SAP HANA、Teradata など) に対して SPN を既に構成してあるものとします。This section assumes you have already configured SPNs for your underlying data sources (such as SQL Server, SAP HANA, Teradata, so on). これらのデータ ソース サーバーの SPN を構成する方法については、それぞれのデータベース サーバーの技術ドキュメントをご覧ください。To learn how to configure those data source server SPNs, please refer to technical documentation for the respective database server. アプリで必要な SPN について説明されているブログ投稿もご覧ください。You can also look at the blog post that describes What SPN does your app require?

次の手順では、ゲートウェイ コンピューターとデータベース サーバー (SQL Server データベース) の 2 つのコンピューターで構成されるオンプレミス環境を想定します。また、この例では次の設定と名前を使います。In the following steps we assume an on-premises environment with two machines: a gateway machine and a database server (SQL Server database), and for the sake of this example we'll also assume the following settings and names:

  • ゲートウェイのコンピューター名: PBIEgwTestGWGateway machine name: PBIEgwTestGW
  • ゲートウェイのサービス アカウント: PBIEgwTest\GatewaySvc (アカウントの表示名: Gateway Connector)Gateway service account: PBIEgwTest\GatewaySvc (account display name: Gateway Connector)
  • SQL Server データ ソースのコンピューター名: PBIEgwTestSQLSQL Server data source machine name: PBIEgwTestSQL
  • SQL Server データ ソースのサービス アカウント: PBIEgwTest\SQLServiceSQL Server data source service account: PBIEgwTest\SQLService

これらの例の名前と設定を使うと、構成手順は次のようになります。Given those example names and settings, the configuration steps are the following:

  1. ドメイン管理者権限で、[Active Directory ユーザーとコンピューター] を起動します。With domain administrator rights, launch Active Directory Users and Computers.
  2. ゲートウェイのサービス アカウント (PBIEgwTest\GatewaySvc) を右クリックし、[プロパティ] を選びます。Right-click on the gateway service account (PBIEgwTest\GatewaySvc) and select Properties.
  3. [委任] タブを選びます。Select the Delegation tab.
  4. [指定されたサービスへの委任でのみこのコンピューターを信頼する] をオンにします。Select Trust this computer for delegation to specified services only.
  5. [任意の認証プロトコルを使う] をオンにします。Select Use any authentication protocol.
  6. [このアカウントが委任された資格情報を提示できるサービス][追加] を選びます。Under the Services to which this account can present delegated credentials: select Add.
  7. 新しいダイアログで、[ユーザーまたはコンピューター] を選択します。In the new dialog, select Users or Computers.
  8. SQL Server データベース サービスのサービス アカウント (PBIEgwTest\SQLService) を入力し、[OK] を選びます。Enter the service account for the SQL Server Database service (PBIEgwTest\SQLService) and select OK.
  9. データベース サーバー用に作成した SPN を選びます。Select the SPN that you created for the database server. この例では、SPN は MSSQLSvc で始まります。In our example, the SPN will begin with MSSQLSvc. データベース サービスに FQDN と NetBIOS 両方の SPN を追加した場合は、両方とも選びます。If you added both the FQDN and the NetBIOS SPN for your database service, select both. 1 つだけしか表示されない場合があります。You may only see one.
  10. [OK]を選択します。Select OK. リストに SPN が表示されます。You should see the SPN in the list now.
  11. 必要に応じて、[展開済み] を選んで FQDN SPN と NetBIOS SPN を両方表示できます。Optionally, you can select Expanded to show both the FQDN and NetBIOS SPN in
  12. [展開済み] をオンにした場合、ダイアログの表示は次のようになります。The dialog will look similar to the following if you checked Expanded.

  13. [OK] を選択します。Select OK.

    最後に、ゲートウェイ サービス (この例では PBIEgwTestGW) を実行しているコンピューターで、ゲートウェイ サービス アカウントにローカル ポリシー "認証後にクライアントを偽装" を付与する必要があります。Finally, on the machine running the gateway service (PBIEgwTestGW in our example), the gateway service account must be granted the local policy “Impersonate a client after authentication”. これは、ローカル グループ ポリシー エディター (gpedit) で実行/確認できます。You can perform/verify this with the Local Group Policy Editor (gpedit).

  14. ゲートウェイ コンピューターで、gpedit.msc を実行します。On the gateway machine, run: gpedit.msc
  15. [ローカル コンピューター ポリシー] > [コンピューターの構成] > [Windows の設定] > [セキュリティの設定] > [ローカル ポリシー] > [ユーザー権利の割り当て] の順に移動します (次の図を参照)。Navigate to Local Computer Policy > Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment, as shown in the following image.

  16. [ユーザー権利の割り当て] のポリシーの一覧で、[認証後にクライアントを偽装] を選びます。From the list of policies under User Rights Assignment, select Impersonate a client after authentication.

    右クリックして、[認証後にクライアントを偽装][プロパティ] を開き、アカウントの一覧を確認します。Right-click and open the Properties for Impersonate a client after authentication and check the list of accounts. ゲートウェイ サービス アカウント (PBIEgwTest\GatewaySvc) が含まれている必要があります。It must include the gateway service account (PBIEgwTest\GatewaySvc).

  17. [ユーザー権利の割り当て] のポリシーの一覧から、[オペレーティング システムの一部として機能 (SeTcbPrivilege)] を選びます。From the list of policies under User Rights Assignment, select Act as part of the operating system (SeTcbPrivilege). アカウントの一覧にゲートウェイ サービス アカウントが含まれることも確認します。Ensure that the gateway service account is included in the list of accounts as well.
  18. オンプレミス データ ゲートウェイ サービス プロセスを再起動します。Restart the on-premises data gateway service process.

Power BI レポートを実行するRunning a Power BI report

この記事でこれまでに説明したすべての構成手順が完了すると、Power BI の [Manage Gateway](ゲートウェイの管理) ページを使ってデータ ソースを構成し、[詳細設定] で SSO を有効にした後、そのデータ ソースに対するレポートとデータセットのバインドを発行できます。After all the configuration steps outlined earlier in this article have been completed, you can use the Manage Gateway page in Power BI to configure the data source, and under its Advanced Settings, enable SSO, then publish reports and datasets binding to that data source.

この構成は、ほとんどの場合に機能します。This configuration will work in most cases. ただし、Kerberos については、環境に応じて構成が異なる可能性があります。However, with Kerberos there can be different configurations depending on your environment. レポートがまだ読み込まれない場合は、ドメイン管理者に連絡してさらに詳しく調査する必要があります。If the report still won't load, you'll need to contact your domain administrator to investigate further.

ゲートウェイをドメイン アカウントに切り替えるSwitching the gateway to a domain account

この記事の前半で、オンプレミス データ ゲートウェイのユーザー インターフェイスを使って、ゲートウェイをローカル サービス アカウントからドメイン アカウントとして実行するように切り替えることを説明しました。Earlier in this article, we discussed switching the gateway from a local service account to run as a domain account, using the on-premises data gateway user interface. そのために必要な手順を以下に示します。Here are the steps necessary to do so.

  1. [オンプレミスのデータ ゲートウェイ] 構成ツールを起動します。Launch the on-premises data gateway configuration tool.

  2. メイン ページの [サインイン] ボタンを選び、Power BI アカウントでサインインします。Select the Sign-in button on the main page, and sign in with your Power BI account.
  3. サインインが完了した後、[サービスの設定] タブを選びます。After sign-in is completed, select the Service Settings tab.
  4. 次の図に示すように、[アカウントの変更] をクリックしてガイド付きチュートリアルを開始します。Click Change account to start the guided walk-through, as shown in the following figure.

次の手順Next steps

オンプレミス データ ゲートウェイDirectQuery の詳細については、次のリソースをご覧ください。For more information about the on-premises data gateway and DirectQuery, check out the following resources: