Terminalserver 2008 R2 RDWeb Aufruf ohne Zertifikatsabfrage möglich?
Hintergrund:
Ein Kunde von uns besitzt 8 Terminalserver (2008 R2) diese werden mit unterschiedlicher Software bestückt und zu Farmverbunden zusammen geschnürrt.
Als Beispiel:
- Farm01 bestehend aus Trmsrv01-04 -> Applikationen -> Office 2010 und allgemein verwendete Programme
- Farm02 bestehend aus Trmsrv 05+06 -> andere wichtige Programme
- Trmsrv 07 -> Ausnahme-Programme (Verwendung von einigen wenigen)
- Trmsrv 08 -> "
Bei Kunden sind alle Workstation leider nicht in der Domäne, was sich vorerst leider auch nicht ändern wird.
Hinsichtlich würde die Verteilung über das Webinterface gehen.
Als Beispiel:
- User geht auf die Seite http://farm01.domain.local/rdweb
- Login mit AD Benutzer
- App wird ausgewählt und gestartet
Folgende Probleme tun sich auf:
Man öffnet das Webinterface der Farm z.B. der Farm01 dieser entscheidet über DNS-Round-Robin wo er hinzeigt z.B. in unserem Fall auf den Trmsrv03.
Dieser hat sein eigenes Zertifikat in sich. (Bild 0)
Dort klickt man dann auf: "Laden dieser Website fortsetzen (nicht empfohlen)." (Bild 1)
Dann wird man ungwollt weitergeleitet von HTTP auf eine HTTPS-Site (Bild 2)
und meldet sich mit dem Domain-User an
Dort öffnet man eines der freigegebenen Apps (Bild 3)
Könnte man evtl. das "Remotedesktop" Anzeigefeld ausblenden?
Man erhält dann den Hinweis das der Herausgeber unbekannt ist. (Bild 4)
Die Ressourcen-Zuteilung scheint auch nicht angenommen zu werden sprich das die Mitarbeiter z.B. ihre Zwischenablage und lokale Drucker verwenden können.
Bzgl. des Hinweises kann man es über eine GPO so ändern, dass man Unbekannte Herausgeber erlaubt, diese Regel greift aber nicht, wenn der Client nicht selbst in der Domaine ist, wie es nun mal der Fall ist.
Dann wird man aufgefodert sich nochmals anzumelden (Bild 5)
Danach startet sich das App dann wie gewohnt.
Im idialsten Fall öffnet der Mitarbeiter die Website, logt sich ein, wählt sein Programm und kann mit arbeiten.
Das die Verteilung genauso gut über geschnürrte MSI-Pakete erfolgen kan ist uns auch bewusst.
Dennoch wäre die Verteilung relativ kompliziert ohne eine Domaine.
Gut besteht noch die Möglichkeit der Netzwerkfreigabe. Überall herum gehen und an mehr als 200 Clients ausführen.
Das eine Domäne in jeglicher Hinsicht von Vorteil wäre ist auch dem Kunden bekannt.
Er will es nur nicht umsetzen.
Hoffe ihr könnt helfen. Danke
Ein Kunde von uns besitzt 8 Terminalserver (2008 R2) diese werden mit unterschiedlicher Software bestückt und zu Farmverbunden zusammen geschnürrt.
Als Beispiel:
- Farm01 bestehend aus Trmsrv01-04 -> Applikationen -> Office 2010 und allgemein verwendete Programme
- Farm02 bestehend aus Trmsrv 05+06 -> andere wichtige Programme
- Trmsrv 07 -> Ausnahme-Programme (Verwendung von einigen wenigen)
- Trmsrv 08 -> "
Bei Kunden sind alle Workstation leider nicht in der Domäne, was sich vorerst leider auch nicht ändern wird.
Hinsichtlich würde die Verteilung über das Webinterface gehen.
Als Beispiel:
- User geht auf die Seite http://farm01.domain.local/rdweb
- Login mit AD Benutzer
- App wird ausgewählt und gestartet
Folgende Probleme tun sich auf:
Man öffnet das Webinterface der Farm z.B. der Farm01 dieser entscheidet über DNS-Round-Robin wo er hinzeigt z.B. in unserem Fall auf den Trmsrv03.
Dieser hat sein eigenes Zertifikat in sich. (Bild 0)
Dort klickt man dann auf: "Laden dieser Website fortsetzen (nicht empfohlen)." (Bild 1)
Dann wird man ungwollt weitergeleitet von HTTP auf eine HTTPS-Site (Bild 2)
und meldet sich mit dem Domain-User an
Dort öffnet man eines der freigegebenen Apps (Bild 3)
Könnte man evtl. das "Remotedesktop" Anzeigefeld ausblenden?
Man erhält dann den Hinweis das der Herausgeber unbekannt ist. (Bild 4)
Die Ressourcen-Zuteilung scheint auch nicht angenommen zu werden sprich das die Mitarbeiter z.B. ihre Zwischenablage und lokale Drucker verwenden können.
Bzgl. des Hinweises kann man es über eine GPO so ändern, dass man Unbekannte Herausgeber erlaubt, diese Regel greift aber nicht, wenn der Client nicht selbst in der Domaine ist, wie es nun mal der Fall ist.
Dann wird man aufgefodert sich nochmals anzumelden (Bild 5)
Danach startet sich das App dann wie gewohnt.
Im idialsten Fall öffnet der Mitarbeiter die Website, logt sich ein, wählt sein Programm und kann mit arbeiten.
Das die Verteilung genauso gut über geschnürrte MSI-Pakete erfolgen kan ist uns auch bewusst.
Dennoch wäre die Verteilung relativ kompliziert ohne eine Domaine.
Gut besteht noch die Möglichkeit der Netzwerkfreigabe. Überall herum gehen und an mehr als 200 Clients ausführen.
Das eine Domäne in jeglicher Hinsicht von Vorteil wäre ist auch dem Kunden bekannt.
Er will es nur nicht umsetzen.
Hoffe ihr könnt helfen. Danke
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 176687
Url: https://administrator.de/forum/terminalserver-2008-r2-rdweb-aufruf-ohne-zertifikatsabfrage-moeglich-176687.html
Ausgedruckt am: 13.05.2025 um 00:05 Uhr
3 Kommentare
Neuester Kommentar
Hallo,
du kannst mal schauen ob du auf dem TS bzw. Gatewayserver (wenn Ihr sowas habt) eine Zertifikat eingetragen ist, und dieses dann löschen. (Müsste irgendwo unter RemoteApp auswählbar sein. Wahlweise im IIS unter der Seite.
Falls das ned fruchtet müssen die Zertifikate in den Speicher der Clients (meine Meinung) ob Ihr das mit der Softwareverteilung macht (die gibts auch ohne AD beispielsweise OPSI von UIB. Ist sogar Freeware aber ein ziemliches Gefrickel).
Und trete deinem Kunden auf die Füße wegen der Domain... sowas ist ja grob fahrlässig. Wofür macht Microsoft sonst den Terz mit DCs, GPOs etc...
Grüße Lenny
du kannst mal schauen ob du auf dem TS bzw. Gatewayserver (wenn Ihr sowas habt) eine Zertifikat eingetragen ist, und dieses dann löschen. (Müsste irgendwo unter RemoteApp auswählbar sein. Wahlweise im IIS unter der Seite.
Falls das ned fruchtet müssen die Zertifikate in den Speicher der Clients (meine Meinung) ob Ihr das mit der Softwareverteilung macht (die gibts auch ohne AD beispielsweise OPSI von UIB. Ist sogar Freeware aber ein ziemliches Gefrickel).
Und trete deinem Kunden auf die Füße wegen der Domain... sowas ist ja grob fahrlässig. Wofür macht Microsoft sonst den Terz mit DCs, GPOs etc...
Grüße Lenny
Hi Lenny,
also gemacht getan
Serverseitig:
Unter jedem Terminalserver unterm Server Manager -> Remotedesktopdienste -> RemoteApp-Manager -> Einstellungen dür digitale Signatur
auf Ändern gegangen und den Harken bei "Mit Digitalem Zertifikate anmelden" raus genommen.
Unter dem Webserver (IIS) -> Internetinformationsdineste (IIS) Manager unter Sites -> Default Web Site -> RDWeb -> SSL-Einstellungen
kein Harken bei "SSL erforderlich" und Clientzertifikate "Ignorieren"
Neue MMC erstellen -> Snap-In hinzufügen -> Zertifikate -> Computerkonto -> Lokalen Computer
Unter Zertifikate -> Eigene Zertifikate -> "Terminalserver Zertifikat" kopieren und in den Ordner
"Vertrauenswürdige Stammzertifizierungsstellen" im Unterordner "Zertifikate" einfügen
= Dieses Zertifikat ist gültig
Soweit so gut ...
Clientseitig:
Per Webinterface z.B. http://trmsrv01.domaine.local/RDWeb aufgerufen
Siehe gleiche Meldung wie Screens oben
Dann auf den Zertifikatsfehler im IE -> "Zertifikate anzeigen" -> Register "Allgemein" -> Zertifikat installieren ... -> weiter -> Alle Zertifikate in folgenden Speicher speichern -> Durchsuchen -> Vertrauenswürdige Stammzertifizierungsstellen -> OK -> weiter -> Fertigstellen
MMC erstellen nochmals überprüfen -> Zertifikate -> Vertrauenswürdige Stammzertifizierungsstellen ob sie auch dort vorhanden sind.
Browser neustarten Webinterface aufrufen -> sie da Zertifikat i.O.
Weiterleitung von HTTP auf HTTPS ohne Probleme wenn man den Server direkt anspricht.
Wenn man aber die Farm anspricht bekommt man immer noch die selbe Meldung gut da müsste man ein neues Zertifikat erstellen welches dann auf farm01.domain.local zugelassen ist. Muss ich dieses dann auf dem Server oder auf dem Client importieren?
Dann schaut es jetzt so aus:
User geht auf die Website -> meldet sich an -> öffnet App -> Bild 4 (siehe oben) dann Bild 5 und das App öffnet sich.
Wie bezwingen wir den Rest?
Gruß
Confix
also gemacht getan
Serverseitig:
Unter jedem Terminalserver unterm Server Manager -> Remotedesktopdienste -> RemoteApp-Manager -> Einstellungen dür digitale Signatur
auf Ändern gegangen und den Harken bei "Mit Digitalem Zertifikate anmelden" raus genommen.
Unter dem Webserver (IIS) -> Internetinformationsdineste (IIS) Manager unter Sites -> Default Web Site -> RDWeb -> SSL-Einstellungen
kein Harken bei "SSL erforderlich" und Clientzertifikate "Ignorieren"
Neue MMC erstellen -> Snap-In hinzufügen -> Zertifikate -> Computerkonto -> Lokalen Computer
Unter Zertifikate -> Eigene Zertifikate -> "Terminalserver Zertifikat" kopieren und in den Ordner
"Vertrauenswürdige Stammzertifizierungsstellen" im Unterordner "Zertifikate" einfügen
= Dieses Zertifikat ist gültig
Soweit so gut ...
Clientseitig:
Per Webinterface z.B. http://trmsrv01.domaine.local/RDWeb aufgerufen
Siehe gleiche Meldung wie Screens oben
Dann auf den Zertifikatsfehler im IE -> "Zertifikate anzeigen" -> Register "Allgemein" -> Zertifikat installieren ... -> weiter -> Alle Zertifikate in folgenden Speicher speichern -> Durchsuchen -> Vertrauenswürdige Stammzertifizierungsstellen -> OK -> weiter -> Fertigstellen
MMC erstellen nochmals überprüfen -> Zertifikate -> Vertrauenswürdige Stammzertifizierungsstellen ob sie auch dort vorhanden sind.
Browser neustarten Webinterface aufrufen -> sie da Zertifikat i.O.
Weiterleitung von HTTP auf HTTPS ohne Probleme wenn man den Server direkt anspricht.
Wenn man aber die Farm anspricht bekommt man immer noch die selbe Meldung gut da müsste man ein neues Zertifikat erstellen welches dann auf farm01.domain.local zugelassen ist. Muss ich dieses dann auf dem Server oder auf dem Client importieren?
Dann schaut es jetzt so aus:
User geht auf die Website -> meldet sich an -> öffnet App -> Bild 4 (siehe oben) dann Bild 5 und das App öffnet sich.
Wie bezwingen wir den Rest?
Gruß
Confix
hallo ich glaube das cert muss man auf dem client installieren.
grüße
grüße
