Autoren-Archiv: weed

Der IIS braucht für Websockets (WS:// oder WSS://) ein bisschen Nachhilfe. Der IIS, oder auch die Internetinformationsdienste unterstützen WS/WSS nativ (und auch sehr performant), aber Secure-by-Default mit dem Setting „off“. Das gilt genauso auch für den ARR mit (pro-site) aktivem ReverseProxy.

Die Aktivierung ist aber im Wesentlichen in drei Schritten erledigt.

Lösung

1. Das Windows-Feature (IIS-Feature) Websockets via PowerShell installieren

PS C:\> Install-WindowsFeature -name Web-WebSockets

… oder das selbe im GUI (Server-Manager) erledigen. Features Hinzufügen > Webserver > Anwendungsentwicklung > WebSocket-Protokoll

2. Die Nutzung (Inhaltsänderung) der Servervariable HTTP_SEC_WEBSOCKET_EXTENSIONS Serverweit erlauben.

Serverweit: Internetinformationsdienste-Manager > links auf den Serverknoten > rechts „URL Rewrite“ öffnen

Dann die „Servervariablen anzeigen“ …

… und über den „Hinzufügen“ Link die Variable HTTP_SEC_WEBSOCKET_EXTENSIONS anlegen.

3. Die Nutzung für die Proxy-Site erlauben

Dazu die ARR-Site „Inbound“ Regel bearbeiten…

… unter „Servervariablen“ die HTTP_SEC_WEBSOCKET_EXTENSIONS Variable mit dem Wert „0“ und dem Haken „Vorhandenen Wert ersetzen“ hinzufügen.

⚠️ Das GUI lässt hier leider keine leeren Werte zu. Das kann manche Web-Apps (SAP, Sales-Apps, Visitenkartenscanner) verwirren.

Um das zu verhindern kann man in der zu der Site gehörigen web.config einfach die „0“ als Wert löschen und die config wieder speichern. Sobald der Wert dort leer ist, leitet der IIS auch Header ohne Inhalt unverändert weiter.

Update (Windows Server 2022)

Unter Windows Server 2022 sind uns einige Maschinen untergekommen, die aus „irgendeinem Grund“ die Websockets trotz dieser Konfiguration nicht eingeschaltet haben.

Wir konnten bisher noch nicht herausfinden, warum das sporadisch so ist, aber der Fix ist zum Glück einfach.

Im IIS-Konfigurationseditor der Site muss man unter system.webServer/webSocket den Wert enabled auf true setzen.

In vielen Szenarien möchte man auf dem localhost die HTTP-Authentifizierung verwenden. Das gilt für alle lokalen URLs, wie zum Beispiel

• http://localhost
• http://127.0.0.1
• http://SERVERNAME
• http://SERVENAME.FQDN.TEST

Lokale Webserver-Software auf einem Terminalserver, Test- und Dev- Systeme, Reverse-Proxys und ähnliches. Vor allem SharePoint mit seinen zahlreichen Scripts und automatismen benötigt gerne „logged on“ Zustand (auf dem SP-Server).

In der Standardkonfiguration erlaubt Windows Server seit 2008R2 das nicht mehr, alle Loopback-Authentifizierungen schlagen fehl und man sieht die Kennwort-Eingabeauffordeung wieder und wieder (und eine 403er Antwort im Log).

Lösung

Man muss die Loopback-Prüfung deaktivieren – oder zumindest anpassen. Diese verhindert by design Reflection-Attacken und ist grade bei teurer schlechter Software sinnvoll.

In Produktivumgebungen kann man einfach den vom Client verwendeten Hostnamen anpassen, zum Testen reicht es in der Regel die Prüfung komplett zu deaktivieren.

Prüfung deaktivieren

In die Registry eintragen, ist sofort (ohne Neustart) aktiv:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa]
"DisableLoopbackCheck"=dword:00000001

Erlaubte Hostnamen eintragen

In die Registry eintragen, ist erst nach einem Neustart aktiv. Das ist eine „mehrteilige Zeichenfolge“ (oder „Multi-String Value“) die beim Export in Hex-Werte umgewandelt werden. Das hier ist ein Beispiel mit „SERVERNAME“ und „LOCALHOST“ darin:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0]

"BackConnectionHostNames"=hex(7):53,00,45,00,52,00,56,00,45,00,52,00,4e,00,41,\
  00,4d,00,45,00,00,00,4c,00,4f,00,43,00,41,00,4c,00,48,00,4f,00,53,00,54,00,\
  00,00,00,00