RDS Farm Windows Server 2019 SHA256

[WSUSPraxis 48]

Hallo und Guten Abend,

 

folgender Aufbau:

 

2 x Windows Server 2019 Session Host(s)

 

1 x Windows Server 2019 Session Brocker

 

Session Hosts / Collection / Session Brocker und Lizenzserver sind konfiguriert - Bis hier funktioniert alles Einwandfrei

 

Interne DNS Domain:     testdomain.de

 

Offizielles Wildcard Zertifikat:  *.testdomain.de            SHA256

 

Und hier beginnt mein Problem:

 

Die Zertifikatszuweisung unter Edit Deploymend wurde gemacht und das Wildcard Zertifikat zugewiesen.

 

Wenn ich nun das Zertifikat auf denn Session Host zuweisen möchte, dann finde ich hierzu keine Möglichkeit für ein SHA256 Zertifikat.

 

Bei SHA 1 habe ich das immer so gemacht:

 

$TSpath = (Get-WmiObject -Class "Win32_TSGeneralSetting" -Namespace root\cimv2\terminalservices -Filter "TerminalName='RDP-tcp'").__path
Set-WmiInstance -Path $TSpath -Argument @{SSLCertificateSHA1Hash="Thumprint"}

 

Leider funktioniert das mit SHA 256 Zertifikaten nicht ? Wie kann ich das Offizielle Wildcard Zertifikat den Session Hosts als RDP Zertifikat zuweisen ?

 

Viele Grüße und Viele Dank

 

Arnd

 

 

[WSUSPraxis 48]

Hallo und Guten Morgen,

 

ich habe die Nacht geforscht und alles probiert ! Doch leider habe ich nichts dazu gefunden.

 

Viele Grüße Arnd

[djmaker 95]

Hallo Arnd,

 

diesen Weg hast Du auch geprüft?

 

https://www.tbs-certificates.co.uk/FAQ/en/rdp-windows.html

[WSUSPraxis 48]

Hallo und Mahlzeit,

 

Danke Dir ! Ja so habe ich es konfiguriert. Aber so wird nach meiner Ansicht nicht den Session Host das RDS Listener Zertifikat zugewiesen ?

 

Viele Grüße Arnd

[djmaker 95]

Hallo Arnd,

 

sorry - war nur ein Schuss in die Wildnis. Ich habe aktuell kein System zum testen.

[WSUSPraxis 48]

Hallo Thomas,

 

danke Dir trotzdem ! Leider komme ich garnicht weiter..

 

Viele Grüße Arnd

[cj_berlin 1.342]

Moin,

 

erstens, auch ein SHA-256-Zertifikat hat auch ein SHA-1-Thumbprint.

zweitens, das Farm-Zertifikat wird nur dem Broker über das Deployment zugewiesen (hast Du ja schon gemacht). Es ist schließlich nicht vorgesehen, dass man direkt auf einen RDSH aus einer Farm zugreift. Und wenn, dann ist man Admin und weiß mit der etwaigen Warnung umzugehen.

 

Was genau funktioniert denn nicht? Wenn Du Pop-Ups kriegst, kann es einen anderen Grund haben, je nachdem, welche Pop-Ups das sind...

[WSUSPraxis 48]

Hallo und Guten Morgen,

 

danke für deine Nachricht.

 

Ich würde den Aufbau / Vorgehen nochmals genauer Beschreiben.

 

=>  Wildcard Zertifikat wurde im Deploymend allen Rollen gleich zugewiesen und ist als Trusted gekennzeichnet

 

=> RDS Zugriff erfolgt üb er Collection Name   webwork.testdomain.de

 

          => Eingabe Benutzername und Kennwort  

          => Keine Zertifikatswarung

          => OK

 

=> Verbindung wird Hergestellt

 

 

 

Dann erscheint die Zertifikatsmeldung. Hier dann jeweils das Zertifikat des jeweiligen Session Host.

 

Viele Grüße Arnd

 

[tesso 375]

Schau dir das Zertifikat und die Kette genauer an. Nach der Fehlermeldung könnte ein Stammzertifikat fehlen.

[cj_berlin 1.342]

vor einer Stunde schrieb WSUSPraxis:

Dann erscheint die Zertifikatsmeldung. Hier dann jeweils das Zertifikat des jeweiligen Session Host.

 

Dann ist irgendwas mit Deinem Deployment nicht so wie es sein soll. Normalerweise spielen die individuellen Zertifikate der Hosts keine Rolle. Hast Du evtl. eine GPO für die Infrastruktur-Server, die zufällig auch auf Deine Farm wirkt und wo die Zertifikatsvorlage für RDP-Zertifikate festgelegt wird? 

Kannst Du die Session Hosts einmal aus dem Deployment entfernen und wieder hinzufügen? Oder einfach schnell eine VM in eine neue Session Collection stecken und schauen, ob das Problem immer noch auftritt?

[WSUSPraxis 48]

vor einer Stunde schrieb tesso:

Schau dir das Zertifikat und die Kette genauer an. Nach der Fehlermeldung könnte ein Stammzertifikat fehlen.

Hallo und Guten Morgen,

 

das es ein Zertifikat von einer Offiziellen PKI ist und die Kette installiert wurde - Nein - 

 

Die Meldung kommt vom Internen Self Sign Zertifikat, welches nicht verwendet werden sollte.

 

Viele Grüße Arnd

vor einer Stunde schrieb cj_berlin:

Dann ist irgendwas mit Deinem Deployment nicht so wie es sein soll. Normalerweise spielen die individuellen Zertifikate der Hosts keine Rolle. Hast Du evtl. eine GPO für die Infrastruktur-Server, die zufällig auch auf Deine Farm wirkt und wo die Zertifikatsvorlage für RDP-Zertifikate festgelegt wird? 

Kannst Du die Session Hosts einmal aus dem Deployment entfernen und wieder hinzufügen? Oder einfach schnell eine VM in eine neue Session Collection stecken und schauen, ob das Problem immer noch auftritt?

Hallo und Guten Morgen,

 

Habe ich gerade nochmals gemacht. Session Host aus Collection genommen. Vererbung von GPO´s abgeschalten für die OU. Session Host wieder rein genommen.

 

Leider das gleiche Problem. Es wird immer das Self Sign Zertifikat des Session Host verwendet.

 

Viele Grüße Arnd

 

[cj_berlin 1.342]

Hmmm. Ich habe es gerade aus Spaß im Labor ausprobiert. Der Session Host erbt nicht das Zertifikat vom Deployment, dieses ist in keinem Store vorhanden:

 

Und dennoch wird bei der Verbindung...

 

...das Zertifikat des Deployments (und auch dessen Name) verwendet:

 

Die einzige Anpassung, die ich gemacht habe, ist:

aber das beseitigt *eigentlich* einen anderen Pop-Up.

Der RD-Listener am Broker hat allerdings sehr wohl das Wildcard-Zertifikat gebunden.

 

 

Na toll, jetzt kann ich keine Screenshots mehr posten.

Aber eine andere Idee: Hat Dein Wildcard-Zertifikat den Wildcard-String auch im SAN oder evtl. nur im Subject?

 

[WSUSPraxis 48]

Hallo Evgenij,

 

danke Dir für den Einsatz.

 

Okay jetzt wird es extrem Verrückt ! Wenn ich mir das RDP File über RDWEB runterlade und verwende - Dann kommt keine Warnung ? Wo liegt mein Denkfehler ?

 

Viele Grüße Arnd

[cj_berlin 1.342]

Gegenfrage: Was verwendest Du denn sonst?