{"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\/de\/blog\/windows-authentifizierung-loadbalancer-ssl","title":{"rendered":"So konfigurieren Sie die integrierte Windows-Authentifizierung von IIS f\u00fcr den Erfolg in einer Load Balancer + SSL-Umgebung"},"content":{"rendered":"<h2>Informationen zur integrierten Windows-Authentifizierung<\/h2>\n\n\n\n<p>Die integrierte Windows-Authentifizierung ist ein Mechanismus, der IIS automatisch Benutzerauthentifizierungsinformationen bereitstellt, wenn IIS und der Benutzer zur selben Active Directory-Dom\u00e4ne geh\u00f6ren. Wenn Sie eine Site mit ASP.NET C# erstellen, k\u00f6nnen Sie feststellen, ob ein Benutzer authentifiziert wurde, und Informationen zu authentifizierten Benutzern abrufen.<\/p>\n\n\n\n<p>Dies erm\u00f6glicht Benutzern den Zugriff auf von IIS gehostete (oder verkn\u00fcpfte) Webanwendungen ohne zus\u00e4tzliche Anmeldevorg\u00e4nge und erm\u00f6glicht die SSO-Integration mit anderen Anwendungsservern.<\/p>\n\n\n\n<p>In einer Umgebung, in der der Webserver (IIS) einem Lastenausgleich unterliegt und die Kommunikation mit SSL\/TLS verschl\u00fcsselt ist, funktioniert diese Windows-Authentifizierung jedoch m\u00f6glicherweise nicht ordnungsgem\u00e4\u00df.<span class=\"swl-marker mark_orange\">Warum ist das so?<\/span><\/p>\n\n\n\n<div class=\"wp-block-columns\">\n<div class=\"wp-block-column\">\n<p class=\"is-style-icon_pen has-small-font-size\">Wenn die Windows-Authentifizierung erfolgreich ist, k\u00f6nnen Sie problemlos auf die Authentifizierungssite zugreifen. Wenn sie jedoch fehlschl\u00e4gt, wird ein Anmeldedialogfeld angezeigt. Wenn Sie sich nicht korrekt authentifizieren, erhalten Sie den HTTP-Fehler 401.1 \u2013 Nicht autorisiert.<\/p>\n<\/div>\n\n\n\n<div class=\"wp-block-column\">\n<figure class=\"wp-block-image size-large is-resized\"><img src=\"https:\/\/chat-messenger.com\/wp-content\/uploads\/2025\/01\/image.png\" alt=\"\" width=\"459\" height=\"193\"\/><\/figure>\n<\/div>\n<\/div>\n\n\n\n<p>Der Punkt ist <strong>So funktioniert die Windows-Authentifizierung<\/strong> und <strong>Load Balancer-Betrieb<\/strong> befindet.<\/p>\n\n\n\n<p>NTLM ist eine Challenge\/Response-Authentifizierungsmethode \u00fcber eine einzelne TCP-Verbindung zwischen jedem Client und Server. Mit Kerberos erh\u00e4lt der Client ebenfalls ein Ticket basierend auf der Service-ID (SPN) und sendet es an IIS. Diese Anmeldeinformationen werden \u00fcber den HTTP-Header gesendet (<code>Autorisierung: Verhandeln ...<\/code> Die Transaktionen werden mithilfe solcher Methoden durchgef\u00fchrt. Ein Layer 7-Load Balancer beendet jedoch die HTTPS-Verbindung vom Client auf seinem eigenen Ger\u00e4t, analysiert den Inhalt und leitet ihn als neue Anfrage an den Backend-IIS weiter. W\u00e4hrend dieses Prozesses<span class=\"swl-marker mark_blue\">Die End-to-End-TLS-Sitzung zwischen dem Client und IIS wird beendet.<\/span>Dar\u00fcber hinaus werden persistente Authentifizierungsinformationen wie NTLM nicht \u00fcbertragen, was dazu f\u00fchrt, dass der Authentifizierungsprozess fehlschl\u00e4gt.<\/p>\n\n\n\n<p>Vor diesem Hintergrund <strong>&quot;<strong>Lastenausgleich<\/strong><\/strong> <strong>+ Konfigurieren der integrierten Windows-Authentifizierung von IIS f\u00fcr den Erfolg in einer SSL-Umgebung<\/strong> Wir werden Folgendes ber\u00fccksichtigen. Wir listen drei typische Konfigurationsmuster auf und erkl\u00e4ren jeweils, ob die Windows-Authentifizierung unterst\u00fctzt wird, welche technischen Gr\u00fcnde dies hat und welche Vor- und Nachteile die Konfiguration hat.<\/p>\n\n\n\n<h2>Technische \u00dcberpr\u00fcfung jedes Konfigurationsplans<\/h2>\n\n\n\n<h3>\u2460: L7-Load Balancer SSL-Terminierung + Weiterleitung an IIS (80 oder 443)<\/h3>\n\n\n\n<p class=\"is-style-bg_stripe\">Client \u2500\u2500HTTPS\u2500\u2500\u25b6 L7 Load Balancer (SSL-Terminierung) \u2500\u2500HTTP(S)\u2500\u2500\u25b6 IIS (80 oder 443)<\/p>\n\n\n\n<h4><strong>Verf\u00fcgbarkeit<\/strong><\/h4>\n\n\n\n<p>Die Windows-Authentifizierung wird in dieser Konfiguration nicht unterst\u00fctzt.<span class=\"swl-marker mark_orange\">Nicht verf\u00fcgbar<\/span>ist.<\/p>\n\n\n\n<h4><strong>Grund<\/strong><\/h4>\n\n\n\n<p>Da die TLS-Sitzung zwischen dem Client und IIS einmal auf dem Load Balancer beendet wird,<span class=\"swl-marker mark_blue\">Eine End-to-End-\u00dcbertragung von Anmeldeinformationen ist nicht m\u00f6glich<\/span>Deshalb. Der L7-Load Balancer entschl\u00fcsselt den empfangenen HTTPS-Verkehr und greift im Namen des Clients auf IIS zu. Zu diesem Zeitpunkt sollte der Kunde die <code>Autorisierung: Aushandeln<\/code> Header (Authentifizierungsheader einschlie\u00dflich Kerberos-Tickets und NTLM-Token) erreichen IIS nicht korrekt. Insbesondere bei NTLM ist die Authentifizierungs-Challenge-Antwort, die IIS auf die urspr\u00fcngliche Anfrage sendet (<code>WWW-Authentifizierung<\/code>) Der Client sendet eine erneute Anfrage, aber \u00fcber den LB<span class=\"swl-marker mark_blue\">Die gleiche TCP-Sitzung wird nicht aufrechterhalten<\/span>Daher ist der NTLM-Handshake nicht erfolgreich.<\/p>\n\n\n\n<p>Tats\u00e4chlich 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.<a rel=\"noreferrer noopener\" href=\"https:\/\/docs.aws.amazon.com\/ja_jp\/whitepapers\/latest\/replatform-dotnet-apps-with-windows-containers\/using-a-load-balancer-with-windows-authentication.html\" target=\"_blank\">Referenz<\/a>]. Au\u00dferdem unterst\u00fctzt Azure Application Gateway v2 nicht die \u00dcbergabe von HTTP-Headern einschlie\u00dflich integrierter Authentifizierung an das Back-End.<a rel=\"noreferrer noopener\" href=\"https:\/\/learn.microsoft.com\/ja-jp\/azure\/application-gateway\/application-gateway-faq#application-gateway-v1-sku-------------\" target=\"_blank\">Referenz<\/a>].<\/p>\n\n\n\n<p>Die Tatsache, dass es nicht von den verwalteten LBs der einzelnen Cloud-Anbieter offiziell unterst\u00fctzt wird, zeigt, wie schwierig es ist, die Windows-Authentifizierung auf L7-Ebene aufrechtzuerhalten.<\/p>\n\n\n\n<h3>2: L4-Load Balancer (TLS-Pass-Through) + IIS-Weiterleitung<\/h3>\n\n\n\n<p class=\"is-style-bg_stripe\">Client \u2500\u2500HTTPS\u2500\u2500\u25b6 L4 Load Balancer (TLS-Passthrough) \u2500\u2500HTTPS\u2500\u2500\u25b6 IIS (443)<\/p>\n\n\n\n<h4><strong>Verf\u00fcgbarkeit<\/strong><\/h4>\n\n\n\n<p>Diese Konfiguration verwendet die Windows-Authentifizierung.<span class=\"swl-marker mark_orange\">kompatibel<\/span>ist.<\/p>\n\n\n\n<h4><strong>Grund<\/strong><\/h4>\n\n\n\n<p>Da ein L4-Load Balancer (LB, der auf OSI-Schicht 4 arbeitet) Pakete auf TCP-Ebene weiterleitet,<span class=\"swl-marker mark_blue\">Die TLS-Sitzung zwischen Client und IIS wird durchg\u00e4ngig aufrechterhalten.<\/span>wird gemacht. Der Load Balancer beendet die Verschl\u00fcsselung nicht, sondern verteilt lediglich die TCP-Verbindung selbst an jeden Server, sodass die f\u00fcr die NTLM-Authentifizierung erforderliche \u201eKommunikation \u00fcber dieselbe TCP-Verbindung\u201c 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\u00fcrde. 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\u00f6ren zu dieser Kategorie (andere umfassen den HAProxy TCP-Modus und Nginx-Stream) und k\u00f6nnen die integrierte Windows-Authentifizierung durchlaufen.<\/p>\n\n\n\n<h4><strong>Verdienst<\/strong><\/h4>\n\n\n\n<p>Die TLS-Sitzung vom Client zum Server wird nicht unterbrochen.<span class=\"swl-marker mark_blue\">Windows-Authentifizierungsprotokolle funktionieren weiterhin wie vorgesehen<\/span>d\u00fcrfen. 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\u00dferdem um eine L4-Operation handelt, ist der Overhead gering und es ist zu erwarten, dass ein hoher Durchsatz erreicht wird.<\/p>\n\n\n\n<h4><strong>Fehler<\/strong><\/h4>\n\n\n\n<p>Die gr\u00f6\u00dfte Herausforderung bei der Konfiguration eines L4-Load Balancers besteht darin, dass kein detailliertes pfad- oder hostnamenbasiertes Routing m\u00f6glich ist. Beispielsweise in einem URL-Pfad (z.\u00a0B.<code>\/API<\/code>,,<code>\/chat<\/code>Die 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\u00f6glich ist.<\/p>\n\n\n\n<p>Daher kann es je nach Systemanforderungen erforderlich sein, mehrere FQDNs vorzubereiten und innerhalb des Load Balancers unterschiedliche virtuelle Server f\u00fcr unterschiedliche Zwecke (Webserver, Server f\u00fcr die Windows-Authentifizierung usw.) zuzuweisen, was den Nachteil hat, dass die Konfiguration schwieriger wird.<\/p>\n\n\n\n<p>Insbesondere beim Zugriff auf die Windows-Authentifizierungsseite \u00fcber einen FQDN (Fully Qualified Domain Name), <a href=\"https:\/\/chat-messenger.com\/de\/blog\/windows-authentifizierungs-setspn\/\">SPN-Registrierung<\/a> ist ziemlich kompliziert, also lesen Sie bitte weiter unten.<\/p>\n\n\n<div class=\"swell-block-postLink\">\t\t\t<div class=\"p-blogCard -external\" data-type=\"type3\" data-onclick=\"clickLink\">\n\t\t\t\t<div class=\"p-blogCard__inner\">\n\t\t\t\t\t<span class=\"p-blogCard__caption\">Chat&amp;Messenger f\u00fcr Webkonferenzen<\/span>\n\t\t\t\t\t<div class=\"p-blogCard__thumb c-postThumb\"><figure class=\"c-postThumb__figure\"><img src=\"https:\/\/chat-messenger.com\/wp-content\/uploads\/2025\/03\/iStock-1313570693-2.jpg\" alt=\"\" class=\"c-postThumb__img u-obf-cover\" width=\"320\" height=\"180\"><\/figure><\/div>\t\t\t\t\t<div class=\"p-blogCard__body\">\n\t\t\t\t\t\t<a class=\"p-blogCard__title\" href=\"https:\/\/chat-messenger.com\/de\/blog\/windows-authentifizierungs-setspn\/\" target=\"_blank\" rel=\"noopener noreferrer\">IIS-Einstellungen f\u00fcr eine erfolgreiche integrierte Windows-Authentifizierung in einer L4-Load Balancer-Umgebung | Webkonferenz-Chat&amp;Messenger<\/a>\n\t\t\t\t\t\t<span class=\"p-blogCard__excerpt\">\u00dcbersicht Der folgende Artikel erl\u00e4utert die Konfiguration der integrierten Windows-Authentifizierung (IWA) in IIS in einer L4-Load Balancer- und SSL-Terminierungsumgebung. Diese Methode\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<p>Beachten Sie au\u00dferdem, dass die folgenden f\u00fcr die Windows-Authentifizierung erforderlichen Einstellungen alle den FQDN des Load Balancers festlegen.<\/p>\n\n\n\n<ul><li>Auf der Registerkarte \u201eSicherheit\u201c der Internetoptionen ist eine Windows-Authentifizierung erforderlich.<a href=\"https:\/\/chat-messenger.com\/de\/handbuch\/camserver\/iis-sso\/#internet-options-settings\" data-type=\"URL\" data-id=\"https:\/\/chat-messenger.com\/manual\/camserver\/iis-sso#internet-options-settings\">\u201eLokales Intranet\u201c \u201eSites\u201c<\/a> Einstellung<\/li><li>IIS-Site-Bindungseinstellungen und SSL-Zertifikat (auf dem Load Balancer selbst muss kein Zertifikat installiert werden)<\/li><\/ul>\n\n\n\n<h4>Kerberos-Erfolgsfluss<\/h4>\n\n\n\n<p>Wenn der FQDN des Load Balancers lb.example.com ist, sieht der Ablauf f\u00fcr erfolgreiches Kerberos wie folgt aus:<\/p>\n\n\n\n<div class=\"hcb_wrap\" data-no-translation=\"\"><pre class=\"prism line-numbers lang-bash\" data-lang=\"Bash\"><code>[Client]\n  | 1. DNS\u89e3\u6c7a: lb.example.com \u2192 LB\n  |\n  | 2. Kerberos: SPN = HTTP\/lb.example.com\n  |             \u2192 \u30c9\u30e1\u30a4\u30f3\u30b3\u30f3\u30c8\u30ed\u30fc\u30e9\u30fc\u306bTGS\u3092\u8981\u6c42\n  |\n  | 3. TLS\u30cf\u30f3\u30c9\u30b7\u30a7\u30a4\u30af: SNI = lb.example.com\n  |             \u2192 IIS\u3067\u4e00\u81f4\u3059\u308b\u8a3c\u660e\u66f8\u5fc5\u8981\n  |\n  | 4. \u30ea\u30af\u30a8\u30b9\u30c8\u9001\u4fe1: Host\u30d8\u30c3\u30c0 = lb.example.com\n[IIS]\n  \u2192 SPN\u53d7\u3051\u5165\u308cOK\u3001\u8a3c\u660e\u66f8OK\u3001\u8a8d\u8a3c\u6210\u529f<\/code><\/pre><\/div>\n\n\n\n<h3>3: L7-Load Balancer-SSL-Terminierung + Umleitung zur IIS-Konfiguration<\/h3>\n\n\n\n<p class=\"is-style-bg_stripe\">Client \u2500\u2500HTTPS\u2500\u2500\u25b6 L7-Load Balancer (SSL-Terminierung)<br>LB \u2500\u2500HTTP 302 (Umleitungsantwort) \u2192 Client<br>Client \u2500\u2500HTTPS\u2500\u2500\u25b6 IIS (direkter Zugriff auf 443)<\/p>\n\n\n\n<h4><strong>Verf\u00fcgbarkeit<\/strong><\/h4>\n\n\n\n<p>Diese Konfiguration verwendet die Windows-Authentifizierung.<span class=\"swl-marker mark_orange\">kompatibel<\/span>ist.<\/p>\n\n\n\n<h4><strong>Grund<\/strong><\/h4>\n\n\n\n<p>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\u00fcck, um \u00fcber HTTPS eine Verbindung mit der entsprechenden IIS-Adresse (z. B. einzelner Hostname oder IP-Adresse f\u00fcr jeden IIS) herzustellen. Der Client-Browser empf\u00e4ngt diese Umleitung und sendet die Anforderung automatisch \u00fcber HTTPS direkt an den angegebenen IIS.<\/p>\n\n\n\n<p>Ergebnis,<span class=\"swl-marker mark_blue\">F\u00fcr die zweite Anfrage verbinden sich Client und IIS direkt \u00fcber TLS<\/span>Daher werden Kerberos\/NTLM-Authentifizierungsinformationen unver\u00e4ndert durchg\u00e4ngig weitergegeben. Da der Load Balancer w\u00e4hrend des Authentifizierungsprozesses nicht eingreift, kann er das Problem des Verlusts des Authentifizierungsheaders vermeiden, wie es in Konfiguration 1 zu sehen ist.<\/p>\n\n\n\n<h4><strong>Verdienst<\/strong><\/h4>\n\n\n\n<p><span class=\"swl-marker mark_blue\">Ein gro\u00dfer Vorteil besteht darin, dass TLS direkt vom Client mit IIS verbunden ist, sodass die Windows-Authentifizierung problemlos erfolgreich ist.<\/span>ist.<br>Wenn die Authentifizierung nur mit IIS erfolgreich ist, kann die Konfiguration so verwendet werden, wie sie ist. Der Aufwand erh\u00f6ht sich also nicht, auch wenn ein Load Balancer als Vermittler verwendet wird.<\/p>\n\n\n\n<p>Dar\u00fcber hinaus ist durch die Nutzung der Umleitung ein gewisses Ma\u00df an flexibler Routing-Steuerung auf der Load Balancer-Seite m\u00f6glich. Sie k\u00f6nnen beispielsweise eine pfadbasierte Verteilung erreichen, indem Sie je nach urspr\u00fcnglichem Zugriffs-URL-Pfad oder Hostnamen auf unterschiedliche Back-End-IIS-URLs umleiten. Wenn sich unter dem LB viele Dienste befinden, ist es m\u00f6glich, diese zun\u00e4chst als gemeinsamen Einstiegspunkt im LB zusammenzufassen und die Benutzer dann von dort zu den tats\u00e4chlichen URLs der einzelnen Dienste weiterzuleiten, sodass diese auf der Oberfl\u00e4che als ein einziger Dienst erscheinen.<\/p>\n\n\n\n<h4><strong>Fehler<\/strong><\/h4>\n\n\n\n<p>Der Nachteil besteht darin, dass IIS nicht hinter dem LB bereitgestellt werden kann und f\u00fcr IIS als \u00f6ffentlichen Server ein separater Endpunkt eingerichtet werden muss und f\u00fcr den LB ein anderes Zertifikat platziert werden muss.<\/p>\n\n\n\n<p>Ein weiterer Nachteil besteht darin, dass beim ersten Zugriff eine Umleitung erfolgt, in Wirklichkeit jedoch eine sofortige Neuverbindung \u00fcber eine HTTP 302-Antwort durchgef\u00fchrt wird, sodass die Auswirkungen auf das Benutzererlebnis nahezu vernachl\u00e4ssigbar sind.<\/p>\n\n\n\n<p class=\"is-style-big_icon_point\">Informationen zur Geschwindigkeit der Anmeldung bei unserem Dienst nach der Umleitung zu IIS und der Windows-Authentifizierung finden Sie hier.<a href=\"https:\/\/chat-messenger.com\/dl\/mp3\/cam-iissso-l7redirect.mp4\">Film<\/a>Bitte beziehen Sie sich auf.<\/p>\n\n\n\n<h2>Vergleichstabelle der einzelnen Konfigurationen<\/h2>\n\n\n\n<figure class=\"wp-block-table min_width10_\"><table style=\"--swl-cell1-width:70px;\"><thead style=\"--thead-color--bg:var(--color_gray);--thead-color--txt:var(--swl-text_color--black)\"><tr><th>Zusammensetzung<\/th><th>\u00dcberblick<\/th><th><span class=\"swl-fz u-fz-s\">Windows-Authentifizierung<\/span><\/th><th>Bemerkungen<\/th><\/tr><\/thead><tbody><tr><td>\u2460<\/td><td>L7 LB (SSL-Terminierung) \u2192 IIS<\/td><td>\u274c Nein<\/td><td>\u30fbTLS-Trennung, NTLM\/Kerberos-Nicht\u00fcbertragung<\/td><\/tr><tr><td>\u2461<\/td><td>L4 LB (TLS-Passthrough) \u2192 IIS<\/td><td>\u2705 Ja<\/td><td>\u30fbPfadbasiertes Routing ist nicht m\u00f6glich. Richten Sie virtuelle Server als LBs mit mehreren FQDNs f\u00fcr das Routing ein.<br>- Zertifikat auf der IIS-Seite einstellen (f\u00fcr LB ist kein Zertifikat erforderlich)<br>- IIS 443-Port erlaubt nur eingehende Verbindungen von LB<br>\u30fbInsgesamt gibt es wenig offizielle Dokumentation und es ist schwierig,<\/td><\/tr><tr><td>\u2462<\/td><td>L7 LB (SSL-Terminierung) \u2192 Weiterleitung zu IIS<\/td><td>\u2705 Ja<\/td><td>\u30fbPfadbasiertes Routing verf\u00fcgbar<br>\u30fbZertifikate sind auf der IIS-Seite und dem Load Balancer erforderlich<br>\u30fbIIS 443-Port erm\u00f6glicht eingehende Verbindungen mit JEDEM<br>\u30fbEinfach zu testen, da IIS alleine getestet werden kann<\/td><\/tr><\/tbody><\/table><figcaption>Vergleichstabelle der einzelnen Konfigurationen<\/figcaption><\/figure>\n\n\n\n<h2>Zusammenfassung<\/h2>\n\n\n\n<p>Damit die Windows-Authentifizierung (NTLM\/Kerberos) ordnungsgem\u00e4\u00df funktioniert, muss die TLS-Sitzung vom Client bis zum IIS unbedingt aufrechterhalten werden.<\/p>\n\n\n\n<p>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 schwieriger, da kein detailliertes pfadbasiertes Routing m\u00f6glich ist und mehrere virtuelle Server innerhalb des Load Balancers konfiguriert werden m\u00fcssen.<\/p>\n\n\n\n<p>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\u00f6nnen Sie sowohl die L7-Regelkontrolle als auch die Windows-Authentifizierung erreichen. Es muss \u00fcberpr\u00fcft werden, ob es Richtlinienprobleme mit IIS gibt, die nicht hinter einem LB stehen, der Port 443 als BELIEBIG zul\u00e4sst.<\/p>\n\n\n\n<p>Andererseits werden in einer Konfiguration wie Option 1, bei der der L7-Load Balancer die TLS-Terminierung oder HTTP-Interpretation durchf\u00fchrt, die Authentifizierungsinformationen unterbrochen und die Windows-Authentifizierung funktioniert nicht.<\/p>\n\n\n\n<p>Wir hoffen, dass dieser Artikel Ihnen bei der Auswahl einer Konfiguration hilft, die sowohl Lastenausgleich als auch verschl\u00fcsselte Kommunikation erm\u00f6glicht und gleichzeitig ein robustes Authentifizierungssystem aufrechterh\u00e4lt.<\/p>","protected":false},"excerpt":{"rendered":"<p>\u00dcber die integrierte Windows-Authentifizierung Integrierte Windows-Authentifizierung (Integrierte Windows-Authentifizierung [\u2026]<\/p>","protected":false},"author":1,"featured_media":11704,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"swell_btn_cv_data":""},"categories":[9,33],"tags":[],"_links":{"self":[{"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/posts\/11700"}],"collection":[{"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/comments?post=11700"}],"version-history":[{"count":9,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/posts\/11700\/revisions"}],"predecessor-version":[{"id":11920,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/posts\/11700\/revisions\/11920"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/media\/11704"}],"wp:attachment":[{"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/media?parent=11700"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/categories?post=11700"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/chat-messenger.com\/de\/wp-json\/wp\/v2\/tags?post=11700"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}