大企業のAIセキュリティを支える基盤技術 - 今こそ理解するActive Directory 第5回 ブラウザ設定と認証

こんにちは！ 第4回では、プロキシの認証とアクセス制御を整理しました。今回は、ブラウザー側で何を確認し、どう設定を配るかを見ていきます。

同じページでも、ブラウザーや接続方法によって認証画面が出ることがあります。ここで許可先や認証方式を広げる前に、誰が認証を求めているのかを確かめます。

主にWindows上の管理対象Chrome・Edge・Firefoxと、明示的なフォワードプロキシを扱います。漫画は理解のための架空の会話です。設定例は説明用で、実環境へのポリシー配布や認証試験を実施した記録ではありません。

連載の構成

• 第1章：基本概念の理解 - Active DirectoryとKerberos/NTLM認証の基礎
• 第2章：ドメイン環境の構築 - 検証環境の構築手順
• 第3章：クライアントとサーバーのドメイン参加 - ドメイン参加の詳細手順
• 第4章：プロキシサーバーと統合Windows認証
• 【★今回です★】第5章：ブラウザ設定と認証 - 各ブラウザでの設定方法
• 第6章：トラブルシューティング - よくある問題と解決方法
• 第7章：セキュリティとベストプラクティス - 本番環境での考慮事項
• 第8章：実践的な構成例 - AIセキュリティツールとの統合事例

5.1 統合認証が動く条件を分ける

5.1.1 サイトの認証とプロキシの認証を分ける

「パスワードを聞かれた」だけでは、変更すべき設定は決まりません。 Webサイトが本人確認を求めた場合と、途中のプロキシが求めた場合では、調べる相手が違います。

NegotiateやNTLMでは交換が複数回に分かれます。途中に407があるだけで失敗とは限りません。認証が進まず同じ要求が続くのか、最終的に拒否されるのかを区別します。

Windowsのゾーン設定も、自動認証の許可判断に関係します。ChromeはWindows上で認証サーバーの許可リストが未設定の場合、Windowsのゾーンによる資格情報利用の判断を参照します。「ゾーン設定はEdgeだけのもの」と考えると、原因を取り違えます。

ゾーンへの登録と、ADへのドメイン参加、Kerberosのチケット取得は別の条件です。サイトを信頼済みに移せば、名前や鍵の不一致まで直るわけではありません。まず実際のプロキシ経路と認証相手を記録し、その後で許可範囲を確認してください。

5.1.2 URLの接続名をDNS・SPNとそろえる

同じサーバーへ届いても、同じ認証条件になるとは限りません。 短い名前、FQDN、別名、IPアドレスでは、名前解決や認証対象の名前が変わります。

認証対象は、誰が認証を求めたかによって変わります。Webサイトの401ならサイト側の接続名とSPN、明示的なフォワードプロキシの407ならプロキシの接続名とSPNを確認します。閲覧先URLとプロキシの名前を混同しないでください。

KerberosのHTTPサービスでは、SPNの名前が重要です。CNAMEの扱いは DisableAuthNegotiateCnameLookup、ポートの付加は EnableAuthNegotiatePort などのポリシーにも左右されます。解決先IPだけで判断せず、実際に生成されるSPNと登録先を確認します。

WindowsにはIPをSPNに使う例外設定もあります。ただしMicrosoftは、DNS名へ変更できない場合の選択肢として説明しています。ここでは例外を広げず、管理者が定めたDNS名を使う構成を基本とします。

URL中に「intranet」という文字が含まれるだけでは、信頼先の証明になりません。許可リストには管理対象の名前を指定し、意図しない外部名まで含むワイルドカードを避けます。

5.1.3 ブラウザーごとの設定と委任を区別する

認証サーバーの許可と、利用者の資格情報の委任は別です。 通常のサインインを直すために、委任の許可先を一律に追加しません。

ChromeとEdgeの仕様では、プロキシからの要求と、許可されたWebサーバーからの要求を区別しています。AuthServerAllowlist にプロキシ名を足すことだけを万能の修正にしません。実際の経路、提示方式、利用可能な資格情報も確認します。

次はFirefoxのサイト認証用 policies.json の最小例です。説明用の名前を使っています。HTTPSの指定先とその配下のホストが対象になるため、サブドメインまで含めた管理範囲を確認してください。プロキシの設定例ではありません。

{
  "policies": {
    "Authentication": {
      "SPNEGO": [
        "https://intranet.ad.example.com"
      ]
    }
  }
}

委任が不要な例なので Delegated は追加していません。プロキシには AllowProxies が別に作用します。通常のHTTP認証を、SAMLやOpenID ConnectのWebサインイン、IEモードの互換設定とも混同しないでください。

5.2 管理対象ブラウザーへ安全に配る

5.2.1 Chromeは初期状態で一律に無効ではない

「Chromeは統合Windows認証が初期状態で無効」という説明は正確ではありません。 未設定時の動作、OS、接続相手、通常・シークレットなどの利用モードを分けて確認します。

現行のChrome用管理テンプレートでは、認証サーバーの許可リストが未設定ならイントラネットかどうかを判断すると説明されています。Windows上のNegotiateはSSPIを利用します。ChromeをWindowsの認証機能から切り離されたブラウザーとして説明するのも適切ではありません。

一方、Chrome 81以降のシークレット・ゲストでは、既定の資格情報による認証は初期状態で許可されません。AmbientAuthenticationInPrivateModesEnabled がその動作を制御します。通常ウィンドウとの違いを調べるためだけに、私用モードの制限を一律に解除する必要はありません。

1. 1同じ端末・ユーザー・URL・プロキシ経路で比較する。
2. 2ブラウザーとOSの版、通常か私用モードかをそろえる。
3. 3管理ポリシーの値、適用元、エラーを確認する。
4. 4必要なチケット、サービス名、提示された認証方式を確認する。
5. 5差が説明できた後、必要な設定だけを試験対象へ適用する。

Firefoxについても「全環境で初期状態では使えない」とはまとめません。サイトの許可先、プロキシ用の設定、私用モードとOSの認証機能を確認します。ブラウザー名だけから架空の内部実装を推測するより、同じ条件での比較が役立ちます。

5.2.2 GPOの作成からブラウザーの適用確認まで

GPOを作ることと、利用者のブラウザーに設定が届くことは別です。 最初は少数の検証用端末・ユーザーに絞り、戻せる形で配布します。

1. 1公式のChrome・Edge・Firefox用管理テンプレートを取得し、利用版に合うことを確認する。
2. 2ドメイン管理では既存のCentral Storeを確認する。ADMXと対応する言語のADMLを版管理し、共有テンプレートを無計画に上書きしない。
3. 3対象OU、ユーザー設定かコンピューター設定か、GPOリンクとフィルターを決める。
4. 4認証を許可する必要な名前を設定する。委任は必要性と対象が確認できた場合だけ別に扱う。
5. 5クライアントで適用結果を読み、必要なブラウザー再起動の後に動作を確認する。

Central StoreはSYSVOL配下の共有テンプレートです。管理端末のローカル PolicyDefinitions だけを書き換えても、Central Storeを使う編集画面へ反映されるとは限りません。ADMXを置いただけでは端末の設定も変わりません。

以下は検証用Windows端末での例です。gpupdate /force は全ポリシーを再適用するため、他の設定への影響も踏まえて実施します。報告書名は保存先に応じて変更してください。

gpupdate /force
gpresult /h ad-browser-policy-report.html

gpresult はGPOの適用結果を調べるものです。ブラウザー側では chrome://policy、edge://policy、Firefoxの about:policies を開き、値とエラーを確認します。Chromeでは適用元も見て、GPOとクラウド管理のどちらが効いているかを判断します。

ポリシーの再読込だけでは足りず、再起動を必要とする項目もあります。少なくともEdgeの認証許可リストと委任許可リストは再起動が必要です。成功したページだけでなく、許可外の相手や未認証のアクセスが期待どおり拒否されるかも確かめます。

5.2.3 パスワード保存と認証キャッシュを分ける

プロキシのキャッシュを短くしても、ブラウザーに保存されたパスワードは消えません。 何を、どこが、どの期間保持しているのかを分ける必要があります。

Edgeの PasswordManagerEnabled を無効にしても、保存済みのパスワードは利用できる仕様です。新規保存の禁止だけで「残っている資格情報も消えた」と報告しないでください。HTTP認証ダイアログの見た目や保存機能も、ブラウザーと版によって確認します。

共有端末ではOSのサインアウト・サインイン、ブラウザープロセス、接続、保存状態を含めて、交代後の認証名を検証します。パスワードを保存させないために資格情報を全URLへ注入する独自拡張を作る、といった対策は本記事では勧めません。

Basicを採用する場合は、宛先サイトだけでなくクライアントからプロキシまでの経路を保護する必要があります。宛先のHTTPSを判定するACLだけでは、プロキシへの資格情報の送信が暗号化される保証になりません。

5.2.4 例外を整理して段階的に展開する

社内・VPN・私物端末という区分だけで、使える認証方式は決まりません。 経路がつながっても、チケットや名前、クライアントの対応が不足していれば認証は成立しません。

VPNや非ドメイン参加を理由に、無条件でBasicへ切り替える構成にはしません。例外が必要なら、対象者、端末、保護する通信区間、利用期限、取り消し方を決め、対応するクライアントとプロキシで試します。

利用者には、使うブラウザー、正式な接続先、不審な認証要求の報告先を案内します。診断ログにはURL、アカウント名、トークンなどが含まれ得るため、共有前に機密情報を除去します。

パスワードレス方式や別のSSO基盤を検討する場合も、Webログインの機能がそのままプロキシの407認証を置き換えるわけではありません。製品側の対応と認証経路を別に設計します。第6回では、この条件をそろえても失敗する場合の切り分けを扱います。