組織のユーザーはオンプレミス データ (アクセス認証を取得済みの) にアクセスできますが、オンプレミス データ ソースに接続するには、事前にオンプレミス データ ゲートウェイをインストールし、設定しておく必要があります。 このゲートウェイにより、クラウドのユーザーとオンプレミス データ ソースの間のバックグラウンドの通信が迅速かつ安全な方法で確立されます。

ゲートウェイのインストールと構成は、通常、管理者によって行われます。 この作業には、オンプレミスのサーバーの特別な知識と、場合によっては、サーバー管理者のアクセス許可が必要です。

この記事では、ゲートウェイをインストールして構成する方法の詳しい手順は説明しません。 そのために、「オンプレミス データ ゲートウェイ」を必ず参照してください。 この記事の目的は、ゲートウェイが機能するしくみを理解できるように、その詳細を説明することです。 また、Azure Active Directory と Analysis Services の両方におけるユーザー名とセキュリティの詳細も少し説明します。さらに、サインインでユーザーが使用した電子メール アドレス、ゲートウェイ、Active Directory をクラウド サービスが利用し、オンプレミスのデータにセキュリティで保護された接続を行い、クエリを実行する方法について説明します。

ゲートウェイのしくみ

on-prem-data-gateway-how-it-works

最初に、オンプレミスのデータ ソースに接続されたレポートを操作した場合に、どのような処理が行われるかを見てみましょう。

メモ:

Power BI の場合、ゲートウェイのデータ ソースを構成する必要があります。

  1. クエリは、オンプレミスのデータ ソースの暗号化された資格情報を使用してクラウド サービスによって作成され、キューに送信されて、ゲートウェイで処理されます。

  2. ゲートウェイ クラウド サービスは、クエリを分析し、要求を Azure Service Bus へプッシュします。

  3. オンプレミス データ ゲートウェイは、Azure Service Bus へのポーリングを実行して保留中の要求の有無を確認します。

  4. ゲートウェイはクエリを取得して資格情報の暗号化を解除し、その資格情報を使用してデータ ソースに接続します。

  5. クエリは、ゲートウェイによってデータ ソースへ送信され、実行されます。

  6. データ ソースからゲートウェイに結果が返送され、さらにクラウド サービスに送信されます。 結果がサービスで使用されます。

使用可能なデータ ソースの種類の一覧

データ ソース Live/DirectQuery ユーザー構成による手動更新またはスケジュールされた更新
Analysis Services 表形式 はい はい
Analysis Services 多次元 はい はい
ファイル いいえ はい
フォルダー いいえ はい
IBM DB2 いいえ はい
IBM Informix データベース いいえ はい
Impala はい はい
MySQL いいえ はい
OData いいえ はい
ODBC いいえ はい
Oledb いいえ はい
Oracle はい はい
PostgresSQL いいえ はい
SAP BW いいえ はい
SAP HANA はい はい
SharePoint リスト (オンプレミス) いいえ はい
SQL Server はい はい
Sybase いいえ はい
Teradata はい はい
Web いいえ はい

アカウントにサインインする

ユーザーは職場または学校のアカウントでサインインします。 これは組織アカウントです。 Office 365 サービスにサインアップし、実際の職場のメールを指定しなかった場合、nancy@contoso.onmicrosoft.com のようになります。 クラウド サービス内では、アカウントは Azure Active Directory (AAD) のテナント内に保存されます。 ほとんどの場合、AAD アカウントの UPN はメール アドレスに一致します。

オンプレミス データ ソースの認証

保存された資格情報は、Analysis Services を除き、オンプレミス データ ソースにゲートウェイから接続するために使用されます。 個々のユーザーに関係なく、ゲートウェイは保存されている資格情報を利用して接続します。

ライブ Analysis Services データ ソースの認証

Analysis Services をユーザーが操作するたびに、有効なユーザー名がゲートウェイに渡され、次にオンプレミスの Analysis Services サーバーに渡されます。 ユーザー プリンシパル名 (UPN)、通常、クラウドにサインインするときに使用する電子メール アドレスは、有効なユーザーとして Analysis Services に渡すものです。 UPN は接続プロパティ EffectiveUserName に渡されます。 この電子メール アドレスは、ローカルの Active Directory ドメイン内で定義されている UPN と一致する必要があります。 UPN は、Active Directory アカウントのプロパティです。 サーバーにアクセスするには、その Windows アカウントが Analysis Services ロールに存在する必要があります。 Active Directory で一致を検出できない場合、ログインは正常に実行されません。

Analysis Services は、このアカウントに基づいて、フィルター処理も提供できます。 フィルター処理は、ロール ベースのセキュリティまたは行レベルのセキュリティで実行できます。

ロール ベース セキュリティ

モデルでは、ユーザー ロールに基づいてセキュリティが提供されます。 特定のモデル プロジェクトに対してロールが定義されるのは、SQL Server Data Tools – Business Intelligence (SSDT-BI) でのオーサリング中、または SQL Server Management Studio (SSMS) を使用してモデルをデプロイした後です。 ロールに含まれるメンバーは、Windows ユーザー名または Windows グループによって決まります。 ロールは、ユーザーがモデルに対してクエリまたは操作を実行するためのアクセス許可を定義します。 ほとんどのユーザーは、読み取りアクセス許可を持つロールに属します。 その他のロールは管理者向けで、項目を処理するアクセス許可、データベースの機能を管理するアクセス許可、他のロールを管理するアクセス許可を持つものがあります。

行レベルのセキュリティ

行レベルのセキュリティは、Analysis Services の行レベルのセキュリティに固有です。 モデルでは、動的な行レベルのセキュリティを提供できます。 ユーザーが少なくとも 1 つのロールに属する場合とは異なり、表形式モデルに動的なセキュリティは必要ではありません。 動的なセキュリティでは、上位レベルから、特定テーブル内の特定の行のデータに対してユーザーの読み取りアクセス権が定義されます。 ロールの場合と同様、動的な行レベルのセキュリティは、ユーザーの Windows ユーザー名に依存します。

ユーザーがモデルのデータを閲覧したりクエリを実行したりできるかどうかは、第 1 にそのユーザーの Windows ユーザー アカウントがメンバーとなっているロールによって決まり、第 2 に動的な行レベルのセキュリティ (構成されている場合) によって決まります。

モデルでのロールと動的な行レベル セキュリティの実装については、この記事では説明しません。 詳細については、MSDN の「ロール (SSAS 表形式)」と「(Analysis Services - 多次元データ) のセキュリティ ロール」を参照してください。 また、表形式モデルのセキュリティに関するさらに詳細な情報については、「表形式 BI セマンティック モデルをセキュリティで保護する」というホワイトペーパーをダウンロードしてお読みください。

Azure Active Directory の役割

Microsoft クラウド サービスは、ユーザーの認証を処理するために Azure Active Directory を使用します。 Azure Active Directory は、ユーザー名とセキュリティ グループを含むテナントです。 通常、ユーザーがサインインに使用する電子メール アドレスはアカウントの UPN と同じです。

ローカル Active Directory の役割

Analysis Services に接続するユーザーがデータの読み取りアクセス許可を持つロールに属しているかどうかを判断するため、サーバーは、AAD からゲートウェイ、Analysis Services サーバーの順に渡された有効なユーザー名を変換する必要があります。 Analysis Services サーバーは、Windows Active Directory ドメイン コントローラー (DC) に有効なユーザー名を渡します。 Active Directory DC は、ローカル アカウントで、有効なユーザー名が有効 UPN であることを検証し、Analysis Services サーバーにそのユーザーの Windows ユーザー名を返します。

EffectiveUserName は、ドメインに参加していない Analysis Services サーバーで使用できません。 ログイン エラーを回避するには、Analysis Services サーバーをドメインに参加させる必要があります。

自分の UPN を確認する方法

自分の UPN がわからないけれども、自分がドメイン管理者ではない場合もあります。 ワークステーションから次のコマンドを実行して、自分のアカウントの UPN を確認できます。

whoami /upn

結果は電子メール アドレスに似ていますが、これはローカル ドメイン アカウントの UPN です。 ライブ接続に Analysis Services データ ソースを使用している場合、これはゲートウェイから EffectiveUserName に渡されたものに一致する必要があります。

Analysis Services データ ソースのユーザー名をマッピングする

Power BI では、Analysis Services データ ソースのユーザー名をマッピングできます。 Power BI のログイン ユーザー名を、Analysis Services 接続の有効なユーザー名に渡される名前にマッピングする規則を構成できます。 ユーザー名のマッピング機能は、AAD のユーザー名がローカル Active Directory の UPN に一致しないときの回避策として優れています。 たとえば、メール アドレスが nancy@contoso.onmicrsoft.com の場合、それを nancy@contoso.com にマッピングできます。その値がゲートウェイに渡されます。 詳細については、ユーザー名のマッピング方法に関するページを参照してください。

オンプレミスの Active Directory を Azure Active Directory と同期する

Analysis Services ライブ接続を使用する場合、ローカル Active Directory アカウントが Azure Active Directory に一致すると便利です。 UPN はアカウント間で一致する必要があるためです。

クラウドサービスは、Azure Active Directory 内のアカウントのみを認識します。 ローカル Active Directory にアカウントを追加したかどうかは問題ではなく、AAD に存在しなければ、使用できません。 ローカル Active Directory アカウントと Azure Active Directory はさまざまな方法で一致させることができます。

  1. Azure Active Directory にアカウントを手動で追加できます。

    Azure ポータルで、あるいは Office 365 Admin ポータル内でアカウントを作成できます。アカウント名はローカル Active Directory アカウントの UPN と一致します。

  2. Azure AD Connect ツールを使用し、ローカル アカウントと Azure Active Directory テナントを同期させることができます。

    Azure AD Connect ツールには、ディレクトリとパスワードの同期オプションがあります。 テナント管理者またはローカル ドメイン管理者ではない場合、IT 管理者に問い合わせ、これを構成してもらう必要があります。

  3. Active Directory Federation Services (ADFS) を構成できます。

    Azure AD Connect ツールを使用し、ADFS サーバーを AAD テナントに関連付けることができます。 ADFS では、上記のディレクトリ同期が利用されますが、シングル サインオン (SSO) が可能です。 たとえば、職場のネットワークにいる場合、クラウド サービスにアクセスし、サインインに進むとき、ユーザー名またはパスワードの入力が求められません。 組織でこれが利用できる場合、IT 管理者と話し合う必要があります。

Azure AD Connect を利用すると、UPN は AAD とローカル Active Directory 間で一致します。

メモ:

Azure AD Connect ツールでアカウントを同期させると、AAD テナント内に新しいアカウントが作成されます。

ゲートウェイについて

ゲートウェイは、クラウドとオンプレミス サーバー間のブリッジとして機能します。 クラウドとゲートウェイ間のデータ転送は、Azure Service Bus を介してセキュリティで保護されます。 Service Bus は、ゲートウェイでの送信接続を使用して、クラウドとオンプレミスのサーバーの間にセキュリティで保護されたチャネルを作成します。 オンプレミス ファイアウォールで開く必要のある受信接続はありません。

Analysis Services データ ソースを持っている場合は、Analysis Services サーバーと同じフォレストまたはドメインに結合しているコンピューターにゲートウェイをインストールする必要があります。

ゲートウェイがサーバーに近づけば近づくほど、接続は速くなります。 データ ソースと同じサーバー上にゲートウェイを取得できる場合、それはゲートウェイとサーバー間のネットワーク遅延を回避するのに最適です。

次に行うこと

ゲートウェイをインストールした後は、そのゲートウェイのデータ ソースを作成します。 データ ソースの追加は、[ゲートウェイの管理] 画面で行うことができます。 詳細については、データ ソースの管理に関する記事をご覧ください。

データ ソースの管理 - Analysis Services
データ ソースの管理 - SAP HANA
データ ソースの管理 - SQL Server
データ ソースの管理 - Oracle
データ ソースの管理 - インポート/スケジュールされた更新

うまくいかない場合

場合によっては、ゲートウェイのインストールが失敗することがあります。 または、ゲートウェイのインストールが成功したように見えても、サービスがそれを処理できない場合があります。 多くの場合、それは簡単な要因です (ゲートウェイがデータ ソースにサインインするのに使用する資格情報のパスワードなど)。

その他のケースとして、ユーザーがサインインする電子メール アドレスの種類に問題がある場合や、Analysis Services が有効なユーザー名を解決できない場合があります。 相互に信頼関係を持つ複数のドメインがあり、ゲートウェイのあるドメインと、Analysis Services のあるドメインが異なっていると、そのことが問題の原因になる場合があります。

ゲートウェイのトラブルシューティングについては、この記事ではなく、トラブルシューティングの手順に関する別の記事で説明します。「オンプレミス データ ゲートウェイのトラブルシューティング」をご覧ください。 何も問題が起きないことを願っています。 もし問題が起きてしまった場合は、この機能のしくみを理解しておくことと、トラブルシューティングの記事が役立ちます。

サインイン アカウント

ユーザーは職場または学校のアカウントでサインインします。 これは組織アカウントです。 Office 365 サービスにサインアップし、実際の職場のメールを指定しなかった場合、nancy@contoso.onmicrosoft.com のようになります。 クラウド サービス内では、アカウントは Azure Active Directory (AAD) のテナント内に保存されます。 ほとんどの場合、AAD アカウントの UPN はメール アドレスに一致します。

Windows サービス アカウント

オンプレミス データ ゲートウェイは、Windows サービスのログオン資格情報に NT SERVICE\PBIEgwService を使用するように設定されています。 既定では、この資格情報には、サービスとしてログオンの権限があります。 これは、ゲートウェイのインストール先コンピューターのコンテキストです。

メモ:

個人モードを選択した場合は、Windows サービス アカウントを個別に構成します。

これは、オンプレミスのデータ ソースへの接続に使用するアカウントではありません。 また、クラウド サービスへのサインインに使用する職場または学校のアカウントでもありません。

認証のためにプロキシ サーバーで問題が発生する場合は、Windows サービス アカウントをドメイン ユーザーまたは管理されたサービス アカウントに変更する必要があります。 プロキシ構成でアカウントを変更する方法についてはこちらをご覧ください。

ポート

ゲートウェイは、Azure Service Bus への送信接続を作成します。 通信は、送信ポート TCP 443 (既定値)、5671、5672、9350 ~ 9354 で行われます。 ゲートウェイには、受信ポートは必要ありません。 詳細情報

ファイアウォールでデータ領域の IP アドレスをホワイトリストに登録することをお勧めします。 Microsoft Azure データ センター IP リストをダウンロードできます。 このリストは毎週更新されます。 ゲートウェイは、IP アドレスと完全修飾ドメイン名 (FQDN) を使って Azure Service Bus と通信します。 HTTPS を使用して通信するようにゲートウェイを強制している場合は、必ず FQDN のみを使用し、IP アドレスを使用した通信は行われません。

メモ:

Azure データ センター IP リストに列記されている IP アドレスは CIDR 表記です。 たとえば、10.0.0.0/24 は 10.0.0.0 ~ 10.0.0.24 の意味ではありません。 CIDR 表記についてはこちらをご覧ください。

ゲートウェイで使用される完全修飾ドメイン名の一覧を次に示します。

ドメイン名 送信ポート 説明
*.download.microsoft.com 80 インストーラーをダウンロードするために使用する HTTP です。
*.powerbi.com 443 HTTPS
*.analysis.windows.net 443 HTTPS
*.login.windows.net 443 HTTPS
*.servicebus.windows.net 5671-5672 Advanced Message Queuing Protocol (AMQP)
*.servicebus.windows.net 443, 9350-9354 TCP 上での Service Bus Relay のリスナー (Access Control のトークン取得のために 443 が必要)
*. frontend.clouddatahub.net 443 HTTPS
*.core.windows.net 443 HTTPS
login.microsoftonline.com 443 HTTPS
*.msftncsi.com 443 Power BI サービスがゲートウェイに到達できない場合に、インターネット接続をテストするために使用します。
*.microsoftonline-p.com 443 構成によっては認証に使用します。
メモ:

visualstudio.com または visualstudioonline.com へのトラフィックはアプリの洞察用であり、関数へのゲートウェイには必要ありません。

Azure Service Bus との強制的な HTTPS 通信

ゲートウェイと Azure Service Bus との間の通信に、直接 TCP ではなく HTTPS を使用するように強制できます。 これはパフォーマンスに影響する場合があります。 この操作を行うには、この段落の直後に続くコード スニペットに示すように、値を AutoDetect から Https に変更して、Microsoft.PowerBI.DataMovement.Pipeline.GatewayCore.dll.config ファイルを変更します。 このファイルは、既定では C:\Program Files\On-premises data gateway にあります。

<setting name="ServiceBusSystemConnectivityModeString" serializeAs="String">
    <value>Https</value>
</setting>

代わりに、2017 年 3 月のリリースから開始する、ゲートウェイのユーザー インターフェイスを使用して、ゲートウェイがこの動作を適用するように強制することができます。 ゲートウェイのユーザー インターフェイスで、[ネットワーク] を選択し、[Azure Service Bus connectivity mode] (Azure Service Bus 接続モード) を [オン] に切り替えます。

変更した後、[適用] を選ぶと (変更を行ったときにのみ表示されるボタン)、*ゲートウェイ Windows サービス*が自動的に再起動して、変更が有効になります。

将来の参照のためには、[サービス設定][今すぐ再起動] の順に選ぶことで、ユーザー インターフェイスのダイアログから*ゲートウェイ Windows サービス*を再起動できます。

ゲートウェイを再起動する方法

ゲートウェイは、Windows サービスとして実行されます。 他の Windows サービスのように、開始および停止できます。 これを行う方法は複数あります。 コマンド プロンプトを使用する方法を次に示します。

  1. ゲートウェイが実行されているコンピューターで、管理者のコマンド プロンプトを起動します。

  2. サービスを停止するには、次のコマンドを使用します。

    net stop PBIEgwService

  3. サービスを開始するには、次のコマンドを使用します。

    net start PBIEgwService

参照

オンプレミス データ ゲートウェイのトラブルシューティング
Azure Service Bus
Azure AD Connect
他にわからないことがある場合は、 Power BI コミュニティを利用してください