How to configure IIS Integrated Windows Authentication to succeed in a load balancer + SSL environment

About Integrated Windows Authentication

Integrated Windows Authentication is a mechanism that automatically provides user authentication information to IIS when IIS and the user belong to the same Active Directory domain. When you create a site with ASP.NET C#, you can determine whether a user has been authenticated and obtain information about authenticated users.

This allows users to access web applications hosted on (or integrated with) IIS without any additional login steps and enables SSO integration with other application servers.

However, in an environment where the web server (IIS) is under a load balancer and communication is encrypted with SSL/TLS, this Windows authentication may not work properly.Why is that?

If Windows authentication is successful, you can seamlessly access the authentication site, but if it fails, a sign-in dial will be displayed. Also, if authentication is not performed correctly, HTTP Error 401.1 – Unauthorized will be displayed.

The point is How Windows authentication works and Load balancer operation is located.

NTLM is a challenge/response authentication method that runs over a single TCP connection between each client and server. In contrast, with Kerberos, the client also obtains a ticket based on a service identifier (SPN) and sends it to IIS. These credentials are then passed to IIS in the HTTP header (Authorization: Negotiate ... However, a Layer 7 load balancer terminates the HTTPS connection from the client on its own device, analyzes the contents, and forwards it to the back-end IIS as a new request.The end-to-end TLS session between the client and IIS is terminated.Furthermore, persistent authentication information such as NTLM is not carried over, causing the authentication process to fail.

In light of the above background, this article ."Load balancer + Configuring IIS Integrated Windows Authentication to succeed in an SSL environment We will consider three typical configuration patterns and explain whether or not Windows authentication is supported for each, the technical reasons for this, and the advantages and disadvantages of each configuration.

Technical verification of each configuration plan

①: L7 load balancer SSL termination + forwarding to IIS (80 or 443)

Client ──HTTPS──▶ L7 Load Balancer (SSL termination) ──HTTP(S)──▶ IIS (80 or 443)

Availability

Windows authentication is not supported in this configuration.Not availableIt is.

reason

Because the TLS session between the client and IIS is terminated once on the load balancer,End-to-end credential transfer is not possibleThe L7 load balancer decrypts the received HTTPS and accesses IIS on behalf of the client. At this time, the Authorization: Negotiate Headers (including Kerberos tickets and NTLM tokens) will not reach IIS correctly. In particular, with NTLM, the authentication challenge response (WWW-Authenticate) the client sends a re-request, but via the LBThe same TCP session is not maintainedTherefore, the NTLM handshake does not succeed.

In fact, even in an AWS environment, Windows authentication does not work with Application Load Balancer (ALB) or HTTP listeners, and a TCP-level LB such as Network Load Balancer (NLB) is required.reference]. Also, Azure Application Gateway v2 does not support transmitting HTTP headers containing integrated authentication to the backend.[reference].

The fact that it is not officially supported by managed LBs of each cloud vendor shows the difficulty of maintaining Windows authentication at the L7 level.

②: L4 load balancer (TLS pass-through) + IIS forwarding

Client ──HTTPS──▶ L4 Load Balancer (TLS pass-through) ──HTTPS──▶ IIS (443)

Availability

This configuration uses Windows authentication.CompatibleIt is.

reason

Since an L4 load balancer (LB that operates at OSI Layer 4) relays packets at the TCP level,TLS session between client and IIS is maintained end-to-endThe load balancer does not terminate encryption, but simply distributes the TCP connection to each server, so the "communication on the same TCP connection" required by NTLM authentication is maintained. As for Kerberos, from the client's perspective, it can reproduce the same state as connecting directly to the FQDN of IIS (service), so ticket-based authentication will pass as is as long as the SPN is set appropriately. AWS NLB and classic LB TCP listener mode, Azure internal load balancer, F5 L4 mode, etc. belong to this category (others include HAProxy TCP mode, nginx stream, etc.), and can pass through Windows integrated authentication.

Advantages

The TLS session is not interrupted from the client to the server.Windows authentication protocols continue to work as they shouldYes, you can. The NTLM three-way handshake is completed within a single connection, and the Kerberos ticket is correctly received by the backend server. In addition, since LB operates as an L4 server, overhead is small and high throughput can be expected.

demerit

The biggest challenge with L4 load balancer configuration is the lack of granular path-based or hostname-based routing./api, ,/chatDistributing each request (or multiple requests) to a different backend server is a feature that can only be achieved with L7 (HTTP) and is not possible with L4 (TCP).

Therefore, depending on the system requirements, it may be necessary to prepare multiple FQDNs and assign different virtual servers for different purposes (web servers, servers for Windows authentication, etc.) within the load balancer, which has the disadvantage of making the configuration more difficult.

Also, please note that the following settings required for Windows authentication all set the FQDN of the load balancer.

• Windows authentication is required in the Internet Options "Security" tab."Local intranet" "Sites" setting
• When accessing the Windows authentication page using FQDN (fully qualified domain name) SPN Registration
• IIS サイトバインド設定とSSL証明書（ロードバランサー自体に証明書設置は不要）

* If the load balancer FQDN is lb.example.com, the flow until Kerberos is successful is as follows:

[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 load balancer SSL termination + redirect to IIS configuration

Client ──HTTPS──▶ L7 load balancer (SSL termination)
LB ──HTTP 302 (Redirect response) → Client
Client ──HTTPS──▶ IIS (direct access to 443)

Availability

This configuration uses Windows authentication.CompatibleIt is.

reason

The idea is that the load balancer does not relay the actual communication, but instead redirects the client directly to the backend IIS with a single HTTP 302 response. The first time the user accesses the LB URL, the L7 load balancer terminates SSL there, analyzes the content, and returns a 302 response with a Location header to connect to the appropriate IIS address (e.g., the individual hostname or IP address of each IIS) via HTTPS. The client browser receives this redirect and automatically re-sends the request directly to the specified IIS via HTTPS.

result,For the second request, the client and IIS connect directly via TLSTherefore, Kerberos/NTLM authentication information is exchanged end-to-end as is. Since the load balancer is not involved in the authentication process, the problem of authentication header loss as seen in configuration 1 can be avoided.

Advantages

A major advantage is that TLS is directly connected from the client to IIS, making Windows authentication easy to succeed.It is.
If authentication is successful using IIS alone, the configuration can be used as is, so there is no increase in difficulty even if a load balancer is used as an intermediary.

In addition, by utilizing redirection, a certain degree of flexible routing control is possible on the load balancer side. For example, by redirecting to different backend IIS URLs depending on the initial access URL path or host name, it is possible to achieve something close to path-based distribution. If there are many services under LB, it is possible to configure it so that they are aggregated in LB as a common entry point for the time being, and then directed to the actual URL of each service from there, making it appear as one on the surface.

demerit

The disadvantage is that IIS cannot be deployed behind the LB, and a separate endpoint must be designed for IIS as a public server, and a different certificate must be placed for the LB.

Another disadvantage is that a redirect occurs the first time you access the site, but in reality, an immediate reconnection is performed via an HTTP 302 response, so the impact on the user experience is almost negligible.

For reference on the speed of logging in to our service after redirecting to IIS and going through Windows authentication, see heremoviefor more information.

Comparison table of each configuration

summary

For Windows authentication (NTLM/Kerberos) to work properly, it is imperative that the TLS session is maintained all the way from the client to IIS.

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

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

On the other hand, in a configuration like Option 1, where the L7 load balancer performs TLS termination or HTTP interpretation, authentication information is interrupted and Windows authentication does not work.

We hope that this article will be helpful in considering a configuration that achieves both load balancing and encrypted communication while maintaining a robust authentication system.