Jump to content

RDS Farm Windows Server 2019 SHA256


Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Empfohlene Beiträge

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

 

 

Link zu diesem Kommentar

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...

Link zu diesem Kommentar

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

 

RDS.jpg.dfc55c25020427919c0fcd24c3540212.jpg

 

 

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

 

Viele Grüße Arnd

 

Link zu diesem Kommentar
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?

Link zu diesem Kommentar
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

 

Link zu diesem Kommentar

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:

image.png.baa82ab1325809a80f5b3b7b563003b9.png

 

Und dennoch wird bei der Verbindung...

image.png.a0603e41a124f9069ac174a6ef33bf5d.png

 

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

image.png.31702df1b7841d570718b253dc44a47a.png

 

Die einzige Anpassung, die ich gemacht habe, ist:

image.png.d81a0590777019ba79ebecedcb65fd56.png

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?

 

Link zu diesem Kommentar
Der letzte Beitrag zu diesem Thema ist mehr als 180 Tage alt. Bitte erstelle einen neuen Beitrag zu Deiner Anfrage!

Schreibe einen Kommentar

Du kannst jetzt antworten und Dich später registrieren. Falls Du bereits ein Mitglied bist, logge Dich jetzt ein.

Gast
Auf dieses Thema antworten...

×   Du hast formatierten Text eingefügt.   Formatierung jetzt entfernen

  Only 75 emoji are allowed.

×   Dein Link wurde automatisch eingebettet.   Einbetten rückgängig machen und als Link darstellen

×   Dein vorheriger Inhalt wurde wiederhergestellt.   Editor-Fenster leeren

×   Du kannst Bilder nicht direkt einfügen. Lade Bilder hoch oder lade sie von einer URL.

×
×
  • Neu erstellen...