【Azure】Application Gateway 経由で Windows 認証（NTLM/Kerberos）が失敗する原因と「専用バックエンド接続」の役割
はじめに
Azure Application Gateway（AppGW）を構築・運用している際、バックエンドの Windows サーバー（IIS）に対して Web アクセスを行ったときに、以下のような現象に遭遇したことはないでしょうか？
- Windows 認証のダイアログ（ポップアップ）が何度も繰り返し表示される
- 正しいユーザー名とパスワードを入力しているのにログインできない
- サーバーに直接アクセスすると成功するのに、AppGW を経由した時だけ 401 エラーになる
この現象の背景には、IIS の Windows 認証（特に NTLM 認証）の仕組みと、AppGW による TCP 接続の再利用（コネクションプーリング）との相性問題があります。
今回は、このトラブルの原因と、解決策である 「専用バックエンド接続（Dedicated Backend Connection）」 の仕組みについて分かりやすく解説します。
1. Windows 認証（Negotiate / NTLM）の仕組み
IIS の Windows Authentication（Windows 認証）では、主に Kerberos または NTLM というプロトコルが使用されます。
IIS の標準的な設定は以下のようになっています。
Windows Authentication : Enabled
Providers:
- Negotiate
- NTLM
この設定（Negotiate）の場合、動作としては 「まず Kerberos での認証を試行し、失敗した場合は NTLM へフォールバックする」 という挙動をとります。
NTLM 認証の大きな特徴：認証状態が「TCP 接続」に紐づく
通常の Form 認証（ログイン画面から送信するタイプ）などは、HTTP リクエスト単位で認証トークンやセッション情報を持たせるため、HTTP リクエストがどの TCP 接続を通ろうが問題ありません。
しかし、NTLM 認証は以下のようなマルチステップ（Challenge-Response）のやり取りを行います。
[ Client ] [ IIS Server ]
│ │
├───────① Challenge 要求 (Type 1) ──────>│
│ │
│<──────② Challenge 応答 (Type 2) ──────┤
│ │
├───────③ Response 送信 (Type 3) ──────>│
│ │
│ 【 認証成功 】
│ IIS: "この TCP 接続は
│ UserA として承認"
NTLM の最大の特徴は、「認証成功のステート（状態）が、クライアント〜サーバー間の『特定の TCP 接続』に紐付けられる」 という点です。
つまり、IIS は「この TCP 接続から来るリクエストは UserA のものだ」と判断して処理を継続します。
2. なぜ AppGW を通すと認証が壊れるのか？
Application Gateway はパフォーマンス向上のため、「バックエンドサーバー（IIS）との TCP 接続を複数ユーザー間で使い回す（再利用する）」 という仕組みを持っています。
これが NTLM 認証と致命的にバッティングします。
発生する問題のシーケンス
【User A のアクセス】
User A ──> AppGW ──( Connection #1 )──> IIS ( User A として認証成功！ )
【User B のアクセス】
User B ──> AppGW ──( Connection #1 を使い回し )──> IIS
-
User A がアクセスし、AppGW と IIS 間の
Connection #1で NTLM 認証を完了（IIS はConnection #1 ＝ User Aと記憶）。 - その直後、User B がアクセスしてきた際、AppGW は効率化のために既存の
Connection #1を再利用して IIS にリクエストを送信。 - IIS からすると「User A として認証済みの接続から、別人のリクエストが来た（あるいは認証手順がスキップされた）」ように見え、不整合を起こして接続を拒否（401 Unauthorized）します。
結果として、ユーザーの画面には「認証ポップアップが繰り返し表示される」「ログインできない」という事象が発生します。
3. 解決策：「専用バックエンド接続 (Dedicated Backend Connection)」
この問題を解決するために用意されている機能が 「専用バックエンド接続（Dedicated Backend Connection）」 です。
これを有効化すると、AppGW はフロントエンドのクライアント（1 ユーザー）に対して、バックエンドへの 1 つの専用 TCP 接続を割り当てるようになります。
有効化後のイメージ
User A ──> AppGW ──( Connection A [専用] )──> IIS => Connection A ＝ User A
User B ──> AppGW ──( Connection B [専用] )──> IIS => Connection B ＝ User B
User C ──> AppGW ──( Connection C [専用] )──> IIS => Connection C ＝ User C
バックエンド接続の再利用が行われず、1 クライアント ＝ 1 バックエンド接続 が担保されるため、IIS 側でも NTLM の認証状態（TCP 紐付け）を正しく管理できるようになります。
4. 「Kerberos 認証を使っているから関係ない」は本当？
「うちは Kerberos を使っているはずだから大丈夫」と思っていても、トラブルになるケースが多発しています。
理由として、Kerberos 認証の前提条件である SPN（サービス主体名） の設定が不適切だと、Kerberos 認証が失敗し、裏で自動的に NTLM へフォールバックしてしまうからです。
よくある落とし穴
クライアントがアクセスする「AppGW の FQDN」と、バックエンド IIS サーバーのホスト名/ドメインアカウントに対する SPN 登録が一致していないと Kerberos 認証に失敗し、NTLM 認証へ落ちます。
そのため、Microsoft の公式ドキュメントでも、Windows 認証（NTLM / Negotiate）を利用する環境では「専用バックエンド接続」の検討・有効化が案内されています。
5. 導入時の注意点（スケールとリソース）
「専用バックエンド接続」は認証問題をクリアする強力な機能ですが、運用にあたっては以下の点に考慮が必要です。
-
TCP 接続数の増加
接続の再利用を行わないため、アクセスするクライアント数に比例してバックエンド（IIS）への TCP 接続数が増加します。 -
サーバーリソースの確認
IIS サーバー側の最大接続数（maxConnections）やエフェメラルポート枯渇、メモリ消費量に余裕があるか確認してください。 -
Keep-Alive タイムアウトの最適化
不要に長い Keep-Alive タイムアウトが設定されていると、接続が解放されずリソースを圧迫するため、クライアント・AppGW・IIS 間で適切なタイムアウト値を設計・設定することが重要です。
まとめ
- 原因: NTLM 認証は 「TCP 接続」に認証状態が紐づくのに対し、AppGW は TCP 接続を再利用するため、認証状態の不整合（401エラーやポップアップ連発）が発生する。
- 対策: AppGW で 「専用バックエンド接続（Dedicated Backend Connection）」 を有効化し、1 クライアント ＝ 1 バックエンド接続の環境を作る。
- 補足: Kerberos を利用している場合でも、SPN 設定不備等で NTLM にフォールバックすることがあるため注意が必要。
IIS ＋ Windows 認証の Web アプリケーションを Azure Application Gateway 経由で公開する際は、ぜひ「専用バックエンド接続」の設定を確認してみてください！