Aperçu #

Le serveur Web de Microsoft, Internet Information Services (IIS), intègre plusieurs mécanismes d’authentification afin de valider les utilisateurs par rapport à un système Active Directory ou autonome (authentification basée sur LDAP). NTLM est le protocole d'authentification Windows Challenge / Réponse pouvant être utilisé dans des réseaux et des applications pouvant être utilisés dans les deux environnements.

Deux scénarios différents pourraient être pris en compte: Authentification NTLM interactive est composé de deux systèmes, un client et un contrôleur de domaine, utilisés pour stocker les données des utilisateurs nécessaires pour servir les authentifications, et Authentification NTLM non interactive implique trois systèmes différents: un client, un serveur d'applications et un domaine afin de permettre à un utilisateur d'accéder à une certaine ressource dans une application.

Emprunt d'identité ASP.NET permet aux applications Web d'authentifier et d'autoriser les utilisateurs qui s'appuient sur Microsoft IIS.

Dans cet article, nous allons expliquer comment équilibrer la charge des applications qui intègrent le protocole NTLM pour les scénarios d'authentification des utilisateurs non interactifs.

Comment fonctionne NTLM? #

Le protocole NTLM repose sur le protocole HTTP / S dans lequel un client donné commence une poignée de main d'un total d'étapes 6 afin d'établir la session authentifiée.

La négociation de session authentifiée nécessite les étapes suivantes:

1. Le client lance une demande anonyme d'une certaine ressource à un serveur Web.

OBTENIR/HTTP

2. Le serveur répond avec un message non autorisé et la méthode d'authentification que le client doit utiliser.

401 Authentification WWW non autorisée : NTLM

3. Le client renvoie la demande, y compris un défi d'authentification au format NTLM.

Autorisation GET / HTTP : NTLM

4. Le serveur répond avec un message non autorisé et demande plus d'informations au client.

401 Authentification WWW non autorisée : NTLM

5. Le client renvoie la demande avec un reste des informations de la session.

Autorisation GET / HTTP : NTLM

6. Le serveur se connecte au contrôleur de domaine pour terminer la demande d'authentification, puis confirme l'authentification au client.

HTTP 200 OK

Notez que cette poignée de main est requise dans chaque nouvelle connexion, pas dans les requêtes HTTP, et pendant les étapes 3 à 6, la connexion doit être maintenue active. Si la connexion est fermée, cette partie de la poignée de main doit être répétée et il n'est pas valide de simplement répéter à partir de l'étape 5. Par contre, une fois la connexion authentifiée, l'en-tête Authorization n'a pas besoin d'être renvoyé alors que le la connexion n'est pas fermée indépendamment de la ressource accédée.

Comment équilibrer la charge des applications Web à l'aide de l'authentification NTLM? #

Avec RELIANOID, il existe 2 manières principales d'équilibrer la charge et de créer une application Web basée sur NTLM en haute disponibilité, avec un simple équilibreur de charge TCP de couche 4 ou avec un proxy de couche 7 pour les fonctionnalités avancées.

Equilibrage de charge NTLM simple sur la couche 4 #

Pour équilibrer la charge des applications Web avec prise en charge de l'authentification NTLM avec une configuration simple, nous pouvons créer des batteries de serveurs basées sur LSLB avec un profil L4xNAT. Nous pouvons utiliser les protocoles HTTP ou HTTPS.

Ensuite, dans la configuration globale, assurez-vous que le protocole utilisé est TCP mais on peut choisir NAT or DNAT en fonction de la topologie requise.

Dans l' Services section, il est nécessaire de définir la persistance afin de garantir que l'authentification pour un certain client va toujours au même backend, sinon l'authentification de la connexion ne pourrait pas être effectuée.

Enfin, ajoutez votre liste de moteurs et configurez une vérification de l’état comme indiqué dans les sections ci-dessous.

Equilibrage de charge NTLM sur la couche 7 #

Cette option permet de gérer les données HTTP / S avec prise en charge de NTLM avec le proxy 7 de couche configuré via le module LSLB et la batterie de serveurs HTTP. Pour cela, nous devons créer une batterie de serveurs pour HTTP ou HTTPS conformément aux exigences SSL pour le service virtuel. La seule différence serait la Auditeur configuré dans le Paramètres globaux de la ferme créée.

Sur cette couche, étant donné que l’application n’est pas encore en mesure de créer un cookie de session afin de créer une persistance ou une épinglage de connexion, nous pouvons utiliser le Insertion de cookie option qui permet à l'équilibreur de charge de créer un nouveau cookie lors de l'établissement initial de l'authentification NTLM.

Enfin, ajoutez votre liste de moteurs et configurez une vérification de l’état comme indiqué dans les sections ci-dessous. Vous pouvez configurer des options d'application supplémentaires au niveau du proxy inclus dans ce type de batterie et la prise en charge de NTLM ne sera pas affectée.

Contrôles d'intégrité avancés pour les sites Web d'authentification NTLM #

Pour créer notre vérification de l'état avancée personnalisée pour les applications authentifiées NTLM, nous devons créer sous le chemin /usr/local/relianoid/app/libexec un script pour vérifier le backend comme indiqué ci-dessous. Par exemple, check_ntlm.sh avec les autorisations appropriées.

#!/bin/bash # obtenir les paramètres d'entrée BACKEND=$1 PORT=$2 USER=$3 PASS=$4 URI=$5 STRING=$6 /usr/bin/curl http://${BACKEND}:${PORT}${URI } --ntlm -négocier -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null si [ $? == 0 ] then # si la commande curl n'échoue pas, notifiez que le backend est opérationnel echo "Server ${BACKEND}:${PORT} OK" exit 0 fi # si la commande curl échoue, notifiez que le backend est en panne echo "Le serveur ${BACKEND}:${PORT} n'est pas OK" sortie 1

Dans l' Surveillance >> Farmguardian section, le cas échéant, ou en l'ajoutant à la commande pour archiver le service de batterie de serveurs.

Nous pouvons tester le script de vérification de l'état en exécutant:

/usr/local/relianoid/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"

Sachant que l'adresse IP principale est 192.168.0.99 le port est 80 HTTP, johndoe est un utilisateur factice dans notre domaine, johnsecret est le mot de passe factice, "/ Mon / uri" est l'URI à vérifier et "DOCTYPE html" est la chaîne à rechercher dans les données de réponse lorsque la demande aboutit.

Nous vous recommandons de créer un utilisateur factice capable de se connecter au domaine mais sans autorisation, afin de l'inclure dans le bilan de santé de nos services. C'est la raison de l'utilisation du johndoe utilisateur factice dans notre bilan de santé personnalisé.

Lorsque notre bilan de santé est testé à partir de la ligne de commande et prêt, nous pouvons l'affecter aux batteries configurées avec le support NTLM.

Profitez de vos applications Web NTLM à charge équilibrée!