Lastverteilung von Webanwendungen mit IIS-Authentifizierung NTLM und ASP.NET-Identitätswechsel

GESCHRIEBEN VON Zevenet | 2. August 2018

Übersicht

Der Microsoft-Webserver Internet Information Services (IIS) integriert mehrere Authentifizierungsmechanismen, um Benutzer anhand von Active Directory- oder Stand-Alone-Systemen (LDAP-basierte Authentifizierung) zu überprüfen. NTLM ist das Windows Challenge / Response-Authentifizierungsprotokoll, das in Netzwerken und Anwendungen verwendet werden kann, die in beiden Umgebungen verwendet werden können.

Zwei verschiedene Szenarien können berücksichtigt werden: Interaktive NTLM-Authentifizierung ist ein Verbund aus zwei Systemen, einem Client und einem Domänencontroller, auf dem die für die Authentifizierung erforderlichen Benutzerdaten gespeichert werden Nicht interaktive NTLM-Authentifizierung umfasst drei verschiedene Systeme, einen Client, einen Anwendungsserver und eine Domäne, um einem Benutzer den Zugriff auf eine bestimmte Ressource in einer Anwendung zu ermöglichen.

ASP.NET-Identitätswechsel erlaubt es Webanwendungen, Benutzer zu authentifizieren und zu autorisieren, die Microsoft IIS verwenden.

In diesem Artikel wird erläutert, wie Sie Lastausgleichsanwendungen erstellen, die das NTLM-Protokoll für nicht interaktive Benutzerauthentifizierungsszenarien integrieren.

Wie funktioniert NTLM?

Das NTLM-Protokoll basiert auf dem HTTP / S-Protokoll, bei dem ein bestimmter Client einen Handshake von insgesamt 6-Schritten startet, um die authentifizierte Sitzung einzurichten.

Der authentifizierte Sitzungshandshake erfordert die folgenden Schritte:

1. Der Client initiiert eine anonyme Anforderung einer bestimmten Ressource an einen Webserver.

GET / HTTP

2. Der Server antwortet mit einer nicht autorisierten Nachricht und der Authentifizierungsmethode, die der Client verwenden muss.

401 Unauthorized
WWW-Authenticate: NTLM

3. Der Client sendet die Anforderung erneut, einschließlich einer Authentifizierungsaufforderung im NTLM-Format.

GET / HTTP
Authorization: NTLM <base64-encoded first NTLM message>

4. Der Server antwortet mit einer nicht autorisierten Nachricht und fordert weitere Informationen an den Client an.

401 Unauthorized
WWW-Authenticate: NTLM <base64-encoded second NTLM message>

5. Der Client sendet die Anforderung einschließlich eines Teils der Sitzungsinformationen erneut.

GET / HTTP
Authorization: NTLM <base64-encoded third NTLM message>

6. Der Server stellt eine Verbindung zum Domänencontroller her, um die Authentifizierungsanforderung abzuschließen, und bestätigt dem Client anschließend die Authentifizierung.

HTTP 200 OK

Beachten Sie, dass dieser Handshake bei jeder neuen Verbindung erforderlich ist, nicht bei HTTP-Anforderungen. Während der Schritte 3 bis 6 muss die Verbindung am Leben gehalten werden. Wenn die Verbindung geschlossen ist, sollte dieser Teil des Handshakes wiederholt werden und es ist nicht gültig, nur ab Schritt 5 zu wiederholen. Wenn die Verbindung authentifiziert ist, muss der Autorisierungsheader nicht erneut gesendet werden, während der Die Verbindung wird nicht unabhängig von der Ressource geschlossen, auf die zugegriffen wird.

Wie werden Balanced-Webanwendungen mithilfe der NTLM-Authentifizierung geladen?

Mit Zevenet gibt es 2-Hauptmethoden zum Lastausgleich und zum Erstellen einer NTLM-basierten Webanwendung mit hoher Verfügbarkeit, mit einem einfachen Layer-4-TCP-Lastausgleich oder mit einem Layer-7-Proxy für erweiterte Funktionen.

Einfacher NTLM-Lastausgleich auf Layer 4

Um Webanwendungen mit NTLM-Authentifizierung mit einer einfachen Konfiguration ausgleichen zu können, können wir LSLB-basierte Farmen mit L4xNAT-Profil erstellen. Wir können entweder HTTP- oder HTTPS-Protokolle verwenden.

Stellen Sie dann in der globalen Konfiguration sicher, dass das verwendete Protokoll verwendet wird TCP aber wir können auswählen NAT or DTA entsprechend der erforderlichen Topologie.

In den Dienstleistungen In diesem Abschnitt muss die Persistenz festgelegt werden, um sicherzustellen, dass die Authentifizierung für einen bestimmten Client immer an dasselbe Backend erfolgt. Andernfalls kann die Verbindungsauthentifizierung nicht durchgeführt werden.

Fügen Sie schließlich Ihre Liste der Backends hinzu und konfigurieren Sie eine Zustandsprüfung wie in den folgenden Abschnitten angegeben.

NTLM-Lastausgleich auf Layer 7

Diese Option ermöglicht die Verarbeitung der HTTP / S-Daten mit NTLM-Unterstützung mit dem über das LSLB-Modul und die HTTP-Farm konfigurierten Layer-7-Proxy. Dazu müssen wir eine Farm für HTTP oder HTTPS gemäß den SSL-Anforderungen für den virtuellen Dienst erstellen. Der einzige Unterschied wäre der Hörer in der konfiguriert Globale Einstellungen der Farm erstellt.

Da auf dieser Ebene die Anwendung noch keine Sitzungscookies erstellen kann, um eine Persistenz oder ein Verbindungspinning zu erstellen, können wir das verwenden Cookie-Einfügung Diese Option ermöglicht es dem Load Balancer, beim ersten Handshake der NTLM-Authentifizierung ein neues Cookie zu erstellen.

Fügen Sie schließlich Ihre Liste der Backends hinzu und konfigurieren Sie eine Zustandsprüfung wie in den folgenden Abschnitten angegeben. Sie können zusätzliche Anwendungsoptionen auf Proxy-Ebene konfigurieren, die in dieser Art von Farm enthalten sind, und die NTLM-Unterstützung ist davon nicht betroffen.

Erweiterte Integritätsprüfungen für NTLM-Authentifizierungswebsites

Um unsere benutzerdefinierte erweiterte Integritätsprüfung für NTLM-authentifizierte Anwendungen zu erstellen, müssen wir sie unter dem Pfad erstellen / usr / local / zevenet / app / libexec Ein Skript zum Überprüfen des Backends, wie unten gezeigt. Beispielsweise, check_ntlm.sh mit den entsprechenden Berechtigungen.

#!/bin/bash

# get input parameters
BACKEND=$1
PORT=$2
USER=$3
PASS=$4
URI=$5
STRING=$6

/usr/bin/curl http://${BACKEND}:${PORT}${URI} --ntlm -negotiate -u ${USER}:${PASS} 2>/dev/null | grep "${STRING}" &>/dev/null

if [ $? == 0 ]
then
	# if the curl command doesn't fail then notify that the backend is up
	echo "Server ${BACKEND}:${PORT} OK"
	exit 0
fi

# if the the curl command fails then notify that the backend is down
echo "Server ${BACKEND}:${PORT} is not OK"
exit 1

In den Überwachung >> Farmguardian Abschnitt, falls zutreffend, oder fügen Sie ihn dem Befehl zum Einchecken des Farmdiensts hinzu.

Wir können das Health-Check-Skript testen, indem Sie Folgendes ausführen:

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

Wissen, dass die Backend-IP ist 192.168.0.99 der Hafen ist 80 HTTP, johndoe ist ein Dummy-Benutzer in unserer Domain, Johnsecret ist das Dummy-Passwort, "/ My / uri" ist der zu überprüfende URI und "DOCTYPE html" ist die Zeichenfolge, die in den Antwortdaten zu finden ist, wenn die Anforderung erfolgreich ist.

Wir empfehlen, einen Dummy-Benutzer zu erstellen, der sich in der Domäne ohne Berechtigungen anmelden kann, um ihn in die Integritätsprüfung unserer Dienste aufzunehmen. Das ist der Grund für die Verwendung der johndoe Dummy-Benutzer in unserem benutzerdefinierten Gesundheitscheck.

Wenn unsere Integritätsprüfung von der Befehlszeile aus getestet wird, können Sie sie den mit NTLM-Unterstützung konfigurierten Farmen zuweisen.

Genießen Sie Ihre NTLM-Webanwendungen mit Lastausgleich!

Teilen:

Dokumentation unter den Bedingungen der GNU Free Documentation License.

War dieser Artikel hilfreich?

Verwandte Artikel