VPN 変更後の Outlook サインイン：Entra が実際に見るもの

VPN を変更した後に Outlook が再びサインインを求めるようになりますが、メールボックスのパスワードは変わっていません。Microsoft Entra は、クラウド サービスが見るネットワーク アドレスを使って要求を評価し、VPN はアカウントに触れずにその観測を変えることができます。この要求はポリシーの結果であり、必ずしも資格情報の失敗ではありません。

関係するのは二つのセッションです。VPN セッションとメールボックスのトークンで、それぞれ別のシステムに対して認証します。

Entra がサインイン時に評価するもの

サインイン時に、Entra は構成された条件に照らして要求を評価します。ネットワーク上の場所、多要素の状態、デバイスの準拠、およびセッション制御です。ネットワーク条件はサービスが見るアドレスを使い、それはノート PC の状態ページのアドレスとは限りません。そのため、企業の範囲を信頼するポリシーは、トラフィックが別の場所から出るようになったクライアントを拒否することがあります。これは正しい評価であり、不具合ではありません。

結果をパスワードの問題として読む前に、ポリシーの判断として読んでください。

VPN セッションとメールボックスのトークンは別物

ゲートウェイが VPN の資格情報を受け入れることは、ネットワーク セッションが存在することだけを証明します。Exchange Online がメールボックスのアカウント、デバイス、現在のアクセス ポリシーを受け入れたかどうかは何も示しません。

新しいトークン要求が Conditional Access の要件に当たり、正当な追加の認証手順を生むことがあります。終わらない失敗の要求は別の結果です。どちらなのかを、どのパスワードもリセットする前に特定してください。

継続的アクセス評価は別の経路を加えます。リソースが期限切れでないトークンを拒否し、再評価を求めることがあります。だからといって、ネットワークの変更のたびにすべての Outlook クライアントがサインインを求めるわけではありません。

クラウドが実際に見るのはどのアドレスか

VPN が接続されているアイコンは、すべてのクラウド要求の公開元を証明しません。スプリット トンネル、IPv6 の経路、またはプロキシから出るトラフィックは、Exchange Online とは別のアドレスを Entra に見せることがあります。ブラウザーの確認はまったく別の経路をたどることもあります。

実際のサインインの観測を想定したネットワーク設計と比較し、展開が公開している場合はリソースが見るアドレスも含めてください。

転送の失敗とポリシーによる拒否を切り分けてください。ブロックされた認証エンドポイント、TLS の失敗、壊れたプロキシ経路はサインインの問題のように見えますが、Conditional Access の判断ではありません。この区別が、テナントの規則を変えるのか経路を直すのかを決めます。何かを編集する前に、その区別を保ってください。

一つの要求を一つのサインイン イベントに対応づける

試行は一回ずつ記録します。時刻とタイム ゾーン、Outlook のビルド、メールボックスのアカウント、VPN の状態、正確なエラーです。エラーがトラブルシューティングの詳細を表示する場合は、パスワードやトークンをコピーせずに相関 ID を保管してください。

権限のある管理者は、Entra のサインイン ログで一致するイベントを見つけ、クライアント、リソース、認証の詳細、ポリシーの結果を確認できます。

ポリシーを修正し、それから経路を試す

ログ エントリを注意深く読んでください。ブラウザーでのサインインに成功しても、それが追っている Outlook の要求とは限らず、表示者のタイム ゾーンが自分と異なることもあります。バックグラウンドのトークン活動も再構成に含めます。

ポリシーが要求を説明している場合は、承認された ID、デバイス、またはネットワーク構成をその所有者とともに修正します。プロバイダーの範囲全体を信頼したり、要求を黙らせるために MFA をオフにしたりすることは修理ではありません。

サインインの頻度も、誤ったパスワードなしに再認証を強制できます。修正後は、新しく承認されたメールボックスの同期または送信で経路を試してください。キャッシュされたメッセージを読んでも何も証明できません。Conditional Access のトラブルシューティング手順にログの相関が説明されています。