はじめに
社外のベンダーを Entra ID にゲスト（B2B）として招き、AWS の EC2 にオンプレミス データ ゲートウェイを立ててもらう構成で、ゲートウェイの登録が2回止まりました。
- ベンダー（ゲスト）のアカウントでは登録できなかった
- テナントの社員のアカウントに切り替えると、サインインが
0xCAA80000で止まった
この2つの原因と対応をまとめます。ベンダーをゲストで招いて Power BI を構築する方（招く側・招かれる側のどちらも）向けです。
結論
| 登録するアカウント | ゲートウェイ インストーラーの制限 | 登録 | 理由 |
|---|---|---|---|
| ベンダー（ゲスト／B2B） | 関係なし | ✕ | ゲストはゲートウェイを入れて組織につなげない（公式に記載） |
| テナントの社員 | 制限なし（既定） | ○ | 既定では組織のだれでも登録できる |
| テナントの社員 | 制限あり・許可リストにいない | ✕ | 登録の段階でエラーになる |
| テナントの社員 | 制限あり・許可リストにいる | ○ | — |
ゲートウェイ インストーラーの制限とは
| 項目 | 内容 |
|---|---|
| 何の設定か | オンプレミス データ ゲートウェイを、テナントにインストール・登録できる人を絞る設定 |
| 設定する場所 | Power Platform 管理センター →「データ」→「ゲートウェイ インストーラーの管理」 |
| 既定 | オフ（組織のだれでも登録できる） |
| 設定できる人 | グローバル管理者、Power BI サービス管理者（ゲートウェイの管理者はできない） |
| 追加の単位 | 1人ずつ（グループは不可） |
| 対象外 | 個人モードのゲートウェイ |
出典：View and manage on-premises data gateways（Manage gateway installers）
環境
| 項目 | 内容 |
|---|---|
| データ | AWS の Redshift（プライベートな VPC の中にあるため、ゲートウェイが必要） |
| ゲートウェイ | AWS の EC2（Windows）に、オンプレミス データ ゲートウェイ（標準モード） |
| Power BI | テナントのワークスペース |
| 構築する人 | 社外のベンダー（テナントのゲスト） |
| テナントのサインイン | AD FS によるフェデレーション（AD FS は AWS の別の VPC） |
構成の全体は、末尾の付録に載せています。
経緯
| 起きたこと | 対応 |
|---|---|
| ベンダーのアカウントで登録しようとしたが、進まない | ユーザーの種類を見ると「ゲスト」だった |
| ゲストのままでは登録できない | テナントの社員のアカウントで登録する方針にし、インストーラーの許可リストにも追加 |
社員のアカウントで試すと、0xCAA80000 で止まる |
リダイレクト先から AD FS だと分かり、VM から AD FS への通信を許可する申請をした |
ゲストかどうかの確かめ方
Entra 管理センター（または Azure ポータル）でユーザーを開き、プロパティの「ユーザーの種類」を見ます。「ゲスト」なら、そのアカウントではゲートウェイを登録できません。
ゲストではゲートウェイを登録できない
B2B のページの「考慮事項と制限事項」に書かれています。
Guest users can't install a Power BI Gateway and connect it to your organization
ゲートウェイの FAQ にも、B2B ゲストが関わるテナント間のアクセスは正式にはサポートしない、とあります。ゲストにはほかに、Power BI Desktop からの直接発行もできません（同じ B2B のページ）。
| 検討した方法 | 結果 |
|---|---|
| ベンダーのアカウントをゲストからメンバーに変える | 社外の人をメンバーにするのは避けたいため見送り |
| テナントの社員のアカウントで登録する | 採用 |
社内メンバーのアカウントでは 0xCAA80000 で止まった
3 で AD FS に届かず、0xCAA80000 で止まる
| 項目 | 内容 |
|---|---|
| エラーコード | 0xCAA80000 |
| 表示された文言 | 現在、いずれかのサービスに接続できないようです。後でもう一度試すか、問題が解決しない場合は、ヘルプデスクにお問い合わせください |
| 止まる場所 | メールアドレスを入れた直後（パスワードの画面まで行かない） |
| ブラウザで試すと | Edge・Chrome は ERR_TUNNEL_CONNECTION_FAILED、IE は INET_E_SECURITY_PROBLEM
|
このコードで検索すると、Teams や Outlook のサインインの話ばかりで、ゲートウェイの情報はほとんど見つかりませんでした。そこで、VM の上で順番に確かめました。
| 確かめたこと | やり方 | 結果 | 分かったこと |
|---|---|---|---|
| リダイレクト先 | ブラウザのアドレスバー |
/adfs/ls/ と wtrealm=urn:federation:MicrosoftOnline を含む URL |
テナントのサインインは AD FS のフェデレーション |
| 名前解決 | nslookup <AD FS のホスト名> |
AWS の内部 NLB の名前と、プライベート IP | AD FS は AWS の別の VPC にある |
| 443 に届くか | Test-NetConnection <AD FS のホスト名> -Port 443 |
TcpTestSucceeded : False |
VPC 間の経路か、セキュリティグループで止まっている |
| プロキシ | netsh winhttp show proxy |
AD FS のホスト名がバイパスに入っていない | 経路が開いても、プロキシに投げてしまう |
原因：Entra ID に拒否されたのではなく、リダイレクト先の AD FS に VM から接続できなかったことでした。ゲートウェイのふだんの通信（Azure Relay）とは別に、登録のときだけ AD FS への 443 が要ります。
対応：VM から AD FS（NLB）への 443 を許可するようにいたしました。
事前に決めておくこと
| 決めること | 理由 | 出典 |
|---|---|---|
| だれのアカウントで登録するか | ゲストでは登録できない | B2B のページ |
| ゲートウェイの名前 | テナント内で重複できない | インストールのページ |
| 回復キーをだれが保管するか | 後から取り出せない。移行や復旧で使う | 同上 |
| ゲートウェイのバージョン | 2026年5月より前のビルドは、サインインが完了しないことがある。最新版に入れ直しておく | FAQ |
まとめ
- ゲスト（B2B）のベンダーは、ゲートウェイを登録できない。テナントの社員のアカウントで登録する
- インストーラーを制限しているテナントでは、その社員を許可リストに入れる
- AD FS（フェデレーション）のテナントでは、VM から AD FS への 443 も確かめる
付録：全体の構成
番号の順に流れが赤く光ります
| 番号 | 流れ |
|---|---|
| 1 | 更新スクリプトが Entra ID からトークンを取る（サービスプリンシパル） |
| 2 | REST API で更新を指示する |
| 3 | Power BI がクエリと暗号化した資格情報を、ゲートウェイ用のキューに入れる |
| 4 | ゲートウェイ クラウド サービスが、要求を Azure Relay に渡す |
| 5 | ゲートウェイが Azure Relay を定期的に見に行き（ポーリング）、要求を受け取る |
| 6 | ゲートウェイが資格情報を復号し、Redshift にクエリを投げて結果を受け取る |
| 7 | 結果をいったん EC2 に保存し（スプール）、Azure Relay を通してモデルに返す |
3〜7 は公式ドキュメント（On-premises data gateway architecture）の説明に合わせています。ゲートウェイからの通信は外向きだけで、受信のポートは要りません。
ゲートウェイが使う通信先とポート
| 通信先 | ポート | 用途 |
|---|---|---|
*.servicebus.windows.net |
443、9350〜9354 | Azure Relay（5・7） |
*.servicebus.windows.net |
5671〜5672 | AMQP |
login.microsoftonline.com ほか |
443 | ゲートウェイ アプリのサインイン（登録のとき） |
| テナントの AD FS | 443 | フェデレーションのときのサインイン（登録のとき） |
出典：Adjust communication settings for the on-premises data gateway
参考
Discussion
