オンプレミス データ ゲートウェイのプロキシ設定を構成する
作業環境では、プロキシ経由でインターネットにアクセスすることが必要な場合があります。 この要件によって、Microsoft オンプレミス データ ゲートウェイがサービスに接続できなくなることがあります。
superuser.com の次の投稿では、ネットワークにプロキシがあるかどうかを判断する方法について説明されています: 使用しているプロキシ サーバーを確認するにはどうすればよいですか? (SuperUser.com)。
ほとんどのゲートウェイ構成設定は、オンプレミス データ ゲートウェイ アプリを使用して変更できますが、プロキシ情報は .NET 構成ファイル内で構成されます。 構成ファイルの場所と名前は、使用しているゲートウェイによって異なります。
オンプレミス データ ゲートウェイでのプロキシの使用に関連づけられている構成ファイルが 4 個存在します。 次の 2 つの主要な構成ファイルは、ゲートウェイとその構成プロセスに適用されます。
- 1 つ目のファイルは、実際にゲートウェイを構成する構成画面のためのものです。 ゲートウェイの構成に問題がある場合は、次のファイルを確認してください: C:\Program Files\On-premises data gateway\enterprisegatewayconfigurator.exe.config。オンプレミス データ ゲートウェイ (個人用モード) では、対応するファイルは %LocalAppData%\Microsoft\オンプレミス データ ゲートウェイ (個人用モード)\PersonalGatewayConfigurator.exe.config です。
- 2 つ目のファイルは、ゲートウェイを使ってクラウド サービスと対話する実際の Windows サービスのためのものです。 このファイルは要求を処理します: C:\Program Files\On-premises data gateway\Microsoft.PowerBI.EnterpriseGateway.exe.config。オンプレミス データ ゲートウェイ (個人用モード) では、対応するファイルは %LocalAppData%\Microsoft\オンプレミス データ ゲートウェイ (個人用モード)\Microsoft.PowerBI.DataMovement.PersonalGateway.exe.config です。
プロキシの構成を変更する場合は、両方のファイルでプロキシの構成がまったく同じになるように、これらのファイルを編集する必要があります。
ゲートウェイがプロキシを介してクラウド データ ソースに接続するには、3 番目の構成ファイルを編集する必要があります。
- C:\Program Files\On-premises data gateway\m\Microsoft.Mashup.Container.NetFX45.exe.config
オンプレミス データ ゲートウェイ (個人用モード) では、対応するファイルは %LocalAppData%\Microsoft\オンプレミス データ ゲートウェイ (個人用モード)\m\Microsoft.Mashup.Container.NetFX45.exe.config です。
ゲートウェイがプロキシ経由で Fabric Pipelines サービスに接続するには、4 番目の構成ファイルを編集する必要があります。
- C:\Program Files\On-premises data gateway\FabricIntegrationRuntime\5.0\Shared\Fabricworker.exe.config
次のセクションでは、これらのファイルを編集する方法について説明します。
プロキシ設定の構成
次のサンプルは、2 つの主要な構成ファイルの両方にある既定のプロキシ構成を示しています。
<system.net>
<defaultProxy useDefaultCredentials="true" />
</system.net>
既定の構成は、Windows 認証で機能します。 プロキシで別の認証方法を使う場合は、設定を変更する必要があります。 よくわからない場合は、ローカル管理者に問い合わせてください。
基本プロキシ認証はお勧めしません。 基本プロキシ認証を使うと、プロキシ認証エラーが発生し、ゲートウェイが適切に構成されなくなる可能性があります。 解決するには、強力なプロキシ認証メカニズムを使用します。
既定の資格情報を使用することに加え、<proxy>
要素を追加して、プロキシ サーバー設定を詳細に定義することができます。 たとえば、bypassonlocal パラメーターを false に設定することで、ローカル リソースの場合でも、オンプレミス データ ゲートウェイでプロキシが常に使われるように指定できます。 この設定は、ゲートウェイから送信されるすべての HTTPS 要求をプロキシ ログ ファイルで追跡する場合のトラブルシューティングに役立ちます。 次のサンプル構成では、すべての要求を IP アドレス 192.168.1.10 の特定のプロキシ経由で行う必要があることを指定します。
<system.net>
<defaultProxy useDefaultCredentials="true">
<proxy
autoDetect="false"
proxyaddress="http://192.168.1.10:3128"
bypassonlocal="false"
usesystemdefault="false"
/>
</defaultProxy>
</system.net>
また、ゲートウェイを通してクラウド データ ソースに接続する場合は、Microsoft.Mashup.Container.NetFX45.exe.config ファイルも編集する必要があります。
このファイル内の <configurations>
セクションを展開して以下の内容を含めてから、proxyaddress
属性を実際のプロキシ情報で更新します。 次の例では、IP アドレスが 192.168.1.10 の特定のプロキシ経由で、すべてのクラウド要求がルーティングされます。
<configuration>
<system.net>
<defaultProxy useDefaultCredentials="true" enabled="true">
<proxy proxyaddress="http://192.168.1.10:3128" bypassonlocal="true" />
</defaultProxy>
</system.net>
</configuration>
すべてのインターネット通信にプロキシが必要である場合、特にネットワークがセキュリティで保護されロックダウンされている企業で使用する場合は、3 番目のファイルの構成が必要になる場合があります。 ゲートウェイ通信にプロキシが必要な場合は、コンテナーからのインターネット トラフィックにも必要になる場合があります。 この場合、コンテナーが外部 (インターネット) クエリを実行するまで、ゲートウェイが正常に動作しているように見える場合があります。 この問題は特に、オンプレミス データの結果のクエリを Azure Data Lake Storage にプッシュしようとするデータフローに当てはまります。 ただし、ゲートウェイ クエリがオンプレミスのセマンティック モデルをインターネットにバインドされたセマンティック モデルとマージする場合にも適用されます。
.NET 構成ファイルのプロキシ要素の構成について詳しくは、「defaultProxy 要素 (ネットワーク設定)」をご覧ください。
出力先のゲートウェイを構成する
さらに、出力先でゲートウェイを使用するには、ゲートウェイがファイアウォールまたはプロキシを通過して宛先データ ソースに到達できるように構成する必要がある場合があります。 プロキシ サーバーを使用している場合、このパススルーでは、適切な宛先 (LakeHouse の場合は *.datawarehouse.pbidedicated.windows.net、Data Lake の場合は *.dfs.core.windows.net など) への URL の登録を有効にする必要がある場合があります。
Note
LakeHouse の宛先を使用している場合は、少なくとも 2023 年 5 月リリースのゲートウェイを実行している必要があります。 このリリース以前のバージョンのゲートウェイでは、Lakehouse コネクタを使用できません。
ゲートウェイ サービス アカウントをドメイン ユーザーに変更する
前に説明したように、既定の資格情報を使用するようにプロキシ設定を構成すると、プロキシで認証の問題が発生することがあります。 この問題は、既定のサービス アカウントがサービス SID であり、認証済みのドメイン ユーザーでない場合に発生します。 要求を認証するために組織のプロキシにドメイン アカウントが必要な場合は、ゲートウェイのサービス アカウントをドメイン サービス アカウントに変更できます。 この変更により、プロキシでの適切な認証が可能になります。 ゲートウェイ サービス アカウントを変更する方法について詳しくは、「オンプレミス データ ゲートウェイ サービス アカウントを変更する」をご覧ください。
Note
パスワードをリセットする必要がないように、管理サービス アカウントを使うことをお勧めします。 Active Directory 内で管理されたサービス アカウントを作成する方法を参照してください。