ロードバランサー + SSL環境で、IISの統合Windows認証を成功させる構成

統合Windows認証について

統合Windows認証（Integrated Windows Authentication）は、 IISとユーザーが同じActive Directoryドメインに所属している場合に、自動的にユーザの認証情報をIISに提供する仕組みです。 ASP.NET のC#でサイトを作成すると、ユーザ認証済み判定、及び認証済みユーザの情報が取得できます。

これにより、ユーザーは追加のログイン操作をせずに、IISがホストする（または連携する）ウェブアプリケーションにアクセスでき、他のアプリケーションサーバとSSO連携が実現できます。

ところが、Webサーバー（IIS）をロードバランサー配下に置き、さらに通信をSSL/TLSで暗号化した環境では、このWindows認証が正しく動作しないケースがあります。なぜでしょうか？

Windows 認証に成功するとシームレスに認証サイトへアクセスする仕組みを利用できるが、失敗するとサインインダイヤルが表示される。また正しく認証しない場合は、HTTP Error 401.1 – Unauthorized となる。

ポイントは Windows認証の仕組み と ロードバランサーの動作 にあります。

NTLMは各クライアントとサーバー間で単一のTCP接続上でチャレンジ／レスポンスを行う認証方式です。一方、Kerberosの場合も、クライアントはサービス識別子 (SPN) に基づきチケットを取得し、IISに送信します。これらの認証情報はHTTPヘッダー（Authorization: Negotiate ... 等）に乗せられてやり取りされます。しかし、レイヤ7のロードバランサーはクライアントからのHTTPS接続を自装置で終端して内容を解析し、新たなリクエストとしてバックエンドのIISに転送します。この過程でクライアントとIIS間のエンドツーエンドのTLSセッションが切断され、さらに NTLMのような接続維持型の認証情報が引き継がれない ため、認証処理が失敗してしまうのです​。

以上の背景を踏まえ、本記事では 「ロードバランサー + SSL環境で、IISの統合Windows認証を成功させる構成」 を検討します。典型的な構成パターンを３つ挙げ、それぞれについて Windows認証の対応可否、その技術的理由、さらに構成上のメリット・デメリットを解説します。

各構成案の技術的検証

①：L7ロードバランサーSSL終端+IIS(80 or 443)へ転送

クライアント ──HTTPS──▶ L7ロードバランサー(SSL終端) ──HTTP(S)──▶ IIS(80 or 443)

対応可否

Windows認証はこの構成では対応不可です。

理由

クライアントとIISの間のTLSセッションがロードバランサー上で一度終了してしまうため、エンドツーエンドの認証情報引継ぎができないからです。L7ロードバランサーは受け取ったHTTPSを復号し、自身がクライアントの代わりにIISへアクセスします。このとき本来クライアントからIISに送られるはずの Authorization: Negotiate ヘッダー（KerberosチケットやNTLMトークンを含む認証ヘッダー）が正しくIISまで届かなくなります。特にNTLMでは、初回の要求に対しIISが送る認証チャレンジ応答 (WWW-Authenticate) を踏まえてクライアントが再要求を送りますが、LB経由では同一TCPセッションが維持されないためにNTLMハンドシェイクが成立しません。

実際、AWS環境でもApplication Load Balancer (ALB) やHTTPリスナーではWindows認証が動作せず、Network Load Balancer (NLB) などTCPレベルのLBが必要になるとされています​[参考]。またAzure Application Gateway v2でも統合認証を含むHTTPヘッダーをバックエンドに透過させることはサポートされていません[参考]。

このように各クラウドベンダーのマネージドLBで公式に非サポートとなっている点からも、L7レベルでWindows認証を維持することの困難さがわかります。

②：L4ロードバランサー（TLSパススルー）+IIS転送

クライアント ──HTTPS──▶ L4ロードバランサー(TLSパススルー) ──HTTPS──▶ IIS(443)

対応可否

この構成はWindows認証に対応可能です。

理由

L4ロードバランサー（OSIレイヤ4で動作するLB）はパケットをTCPレベルで中継するため、クライアント～IIS間のTLSセッションがエンドツーエンドで維持されます。ロードバランサーは暗号化を終端せず、TCPコネクション自体を各サーバーに振り分けるだけなので、NTLM認証が要求する「同一TCP接続上でのやりとり」も保たれます​。Kerberosについても、クライアントから見ればIIS（サービス）のFQDNに直接接続しているのと同じ状態を再現できるため、適切にSPN設定さえしておけばチケットベースの認証がそのまま通ります。AWS NLBやクラシックLBのTCPリスナーモード、Azureの内部ロードバランサー、F5のL4モードなどはこのカテゴリに属し(他に HAProxyのTCPモード、nginx streamなどが該当)、Windows統合認証を透過できます​。

メリット

TLSセッションがクライアントからサーバーまで途切れないため、Windows認証プロトコルが本来の動作を維持できます。NTLMの3ウェイハンドシェイクも単一接続内で完結し、Kerberosチケットもバックエンドサーバーが正しく受け取ります。加えて、LBはL4動作のためオーバーヘッドが小さく高いスループットを期待できます。

デメリット

パスベースやホスト名ベースの細かなルーティングができない点が、L4ロードバランサー構成における最大の課題です。たとえば、URLパス（例：/api、/chat）ごとに異なるバックエンドサーバーへ振り分けるといったことは、L7（HTTP）でしか実現できない機能であり、L4（TCP）では不可能です。

そのため、システム要件によっては複数のFQDNを用意し、用途ごとに異なる仮想サーバー(Webサーバ、Windows認証用サーバなど)をロードバランサー内に割り当てる必要があり、構成の難易度が高くなるデメリットがあります。

また、Windows認証で必要となる以下設定は全てロードバランサーのFQDNを設定する点も注意が必要です。

• Windows認証で必要になる、インターネット オプション「セキュリティ」タブの「ローカル イントラネット」の「サイト」 設定
• Windows認証ページへFQDN(完全修飾ドメイン名)でアクセスする場合の SPN 登録
• IIS サイトバインド設定とSSL証明書（ロードバランサー自体に証明書設置は不要）

※ ロードバランサーのFQDN が lb.example.com の場合、Kerberosが成功するまでのフロー

[Client]
  | 1. DNS解決: lb.example.com → LB
  |
  | 2. Kerberos: SPN = HTTP/lb.example.com
  |             → ドメインコントローラーにTGSを要求
  |
  | 3. TLSハンドシェイク: SNI = lb.example.com
  |             → IISで一致する証明書必要
  |
  | 4. リクエスト送信: Hostヘッダ = lb.example.com
[IIS]
  → SPN受け入れOK、証明書OK、認証成功

③：L7ロードバランサーSSL終端+IISへリダイレクト構成

クライアント ──HTTPS──▶ L7ロードバランサー（SSL終端）
　　　LB ──HTTP 302 (リダイレクト応答)→ クライアント
　　　　　クライアント ──HTTPS──▶ IIS（443へ直接アクセス）

対応可否

この構成はWindows認証に対応可能です。

理由

アイデアとしては「ロードバランサーでは実際の通信を中継せず、一度リダイレクト（HTTP 302応答）でクライアントをバックエンドのIIS直通に誘導する」方法です。初回、ユーザーはLBのURLにアクセスしますが、L7ロードバランサーはそこでSSLを終端しつつ内容を解析し、適切なIISのアドレス（例：各IISが持つ個別のホスト名やIPアドレス）にHTTPSで接続するようLocationヘッダー付きの302応答を返します。クライアントブラウザはこのリダイレクトを受け取り、自動的に指定されたIISに対して直接HTTPSで再リクエストを送信します。

結果、2回目の要求ではクライアントとIISが直接TLSでつながるため、Kerberos/NTLMの認証情報もそのままエンドツーエンドでやり取りされます。ロードバランサーは認証処理の間は介在しないため、構成案①のような認証ヘッダー消失問題を回避できます。

メリット

TLSがクライアントからIISまで直結するため、Windows認証が簡単に成功できる点が大きな利点です。
IIS単体で認証が成功していれば、その構成をそのまま活かせるため、ロードバランサーを中継したとしても難易度が上がる事はありません。

また、リダイレクトを活用することでロードバランサー側である程度柔軟なルーティング制御が可能です。例えば、最初のアクセスURLパスやホスト名に応じて異なるバックエンドIISのURLへリダイレクトさせることで、パスベース振り分けに近いことも実現できます。LB配下に多数のサービスがある場合、ひとまず共通のエントリポイントとしてLBに集約し、そこから各サービスの実URLに誘導することで表面的には一つに見せる、といった構成も可能です。

デメリット

LBの背後にIISを配備できず、公開サーバとしてIIS用に別エンドポイント設計、及びLBとは異なる証明書の配置が必要になる点はデメリットです。

また、初回アクセス時にリダイレクトが発生する点もデメリットですが、実際にはHTTP 302応答を介した即時再接続が行われるだけであり、ユーザー体感的な影響はほぼ無視できるレベルです。

IISへリダイレクト後、Windows認証を経て弊社サービスへログインするまでの速度の参考は、こちらの動画を参照してください。

各構成の比較表

まとめ

Windows認証（NTLM/Kerberos）を正しく機能させるには、TLSセッションがクライアントからIISまで一貫して維持されることが絶対条件です。

案②のL4ロードバランサー構成は、TLSが中継されず、IISまでストレートに届くため認証が通ります。ただし、パスベースの細かなルーティングができず、ロードバランサー内に複数の仮想サーバーを構成する必要が出てくる点は構成難易度が高くなります。

一方、案③のリダイレクト構成は、初回だけL7ロードバランサーで処理し、その後はIISに直結する形を取るため、TLSと認証の観点では理想的な流れになります。特定のパスに対してIISのFQDNへリダイレクトすることで、L7でのルール制御とWindows認証の両立を図れます。LBの背後にないIISが 443ポートを ANYで許可する点はポリシー的に問題がないか確認が必要です。

逆に案①のように、L7ロードバランサーがTLS終端またはHTTP解釈を挟むような構成では、認証情報が断絶されるため、Windows認証は成立しません。

堅牢な認証システムを維持しつつ、負荷分散と暗号化通信を両立させる構成の検討に、本記事が助けになれば幸いです。