Jump to content

Zertifikatsproblem mit RDS


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

Empfohlene Beiträge

Liebe Fachleute,

 

ich beisse mit gerade die Zähne an einem Zertifikatsproblem aus.

 

Ausgangssituation:

 

2 Domänencontroller Windows Server 2016, einer davon (SRV11) betreibt die interne Zertifizierungsstelle.

Dann 2 RDS-Hosts (SRV18, SRV19) auch Windows Server2016 - SRV18 ist Sitzungshost, macht den Verbindungsbroker (VB) und WebAccess für RDP - SRV19 ist Lizenzserver und auch Sitzungshost.

 

IM DNS gibt es einen Eintrag RDS, der auf SRV18 und SRV19 verweist (Round Robin).

 

Die Bereitstellung ist mit einem Zertifikat der internen Zertifizierungsstelle ausgestattet (für die drei Bereiche VB Serverauthentfizierung, VB RDP-Verschlüsselung und Web Access) das Zertifikat ist als vertrauenswürdig eingestuft.

Das Zertifikat ist ausgestellt auf den Eintrag im DNS - also auf RDS.meineDomain.local

 

Wenn ich nun mit einen Client, der nicht Mitglied der Domäne ist, über VPN per RDP eine Verbindung zu RDS.meineDomain.local aufbaue, erhalte ich nach Eingabe von Benutzer und Passwort abwechselnd unterschiedliche Zertifikatsmeldungen:

- Einmal die Meldung zum Zertifikat RDS.meineDomain.local, "Es konnte keine Sperrprüfung für das Zertifikat durchgeführt werden". - Verbindungsaufbau klappt dann trotzdem und ich lande dann z.B. auf SRV19

- und bei der nächsten Verbindung dann die Meldung zum selbst ausgestellten Zertifikatdes SRV19  - SRV19.meineDomain.local, "Das Zertifikat stammt nicht von einer vertrauenswürdigen Zertifizierungsstelle." - Verbindung klappt auch hier und ich lande dann auch auf SRV19 oder auch SRV18 - je nachdem, welcher mir dann vom VB zugewiesen wird.

 

Die unterschiedlichen Zertifikatsmeldungen ergeben sich offensichtlich aus der Verteilung des Zugriffs aus dem DNS: lande ich mit der Anfrage bei SRV18 bekomme ich das Zertifikat RDS.meineDomain.local, lande ich bei SRV19, bekomme ich dessen selbst ausgestelltes Zertifikat.

 

Aber warum?

 

Auf beiden Servern SRV18 und SRV19 ist das Zertifikat RDS.meineDomain.local im lokalen Zertifaktsspeicher "Eigene Zertifikate" und "Remotedesktop" hinterlegt. Zusätzlich liegt dort jeweils auch das Zertifikat der internen CA und ein selbst ausgestelltes Zertifikat des jeweiligen Servers.

 

SRV18 zeigt mir das Zertifikat des DNS-Eintrages RDS.meineDomain.local, SRV19 offenbar immer sein selbst signiertes Zertifikat - selbst wenn ich es lösche und alle Caches lösche und den IIS von SRV18 resete.

 

Kann mir jemand dieses Verhalten plausibel erklären? Wo mache ich etwas falsch?

 

Darüber hinaus bringe ich den externen Client auch nicht dazu, einem oder beiden Zertifikaten zu vertrauen - und wenn ich sie noch so oft in den Zertifikatsspeicher installiere.

 

Entschuldigt den langen Text - ich hoffe ich konnte mein Problem deutlich machen. Für Rückfragen stehe ich gerne zur Verfügung - besten Dank im Voraus!

 

MfG Thomas

 

 

 

 

Link zu diesem Kommentar

Danke Jan,

 

wenn ich die beiden angeführten Threads richtig interpretiere, meinst du, ich sollte als Broker einen dedizierten (anderen) Server einsetzen, der nicht auch Sitzungshost ist und im DNS dann explizit auf diesen einen mit RDS.meineDomain.local = VerbindungsbrokerIP verweisen und damit RoundRobin vermeiden? Und damit löst sich auch das Zertfikatsproblem?

 

Hmm - muss ich mal schauen, ob ich die Verbindungsbrokerrolle einfach so woanders hin umgedreht bekomme - ich probiere es mal - und berichte dann - danke!

 

MfG Thomas

Link zu diesem Kommentar

Ich würde dir, wie in den anderen Beiträgen, zu einem dedizierten Broker raten. _Müssen_ tust du nicht.

Ansonsten zitiere ich mich mal aus einem der beiden Beiträge:

Zitat

Erstelle mal eine RDP Datei mit dem Broker (bei dir also TS01.<Domäne>.<tld>) als Ziel und speichere diese ab. Öffne die Datei z.B. mit Notepad und passe folgende Einträge an bzw. füge diese hinzu:


use redirection server name:i:1
loadbalanceinfo:s:tsv://MS Terminal Services Plugin.1.<RDS COLLECTION NAME>

Bei dir wäre es dann aber SRV18 anstelle von TS01.

Link zu diesem Kommentar

Ja - FQDN des Brokers.

 

Edit: Der gleiche Fehler taucht auch auf, wenn ich das direkt in der registry versenke, also mit:

 

DefaultTsvUrl"="tsv://MS Terminal Services Plugin.1.OfficeCollection

 

 

Edit erneut: Manchmal ist man auch schon belämmert - wenn ich in der registry nun denn den richtigen Namen für den Platzhalter angebe, klappts auch mit dem Nachbarn - sorry.

 

Nun verbindet sich der Client brav nacheinander immer mit dem jeweils nächsten freien Host und ich bekomme jedes mal das Zertifikat der Bereitstellung präsentiert -allerdings mit dem Fehler - siehe unten:

 

image.png.0f20c105fbfbbf8c44e5ca6be7841e6b.png

 

Bekomme ich das mit einem internen Zertifikat gelöst? Oder brauche ich da was von einer externen CA?

 

Besten Dank schon mal für deine Hilfe!

 

MfG Thomas

bearbeitet von THC
Link zu diesem Kommentar

Mensch, zahni! Endlich mal ein wirklich hilfreicher Post! Wird man eigentlich Expert Member weil man sich besonders eng an sein Motto hält ? :-)

 

Wenn ich den Pfad für die Sperrprüfung direkt in Explorer einfüge, erreiche ich die Sperrliste aber....

 

 

 

Sperrlistenpfad.JPG.9488dc83350d542427b6c5fd9f414c3f.JPG

 

Allerdings kann ich irgendwie in der Zertifizierungsstelle den HTTP-Pfad nicht richtig veröffentlichen, das ist ausgegraut - irgendwas fehlt da noch - hast du da vielleicht einen Tip aus deinem Fundus, was ich falsch mache bzw. anders machen muss? Danke im Voraus - Thomas

5a8c6c727b4d5_Verfentlichen.JPG.15c9e5977b786c448ac95b19d741699e.JPG

 

 

 

 

Link zu diesem Kommentar
Am 19.2.2018 um 17:02 schrieb THC:

Bekomme ich das mit einem internen Zertifikat gelöst? Oder brauche ich da was von einer externen CA?

Das geht auch mit einem Zertifikat deiner eigenen CA. Ich würde bei sowas aber immer von einer externen CA signieren lassen.

Wo liegen die Sperrlisten? Auf einem IIS? Dann wirst du den Delta-CRL Download noch erlauben müssen: https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd379478(v=ws.10)

 

Beim verwalten der Pfade solltest du einfach den "Hinzufügen" Button wählen und dort dann den Ort angeben, wo die CRLs abgerufen werden können (Und die CRLs dort natürlich auch veröffentlichen).

Am 19.2.2018 um 17:02 schrieb THC:

Ja - FQDN des Brokers.

 

Edit: Der gleiche Fehler taucht auch auf, wenn ich das direkt in der registry versenke, also mit:

 


DefaultTsvUrl"="tsv://MS Terminal Services Plugin.1.OfficeCollection

 

 

Edit erneut: Manchmal ist man auch schon belämmert - wenn ich in der registry nun denn den richtigen Namen für den Platzhalter angebe, klappts auch mit dem Nachbarn - sorry.

Das ist, wie im anderen Thread beschrieben, nur ein Workaroun für alte Clients. Du solltest die RDP entsprechend richtig konfigurieren und verteilen. Zur Not eine über RDWeb generieren.

 

P.S.: Evtl. solltest du deine Server / Domänen / etc. Namen in den Screenshots anonymisieren.

bearbeitet von testperson
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...