Microsoft 365を利用していると、自宅や外部ネットワークからは問題なくサインインできるのに、会社のネットワークに接続したときだけ「このネットワークからのアクセスは許可されていません」というエラーが表示されることがあります。多くの場合、この現象は条件付きアクセスで設定された場所ベース制御が原因です。場所ベース制御とは、アクセス元のIPアドレスや地理的な位置情報をもとに認証を許可または禁止するポリシーであり、社内ネットワークの設定ミスや端末の状態が原因で誤ってブロックされる場合があります。本記事では、場所ベース制御の仕組みを理解し、安全に原因を切り分ける手順を解説します。
【要点】この記事で確認すること
- 最初に見る場所: 管理者が設定した条件付きアクセスのポリシー一覧と、既知のネットワークのIP範囲設定。
- 切り分けの軸: 端末側のIPアドレスやネットワーク種別の確認、アカウントの条件付きアクセス評価ログの確認。
- 注意点: 会社PCではレジストリやネットワーク設定を管理者の指示なしに変更しないこと。ポリシー設定自体は管理者のみ操作可能。
ADVERTISEMENT
目次
社内ネットワークからの認証拒否が発生する原因の種類
社内ネットワークに接続しているにもかかわらず認証が拒否される場合、原因は主に以下の3つに分類できます。
| 原因カテゴリ | 具体例 |
|---|---|
| 場所ベース制御の設定ミス | 管理者が登録した社内IP範囲に実際の出口IPが含まれていない、またはポリシーで「すべての場所」をブロックしている。 |
| 端末のネットワーク状態の問題 | 社内Wi-Fiの代わりにモバイルネットワークを経由している、VPNが正しく接続されていない、プロキシ設定が誤っている。 |
| 端末の準拠状態の問題 | デバイスが条件付きアクセスの「準拠デバイス」要件を満たしていない、OSバージョンが古い、ウイルス対策ソフトが無効。 |
このうち、場所ベース制御が最も直接的に「ネットワーク単位」のブロックを引き起こします。特に社内ネットワークからのみ拒否されるという状況は、ポリシーが社外ネットワークからのアクセスを許可する設定になっていて、社内IP範囲が誤ってブロックリストに入っているケースが典型的です。
場所ベース制御とは何か:条件付きアクセスの仕組み
場所ベース制御は、Azure AD(Microsoft Entra ID)の条件付きアクセス機能の一部で、サインイン要求の元となるIPアドレスや国・地域に基づいてアクセスを制御します。管理者は「条件」として場所(既知のネットワークまたは信頼できるIP範囲)を指定し、その条件を満たす場合に「アクセスを許可する」「アクセスをブロックする」「多要素認証を要求する」などの制御を割り当てます。
場所の判定には以下の2つの情報が使われます。
- クライアントのパブリックIPアドレス: 社内ネットワークの出口ルーターのグローバルIP。会社が複数の拠点を持つ場合、各拠点のIP範囲を個別に登録する必要があります。
- 地理的な位置情報(オプション): IPアドレスから推定される国や地域。社外からのアクセスを制限する用途で使われます。
管理者は「場所」を「すべての場所」「信頼できる場所」「すべての信頼できる場所」「VPNネットワーク」のように分類できます。「既知のネットワーク」は、管理者が事前に登録したIP範囲を指します。社内ネットワークだけがブロックされる場合、この既知のネットワーク範囲に現状の出口IPが含まれていないか、ポリシーで「すべての場所」に対してブロック制御が適用されている可能性が高いです。
端末側で確認すべきポイント:IPアドレス・ネットワーク状態
まず、一般ユーザーでも可能な範囲で端末のネットワーク状態を確認します。以下の手順で自端末のパブリックIPを調べ、社内ネットワーク経由であることを確かめてください。
- ブラウザで「what is my ip」などの検索サイトにアクセスし、表示されるグローバルIPアドレスをメモします。
- 同じ端末で社内ネットワーク(有線LANまたは会社指定のWi-Fi)に接続していることを確認します。タスクバーのネットワークアイコンから接続先を確認してください。
- 可能であれば、別の端末(同僚のPCや個人スマートフォンのテザリング)でも同じ社内ネットワークからMicrosoft 365にサインインを試みます。他の端末でも同様に拒否される場合、ネットワーク単位の問題です。
- VPNを使用している場合、VPN切断後にもう一度試します。VPN経由だと異なるIPアドレスになるため、場所ベース制御に引っかかる可能性があります。
- 組織がプロキシを使用している場合、プロキシ設定が正しいか確認します(プロキシ自動構成スクリプトの有無など)。
端末側で確認したIPアドレスは、管理者に報告する際の重要な手がかりになります。
注意:端末の準拠状態も併せて確認
場所ベース制御以外にも、端末が条件付きアクセスの「準拠デバイス」要件を満たしていないためにブロックされることがあります。特に社内ネットワーク経由であっても、端末のOSバージョンが古い、ウイルス対策が無効、ディスク暗号化が未設定などの理由で準拠状態になっていない場合、認証が拒否されます。この場合、エラーメッセージに「このデバイスは組織のセキュリティポリシーに準拠していません」といった文言が含まれることが多いです。場所ベース制御によるブロックと端末準拠によるブロックは異なるため、エラーメッセージの詳細を確認してください。
管理者側で確認すべき設定:条件付きアクセスポリシーと既知のネットワーク
管理者はMicrosoft Entra管理センターで条件付きアクセスポリシーを確認します。以下の項目を重点的にチェックしてください。
- 場所の条件: 各ポリシーの「条件」→「場所」で、どの場所に対して制御が適用されているか。社内ネットワークのIP範囲が「含める」または「除外する」に正しく設定されているか。
- 既知のネットワークのIP範囲: 「条件付きアクセス」→「名前付きの場所」で登録されているIPアドレス範囲。社内ネットワークの出口IPが最新のものになっているか。
- ポリシーの割り当て: ポリシーが「すべてのクラウドアプリ」または特定のアプリに対して有効になっているか。対象外のアプリで問題が再現するかも確認してください。
- レポート専用モード: ポリシーが「レポート専用」で設定されている場合、実際にはブロックされずにログのみ残ります。ブロックが発生している場合は「オン」または「オフ」のポリシーが有効になっています。
特に、場所ベース制御で「すべての場所」をブロックに設定しているポリシーが、社内ネットワークのIPを除外リストに入れていないケースが典型的です。また、複数のポリシーが重複して適用される場合、優先順位(高い順から適用)も影響するため、ポリシーの一覧と各ポリシーの状態を確認します。
サインインログの活用
管理者はMicrosoft Entra管理センターの「サインインログ」で、失敗したサインイン要求の詳細を確認できます。該当ユーザーのサインインをフィルターし、「条件付きアクセス」タブでどのポリシーが適用されてブロックされたかが表示されます。「場所」の情報も含まれているため、実際に使用されたIPアドレスとポリシーの評価結果を突き合わせることで原因を特定できます。
切り分けの手順:問題が端末原因かポリシー原因か
以下の手順で段階的に原因を絞り込みます。
- 別端末で同じネットワークからテスト: 別のPCやスマートフォン(会社支給のデバイス)で社内ネットワークに接続し、同じMicrosoft 365アカウントでサインインを試みます。もし別端末でも拒否されるなら、端末固有の問題ではなくネットワークまたはポリシーの問題です。
- 同じ端末を社外ネットワークでテスト: モバイルデータ通信や自宅Wi-Fiなど、社内ネットワーク以外からサインインを試みます。社外では問題なくサインインできる場合、場所ベース制御が原因である可能性が高まります。
- 管理者がサインインログを確認: 社内ネットワークからの失敗レコードを抽出し、適用されたポリシー名とブロック理由を確認します。特に「場所の条件が満たされていない」という理由が表示されれば、場所ベース制御の設定ミスです。
- ポリシーの一時的な無効化テスト(管理者のみ): 問題のポリシーを「レポート専用」に切り替えるか、対象ユーザーから一時的に除外して動作を確認します。このテストは本番環境に影響を与えるため、慎重に行い、すぐに元に戻せるよう準備してください。
- 既知のネットワークのIP範囲の見直し: 社内ネットワークの出口IPが変更されていないか、または新しい拠点のIPが未登録でないか確認します。IT部門でIPアドレス管理台帳と照合します。
よくある失敗パターンと対処例
現場でよく遭遇する失敗パターンをいくつか紹介します。
失敗パターン1:VPN経由で社内ネットワークに接続しているのに、社内ネットワークとみなされない
VPN接続を使用している場合、クライアントのパブリックIPはVPNゲートウェイのIPになるため、社内ネットワークの出口IPとは異なります。管理者はVPN接続用のIP範囲を別途「既知のネットワーク」として登録するか、VPN接続時用の条件付きアクセスポリシーを作成する必要があります。ユーザー側では、VPN切断後に社内LAN直接接続で試すことで切り分けられます。
失敗パターン2:「すべての場所」をブロックするポリシーが意図せず有効になっている
管理者がテスト目的で「すべての場所」からのアクセスをブロックするポリシーを作成し、そのまま本番環境に適用してしまうケースです。この場合、社内ネットワークも含めてすべてのアクセスが拒否されるため、緊急対応が必要です。サインインログで「条件付きアクセスポリシーによりブロックされました」というエラーが多数発生していないか監視することが防止策です。
失敗パターン3:古いIP範囲が登録されたまま新しい出口IPが使われている
ISPの変更やネットワーク機器の更新で社内の出口IPが変わった場合、管理者側で「既知のネットワーク」のIP範囲を更新しないと、新しいIPが社外扱いになります。定期的なIPアドレスの棚卸しと条件付きアクセス設定のレビューが再発防止に有効です。
まとめ:管理者への報告ポイント
社内ネットワークからのみMicrosoft 365認証が拒否される場合、最初に疑うべきは場所ベース制御の設定ミスです。ユーザーは端末のIPアドレスとネットワーク種別を確認し、別端末でのテスト結果を添えて管理者に報告してください。管理者は条件付きアクセスポリシーとサインインログを確認し、既知のネットワークのIP範囲が最新かどうか、ポリシーの条件が正しいかを検証します。また、端末の準拠状態も同時に確認することで、原因の誤認を防げます。これらの手順を踏めば、問題解決までの時間を大幅に短縮できるでしょう。
超解決 リモートワーク研究班
Microsoft 365の導入・保守を専門とするエンジニアグループ。通信障害やサインイン不具合など、ビジネスインフラのトラブル対応に精通しています。
Office・仕事術の人気記事ランキング
- 【神技】保存せずに閉じたExcel・Wordファイルを復元する!消えたデータを復活させる4つの救出法
- 【Outlook】添付ファイルが「Winmail.dat」に化ける!受信側が困らない送信設定
- 【Excel】文字が入っているセルの「個数」を数える!COUNTA関数の簡単な使い方
- 【Word】差し込み印刷で数字の桁を整える!金額にカンマ(桁区切り)を入れる設定
- 【Teams】メッセージを「保存済み」にして後で読む!重要なチャットをブックマークして整理する技
- 【Outlook】予定表の「祝日」が表示されない!最新カレンダーの追加と二重表示の修正手順
- 【PDF】PDFに入力した文字の「フォント・サイズ・色」を変更するプロパティ設定
- 【Word】校閲機能の基本!赤字(変更履歴)とコメントで修正を見える化する
- 【Copilot】「サービスに接続できません」エラーの原因切り分けと対処法
- 【PDF】結合するPDFの「用紙サイズ」がバラバラな時、すべてを「A4サイズ」に強制リサイズしてから結合する
