Informationen zur integrierten Windows-Authentifizierung
Die integrierte Windows-Authentifizierung ist ein Mechanismus, der IIS automatisch Benutzerauthentifizierungsinformationen bereitstellt, wenn IIS und der Benutzer zur selben Active Directory-Domäne gehören. Wenn Sie eine Site mit ASP.NET C# erstellen, können Sie feststellen, ob ein Benutzer authentifiziert wurde, und Informationen zu authentifizierten Benutzern abrufen.
Dies ermöglicht Benutzern den Zugriff auf von IIS gehostete (oder verknüpfte) Webanwendungen ohne zusätzliche Anmeldevorgänge und ermöglicht die SSO-Integration mit anderen Anwendungsservern.
In einer Umgebung, in der der Webserver (IIS) einem Lastenausgleich unterliegt und die Kommunikation mit SSL/TLS verschlüsselt ist, funktioniert diese Windows-Authentifizierung jedoch möglicherweise nicht ordnungsgemäß.Warum ist das so?
Der Punkt ist So funktioniert die Windows-Authentifizierung und Load Balancer-Betrieb befindet.
NTLM ist eine Challenge/Response-Authentifizierungsmethode über eine einzelne TCP-Verbindung zwischen jedem Client und Server. Mit Kerberos erhält der Client ebenfalls ein Ticket basierend auf der Service-ID (SPN) und sendet es an IIS. Diese Anmeldeinformationen werden über den HTTP-Header gesendet (Autorisierung: Verhandeln ... Die Transaktionen werden mithilfe solcher Methoden durchgeführt. Ein Layer 7-Load Balancer beendet jedoch die HTTPS-Verbindung vom Client auf seinem eigenen Gerät, analysiert den Inhalt und leitet ihn als neue Anfrage an den Backend-IIS weiter. Während dieses ProzessesDie End-to-End-TLS-Sitzung zwischen dem Client und IIS wird beendet.Darüber hinaus werden persistente Authentifizierungsinformationen wie NTLM nicht übertragen, was dazu führt, dass der Authentifizierungsprozess fehlschlägt.
Vor diesem Hintergrund "Lastenausgleich + Konfigurieren der integrierten Windows-Authentifizierung von IIS für den Erfolg in einer SSL-Umgebung Wir werden Folgendes berücksichtigen. Wir listen drei typische Konfigurationsmuster auf und erklären jeweils, ob die Windows-Authentifizierung unterstützt wird, welche technischen Gründe dies hat und welche Vor- und Nachteile die Konfiguration hat.
Technische Überprüfung jedes Konfigurationsplans
①: L7 Load Balancer SSL-Terminierung + IIS (80 oder 443)
Client ──HTTPS──▶ L7 Load Balancer (SSL-Terminierung) ──HTTP(S)──▶ IIS (80 oder 443)
Verfügbarkeit
Die Windows-Authentifizierung wird in dieser Konfiguration nicht unterstützt.Nicht verfügbarist.
Grund
Da die TLS-Sitzung zwischen dem Client und IIS einmal auf dem Load Balancer beendet wird,Eine End-to-End-Übertragung von Anmeldeinformationen ist nicht möglichDeshalb. Der L7-Load Balancer entschlüsselt den empfangenen HTTPS-Verkehr und greift im Namen des Clients auf IIS zu. Zu diesem Zeitpunkt sollte der Kunde die Autorisierung: Aushandeln Header (Authentifizierungsheader einschließlich Kerberos-Tickets und NTLM-Token) erreichen IIS nicht korrekt. Insbesondere bei NTLM ist die Authentifizierungs-Challenge-Antwort, die IIS auf die ursprüngliche Anfrage sendet (WWW-Authentifizierung) Der Client sendet eine erneute Anfrage, aber über den LBDie gleiche TCP-Sitzung wird nicht aufrechterhaltenDaher ist der NTLM-Handshake nicht erfolgreich.
Tatsächlich funktioniert die Windows-Authentifizierung sogar in einer AWS-Umgebung nicht mit Application Load Balancer (ALB) oder HTTP-Listenern, und es ist ein LB auf TCP-Ebene wie Network Load Balancer (NLB) erforderlich.Referenz]. Außerdem unterstützt Azure Application Gateway v2 nicht die Übergabe von HTTP-Headern einschließlich integrierter Authentifizierung an das Back-End.Referenz].
Die Tatsache, dass es nicht von den verwalteten LBs der einzelnen Cloud-Anbieter offiziell unterstützt wird, zeigt, wie schwierig es ist, die Windows-Authentifizierung auf L7-Ebene aufrechtzuerhalten.
②: L4-Lastenausgleich (TLS-Passthrough)
Client ──HTTPS──▶ L4 Load Balancer (TLS-Passthrough) ──HTTPS──▶ IIS (443)
Verfügbarkeit
Diese Konfiguration verwendet die Windows-Authentifizierung.kompatibelist.
Grund
Da ein L4-Load Balancer (LB, der auf OSI-Schicht 4 arbeitet) Pakete auf TCP-Ebene weiterleitet,Die TLS-Sitzung zwischen Client und IIS wird durchgängig aufrechterhalten.wird gemacht. Der Load Balancer beendet die Verschlüsselung nicht, sondern verteilt lediglich die TCP-Verbindung selbst an jeden Server, sodass die für die NTLM-Authentifizierung erforderliche „Kommunikation über dieselbe TCP-Verbindung“ aufrechterhalten wird. Was Kerberos betrifft, kann es aus Sicht des Clients so reproduziert werden, als ob der Client eine direkte Verbindung zum FQDN von IIS (Dienst) herstellen würde. Solange der SPN also entsprechend eingestellt ist, wird die ticketbasierte Authentifizierung wie bisher fortgesetzt. AWS NLB und klassischer LB TCP-Listener-Modus, Azure-interner Load Balancer, F5 L4-Modus usw. gehören zu dieser Kategorie (andere umfassen den HAProxy TCP-Modus und Nginx-Stream) und können die integrierte Windows-Authentifizierung durchlaufen.
Verdienst
Die TLS-Sitzung vom Client zum Server wird nicht unterbrochen.Windows-Authentifizierungsprotokolle funktionieren weiterhin wie vorgesehendürfen. Der NTLM-Drei-Wege-Handshake wird ebenfalls innerhalb einer einzigen Verbindung abgeschlossen und das Kerberos-Ticket wird vom Back-End-Server korrekt empfangen. Da es sich bei LB außerdem um eine L4-Operation handelt, ist der Overhead gering und es ist zu erwarten, dass ein hoher Durchsatz erreicht wird.
Fehler
Die größte Herausforderung bei der Konfiguration eines L4-Load Balancers besteht darin, dass kein detailliertes pfad- oder hostnamenbasiertes Routing möglich ist. Beispielsweise in einem URL-Pfad (z. B./API,,/chatDie Verteilung jeder Anfrage (oder mehrerer Anfragen) an einen anderen Backend-Server ist eine Funktion, die nur mit L7 (HTTP) erreicht werden kann und mit L4 (TCP) nicht möglich ist.
Daher kann es je nach Systemanforderungen erforderlich sein, mehrere FQDNs vorzubereiten und innerhalb des Load Balancers unterschiedliche virtuelle Server für unterschiedliche Zwecke (Webserver, Server für die Windows-Authentifizierung usw.) zuzuweisen, was den Nachteil hat, dass die Konfiguration schwieriger wird.
Beachten Sie außerdem, dass die folgenden für die Windows-Authentifizierung erforderlichen Einstellungen alle den FQDN des Load Balancers festlegen.
- Auf der Registerkarte „Sicherheit“ der Internetoptionen ist eine Windows-Authentifizierung erforderlich.„Lokales Intranet“ „Sites“ Einstellung
- Beim Zugriff auf die Windows-Authentifizierungsseite mit FQDN (Fully Qualified Domain Name) SPN-Registrierung
- SSL-Zertifikat in den IIS-Sitebindungseinstellungen
* Wenn der FQDN des Load Balancers lb.example.com ist, ist der Ablauf bis zum erfolgreichen Abschluss von Kerberos wie folgt:
[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、認証成功3: L7-Load Balancer SSL-Terminierung + Umleitungskonfiguration
Client ──HTTPS──▶ L7-Load Balancer (SSL-Terminierung)
LB ──HTTP 302 (Umleitungsantwort) → Client
Client ──HTTPS──▶ IIS (direkter Zugriff auf 443)
Verfügbarkeit
Diese Konfiguration verwendet die Windows-Authentifizierung.kompatibelist.
Grund
Die Idee besteht darin, dass der Load Balancer die eigentliche Kommunikation nicht weiterleitet, sondern den Client direkt zum Backend-IIS umleitet (HTTP 302-Antwort). Wenn ein Benutzer zum ersten Mal auf die LB-URL zugreift, beendet der L7-Load Balancer dort SSL, analysiert den Inhalt und gibt eine 302-Antwort mit einem Location-Header zurück, um über HTTPS eine Verbindung mit der entsprechenden IIS-Adresse (z. B. einzelner Hostname oder IP-Adresse für jeden IIS) herzustellen. Der Client-Browser empfängt diese Umleitung und sendet die Anforderung automatisch über HTTPS direkt an den angegebenen IIS.
Ergebnis,Für die zweite Anfrage verbinden sich Client und IIS direkt über TLSDaher werden Kerberos/NTLM-Authentifizierungsinformationen unverändert durchgängig weitergegeben. Da der Load Balancer während des Authentifizierungsprozesses nicht eingreift, kann er das Problem des Verlusts des Authentifizierungsheaders vermeiden, wie es in Konfiguration 1 zu sehen ist.
Verdienst
Ein großer Vorteil besteht darin, dass TLS direkt vom Client mit IIS verbunden ist, sodass die Windows-Authentifizierung problemlos erfolgreich ist.ist.
Wenn die Authentifizierung nur mit IIS erfolgreich ist, kann die Konfiguration so verwendet werden, wie sie ist. Der Aufwand erhöht sich also nicht, auch wenn ein Load Balancer als Vermittler verwendet wird.
Darüber hinaus ist durch die Nutzung der Umleitung ein gewisses Maß an flexibler Routing-Steuerung auf der Load Balancer-Seite möglich. Sie können beispielsweise eine pfadbasierte Verteilung erreichen, indem Sie je nach ursprünglichem Zugriffs-URL-Pfad oder Hostnamen auf unterschiedliche Back-End-IIS-URLs umleiten. Wenn sich unter dem LB viele Dienste befinden, ist es möglich, diese zunächst als gemeinsamen Einstiegspunkt im LB zusammenzufassen und die Benutzer dann von dort zu den tatsächlichen URLs der einzelnen Dienste weiterzuleiten, sodass diese auf der Oberfläche als ein einziger Dienst erscheinen.
Fehler
Der Nachteil besteht darin, dass IIS nicht hinter dem LB bereitgestellt werden kann und für IIS als öffentlichen Server ein separater Endpunkt eingerichtet werden muss und für den LB ein anderes Zertifikat platziert werden muss.
Ein weiterer Nachteil besteht darin, dass beim ersten Zugriff eine Umleitung erfolgt, in Wirklichkeit jedoch eine sofortige Neuverbindung über eine HTTP 302-Antwort durchgeführt wird, sodass die Auswirkungen auf das Benutzererlebnis nahezu vernachlässigbar sind.
Informationen zur Geschwindigkeit der Anmeldung bei unserem Dienst nach der Umleitung zu IIS und der Windows-Authentifizierung finden Sie hier.FilmBitte beziehen Sie sich auf.
Vergleichstabelle der einzelnen Konfigurationen
| Zusammensetzung | Überblick | Windows-Authentifizierung | Bemerkungen |
|---|---|---|---|
| ① | SSL-Terminierung bei L7 LB → IIS | ❌ Nein | ・TLS-Trennung, NTLM/Kerberos-Nichtübertragung |
| ② | TLS-Passthrough bei L4 LB | ✅ Ja | - Pfadbasiertes Routing ist nicht möglich, daher werden mehrere virtuelle Server in einem LB zusammengefasst ・Es gibt keine genaue offizielle Dokumentation, daher ist es schwierig ・Einrichten eines Zertifikats für den Load Balancer |
| ③ | Leiten Sie Authentifizierungsseiten direkt zu IIS um | ✅ Ja | - IIS kann nicht hinter LB eingesetzt werden - Ein separates Endpunktdesign für IIS und ein anderes Zertifikat vom LB sind erforderlich ・L7-Load Balancer ermöglicht pfadbasierte Zuweisung |
Zusammenfassung
Damit die Windows-Authentifizierung (NTLM/Kerberos) ordnungsgemäß funktioniert, muss die TLS-Sitzung vom Client bis zum IIS unbedingt aufrechterhalten werden.
In der L4-Load Balancer-Konfiguration von Option 2 wird TLS nicht weitergeleitet und erreicht IIS direkt, sodass die Authentifizierung erfolgreich ist. Die Konfiguration ist jedoch kompliziert, da sie kein detailliertes pfadbasiertes Routing zulässt und die Konfiguration mehrerer virtueller Server innerhalb des Load Balancers erfordert.
Andererseits wird die Umleitungskonfiguration in Option 3 nur beim ersten Mal vom L7-Lastenausgleich verarbeitet und stellt dann eine direkte Verbindung zu IIS her, was aus Sicht von TLS und Authentifizierung ein idealer Ablauf ist. Durch die Umleitung bestimmter Pfade zum IIS-FQDN können Sie sowohl die L7-Regelkontrolle als auch die Windows-Authentifizierung erreichen. Es muss überprüft werden, ob es irgendwelche Richtlinienprobleme hinsichtlich der Unfähigkeit gibt, IIS hinter LB bereitzustellen.
Andererseits werden in einer Konfiguration wie Option 1, bei der der L7-Load Balancer die TLS-Terminierung oder HTTP-Interpretation durchführt, die Authentifizierungsinformationen unterbrochen und die Windows-Authentifizierung funktioniert nicht.
Wir hoffen, dass dieser Artikel Ihnen bei der Auswahl einer Konfiguration hilft, die sowohl Lastenausgleich als auch verschlüsselte Kommunikation ermöglicht und gleichzeitig ein robustes Authentifizierungssystem aufrechterhält.