Übersicht #
Der Microsoft-Webserver Internet Information Services (IIS) integriert verschiedene Authentifizierungsmechanismen zur Benutzerauthentifizierung gegenüber Active Directory oder eigenständigen Systemen (LDAP-basierte Authentifizierung). NTLM ist das Windows-Challenge/Response-Authentifizierungsprotokoll, das in Netzwerken und Anwendungen eingesetzt werden kann, die in beiden Umgebungen funktionieren.
Es können zwei verschiedene Szenarien berücksichtigt werden: Die interaktive NTLM-Authentifizierung besteht aus zwei Systemen – einem Client und einem Domänencontroller, der zur Speicherung der für die Authentifizierung erforderlichen Benutzerdaten dient. Die nicht-interaktive NTLM-Authentifizierung hingegen 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.
Die ASP.NET-Identitätswechselfunktion ermöglicht es Webanwendungen, Benutzer zu authentifizieren und zu autorisieren, die auf Microsoft IIS angewiesen sind.
In diesem Artikel erklären wir, wie Sie die Last von Anwendungen ausgleichen, 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 mit insgesamt 6 Schritten startet, um die authentifizierte Sitzung herzustellen.
Der authentifizierte Sitzungs-Handshake erfordert die folgenden Schritte:
1. Der Client initiiert eine anonyme Anfrage nach einer bestimmten Ressource an einen Webserver.
GET / HTTP
2. Der Server antwortet mit einer Meldung über die fehlende Autorisierung und der Angabe der Authentifizierungsmethode, die der Client verwenden muss.
401 Nicht autorisierte WWW-Authentifizierung: NTLM
3. Der Client sendet die Anfrage erneut und fügt eine Authentifizierungsherausforderung im NTLM-Format hinzu.
GET / HTTP-Autorisierung: NTLM
4. Der Server antwortet mit einer Meldung über eine nicht autorisierte Anfrage und fordert weitere Informationen vom Client an.
401 Nicht autorisierte WWW-Authentifizierung: NTLM
5. Der Client sendet die Anfrage erneut und fügt dabei die restlichen Sitzungsinformationen hinzu.
GET / HTTP-Autorisierung: NTLM
6. Der Server stellt eine Verbindung zum Domänencontroller her, um die Authentifizierungsanfrage 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-Anfragen, und dass die Verbindung während der Schritte 3 bis 6 aufrechterhalten werden muss. Wenn die Verbindung geschlossen wird, muss dieser Teil des Handshakes wiederholt werden, und es ist nicht gültig, nur ab Schritt 5 zu wiederholen. Wenn die Verbindung jedoch einmal authentifiziert ist, muss der Autorisierungsheader nicht erneut gesendet werden, während die Verbindung unabhängig von der aufgerufenen Ressource nicht geschlossen wird.
Wie kann die Last von Webanwendungen mithilfe der NTLM-Authentifizierung ausgeglichen werden? #
Mit RELIANOIDEs gibt zwei Hauptmethoden zum Lastenausgleich und zum Erstellen einer NTLM-basierten Webanwendung mit hoher Verfügbarkeit: mit einem einfachen TCP-Lastenausgleich der Schicht 2 oder mit einem Proxy der Schicht 4 für erweiterte Funktionen.
Einfaches NTLM-Load-Balancing auf Layer 4 #
Um Webanwendungen mit NTLM-Authentifizierungsunterstützung mit einer einfachen Konfiguration auszugleichen, können wir LSLB-basierte Farmen mit L4xNAT-Profil erstellen. Wir können entweder HTTP- oder HTTPS-Protokolle verwenden.
Stellen Sie anschließend in der globalen Konfiguration sicher, dass das verwendete Protokoll TCP ist . Je nach benötigter Topologie können Sie jedoch NAT oder DNAT auswählen .
Im Abschnitt „Dienste“ muss die Persistenz eingestellt werden, um sicherzustellen, dass die Authentifizierung für einen bestimmten Client immer über dasselbe Backend erfolgt, da die Verbindungsauthentifizierung sonst nicht durchgeführt werden kann.
Fügen Sie abschließend Ihre Liste mit Backends hinzu und konfigurieren Sie eine Integritätsprüfung, wie in den folgenden Abschnitten angegeben.
NTLM-Lastausgleich auf Schicht 7 #
Diese Option ermöglicht die Verarbeitung von HTTP/S-Daten mit NTLM-Unterstützung über den Layer-7-Proxy, der über das LSLB-Modul und eine HTTP-Farm konfiguriert wird. Dazu muss je nach SSL-Anforderungen des virtuellen Dienstes eine Farm für HTTP oder HTTPS erstellt werden. Der einzige Unterschied besteht im Listener , der in den globalen Einstellungen der erstellten Farm konfiguriert ist.
Auf dieser Ebene, da die Anwendung noch keinen Session-Cookie erstellen kann, um eine Persistenz oder Verbindungsfixierung zu erreichen, können wir die Option „Cookie Insertion“ nutzen, die es dem Load Balancer ermöglicht, während des ersten Handshakes der NTLM-Authentifizierung einen neuen Cookie zu erstellen.
Fügen Sie abschließend Ihre Liste mit Backends hinzu und konfigurieren Sie einen Integritätscheck, 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 wird dadurch nicht beeinträchtigt.
Erweiterte Integritätsprüfungen für NTLM-Authentifizierungswebsites #
Um unsere benutzerdefinierte, erweiterte Integritätsprüfung für NTLM-authentifizierte Anwendungen zu erstellen, muss unter dem Pfad `/usr/local/relianoid/app/libexec` ein Skript zur Überprüfung des Backends erstellt werden, wie unten gezeigt. Zum Beispiel ` check_ntlm.sh` mit den entsprechenden Berechtigungen.
#!/bin/bash # Eingabeparameter abrufen 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 # wenn der curl-Befehl nicht fehlschlägt, dann benachrichtigen, dass das Backend aktiv ist echo "Server ${BACKEND}:${PORT} OK" exit 0 fi # wenn der curl-Befehl fehlschlägt, dann benachrichtigen, dass das Backend inaktiv ist echo "Server ${BACKEND}:${PORT} ist nicht OK" exit 1
Im Abschnitt Monitoring >> Farmguardian , falls zutreffend, oder durch Hinzufügen zum Befehl, um den Farmdienst zu überprüfen.
Wir können das Integritätsprüfskript testen, indem wir Folgendes ausführen:
/usr/local/relianoid/app/libexec/check_ntlm.sh 192.168.0.99 80 johndoe johnsecret "/my/uri" "DOCTYPE html"
Wir wissen, dass die Backend-IP 192.168.0.99 ist, der Port 80 (HTTP), johndoe ein Dummy-Benutzer in unserer Domäne ist, johnsecret das Dummy-Passwort ist, “/my/uri” die zu prüfende URI ist und “DOCTYPE html” die Zeichenkette ist, die in den Antwortdaten gesucht werden soll, wenn die Anfrage erfolgreich ist.
Wir empfehlen, einen Dummy-Benutzer anzulegen, der sich zwar in der Domäne anmelden kann, aber keine Berechtigungen besitzt, um ihn in die Integritätsprüfung unserer Dienste einzubeziehen. Aus diesem Grund verwenden wir den Dummy-Benutzer „johndoe“ in unserer benutzerdefinierten Integritätsprüfung.
Wenn unser Integritätscheck über die Befehlszeile getestet und bereit ist, können wir ihn den mit NTLM-Unterstützung konfigurierten Farmen zuweisen.
Viel Spaß mit Ihren lastausgeglichenen NTLM-Webanwendungen!
