{"id":11700,"date":"2025-03-31T11:01:47","date_gmt":"2025-03-31T02:01:47","guid":{"rendered":"https:\/\/chat-messenger.com\/?p=11700"},"modified":"2025-04-25T14:39:43","modified_gmt":"2025-04-25T05:39:43","slug":"windowsauthentication-loadbalancer-ssl","status":"publish","type":"post","link":"https:\/\/chat-messenger.com\/fr\/blog\/equilibreur-de-charge-dauthentification-windows-ssl","title":{"rendered":"Comment configurer l'authentification Windows int\u00e9gr\u00e9e IIS pour r\u00e9ussir dans un environnement d'\u00e9quilibrage de charge + SSL"},"content":{"rendered":"

\u00c0 propos de l'authentification Windows int\u00e9gr\u00e9e<\/h2>\n\n\n\n

L'authentification Windows int\u00e9gr\u00e9e est un m\u00e9canisme qui fournit automatiquement des informations d'authentification utilisateur \u00e0 IIS lorsque IIS et l'utilisateur appartiennent au m\u00eame domaine Active Directory. Lorsque vous cr\u00e9ez un site \u00e0 l\u2019aide d\u2019ASP.NET C#, vous pouvez d\u00e9terminer si un utilisateur a \u00e9t\u00e9 authentifi\u00e9 et obtenir des informations sur les utilisateurs authentifi\u00e9s.<\/p>\n\n\n\n

Cela permet aux utilisateurs d'acc\u00e9der aux applications Web h\u00e9berg\u00e9es (ou li\u00e9es) par IIS sans op\u00e9rations de connexion suppl\u00e9mentaires et permet l'int\u00e9gration SSO avec d'autres serveurs d'applications.<\/p>\n\n\n\n

Cependant, dans un environnement o\u00f9 le serveur Web (IIS) est sous un \u00e9quilibreur de charge et la communication est crypt\u00e9e avec SSL\/TLS, cette authentification Windows peut ne pas fonctionner correctement.Pourquoi donc?<\/span><\/p>\n\n\n\n

\n
\n

Si l\u2019authentification Windows r\u00e9ussit, vous pourrez acc\u00e9der de mani\u00e8re transparente au site d\u2019authentification, mais si elle \u00e9choue, un cadran de connexion s\u2019affichera. Si vous ne vous authentifiez pas correctement, vous obtiendrez l\u2019erreur HTTP 401.1 \u2013 Non autoris\u00e9.<\/p>\n<\/div>\n\n\n\n

\n
\"\"<\/figure>\n<\/div>\n<\/div>\n\n\n\n

Le point est Comment fonctionne l'authentification Windows<\/strong> et Fonctionnement de l'\u00e9quilibreur de charge<\/strong> est situ\u00e9.<\/p>\n\n\n\n

NTLM est une m\u00e9thode d'authentification par d\u00e9fi\/r\u00e9ponse sur une seule connexion TCP entre chaque client et serveur. Avec Kerberos, le client obtient \u00e9galement un ticket bas\u00e9 sur l'identifiant de service (SPN) et l'envoie \u00e0 IIS. Ces informations d'identification sont envoy\u00e9es via l'en-t\u00eate HTTP (Autorisation : N\u00e9gocier...<\/code> Les transactions sont effectu\u00e9es \u00e0 l\u2019aide de telles m\u00e9thodes. Cependant, un \u00e9quilibreur de charge de couche 7 met fin \u00e0 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\u00e9e.<\/span>De plus, les informations d\u2019authentification persistantes telles que NTLM ne sont pas transf\u00e9r\u00e9es, ce qui entra\u00eene l\u2019\u00e9chec du processus d\u2019authentification.<\/p>\n\n\n\n

\u00c0 la lumi\u00e8re du contexte ci-dessus, cet article "\u00c9quilibreur de charge<\/strong><\/strong> + Configuration de l'authentification Windows int\u00e9gr\u00e9e IIS pour r\u00e9ussir dans un environnement SSL<\/strong> Nous allons consid\u00e9rer les points suivants. Nous allons \u00e9num\u00e9rer trois mod\u00e8les 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\u00e9nients de la configuration.<\/p>\n\n\n\n

V\u00e9rification technique de chaque plan de configuration<\/h2>\n\n\n\n

1\u00a0: Terminaison SSL de l'\u00e9quilibreur de charge L7 + transfert vers IIS (80 ou 443)<\/h3>\n\n\n\n

Client \u2500\u2500HTTPS\u2500\u2500\u25b6 \u00c9quilibreur de charge L7 (terminaison SSL) \u2500\u2500HTTP(S)\u2500\u2500\u25b6 IIS (80 ou 443)<\/p>\n\n\n\n

Disponibilit\u00e9<\/strong><\/h4>\n\n\n\n

L'authentification Windows n'est pas prise en charge dans cette configuration.Pas disponible<\/span>est.<\/p>\n\n\n\n

raison<\/strong><\/h4>\n\n\n\n

\u00c9tant donn\u00e9 que la session TLS entre le client et IIS est termin\u00e9e une fois sur l'\u00e9quilibreur de charge,Le transfert d'informations d'identification de bout en bout n'est pas possible<\/span>C'est pourquoi. L'\u00e9quilibreur de charge L7 d\u00e9crypte le trafic HTTPS re\u00e7u et acc\u00e8de \u00e0 IIS au nom du client. \u00c0 ce moment-l\u00e0, le client doit envoyer le Autorisation : N\u00e9gocier<\/code> Les en-t\u00eates (en-t\u00eates d'authentification, y compris les tickets Kerberos et les jetons NTLM) n'atteindront pas correctement IIS. Plus pr\u00e9cis\u00e9ment, avec NTLM, la r\u00e9ponse au d\u00e9fi d'authentification qu'IIS envoie \u00e0 la requ\u00eate initiale (WWW-Authentifier<\/code>) le client envoie une nouvelle demande, mais via le LBLa m\u00eame session TCP n'est pas maintenue<\/span>Par cons\u00e9quent, la poign\u00e9e de main NTLM ne r\u00e9ussit pas.<\/p>\n\n\n\n

En fait, m\u00eame dans un environnement AWS, l'authentification Windows ne fonctionne pas avec Application Load Balancer (ALB) ou les \u00e9couteurs HTTP, et un LB de niveau TCP tel que Network Load Balancer (NLB) est requis.r\u00e9f\u00e9rence<\/a>]. De plus, Azure Application Gateway v2 ne prend pas en charge la transmission d\u2019en-t\u00eates HTTP, y compris l\u2019authentification int\u00e9gr\u00e9e au backend.r\u00e9f\u00e9rence<\/a>].<\/p>\n\n\n\n

Le fait qu'il ne soit pas officiellement pris en charge par les LB g\u00e9r\u00e9s de chaque fournisseur de cloud montre la difficult\u00e9 de maintenir l'authentification Windows au niveau L7.<\/p>\n\n\n\n

2\u00a0: \u00c9quilibreur de charge L4 (transfert TLS) + transfert IIS<\/h3>\n\n\n\n

Client \u2500\u2500HTTPS\u2500\u2500\u25b6 \u00c9quilibreur de charge L4 (transmission TLS) \u2500\u2500HTTPS\u2500\u2500\u25b6 IIS (443)<\/p>\n\n\n\n

Disponibilit\u00e9<\/strong><\/h4>\n\n\n\n

Cette configuration utilise l\u2019authentification Windows.Compatible<\/span>est.<\/p>\n\n\n\n

raison<\/strong><\/h4>\n\n\n\n

\u00c9tant donn\u00e9 qu'un \u00e9quilibreur 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 bout<\/span>sera fait. L'\u00e9quilibreur de charge ne met pas fin au chiffrement, mais distribue simplement la connexion TCP elle-m\u00eame \u00e0 chaque serveur, de sorte que la \u00ab communication sur la m\u00eame connexion TCP \u00bb requise par l'authentification NTLM est maintenue. Quant \u00e0 Kerberos, du point de vue du client, il peut \u00eatre reproduit comme si le client se connectait directement au FQDN d'IIS (service), donc tant que le SPN est d\u00e9fini de mani\u00e8re appropri\u00e9e, l'authentification bas\u00e9e sur les tickets se d\u00e9roulera telle quelle. Le mode d'\u00e9coute AWS NLB et LB TCP classique, l'\u00e9quilibreur de charge interne Azure, le mode F5 L4, etc. appartiennent \u00e0 cette cat\u00e9gorie (d'autres incluent le mode TCP HAProxy et le flux nginx) et peuvent passer par l'authentification int\u00e9gr\u00e9e Windows.<\/p>\n\n\n\n

m\u00e9rite<\/strong><\/h4>\n\n\n\n

La session TLS n'est pas interrompue du client au serveur.Les protocoles d\u2019authentification Windows continuent de fonctionner comme ils le devraient<\/span>peut. La n\u00e9gociation \u00e0 trois voies NTLM est \u00e9galement effectu\u00e9e au sein d'une seule connexion et le ticket Kerberos est correctement re\u00e7u par le serveur principal. De plus, comme LB est une op\u00e9ration L4, sa surcharge est faible et on peut s'attendre \u00e0 ce qu'elle atteigne un d\u00e9bit \u00e9lev\u00e9.<\/p>\n\n\n\n

D\u00e9m\u00e9rite<\/strong><\/h4>\n\n\n\n

Le plus grand d\u00e9fi dans la configuration d\u2019un \u00e9quilibreur de charge L4 est l\u2019incapacit\u00e9 d\u2019effectuer un routage d\u00e9taill\u00e9 bas\u00e9 sur le chemin ou le nom d\u2019h\u00f4te. Par exemple, dans un chemin d'URL (par ex.\/api<\/code>,,\/chat<\/code>La distribution de chaque requ\u00eate (ou de plusieurs requ\u00eates) vers un serveur backend diff\u00e9rent est une fonctionnalit\u00e9 qui ne peut \u00eatre r\u00e9alis\u00e9e qu'avec L7 (HTTP) et n'est pas possible avec L4 (TCP).<\/p>\n\n\n\n

Par cons\u00e9quent, en fonction des exigences du syst\u00e8me, il peut \u00eatre n\u00e9cessaire de pr\u00e9parer plusieurs FQDN et d'attribuer diff\u00e9rents serveurs virtuels \u00e0 des fins diff\u00e9rentes (serveurs Web, serveurs pour l'authentification Windows, etc.) au sein de l'\u00e9quilibreur de charge, ce qui pr\u00e9sente l'inconv\u00e9nient de rendre la configuration plus difficile.<\/p>\n\n\n\n

En particulier, lors de l'acc\u00e8s \u00e0 la page d'authentification Windows \u00e0 l'aide d'un FQDN (nom de domaine complet), Inscription SPN<\/a> c'est assez compliqu\u00e9, alors veuillez voir ci-dessous.<\/p>\n\n\n

\t\t\t
\n\t\t\t\t
\n\t\t\t\t\tChat&Messenger pour les conf\u00e9rences en ligne<\/span>\n\t\t\t\t\t
\"\"<\/figure><\/div>\t\t\t\t\t
\n\t\t\t\t\t\tParam\u00e8tres IIS pour une authentification Windows int\u00e9gr\u00e9e r\u00e9ussie dans un environnement d'\u00e9quilibrage de charge L4 | Web Conferencing Chat & Messenger<\/a>\n\t\t\t\t\t\tPr\u00e9sentation L'article suivant explique comment configurer l'authentification Windows int\u00e9gr\u00e9e (IWA) dans IIS dans un environnement d'\u00e9quilibrage de charge L4 avec terminaison SSL. Cette m\u00e9thode\u2026<\/span>\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t<\/div>\n\t\t<\/div>\n\n\n

Veuillez \u00e9galement noter que les param\u00e8tres suivants requis pour l\u2019authentification Windows d\u00e9finissent tous le nom de domaine complet de l\u2019\u00e9quilibreur de charge.<\/p>\n\n\n\n