Comment configurer l'authentification Windows intégrée IIS pour réussir dans un environnement d'équilibrage de charge + SSL

31 mars 2025

table des matières

À propos de l'authentification Windows intégrée

L'authentification Windows intégrée est un mécanisme qui fournit automatiquement des informations d'authentification utilisateur à IIS lorsque IIS et l'utilisateur appartiennent au même domaine Active Directory. Lorsque vous créez un site à l’aide d’ASP.NET C#, vous pouvez déterminer si un utilisateur a été authentifié et obtenir des informations sur les utilisateurs authentifiés.

Cela permet aux utilisateurs d'accéder aux applications Web hébergées (ou liées) par IIS sans opérations de connexion supplémentaires et permet l'intégration SSO avec d'autres serveurs d'applications.

Cependant, dans un environnement où le serveur Web (IIS) est sous un équilibreur de charge et la communication est cryptée avec SSL/TLS, cette authentification Windows peut ne pas fonctionner correctement.Pourquoi donc?

Si l’authentification Windows réussit, vous pourrez accéder de manière transparente au site d’authentification, mais si elle échoue, un cadran de connexion s’affichera. Si vous ne vous authentifiez pas correctement, vous obtiendrez l’erreur HTTP 401.1 – Non autorisé.

Le point est Comment fonctionne l'authentification Windows et Fonctionnement de l'équilibreur de charge est situé.

NTLM est une méthode d'authentification par défi/réponse sur une seule connexion TCP entre chaque client et serveur. Avec Kerberos, le client obtient également un ticket basé sur l'identifiant de service (SPN) et l'envoie à IIS. Ces informations d'identification sont envoyées via l'en-tête HTTP (Autorisation : Négocier... Les transactions sont effectuées à l’aide de telles méthodes. Cependant, un équilibreur de charge de couche 7 met fin à la connexion HTTPS du client sur son propre appareil, analyse le contenu et le transmet au serveur IIS principal en tant que nouvelle demande. Au cours de ce processusLa session TLS de bout en bout entre le client et IIS est terminée.De plus, les informations d’authentification persistantes telles que NTLM ne sont pas transférées, ce qui entraîne l’échec du processus d’authentification.

À la lumière du contexte ci-dessus, cet article "Équilibreur de charge + Configuration de l'authentification Windows intégrée IIS pour réussir dans un environnement SSL Nous allons considérer les points suivants. Nous allons énumérer trois modèles de configuration typiques et expliquer pour chacun d'eux si l'authentification Windows est prise en charge, les raisons techniques de cela et les avantages et inconvénients de la configuration.

Vérification technique de chaque plan de configuration

1 : Terminaison SSL de l'équilibreur de charge L7 + transfert vers IIS (80 ou 443)

Client ──HTTPS──▶ Équilibreur de charge L7 (terminaison SSL) ──HTTP(S)──▶ IIS (80 ou 443)

Disponibilité

L'authentification Windows n'est pas prise en charge dans cette configuration.Pas disponibleest.

raison

Étant donné que la session TLS entre le client et IIS est terminée une fois sur l'équilibreur de charge,Le transfert d'informations d'identification de bout en bout n'est pas possibleC'est pourquoi. L'équilibreur de charge L7 décrypte le trafic HTTPS reçu et accède à IIS au nom du client. À ce moment-là, le client doit envoyer le Autorisation : Négocier Les en-têtes (en-têtes d'authentification, y compris les tickets Kerberos et les jetons NTLM) n'atteindront pas correctement IIS. Plus précisément, avec NTLM, la réponse au défi d'authentification qu'IIS envoie à la requête initiale (WWW-Authentifier) le client envoie une nouvelle demande, mais via le LBLa même session TCP n'est pas maintenuePar conséquent, la poignée de main NTLM ne réussit pas.

En fait, même dans un environnement AWS, l'authentification Windows ne fonctionne pas avec Application Load Balancer (ALB) ou les écouteurs HTTP, et un LB de niveau TCP tel que Network Load Balancer (NLB) est requis.référence]. De plus, Azure Application Gateway v2 ne prend pas en charge la transmission d’en-têtes HTTP, y compris l’authentification intégrée au backend.référence].

Le fait qu'il ne soit pas officiellement pris en charge par les LB gérés de chaque fournisseur de cloud montre la difficulté de maintenir l'authentification Windows au niveau L7.

2 : Équilibreur de charge L4 (transfert TLS) + transfert IIS

Client ──HTTPS──▶ Équilibreur de charge L4 (transmission TLS) ──HTTPS──▶ IIS (443)

Disponibilité

Cette configuration utilise l’authentification Windows.Compatibleest.

raison

Étant donné qu'un équilibreur de charge L4 (LB qui fonctionne au niveau OSI Layer 4) relaie les paquets au niveau TCP,La session TLS entre le client et IIS est maintenue de bout en boutsera fait. L'équilibreur de charge ne met pas fin au chiffrement, mais distribue simplement la connexion TCP elle-même à chaque serveur, de sorte que la « communication sur la même connexion TCP » requise par l'authentification NTLM est maintenue. Quant à Kerberos, du point de vue du client, il peut être reproduit comme si le client se connectait directement au FQDN d'IIS (service), donc tant que le SPN est défini de manière appropriée, l'authentification basée sur les tickets se déroulera telle quelle. Le mode d'écoute AWS NLB et LB TCP classique, l'équilibreur de charge interne Azure, le mode F5 L4, etc. appartiennent à cette catégorie (d'autres incluent le mode TCP HAProxy et le flux nginx) et peuvent passer par l'authentification intégrée Windows.

mérite

La session TLS n'est pas interrompue du client au serveur.Les protocoles d’authentification Windows continuent de fonctionner comme ils le devraientpeut. La négociation à trois voies NTLM est également effectuée au sein d'une seule connexion et le ticket Kerberos est correctement reçu par le serveur principal. De plus, comme LB est une opération L4, sa surcharge est faible et on peut s'attendre à ce qu'elle atteigne un débit élevé.

Démérite

Le plus grand défi dans la configuration d’un équilibreur de charge L4 est l’incapacité d’effectuer un routage détaillé basé sur le chemin ou le nom d’hôte. Par exemple, dans un chemin d'URL (par ex./api,,/chatLa distribution de chaque requête (ou de plusieurs requêtes) vers un serveur backend différent est une fonctionnalité qui ne peut être réalisée qu'avec L7 (HTTP) et n'est pas possible avec L4 (TCP).

Par conséquent, en fonction des exigences du système, il peut être nécessaire de préparer plusieurs FQDN et d'attribuer différents serveurs virtuels à des fins différentes (serveurs Web, serveurs pour l'authentification Windows, etc.) au sein de l'équilibreur de charge, ce qui présente l'inconvénient de rendre la configuration plus difficile.

Veuillez également noter que les paramètres suivants requis pour l’authentification Windows définissent tous le nom de domaine complet de l’équilibreur de charge.

L'authentification Windows est requise dans l'onglet « Sécurité » des options Internet.« Intranet local » « Sites » paramètre
Lors de l'accès à la page d'authentification Windows à l'aide du FQDN (nom de domaine complet) Inscription SPN
IIS サイトバインド設定とSSL証明書（ロードバランサー自体に証明書設置は不要）

* Si le nom de domaine complet de l'équilibreur de charge est lb.example.com, le flux jusqu'à ce que Kerberos réussisse est le suivant :

[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、認証成功

③ : Terminaison SSL de l'équilibreur de charge L7 + redirection vers la configuration IIS

Client ──HTTPS──▶ Équilibreur de charge L7 (terminaison SSL)
LB ──HTTP 302 (Réponse de redirection) → Client
Client ──HTTPS──▶ IIS (accès direct à 443)

Disponibilité

Cette configuration utilise l’authentification Windows.Compatibleest.

raison

L'idée est que l'équilibreur de charge ne relaie pas la communication réelle, mais redirige plutôt le client directement vers le backend IIS (réponse HTTP 302). La première fois qu'un utilisateur accède à l'URL LB, l'équilibreur de charge L7 y arrête SSL, analyse le contenu et renvoie une réponse 302 avec un en-tête Location pour se connecter à l'adresse IIS appropriée (par exemple, le nom d'hôte individuel ou l'adresse IP pour chaque IIS) via HTTPS. Le navigateur client reçoit cette redirection et renvoie automatiquement la demande via HTTPS directement à l'IIS spécifié.

résultat,Pour la deuxième requête, le client et IIS se connectent directement via TLSPar conséquent, les informations d’authentification Kerberos/NTLM sont transmises de bout en bout telles quelles. Étant donné que l'équilibreur de charge n'intervient pas pendant le processus d'authentification, il peut éviter le problème de perte de l'en-tête d'authentification comme indiqué dans la configuration 1.

mérite

L’un des principaux avantages est que TLS est directement connecté du client à IIS, ce qui facilite la réussite de l’authentification Windows.est.
Si l’authentification réussit en utilisant IIS seul, la configuration peut être utilisée telle quelle, il n’y a donc pas d’augmentation de difficulté même si un équilibreur de charge est utilisé comme intermédiaire.

De plus, en utilisant la redirection, un certain degré de contrôle de routage flexible est possible du côté de l'équilibreur de charge. Par exemple, vous pouvez obtenir quelque chose de proche d'une distribution basée sur le chemin en redirigeant vers différentes URL IIS backend en fonction du chemin d'accès initial de l'URL ou du nom d'hôte. S'il existe de nombreux services sous le LB, il est possible de les regrouper d'abord dans le LB en tant que point d'entrée commun, puis de diriger les utilisateurs vers les URL réelles de chaque service à partir de là, les faisant apparaître comme un seul en surface.

Démérite

L’inconvénient est qu’IIS ne peut pas être déployé derrière le LB, et un point de terminaison distinct doit être conçu pour IIS en tant que serveur public, et un certificat différent doit être placé pour le LB.

Un autre inconvénient est qu’une redirection se produit lors du premier accès, mais en réalité, une reconnexion immédiate est effectuée via une réponse HTTP 302, donc l’impact sur l’expérience utilisateur est presque négligeable.

Pour plus d'informations sur la vitesse de connexion à notre service après avoir redirigé vers IIS et passé par l'authentification Windows, voir icifilmPrière de se référer à.

Tableau comparatif de chaque configuration

composition	aperçu	Authentification Windows	remarques
1	L7 LB (terminaison SSL) → IIS	❌ Non	・Séparation TLS, non-transmission NTLM/Kerberos
②	L4 LB (transfert TLS) → IIS	✅ Oui	・パスベースのルーティング不可、複数FQDNで仮想サーバーをLBに設定してルーティング・IIS側に証明書を設定（LBに証明書不要）・IIS 443ポートはLBからインバウンド接続のみ許可・Dans l'ensemble, il existe peu de documentation officielle et il est difficile de
③	L7 LB (terminaison SSL) → Redirection vers IIS	✅ Oui	・Routage basé sur le chemin disponible ・IIS側及びロードバランサーに証明書が必要・IIS 443ポートは ANYでインバウンド接続を許可・Facile à tester car IIS peut être testé seul

Tableau comparatif de chaque configuration

résumé

Pour que l’authentification Windows (NTLM/Kerberos) fonctionne correctement, il est impératif que la session TLS soit maintenue du client jusqu’à IIS.

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

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

En revanche, dans une configuration comme l’option 1, où l’équilibreur de charge L7 effectue la terminaison TLS ou l’interprétation HTTP, les informations d’authentification sont interrompues et l’authentification Windows ne fonctionne pas.

Nous espérons que cet article vous sera utile pour envisager une configuration qui permette à la fois l’équilibrage de charge et la communication cryptée tout en maintenant un système d’authentification robuste.

URLをコピーしました！