【Entra ID】クロステナントアクセス設定で相手先だけ拒否される時の双方向確認

会社でMicrosoft Entra ID(旧Azure Active Directory)のクロステナントアクセス設定を構成していると、「特定の相手先テナントからのアクセスだけが拒否されてしまう」という現象に悩まされることがあります。設定画面ではすべて許可しているつもりでも、実際の動作で片方向だけがブロックされてしまうケースは珍しくありません。この問題の原因は、双方向の設定が不整合であることや、片方のテナントで未設定の項目があることが大半です。この記事では、クロステナントアクセス設定で相手先だけ拒否される時の原因を具体的に切り分け、双方向での確認ポイントをわかりやすく解説します。

クロステナントアクセス設定の基本構造を理解する

クロステナントアクセス設定は、Entra IDテナント間でユーザー、グループ、アプリケーションのアクセスを制御する機能です。この設定は「インバウンド(受信)」と「アウトバウンド(送信)」の2方向で構成されており、各方向ごとに許可するテナント、ユーザー、条件を個別に定義します。相手先だけ拒否される状態は、この双方向のいずれかで設定漏れや矛盾が発生していることがほとんどです。

設定は「外部ID」→「クロステナントアクセス設定」から行います。各テナントで以下の3つの要素を設定する必要があります。

1. 組織の追加: 相手のテナントIDを登録します。
2. アクセス設定(インバウンド/アウトバウンド): それぞれの方向で「アクセスを許可」または「アクセスをブロック」を選択し、さらにユーザー/グループのスコープを設定します。
3. 信頼設定: 多要素認証やデバイスコンプライアンスなどの条件を信頼するかどうか、オプションで構成します。

双方向の確認では、自テナントのアウトバウンドと相手テナントのインバウンド、さらに自テナントのインバウンドと相手テナントのアウトバウンドがそれぞれ正しく設定されているかをペアでチェックすることが重要です。

相手先だけ拒否される代表的な原因と失敗パターン

原因1: 片方のテナントで設定が未完了

最も多いのは、自テナントで相手テナントを追加してアウトバウンドを許可しても、相手テナント側で自テナントのインバウンド設定が行われていないケースです。例えば、自テナントから相手テナントのリソースにアクセスしようとした場合、自テナントのアウトバウンド許可に加えて、相手テナントのインバウンド許可が必要になります。相手テナント管理者が設定を忘れていると、「アクセス拒否」エラーが発生します。

原因2: ユーザーまたはグループのスコープ不一致

テナント全体ではなく、特定のユーザーやグループにのみアクセスを許可している場合、対象外のユーザーは拒否されます。自テナントのアウトバウンド設定で「すべてのユーザー」に許可していても、相手テナントのインバウンド設定で「特定のグループ」だけ許可していると、そのグループに属さないユーザーはブロックされます。逆も同様です。

原因3: 信頼設定の条件によるブロック

クロステナントアクセス設定では、多要素認証の要求やデバイスコンプライアンスのチェックなど、信頼設定を構成できます。例えば、自テナントが相手テナントのMFA要求を信頼しない設定にしている場合、相手側がMFAを要求しているとアクセスが拒否されます。また、条件付きアクセスポリシーと競合することもあります。

原因	発生シナリオ	確認ポイント
設定未完了	自テナントから相手テナントの共有リソースにアクセスできない	相手テナントのインバウンド設定に自テナントが追加されているか
スコープ不一致	一部のユーザーのみアクセスできる、またはできない	両テナントのユーザー/グループスコープが一致しているか
信頼設定の競合	多要素認証やデバイスコンプライアンスの要求でアクセスが弾かれる	互いの信頼設定と条件付きアクセスのログを確認

双方向確認のための具体的な手順(自テナント管理者向け)

問題を切り分けるためには、自テナントと相手テナントの両方の設定を順番に確認する必要があります。以下の手順を実施してください。

1. 自テナントのアウトバウンド設定を確認する: Entra ID管理センターで「外部ID」→「クロステナントアクセス設定」→「組織の追加」で相手テナントを選択し、「アウトバウンドアクセス」タブを開きます。「アクセスを許可」が選択され、対象ユーザーが「すべてのユーザー」または必要なグループに設定されているか確認します。
2. 自テナントのインバウンド設定を確認する: 同じ画面の「インバウンドアクセス」タブで、相手テナントからのアクセスが許可されているか確認します。自分自身が相手テナントのリソースにアクセスする場合、この設定は直接関係しませんが、相手が自テナントのリソースにアクセスする際の拒否原因になります。
3. 相手テナントの設定を依頼して確認する: 相手テナントの管理者に、自テナントに対するインバウンド設定とアウトバウンド設定を確認してもらいます。特に、自テナントが「組織の追加」に登録されているか、インバウンドが「アクセスを許可」になっているかを重点的にチェックします。また、相手テナントの信頼設定でMFAやデバイス条件が有効になっていないかも確認します。
4. 拒否ログを調査する: Entra IDの「サインインログ」で拒否されたログを検索します。「状態」が「失敗」のものを探し、「条件付きアクセス」や「クロステナントアクセス」に関連するエラーを確認します。拒否コードやメッセージから原因を特定できます。
5. 設定のスクリーンショットを共有する: 自テナントと相手テナントで設定の整合性を確認するために、互いの設定画面のスクリーンショットをメールやチャットで共有します。特に、「アクセスの割り当て」と「信頼設定」の部分を見比べます。

これらの手順で設定の不一致が見つからない場合、条件付きアクセスポリシーや他の認証ポリシーが影響している可能性があります。

管理者に伝えるべき情報と確認依頼のポイント

拒否問題が自テナント側だけで解決できない場合、相手テナントの管理者に協力を依頼する必要があります。以下の情報を整理して伝えることで、スムーズな原因特定が可能です。

• 拒否が発生する正確な操作: いつ、どのユーザーが、どのアプリケーションにアクセスしようとして拒否されたのかを具体的に伝えます。
• 自テナントの現在の設定内容: 自テナントのクロステナントアクセス設定(相手テナントのID、インバウンド/アウトバウンドの状態、スコープ、信頼設定)をテキストやスクリーンショットで共有します。
• 拒否ログのエラーコード: サインインログから取得したエラーコード(例: AADSTS50107)やエラーメッセージを伝えます。これにより、相手管理者が自テナント側のログと突き合わせやすくなります。
• 確認してほしい設定のリスト: 相手テナントで「組織の追加」に自テナントが登録されているか、インバウンドが許可になっているか、信頼設定で何かブロック条件が有効でないか、などを具体的に依頼します。

また、相手テナントの管理者が設定を変更する場合は、事前にキャプチャを取ってもらうと後戻りが容易です。

よくある質問

Q1: 両テナントで設定は完了しているはずなのに、なぜ拒否されるのですか?

設定が完了していても、条件付きアクセスポリシーやIDプロバイダーの設定が競合している可能性があります。また、設定の反映に最大30分かかる場合があるため、変更直後は一時的に拒否されることもあります。しばらく待ってから再試行してください。それでも改善しない場合は、サインインログで具体的なエラーを確認しましょう。

Q2: 自テナントのインバウンド設定は関係ありますか?

自テナントから相手テナントへのアクセス拒否の場合、自テナントのインバウンド設定は直接原因になりません。ただし、双方向の設定ミスで動作が不安定になることがあるため、一貫性を保つためにはインバウンドも正しく設定しておくことをおすすめします。

Q3: 拒否が特定のユーザーだけに発生します。どうすればよいですか?

ユーザーごとにスコープが異なる場合が考えられます。両テナントのアクセス設定で、該当ユーザーが許可対象のグループに含まれているか確認してください。また、条件付きアクセスポリシーがユーザー単位で適用されている可能性もあるため、管理者に問い合わせてください。

まとめ

クロステナントアクセス設定で相手先だけ拒否される問題は、双方向の設定不一致が主な原因です。自テナントのアウトバウンドだけでなく、相手テナントのインバウンド設定、さらに信頼設定や条件付きアクセスポリシーまで多角的に確認する必要があります。設定のバックアップを事前に取得し、相手テナント管理者と連携してスクリーンショットやログを共有することで、原因特定と解決がスムーズになります。もし設定に矛盾がなくても拒否される場合は、サインインログのエラーコードを手がかりに、さらに詳細な調査を行ってください。

👥

Teams/Outlookトラブル完全解決データベース サインイン、接続エラー、メール送受信の不具合など、特有のトラブル解決策を網羅。困った時の逆引きに活用してください。

🔐

会社アカウント・認証トラブル完全解決データベース 職場または学校アカウント、MFA、Authenticator、VPN、権限、会社ポリシーで止まる問題を横断的に確認できます。