Archiv der Kategorie: Microsoft

Der „Open SSTP Client“ von KOBAYASHI Ittoku ist schon länger ein gerne gewählter Client zur Verbindung Microsoft SSTP (MS-SSTP) Protokoll.

Seit Windows Server 2016 (auch 2019 und 2022) gibt es einen Verbindungsfehler („receiveChapFailure„) wenn man sich einwählen möchte.

Die Fehlermeldung im Ereignisprotokoll lautet:

Der Benutzer DOMAIN\USERNAME, der eine Verbindung mit <IPAADRESS> hergestellt hat, konnte sich aus folgendem Grund nicht authentifizieren: Die Remoteverbindung wurde verweigert, weil die angegebene Kombination aus Benutzername und Kennwort nicht erkannt wird oder das ausgewählte Authentifizierungsprotokoll nicht für den RAS-Server zulässig ist.

Lösung

Die Verwendung von „@“ (UPN) anstelle der alten Syntax „\“ (NT-Logon) ist erforderlich, um den Fehler beim Herstellen einer Verbindung zu vermeiden.

Sobald man die Verbindung auf „[email protected]“ umstellt, ist die Einwahl sofort wieder da.

Thx Dariusz!

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

Der IIS mit ARR verhindert „by Default“ den Zugriff auf Adressen (URLs), die reservierte Zeichen enthalten. Genauer gesagt werden Anfragen mit solchen Zeichen von der IIS-Anfragefilterung blockiert und mit einen Fehler 404 beantwortet.

Die IIS-Anforderungsfilterung prüft standardmäßig auf viele verschiedene Dinge. Das Verhalten wird aber durch die Konfiguration gesteuert und kann (muss) pro Site angepasst werden.

Dazu gehören:

• Doppelte Escapezeichen (..%25)
• Prozent-Zeichen „%“-Zeichen
• Plus „+“-Zeichen (Leerzeichen, also auch „%2b“)
• Nicht-ASCII-High-Bit-Zeichen (ja, auch Emojies)
• Punkt im URI-Pfad, wenn eine Anfrage, die einen anderen Punkt als den für die Ressourcenerweiterung enthält, abgelehnt wird (http://foo/a.b/bar.aspx)

Lösung

In der betreffenden web.config die Ausnahme für Double-Escaping hinzufügen:

<system.webServer>

  <security>
    <requestFiltering allowDoubleEscaping="true">
    </requestFiltering>
  </security>

[...]

Die Windows Remotehilfe (STRG+Win+Q) ist ein ausgezeichnetes, oft unterschätztes und seit Windows 10 allgegenwärtiges Werkzeug. Der Admin kann damit beliebigen Windows (Clients) direkt Hilfe anbieten, ohne Tools wie Teamviewer oder Anydesk herunterladen zu müssen.

Das einzige Problem ist die Rechteausweitung. Die Windows Remotehilfe kann nicht selbstständig „Erweiterte Rechte“ erlangen, man kann also nicht mal eben Dinge „Als Administrator“ starten. Wenn man das versucht, sieht man auf der Helfer-Seite ein „Pause“ Symbol und auf dem Client den „Secure Desktop“ der die Eingabeaufforderung für Admin-Credentials

Selbst wenn man dann bestimmte Anwendungen als Administrator gestartet hat, zum Beispiel via runas oder minirunas, sind Eingaben in diese Fenster für den Helfenden nicht möglich. Der „Sichere Desktop“ verhindert das ein nicht-admin die Administrator-Fenster bedienen kann. Grundsätzlich sicher eine sichere Idee, aber auch etwas unprkatisch.

Lösung

Um es Admins zu ermöglichen, die Anmeldedaten auch in einer Remotehilfesitzung einzugeben, müssen zwei Dinge geschehen. Erstens muss die UAC-Eingabeauffoderung ohne „Sicheren Desktop“ angezeigt werden und zweitens muss die ganze Benutzersitzung zum „Sicheren Desktop“ wechseln dürfen.

Das geht am einfachsten per Gruppenrichtlinie.

Computerkonfiguration > Richtlinien > Lokale Richtlinien > Sicherheitsoptionen > Benutzerkontensteuerung >
„Benutzerkontensteuerung: Bei Benutzeraufforderung nach erhöhten Rechten zum sicheren Desktop wechseln“: Deaktiviert

(Gleicher Pfad)
„Benutzerkontensteuerung: Erhöhte Rechte nur für UIAccess-Anwendungen, die an sicheren Orten installiert sind“: Aktiviert

(Gleicher Pfad)
„Benutzerkontensteuerung: UIAccess-Anwendungen können erhöhte Rechte ohne sicheren Desktop anfordern“: Aktiviert

Nach dem nächsten gpupdate können Admins auch in der Windows Remotehilfe wieder Anmeldedaten „für „Als Administrator“ eingeben.