RDS - HTML WebClient

[Gerber 15]

Hi zusammen,

 

ich bin gerade am testen mit einem RDS 2016 Server und würde dort gerne den WebClient HTML testen.

Der WebClient wurde installiert. RD - Gateway, RD Verbindungsbroker und WebAccess wurden alle mit dem gleichen selbst signierten Zertifikat ausgestattet (da es sich nur um einen Test handelt).

 

DNS Zone "remote.domain.de" zeigt auf den RDS Server.

 

Per "https://remote.domain.de/RDWeb/webclient/index.html" komme ich sauber auf den Web Client vom RDS Server, kann mich anmelden und sehe die Work Ressources.

Wenn ich nun die Sammlung im HTML (Browser) öffnen will, bekomme ich keine Verbindung zum Server hergestellt.

Fehler: siehe Anhang.

 

Wenn ich die Ressource aus dem Portal herunterlade, kann ich die RDP Datei ohne Probleme starten und mich verbinden.

---------------------------------

 

Hat jemand eine Idee?

 

Grüße

Phil

bearbeitet 20. November 2020 von Gerber
Anhang

[mwiederkehr 373]

Kommst Du vom Server selbst auf "remote.domain.de"? Wenn das extern auflöst, könnte es ein Problem mit NAT-Loopback geben.

[Gerber 15]

Von Extern will ich zunächst gar nicht darauf zugreifen.
Erstmal soll alles von Intern laufen.

Ich kann mich ja über die oben genannte URL anmelden. Wie gesagt Zone ist angelegt und zeigt auf den RDS Server.

"Auch wenn ich über mstsc mich mit dem Server "remote.domain.de"  verbinde, bekomme ich die Verbindung zum RDS Server hergestellt. Nur eben nicht über den Web Client.

bearbeitet 20. November 2020 von Gerber

[mwiederkehr 373]

Beim Webclient ist eben speziell, dass der Server bzw. die RDP-to-HTML-Komponente auf sich selbst zugreift.

 

Über RDWeb funktioniert es auch? Vertraut der Server selbst dem Zertifikat?

[Gerber 15]

Gerade eben schrieb mwiederkehr:

Beim Webclient ist eben speziell, dass der Server bzw. die RDP-to-HTML-Komponente auf sich selbst zugreift.

Okay. Wie gesagt er zeigt auf sich selbst und ich komme ja bis zur Verbindung.
 

Gerade eben schrieb mwiederkehr:

Über RDWeb funktioniert es auch? Vertraut der Server selbst dem Zertifikat?

Über RD Web sehe ich ebenfalls die Farm und kann mich dann direkt verbinden. Allerdings verbindet sich er dort eben per MSTSC und nicht per HTML über den WebClient.

Das Zertifikat ist installiert, genau.

Funktioniert dies mit einem selbstsignierten Zertifikat oder muss zwingend ein offizielles her?

 

[mwiederkehr 373]

vor 20 Minuten schrieb Gerber:

Funktioniert dies mit einem selbstsignierten Zertifikat oder muss zwingend ein offizielles her?

Es sollte eigentlich schon funktionieren, aber ich muss zugeben, dass ich es noch nie probiert habe. Habe den Webclient erst an einem Ort im Einsatz und dort läuft er mit öffentlichem Wildcard-Zertifikat. Dort hat die Installation problemlos funktioniert. (Ist allerdings Server 2019, nicht 2016, aber das sollte keinen Unterschied machen.)

[Gerber 15]

Mhh. Ich habe zum Test das Gateway und den Broker auf einer VM laufen, was aber eigentlich auch nichts machen sollte oder?

 

Ich habe gerade nochmals die Zertifikatsbindung geprüft:

Befehl "netsh http show sslcert" gibt aus, das ein Zertifikat auf 443 gebunden ist.
Im WWW ist oft zu finden, dass ein Zertifikat an 3392 gebunden sein muss ?

 

Wenn ich über den WebClient den Verbindungsversuch mitlogge, bekomme ich irgendwann einen "WebSocketTransport(ERR): WebSocket error received for url=wss:".
 

bearbeitet 20. November 2020 von Gerber

[mwiederkehr 373]

Wenn Du im Browser die Developer Tools aufmachst, wie sieht der Fehler denn genau aus? wss ist WebSockets, irgendwo dort hat er ein Problem. Auf welchen Port versucht er zu verbinden? Ist der vom Client erreichbar?

[testperson 1.677]

Hi,

 

der WebClient steht auch noch auf meiner To-Test-Liste. ;) Ansonsten findet sich hier mehrfach (https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin):

Zitat

Make sure public trusted certificates are configured for the RD Gateway and RD Web Access roles.

Etwas weiter unten findet sich (für Server 2019) noch (https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin#setting-up-the-rd-session-host):

Zitat

netsh http add sslcert ipport=0.0.0.0:3392 certhash="<thumbprint>" appid="{00000000-0000-0000-0000-000000000000}"

...

Note

If both the RD Session Host and the RD Broker server share the same machine, set the RD Broker server certificate only. If the RD Session Host and RD Broker server use different machines, both must be configured with unique certificates.

 

"Notfalls" bekommst du bei der PSW Group ein SAN Zertifikat ab 19€ / Jahr. Alternativ halt die Testumgebung direkt für "Let's Encrypt" und Win-Acme mit benutztn: https://www.win-acme.com/

 

Gruß

Jan

[Gerber 15]

vor 10 Minuten schrieb mwiederkehr:

Wenn Du im Browser die Developer Tools aufmachst, wie sieht der Fehler denn genau aus? wss ist WebSockets, irgendwo dort hat er ein Problem. Auf welchen Port versucht er zu verbinden?

 

Hier nochmals der Fehler.

vor 9 Minuten schrieb testperson:

der WebClient steht auch noch auf meiner To-Test-Liste. ;) Ansonsten findet sich hier mehrfach (https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin):

. Die Liste habe ich schon mehrfach durch gearbeitet.

 

Achso und ja, dass Zertifikat ist an alle Dienste gebunden.

 

vor 9 Minuten schrieb testperson:

Etwas weiter unten findet sich (für Server 2019) noch (https://docs.microsoft.com/en-us/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin#setting-up-the-rd-session-host):

Genau daran habe ich mich auch schon aufgehängt. Die MSTSC Verbindung geht natürlich auf diesen Port, weswegen es auch funktioniert.
Allerdings habe ich ein 2016er im Einsatz und ich meine die von dir verlinkte Variante ist nur dafür da, wenn der WebClient ohne RDS Gateway eingesetzt wird, was ab Server 2019 möglich ist.

Auch wenn alle Rollen auf dem gleichen Server sind muss z.B. kein Zertifikat an den Port "3392" gebunden werden.
Hatte ich irgendwo gelesen, finde ich gerade nicht mehr.
 

 

vor 9 Minuten schrieb testperson:

"Notfalls" bekommst du bei der PSW Group ein SAN Zertifikat ab 19€ / Jahr. Alternativ halt die Testumgebung direkt für "Let's Encrypt" und Win-Acme mit benutztn: https://www.win-acme.com/

Ich denke ich werde gleich mal eines mit LetsEncrypt beantragen. Nacher liegt es wirklich nru am Public Zertifikat 
 

bearbeitet 20. November 2020 von Gerber

[Gerber 15]

so Feedback:

Ich habe nun ein Zertifikat bei PSW Group für 30 Tage Test beantragt. Zunächst zur der Rolle Web Access und Gateway zugewiesen -> kein Erfolg.

Die komplette Konfiguration nochmal auf die Standardwerte zurückgesetzt:

Zitat

Reset-RDWebClientDeploymentSetting -Name "LaunchResourceInBrowser"

Reset-RDWebClientDeploymentSetting -Name "SuppressTelemetry"

Danach nochmal die Config durchgegangen:

Zitat

https://docs.microsoft.com/de-de/windows-server/remote/remote-desktop-services/clients/remote-desktop-web-client-admin#setting-up-the-rd-session-host

Kein Erfolg.
Nächster Schritt obwohl eigentlich nciht benötigt, dass Zertifikat an den Port : 3392 gebunden

 

 

Kein Erfolg.

Dann nochmals das Zertifikat allen Rollen zugewiesen -> kein Erfolg.

 

So langsam bin ich ratlos was ich noch versuchen kann um ehrlich zu sein 

Eventuell hat ja jemand noch irgend eine Idee parat.

 

Grüße

Phil

[Gerber 15]

Vllt kann hiermit noch jemand was anfangen:

Im Log ist folgender Fehler zu sehen:

 

Zitat

2020-11-21T08:48:39.954Z WebSocketTransport(NORM): WebSocket closed, url=wss://remote.domain.de:443/remoteDesktopGateway?CorId=%7B7b645ade-37a2-468d-966a-33ad7e870000%7D&ConId=%7B845c953f-009f-4471-b15c-97d850bc2d94%7D&ClGen=HTML%3D1&ClBld=Type%3DRdClient%3B%20Build%3Dprivate&AuthS=SSPI_NTLM, wasClean=false, code=1006, reason=""
2020-11-21T08:48:40.268Z Connection(ERR): The connection generated an internal exception with disconnect code=ConnectionBroken(8), extended code=<null>, reason=WebSocket closed with code: 1006 reason: 
 Thrown in thread 399652 at:
    websockettransport.cpp(335)
Call Stack:
        at imb
        at fmb
        at Tp
        at Djd 

    connection.cpp(1335): OnException()

 

[testperson 1.677]

Hast du mal ein oder zwei andere Browser getestet?

Du bist im gleichen Netz ohne Firewall / Proxy / Loadbalancer dazwischen?

Windows Firewall testweise mal ausgeschaltet?

 

Ich erinnere mich dunkel an irgendein Problem mit einer Webanwendung auf Server 2016, da "lag" es an http/2. Bevor du es serverseitig oder im Client Browser deaktivierst ggfs. erst einmal IIS Crypto mit Best Practice über die beteiligten Systeme jagen.

[mwiederkehr 373]

Ergänzend zu Jan: Mal mit einem anderen Browser getestet? Error 1006 wäre nämlich eigentlich ein clientseitiger Verbindungsabbruch.

[Gerber 15]

Am 21.11.2020 um 11:27 schrieb testperson:

Hast du mal ein oder zwei andere Browser getestet?

Werde ich später mal noch machen. 

Bin mir gerade durch die ganze testerei nicht mehr sicher mit welchen Browsern ich es getestet habe ?. 

 

Ich glaube allerdings mit ie und Chrome. 

 

Am 21.11.2020 um 11:27 schrieb testperson:

Du bist im gleichen Netz ohne Firewall / Proxy / Loadbalancer dazwischen?

Windows Firewall testweise mal ausgeschaltet?

Ja es handelt sich um zwei test Vms im gleichen Netz. Dc und eben der Test Rds Server auf dem lle Rollen installiert sind. 

 

Es hängt nichts dazwischen. Es funktioniert auch nicht lokl auf dem Rds Server direkt. 

 

Firewall wurde ebenfalls bereits deaktiviert. 

 

vor 23 Stunden schrieb mwiederkehr:

Ergänzend zu Jan: Mal mit einem anderen Browser getestet? Error 1006 wäre nämlich eigentlich ein clientseitiger Verbindungsabbruch.

Ok. Wie gesagt ich teste es nochmals. Bin mir allerdings fast sicher, dass ich es mit verschiedenen getestet habe. 

 

Grüße 

Phil