【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 経由で公開する際は、ぜひ「専用バックエンド接続」の設定を確認してみてください！