【Teams】社内LANから社外回線に変えた後にゲスト参加が通らない時の条件付きアクセスと信頼済み場所の見直し

Teamsでゲストユーザー(外部の参加者)を会議に招待する際、社内LANに接続しているときは問題なく参加できていたのに、社外回線(自宅や出先のWi-Fi、テザリングなど)に切り替えたとたんに参加できなくなる現象が発生することがあります。このトラブルは多くの場合、Entra ID(旧Azure Active Directory)の条件付きアクセス(Conditional Access)ポリシーと、その中で設定される「信頼済み場所(Named Locations)」の構成が原因です。本記事では、この問題の根本原因を解説し、端末側・アカウント側・管理設定側の切り分け方、具体的な確認手順、管理者が取り得る対応策を順を追って説明します。

1. なぜ社外回線に変えるとゲスト参加がブロックされるのか

条件付きアクセスは、ユーザーがリソースにアクセスする際に、場所、デバイス、リスクなどを評価してアクセスを許可・ブロック・MFA要求などの制御を行います。多くの組織では、社内LANのIPレンジを「信頼済み場所」として登録し、その場所からのアクセスは許可またはMFAを免除するポリシーを設定しています。しかし、ゲストユーザーが社外回線から接続した場合、そのIPアドレスは信頼済み場所に該当しないため、ポリシーによってアクセスがブロックされることがあります。特に、「すべてのアクセスをブロックする」ポリシーや「信頼済み場所以外からのアクセスにはMFAを要求する」ポリシーがゲストユーザーにも適用されている場合、社外回線からのゲスト参加が通らなくなります。

条件付きアクセスの主要な構成要素

条件付きアクセスポリシーは、以下の要素で構成されます。

• アサイン(割り当て): ポリシーを適用するユーザー・グループ(例:すべてのユーザー、ゲストユーザーのみ)
• 条件: 場所、デバイスプラットフォーム、アプリケーション、リスクなど
• アクセス制御: 許可、ブロック、MFA要求など

ゲスト参加がブロックされるパターンとして多いのは、他のユーザー(ゲストを含む)に対して場所条件で「すべての場所」または「信頼済み場所ではない場所」を指定し、アクセス制御で「ブロック」を設定している場合です。この場合、社外からのゲストアクセスは一律にブロックされます。

2. まずはエラーメッセージとサインインログを確認する

トラブルシューティングの第一歩は、ブロックされたときに表示されるエラーメッセージを確認することです。ブラウザからTeams会議に参加しようとした場合、「アクセスが拒否されました」や「お使いのアカウントからのアクセスは許可されていません」といったメッセージが表示されることがあります。また、Teamsアプリの場合もエラーコードが表示されることがあります。

管理者はEntra IDのサインインログを確認して、ブロックされたサインインの詳細を調査します。以下の手順で確認できます。

1. Azure Portal(https://portal.azure.com)にサインインします。
2. 「Entra ID」→「ユーザー」→「サインイン ログ」を開きます。
3. 日時範囲やユーザー名でフィルターをかけ、該当するゲストユーザーのサインインを探します。
4. 該当する行をクリックし、詳細情報を確認します。「条件付きアクセス」タブを開くと、適用されたポリシーとその結果が表示されます。
5. 「Location」列に表示されるIPアドレスと国/地域が、社外回線のものかどうかを確認します。

もし「条件付きアクセス」タブで「失敗」ステータスが表示され、ポリシー名が示されていれば、そのポリシーが原因である特定できます。

3. 信頼済み場所(Named Locations)の設定を見直す

条件付きアクセスで使用される場所条件は、Entra IDの「Named Locations」で定義されます。通常、社内LANのグローバルIPレンジやVPNの出口IPが登録されています。ゲスト参加が社外回線からブロックされる場合、多くのケースでこのNamed Locationsに社外のIPレンジが含まれていないことが原因です。

ただし、Named Locationsに社外のIPレンジを追加することは、セキュリティ上のリスクを伴います。代わりに、ゲストユーザー専用のポリシーを作成して、場所条件を緩和する方法が推奨されます。

Named Locationsの確認手順(管理者向け)

1. Azure Portalで「Entra ID」→「セキュリティ」→「Conditional Access」→「Named Locations」を開きます。
2. 現在登録されているIPレンジを確認します。多くの場合、会社の固定IP範囲が登録されています。
3. ゲスト参加時のIPアドレスがこの範囲に含まれているかどうかを確認するには、ゲストユーザーに現在のIPアドレスを確認してもらうか、サインインログのIPを確認します。
4. 必要に応じて、ゲストアクセスを許可するためのIPレンジ(例:特定のゲスト用VPNのIP)を追加することも検討しますが、社外の広いレンジは追加しないでください。

4. 条件付きアクセスポリシーの確認と修正

ゲスト参加がブロックされる場合、原因となっているポリシーを特定し、そのポリシーのアサインや条件を確認します。特に以下の点に注意してください。

• ポリシーの対象ユーザー: 「すべてのユーザー」または「ゲストまたは外部ユーザー」が含まれているか。
• 条件の場所: 「信頼済み場所ではない場所」が指定されている場合、社外からの全アクセスがブロックされます。
• アクセス制御: 「ブロック」が選択されている場合、場所条件が一致するとブロックされます。

修正方法として、以下のような対応が考えられます。

シナリオ別の対応例(管理者向け)

シナリオ	現在のポリシー設定	推奨対応
ゲストも内部ユーザーと同様に扱いたい	「すべてのユーザー」対象、場所条件「信頼済み場所ではない場所」でブロック	ゲストユーザーをポリシーから除外するか、ゲストユーザー専用のポリシーを別途作成して場所条件を緩和する
ゲストはMFAを求めたいがブロックはしたくない	「ゲストまたは外部ユーザー」対象、場所条件「すべての場所」でMFA要求	MFAが設定されていればそのまま。MFAが不要な場合はポリシーを無効化する
ゲスト参加を社外から完全に許可したい	該当のポリシーでゲストユーザーが対象になっている	ゲストユーザーをポリシーの対象から削除する(注意:セキュリティリスクを評価すること)

5. ゲストアクセスのポリシーと外部ユーザー設定の関係

条件付きアクセスポリシーだけでなく、Teams管理センターの外部アクセス設定やクロス組織アクセスも影響します。例えば、外部ユーザーとのチャットや会議を許可する設定が無効になっている場合、条件付きアクセス以前に参加自体ができません。また、ゲストアカウントの有効期限や招待の有効期限が切れている場合もブロックされます。

ただし、本記事のテーマである「社内LANから社外回線に変わった後に発生するブロック」は、多くの場合条件付きアクセスの場所条件が原因です。そのため、Teams管理センターの設定は関係ないことがほとんどです。

6. 失敗パターンと対処例

実際に遭遇しやすい失敗パターンをいくつか挙げ、その対処方法を説明します。

失敗パターン①:信頼済み場所に間違ったIPレンジを登録している

Named Locationsに誤って社外の広いIPレンジを登録してしまい、その場所が信頼済みになった結果、本来ブロックすべきアクセスが許可されてしまうケースや、逆に社内IPを登録し忘れてブロックされるケースです。必ず自社のグローバルIPレンジを正確に把握して登録してください。

失敗パターン②:ポリシーの優先順位を考慮していない

複数の条件付きアクセスポリシーが存在する場合、最も制限の厳しいポリシーが適用されます。ゲストユーザーに対して「ブロック」ポリシーと「許可」ポリシーが両方ある場合、ブロックが優先されるため、許可ポリシーが無効になることがあります。必ずポリシーの一覧を確認し、競合を解決してください。

失敗パターン③:ゲストユーザーのMFA登録が完了していない

条件付きアクセスでMFAが要求されているにもかかわらず、ゲストユーザーがMFAを登録していない場合、サインインがブロックされます。この場合、サインインログに「MFAはユーザーに登録されていません」という詳細が表示されます。ゲストユーザーにMFA登録を促す必要があります。

7. よくある質問

Q1: ゲスト参加がブロックされたとき、最初に確認すべきことは何ですか?
A: エラーメッセージと、管理者にサインインログを確認してもらうことです。エラーメッセージに「条件付きアクセス」と表示されていれば、ポリシーが原因です。

Q2: 社外からでもゲスト参加できるようにするには、Named Locationsに自宅のIPを追加すればよいですか?
A: いいえ。動的IPの自宅環境は頻繁に変わるため、Named Locationsに追加するのは非現実的です。代わりに、ゲストユーザー専用の条件付きアクセスポリシーを作成して場所条件を無効にするか、MFA要求のみにすることを検討してください。

Q3: ゲストユーザーにVPN接続を強制することはできますか?
A: 可能です。組織がVPNを提供している場合、ゲストユーザーにVPN経由での参加を依頼することで、社内IPとして認識させることができます。ただし、ゲストユーザー用のVPNアクセス権が必要です。

Q4: 条件付きアクセスポリシーを変更する前に、影響を確認する方法はありますか?
A: Azure Portalの条件付きアクセスで「What If」ツールを使用できます。ゲストユーザーのアカウントとアクセス先のアプリ(Teams)を指定して、どのポリシーが適用されるかをシミュレーションできます。

まとめ

社内LANから社外回線に変えた後にTeamsのゲスト参加が通らなくなる原因の多くは、Entra IDの条件付きアクセスポリシーと信頼済み場所の設定にあります。まずはサインインログでブロックの原因を特定し、対象のポリシーを確認してください。管理者は、ゲストユーザー専用のポリシーを作成するか、既存ポリシーからゲストユーザーを除外することで対応できます。ただし、セキュリティを低下させないよう、MFAの要求やデバイスコンプライアンスの確認など、代替の制御を併用することを推奨します。本記事の手順を参考に、適切な設定見直しを行ってください。

👥

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

🔐

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