Chrome で Azure ポータルにサインインすると、MFA は通るのに画面が再読み込みを繰り返して「Sign-in failed」になる――この症状は、拡張機能やプライバシー保護設定が認証の最終処理を妨げているケースが多いです。本記事では Norton AntiTrack が原因だった事例をベースに、最短で直す手順と切り分けのポイントをまとめます。
起きている症状を整理する（MFA 成功後にサインイン失敗）
今回の相談内容は、次のような流れでした。
- Chrome から Azure ポータル（
https://portal.azure.com）にアクセス - ユーザー名・パスワード入力 → 多要素認証（MFA）を実施
- MFA は正常に承認される
- その直後、画面が数回リロードされたあとに 「Sign-in failed」 と表示され、ポータルに入れない
ここで重要なのは、「MFA は成功しているのに、最終的なサインインが完了しない」 という点です。認証フローの途中までは通っているため、パスワードや MFA そのものの設定不備よりも、ブラウザ側（Cookie・リダイレクト・拡張機能・セキュリティ製品）が原因になりやすいパターンです。
| 観点 | よくある状況 | この時点で疑うべきこと |
|---|---|---|
| ブラウザ差 | Edge だと入れる／Chrome だけ失敗 | Chrome の拡張機能、Cookie 設定、プロファイル固有のデータ |
| プロファイル差 | 同じ Chrome でも特定プロファイルのみ失敗 | そのプロファイルにだけ入っている拡張機能、設定、ポリシー |
| 再読み込み | リロードを繰り返した末に失敗 | リダイレクトやトークン受け渡しがブロックされている可能性 |
| MFA 成功 | 承認アプリ・SMS などは成功扱い | 認証後のセッション確立（Cookie/Storage）が阻害されている可能性 |
原因：Norton AntiTrack がサインイン処理をブロックしていた
結論から言うと、問題が起きていた Chrome のプロファイルにだけ Norton AntiTrack 拡張機能が追加されており、トラッキング防止（追跡対策）機能が Azure ポータルのサインイン処理 を妨げていました。
このタイプの拡張機能は「広告やトラッカーを防ぐ」ことが目的ですが、現代のクラウドサービスのサインインは、複数ドメイン間のリダイレクトや Cookie／ストレージを使って“正当なログイン状態”を確立します。そこで、追跡対策が強く働くと、ログインに必要な通信まで“追跡っぽい動き”として止めてしまう ことがあります。
なぜ「MFA は成功するのに、最後で失敗する」のか
Azure ポータルのサインインは、ざっくり言うと次のような段階を踏みます。
| 段階 | ブラウザ内部で起きていること（イメージ） | ブロックされると起こりやすい症状 |
|---|---|---|
| 認証開始 | サインインページへ遷移し、必要なスクリプトや認証用 Cookie を準備 | サインイン画面が崩れる／入力後に戻される |
| MFA 実施 | 別画面・別要素で追加認証（承認アプリなど） | MFA 画面が表示されない／承認できない |
| トークン受け渡し | リダイレクトでトークンを受け取り、セッションを確立 | リロードループ／Sign-in failed |
| ポータル表示 | ポータル UI を読み込み、Graph/API などへアクセス開始 | 画面が真っ白／一部のブレードだけ開けない |
今回のケースは、MFA 自体は完了しているため「MFA の段階」は通過しています。しかし、その後の トークン受け渡し〜セッション確立 のどこかで通信・Cookie・ストレージがブロックされ、結果として Azure ポータル側はログイン状態を確定できず、エラーに落ちます。
ポイント：「MFA が成功した」という事実は、“本人確認ができた”ことを示しますが、“ブラウザがログイン状態を保持できた”ことまでは保証しません。拡張機能が Cookie や追跡関連の処理を止めると、本人確認ができてもポータルに入れないことがあります。
解決策：Norton AntiTrack に Azure ポータルを許可（ホワイトリスト）する
対処はシンプルで、Norton AntiTrack 側で Azure ポータル関連のサイトを「許可」 します。AntiTrack の画面では環境によって表記が異なり、次のような名前になっていることがあります。
- 許可サイト／許可済みサイト
- ホワイトリスト
- 保護しないサイト
- 除外（例外）
手順（まずは最短で直す）
- Chrome 右上の拡張機能アイコンから Norton AntiTrack を開く
- 設定（Settings）やサイト管理の画面を開く
- Azure ポータルを許可サイトに追加する（例：
https://portal.azure.com） - Azure ポータルのタブを 再読み込み（または一度タブを閉じて開き直す）
- もう一度サインインし、MFA まで実施してポータルに入れるか確認
実際にこの手順で、Chrome でも Azure ポータルへのサインインが正常に完了することが確認されています。
許可リストに追加する URL の考え方（追加が必要な場合）
環境によっては、ポータル本体だけでなく、サインイン基盤（Microsoft のログインページ）側のドメインも許可すると安定します。まずは最小構成で https://portal.azure.com を追加し、改善しない場合に段階的に追加するのがおすすめです。
| 優先度 | 例 | 目的 |
|---|---|---|
| 高 | https://portal.azure.com | Azure ポータル本体 |
| 中 | https://login.microsoftonline.com | Microsoft のサインイン（Entra ID） |
| 中 | https://*.microsoftonline.com（許可できる場合） | サインイン関連で参照されることがある |
| 低（必要時） | https://*.msauth.net / https://*.msftauth.net など | 認証 UI やリソース参照（環境差あり） |
ただし、拡張機能によってはワイルドカード（*）が使えない場合があります。その場合は、まずはポータルとログインページの 2 つ（portal.azure.com と login.microsoftonline.com）を追加し、症状が続く場合に Norton 側のブロックログ（あれば）を見ながら追加するのが現実的です。
Norton のサポート記事で手順を確認する
質問者が共有している Norton のサポート記事「Unable to access a specific website when Norton AntiTrack extension is turned ON or enabled」では、拡張機能が原因で特定サイトにアクセスできない場合の対処（許可サイトへの登録など）が案内されています。画面構成はバージョンで変わることがあるため、記事タイトルで検索して最新の手順を確認すると迷いにくいです。
切り分け：拡張機能が原因かどうかを最短で見抜く方法
同じような「MFA 後に Sign-in failed」系のトラブルは、Norton AntiTrack 以外でも起こります。そこで、原因が“ブラウザ側”かどうかを短時間で判定するための切り分け手順を紹介します。
シークレットモードで試す（拡張機能が無効になることが多い）
シークレットモード（プライベートブラウズ）は、拡張機能が無効になったり、Cookie/キャッシュの影響を受けにくかったりします。
- シークレットでは成功 → 拡張機能、Cookie、プロファイル固有データが原因の可能性が高い
- シークレットでも失敗 → ネットワーク、アカウント側、端末側の要因も疑う
別ブラウザ（Edge / Firefox）で試す
Edge で成功するなら、Azure 側の障害やアカウント設定よりも、Chrome の設定・拡張機能が疑わしいです。逆に、Edge でも同様に失敗する場合は、拡張機能以外（ネットワーク制御、セキュリティ製品、条件付きアクセスなど）も視野に入れます。
拡張機能を一時停止して試す（原因特定が早い）
業務端末では拡張機能を多く入れていることがあります。最短で原因に当たるには、次の順番がおすすめです。
- 広告・トラッカー対策系（Norton AntiTrack、Ghostery、Privacy Badger など）
- 広告ブロック系（AdBlock、uBlock Origin など）
- スクリプト制御系（NoScript など）
- Cookie 制御・セッション管理系
- セキュリティ製品の Web 保護系アドオン
すべてを無効化するのが難しい場合は、まず “怪しいカテゴリ”をまとめてオフにして挙動を見て、当たりを付けてから 1 つずつ戻すと効率的です。
追加の改善策：Chrome 側の設定も確認しておく
Norton AntiTrack を許可しても改善しない場合や、そもそも拡張機能が入っていないのに似た症状が出る場合は、Chrome 側の設定・状態もチェックしてください。Azure ポータルは複数のドメイン間で認証状態を引き継ぐため、Cookie 周りの制限が強いと失敗しやすくなります。
サードパーティ Cookie のブロック設定
Chrome のプライバシー設定で「サードパーティ Cookie をブロック」が有効になっていると、環境によってはサインイン後の遷移が不安定になることがあります。全体を緩めるのが難しい場合は、例外（許可）として Microsoft 関連のドメインだけ許可する運用が現実的です。
- 例外に入れる候補：
portal.azure.com、login.microsoftonline.comなど - 会社のポリシーで固定されている場合：管理者に相談（ユーザー側で変更できないことがあります）
サイトデータ（Cookie / キャッシュ）のクリア
一度失敗状態になったプロファイルでは、古い Cookie や壊れたセッション情報が残って、許可設定後も挙動が安定しないことがあります。
- Chrome の設定から「プライバシーとセキュリティ」へ
- 「閲覧履歴データを削除」または「サイトの設定 → 保存されたデータ」へ
- portal.azure.com / microsoftonline.com などのサイトデータを削除
- ブラウザを再起動して再サインイン
全消しが不安な場合は、特定サイトのデータだけ削除から始めると影響を抑えられます。
Chrome プロファイルの分離（仕事用プロファイルを作る）
今回の事例のように「特定プロファイルだけ失敗」する場合、プロファイル分離が根本対策として効きます。
- 仕事用プロファイル：Azure/Microsoft 365 に必要な拡張だけ入れる（最小構成）
- 個人用プロファイル：プライバシー強化・広告ブロックなど自由に
拡張機能は便利ですが、認証まわりは非常に繊細です。業務のサインインが止まるリスクを下げる意味でも、用途別プロファイルはおすすめです。
原因が拡張機能以外だった場合に疑うポイント
切り分けの結果、拡張機能を止めても改善しない場合は、次の観点も確認してください。
| 疑うポイント | 典型的なサイン | 対処の方向性 |
|---|---|---|
| プロキシ／SSL インスペクション | 会社ネットワークだけ失敗、モバイル回線では成功 | ネットワーク管理者へ相談、例外設定の検討 |
| エンドポイント保護（Web 保護） | 拡張機能は無いがセキュリティ製品でブロックログが出る | 製品の Web フィルタ除外、信頼サイト登録 |
| 条件付きアクセス／サインイン制御 | 別端末でも同じユーザーだけ失敗 | 管理者に Entra ID のサインインログ確認を依頼 |
| 端末の日時ずれ | 他のサイトでも認証が不安定、証明書エラーが出る | 時刻同期、タイムゾーン確認 |
特に企業環境では、ブラウザ拡張以外に「ネットワーク側での URL フィルタ」「SSL 復号」「CASB」などが絡み、サインイン後のリダイレクトが壊れることがあります。拡張機能で改善しないときは、別ネットワーク（テザリング等）で試すと原因の方向性が絞れます。
同種のトラブルを起こしやすい拡張機能・設定の例
今回の原因は Norton AntiTrack でしたが、仕組みが近いものは同様の症状を起こし得ます。「犯人探し」をするときの参考として、カテゴリ別に代表例を挙げます。
| カテゴリ | 例 | 起こりやすい影響 |
|---|---|---|
| トラッキング防止 | Norton AntiTrack、Ghostery など | 認証後のリダイレクト、Cookie／ストレージが阻害 |
| 広告ブロック | AdBlock、uBlock Origin など | ログインページの一部スクリプトが止まり UI が崩れる |
| スクリプト制御 | NoScript など | 認証に必要な JavaScript が動かず遷移できない |
| Cookie 制御 | Cookie 自動削除、セッション隔離系 | MFA 後にセッションが消えてループする |
| セキュリティ拡張 | Web レピュテーション、フィッシング対策 | 正規サイトでも誤検知でブロックされることがある |
「セキュリティのために入れたものが業務を止める」のは本末転倒に感じますが、これはどちらが悪いというより “認証フローの複雑さ” と “防御の強さ” が衝突して起きる現象です。だからこそ、必要なサイトだけ例外登録して両立させるのが現実的です。
再発防止：Azure ポータルを安定して使うための運用Tips
- 仕事用プロファイルは最小構成にする（拡張機能は必要最低限）
- プライバシー系拡張は、「すべてブロック」より「重要サイトは許可」の方針にする
- 拡張機能を入れた／更新した直後に不具合が出たら、まず疑う
- 社内端末なら、拡張機能の追加・更新は計画的に（業務影響が出ないタイミングで）
- 同僚にも同じ症状が出た場合は、“共通の拡張機能”を洗い出すと早い
管理者・サポートへ相談するときに伝えると早い情報
ユーザー側で解決できない場合でも、次の情報が揃っていると管理者やサポートが原因に近づきやすくなります。
- 失敗した日時（可能なら分単位）
- 利用ブラウザとバージョン（Chrome のバージョン）
- 利用している拡張機能の一覧（特にプライバシー・広告ブロック系）
- 失敗するプロファイル名（仕事用／個人用など）
- エラー画面のスクリーンショット（URL が見える範囲）
- 別ブラウザ・シークレットで成功するかどうか
- 会社ネットワークとモバイル回線で結果が変わるか
管理者に依頼できる場合は、Microsoft Entra ID（旧 Azure AD）のサインインログで「成功（MFA 済み）」の後にどの段階で止まっているか確認できることがあります。ユーザー側ではポータルに入れず確認できないことも多いので、状況だけでも共有すると判断材料になります。
まとめ
Chrome で Azure ポータルにサインインする際、MFA は成功しているのに「Sign-in failed」になる場合、拡張機能（特にトラッキング防止系）がサインイン後のセッション確立を妨げていることがあります。今回の事例では Norton AntiTrack が原因で、Azure ポータルを許可サイトに登録することで解消しました。
同じ症状が出たら、まずはシークレットモード・別ブラウザで切り分け、拡張機能を疑うのが最短ルートです。セキュリティと利便性を両立させるためにも、必要なサイトは例外登録して、安定したサインイン環境を整えておきましょう。
コメント